From owner-ipng@sunroof.eng.sun.com Tue Apr 1 03:26:18 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 h31BQIPL022959; Tue, 1 Apr 2003 03:26:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31BQI9U022958; Tue, 1 Apr 2003 03:26: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.9+Sun/8.12.9) with ESMTP id h31BQEPL022951 for ; Tue, 1 Apr 2003 03:26: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 h31BQMcU000039 for ; Tue, 1 Apr 2003 03:26: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 EAA04995 for ; Tue, 1 Apr 2003 04:26:16 -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 11:25: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; Tue, 1 Apr 2003 11:22: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; Tue, 1 Apr 2003 11:25:46 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, 1 Apr 2003 11:25:00 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 h31BOc33079028; Tue, 1 Apr 2003 13:24:42 +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 h31BOL0Z267486; Tue, 1 Apr 2003 13:24:27 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59164 from ; Tue, 1 Apr 2003 13:23:59 +0200 Message-Id: <3E89768C.7CF81D56@hursley.ibm.com> Date: Tue, 01 Apr 2003 13:22:52 +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: alh-ietf@tndh.net Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft IPv6 Minutes from Atlanta IETF References: <076701c2f7a9$fc195ed0$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: > > 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. Indeed, it is the ambiguity of RFC 1597/1918 addresses that leads to most of their unpleasant effects (including the temptation to translate them). And it is the ambiguity of SLs as defined today that I find most objectionable. > > 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. Which does not require ambiguity. Hence my belief that we should clear our minds by agreeing to deprecate SLs as defined today, which would get rid of ambiguous address space and leave us free to define what we really need. 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 Apr 1 03:58: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 h31BwoPL023435; Tue, 1 Apr 2003 03:58:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31BwoBk023434; Tue, 1 Apr 2003 03:58: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 h31BwlPL023426 for ; Tue, 1 Apr 2003 03:58: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 h31BwsHP007146 for ; Tue, 1 Apr 2003 03:58: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 DAA26996 for ; Tue, 1 Apr 2003 03:58:48 -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, 1 Apr 2003 11:58: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; Tue, 1 Apr 2003 11:58:21 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 11:58:20 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, 1 Apr 2003 11:58:19 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 h31BtMdk031200; Tue, 1 Apr 2003 13:55:22 +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 h31BtH5K281840; Tue, 1 Apr 2003 13:55:21 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA51234 from ; Tue, 1 Apr 2003 13:55:15 +0200 Message-Id: <3E897DE0.85A84EED@hursley.ibm.com> Date: Tue, 01 Apr 2003 13:54: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: alh-ietf@tndh.net Cc: jbartas@iniche.com, ipng@sunroof.eng.sun.com Subject: Re: Outlawing (Avoiding) NAT with IPv6 References: <07a201c2f7d7$157391c0$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: > > 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. Actually not, if you have a domestic /48 or /64 prefix. But the MobileIP solution looks OK. 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 Apr 1 04:25:59 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 h31CPxPL023783; Tue, 1 Apr 2003 04:25:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31CPxak023782; Tue, 1 Apr 2003 04:25: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.9+Sun/8.12.9) with ESMTP id h31CPtPL023775 for ; Tue, 1 Apr 2003 04:25: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 h31CQ2HP012280 for ; Tue, 1 Apr 2003 04:26:02 -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 FAA02363 for ; Tue, 1 Apr 2003 05:25: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, 1 Apr 2003 12:25: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, 1 Apr 2003 12:22: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, 1 Apr 2003 12:25:56 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, 1 Apr 2003 12:25:52 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 h31COm33016806; Tue, 1 Apr 2003 14:24:51 +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 h31COh5K240154; Tue, 1 Apr 2003 14:24:47 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44600 from ; Tue, 1 Apr 2003 14:24:41 +0200 Message-Id: <3E8984C6.D05E9B6B@hursley.ibm.com> Date: Tue, 01 Apr 2003 14:23:34 +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: alh-ietf@tndh.net Cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <076901c2f7ac$f7017a60$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: > > 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. I prefer to think about this the other way round: kill the ambiguous space, which we have learnt the hard way is a mistake, and then design the alternative, which may well be unrouteable GUPI (and for all I care, starts with FEC::/10). > 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? I think the scenario where two networks merge or build a VPN between them would remain messy. You will remember Bob Moskowitz's analysis of the ANX scenario with Net 10, which seemed to be unsolvable. I hear from IBM Global Services that this is still a daily problem with hosted customers, when several of them need to access RFC 1918 addresses from the same hosting center. So it's just cleaner not to have the problem at all. However, an RA flag rather than a magic prefix seems like a very good idea in any case. It is robust under a number of assumptions about the future. 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 Apr 1 08:05: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 h31G5QPL026397; Tue, 1 Apr 2003 08:05:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31G5Q3w026396; Tue, 1 Apr 2003 08:05: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.9+Sun/8.12.9) with ESMTP id h31G5MPL026389 for ; Tue, 1 Apr 2003 08:05:22 -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 h31G5TcU005855 for ; Tue, 1 Apr 2003 08:05:29 -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 JAA17708 for ; Tue, 1 Apr 2003 09:05: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; Tue, 1 Apr 2003 16:05: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; Tue, 1 Apr 2003 16:05: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; Tue, 1 Apr 2003 16:05:18 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 16:05:18 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 01 Apr 2003 08:04:17 -0800 Reply-To: From: "Tony Hain" To: "'Pekka Savola'" Cc: , Subject: RE: Outlawing (Avoiding) NAT with IPv6 Date: Tue, 1 Apr 2003 08:04:17 -0800 Message-Id: <085f01c2f868$59b02b00$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: > ... > By the ISP? RFC3041 doesn't give you anything except a false > sense of anonomity and broken apps. It provides anonomity for devices that appear on multiple networks. It does not prevent an ISP from identifying the customer demarc. It does not break apps that were not broken already due to a reliance on a DNS ptr record as some warped form of security. 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 Apr 1 09:33:02 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 h31HX2PL027037; Tue, 1 Apr 2003 09:33:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31HX2et027036; Tue, 1 Apr 2003 09: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h31HWwPL027029 for ; Tue, 1 Apr 2003 09: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 h31HX6cU002169 for ; Tue, 1 Apr 2003 09: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 JAA09898 for ; Tue, 1 Apr 2003 09:33: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; Tue, 1 Apr 2003 17:32:59 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 17:32: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, 1 Apr 2003 17:32:58 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; Tue, 1 Apr 2003 17:32:58 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 h31GRVA01838; Tue, 1 Apr 2003 18:27:38 +0200 Message-Id: <3E89BDF3.305@it.su.se> Date: Tue, 01 Apr 2003 18:27:31 +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: alh-ietf@tndh.net CC: "'Pekka Savola'" , jbartas@iniche.com, ipng@sunroof.eng.sun.com Subject: Re: Outlawing (Avoiding) NAT with IPv6 References: <085f01c2f868$59b02b00$ee1a4104@eagleswings> In-Reply-To: <085f01c2f868$59b02b00$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: >Pekka Savola wrote: > > >>... >>By the ISP? RFC3041 doesn't give you anything except a false >>sense of anonomity and broken apps. >> >> > >It provides anonomity for devices that appear on multiple networks. It >does not prevent an ISP from identifying the customer demarc. It does >not break apps that were not broken already due to a reliance on a DNS >ptr record as some warped form of security. > >Tony > > Applications break for _completely_ different reasons than that 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 Apr 1 11:48:58 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 h31JmwPL027543; Tue, 1 Apr 2003 11:48:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31Jmv1P027542; Tue, 1 Apr 2003 11:48: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 h31JmsPL027535 for ; Tue, 1 Apr 2003 11:48: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 h31Jn2HP020114 for ; Tue, 1 Apr 2003 11:49: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 LAA22536 for ; Tue, 1 Apr 2003 11:48:56 -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 19:48:40 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 19:48:35 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 19:48:34 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; Tue, 1 Apr 2003 19:48:34 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.34]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA06590 for ; Tue, 1 Apr 2003 11:48:10 -0800 (PST) Message-Id: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 Apr 2003 14:37:56 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: CONSENSUS CALL: Deprecating Site-Local Addressing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, At the IPv6 WG meetings in SF, we reached consensus on several points, all of which will be confirmed on the IPv6 mailing list. One point in particular seems to be the source of discussion on our list and elsewhere, so we will check this consensus on the mailing list now. Specifically, we would like to check the consensus of the IPv6 WG regarding the deprecation of site-local addresses. This email asks those that were NOT present at the Thursday IPv6 meeting in SF to express their opinions on a question that was asked of the room. If you expressed an opinion on this issue in SF you can skip this message; in any case you MUST NOT respond to this query. By now, all of you have heard about the IPv6 meeting held on Thursday, March 20th, where we discussed what to do about IPv6 site-local addressing. At the meeting, the chairs (Bob Hinden and Margaret Wasserman) changed the agenda to include a joint presentation by the chairs on various options for site-local usage. There were no objections to the agenda change. The chairs' joint presentation can be found at: http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt After the chairs' joint presentation, there was over an hour of lively discussion that covered many aspects of site-local addressing. Draft minutes of the discussion can be found at: http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt These minutes are a summary of the discussion, and they did not capture every detail of the discussion. During the discussion, it became clear that the "exclusive" model proposed by the chairs had some fundamental flaws and was not a viable option. The WG was unwilling to choose between the three options presented for site-local usage ("limited", "exclusive" or "moderate"), believing that all three models represented a poor cost vs. benefit trade-off. And, as the discussion developed, it became clear that there was growing support for deprecating site-local addressing. After the usual discussion regarding the phrasing and meaning of the question (not all of which was captured in the minutes), the chairs asked a yes/no question: "Should we deprecate IPv6 site-local unicast addressing?" There was clear consensus in the room to deprecate site-local addressing. So, now it is time to check that consensus on the mailing list. In order to get a good read for consensus on this point, PLEASE adhere to the following rules: NOTE: DO NOT reply if you already expressed an opinion during the IPv6 WG meeting in SF! - Make your response very clear (YES or NO). - Respond by Monday, April 7th, 2003 at 5pm EST. - Do NOT respond if you were physically present in SF and participated in the consensus call at that time (We are trusting you!). - Respond to this thread with the subject intact. - Respond only once. - Clearly identify yourself (in the From: line or inside your message). - Include the IPv6 WG mailing list in your response (ipng@sunroof.eng.sun.com). - PLEASE do NOT start any discussion in this thread (Discussions are encouraged in other threads). Any responses that do not adhere to these rules may not be counted. The question is: Should we deprecate IPv6 site-local unicast addressing? Valid responses are: "YES -- Deprecate site-local unicast addressing". "NO -- Do not deprecate site-local unicast addressing". If you express an opinion not to deprecate site-local addressing, it would be helpful if you would provide a reason. Providing a reason is completely optional, but it may help us to determine how to move forward if the consensus to deprecate site-locals does not hold. Possible reasons include: - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained for their access control benefits. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. - Other (please specify). Please, make your response _very_ clear (either YES or NO), or it will not be counted. Please Note: DO NOT respond if you already participated in the consensus call at the meeting in SF. At the meeting, there were 102 people who raised their hands for YES (deprecate site-locals) and 20 people who raised their hands for NO (do not deprecate site-locals). We will add the responses received on the mailing list to the hands counted at the meeting, and use that information to determine full WG consensus on this issue. If you feel an urgent need to reply to something that someone sends in response to this message, please do it in a SEPARATE THREAD with a different subject line. No discussion in this thread! Please voice your opinion on this important issue. Bob Hinden & Margaret Wasserman IPv6 WG Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 11:52:53 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 h31JqrPL027654; Tue, 1 Apr 2003 11:52:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31JqrmN027653; Tue, 1 Apr 2003 11:52: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.9+Sun/8.12.9) with ESMTP id h31JqmPL027643 for ; Tue, 1 Apr 2003 11:52: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 h31JquHP021520 for ; Tue, 1 Apr 2003 11:52: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 MAA07072 for ; Tue, 1 Apr 2003 12:52: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, 1 Apr 2003 19:52: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, 1 Apr 2003 19:52: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; Tue, 1 Apr 2003 19:52:49 Z Received: from psg.com (psg.com [147.28.0.62]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 19:52:49 Z Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 190RoC-0006PR-00; Tue, 01 Apr 2003 11:52:36 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 190RoB-000AqX-00; Tue, 01 Apr 2003 11:52:35 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 1 Apr 2003 11:52:34 -0800 To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Message-Id: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 11:55:16 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 h31JtFPL027746; Tue, 1 Apr 2003 11:55:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31JtFxB027745; Tue, 1 Apr 2003 11:55: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.9+Sun/8.12.9) with ESMTP id h31JtCPL027738 for ; Tue, 1 Apr 2003 11:55:12 -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 h31JtJcU024855 for ; Tue, 1 Apr 2003 11:55: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 LAA21318 for ; Tue, 1 Apr 2003 11:55:14 -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 19:55:13 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 19:52: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; Tue, 1 Apr 2003 19:55:13 Z Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 19:55:13 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 h31JtAMR028380; Tue, 1 Apr 2003 14:55:11 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-192.cisco.com [161.44.149.192]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA09637; Tue, 1 Apr 2003 14:55:10 -0500 (EST) Message-Id: <4.3.2.7.2.20030401145307.00b51908@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 Apr 2003 14:55:11 -0500 To: Margaret Wasserman From: Ralph Droms Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Cc: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@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 Margaret, Sorry to ask a question for which the answer might be obvious... You wrote: At 02:37 PM 4/1/2003 -0500, Margaret Wasserman wrote: >NOTE: DO NOT reply if you already expressed an opinion during >the IPv6 WG meeting in SF! Does "expressed an opinion" mean "stepped to the mike and spoke" or "raised your hand during the consensus determination at the meeting"? - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 12:04: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 h31K41PL028270; Tue, 1 Apr 2003 12:04:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31K41WX028269; Tue, 1 Apr 2003 12:04: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.9+Sun/8.12.9) with ESMTP id h31K3vPL028259 for ; Tue, 1 Apr 2003 12:03:57 -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 h31K45HP025957 for ; Tue, 1 Apr 2003 12:04:05 -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 NAA24418 for ; Tue, 1 Apr 2003 13:03:54 -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 20:03:24 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 20:00: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; Tue, 1 Apr 2003 20:03:24 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; Tue, 1 Apr 2003 20:03:24 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.34]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA17484; Tue, 1 Apr 2003 12:02:51 -0800 (PST) Message-Id: <5.1.0.14.2.20030401145930.04a10210@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 Apr 2003 15:00:57 -0500 To: Ralph Droms From: Margaret Wasserman Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4.3.2.7.2.20030401145307.00b51908@funnel.cisco.com> References: <5.1.0.14.2.20030401143711.04a0f848@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 >Does "expressed an opinion" mean "stepped to the mike and >spoke" or "raised your hand during the consensus determination >at the meeting"? The latter. Do not respond to this consensus call if you already raised your hand at the meeting in SF. People who spoke at the mike, but did not express an opinion during the show of hands, may express their YES/NO opinion now on the list. Thanks, Ralph. 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 Tue Apr 1 12:11: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 h31KBDPL028538; Tue, 1 Apr 2003 12:11:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31KBD8G028537; Tue, 1 Apr 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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h31KB9PL028527 for ; Tue, 1 Apr 2003 12:11:09 -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 h31KBHHP028206 for ; Tue, 1 Apr 2003 12:11:17 -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 MAA02626 for ; Tue, 1 Apr 2003 12:11:10 -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, 1 Apr 2003 20:10:55 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 20:10: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; Tue, 1 Apr 2003 20:10:54 Z Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 20:10:54 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 h31KAr9T006956 for ; Tue, 1 Apr 2003 12:10:53 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 1 Apr 2003 12:10:53 -0800 Received: from apple.com (graejo5.apple.com [17.202.43.251]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id h31KArd06192 for ; Tue, 1 Apr 2003 12:10:53 -0800 (PST) Date: Tue, 1 Apr 2003 12:10:53 -0800 Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joshua Graessley To: ipng@sunroof.eng.sun.com Content-Transfer-Encoding: 7bit In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Message-Id: <0ABEA727-647E-11D7-8729-000A959D832C@apple.com> X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 12:14:15 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 h31KEEPL028713; Tue, 1 Apr 2003 12:14:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31KEEOS028712; Tue, 1 Apr 2003 12:14: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.9+Sun/8.12.9) with ESMTP id h31KE8PL028689 for ; Tue, 1 Apr 2003 12:14:08 -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 h31KEFcU001841 for ; Tue, 1 Apr 2003 12:14: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 NAA27676 for ; Tue, 1 Apr 2003 13:14: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; Tue, 1 Apr 2003 20:13:52 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, 1 Apr 2003 20:13: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, 1 Apr 2003 20:13:48 Z Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 20:13:48 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 8670E58226; Tue, 1 Apr 2003 15:02:25 -0500 (EST) Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h31KDke00981; Tue, 1 Apr 2003 15:13:46 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id AB2287B4D; Tue, 1 Apr 2003 15:13:46 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: Your message of "Tue, 01 Apr 2003 14:46:35 EST." <5.1.0.14.2.20030401143803.04a06d38@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Apr 2003 15:13:46 -0500 Message-Id: <20030401201346.AB2287B4D@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> "YES -- Deprecate site-local unicast addressing". --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 Apr 1 12:15: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 h31KFbPL028828; Tue, 1 Apr 2003 12:15:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31KFbxZ028827; Tue, 1 Apr 2003 12:15: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.9+Sun/8.12.9) with ESMTP id h31KFVPL028820 for ; Tue, 1 Apr 2003 12:15: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 h31KFdcU002461 for ; Tue, 1 Apr 2003 12:15:39 -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 NAA28540 for ; Tue, 1 Apr 2003 13:15:33 -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 20:15:32 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 20:15:32 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 20:15:31 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 20:15:31 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 01 Apr 2003 12:15:28 -0800 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Tue, 1 Apr 2003 12:15:28 -0800 Message-Id: <08a801c2f88b$70a5eca0$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.20030401143711.04a0f848@mail.windriver.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing - Site-locals should be retained for disconnected sites. Easy to get No public registration, payment, customer/provider relationship, or approval required. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. Stable Both during ISP changes, and for intermittently connected networks. - Site-locals should be retained for their access control benefits. Private Well-known routing filter provides multiple levels of filtering to ensure a single error does not expose the network to global access. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Margaret > Wasserman > Sent: Tuesday, April 01, 2003 11:38 AM > To: ipng@sunroof.eng.sun.com > Subject: CONSENSUS CALL: Deprecating Site-Local Addressing > > > > Hi All, > > At the IPv6 WG meetings in SF, we reached consensus on > several points, all of which will be confirmed on the IPv6 > mailing list. One point in particular seems to be the source > of discussion on our list and elsewhere, so we will check > this consensus on the mailing list now. Specifically, we > would like to check the consensus of the IPv6 WG regarding > the deprecation of site-local addresses. > > This email asks those that were NOT present at the Thursday > IPv6 meeting in SF to express their opinions on a question that was > asked of the room. If you expressed an opinion on this issue in > SF you can skip this message; in any case you MUST NOT > respond to this query. > > By now, all of you have heard about the IPv6 meeting held on > Thursday, March 20th, where we discussed what to do about > IPv6 site-local addressing. > > At the meeting, the chairs (Bob Hinden and Margaret > Wasserman) changed the agenda to include a joint presentation > by the chairs on various options for site-local usage. There > were no objections to the agenda change. > > The chairs' joint presentation can be found at: > > http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt > > After the chairs' joint presentation, there was over an hour > of lively discussion that covered many aspects of site-local > addressing. Draft minutes of the discussion can be found at: > > http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt > > These minutes are a summary of the discussion, and they did > not capture every detail of the discussion. > > During the discussion, it became clear that the "exclusive" > model proposed by the chairs had some fundamental flaws and > was not a viable option. The WG was unwilling to choose > between the three options presented for site-local usage > ("limited", "exclusive" or "moderate"), believing that all > three models represented a poor cost vs. benefit trade-off. > And, as the discussion developed, it became clear that there > was growing support for deprecating site-local addressing. > > After the usual discussion regarding the phrasing and meaning > of the question (not all of which was captured in the > minutes), the chairs asked a yes/no question: "Should we > deprecate IPv6 site-local unicast addressing?" There was > clear consensus in the room to deprecate site-local > addressing. So, now it is time to check that consensus on > the mailing list. > > In order to get a good read for consensus on this point, > PLEASE adhere to the following rules: > > NOTE: DO NOT reply if you already expressed an opinion > during the IPv6 WG meeting in SF! > > - Make your response very clear (YES or NO). > - Respond by Monday, April 7th, 2003 at 5pm EST. > - Do NOT respond if you were physically present > in SF and participated in the consensus > call at that time (We are trusting you!). > - Respond to this thread with the subject intact. > - Respond only once. > - Clearly identify yourself (in the From: line or > inside your message). > - Include the IPv6 WG mailing list in your response > (ipng@sunroof.eng.sun.com). > - PLEASE do NOT start any discussion in this thread > (Discussions are encouraged in other threads). > > Any responses that do not adhere to these rules may not be counted. > > The question is: > > Should we deprecate IPv6 site-local unicast addressing? > > Valid responses are: > > "YES -- Deprecate site-local unicast addressing". > "NO -- Do not deprecate site-local unicast addressing". > > If you express an opinion not to deprecate site-local > addressing, it would be helpful if you would provide a > reason. Providing a reason is completely optional, but it > may help us to determine how to move forward if the consensus > to deprecate site-locals does not hold. Possible reasons include: > > - Site-locals should be retained for disconnected sites. > - Site-locals should be retained for intermittently > connected sites. > - Site-locals should be retained for their access control > benefits. > - Site-locals should be retained as a means for internal > connections to survive global prefix renumbering. > - Other (please specify). > > Please, make your response _very_ clear (either YES or NO), > or it will not be counted. > > Please Note: DO NOT respond if you already participated in > the consensus call at the meeting in SF. At the meeting, > there were 102 people who raised their hands for YES > (deprecate site-locals) and 20 people who raised their hands > for NO (do not deprecate site-locals). We will add the > responses received on the mailing list to the hands counted > at the meeting, and use that information to determine full WG > consensus on this issue. > > If you feel an urgent need to reply to something that someone > sends in response to this message, please do it in a SEPARATE > THREAD with a different subject line. No discussion in this thread! > > Please voice your opinion on this important issue. > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 1 12:16:48 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 h31KGmPL028981; Tue, 1 Apr 2003 12:16:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31KGmrc028980; Tue, 1 Apr 2003 12:16: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.9+Sun/8.12.9) with ESMTP id h31KGhPL028967 for ; Tue, 1 Apr 2003 12:16: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 h31KGpHP000224 for ; Tue, 1 Apr 2003 12:16:51 -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 NAA01237 for ; Tue, 1 Apr 2003 13:16:43 -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 20:16: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, 1 Apr 2003 20:16: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; Tue, 1 Apr 2003 20:16:38 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; Tue, 1 Apr 2003 20:16:38 Z Received: from cisco.com (dhcp-171-71-194-128.cisco.com [171.71.194.128]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA07838; Tue, 1 Apr 2003 12:16:34 -0800 (PST) Message-Id: <3E89F3A2.8090505@cisco.com> Date: Tue, 01 Apr 2003 12:16:34 -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: Margaret Wasserman CC: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing". Short answer: SLs need to be deprecated in favor of better tooling. SLs as currently envisioned eliminate justification to move to IPv6. Applications won't know how to make a proper choice. Encourages behavior that breaks connectivity. 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 Tue Apr 1 12:17:22 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 h31KHMPL029060; Tue, 1 Apr 2003 12:17:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31KHMNb029059; Tue, 1 Apr 2003 12:17: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 h31KHGPL029046 for ; Tue, 1 Apr 2003 12:17:16 -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 h31KHNHP000464 for ; Tue, 1 Apr 2003 12:17: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 MAA06798 for ; Tue, 1 Apr 2003 12:17:17 -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, 1 Apr 2003 20:17: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; Tue, 1 Apr 2003 20:17:07 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 20:17:07 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; Tue, 1 Apr 2003 20:17:06 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 h31KH4Oc020182; Tue, 1 Apr 2003 23:17:04 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h31KH4gY020178; Tue, 1 Apr 2003 23:17:04 +0300 Date: Tue, 1 Apr 2003 23:17:04 +0300 Message-Id: <200304012017.h31KH4gY020178@burp.tkv.asdf.org> From: Markku Savela To: mrw@windriver.com CC: ipng@sunroof.eng.sun.com In-reply-to: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> (message from Margaret Wasserman on Tue, 01 Apr 2003 14:37:56 -0500) Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "NO -- Do not deprecate site-local unicast addressing". - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained for their access control benefits. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 12:18: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 h31KIKPL029162; Tue, 1 Apr 2003 12:18:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31KIKZK029161; Tue, 1 Apr 2003 12:18: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 h31KIFPL029145 for ; Tue, 1 Apr 2003 12:18: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 h31KIMHP000947 for ; Tue, 1 Apr 2003 12:18:23 -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 NAA00804 for ; Tue, 1 Apr 2003 13:18:17 -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 20:18: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; Tue, 1 Apr 2003 20:17:54 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 20:17:54 Z Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 20:17:54 Z Received: from sbctri.tri.sbc.com (mayhem-web-dmz.tri.sbc.com [144.60.9.137]) by howler.tri.sbc.com (8.12.9/8.12.5) with ESMTP id h31KHpMs029796; Tue, 1 Apr 2003 14:17:51 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id h31KHnm28560; Tue, 1 Apr 2003 14:17:49 -0600 (CST) Received: by trimail2 with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 14:17:48 -0600 Message-Id: <905A1C4ABF353F4C8CC16FA9F53DD0D632283B@trimail2> From: "Chen, Weijing" To: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Tue, 1 Apr 2003 14:17:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing. -- Weijing Chen -----Original Message----- From: Margaret Wasserman [mailto:mrw@windriver.com] Sent: Tuesday, April 01, 2003 1:38 PM To: ipng@sunroof.eng.sun.com Subject: CONSENSUS CALL: Deprecating Site-Local Addressing Hi All, At the IPv6 WG meetings in SF, we reached consensus on several points, all of which will be confirmed on the IPv6 mailing list. One point in particular seems to be the source of discussion on our list and elsewhere, so we will check this consensus on the mailing list now. Specifically, we would like to check the consensus of the IPv6 WG regarding the deprecation of site-local addresses. This email asks those that were NOT present at the Thursday IPv6 meeting in SF to express their opinions on a question that was asked of the room. If you expressed an opinion on this issue in SF you can skip this message; in any case you MUST NOT respond to this query. By now, all of you have heard about the IPv6 meeting held on Thursday, March 20th, where we discussed what to do about IPv6 site-local addressing. At the meeting, the chairs (Bob Hinden and Margaret Wasserman) changed the agenda to include a joint presentation by the chairs on various options for site-local usage. There were no objections to the agenda change. The chairs' joint presentation can be found at: http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt After the chairs' joint presentation, there was over an hour of lively discussion that covered many aspects of site-local addressing. Draft minutes of the discussion can be found at: http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt These minutes are a summary of the discussion, and they did not capture every detail of the discussion. During the discussion, it became clear that the "exclusive" model proposed by the chairs had some fundamental flaws and was not a viable option. The WG was unwilling to choose between the three options presented for site-local usage ("limited", "exclusive" or "moderate"), believing that all three models represented a poor cost vs. benefit trade-off. And, as the discussion developed, it became clear that there was growing support for deprecating site-local addressing. After the usual discussion regarding the phrasing and meaning of the question (not all of which was captured in the minutes), the chairs asked a yes/no question: "Should we deprecate IPv6 site-local unicast addressing?" There was clear consensus in the room to deprecate site-local addressing. So, now it is time to check that consensus on the mailing list. In order to get a good read for consensus on this point, PLEASE adhere to the following rules: NOTE: DO NOT reply if you already expressed an opinion during the IPv6 WG meeting in SF! - Make your response very clear (YES or NO). - Respond by Monday, April 7th, 2003 at 5pm EST. - Do NOT respond if you were physically present in SF and participated in the consensus call at that time (We are trusting you!). - Respond to this thread with the subject intact. - Respond only once. - Clearly identify yourself (in the From: line or inside your message). - Include the IPv6 WG mailing list in your response (ipng@sunroof.eng.sun.com). - PLEASE do NOT start any discussion in this thread (Discussions are encouraged in other threads). Any responses that do not adhere to these rules may not be counted. The question is: Should we deprecate IPv6 site-local unicast addressing? Valid responses are: "YES -- Deprecate site-local unicast addressing". "NO -- Do not deprecate site-local unicast addressing". If you express an opinion not to deprecate site-local addressing, it would be helpful if you would provide a reason. Providing a reason is completely optional, but it may help us to determine how to move forward if the consensus to deprecate site-locals does not hold. Possible reasons include: - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained for their access control benefits. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. - Other (please specify). Please, make your response _very_ clear (either YES or NO), or it will not be counted. Please Note: DO NOT respond if you already participated in the consensus call at the meeting in SF. At the meeting, there were 102 people who raised their hands for YES (deprecate site-locals) and 20 people who raised their hands for NO (do not deprecate site-locals). We will add the responses received on the mailing list to the hands counted at the meeting, and use that information to determine full WG consensus on this issue. If you feel an urgent need to reply to something that someone sends in response to this message, please do it in a SEPARATE THREAD with a different subject line. No discussion in this thread! Please voice your opinion on this important issue. Bob Hinden & Margaret Wasserman IPv6 WG Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Apr 1 12:27: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 h31KRiPL000558; Tue, 1 Apr 2003 12:27:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31KRi7l000557; Tue, 1 Apr 2003 12:27:44 -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.9+Sun/8.12.9) with ESMTP id h31KRePL000544 for ; Tue, 1 Apr 2003 12:27:40 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h31KRkuK021958; Tue, 1 Apr 2003 15:27:46 -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 h31KRkaj006975; Tue, 1 Apr 2003 15:27:46 -0500 (EST) Message-Id: <200304012027.h31KRkaj006975@thunk.east.sun.com> From: Bill Sommerfeld To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: Your message of "Tue, 01 Apr 2003 14:37:56 EST." <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 01 Apr 2003 15:27:46 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing Does not provide any tangible security benefit. Provides false sense of security. Increases application complexity. Reduces application reliability. Requires too many compensating hacks to other protocols. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 12:28: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 h31KStPL000656; Tue, 1 Apr 2003 12:28:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31KSsog000655; Tue, 1 Apr 2003 12:28: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.9+Sun/8.12.9) with ESMTP id h31KSpPL000648 for ; Tue, 1 Apr 2003 12:28: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 h31KSwHP005208 for ; Tue, 1 Apr 2003 12:28: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 NAA06936 for ; Tue, 1 Apr 2003 13:28:39 -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, 1 Apr 2003 20:28: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; Tue, 1 Apr 2003 20:28: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; Tue, 1 Apr 2003 20:28:31 Z Received: from DAMASCUS.chrims.com ([167.160.208.2] [167.160.208.2]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 20:28:30 Z Received: by DAMASCUS.chrims.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 12:28:28 -0800 Message-Id: <2C87B4813250464C9BFA684F807673D5780DA2@DAMASCUS.chrims.com> From: Sean Gray To: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Tue, 1 Apr 2003 12:28:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "NO -- Do not deprecate site-local unicast addressing". Reasons that I see: - Site-locals should be retained for disconnected sites. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. -----Original Message----- From: Margaret Wasserman [mailto:mrw@windriver.com] Sent: Tuesday, April 01, 2003 11:38 AM To: ipng@sunroof.eng.sun.com Subject: CONSENSUS CALL: Deprecating Site-Local Addressing Hi All, At the IPv6 WG meetings in SF, we reached consensus on several points, all of which will be confirmed on the IPv6 mailing list. One point in particular seems to be the source of discussion on our list and elsewhere, so we will check this consensus on the mailing list now. Specifically, we would like to check the consensus of the IPv6 WG regarding the deprecation of site-local addresses. This email asks those that were NOT present at the Thursday IPv6 meeting in SF to express their opinions on a question that was asked of the room. If you expressed an opinion on this issue in SF you can skip this message; in any case you MUST NOT respond to this query. By now, all of you have heard about the IPv6 meeting held on Thursday, March 20th, where we discussed what to do about IPv6 site-local addressing. At the meeting, the chairs (Bob Hinden and Margaret Wasserman) changed the agenda to include a joint presentation by the chairs on various options for site-local usage. There were no objections to the agenda change. The chairs' joint presentation can be found at: http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt After the chairs' joint presentation, there was over an hour of lively discussion that covered many aspects of site-local addressing. Draft minutes of the discussion can be found at: http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt These minutes are a summary of the discussion, and they did not capture every detail of the discussion. During the discussion, it became clear that the "exclusive" model proposed by the chairs had some fundamental flaws and was not a viable option. The WG was unwilling to choose between the three options presented for site-local usage ("limited", "exclusive" or "moderate"), believing that all three models represented a poor cost vs. benefit trade-off. And, as the discussion developed, it became clear that there was growing support for deprecating site-local addressing. After the usual discussion regarding the phrasing and meaning of the question (not all of which was captured in the minutes), the chairs asked a yes/no question: "Should we deprecate IPv6 site-local unicast addressing?" There was clear consensus in the room to deprecate site-local addressing. So, now it is time to check that consensus on the mailing list. In order to get a good read for consensus on this point, PLEASE adhere to the following rules: NOTE: DO NOT reply if you already expressed an opinion during the IPv6 WG meeting in SF! - Make your response very clear (YES or NO). - Respond by Monday, April 7th, 2003 at 5pm EST. - Do NOT respond if you were physically present in SF and participated in the consensus call at that time (We are trusting you!). - Respond to this thread with the subject intact. - Respond only once. - Clearly identify yourself (in the From: line or inside your message). - Include the IPv6 WG mailing list in your response (ipng@sunroof.eng.sun.com). - PLEASE do NOT start any discussion in this thread (Discussions are encouraged in other threads). Any responses that do not adhere to these rules may not be counted. The question is: Should we deprecate IPv6 site-local unicast addressing? Valid responses are: "YES -- Deprecate site-local unicast addressing". "NO -- Do not deprecate site-local unicast addressing". If you express an opinion not to deprecate site-local addressing, it would be helpful if you would provide a reason. Providing a reason is completely optional, but it may help us to determine how to move forward if the consensus to deprecate site-locals does not hold. Possible reasons include: - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained for their access control benefits. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. - Other (please specify). Please, make your response _very_ clear (either YES or NO), or it will not be counted. Please Note: DO NOT respond if you already participated in the consensus call at the meeting in SF. At the meeting, there were 102 people who raised their hands for YES (deprecate site-locals) and 20 people who raised their hands for NO (do not deprecate site-locals). We will add the responses received on the mailing list to the hands counted at the meeting, and use that information to determine full WG consensus on this issue. If you feel an urgent need to reply to something that someone sends in response to this message, please do it in a SEPARATE THREAD with a different subject line. No discussion in this thread! Please voice your opinion on this important issue. Bob Hinden & Margaret Wasserman IPv6 WG Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Apr 1 12:35:14 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 h31KZEPL001198; Tue, 1 Apr 2003 12:35:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31KZEDu001197; Tue, 1 Apr 2003 12:35: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.9+Sun/8.12.9) with ESMTP id h31KZBPL001190 for ; Tue, 1 Apr 2003 12:35:11 -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 h31KZIcU014589 for ; Tue, 1 Apr 2003 12:35: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 MAA26761 for ; Tue, 1 Apr 2003 12:35:13 -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, 1 Apr 2003 20:34: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, 1 Apr 2003 20:34:48 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 20:34:48 Z Received: from paddock.ermy.net (paddock.ermy.net [62.189.30.132]) by relay1.sun.com for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 20:34:47 Z Received: (qmail 14773 invoked by uid 500); 1 Apr 2003 20:34:44 -0000 Date: Tue, 1 Apr 2003 21:34:44 +0100 From: Mark Thompson To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Message-Id: <20030401203444.GD30003@paddock.ermy.net> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "NO -- Do not deprecate site-local unicast addressing" - SLs should be retained for disconnected sites - SLs should be retained for intermittently connected sites - Applications should NOT be aware (or need to be aware) of any difference between site-local and any other address (c.f. anycast); a principal purpose of SLs should be for nodes having site-local access to site-local services, irrespective of the number (0+) of external links to other networks, ephemeral or otherwise. Any requirements, e.g., for split-view DNSes is not this WG's concern - SLs should NOT be retained for their access control benefits and it SHOULD be clearly documented that this is a broken philosophy! Mark Thompson, University of 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 Tue Apr 1 12:38: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 h31KcJPL001394; Tue, 1 Apr 2003 12:38:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31KcJmX001393; Tue, 1 Apr 2003 12:38: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.9+Sun/8.12.9) with ESMTP id h31KcFPL001386 for ; Tue, 1 Apr 2003 12:38:15 -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 h31KcNcU015727 for ; Tue, 1 Apr 2003 12:38:23 -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 NAA10119 for ; Tue, 1 Apr 2003 13:38: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; Tue, 1 Apr 2003 20:38: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; Tue, 1 Apr 2003 20:38: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, 1 Apr 2003 20:38:15 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, 1 Apr 2003 20:38:15 Z Received: (cpmta 13685 invoked from network); 1 Apr 2003 12:38:12 -0800 Received: from 65.247.209.130 (HELO w2knerick) by smtp.register-admin.com (209.228.32.114) with SMTP; 1 Apr 2003 12:38:12 -0800 X-Sent: 1 Apr 2003 20:38:12 GMT Message-Id: <000901c2f88e$d453ee70$08cda8c0@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Tue, 1 Apr 2003 23:39:42 +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 Eric Klein - No we should not deprecate IPv6 site-local unicast addressing ----- Original Message ----- From: "Margaret Wasserman" To: Sent: Tuesday, April 01, 2003 10:37 PM Subject: CONSENSUS CALL: Deprecating Site-Local Addressing > > Hi All, > > At the IPv6 WG meetings in SF, we reached consensus on several > points, all of which will be confirmed on the IPv6 mailing list. > One point in particular seems to be the source of discussion > on our list and elsewhere, so we will check this consensus on the > mailing list now. Specifically, we would like to check the consensus > of the IPv6 WG regarding the deprecation of site-local addresses. > > This email asks those that were NOT present at the Thursday IPv6 > meeting in SF to express their opinions on a question that was > asked of the room. If you expressed an opinion on this issue in > SF you can skip this message; in any case you MUST NOT respond to > this query. > > By now, all of you have heard about the IPv6 meeting held on > Thursday, March 20th, where we discussed what to do about > IPv6 site-local addressing. > > At the meeting, the chairs (Bob Hinden and Margaret Wasserman) > changed the agenda to include a joint presentation by the > chairs on various options for site-local usage. There were > no objections to the agenda change. > > The chairs' joint presentation can be found at: > > http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt > > After the chairs' joint presentation, there was over an hour of > lively discussion that covered many aspects of site-local > addressing. Draft minutes of the discussion can be found at: > > http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt > > These minutes are a summary of the discussion, and they did > not capture every detail of the discussion. > > During the discussion, it became clear that the "exclusive" model > proposed by the chairs had some fundamental flaws and was not > a viable option. The WG was unwilling to choose between the three > options presented for site-local usage ("limited", "exclusive" or > "moderate"), believing that all three models represented a poor > cost vs. benefit trade-off. And, as the discussion developed, it > became clear that there was growing support for deprecating > site-local addressing. > > After the usual discussion regarding the phrasing and meaning > of the question (not all of which was captured in the minutes), > the chairs asked a yes/no question: "Should we deprecate IPv6 > site-local unicast addressing?" There was clear consensus in the > room to deprecate site-local addressing. So, now it is time to > check that consensus on the mailing list. > > In order to get a good read for consensus on this point, PLEASE > adhere to the following rules: > > NOTE: DO NOT reply if you already expressed an opinion during > the IPv6 WG meeting in SF! > > - Make your response very clear (YES or NO). > - Respond by Monday, April 7th, 2003 at 5pm EST. > - Do NOT respond if you were physically present > in SF and participated in the consensus > call at that time (We are trusting you!). > - Respond to this thread with the subject intact. > - Respond only once. > - Clearly identify yourself (in the From: line or > inside your message). > - Include the IPv6 WG mailing list in your response > (ipng@sunroof.eng.sun.com). > - PLEASE do NOT start any discussion in this thread > (Discussions are encouraged in other threads). > > Any responses that do not adhere to these rules may not be counted. > > The question is: > > Should we deprecate IPv6 site-local unicast addressing? > > Valid responses are: > > "YES -- Deprecate site-local unicast addressing". > "NO -- Do not deprecate site-local unicast addressing". > > If you express an opinion not to deprecate site-local addressing, it > would be helpful if you would provide a reason. Providing a reason > is completely optional, but it may help us to determine how to move > forward if the consensus to deprecate site-locals does not hold. > Possible reasons include: > > - Site-locals should be retained for disconnected sites. > - Site-locals should be retained for intermittently > connected sites. > - Site-locals should be retained for their access control > benefits. > - Site-locals should be retained as a means for internal > connections to survive global prefix renumbering. > - Other (please specify). > > Please, make your response _very_ clear (either YES or NO), or it will > not be counted. > > Please Note: DO NOT respond if you already participated in the > consensus call at the meeting in SF. At the meeting, there were > 102 people who raised their hands for YES (deprecate site-locals) > and 20 people who raised their hands for NO (do not deprecate > site-locals). We will add the responses received on the mailing > list to the hands counted at the meeting, and use that information > to determine full WG consensus on this issue. > > If you feel an urgent need to reply to something that someone sends > in response to this message, please do it in a SEPARATE THREAD with > a different subject line. No discussion in this thread! > > Please voice your opinion on this important issue. > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 1 12:45: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 h31KjOPL001848; Tue, 1 Apr 2003 12:45:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31KjOjb001847; Tue, 1 Apr 2003 12: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.9+Sun/8.12.9) with ESMTP id h31KjKPL001837 for ; Tue, 1 Apr 2003 12:45: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 h31KjRcU018431 for ; Tue, 1 Apr 2003 12:45: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 NAA21002 for ; Tue, 1 Apr 2003 13:45:22 -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 20:45: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; Tue, 1 Apr 2003 20:45: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; Tue, 1 Apr 2003 20:45:20 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; Tue, 1 Apr 2003 20:45:20 Z Received: from heavygear (qing4.isi.com [192.103.54.235]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id MAA13637; Tue, 1 Apr 2003 12:44:58 -0800 (PST) From: "Qing Li" To: "Margaret Wasserman" , Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Tue, 1 Apr 2003 12:45:12 -0800 Message-Id: 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 IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "NO -- Do not deprecate site-local unicast addressing". - Site-locals should be retained for their access control benefits. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. -- Qing Li Qing.Li@windriver.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 Apr 1 12: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 h31KpvPL002159; Tue, 1 Apr 2003 12:51:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31Kpucl002158; Tue, 1 Apr 2003 12:51: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.9+Sun/8.12.9) with ESMTP id h31KprPL002145 for ; Tue, 1 Apr 2003 12:51: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 h31Kq0cU020668 for ; Tue, 1 Apr 2003 12:52:00 -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 NAA17712 for ; Tue, 1 Apr 2003 13:51: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; Tue, 1 Apr 2003 20:50: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, 1 Apr 2003 20:50:48 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 20:50:48 Z Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 20:50:48 Z Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id C9CBC1C01391 for ; Tue, 1 Apr 2003 15:50:47 -0500 (EST) Received: from xcorbh2.cv.hp.com (xcorbh2.cv.hp.com [15.7.113.190]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 8E28D1C00097 for ; Tue, 1 Apr 2003 15:50:47 -0500 (EST) Received: by xcorbh2.cv.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 1 Apr 2003 12:50:47 -0800 Message-Id: <2F3371969CCF964795426F109CF8CFBE16D4E9@xcor05.cv.hp.com> From: "FROELICH,STEVE (HP-Corvallis,ex1)" To: "'ipng@sunroof.eng.sun.com'" Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Tue, 1 Apr 2003 12:50:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing - Site-locals should be retained for disconnected sites. Easy to get No public registration, payment, customer/provider relationship, or approval required. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. Stable Both during ISP changes, and for intermittently connected networks. - Site-locals should be retained for their access control benefits. Private Well-known routing filter provides multiple levels of filtering to ensure a single error does not expose the network to global access. i am in complete agreement with Tony. Do not deprecate SL. steve froelich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 12:59: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 h31KxiPL002580; Tue, 1 Apr 2003 12:59:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31KxiO8002579; Tue, 1 Apr 2003 12:59: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 h31KxfPL002572 for ; Tue, 1 Apr 2003 12:59: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 h31KxmHP015788 for ; Tue, 1 Apr 2003 12:59: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-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07659 for ; Tue, 1 Apr 2003 12:59: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; Tue, 1 Apr 2003 20:59: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; Tue, 1 Apr 2003 20:59: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; Tue, 1 Apr 2003 20:59:11 Z Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 20:59:11 Z Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id CADC41C019BA for ; Tue, 1 Apr 2003 15:59:10 -0500 (EST) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id C54641C000A5 for ; Tue, 1 Apr 2003 15:59:10 -0500 (EST) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Tue, 1 Apr 2003 15:59:10 -0500 Message-Id: <6F2B25E1D54DA6428013E7FB7CD84EBFEADA7B@xvan01.vcd.hp.com> From: "BURDEN,KEN (HP-Vancouver,ex1)" To: "'ipng@sunroof.eng.sun.com'" Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Tue, 1 Apr 2003 15:59:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing Ken Burden -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 13:09: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 h31L9jPL003025; Tue, 1 Apr 2003 13:09:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31L9iZi003024; Tue, 1 Apr 2003 13:09: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 h31L9fPL003017 for ; Tue, 1 Apr 2003 13:09:41 -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 h31L9nHP019304 for ; Tue, 1 Apr 2003 13:09:49 -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 OAA07971 for ; Tue, 1 Apr 2003 14:09:43 -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 21:09:27 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 21:06: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; Tue, 1 Apr 2003 21:09:26 Z Received: from nolink.net (nolink.net [195.139.204.207]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 21:09:26 Z Received: (qmail 69599 invoked from network); 1 Apr 2003 21:09:24 -0000 Received: from unknown (HELO ?193.71.27.162?) (193.71.27.162) by electra.nolink.net with SMTP; 1 Apr 2003 21:09:24 -0000 Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing From: Lars Erik Gullerud To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Content-Type: text/plain Organization: Message-Id: <1049231363.4042.2.camel@spectre.nolink.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 01 Apr 2003 23:09:24 +0200 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 13:12: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 h31LC7PL003075; Tue, 1 Apr 2003 13:12:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31LC71t003074; Tue, 1 Apr 2003 13:12: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 h31LC2PL003061 for ; Tue, 1 Apr 2003 13:12: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 h31LCAHP019968 for ; Tue, 1 Apr 2003 13:12:10 -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 NAA16469 for ; Tue, 1 Apr 2003 13:12:04 -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 21:12:03 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, 1 Apr 2003 21:12: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; Tue, 1 Apr 2003 21:12:01 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, 1 Apr 2003 21:12:00 Z Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 66E8C4C5F for ; Wed, 2 Apr 2003 06:11:53 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: smb's message of Tue, 01 Apr 2003 15:13:46 EST. <20030401201346.AB2287B4D@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: CONSENSUS CALL: Deprecating Site-Local Addressing From: itojun@iijlab.net Date: Wed, 02 Apr 2003 06:11:53 +0900 Message-Id: <20030401211153.66E8C4C5F@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I was in the wg meeting room but was unable to raise hand (too tired, fell asleep). >>> "YES -- Deprecate site-local unicast addressing". Site local address complicates overall access control. Applications has to be altered to support site local addresses (= increased cost of IPv6 transition). 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 Apr 1 13:17: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 h31LHJPL003452; Tue, 1 Apr 2003 13:17:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31LHJtE003451; Tue, 1 Apr 2003 13: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h31LHGPL003442 for ; Tue, 1 Apr 2003 13:17:16 -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 h31LHNcU000062 for ; Tue, 1 Apr 2003 13:17: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 OAA14143 for ; Tue, 1 Apr 2003 14:17: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; Tue, 1 Apr 2003 21:17:17 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 21:17: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; Tue, 1 Apr 2003 21:17:16 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, 1 Apr 2003 21:17:16 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 WAA12837 for ; Tue, 1 Apr 2003 22:17:15 +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 WAA28616 for ; Tue, 1 Apr 2003 22:17:15 +0100 (BST) Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h31LHFc17363 for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 22:17:15 +0100 Date: Tue, 1 Apr 2003 22:17:15 +0100 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Message-Id: <20030401211715.GF21679@ecs.soton.ac.uk> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing. - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. - Other #1 In the absence of a defined private prefix people will either invent their own or use 2002::/16 with RFC1918 addresses which will cause worse problems than SLs. - Other #2 SLs should be retained since they provide a large and free address space for anybody to use, test, research and develop with. -- Mike Saywell Southampton University, 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 Tue Apr 1 13:36: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 h31LafPL004165; Tue, 1 Apr 2003 13:36:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31Lafe6004164; Tue, 1 Apr 2003 13:36: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.9+Sun/8.12.9) with ESMTP id h31LabPL004157 for ; Tue, 1 Apr 2003 13:36:37 -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 h31LajcU006632 for ; Tue, 1 Apr 2003 13:36:45 -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 OAA29300 for ; Tue, 1 Apr 2003 14:36:39 -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 21:36: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; Tue, 1 Apr 2003 21:33:23 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 21:36:22 Z Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 21:36:21 Z Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id h31LaFa00308; Tue, 1 Apr 2003 16:36:15 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id h31LaFg17588; Tue, 1 Apr 2003 16:36:15 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id QAA00761; Tue, 1 Apr 2003 16:36:14 -0500 (EST) Subject: What is a site local address? [Re: CONSENSUS CALL: Deprecating Site-Local Addressing] From: Steven Blake Reply-To: steven.blake@ericsson.com To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 01 Apr 2003 16:36:14 -0500 Message-Id: <1049232974.20706.1409.camel@newcastle.torrentnet.com> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2003-04-01 at 14:37, Margaret Wasserman wrote: > The question is: > > Should we deprecate IPv6 site-local unicast addressing? > > Valid responses are: > > "YES -- Deprecate site-local unicast addressing". > "NO -- Do not deprecate site-local unicast addressing". I think the question needs to be more specific: - Deprecate addresses in fec0::/48? - Deprecate addresses in fec0::/10 (with no scheme to make bits 10:47 probabilistically or globally unique at a site)? - Deprecate all non-PA, non-link-local unicast addresses? Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 13:38:10 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 h31Lc9PL004197; Tue, 1 Apr 2003 13:38:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31Lc9Vv004196; Tue, 1 Apr 2003 13:38: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 h31Lc4PL004177 for ; Tue, 1 Apr 2003 13:38: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 h31LcBcU007196 for ; Tue, 1 Apr 2003 13:38:11 -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 OAA27494 for ; Tue, 1 Apr 2003 14:38:06 -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, 1 Apr 2003 21:38:05 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 21:38:05 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 21:38:05 Z Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 21:38:04 Z Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h31Lc24c024358; Tue, 1 Apr 2003 13:38:02 -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 ACV16463; Tue, 1 Apr 2003 13:38:01 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA16628; Tue, 1 Apr 2003 13:38:01 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16010.1720.893239.966376@thomasm-u1.cisco.com> Date: Tue, 1 Apr 2003 13:38:00 -0800 (PST) To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, nuke site locals. Mike Margaret Wasserman writes: > > Hi All, > > At the IPv6 WG meetings in SF, we reached consensus on several > points, all of which will be confirmed on the IPv6 mailing list. > One point in particular seems to be the source of discussion > on our list and elsewhere, so we will check this consensus on the > mailing list now. Specifically, we would like to check the consensus > of the IPv6 WG regarding the deprecation of site-local addresses. > > This email asks those that were NOT present at the Thursday IPv6 > meeting in SF to express their opinions on a question that was > asked of the room. If you expressed an opinion on this issue in > SF you can skip this message; in any case you MUST NOT respond to > this query. > > By now, all of you have heard about the IPv6 meeting held on > Thursday, March 20th, where we discussed what to do about > IPv6 site-local addressing. > > At the meeting, the chairs (Bob Hinden and Margaret Wasserman) > changed the agenda to include a joint presentation by the > chairs on various options for site-local usage. There were > no objections to the agenda change. > > The chairs' joint presentation can be found at: > > http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt > > After the chairs' joint presentation, there was over an hour of > lively discussion that covered many aspects of site-local > addressing. Draft minutes of the discussion can be found at: > > http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt > > These minutes are a summary of the discussion, and they did > not capture every detail of the discussion. > > During the discussion, it became clear that the "exclusive" model > proposed by the chairs had some fundamental flaws and was not > a viable option. The WG was unwilling to choose between the three > options presented for site-local usage ("limited", "exclusive" or > "moderate"), believing that all three models represented a poor > cost vs. benefit trade-off. And, as the discussion developed, it > became clear that there was growing support for deprecating > site-local addressing. > > After the usual discussion regarding the phrasing and meaning > of the question (not all of which was captured in the minutes), > the chairs asked a yes/no question: "Should we deprecate IPv6 > site-local unicast addressing?" There was clear consensus in the > room to deprecate site-local addressing. So, now it is time to > check that consensus on the mailing list. > > In order to get a good read for consensus on this point, PLEASE > adhere to the following rules: > > NOTE: DO NOT reply if you already expressed an opinion during > the IPv6 WG meeting in SF! > > - Make your response very clear (YES or NO). > - Respond by Monday, April 7th, 2003 at 5pm EST. > - Do NOT respond if you were physically present > in SF and participated in the consensus > call at that time (We are trusting you!). > - Respond to this thread with the subject intact. > - Respond only once. > - Clearly identify yourself (in the From: line or > inside your message). > - Include the IPv6 WG mailing list in your response > (ipng@sunroof.eng.sun.com). > - PLEASE do NOT start any discussion in this thread > (Discussions are encouraged in other threads). > > Any responses that do not adhere to these rules may not be counted. > > The question is: > > Should we deprecate IPv6 site-local unicast addressing? > > Valid responses are: > > "YES -- Deprecate site-local unicast addressing". > "NO -- Do not deprecate site-local unicast addressing". > > If you express an opinion not to deprecate site-local addressing, it > would be helpful if you would provide a reason. Providing a reason > is completely optional, but it may help us to determine how to move > forward if the consensus to deprecate site-locals does not hold. > Possible reasons include: > > - Site-locals should be retained for disconnected sites. > - Site-locals should be retained for intermittently > connected sites. > - Site-locals should be retained for their access control > benefits. > - Site-locals should be retained as a means for internal > connections to survive global prefix renumbering. > - Other (please specify). > > Please, make your response _very_ clear (either YES or NO), or it will > not be counted. > > Please Note: DO NOT respond if you already participated in the > consensus call at the meeting in SF. At the meeting, there were > 102 people who raised their hands for YES (deprecate site-locals) > and 20 people who raised their hands for NO (do not deprecate > site-locals). We will add the responses received on the mailing > list to the hands counted at the meeting, and use that information > to determine full WG consensus on this issue. > > If you feel an urgent need to reply to something that someone sends > in response to this message, please do it in a SEPARATE THREAD with > a different subject line. No discussion in this thread! > > Please voice your opinion on this important issue. > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 1 13:42: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 h31LglPL004617; Tue, 1 Apr 2003 13:42:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31Lgk9b004616; Tue, 1 Apr 2003 13:42: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 h31LghPL004606 for ; Tue, 1 Apr 2003 13:42: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 h31LgocU009083 for ; Tue, 1 Apr 2003 13:42: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 OAA00805 for ; Tue, 1 Apr 2003 14:42: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; Tue, 1 Apr 2003 21:42: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, 1 Apr 2003 21:42: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, 1 Apr 2003 21:42:43 Z Received: from infobro.com (infobro.com [63.71.25.39]) by relay11.sun.com for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 21:42:43 Z Received: from red (unverified [207.199.136.153]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id ; Tue, 01 Apr 2003 16:30:55 -0500 Received: by localhost with Microsoft MAPI; Tue, 1 Apr 2003 16:30:55 -0500 Message-Id: <01C2F86C.11793DF0.eric@infobro.com> From: "Eric D. Williams" To: "ipng@sunroof.eng.sun.com" Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Tue, 1 Apr 2003 16:30:53 -0500 Organization: Information Brokers, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing ----- Eric Williams mailto:eric@infobro.com PGP Public Key http://new.infobro.com/KeyServ/EricDWilliams.asc Finger Print: 1055 8AED 9783 2378 73EF 7B19 0544 A590 FF65 B789 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 13:44: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 h31Li6PL004712; Tue, 1 Apr 2003 13:44:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31Li6TO004711; Tue, 1 Apr 2003 13:44: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.9+Sun/8.12.9) with ESMTP id h31Li2PL004698 for ; Tue, 1 Apr 2003 13:44: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 h31Li9HP001582 for ; Tue, 1 Apr 2003 13:44: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 OAA12072 for ; Tue, 1 Apr 2003 14:44: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; Tue, 1 Apr 2003 21:44: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; Tue, 1 Apr 2003 21:40: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, 1 Apr 2003 21:44:00 Z Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 21:44:00 Z Received: from nomad.ctd.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA28019 for ; Tue, 1 Apr 2003 15:43:59 -0600 (CST) Message-Id: <5.1.1.5.2.20030401153716.00a43910@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 01 Apr 2003 15:42:10 -0600 To: ipng@sunroof.eng.sun.com From: Richard Carlson Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@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 "NO -- Do not deprecate site-local unicast addressing". Institutions and individuals should be able to obtain private non-Internet IP addresses in a cheap, easy fashion. No other address space is defined to meet these objectives. Rich [snip snip snip] >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > ------------------------------------ Richard A. Carlson e-mail: RACarlson@anl.gov Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 13:56: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 h31LujPL005477; Tue, 1 Apr 2003 13:56:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31LujZP005476; Tue, 1 Apr 2003 13:56: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.9+Sun/8.12.9) with ESMTP id h31LufPL005469 for ; Tue, 1 Apr 2003 13:56: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 h31LunHP006964 for ; Tue, 1 Apr 2003 13:56: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 OAA04470 for ; Tue, 1 Apr 2003 14:56:43 -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 21:56: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; Tue, 1 Apr 2003 21:53: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, 1 Apr 2003 21:56:42 Z Received: from syd-msg-core-1.cisco.com (syd-msg-core-1.cisco.com [64.104.193.198]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 21:56:41 Z Received: from shmcfarlw2k (localhost [127.0.0.1]) by syd-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h31LuKlR009846; Wed, 2 Apr 2003 07:56:29 +1000 (EST) Reply-To: From: "Shannon McFarland \(shmcfarl\)" To: "'Margaret Wasserman'" , Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Tue, 1 Apr 2003 14:56:17 -0700 Message-Id: <004201c2f899$8eddcae0$8c00a8c0@amer.cisco.com> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "NO -- Do not deprecate site-local unicast addressing". - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained for disconnected sites. Shannon -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Margaret Wasserman Sent: Tuesday, April 01, 2003 12:38 PM To: ipng@sunroof.eng.sun.com Subject: CONSENSUS CALL: Deprecating Site-Local Addressing Hi All, At the IPv6 WG meetings in SF, we reached consensus on several points, all of which will be confirmed on the IPv6 mailing list. One point in particular seems to be the source of discussion on our list and elsewhere, so we will check this consensus on the mailing list now. Specifically, we would like to check the consensus of the IPv6 WG regarding the deprecation of site-local addresses. This email asks those that were NOT present at the Thursday IPv6 meeting in SF to express their opinions on a question that was asked of the room. If you expressed an opinion on this issue in SF you can skip this message; in any case you MUST NOT respond to this query. By now, all of you have heard about the IPv6 meeting held on Thursday, March 20th, where we discussed what to do about IPv6 site-local addressing. At the meeting, the chairs (Bob Hinden and Margaret Wasserman) changed the agenda to include a joint presentation by the chairs on various options for site-local usage. There were no objections to the agenda change. The chairs' joint presentation can be found at: http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt After the chairs' joint presentation, there was over an hour of lively discussion that covered many aspects of site-local addressing. Draft minutes of the discussion can be found at: http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt These minutes are a summary of the discussion, and they did not capture every detail of the discussion. During the discussion, it became clear that the "exclusive" model proposed by the chairs had some fundamental flaws and was not a viable option. The WG was unwilling to choose between the three options presented for site-local usage ("limited", "exclusive" or "moderate"), believing that all three models represented a poor cost vs. benefit trade-off. And, as the discussion developed, it became clear that there was growing support for deprecating site-local addressing. After the usual discussion regarding the phrasing and meaning of the question (not all of which was captured in the minutes), the chairs asked a yes/no question: "Should we deprecate IPv6 site-local unicast addressing?" There was clear consensus in the room to deprecate site-local addressing. So, now it is time to check that consensus on the mailing list. In order to get a good read for consensus on this point, PLEASE adhere to the following rules: NOTE: DO NOT reply if you already expressed an opinion during the IPv6 WG meeting in SF! - Make your response very clear (YES or NO). - Respond by Monday, April 7th, 2003 at 5pm EST. - Do NOT respond if you were physically present in SF and participated in the consensus call at that time (We are trusting you!). - Respond to this thread with the subject intact. - Respond only once. - Clearly identify yourself (in the From: line or inside your message). - Include the IPv6 WG mailing list in your response (ipng@sunroof.eng.sun.com). - PLEASE do NOT start any discussion in this thread (Discussions are encouraged in other threads). Any responses that do not adhere to these rules may not be counted. The question is: Should we deprecate IPv6 site-local unicast addressing? Valid responses are: "YES -- Deprecate site-local unicast addressing". "NO -- Do not deprecate site-local unicast addressing". If you express an opinion not to deprecate site-local addressing, it would be helpful if you would provide a reason. Providing a reason is completely optional, but it may help us to determine how to move forward if the consensus to deprecate site-locals does not hold. Possible reasons include: - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained for their access control benefits. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. - Other (please specify). Please, make your response _very_ clear (either YES or NO), or it will not be counted. Please Note: DO NOT respond if you already participated in the consensus call at the meeting in SF. At the meeting, there were 102 people who raised their hands for YES (deprecate site-locals) and 20 people who raised their hands for NO (do not deprecate site-locals). We will add the responses received on the mailing list to the hands counted at the meeting, and use that information to determine full WG consensus on this issue. If you feel an urgent need to reply to something that someone sends in response to this message, please do it in a SEPARATE THREAD with a different subject line. No discussion in this thread! Please voice your opinion on this important issue. Bob Hinden & Margaret Wasserman IPv6 WG Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Apr 1 13:56:58 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 h31LuwPL005496; Tue, 1 Apr 2003 13:56:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31LuwZg005493; Tue, 1 Apr 2003 13:56: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.9+Sun/8.12.9) with ESMTP id h31LunPL005479 for ; Tue, 1 Apr 2003 13:56: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 h31LuucU014947 for ; Tue, 1 Apr 2003 13:56: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 NAA25681 for ; Tue, 1 Apr 2003 13:56:51 -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 21:56: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; Tue, 1 Apr 2003 21:56:50 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 21:56:50 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, 1 Apr 2003 21:56:50 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 h31LvD519872; Tue, 1 Apr 2003 13:57:13 -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 h31LvEA07669; Tue, 1 Apr 2003 13:57:14 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id OAA22343; Tue, 1 Apr 2003 14:02:52 -0800 (PST) Date: Tue, 1 Apr 2003 14:02:52 -0800 (PST) From: Tim Hartrick Message-Id: <200304012202.OAA22343@feller.mentat.com> To: mrw@windriver.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing. - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained for their access control benefits. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. 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 Apr 1 13:58: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 h31LwdPL005591; Tue, 1 Apr 2003 13:58:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31LwdWo005590; Tue, 1 Apr 2003 13:58: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.9+Sun/8.12.9) with ESMTP id h31LwZPL005577 for ; Tue, 1 Apr 2003 13:58: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 h31LwgHP007864 for ; Tue, 1 Apr 2003 13:58: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 OAA12779 for ; Tue, 1 Apr 2003 14:58: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; Tue, 1 Apr 2003 21:58: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; Tue, 1 Apr 2003 21:58:35 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 21:58:35 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, 1 Apr 2003 21:58:34 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 4E3978BA9; Tue, 1 Apr 2003 23:58:32 +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 8A11889B2; Tue, 1 Apr 2003 23:58:26 +0200 (CEST) From: "Jeroen Massar" To: "'Margaret Wasserman'" , Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Tue, 1 Apr 2003 23:59:34 +0200 Organization: Unfix Message-Id: <004301c2f899$fb8b72a0$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 In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 14:02:12 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 h31M2BPL005970; Tue, 1 Apr 2003 14:02:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31M2BWm005969; Tue, 1 Apr 2003 14:02: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 h31M27PL005953 for ; Tue, 1 Apr 2003 14:02: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 h31M2EcU017146 for ; Tue, 1 Apr 2003 14:02:14 -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 OAA21856 for ; Tue, 1 Apr 2003 14:02: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; Tue, 1 Apr 2003 22:02: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; Tue, 1 Apr 2003 21:58:54 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 22:02:04 Z Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 22:02:04 Z Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Tue, 1 Apr 2003 14:02:05 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 01 Apr 2003 14:02:03 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3789.0); Tue, 1 Apr 2003 14:02:25 -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, 1 Apr 2003 14:01:44 -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); Tue, 1 Apr 2003 14:02:00 -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: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Tue, 1 Apr 2003 14:02:04 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CONSENSUS CALL: Deprecating Site-Local Addressing Thread-Index: AcL4iII2kbr0fuIsTOCs1DVqldepCwAEZr+A From: "Christian Huitema" To: "Margaret Wasserman" , X-OriginalArrivalTime: 01 Apr 2003 22:02:00.0567 (UTC) FILETIME=[5216C070:01C2F89A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h31M27PL005954 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes but. I understand why we want to remove ambiguity in addressing and make the application writer's task simpler, but we need to have a solution for zero-configuration of disconnected sites. > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Tuesday, April 01, 2003 11:38 AM > To: ipng@sunroof.eng.sun.com > > > Hi All, > > At the IPv6 WG meetings in SF, we reached consensus on several > points, all of which will be confirmed on the IPv6 mailing list. > One point in particular seems to be the source of discussion > on our list and elsewhere, so we will check this consensus on the > mailing list now. Specifically, we would like to check the consensus > of the IPv6 WG regarding the deprecation of site-local addresses. > > This email asks those that were NOT present at the Thursday IPv6 > meeting in SF to express their opinions on a question that was > asked of the room. If you expressed an opinion on this issue in > SF you can skip this message; in any case you MUST NOT respond to > this query. > > By now, all of you have heard about the IPv6 meeting held on > Thursday, March 20th, where we discussed what to do about > IPv6 site-local addressing. > > At the meeting, the chairs (Bob Hinden and Margaret Wasserman) > changed the agenda to include a joint presentation by the > chairs on various options for site-local usage. There were > no objections to the agenda change. > > The chairs' joint presentation can be found at: > > http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt > > After the chairs' joint presentation, there was over an hour of > lively discussion that covered many aspects of site-local > addressing. Draft minutes of the discussion can be found at: > > http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt > > These minutes are a summary of the discussion, and they did > not capture every detail of the discussion. > > During the discussion, it became clear that the "exclusive" model > proposed by the chairs had some fundamental flaws and was not > a viable option. The WG was unwilling to choose between the three > options presented for site-local usage ("limited", "exclusive" or > "moderate"), believing that all three models represented a poor > cost vs. benefit trade-off. And, as the discussion developed, it > became clear that there was growing support for deprecating > site-local addressing. > > After the usual discussion regarding the phrasing and meaning > of the question (not all of which was captured in the minutes), > the chairs asked a yes/no question: "Should we deprecate IPv6 > site-local unicast addressing?" There was clear consensus in the > room to deprecate site-local addressing. So, now it is time to > check that consensus on the mailing list. > > In order to get a good read for consensus on this point, PLEASE > adhere to the following rules: > > NOTE: DO NOT reply if you already expressed an opinion during > the IPv6 WG meeting in SF! > > - Make your response very clear (YES or NO). > - Respond by Monday, April 7th, 2003 at 5pm EST. > - Do NOT respond if you were physically present > in SF and participated in the consensus > call at that time (We are trusting you!). > - Respond to this thread with the subject intact. > - Respond only once. > - Clearly identify yourself (in the From: line or > inside your message). > - Include the IPv6 WG mailing list in your response > (ipng@sunroof.eng.sun.com). > - PLEASE do NOT start any discussion in this thread > (Discussions are encouraged in other threads). > > Any responses that do not adhere to these rules may not be counted. > > The question is: > > Should we deprecate IPv6 site-local unicast addressing? > > Valid responses are: > > "YES -- Deprecate site-local unicast addressing". > "NO -- Do not deprecate site-local unicast addressing". > > If you express an opinion not to deprecate site-local addressing, it > would be helpful if you would provide a reason. Providing a reason > is completely optional, but it may help us to determine how to move > forward if the consensus to deprecate site-locals does not hold. > Possible reasons include: > > - Site-locals should be retained for disconnected sites. > - Site-locals should be retained for intermittently > connected sites. > - Site-locals should be retained for their access control > benefits. > - Site-locals should be retained as a means for internal > connections to survive global prefix renumbering. > - Other (please specify). > > Please, make your response _very_ clear (either YES or NO), or it will > not be counted. > > Please Note: DO NOT respond if you already participated in the > consensus call at the meeting in SF. At the meeting, there were > 102 people who raised their hands for YES (deprecate site-locals) > and 20 people who raised their hands for NO (do not deprecate > site-locals). We will add the responses received on the mailing > list to the hands counted at the meeting, and use that information > to determine full WG consensus on this issue. > > If you feel an urgent need to reply to something that someone sends > in response to this message, please do it in a SEPARATE THREAD with > a different subject line. No discussion in this thread! > > Please voice your opinion on this important issue. > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 1 14:21: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 h31MLSPL007035; Tue, 1 Apr 2003 14:21:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31MLSp8007034; Tue, 1 Apr 2003 14:21: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 h31MLPPL007027 for ; Tue, 1 Apr 2003 14:21: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 h31MLWcU024133 for ; Tue, 1 Apr 2003 14:21: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 OAA13277 for ; Tue, 1 Apr 2003 14:21:27 -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, 1 Apr 2003 22:21:09 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 22:20: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; Tue, 1 Apr 2003 22:20:49 Z Received: from gabriel.advsys.com (gabriel.advsys.com [198.49.218.20]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 22:20:48 Z Received: from geek.advsys.com ([129.203.1.22]) by gabriel.advsys.com (8.11.6/8.10.2) with ESMTP id h31MKlM27599; Tue, 1 Apr 2003 17:20:47 -0500 (EST) Received: from geek.advsys.com (localhost.advsys.com [127.0.0.1]) by geek.advsys.com (8.9.3/8.9.3) with ESMTP id RAA49948; Tue, 1 Apr 2003 17:20:47 -0500 (EST) (envelope-from andy@geek.advsys.com) Message-Id: <200304012220.RAA49948@geek.advsys.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-reply-to: Your message of "Tue, 01 Apr 2003 14:37:56 EST." <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Apr 2003 17:20:47 -0500 From: Andrew L Hazeltine Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained for their access control benefits. Andy Hazeltine Advanced Systems Consulting, 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 Apr 1 14:21: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 h31MLZPL007045; Tue, 1 Apr 2003 14:21:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31MLZi1007044; Tue, 1 Apr 2003 14:21: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.9+Sun/8.12.9) with ESMTP id h31MLTPL007037 for ; Tue, 1 Apr 2003 14:21:29 -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 h31MLbHP016821 for ; Tue, 1 Apr 2003 14:21:37 -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 PAA28697 for ; Tue, 1 Apr 2003 15:21:31 -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, 1 Apr 2003 22:21:09 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, 1 Apr 2003 22:20: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; Tue, 1 Apr 2003 22:20:51 Z Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 22:20:51 Z Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h31MKoA23179 for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 14:20:50 -0800 (PST) From: Bill Manning Message-Id: <200304012220.h31MKoA23179@boreas.isi.edu> Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing To: ipng@sunroof.eng.sun.com Date: Tue, 1 Apr 2003 14:20:50 -0800 (PST) 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 long as we are voting... NO -- Do not deprecate site-local unicast addressing. --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 Tue Apr 1 14:22: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 h31MM7PL007076; Tue, 1 Apr 2003 14:22:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31MM7Wj007075; Tue, 1 Apr 2003 14:22: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 h31MM0PL007061 for ; Tue, 1 Apr 2003 14:22:00 -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 h31MM8HP016970 for ; Tue, 1 Apr 2003 14:22:08 -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 PAA06594 for ; Tue, 1 Apr 2003 15:22:02 -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 22:21:31 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 22:21: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; Tue, 1 Apr 2003 22:21:30 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, 1 Apr 2003 22:21:30 Z Content-class: urn:content-classes:message Subject: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Apr 2003 14:21:29 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F711@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: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing Thread-Index: AcL4iQ/mZKOW52xkQTuRBd7MBu5EoAAE3MPA From: "Michel Py" To: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h31MM1PL007062 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret / Bob, What is this consensus about? I was hoping that the mailing list would be asked to express their opinions _after_ a text to deprecate site-local addressing had been submitted to the working group. In the current situation, this consensus if there is one would be good only to accept text as a working document. This document that still has to be seen then should go to WG last call. Where is the doc to deprecate site-local addressing? 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 Apr 1 14:25:46 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 h31MPjPL007369; Tue, 1 Apr 2003 14:25:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31MPjRw007368; Tue, 1 Apr 2003 14: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.9+Sun/8.12.9) with ESMTP id h31MPgPL007358 for ; Tue, 1 Apr 2003 14:25: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 h31MPnHP018501 for ; Tue, 1 Apr 2003 14:25:49 -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 OAA16841 for ; Tue, 1 Apr 2003 14:25:44 -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, 1 Apr 2003 22:25: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; Tue, 1 Apr 2003 22:22: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, 1 Apr 2003 22:25:43 Z Received: from mail1.netscreen.com (mail1.netscreen.com [63.126.135.16]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 22:25:42 Z Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail1.netscreen.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h31MLFW06483; Tue, 1 Apr 2003 14:21:15 -0800 (PST) Received: by NS-CA.netscreen.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 14:22:33 -0800 Message-Id: <541402FFDC56DA499E7E13329ABFEA87DBB968@SARATOGA.netscreen.com> From: Rakesh Nair To: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Tue, 1 Apr 2003 14:20:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing Benefits are less compared to the complications it introduces!!! Rakesh Nair www.netscreen.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 Apr 1 14:56:28 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 h31MuSPL008267; Tue, 1 Apr 2003 14:56:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31MuSj4008266; Tue, 1 Apr 2003 14:56: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.9+Sun/8.12.9) with ESMTP id h31MuPPL008259 for ; Tue, 1 Apr 2003 14:56:25 -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 h31MuWHP000036 for ; Tue, 1 Apr 2003 14:56:32 -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 PAA23677 for ; Tue, 1 Apr 2003 15:56: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, 1 Apr 2003 22:56: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; Tue, 1 Apr 2003 22:56: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; Tue, 1 Apr 2003 22:56:22 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 22:56:20 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h31MuHvm049064; Tue, 1 Apr 2003 14:56:17 -0800 (PST) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h31MuGZp049063; Tue, 1 Apr 2003 14:56:16 -0800 (PST) Date: Tue, 1 Apr 2003 14:56:16 -0800 From: Shannon -jj Behrens To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Message-Id: <20030401225616.GB48812@alicia.nttmcl.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing". -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 Tue Apr 1 15:02:18 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 h31N2HPL008500; Tue, 1 Apr 2003 15:02:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31N2Hmf008499; Tue, 1 Apr 2003 15:02: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.9+Sun/8.12.9) with ESMTP id h31N2EPL008492 for ; Tue, 1 Apr 2003 15:02:14 -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 h31N2LcU009916 for ; Tue, 1 Apr 2003 15:02:21 -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 QAA18385 for ; Tue, 1 Apr 2003 16:01:58 -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, 1 Apr 2003 23:01: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; Tue, 1 Apr 2003 23:01: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; Tue, 1 Apr 2003 23:01:55 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 23:01:55 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id SAA24243; Tue, 1 Apr 2003 18:01:51 -0500 (EST) Date: Tue, 1 Apr 2003 18:01:51 -0500 (EST) From: Dan Lanciani Message-Id: <200304012301.SAA24243@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: avoiding NAT with IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've noticed a common theme in many of these anti-NAT dissertations: the stupid NAT user is using NAT for stupid reasons and if we merely educate him and/or force her to stop using NAT the world (and the particular user) will be oh so much better off. You will not eliminate NAT by repeatedly telling its users that they are misguided idiots. A new generation of NAT-hostile peer-to-peer applications is neither necessary nor sufficient to eliminate NAT. Many users couldn't care less about these wonder-apps and for those who have a legitimate need, the market will provide a NAT-friendly alternative. MUST NOTs in RFCs are not going to stop NAT. Eliminating NAT is actually very simple. All you have to do is give users that which by its lack drove them to use NAT in the first place: plentiful, free, stable address space. I conclude from the effort that folks are putting into discussing other (pointless) ways to mandate NAT away that they in fact agree with my prediction that v6 ISPs will not magically change their business models and offer such address space freely. As long as address space and stability remain profit centers, you will not be able to eliminate NAT. |These enterprises apparently don't want/require/need global |reachability for their hosts. Otherwise they would not NAT. Is that really apparent? They might be using NAT exactly because they want global reachability for their hosts but cannot afford to rent enough global IP addresses. Or perhaps their ISP won't offer them additional global IP addresses at any price. Or perhaps they cannot cope with constant changes in the ISP's dynamic addressing disrupting their internal connections. Or perhaps they simply want to be able to change ISPs without the extreme pain of renumbering. Or perhaps they implement a poor-man's multi-homing solution to provide higher availability (though not connection survival). |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 wouldn't count on this for much help. The multi group was in effect tasked with solving the multi-homing problem without solving the portable identifier problem in general. Even if they "fail" and are forced to solve the portable identifier problem (assuming they solve anything) their solution can easily be restricted to sites paying for connections to multiple ISPs. In any case, don't you think it's a little late in the game to keep putting off solving the problem in hopes that a solution will appear as a side-effect of some other effort? Especially when that effort is stalled? |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 in other words, IP renumbering *is* that much of a problem... Dan Lanciani ddl@danlan.*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 Apr 1 15:05: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 h31N5IPL008624; Tue, 1 Apr 2003 15:05:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31N5IQd008623; Tue, 1 Apr 2003 15: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h31N5EPL008610 for ; Tue, 1 Apr 2003 15:05: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 h31N5McU011094 for ; Tue, 1 Apr 2003 15:05: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 PAA06731 for ; Tue, 1 Apr 2003 15:05:16 -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 23:05:12 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 23:02: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; Tue, 1 Apr 2003 23:05:12 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 23:05:11 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id SAA24358; Tue, 1 Apr 2003 18:05:08 -0500 (EST) Date: Tue, 1 Apr 2003 18:05:08 -0500 (EST) From: Dan Lanciani Message-Id: <200304012305.SAA24358@ss10.danlan.com> To: ipng@sunroof.eng.sun.com, mrw@windriver.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "NO -- Do not deprecate site-local unicast addressing". Dan Lanciani ddl@danlan.*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 Apr 1 15:16:35 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 h31NGZPL009111; Tue, 1 Apr 2003 15:16:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31NGYQ6009110; Tue, 1 Apr 2003 15:16: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.9+Sun/8.12.9) with ESMTP id h31NGVPL009103 for ; Tue, 1 Apr 2003 15:16:31 -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 h31NGdHP007357 for ; Tue, 1 Apr 2003 15:16:39 -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 QAA19535 for ; Tue, 1 Apr 2003 16:16: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; Tue, 1 Apr 2003 23:16: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, 1 Apr 2003 23:13: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, 1 Apr 2003 23:16:32 Z Received: from albert.tavian.com (albert.tavian.com [66.149.217.205]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 23:16:32 Z Received: from localhost (doc@localhost) by albert.tavian.com (8.8.7/8.8.7) with ESMTP id PAA02135 for ; Tue, 1 Apr 2003 15:16:28 -0800 Date: Tue, 1 Apr 2003 15:16:28 -0800 (PST) From: Brian McGehee To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing - Site-locals should be retained for disconnected sites. If not SL, then a mechanism needs to be adopted that can provide a private means of selecting from a private address space that is "reserved" for this function. 2002 is not a working alternative. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. - Other (please specify). Continually changing the specs will only further alienate those that refuse to adopt. Not offering equivalents to what exists today (rfc 1918) will accomplish the same. (and do we really want to put all the NAT vendors out of business? ;-) "Necessity drives ingenuity." Brian McGehee Native6, Inc. www.native6group.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 Apr 1 15:17: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 h31NHPPL009141; Tue, 1 Apr 2003 15:17:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31NHPs6009139; Tue, 1 Apr 2003 15:17: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.9+Sun/8.12.9) with ESMTP id h31NHMPL009132 for ; Tue, 1 Apr 2003 15:17: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 h31NHTcU015262 for ; Tue, 1 Apr 2003 15:17: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 PAA14492 for ; Tue, 1 Apr 2003 15:17:23 -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, 1 Apr 2003 23:17:23 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 23:17: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; Tue, 1 Apr 2003 23:17:23 Z Received: from lithium.nac.net (lithium.nac.net [64.21.52.83]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 23:17:23 Z Received: (qmail 5741 invoked from network); 1 Apr 2003 23:15:45 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.173) by mail.nac.net with SMTP; 1 Apr 2003 23:15:45 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h31LRFf23366; Tue, 1 Apr 2003 16:27:15 -0500 Date: Tue, 1 Apr 2003 16:27:15 -0500 (EST) From: George Gross To: Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: <20030401225616.GB48812@alicia.nttmcl.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 15:50: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 h31NohPL009821; Tue, 1 Apr 2003 15:50:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31NohgN009820; Tue, 1 Apr 2003 15:50: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 h31NodPL009813 for ; Tue, 1 Apr 2003 15:50:39 -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 h31NokcU026981 for ; Tue, 1 Apr 2003 15:50: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 QAA14202 for ; Tue, 1 Apr 2003 16:50:41 -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 23:50: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, 1 Apr 2003 23:50:27 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 23:50:26 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; Tue, 1 Apr 2003 23:50:25 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: Tue, 1 Apr 2003 15:50:25 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F712@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: AcL4pPrTW8zZF2lPSAKxV7uIC8gb2gAAxTEQ From: "Michel Py" To: "Dan Lanciani" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h31NodPL009814 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Dan Lanciani wrote: > Or perhaps they implement a poor-man's multi-homing > solution to provide higher availability (though not > connection survival). This indeed is a very common situation; T1 with DSL backup or SDSL with cable backup, NAT+RFC1918, just change the default route in the router and change the DNS (with 15 min TTL) to point to the new IP. Being crippled one hour instead of dead for days (I just had a TransEdge customer that was down for 6+ days) is a good proposition for lots of businesses and the $80/mo for backup DSL are a no brainer. 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 Apr 1 16:03:14 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 h3203EPL010024; Tue, 1 Apr 2003 16:03:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3203EgM010023; Tue, 1 Apr 2003 16:03: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.9+Sun/8.12.9) with ESMTP id h3203APL010014 for ; Tue, 1 Apr 2003 16:03:11 -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 h3203IHP023854 for ; Tue, 1 Apr 2003 16:03:18 -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.3p2+Sun/8.9.3) with ESMTP id RAA22547 for ; Tue, 1 Apr 2003 17:03: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; Wed, 2 Apr 2003 00:03: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; Wed, 2 Apr 2003 00:03: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; Wed, 2 Apr 2003 00:03:11 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 00:03:11 Z Received: from cisco.com (dhcp-171-71-194-128.cisco.com [171.71.194.128]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA23892; Tue, 1 Apr 2003 16:03:08 -0800 (PST) Message-Id: <3E8A28BB.8030004@cisco.com> Date: Tue, 01 Apr 2003 16:03:07 -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: Dan Lanciani CC: ipng@sunroof.eng.sun.com Subject: Re: avoiding NAT with IPv6 References: <200304012301.SAA24243@ss10.danlan.com> In-Reply-To: <200304012301.SAA24243@ss10.danlan.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: > A new generation of NAT-hostile peer-to-peer applications is neither necessary > nor sufficient to eliminate NAT. Many users couldn't care less about these > wonder-apps and for those who have a legitimate need, the market will provide > a NAT-friendly alternative. The old generation is hard enough to support. I think you missed the point of many of these folks; it's not that users are stupid, it's that tools are lacking. 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 Tue Apr 1 16:03: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 h3203OPL010037; Tue, 1 Apr 2003 16:03:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3203NlB010036; Tue, 1 Apr 2003 16:03: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 h3203HPL010026 for ; Tue, 1 Apr 2003 16:03: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 h3203OcU001442 for ; Tue, 1 Apr 2003 16:03:25 -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 RAA15089 for ; Tue, 1 Apr 2003 17:03: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; Wed, 2 Apr 2003 00:03: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, 2 Apr 2003 00:02: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, 2 Apr 2003 00:02:55 Z Received: from ns.live.com (ns.live.com [66.80.62.34]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 00:02:54 Z Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.5) with ESMTP id h3202q5j043630 for ; Tue, 1 Apr 2003 16:02:53 -0800 (PST) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.3/Submit) id h3202qnk043629; Tue, 1 Apr 2003 16:02:52 -0800 (PST) Message-Id: <4.3.1.1.20030401160007.00b88d60@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 01 Apr 2003 16:01:21 -0800 To: ipng@sunroof.eng.sun.com From: Ross Finlayson Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@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 YES -- Deprecate site-local unicast addressing". (Any benefits are vastly outweighed by the added complications, IMHO.) Ross. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 16:46:02 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 h320k1PL010699; Tue, 1 Apr 2003 16:46:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h320k1XO010698; Tue, 1 Apr 2003 16:46: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.9+Sun/8.12.9) with ESMTP id h320jwPL010691 for ; Tue, 1 Apr 2003 16:45: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 h320k5HP008416 for ; Tue, 1 Apr 2003 16:46:05 -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 QAA23896 for ; Tue, 1 Apr 2003 16:45:59 -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, 2 Apr 2003 00:45: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, 2 Apr 2003 00:42: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; Wed, 2 Apr 2003 00:45:58 Z Received: from nutcracker.stacken.kth.se ([130.237.237.2] [130.237.237.2]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 00:45:58 Z Received: (from lha@localhost) by nutcracker.stacken.kth.se (8.11.6/8.11.6) id h320jB122630; Wed, 2 Apr 2003 02:45:11 +0200 (CEST) X-Authentication-Warning: nutcracker.stacken.kth.se: lha set sender to lha@stacken.kth.se using -f To: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing From: Love =?iso-8859-1?q?H=F6rnquist_=C5strand?= Date: Wed, 02 Apr 2003 02:45:10 +0200 In-Reply-To: <20030401201346.AB2287B4D@berkshire.research.att.com> ("Steven M. Bellovin"'s message of "Tue, 01 Apr 2003 15:13:46 -0500") Message-Id: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386--netbsdelf) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing". Love -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 17:05:28 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 h3215SPL010963; Tue, 1 Apr 2003 17:05:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3215SBm010962; Tue, 1 Apr 2003 17:05: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.9+Sun/8.12.9) with ESMTP id h3215PPL010955 for ; Tue, 1 Apr 2003 17:05:25 -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 h3215WHP015105 for ; Tue, 1 Apr 2003 17:05:32 -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 RAA24290 for ; Tue, 1 Apr 2003 17:05: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; Wed, 2 Apr 2003 01:05: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; Wed, 2 Apr 2003 01:05: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, 2 Apr 2003 01:05:26 Z Received: from southstation.m5p.com (southstation.m5p.com [209.162.215.52]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 01:05:26 Z Received: from m5p.com (parkstreet.m5p.com [10.100.0.1]) by southstation.m5p.com (8.12.9/8.12.9) with ESMTP id h3215OMh066985 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Apr 2003 17:05:24 -0800 (PST) Received: (from george@localhost) by m5p.com (8.12.9/8.12.9/Submit) id h3215OAd084024; Tue, 1 Apr 2003 17:05:24 -0800 (PST) Date: Tue, 1 Apr 2003 17:05:24 -0800 (PST) Message-Id: <200304020105.h3215OAd084024@m5p.com> From: george+ipng@m5p.com To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing. Site-locals are useful for disconnected sites, and for nodes on connected sites which should never have global connectivity. The cost: Addresses may be ambiguous in certain cases. Applications will have to choose between addresses when a interface has multiple addresses. It's unrealistic, however, to think that deprecating site-locals will forestall these problems. They will recur in other guises. So let's attack them now. -- George Mitchell -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 17:22:58 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 h321MwPL011318; Tue, 1 Apr 2003 17:22:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h321MvGL011317; Tue, 1 Apr 2003 17: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.9+Sun/8.12.9) with ESMTP id h321MsPL011307 for ; Tue, 1 Apr 2003 17:22: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 h321N1HP020445 for ; Tue, 1 Apr 2003 17:23: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-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16350 for ; Tue, 1 Apr 2003 17:22:56 -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, 2 Apr 2003 01:22:55 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, 2 Apr 2003 01:22: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, 2 Apr 2003 01:22:55 Z Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 01:22:54 Z Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id h321Mow01101 for ; Wed, 2 Apr 2003 10:22:50 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) id h321Mot01672 for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 10:22:50 +0900 (JST) Received: from shikibu.jp.nec.com (shikibu.jp.nec.com [10.26.220.2]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id h321Mn519801 for ; Wed, 2 Apr 2003 10:22:49 +0900 (JST) Received: from [10.41.211.53] by mail.jp.nec.com with ESMTP; Wed, 2 Apr 2003 10:22:49 +0900 Date: Wed, 02 Apr 2003 10:22:46 +0900 From: Hiroki Ishibashi Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 2.60 (WinNT,500) Organization: NEC Corporation In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Message-Id: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing. - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained for their access control benefits. Hiroki Ishibashi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 17:42:22 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 h321gMPL011829; Tue, 1 Apr 2003 17:42:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h321gLTF011828; Tue, 1 Apr 2003 17: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h321gIPL011821 for ; Tue, 1 Apr 2003 17:42:18 -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 h321gQHP026315 for ; Tue, 1 Apr 2003 17:42:26 -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 RAA26997 for ; Tue, 1 Apr 2003 17:42:20 -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, 2 Apr 2003 01:42: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; Wed, 2 Apr 2003 01:42: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, 2 Apr 2003 01:42:19 Z Received: from mail.syce.net (mail.syce.net [192.16.178.14]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 01:42:19 Z Received: from localhost (erika.syce.net [192.16.178.89]) by mail.syce.net (8.12.6p2/8.12.6) with ESMTP/inet id h321gHJr011010 for ; Wed, 2 Apr 2003 10:42:17 +0900 (JST) (envelope-from fujisaki@syce.net) Date: Wed, 02 Apr 2003 10:42:17 +0900 (JST) Message-Id: <20030402.104217.120912639.fujisaki@syce.net> To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing From: (Tomohiro -INSTALLER- =?iso-2022-jp?B?RnVqaXNha2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhC?=) In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> X-Mailer: Mew version 3.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing". --- Tomohiro Fujisaki -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 17:42: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 h321gdPL011839; Tue, 1 Apr 2003 17:42:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h321gdaG011838; Tue, 1 Apr 2003 17: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.9+Sun/8.12.9) with ESMTP id h321gXPL011831 for ; Tue, 1 Apr 2003 17:42:33 -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 h321geHP026380 for ; Tue, 1 Apr 2003 17:42:40 -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 RAA14961 for ; Tue, 1 Apr 2003 17:42: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, 2 Apr 2003 01:42: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, 2 Apr 2003 01:39:23 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, 2 Apr 2003 01:42:34 Z Received: from kokone.v6.linux.or.jp (kokone.v6.linux.or.jp [210.157.158.26]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 01:42:33 Z Received: from v6.linux.or.jp (localhost.localdomain [127.0.0.1]) by kokone.v6.linux.or.jp (8.12.8/8.12.5) with ESMTP id h321gQxW009997; Wed, 2 Apr 2003 10:42:26 +0900 Message-Id: <200304020142.h321gQxW009997@kokone.v6.linux.or.jp> From: Takeshi Kusune To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-reply-to: Your message of "Tue, 01 Apr 2003 14:37:56 JST." <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> User-Agent: EMH/1.10.0 SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Date: Wed, 02 Apr 2003 10:42:26 +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "NO -- Do not deprecate site-local unicast addressing". Reasons: - Site-locals should be retained for disconnected sites. - Site-locals should be retained for their access control benefits. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. (other) - Site-locals should be retained to stop domain hi-jack for the reason above. - Site-locals should be retained for Comments: I want only private address space like RFC1918 in IPv4. Any other complicated feature is not needed. -- Takeshi Kusune -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 18:12: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 h322ClPL012398; Tue, 1 Apr 2003 18:12:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h322ClPq012397; Tue, 1 Apr 2003 18:12: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.9+Sun/8.12.9) with ESMTP id h322CiPL012390 for ; Tue, 1 Apr 2003 18:12: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 h322CpHP005231 for ; Tue, 1 Apr 2003 18:12: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.3p2+Sun/8.9.3) with ESMTP id TAA16886 for ; Tue, 1 Apr 2003 19:12:46 -0700 (MST) From: William_G_Allmond@notes.tcs.treas.gov 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, 2 Apr 2003 02:12: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; Wed, 2 Apr 2003 02:12: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, 2 Apr 2003 02:12:45 Z Received: from mx-relay21.treas.gov (mx-relay21.treas.gov [199.196.132.5]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 02:12:45 Z Received: from TIAS24.net.treas.gov (tias24.treas.gov [199.196.132.24]) by mx-relay21.treas.gov (8.12.9/8.12.9) with SMTP id h321xajJ020095; Tue, 1 Apr 2003 20:59:36 -0500 (EST) Received: from no.name.available by TIAS24.net.treas.gov via smtpd (for [199.196.132.5]) with SMTP; 2 Apr 2003 02:12:42 UT Received: from notes.tcs.treas.gov (localhost [127.0.0.1]) by mailhub-23.net.treas.gov (8.12.8/8.12.8) with ESMTP id h322Capk005884; Tue, 1 Apr 2003 21:12:36 -0500 (EST) Sensitivity: Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999 Message-Id: Date: Tue, 1 Apr 2003 21:12:34 -0500 X-MIMETrack: Serialize by Router on TCSHUB_LN/TCS/TREAS/GOV(Release 5.0.9 |November 16, 2001) at 04/01/2003 09:12:36 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO - Do NOT Deprecate Site-Local Addressing. There are reason to use site-locals, and reason NOT to use them. But "FORBIDDING" people will only alienate them and lead them to find ways to do it anyway. Perfect example, when (or should I say IF) my home ISP goes to IPv6, they charge per IP. Always have, and always will. Sure, they will gladly give me a range of IPs, as well as gladly charge me as if each were a PC. Also, when I get tired of putting up with the abuse from this particular ISP and decide to choose another ISP to abuse me, I will still have the same issue. Does having Site-locals cause problems? Sure. Can these problems be mitigated? Yes. Does deprecating site-locals solve the problem? Yes and no. In the short term it may. But those that are determined to have themwill find a way around. It is better to face an enemy that we know and can control than to unleash a beast that we may not be able to contain. We must NOT forget that the end user is the one that will have no input into this, but will be bound by the decision. I shall get off my soap-box. Gary -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 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 h322jcPL012873; Tue, 1 Apr 2003 18:45:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h322jcCq012872; Tue, 1 Apr 2003 18:45: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 h322jZPL012865 for ; Tue, 1 Apr 2003 18:45: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 h322jgHP014163 for ; Tue, 1 Apr 2003 18:45: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 SAA20881 for ; Tue, 1 Apr 2003 18:45:36 -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, 2 Apr 2003 02:45: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, 2 Apr 2003 02:42: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, 2 Apr 2003 02:45:35 Z Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 02:45:34 Z Received: from s30.crl.hitachi.co.jp (orange.kame.net [3ffe:501:4819:2000:203:47ff:fea5:3085]) by orange.kame.net (Postfix) with ESMTP id A90867020; Wed, 2 Apr 2003 11:45:31 +0900 (JST) Date: Wed, 02 Apr 2003 11:44:46 +0900 Message-Id: From: SUZUKI Shinsuke To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing X-cite: xcite 1.33 In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> User-Agent: User-Agent: Wanderlust/2.11.3 (Wonderwall) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Network Architecture Research Dept., Central Research Laboratory, Hitachi, Ltd, Japan MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing" -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 18:56: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 h322uiPL013187; Tue, 1 Apr 2003 18:56:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h322uhZO013186; Tue, 1 Apr 2003 18:56: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 h322uePL013174 for ; Tue, 1 Apr 2003 18:56:40 -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 h322ulHP016703 for ; Tue, 1 Apr 2003 18:56:47 -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 TAA05976 for ; Tue, 1 Apr 2003 19:56:42 -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, 2 Apr 2003 02:56:27 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, 2 Apr 2003 02:56:27 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, 2 Apr 2003 02:56:26 Z Received: from r-bu.iij4u.or.jp (r-bu.iij4u.or.jp [210.130.0.89]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 02:56:26 Z Received: from localhost (flets-atarashi.yagami.wide.ad.jp [203.178.138.179] (may be forged)) by r-bu.iij4u.or.jp (8.11.6+IIJ/8.11.6) with ESMTP id h322uNb29038; Wed, 2 Apr 2003 11:56:23 +0900 (JST) Date: Wed, 02 Apr 2003 11:56:13 +0900 (JST) Message-Id: <20030402.115613.107714610.atarashi@ebina.hitachi.co.jp> To: ipng@sunroof.eng.sun.com Cc: atarashi@ebina.hitachi.co.jp Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing From: Yoshifumi Atarashi In-Reply-To: <20030401211153.66E8C4C5F@coconut.itojun.org> References: <20030401201346.AB2287B4D@berkshire.research.att.com> <20030401211153.66E8C4C5F@coconut.itojun.org> X-Mailer: Mew version 3.0.54 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: itojun@iijlab.net Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Wed, 02 Apr 2003 06:11:53 +0900 "YES -- Deprecate site-local unicast addressing". > Site local address complicates overall access control. > Applications has to be altered to support site local addresses > (= increased cost of IPv6 transition). Site local address increse cost of network products. Because venders must do a lot of test for site local addreses. (If site local address spec does not change implementation, earnest venders will do additional tests.) Therefore venders will delay to shipment of IPv6 products. It is very bad for IPv6 deployment and transition. ------ Yoshifumi Atarashi Hitachi, Ltd. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 19:22: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 h323MCPL013541; Tue, 1 Apr 2003 19:22:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h323MCDL013540; Tue, 1 Apr 2003 19: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h323M9PL013533 for ; Tue, 1 Apr 2003 19:22: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 h323MGcU009865 for ; Tue, 1 Apr 2003 19:22:17 -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 UAA06971 for ; Tue, 1 Apr 2003 20:22: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; Wed, 2 Apr 2003 03:22: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; Wed, 2 Apr 2003 03:22: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; Wed, 2 Apr 2003 03:22:08 Z Received: from smtp1.att.ne.jp (smtp1.att.ne.jp [165.76.15.137]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 03:22:08 Z Received: from localhost (82.180.32.202.ts.2iij.net [202.32.180.82]) by smtp1.att.ne.jp (Postfix) with ESMTP id 2985015979 for ; Wed, 2 Apr 2003 12:22:06 +0900 (JST) Date: Wed, 02 Apr 2003 12:22:05 +0900 (JST) Message-Id: <20030402.122205.71085633.nov@tahi.org> To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing From: Nobuo OKABE In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> X-Mailer: Mew version 3.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing". ---- nobuo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 20:10: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 h324AVPL013939; Tue, 1 Apr 2003 20:10:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h324AVTW013938; Tue, 1 Apr 2003 20:10: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.9+Sun/8.12.9) with ESMTP id h324ASPL013931 for ; Tue, 1 Apr 2003 20:10:28 -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 h324AZHP002540 for ; Tue, 1 Apr 2003 20:10:35 -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.3p2+Sun/8.9.3) with ESMTP id VAA16676 for ; Tue, 1 Apr 2003 21:10: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; Wed, 2 Apr 2003 04:10: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, 2 Apr 2003 04:09: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, 2 Apr 2003 04:09:55 Z Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 04:09:55 Z Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 1 Apr 2003 20:10:15 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 01 Apr 2003 20:09:40 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.196]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 1 Apr 2003 20:09:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6895.0 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: Tue, 1 Apr 2003 20:09:47 -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: AcL0j4xQqULPeJZtQiiH+Rg9WGQpHwABnIgwAQ2mwzA= From: "Brian Zill" To: "Michel Py" Cc: "Brian Carpenter" , X-OriginalArrivalTime: 02 Apr 2003 04:09:48.0752 (UTC) FILETIME=[B3C08D00:01C2F8CD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h324ASPL013932 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the case you list below, host1 and host2 will both have two addresses. One set of those addresses share a subnet and by virtue of longest prefix match will be the pair picked by the source/destination address selection rules. So host1 and host2 will happily communicate without needing to traverse a router. In other words: it is quite all right for nodes to have a 6to4 pseudo-interface enabled even if another link to which they are connected has a native prefix including those within 2002::/16. The RFC is fine as is. --Brian > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Thursday, 27 March, 2003 12:14 > To: Ole Troan > Cc: Brian Carpenter; ipng@sunroof.eng.sun.com > Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local > addresses?] > > > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 21:11:12 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 h325BCPL014790; Tue, 1 Apr 2003 21:11:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h325BBQ7014789; Tue, 1 Apr 2003 21:11: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 h325B8PL014782 for ; Tue, 1 Apr 2003 21:11:08 -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 h325BFcU003052 for ; Tue, 1 Apr 2003 21:11:15 -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 WAA05034 for ; Tue, 1 Apr 2003 22:11: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, 2 Apr 2003 05:08:45 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, 2 Apr 2003 05:05: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, 2 Apr 2003 05:08:44 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, 2 Apr 2003 05:08:44 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: Tue, 1 Apr 2003 21:08:43 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F715@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+Rg9WGQpHwABnIgwAQ2mwzAAAEwuQA== From: "Michel Py" To: "Brian Zill" Cc: "Brian Carpenter" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h325B8PL014783 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > Brian Zill wrote: > In the case you list below, host1 and host2 will both have > two addresses. One set of those addresses share a subnet > and by virtue of longest prefix match will be the pair > picked by the source/destination address selection rules. > So host1 and host2 will happily communicate without > needing to traverse a router. I re-read what I have posted and a copy/paste casualty got rid of "the internal" in front of "router" which equates un-necessary encapsulation/decapsulation. There are two points about this: 1. The source host knowing all addresses about the destination host. 2. Where it really breaks. 1. The source host knowing all addresses about the destination host. -------------------------------------------------------------------- There is some truth in what you wrote, but unfortunately you assume that the source host will acquire both addresses of the destination host. Without bad intents, I will remind you that there are five ways a v4 Microsoft host in the majority of deployed cases can locate another host by name, as defined by option #46 in DHCP and complemented by local options: - hosts files - lmhosts files - Broadcast - WINS - DNS Again, keep in mind that I am not one of these guys that scream "Microsoft sucks" each time they have an opportunity nor one that says that Windows is not a "real" operating system (it is strangely real for an "unreal" product to have 90% of the market, pun intended). That being said, when one has five different ways to resolve a name to an IP address, you will allow me to see multiple reasons for SNAFUs. 2. Where it really breaks, with the knowledge of 1. above: ---------------------------------------------------------- > In other words: it is quite all right for nodes to have a > 6to4 pseudo-interface enabled even if another link to which > they are connected has a native prefix including those within > 2002::/16. The RFC is fine as is. You missed the main point although I will concede that I failed to explain it in sufficient detail. Here it is: a) By re-reading the example pasted below you will understand that the entire site uses 2002:xxyy:zz01::/48 as its prefix, and there are multiple reasons for this including a stable DNS. b) Host2 is a server of some kind. Host2 has two IPv6 addresses as you mentioned, one being a statically configured IPv6 address: b1> host2: 2002:xxyy:zz01:0001:2::2/64 This is a perfectly valid modified-EUI-64 address with the "u" bit set. And the other one being the 6to4 address of the pseudo interface: b2> host2: 2002:xxyy:zz67:????:HST2:I:I:D/64 It is clear to me that it is highly desirable that the only IPv6 address present in DNS for outside resolution is the first one, both for the reason that a v4 address change should not trigger a v6 address change (minor) and more because good practice will deny protocol 41 ingress for any address other than x.y.z.1 (major). Here's where it breaks: - A host from the outside wants to communicate to host2. - The host outside picks 2002:xxyy:zz01:0001:2::2 as the destination address. Even if 2002:xxyy:zz67:????:HST2:I:I:D is also published in DNS you can't guarantee that it won't happen as the longest match rule does not apply here, note that there are no subnet masks anymore. - Host2 receives the traffic and wants to reply. - Host2 SAS picks 2002:xxyy:zz01:0001:2::2/64 as the source address for the reply (a no-brainer, since the communication originated to this address) - Host2 has three IPv6 routes (non including link-local) - The default route pointing to the router, acquired by stateless autoconfig. - 2002:xxyy:zz01:0001:2::/64 directly connected. - 2002::/16 on the pseudo-interface. ==> The longest match rule sends the packet to the pseudo-interface where the RFC3056-compliant implementation dumps it in the bit bucket. ==> Even if the implementation is not RFC-3056 compliant good chances are that an access-list somewhere on the edge will dump the traffic because protocol 41 is allowed only from and to x.y.z.1. I know what you're going to reply: just configure a static route for 2002:xxyy:zz01::/48 pointing to the router. Yes, it would solve one of the problems, and yes it also stinks big time. Configuring a static IP address is one thing, configuring static routes in hosts is quite another one. Sorry I did not include this in my previous post, I was trying to make it short and it was not a good idea. More comments? Michel. > > 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. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 21:36: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 h325aXPL015104; Tue, 1 Apr 2003 21:36:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h325aXOm015103; Tue, 1 Apr 2003 21:36: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.9+Sun/8.12.9) with ESMTP id h325aTPL015096 for ; Tue, 1 Apr 2003 21:36: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 h325aacU008429 for ; Tue, 1 Apr 2003 21:36:36 -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 WAA21954 for ; Tue, 1 Apr 2003 22:36:31 -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, 2 Apr 2003 05:36: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; Wed, 2 Apr 2003 05:36: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; Wed, 2 Apr 2003 05:36:30 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; Wed, 2 Apr 2003 05:36:29 Z Received: from localhost (unknown [3ffe:501:100f:1048:6d96:fdb9:f33f:dfeb]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5B21815210; Wed, 2 Apr 2003 14:36:46 +0900 (JST) Date: Wed, 02 Apr 2003 14:36:19 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 30 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Before responding to the consensus call on site-local addresses, I'd like to ask one question for clarification. (As required, I changed the subject line). What was the consensus, if any, on alternatives to site-locals when SL is deprecated? In particular, which prefixes will we use for disconnected or intermittently connected "site"s? I've checked the chair's presentation slides and the draft minutes, and (roughly) followed the very recent discussion in the ML, but I cannot be sure about it. According to the draft minutes, someone mentioned we can use arbitrary prefixes for those purposes. That's true, but we cannot assure the uniqueness of the arbitrary-chosen prefixes, so I don't see any essential advantage over the existing fec0::/10 (with eliminating the "full" usage). I can live without site-locals, and, furthermore, I personally want the wg to stop the endless discussion and to concentrate on more important -from my personal perspective- issues. So, even if the idea of "arbitrary-chosen prefixes" is just a compromise (without any real benefit) to convince ourselves, it's okay for me. Then I'll vote for deprecating site-local. Could someone clarify this point, please? 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 Tue Apr 1 22:05: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 h3265uPL015438; Tue, 1 Apr 2003 22:05:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3265uru015437; Tue, 1 Apr 2003 22:05: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.9+Sun/8.12.9) with ESMTP id h3265qPL015430 for ; Tue, 1 Apr 2003 22:05: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 h3265xHP025725 for ; Tue, 1 Apr 2003 22:06:00 -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 XAA05299 for ; Tue, 1 Apr 2003 23:05: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; Wed, 2 Apr 2003 06:05: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; Wed, 2 Apr 2003 06:05: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; Wed, 2 Apr 2003 06:05:24 Z Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [210.49.138.109]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 06:05:23 Z Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h32659ab003898; Wed, 2 Apr 2003 16:05:09 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h32658IC010315; Wed, 2 Apr 2003 16:05:09 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200304020605.h32658IC010315@drugs.dv.isc.org> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) In-reply-to: Your message of "Wed, 02 Apr 2003 14:36:19 +0900." Date: Wed, 02 Apr 2003 16:05:08 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Before responding to the consensus call on site-local addresses, I'd > like to ask one question for clarification. (As required, I changed > the subject line). > > What was the consensus, if any, on alternatives to site-locals when SL > is deprecated? In particular, which prefixes will we use for > disconnected or intermittently connected "site"s? I've checked the > chair's presentation slides and the draft minutes, and (roughly) > followed the very recent discussion in the ML, but I cannot be sure > about it. The concensus call was predicated on "we will find another way to deal with disconnected / intermittently connected site." The was no concensus on how this would be achieved but there wa a commitment to find a solution if site-locals were deprecated. There are plenty of potential ways to achieve this some of which include: * get a prefix for disconnected access from a ISP. * set up registries. Mark > According to the draft minutes, someone mentioned we can use arbitrary > prefixes for those purposes. That's true, but we cannot assure the > uniqueness of the arbitrary-chosen prefixes, so I don't see any > essential advantage over the existing fec0::/10 (with eliminating the > "full" usage). > > I can live without site-locals, and, furthermore, I personally want > the wg to stop the endless discussion and to concentrate on more > important -from my personal perspective- issues. So, even if the > idea of "arbitrary-chosen prefixes" is just a compromise (without any > real benefit) to convince ourselves, it's okay for me. Then I'll vote > for deprecating site-local. > > Could someone clarify this point, please? > > 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 > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 22:29: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 h326T7PL015771; Tue, 1 Apr 2003 22:29:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h326T7Eh015770; Tue, 1 Apr 2003 22: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.9+Sun/8.12.9) with ESMTP id h326T3PL015763 for ; Tue, 1 Apr 2003 22:29: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 h326TBcU018650 for ; Tue, 1 Apr 2003 22:29:11 -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 XAA16748 for ; Tue, 1 Apr 2003 23:29:05 -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, 2 Apr 2003 06: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; Wed, 2 Apr 2003 06:25: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, 2 Apr 2003 06:28:47 Z Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 06:28:46 Z Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id h326Scw10176; Wed, 2 Apr 2003 15:28:38 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) id h326Sc126533; Wed, 2 Apr 2003 15:28:38 +0900 (JST) Received: from zuizan.jp.nec.com (zuizan.jp.nec.com [10.26.220.9]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id h326Sa918009; Wed, 2 Apr 2003 15:28:36 +0900 (JST) Received: from [10.41.211.53] by mail.jp.nec.com with ESMTP; Wed, 2 Apr 2003 15:28:36 +0900 Date: Wed, 02 Apr 2003 15:28:35 +0900 From: Hiroki Ishibashi Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) To: Mark.Andrews@isc.org Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 2.60 (WinNT,500) Organization: NEC Corporation In-Reply-To: <200304020605.h32658IC010315@drugs.dv.isc.org> References: <200304020605.h32658IC010315@drugs.dv.isc.org> Message-Id: <15C2F8E117049Dbashi@ipv6.nec.co.jp> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> Before responding to the consensus call on site-local addresses, I'd >> like to ask one question for clarification. (As required, I changed >> the subject line). >> >> What was the consensus, if any, on alternatives to site-locals when SL >> is deprecated? In particular, which prefixes will we use for >> disconnected or intermittently connected "site"s? I've checked the >> chair's presentation slides and the draft minutes, and (roughly) >> followed the very recent discussion in the ML, but I cannot be sure >> about it. > > The concensus call was predicated on "we will find another way > to deal with disconnected / intermittently connected site." > > The was no concensus on how this would be achieved but there wa > a commitment to find a solution if site-locals were deprecated. > > There are plenty of potential ways to achieve this some of > which include: > * get a prefix for disconnected access from a ISP. > * set up registries. These will definitely increase the cost of owning even disconnected IPv6 networks. Hiroki Ishibashi > > Mark > >> According to the draft minutes, someone mentioned we can use arbitrary >> prefixes for those purposes. That's true, but we cannot assure the >> uniqueness of the arbitrary-chosen prefixes, so I don't see any >> essential advantage over the existing fec0::/10 (with eliminating the >> "full" usage). >> >> I can live without site-locals, and, furthermore, I personally want >> the wg to stop the endless discussion and to concentrate on more >> important -from my personal perspective- issues. So, even if the >> idea of "arbitrary-chosen prefixes" is just a compromise (without any >> real benefit) to convince ourselves, it's okay for me. Then I'll vote >> for deprecating site-local. >> >> Could someone clarify this point, please? >> >> 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 >> -------------------------------------------------------------------- >-- >Mark Andrews, Internet Software Consortium >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Apr 1 23:11: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 h327B5PL016304; Tue, 1 Apr 2003 23:11:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h327B5CY016303; Tue, 1 Apr 2003 23:11: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 h327B2PL016296 for ; Tue, 1 Apr 2003 23:11:02 -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 h327B9HP008645 for ; Tue, 1 Apr 2003 23:11:09 -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 AAA03588 for ; Wed, 2 Apr 2003 00:11: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; Wed, 2 Apr 2003 07:11: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; Wed, 2 Apr 2003 07:11:02 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, 2 Apr 2003 07:11:01 Z Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [210.49.138.109]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 07:11:00 Z Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h327Akab003961; Wed, 2 Apr 2003 17:10:47 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h327AkIC010514; Wed, 2 Apr 2003 17:10:46 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200304020710.h327AkIC010514@drugs.dv.isc.org> To: Hiroki Ishibashi Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) In-reply-to: Your message of "Wed, 02 Apr 2003 15:28:35 +0900." <15C2F8E117049Dbashi@ipv6.nec.co.jp> Date: Wed, 02 Apr 2003 17:10:46 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > >> Before responding to the consensus call on site-local addresses, I'd > >> like to ask one question for clarification. (As required, I changed > >> the subject line). > >> > >> What was the consensus, if any, on alternatives to site-locals when SL > >> is deprecated? In particular, which prefixes will we use for > >> disconnected or intermittently connected "site"s? I've checked the > >> chair's presentation slides and the draft minutes, and (roughly) > >> followed the very recent discussion in the ML, but I cannot be sure > >> about it. > > > > The concensus call was predicated on "we will find another way > > to deal with disconnected / intermittently connected site." > > > > The was no concensus on how this would be achieved but there wa > > a commitment to find a solution if site-locals were deprecated. > > > > There are plenty of potential ways to achieve this some of > > which include: > > * get a prefix for disconnected access from a ISP. > > * set up registries. > > These will definitely increase the cost of owning even disconnected > IPv6 networks. > > Hiroki Ishibashi TNSTAAFL RFC 1918 addresses cost real money to support. There are sacrificial machines that just serve reverse lookups for these addresses. They actually receive more traffic than the root servers. Site-locals will cost real money. The address will leak. Put the costs of supporting disconnected / intermittently connected sites back on the sites that need this fuctionality. Having to lease a prefix will help cover the costs of supporting the reverse lookups on leaked lookups. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 1 23:12: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 h327CvPL016342; Tue, 1 Apr 2003 23:12:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h327CuKr016341; Tue, 1 Apr 2003 23:12: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.9+Sun/8.12.9) with ESMTP id h327CqPL016325 for ; Tue, 1 Apr 2003 23:12:53 -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 h327D0cU028239 for ; Tue, 1 Apr 2003 23:13: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-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27242 for ; Tue, 1 Apr 2003 23:12:54 -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, 2 Apr 2003 07:12: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; Wed, 2 Apr 2003 07:12: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; Wed, 2 Apr 2003 07:12:53 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 07:12:52 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h327CIu23501; Wed, 2 Apr 2003 10:12:18 +0300 Date: Wed, 2 Apr 2003 10:12:18 +0300 (EEST) From: Pekka Savola To: Brian Zill cc: Michel Py , Brian Carpenter , Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] 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, 1 Apr 2003, Brian Zill wrote: > In other words: it is quite all right for nodes to have a 6to4 > pseudo-interface enabled even if another link to which they are > connected has a native prefix including those within 2002::/16. True. But you assume that such links are either very simple (one link, no links behind that) or you run a routing protocol which distributes those prefixes. (There are, I think, also some implementations that might not handle this properly but I haven't verified.) > The RFC > is fine as is. Depends on what you want. The use of 2002:PRIV:ATE is *not* fine for a substitute of site-local addressing. > > -----Original Message----- > > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > > Sent: Thursday, 27 March, 2003 12:14 > > To: Ole Troan > > Cc: Brian Carpenter; ipng@sunroof.eng.sun.com > > Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local > > addresses?] > > > > > > > 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 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Tue Apr 1 23:56: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 h327usPL016995; Tue, 1 Apr 2003 23:56:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h327usLg016994; Tue, 1 Apr 2003 23:56: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 h327upPL016987 for ; Tue, 1 Apr 2003 23:56: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 h327uwcU007564 for ; Tue, 1 Apr 2003 23:56: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 AAA27563 for ; Wed, 2 Apr 2003 00:56:42 -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, 2 Apr 2003 07:56: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; Wed, 2 Apr 2003 07:56: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, 2 Apr 2003 07:56:34 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, 2 Apr 2003 07:56:33 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.8) with ESMTP id h327uW5c024046 for ; Wed, 2 Apr 2003 09:56:32 +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 h327uVHD270992 for ; Wed, 2 Apr 2003 09:56:31 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA29552 from ; Wed, 2 Apr 2003 09:56:27 +0200 Message-Id: <3E8A9768.7EE57527@hursley.ibm.com> Date: Wed, 02 Apr 2003 09:55:20 +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: JINMEI@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: DeprecatingSite-Local Addressing) References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya / $B?@L@C#:H(B wrote: > > Before responding to the consensus call on site-local addresses, I'd > like to ask one question for clarification. (As required, I changed > the subject line). > > What was the consensus, if any, on alternatives to site-locals when SL > is deprecated? As I've already said, I think that is the wrong order of discussion. I think we should clear the desktop first, by getting rid of ambiguous site-local address space, and then discuss possible new solutions. We've been going round in circles for months, and we need to stop 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 Apr 2 00:05:18 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 h3285HPL017321; Wed, 2 Apr 2003 00:05:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3285Hhq017320; Wed, 2 Apr 2003 00:05: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.9+Sun/8.12.9) with ESMTP id h3285EPL017313 for ; Wed, 2 Apr 2003 00: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 h3285LHP019740 for ; Wed, 2 Apr 2003 00:05:21 -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 BAA05459 for ; Wed, 2 Apr 2003 01:05:15 -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, 2 Apr 2003 08:05:14 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, 2 Apr 2003 08:02: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, 2 Apr 2003 08:05:14 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, 2 Apr 2003 08:05:13 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h3285A7o024908 for ; Wed, 2 Apr 2003 10:05:11 +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 h3284svv271554 for ; Wed, 2 Apr 2003 10:05:00 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44734 from ; Wed, 2 Apr 2003 10:04:53 +0200 Message-Id: <3E8A9962.D825503D@hursley.ibm.com> Date: Wed, 02 Apr 2003 10:03:46 +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 Cc: ipng@sunroof.eng.sun.com Subject: Re: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing References: <963621801C6D3E4A9CF454A1972AE8F504F711@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 What I raised my hand for in San Francisco was to deprecate SL addresses as currently defined in draft-ietf-ipngwg-addr-arch-v3-11.txt (and in RFC 2373). I don't find this question ambiguous. It's true that we would have to revise the addressing architecture again as a result (probably simply by removing all reference to SL and reserving FEC0::/10), but that is editorial work. Brian Michel Py wrote: > > Margaret / Bob, > > What is this consensus about? I was hoping that the mailing list would > be asked to express their opinions _after_ a text to deprecate > site-local addressing had been submitted to the working group. In the > current situation, this consensus if there is one would be good only to > accept text as a working document. This document that still has to be > seen then should go to WG last call. > > Where is the doc to deprecate site-local addressing? > > 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 Wed Apr 2 00:21: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 h328L5PL017798; Wed, 2 Apr 2003 00:21:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h328L5c6017797; Wed, 2 Apr 2003 00:21: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.9+Sun/8.12.9) with ESMTP id h328L1PL017790 for ; Wed, 2 Apr 2003 00:21:01 -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 h328L8cU014938 for ; Wed, 2 Apr 2003 00:21:08 -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 AAA08848 for ; Wed, 2 Apr 2003 00:21: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; Wed, 2 Apr 2003 08:21: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; Wed, 2 Apr 2003 08: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; Wed, 2 Apr 2003 08:20:59 Z Received: from mailhost.packetfront.com ([192.121.165.3] [192.121.165.3]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 08:20:59 Z Received: from [192.168.1.11] (helo=Mtw10) by mailhost.packetfront.com with esmtp (Exim 3.35 #1 (Debian)) id 190dUE-0008Mj-00; Wed, 02 Apr 2003 10:20:46 +0200 From: "Fredrik Nyman" Organization: PacketFront Sweden AB To: Margaret Wasserman Date: Wed, 2 Apr 2003 10:20:43 +0200 MIME-Version: 1.0 Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Reply-to: fredrik@packetfront.com CC: ipng@sunroof.eng.sun.com Message-Id: <3E8AB97B.31214.9FA6DAA@localhost> In-reply-to: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing". -- Fredrik Nyman PacketFront Sweden AB http://www.packetfront.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 Apr 2 00:43: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 h328huPL018109; Wed, 2 Apr 2003 00:43:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h328hutw018108; Wed, 2 Apr 2003 00:43: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.9+Sun/8.12.9) with ESMTP id h328hrPL018101 for ; Wed, 2 Apr 2003 00:43: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 h328i0cU021923 for ; Wed, 2 Apr 2003 00:44:00 -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 BAA03107 for ; Wed, 2 Apr 2003 01:43:54 -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, 2 Apr 2003 08:42: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, 2 Apr 2003 08:42: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, 2 Apr 2003 08:42:36 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, 2 Apr 2003 08:42:36 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 h328gU7o024664 for ; Wed, 2 Apr 2003 10:42: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 h328gUHD272710 for ; Wed, 2 Apr 2003 10:42:30 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA53594 from ; Wed, 2 Apr 2003 10:42:28 +0200 Message-Id: <3E8AA231.C4992A71@hursley.ibm.com> Date: Wed, 02 Apr 2003 10:41:21 +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: What is a site local address? [Re: CONSENSUS CALL: DeprecatingSite-Local Addressing] References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> <1049232974.20706.1409.camel@newcastle.torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As I already said under another subject line, what I understood we were deprecating is SL as defined in the current address architecture, i.e. FEC0::/10. That's the only formal definition of SL, so I don't see what else we could be referring to. Brian Steven Blake wrote: > > On Tue, 2003-04-01 at 14:37, Margaret Wasserman wrote: > > > The question is: > > > > Should we deprecate IPv6 site-local unicast addressing? > > > > Valid responses are: > > > > "YES -- Deprecate site-local unicast addressing". > > "NO -- Do not deprecate site-local unicast addressing". > > I think the question needs to be more specific: > > - Deprecate addresses in fec0::/48? > > - Deprecate addresses in fec0::/10 (with no scheme to make bits 10:47 > probabilistically or globally unique at a site)? > > - Deprecate all non-PA, non-link-local unicast addresses? > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven L. Blake > Ericsson IP Infrastructure +1 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 01:36: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 h329agPL018635; Wed, 2 Apr 2003 01:36:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h329agAd018634; Wed, 2 Apr 2003 01:36:42 -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.9+Sun/8.12.9) with ESMTP id h329acPL018627 for ; Wed, 2 Apr 2003 01:36:38 -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 h329afS04506; Wed, 2 Apr 2003 11:36:41 +0200 (MEST) Date: Wed, 2 Apr 2003 11:36:38 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Margaret Wasserman , 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 > According to the draft minutes, someone mentioned we can use arbitrary > prefixes for those purposes. That's true, but we cannot assure the > uniqueness of the arbitrary-chosen prefixes, so I don't see any > essential advantage over the existing fec0::/10 (with eliminating the > "full" usage). > > I can live without site-locals, and, furthermore, I personally want > the wg to stop the endless discussion and to concentrate on more > important -from my personal perspective- issues. So, even if the > idea of "arbitrary-chosen prefixes" is just a compromise (without any > real benefit) to convince ourselves, it's okay for me. Then I'll vote > for deprecating site-local. I don't think the WG has discussed the details of how to handle disconnected sites. One of my high bits expressed at the mike in SF was that we should design IPv6 for the global Internet and not add a bunch of special cases to the global architecture to support local communication. For local communication I personally think that just making up a prefix might not be a bad approach. Whether you use a designed non-unique prefix (like fec0) or a made up prefix for a disconnected site you have the same issue; when you actually connect - either to the global Internet or to some other local domain - you need to renumber. In the case of the global Internet you need to renumber to make global communication work. In case of connecting to some other local domain you need to renumber so that the two domains can communicate i.e. they can't have conflicting addresses. A designated non-unique prefix doesn't make this any easier. But as I said, this is yet to be discussed in the WG, as is the issue of bellovin/zill prefix advertisements for designating the address prefixes for the local domain (which has most of the same issues as using site-locals for "security" benefits). 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 Apr 2 02:48:59 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 h32AmwPL018866; Wed, 2 Apr 2003 02:48:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32Amw6U018865; Wed, 2 Apr 2003 02:48: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.9+Sun/8.12.9) with ESMTP id h32AmtPL018858 for ; Wed, 2 Apr 2003 02:48:55 -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 h32An2cU018388 for ; Wed, 2 Apr 2003 02:49: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 CAA23533 for ; Wed, 2 Apr 2003 02:48:56 -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, 2 Apr 2003 10:48: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, 2 Apr 2003 10:48: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, 2 Apr 2003 10:48:55 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, 2 Apr 2003 10:48:55 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id D37628F16; Wed, 2 Apr 2003 12:48:51 +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 7FECC8A47; Wed, 2 Apr 2003 12:48:42 +0200 (CEST) From: "Jeroen Massar" To: Cc: Subject: Charge for traffic, not IP addresses (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 12:49:49 +0200 Organization: Unfix Message-Id: <001101c2f905$96e6dc60$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 h32AmtPL018859 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk William_G_Allmond@notes.tcs.treas.gov wrote: > NO - Do NOT Deprecate Site-Local Addressing. > > There are reason to use site-locals, and reason NOT to use them. But > "FORBIDDING" people will only alienate them and lead them to > find ways to do it anyway. > > Perfect example, when (or should I say IF) my home ISP goes > to IPv6, they charge per IP. Always have, and always will. > Sure, they will gladly give me a range of IPs, as well as > gladly charge me as if each were a PC. Also, > when I get tired of putting up with the abuse from this > particular ISP and decide to choose another ISP to abuse me, > I will still have the same issue. Very good example that you don't get it at all. ISP's should be charging for traffic, not for IP's. They pay for traffic to their upstreams not for IP addresses. IP addresses only have a registration cost. Just like when you sign up to the service. There is no reason for keeping SL unless you imply that you are going to NAT anyways. If you intend to do that stay with IPv4. Or: stay in your soap box ;) 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 Apr 2 02:52: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 h32Aq8PL018964; Wed, 2 Apr 2003 02:52:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32Aq8Ac018963; Wed, 2 Apr 2003 02:52: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 h32Aq4PL018956 for ; Wed, 2 Apr 2003 02:52: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 h32AqBHP024080 for ; Wed, 2 Apr 2003 02:52:11 -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 DAA16920 for ; Wed, 2 Apr 2003 03:52: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; Wed, 2 Apr 2003 10:52: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; Wed, 2 Apr 2003 10:52: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; Wed, 2 Apr 2003 10:52:05 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, 2 Apr 2003 10:52:05 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 689C18F16; Wed, 2 Apr 2003 12:52:03 +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 F021E8A47; Wed, 2 Apr 2003 12:51:56 +0200 (CEST) From: "Jeroen Massar" To: "'Brian McGehee'" , Subject: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 12:53:04 +0200 Organization: Unfix Message-Id: <001901c2f906$0a6bc470$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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 h32Aq5PL018957 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian McGehee write: > NO -- Do not deprecate site-local unicast addressing > > - Site-locals should be retained for disconnected sites. If > not SL, then > a mechanism needs to be adopted that can provide a private means of > selecting from a private address space that is "reserved" for this > function. 2002 is not a working alternative. > - Site-locals should be retained for intermittently connected sites. > - Site-locals should be retained as a means for internal > connections to > survive global prefix renumbering. All of the above will make the address not unique. Have fun merging your networks. > - Other (please specify). Continually changing the specs will only > further alienate those that refuse to adopt. Not offering > equivalents to what exists today (rfc 1918) will accomplish the same. > (and do we really want to put all the NAT vendors out of business? ;-) > "Necessity drives ingenuity." Here you are already levelling NAT with SL. If you already intend to NAT, stay with IPv4, you will have the same problems and still won't get back the end to end connectivity which was one of the major things IPv6 was built for. Or we could just do IPv6 with 32bits again... 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 Apr 2 03:01: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 h32B1sPL019419; Wed, 2 Apr 2003 03:01:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32B1sNX019418; Wed, 2 Apr 2003 03:01: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 h32B1oPL019408 for ; Wed, 2 Apr 2003 03:01: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 h32B1wcU020724 for ; Wed, 2 Apr 2003 03:01:58 -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 DAA01663 for ; Wed, 2 Apr 2003 03:01:52 -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, 2 Apr 2003 11:01:40 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, 2 Apr 2003 11:01: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; Wed, 2 Apr 2003 11:01:39 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, 2 Apr 2003 11:01:39 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 531258B6F; Wed, 2 Apr 2003 13:01:36 +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 2F98C8F16; Wed, 2 Apr 2003 13:01:30 +0200 (CEST) From: "Jeroen Massar" To: , "'Hiroki Ishibashi'" Cc: "=?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?=" , Subject: RE: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 13:02:35 +0200 Organization: Unfix Message-Id: <002101c2f907$6013c1b0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <200304020710.h327AkIC010514@drugs.dv.isc.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 h32B1oPL019409 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark.Andrews@isc.org wrote: > > Hiroki Ishibashi wrote: > > > There are plenty of potential ways to achieve this some of > > > which include: > > > * get a prefix for disconnected access from a ISP. > > > * set up registries. > > > > These will definitely increase the cost of owning even disconnected > > IPv6 networks. > > > > Hiroki Ishibashi > > TNSTAAFL > > RFC 1918 addresses cost real money to support. There are > sacrificial machines that just serve reverse lookups for > these addresses. They actually receive more traffic than > the root servers. Fortunatly AS112 now catches these at some IX'es thus lowering *transit* traffic. > Put the costs of supporting disconnected / intermittently > connected sites back on the sites that need this fuctionality. > Having to lease a prefix will help cover the costs of > supporting the reverse lookups on leaked lookups. If someone doesn't want/like this they can pick a random number and use that, they still have to renumber when they interconnect to another site or the internet. 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 Apr 2 03:45:14 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 h32BjEPL019846; Wed, 2 Apr 2003 03:45:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32BjE62019845; Wed, 2 Apr 2003 03:45: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.9+Sun/8.12.9) with ESMTP id h32BjAPL019838 for ; Wed, 2 Apr 2003 03:45:10 -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 h32BjEHP004150 for ; Wed, 2 Apr 2003 03:45:14 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA07550 for ; Wed, 2 Apr 2003 04:45:08 -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, 2 Apr 2003 11:45: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; Wed, 2 Apr 2003 11:45: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, 2 Apr 2003 11:44:51 Z Received: from omgo.iij.ad.jp (omgo.iij.ad.jp [202.232.30.157]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 11:44:50 Z Received: from ns.iij.ad.jp ([192.168.2.111]) by omgo.iij.ad.jp (8.12.9/8.12.7) with ESMTP id h32BilgA020570; Wed, 2 Apr 2003 20:44:48 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA28137; Wed, 2 Apr 2003 20:44:47 +0900 (JST) Date: Wed, 02 Apr 2003 20:44:44 +0900 (JST) Message-Id: <20030402.204444.128787396.keiichi@iij.ad.jp> To: mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> X-Mailer: Mew version 4.0.51 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing". But, some mechanisms (or manner) for disconnected sites should be invented. --- Keiichi SHIMA IIJ Research Laboratory KAME Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 03:57: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 h32BviPL020164; Wed, 2 Apr 2003 03:57:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32BviPD020163; Wed, 2 Apr 2003 03:57: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 h32BvePL020156 for ; Wed, 2 Apr 2003 03:57:40 -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 h32BvmHP006353 for ; Wed, 2 Apr 2003 03:57:48 -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 DAA23962 for ; Wed, 2 Apr 2003 03:57:43 -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, 2 Apr 2003 11:57: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; Wed, 2 Apr 2003 11:57: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; Wed, 2 Apr 2003 11:57:42 Z Received: from albert.tavian.com (albert.tavian.com [66.149.217.205]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 11:57:41 Z Received: from gamer (dltpppdsl198.sttl.uswest.net [63.226.214.198]) by albert.tavian.com (8.8.7/8.8.7) with SMTP id DAA02968; Wed, 2 Apr 2003 03:57:32 -0800 Message-Id: <007101c2f90e$d0522d20$6801010a@tavian.com> From: "Brian McGehee" To: "Jeroen Massar" Cc: References: <001901c2f906$0a6bc470$210d640a@unfix.org> Subject: Re: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 03:55:50 -0800 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 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk *Notes below * I agree "NAT != SL"! Except in the case that hosts need "global" connectivity and they ONLY have a SL address will require NAT. Or they should have a second IPv6 globally unique unicast address (which isn't that hard to have multiple addresses???) * I can envision an enterprise environment that is comfortable using FEC0::/10 for internal communications but a host has a globally unique address also for external communications (on hosts that have this neccessity) This could be comfortable to a network admin/ops/noc. ----- Original Message ----- From: "Jeroen Massar" To: "'Brian McGehee'" ; Sent: Wednesday, April 02, 2003 2:53 AM Subject: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) > Brian McGehee write: > > > NO -- Do not deprecate site-local unicast addressing > > > > - Site-locals should be retained for disconnected sites. If > > not SL, then > > a mechanism needs to be adopted that can provide a private means of > > selecting from a private address space that is "reserved" for this > > function. 2002 is not a working alternative. > > - Site-locals should be retained for intermittently connected sites. > > - Site-locals should be retained as a means for internal > > connections to > > survive global prefix renumbering. > > All of the above will make the address not unique. > Have fun merging your networks. * Anyone that has had to merge 2 very large networks will know the great amount of design, architecture, and planning that has to go into such a project. It's not as easy as changing "a DHCP range" or a "handful of RAs" even if they were Globally unique IPv6 (or globally unique IPv4 addresses). I agree that IPv6 stateless Auto-Config adds a lot of room to make this an easier process but it doesn't solve the unique problems that come up in merging two large enterprise networks. * Yes. There is the chance that SL will "overlap" in a situation of merging two IPv6 enterprise networks. But if we don't offer SL. What will people choose for private addressing? I would REALLY like to see an alternative to SL that maybe provides for a set of bits that relate to Geography? ISP? etc? I'm open to other suggestions. But without an alternative I have to vote "NO". Let's see some alternatives? Please, again!=> Let's not alienate those that are already afraid of change by "changing" things. > > > - Other (please specify). Continually changing the specs will only > > further alienate those that refuse to adopt. Not offering > > equivalents to what exists today (rfc 1918) will accomplish the same. > > (and do we really want to put all the NAT vendors out of business? > ;-) > > "Necessity drives ingenuity." > > Here you are already levelling NAT with SL. > If you already intend to NAT, stay with IPv4, you will have the same > problems and still won't get back the end to end connectivity which > was one of the major things IPv6 was built for. Or we could just > do IPv6 with 32bits again... * Yes if anyone chooses to do NAT. They should have that option, and an IPv6 address space to appropriately use for such functionality [it's a feature, not a bug](some people feel strongly that NAT is a security feature). * Again we shouldn't "take away" from what is already there. From what people are comfortable with! I am not a proponent of NAT (bottlenecking, added administration, etc...) but we need to continue to support environments that exists today. If a company decides to incorporate NAT in their firewall(s) (or even NAT-PT/NAPT-PT), well let's let them! We've introduced these ideas in IPv4, they exist today. The current "IPv6 RFC's" and "IPv6 literature" document this continued support clearly (FEC0::/10). Constantly changing the standards scares "people" away from adoption. Do we really want to make such a drastic change. (I'm still trying to deal w/ the deprecation of A6 records. They worked GREAT in renumbering!) Yes. IPv6 offers 340 undecillion (or sextillion depending on where your from) addresses. Enough to address every device in the world. Great. But we need to offer all the functionality that exists today. They exist for reason (besides just lack of address space. Some people feel secure/comfortable behind NAT!) ...my $.02 > > 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 Apr 2 04:09: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 h32C9KPL020361; Wed, 2 Apr 2003 04:09:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32C9KKL020360; Wed, 2 Apr 2003 04:09: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 h32C9GPL020353 for ; Wed, 2 Apr 2003 04:09: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 h32C9OHP008805 for ; Wed, 2 Apr 2003 04:09:24 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA25622 for ; Wed, 2 Apr 2003 05:09: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, 2 Apr 2003 12:09: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; Wed, 2 Apr 2003 12:09: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; Wed, 2 Apr 2003 12:09:17 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; Wed, 2 Apr 2003 12:09: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 h32C8dOc027750; Wed, 2 Apr 2003 15:08:39 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h32C8c5U027746; Wed, 2 Apr 2003 15:08:38 +0300 Date: Wed, 2 Apr 2003 15:08:38 +0300 Message-Id: <200304021208.h32C8c5U027746@burp.tkv.asdf.org> From: Markku Savela To: jeroen@unfix.org CC: Mark.Andrews@isc.org, bashi@ipv6.nec.co.jp, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com In-reply-to: <002101c2f907$6013c1b0$210d640a@unfix.org> (jeroen@unfix.org) Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) References: <002101c2f907$6013c1b0$210d640a@unfix.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Jeroen Massar" > > If someone doesn't want/like this they can pick a random number > and use that, they still have to renumber when they interconnect > to another site or the internet. No, when you interconnect, you just keep using your global addresses in parallel with site locals. Despite claims of opposite, this combination works just fine. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 04:13:49 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 h32CDnPL020506; Wed, 2 Apr 2003 04:13:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32CDmGr020505; Wed, 2 Apr 2003 04:13: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.9+Sun/8.12.9) with ESMTP id h32CDjPL020498 for ; Wed, 2 Apr 2003 04:13: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 h32CDrHP009496 for ; Wed, 2 Apr 2003 04:13:53 -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 EAA29145 for ; Wed, 2 Apr 2003 04:13:48 -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, 2 Apr 2003 12:13: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; Wed, 2 Apr 2003 12:13: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; Wed, 2 Apr 2003 12:13:47 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, 2 Apr 2003 12:13:46 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 4AC418F17; Wed, 2 Apr 2003 14:13:44 +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 CEE528A47; Wed, 2 Apr 2003 14:13:37 +0200 (CEST) From: "Jeroen Massar" To: "'Brian McGehee'" Cc: Subject: RE: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 14:14:44 +0200 Organization: Unfix Message-Id: <003801c2f911$7393c6e0$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 In-Reply-To: <007101c2f90e$d0522d20$6801010a@tavian.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 h32CDjPL020499 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian McGehee [mailto:doc@albert.tavian.com] wrote: > *Notes below > > * I agree "NAT != SL"! Except in the case that hosts need "global" > connectivity and they ONLY have a SL address will require > NAT. Or they should have a second IPv6 globally unique unicast address > (which isn't that hard to have multiple addresses???) Use a firewall to block incoming packets. > * I can envision an enterprise environment that is comfortable using > FEC0::/10 for internal communications but a host has a globally unique > address also for external communications (on hosts that have this > neccessity) This could be comfortable to a network admin/ops/noc. Then don't route a certain prefix. > ----- Original Message ----- > From: "Jeroen Massar" > To: "'Brian McGehee'" ; > > Sent: Wednesday, April 02, 2003 2:53 AM > Subject: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local > Addressing) > > > > Brian McGehee write: > > > > > NO -- Do not deprecate site-local unicast addressing > > > > > > - Site-locals should be retained for disconnected sites. If > > > not SL, then > > > a mechanism needs to be adopted that can provide a > private means of > > > selecting from a private address space that is "reserved" for this > > > function. 2002 is not a working alternative. > > > - Site-locals should be retained for intermittently > connected sites. > > > - Site-locals should be retained as a means for internal > > > connections to > > > survive global prefix renumbering. > > > > All of the above will make the address not unique. > > Have fun merging your networks. > > * Anyone that has had to merge 2 very large networks will > know the great amount of design, architecture, and planning > that has to go into such a project. It's not as easy as > changing "a DHCP range" or a "handful of RAs" even if they > were Globally unique IPv6 (or globally unique IPv4 addresses). > I agree that IPv6 stateless Auto-Config adds a lot of room to > make this an easier process but it doesn't solve the unique > problems that come up in merging two large enterprise networks. If they are globally unique, one doesn't HAVE to renumber. And indeed the problems of renumbering lie in configuration items not in the network numbering itself. > * Yes. There is the chance that SL will "overlap" in a > situation of merging two IPv6 enterprise networks. > But if we don't offer SL. What will people > choose for private addressing? I would REALLY like to see an > alternative to SL that maybe provides for a set of bits that > relate to Geography? ISP? > etc? I'm open to other suggestions. But without an > alternative I have to vote "NO". Let's see some alternatives? > Please, again!=> Let's not alienate those that are already > afraid of change by "changing" things. A central registry where one can obtain unique disconnected space per /48. > > > - Other (please specify). Continually changing the specs > will only > > > further alienate those that refuse to adopt. Not offering > > > equivalents to what exists today (rfc 1918) will > accomplish the same. > > > (and do we really want to put all the NAT vendors out of > business? > > ;-) > > > "Necessity drives ingenuity." > > > > Here you are already levelling NAT with SL. > > If you already intend to NAT, stay with IPv4, you will have the same > > problems and still won't get back the end to end connectivity which > > was one of the major things IPv6 was built for. Or we could just > > do IPv6 with 32bits again... > > * Yes if anyone chooses to do NAT. They should have that > option, and an IPv6 address space to appropriately use for > such functionality [it's a feature, not a bug](some people > feel strongly that NAT is a security feature). If you intend to do it then just stay with IPv4 without end-to-end connectivity and don't drag down the rest of us. > * Again we shouldn't "take away" from what is already there. > From what people are comfortable with! I am not a proponent > of NAT (bottlenecking, added administration, etc...) but we > need to continue to support environments that exists today. > If a company decides to incorporate NAT in their firewall(s) "Look mom he said NAT and firewall in one sentence" > (or even NAT-PT/NAPT-PT), well let's let them! We've > introduced these ideas in IPv4, they exist today. They didn't pay with money a very long time ago. Should we now all go exchange eggs, chicken and wild beast again as a currency? That's called evolution. There is no need for NAT which is apparently the sole reason you want SL. > The current "IPv6 RFC's" and "IPv6 literature" document this > continued support clearly (FEC0::/10). And people have realized that it was a mistake and want to clear that mistake up before it starts to hurt hard. > Constantly changing the standards scares "people" away from > adoption. Do we really want to make such a drastic change. > (I'm still trying to deal w/ the deprecation of A6 records. > They worked GREAT in renumbering!) If you have a real use for A6, just like A6, then document it and bring it forward, thats where these WG's are all about. > Yes. IPv6 offers 340 undecillion (or sextillion depending > on where your from) addresses. Enough to address every > device in the world. Indeed so where did we need SL for again? To NAT???? > Great. But we need to offer all the functionality that > exists today. They exist for reason (besides just lack > of address space. And which reasons where that again, I don't recall you mentioning ANY reason here that doesn't relate to NAT. Again, if you want NAT, then stick to IPv4. > Some people feel secure/comfortable behind NAT!) > ...my $.02 You should not feel secure behind a NAT. NAT has nothing to do with security. Not routing a prefix somehow has though. Apparently you have no other need for SL than to NAT. I rest my case. 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 Apr 2 04:20:35 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 h32CKZPL020884; Wed, 2 Apr 2003 04:20:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32CKZ7U020883; Wed, 2 Apr 2003 04:20: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.9+Sun/8.12.9) with ESMTP id h32CKVPL020874 for ; Wed, 2 Apr 2003 04:20:31 -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 h32CKdHP010911 for ; Wed, 2 Apr 2003 04:20: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 FAA09290 for ; Wed, 2 Apr 2003 05:20: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; Wed, 2 Apr 2003 12:20: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; Wed, 2 Apr 2003 12: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; Wed, 2 Apr 2003 12:20:28 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, 2 Apr 2003 12:20:27 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id B480F8F19; Wed, 2 Apr 2003 14:20:23 +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 91C9E89B2; Wed, 2 Apr 2003 14:20:16 +0200 (CEST) From: "Jeroen Massar" To: "'Markku Savela'" Cc: , , , Subject: RE: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 14:21:24 +0200 Organization: Unfix Message-Id: <004001c2f912$619c5c80$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 In-Reply-To: <200304021208.h32C8c5U027746@burp.tkv.asdf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 h32CKWPL020877 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela [mailto:msa@burp.tkv.asdf.org] wrote: > > From: "Jeroen Massar" > > > > If someone doesn't want/like this they can pick a random number > > and use that, they still have to renumber when they interconnect > > to another site or the internet. > > No, when you interconnect, you just keep using your global addresses > in parallel with site locals. > > Despite claims of opposite, this combination works just fine. Example.com: fec0::/10 Example.org: fec0::/10 Good luck in tossing the bits around to routers in between those sites :) Not even speaking about when you have internal webservers: www.example.com fec0::1 www.example.org fec0::1 Even NAT won't help you here... Or is it suddenly 'allowed' to use the global address ? Then where did you need those site locals for again? What you need is a globally unique /48 that is disconnected and which one should be able to register 'cheaply'. Eg an annual fee of E20 or something just to make sure that not everybody starts harvesting them. The /32 from which these /48's come (or fec0::/10 could be a great candidate) should never be routable/announced onto the internet. 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 Apr 2 04: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 h32CdNPL021716; Wed, 2 Apr 2003 04:39:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32CdNhk021715; Wed, 2 Apr 2003 04: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 h32CdJPL021705 for ; Wed, 2 Apr 2003 04:39:19 -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 h32CdSHP014576 for ; Wed, 2 Apr 2003 04:39: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 EAA00924 for ; Wed, 2 Apr 2003 04:39:22 -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, 2 Apr 2003 12:39: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; Wed, 2 Apr 2003 12:39:14 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, 2 Apr 2003 12:39:14 Z Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 12:39:13 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.8) with ESMTP id h32CdAni026382 for ; Wed, 2 Apr 2003 14:39:10 +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 h32CdAvv215486 for ; Wed, 2 Apr 2003 14:39:10 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49982 from ; Wed, 2 Apr 2003 14:39:08 +0200 Message-Id: <3E8AD9A9.F130D71A@hursley.ibm.com> Date: Wed, 02 Apr 2003 14:38:01 +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: <963621801C6D3E4A9CF454A1972AE8F504F70C@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: > > 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. Exactly. It was the present incarnation, not some possible future incarnation, that I raised my hand against. 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 Apr 2 04:41: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 h32CftPL021835; Wed, 2 Apr 2003 04:41:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32CftKY021834; Wed, 2 Apr 2003 04:41: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 h32CfqPL021827 for ; Wed, 2 Apr 2003 04:41:52 -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 h32Cg0HP015038 for ; Wed, 2 Apr 2003 04:42:00 -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 EAA15670 for ; Wed, 2 Apr 2003 04:41:54 -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, 2 Apr 2003 12:41: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; Wed, 2 Apr 2003 12:38: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, 2 Apr 2003 12:41:52 Z Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 12:41:52 Z Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h32CavaX028589; Wed, 2 Apr 2003 05:36:57 -0700 (MST) Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA13547; Wed, 2 Apr 2003 05:36:56 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h32CapF27309; Wed, 2 Apr 2003 06:36:52 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 9C8F02EC86; Wed, 2 Apr 2003 14:36:49 +0200 (CEST) Message-Id: <3E8AD961.9050006@nal.motlabs.com> Date: Wed, 02 Apr 2003 14:36:49 +0200 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter Cc: , , Subject: Re: Outlawing (Avoiding) NAT with IPv6 References: <07a201c2f7d7$157391c0$ee1a4104@eagleswings> <3E897DE0.85A84EED@hursley.ibm.com> In-Reply-To: <3E897DE0.85A84EED@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: >>> 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. > > > Actually not, if you have a domestic /48 or /64 prefix. But the > MobileIP solution looks OK. Looks but doesn't act like really providing location privacy, IMHO. In my understanding, the essence of the hmipv6 location privacy mechanism lies in the MAP replacing a RCoA for a LCoA (when decapsulating). However, it is very much likely that the two addresses will only differ in the /64 prefix. Suffices it for an attacker that wants to find the correlation LCoA-RCoA to visit the MAP domain once and learn that domain's prefixes that are part of all of that domain's LCoA's. What one really obtains with HMIP is that one gets assigned two addresses and is free to inform its CN about one of those addresses. Nothing about a location being assigned to an address, let alone the question of hiding that location. Another location privacy drawback in hmipv6 is that it is the network that decides whether an MN can use that location privacy or not. That should supposedly be entirely an MN choice. My two cents worth; (two because I'm getting the ipng mails twice :-) Alex GBU -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 04:44: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 h32CiNPL022138; Wed, 2 Apr 2003 04:44:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32CiMRQ022137; Wed, 2 Apr 2003 04:44: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.9+Sun/8.12.9) with ESMTP id h32CiJPL022128 for ; Wed, 2 Apr 2003 04:44: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 h32CiRcU011140 for ; Wed, 2 Apr 2003 04:44: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.3p2+Sun/8.9.3) with ESMTP id FAA17966 for ; Wed, 2 Apr 2003 05:44: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; Wed, 2 Apr 2003 12:44:21 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, 2 Apr 2003 12:44: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, 2 Apr 2003 12:44:18 Z Received: from darwin.altera.com (darwin.altera.com [66.35.227.3]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 12:44:17 Z Received: from Altera.COM (sunrise [137.57.1.1]) by darwin.altera.com (8.11.6+Sun/8.11.6) with ESMTP id h32CeaJ07553; Wed, 2 Apr 2003 04:40:36 -0800 (PST) Received: from sj-gw01.altera.priv.altera.com by Altera.COM (8.8.8+Sun/SMI-4.1) id EAA04059; Wed, 2 Apr 2003 04:44:14 -0800 (PST) Received: by sj-gw01.altera.priv.altera.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 04:44:14 -0800 Message-Id: <0C3F0B5700099E419AAE3711394DCA5E88FA7C@UK-ISMSG01.altera.priv.altera.com> From: Andrew Draper To: "'Margaret Wasserman'" Cc: ipng@sunroof.eng.sun.com Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Wed, 2 Apr 2003 04:44:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing ... as presently defined. The ambiguity of the current site-local addresses will impact applications. We still need to solve the other problems (renumbering and disconnected sites) but we should do this using an addressing format which can be made transparent to applications. Andy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 05:17:53 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 h32DHqPL023074; Wed, 2 Apr 2003 05:17:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32DHqGS023073; Wed, 2 Apr 2003 05:17: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.9+Sun/8.12.9) with ESMTP id h32DHnPL023066 for ; Wed, 2 Apr 2003 05:17: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 h32DHvHP022615 for ; Wed, 2 Apr 2003 05:17:57 -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 GAA00889 for ; Wed, 2 Apr 2003 06:17: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; Wed, 2 Apr 2003 13:17: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, 2 Apr 2003 13:17:34 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, 2 Apr 2003 13:17:34 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; Wed, 2 Apr 2003 13:17:34 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 h32DHWOc028317; Wed, 2 Apr 2003 16:17:32 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h32DHWB2028313; Wed, 2 Apr 2003 16:17:32 +0300 Date: Wed, 2 Apr 2003 16:17:32 +0300 Message-Id: <200304021317.h32DHWB2028313@burp.tkv.asdf.org> From: Markku Savela To: jeroen@unfix.org CC: ipng@sunroof.eng.sun.com In-reply-to: <004001c2f912$619c5c80$210d640a@unfix.org> (jeroen@unfix.org) Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) References: <004001c2f912$619c5c80$210d640a@unfix.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Jeroen Massar" > Markku Savela [mailto:msa@burp.tkv.asdf.org] wrote: > > Despite claims of opposite, this combination works just fine. > > Example.com: fec0::/10 > Example.org: fec0::/10 > > Good luck in tossing the bits around to routers in between those sites > :) That would happen only if both sites merged into single site. If sites are just connected via global internet example.com example.org | Site-A --| | |---- INTERNET---| |-- Site-B If a host at example.com resolves xxx.example.org, it will not get fec0::/10 address as reply. It will get some global address of site-B. Yes, you need two-faced DNS, but again, this is standard practise today. Banning sitelocals will not kill two-faced DNS. However, a "merger", without global addresses and renumbering, would look as example.com example.org | Site-A --| | |--GW---| |-- Site-B Now, if site-A and site-b previously used different prefixes, like "fec0:site:aaaa" and "fec0:site:bbbb", then merger is trivial (GUPI, anyone?) However, if they used overlapping fec0:: prefixes, yes, simplest would be to renumber one of the sites. [Although, I could also make it work with overlapping addresses as is, but it does require a revision to the way name resolving is done--I have this implemented, but I would not expect everyone to do it. The solution does get a bit too complex to explain here. The solution is designed to handle multiple overlapping IPv4 private address spaces, so IPv6 sitelocal would be a no-brainer for it :-]. > Not even speaking about when you have internal webservers: > > www.example.com fec0::1 > www.example.org fec0::1 Well, unless sites are truly merged, accessing "internal" servers from another site is not supposed to happen anyway. > What you need is a globally unique /48 that is disconnected > and which one should be able to register 'cheaply'. Eg > an annual fee of E20 or something just to make sure that > not everybody starts harvesting them. Why should I pay anything? I have a small net at home with few hosts, but connected to the internet. I just pick some random address, for example starting with "fec0:/10".. :-). Big organisations do not need IPv6 at all. Their internal networks run quite happily using IPv4 private address spaces. As I said earlier, system admins wont allow globally routable addresses for the internal nodes anyway. IPv6 is needed by millions of private homes getting connected to the internet and needing global addresses. And, it is needed by millions of mobile phones that want to run E2E applications, which need global 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 Apr 2 05:36:59 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 h32DaxPL023390; Wed, 2 Apr 2003 05:36:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32DaxwG023389; Wed, 2 Apr 2003 05:36: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.9+Sun/8.12.9) with ESMTP id h32DatPL023382 for ; Wed, 2 Apr 2003 05:36: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 h32Db3cU021943 for ; Wed, 2 Apr 2003 05:37:03 -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 FAA17120 for ; Wed, 2 Apr 2003 05:36:57 -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, 2 Apr 2003 13:36: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; Wed, 2 Apr 2003 13:36: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, 2 Apr 2003 13:36:56 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, 2 Apr 2003 13:36:55 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 93B328F1C; Wed, 2 Apr 2003 15:36:32 +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 A26DA8B6F; Wed, 2 Apr 2003 15:36:26 +0200 (CEST) From: "Jeroen Massar" To: "'Markku Savela'" Cc: Subject: RE: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 15:37:25 +0200 Organization: Unfix Message-Id: <005001c2f91c$ffd7d2d0$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 In-Reply-To: <200304021317.h32DHWB2028313@burp.tkv.asdf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 h32DatPL023383 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela [mailto:msa@burp.tkv.asdf.org] wrote: > > From: "Jeroen Massar" > > Markku Savela [mailto:msa@burp.tkv.asdf.org] wrote: > > > Despite claims of opposite, this combination works just fine. > > > > Example.com: fec0::/10 > > Example.org: fec0::/10 > > > > Good luck in tossing the bits around to routers in between > those sites > > :) > > That would happen only if both sites merged into single site. If sites > are just connected via global internet > > > example.com example.org > | > Site-A --| | > |---- INTERNET---| > |-- Site-B > > > If a host at example.com resolves xxx.example.org, it will not get > fec0::/10 address as reply. It will get some global address of site-B. Global addresses, good, and where did you need a SL for again? > > Yes, you need two-faced DNS, but again, this is standard practise > today. Banning sitelocals will not kill two-faced DNS. They used to walk from europe to isreal for the crusades? Do you really think that current armies will walk all that way? Times change, so does the internet. Also why should 'banning' sitelocals 'kill' two-faced DNS? Two faced DNS is just a way of showing a specific namespace to a specific set of clients. Or for some people security through obscurity. > However, a "merger", without global addresses and renumbering, would > look as > > example.com example.org > | > Site-A --| | > |--GW---| > |-- Site-B > > Now, if site-A and site-b previously used different prefixes, like > "fec0:site:aaaa" and "fec0:site:bbbb", then merger is trivial (GUPI, > anyone?) And SL hasn't got any GUPI or unique addresses in it's current form. Thats why the *current* form should be deprecated and a better way for solving this kind of problem should be found out. > However, if they used overlapping fec0:: prefixes, yes, simplest would > be to renumber one of the sites. Have fun renumbering ;) > [Although, I could also make it work with overlapping addresses as is, > but it does require a revision to the way name resolving is done--I > have this implemented, but I would not expect everyone to do it. The > solution does get a bit too complex to explain here. The solution is > designed to handle multiple overlapping IPv4 private address spaces, > so IPv6 sitelocal would be a no-brainer for it :-]. Which breaks end-to-end connectivity. Where did you need SL for again? > > Not even speaking about when you have internal webservers: > > > > www.example.com fec0::1 > > www.example.org fec0::1 > > Well, unless sites are truly merged, accessing "internal" servers from > another site is not supposed to happen anyway. Then why merge in the first place? > > What you need is a globally unique /48 that is disconnected > > and which one should be able to register 'cheaply'. Eg > > an annual fee of E20 or something just to make sure that > > not everybody starts harvesting them. > > Why should I pay anything? I have a small net at home with few hosts, > but connected to the internet. I just pick some random address, for > example starting with "fec0:/10".. :-). Indeed 'just pick some random address' if you don't want to be connected to the rest of the world. No need for SL. Also E20 or a similar amount is peanuts compared to what it would cost if you need to renumber your complete site. > Big organisations do not need IPv6 at all. Their internal networks run > quite happily using IPv4 private address spaces. As I said earlier, > system admins wont allow globally routable addresses for the internal > nodes anyway. Great, if they don't need IPv6, where did we need SL for again? > IPv6 is needed by millions of private homes getting connected to the > internet and needing global addresses. And, it is needed by millions > of mobile phones that want to run E2E applications, which need global > addresses. Indeed global addresses. Where did the need for SL go again? Still no reason for keeping SL'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 Wed Apr 2 05:40: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 h32De5PL023464; Wed, 2 Apr 2003 05:40:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32De4H0023463; Wed, 2 Apr 2003 05:40: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.9+Sun/8.12.9) with ESMTP id h32De0PL023450 for ; Wed, 2 Apr 2003 05:40: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 h32De9HP026694 for ; Wed, 2 Apr 2003 05:40:09 -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 FAA06308 for ; Wed, 2 Apr 2003 05:40:03 -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, 2 Apr 2003 13:39:07 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, 2 Apr 2003 13:35: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; Wed, 2 Apr 2003 13:38:43 Z Received: from dhcp1.se.kurtis.pp.se ([194.230.196.70] [194.230.196.70]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 13:38:41 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 h32Dd5Wv003689; Wed, 2 Apr 2003 15:40:09 +0200 (CEST) Date: Wed, 2 Apr 2003 15:39:05 +0200 Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipng@sunroof.eng.sun.com To: Margaret Wasserman From: Kurt Erik Lindqvist In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Message-Id: <78C8012E-6510-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 -- Deprecate site-local unicast addressing - 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 Apr 2 05:49:02 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 h32Dn1PL023828; Wed, 2 Apr 2003 05:49:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32Dn1T8023826; Wed, 2 Apr 2003 05:49: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.9+Sun/8.12.9) with ESMTP id h32DmvPL023811 for ; Wed, 2 Apr 2003 05:48:57 -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 h32Dn5HP028555 for ; Wed, 2 Apr 2003 05:49:05 -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 GAA05781 for ; Wed, 2 Apr 2003 06:48: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; Wed, 2 Apr 2003 13:48: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; Wed, 2 Apr 2003 13:48: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; Wed, 2 Apr 2003 13:48:56 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; Wed, 2 Apr 2003 13:48:55 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 h32DmsOc028448; Wed, 2 Apr 2003 16:48:54 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h32Dms3C028444; Wed, 2 Apr 2003 16:48:54 +0300 Date: Wed, 2 Apr 2003 16:48:54 +0300 Message-Id: <200304021348.h32Dms3C028444@burp.tkv.asdf.org> From: Markku Savela To: jeroen@unfix.org CC: ipng@sunroof.eng.sun.com In-reply-to: <005001c2f91c$ffd7d2d0$210d640a@unfix.org> (jeroen@unfix.org) Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) References: <005001c2f91c$ffd7d2d0$210d640a@unfix.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Jeroen Massar" > > Global addresses, good, and where did you need a SL for again? Well, just for fun, I keep using SL for internal connections. One never knows when my global connection may break or change prefix, at a whim of ISP. Or maybe I have two ISP connections, one is cheaper during day, other cheaper during night, and I just alternate between them. > Indeed 'just pick some random address' if you don't want to > be connected to the rest of the world. No need for SL. > Also E20 or a similar amount is peanuts compared to what it > would cost if you need to renumber your complete site. Hmm.. maybe this could be my retirement job. Can I be the "registrar"?. It might be nice cash flow for very little work. > Indeed global addresses. Where did the need for SL go again? > > Still no reason for keeping SL's... Still, can keep them in spec as is. - nobody forces you to use SL's on your site, if you don't want. It's just an option for those who think they can take advantage of it. - applications do not need to care about them. They just SL's as any other address. - IPv6 stacks have already been impelmented based on scope addressing. There is the source address selection rules, also implemented. It hurts noone to keep the current spec AS IS. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 06:25: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 h32EPPPL024295; Wed, 2 Apr 2003 06:25:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32EPPFg024294; Wed, 2 Apr 2003 06:25: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 h32EPLPL024287 for ; Wed, 2 Apr 2003 06:25: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 h32EPTHP005820 for ; Wed, 2 Apr 2003 06:25: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 HAA12023 for ; Wed, 2 Apr 2003 07:25: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; Wed, 2 Apr 2003 14:25: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, 2 Apr 2003 14:22: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, 2 Apr 2003 14:25:22 Z Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [210.49.138.109]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 14:25:21 Z Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h32EP6ab004305; Thu, 3 Apr 2003 00:25:06 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h32EP5IC013324; Thu, 3 Apr 2003 00:25:05 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200304021425.h32EP5IC013324@drugs.dv.isc.org> To: "Jeroen Massar" Cc: "'Hiroki Ishibashi'" , "=?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?=" , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) In-reply-to: Your message of "Wed, 02 Apr 2003 13:02:35 +0200." <002101c2f907$6013c1b0$210d640a@unfix.org> Date: Thu, 03 Apr 2003 00:25:05 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mark.Andrews@isc.org wrote: > > > > Hiroki Ishibashi wrote: > > > > > > > There are plenty of potential ways to achieve this some of > > > > which include: > > > > * get a prefix for disconnected access from a ISP. > > > > * set up registries. > > > > > > These will definitely increase the cost of owning even disconnected > > > IPv6 networks. > > > > > > Hiroki Ishibashi > > > > TNSTAAFL > > > > RFC 1918 addresses cost real money to support. There are > > sacrificial machines that just serve reverse lookups for > > these addresses. They actually receive more traffic than > > the root servers. > > Fortunatly AS112 now catches these at some IX'es thus > lowering *transit* traffic. They still have to be caught and machines have to return NXDOMAIN. These machines are NOT being paid for by the people who are leaking the traffic. > > Put the costs of supporting disconnected / intermittently > > connected sites back on the sites that need this fuctionality. > > Having to lease a prefix will help cover the costs of > > supporting the reverse lookups on leaked lookups. > > If someone doesn't want/like this they can pick a random number > and use that, they still have to renumber when they interconnect > to another site or the internet. Well if they are not connected at all there is no costs to be bourn by eveyone else. > Greets, > Jeroen > > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 06:27: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 h32ERJPL024315; Wed, 2 Apr 2003 06:27:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32ERI5K024314; Wed, 2 Apr 2003 06: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h32ERFPL024307 for ; Wed, 2 Apr 2003 06:27:15 -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 h32ERMHP006288 for ; Wed, 2 Apr 2003 06:27:23 -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 HAA13276 for ; Wed, 2 Apr 2003 07:27: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, 2 Apr 2003 14:27: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, 2 Apr 2003 14:27: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, 2 Apr 2003 14:27:15 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; Wed, 2 Apr 2003 14:27:15 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 PAA23703 for ; Wed, 2 Apr 2003 15:27:05 +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 PAA13711 for ; Wed, 2 Apr 2003 15:27:05 +0100 (BST) Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h32ER5j09582 for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 15:27:05 +0100 Date: Wed, 2 Apr 2003 15:27:05 +0100 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) Message-Id: <20030402142705.GB30669@ecs.soton.ac.uk> References: <200304021317.h32DHWB2028313@burp.tkv.asdf.org> <005001c2f91c$ffd7d2d0$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005001c2f91c$ffd7d2d0$210d640a@unfix.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Apr 02, 2003 at 03:37:25PM +0200, Jeroen Massar wrote: > Indeed 'just pick some random address' if you don't want to > be connected to the rest of the world. No need for SL. > Also E20 or a similar amount is peanuts compared to what it > would cost if you need to renumber your complete site. > Think beyond corporate networks. SL does not lead to NAT but choosing random addresses *WILL*, consider: I setup an ad-hoc network using my laptop, wireless is 1 network and wired is a second, my laptop routes between them. There is no external connectivity and site-locals are deprecated so I pick a random prefix. Now somebody with a link to the wider world joins my network, since there is no guarantee that the prefix used on the ad-hoc network is not used on the internet you either have to nat outgoing traffic or re-number the network. You have repeatedly slated re-numbering, and it seems un-feasible in an ad-hoc network anyway so the only choice left is NAT. If the network was numbered using site-locals all you don't need to re-number, just advertise an additional prefix. Yes, applications would need to be made to use the global prefix, we need a way of enforcing this - a simple method could be that the O/S simply deprecates the site-local prefix. If you only consider that Site-locals will ever be deployed in a "normal" network then the deprecation question is easy (yes deprecate them), however I thought that one of the advantages of v6 was that it gives better support for the a-typical network. I dont think some organisation allocating private prefixes is viable either, ad-hoc means exactly that, I don't want to be manually entering my unique private prefix. How about using fec0:::/64? That gives a (probably) private network per interface, the only issue is that you wouldn't be able to aggregate them in a sizeable network - however I agree that site-locals shouldn't be used in such a scenario. :) 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 Apr 2 06:33: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 h32EXbPL024760; Wed, 2 Apr 2003 06:33:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32EXbQB024759; Wed, 2 Apr 2003 06:33: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 h32EXXPL024743 for ; Wed, 2 Apr 2003 06:33:33 -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 h32EXfHP008016 for ; Wed, 2 Apr 2003 06:33:41 -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 GAA10465 for ; Wed, 2 Apr 2003 06:33: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; Wed, 2 Apr 2003 14:33: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; Wed, 2 Apr 2003 14:30:05 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, 2 Apr 2003 14:33:17 Z Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 14:33:16 Z Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h32ETW15007308; Wed, 2 Apr 2003 07:29:32 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA02811; Wed, 2 Apr 2003 07:29:32 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h32ETRj15693; Wed, 2 Apr 2003 08:29:27 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 001582EC86; Wed, 2 Apr 2003 16:29:25 +0200 (CEST) Message-Id: <3E8AF3C5.9020806@nal.motlabs.com> Date: Wed, 02 Apr 2003 16:29:25 +0200 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter Cc: , , Subject: Re: Outlawing (Avoiding) NAT with IPv6 References: <07a201c2f7d7$157391c0$ee1a4104@eagleswings> <3E897DE0.85A84EED@hursley.ibm.com> <3E8AD961.9050006@nal.motlabs.com> In-Reply-To: <3E8AD961.9050006@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alexandru Petrescu wrote: > Brian E Carpenter 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. >> >> Actually not, if you have a domestic /48 or /64 prefix. But the >> MobileIP solution looks OK. > > Looks but doesn't act like really providing location privacy, IMHO. I meant HMIPv6 providing location privacy is dubitable (I was not referring to Mobile IPv6). Alex GBU -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 06:42:49 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 h32EgnPL025365; Wed, 2 Apr 2003 06:42:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32Egnfm025364; Wed, 2 Apr 2003 06:42: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.9+Sun/8.12.9) with ESMTP id h32EgjPL025357 for ; Wed, 2 Apr 2003 06:42: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 h32EgrcU009265 for ; Wed, 2 Apr 2003 06:42:54 -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 HAA04022 for ; Wed, 2 Apr 2003 07:42: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; Wed, 2 Apr 2003 14:42: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; Wed, 2 Apr 2003 14:42: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, 2 Apr 2003 14:42:45 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, 2 Apr 2003 14:42:44 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id B44E28F1E; Wed, 2 Apr 2003 16:42:40 +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 8F6CC8F17; Wed, 2 Apr 2003 16:42:35 +0200 (CEST) From: "Jeroen Massar" To: "'Markku Savela'" Cc: Subject: RE: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 16:43:29 +0200 Organization: Unfix Message-Id: <005a01c2f926$3a3524b0$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 In-Reply-To: <200304021348.h32Dms3C028444@burp.tkv.asdf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 h32EgkPL025358 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela [mailto:msa@burp.tkv.asdf.org] wrote: > > From: "Jeroen Massar" > > > > Global addresses, good, and where did you need a SL for again? > > Well, just for fun, I keep using SL for internal connections. One > never knows when my global connection may break or change prefix, at a > whim of ISP. Or maybe I have two ISP connections, one is cheaper > during day, other cheaper during night, and I just alternate between > them. Great example for a use of multihoming. Also who says your prefix becomes 'instable' when you swap it from the night to the day ISP? Also if you swap your ISP without multihoming it will break connections to the rest of the internet, read: rest of -> non site local. I don't see the need for site-local here either. I do see the need for PI/multihoming though. Maybe you are mixing 'global' a /48 (site-global :) with site-locals? > > Indeed 'just pick some random address' if you don't want to > > be connected to the rest of the world. No need for SL. > > Also E20 or a similar amount is peanuts compared to what it > > would cost if you need to renumber your complete site. > > Hmm.. maybe this could be my retirement job. Can I be the > "registrar"?. It might be nice cash flow for very little work. It could be indeed, go set it up. Why do you think that the domainname business is so good? Virtual money for virtual bits! Thats why there has been so much contraversy. But some entity needs to regulate it. Also you 'rent' the domainnames/space, you do not own it. > > Indeed global addresses. Where did the need for SL go again? > > > > Still no reason for keeping SL's... > > Still, can keep them in spec as is. > > - nobody forces you to use SL's on your site, if you don't want. It's > just an option for those who think they can take advantage of it. True, bad it is also a bad option that will cause many problems. You might see the problems ahead but $manager won't. And that's why there needs to be a replacement for this. > - applications do not need to care about them. They just SL's as any > other address. That would be a good thing. But how are you solving the: AL talks to BL and B passes A's address to CG case? Or are you talking about completely disconnected sites again? > - IPv6 stacks have already been impelmented based on scope > addressing. There is the source address selection rules, also > implemented. It hurts noone to keep the current spec AS IS. See the case above and the numberous of other problems presented througout the thread and in the presentations. 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 Apr 2 06:58: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 h32EwTPL025787; Wed, 2 Apr 2003 06:58:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32EwT0T025786; Wed, 2 Apr 2003 06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h32EwPPL025779 for ; Wed, 2 Apr 2003 06:58: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 h32EwXcU012935 for ; Wed, 2 Apr 2003 06:58: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 GAA27997 for ; Wed, 2 Apr 2003 06:58: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; Wed, 2 Apr 2003 14:58:27 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, 2 Apr 2003 14:58: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; Wed, 2 Apr 2003 14:58:23 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, 2 Apr 2003 14:58:22 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 2455C8F1E; Wed, 2 Apr 2003 16:58:19 +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 061878B6F; Wed, 2 Apr 2003 16:58:13 +0200 (CEST) From: "Jeroen Massar" To: "'Mike Saywell'" , Subject: RE: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 16:59:06 +0200 Organization: Unfix Message-Id: <006201c2f928$6933dd90$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 In-Reply-To: <20030402142705.GB30669@ecs.soton.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 h32EwQPL025780 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike Saywell wrote: > On Wed, Apr 02, 2003 at 03:37:25PM +0200, Jeroen Massar wrote: > > Indeed 'just pick some random address' if you don't want to > > be connected to the rest of the world. No need for SL. > > Also E20 or a similar amount is peanuts compared to what it > > would cost if you need to renumber your complete site. You accidentally cut out the following lines from the reply above this one which does make a big difference in the rest of the context: > > What you need is a globally unique /48 that is disconnected > > and which one should be able to register 'cheaply'. Eg > > an annual fee of E20 or something just to make sure that > > not everybody starts harvesting them. > Think beyond corporate networks. > > SL does not lead to NAT but choosing random addresses *WILL*, > consider: > > I setup an ad-hoc network using my laptop, wireless is 1 network and > wired is a second, my laptop routes between them. There is > no external connectivity and site-locals are deprecated so I pick > a random prefix. This looks like a typical house style network... just like mine except that I got a machine which gates these two nets to the internet just like you explain in: > Now somebody with a link to the wider world joins my network, > since there is no guarantee that the prefix used on the ad-hoc > network is not used on the internet you either have to nat > outgoing traffic or re-number the network. > You have repeatedly slated re-numbering, and it seems > un-feasible in an ad-hoc network anyway so the only choice left is NAT. Announce the new prefix, deprecate the old prefix done. Small networks don't really care about having to edit a couple of places where hosts<->ip are registered which should quite probably only be DNS and a single firewalling place. That's the joy of small non-corporate networks. For SOHO usage this will boil down to a click-and-pray interface. > If the network was numbered using site-locals all you don't need to > re-number, just advertise an additional prefix. And why can't you just advertise an additional prefix when having some space that is globally unique and private as that's where it is registered for (see the text above that was cut away :) ? > Yes, applications would need to be made to use the global prefix, we > need a way of enforcing this - a simple method could be that the O/S > simply deprecates the site-local prefix. What I stated above. > If you only consider that Site-locals will ever be deployed > in a "normal" network then the deprecation question is easy > (yes deprecate them), however I thought that one of the > advantages of v6 was that it gives better support for the a-typical network. Name these a-typical networks. Otherwise there can be no cases for them. I do still like the boat case :) > I dont think some organisation allocating private prefixes is viable > either, ad-hoc means exactly that, I don't want to be manually entering > my unique private prefix. You have to enter a site local prefix too. Whats the difference in entering a unique prefix or typing in 10.0.0.0/8 again? Most people will want to connect to the internet. So especially for SOHO cases they will be connected to the internet. Their ISP will provide them with a /48 either through router advertisements or using the old fashion paper way. SOHO routers will simply ask "please enter the prefix as stated on the paper" and done. We are fortunatly taling SOHO here and > How about using fec0:::/64? That gives a (probably) private > network per interface, the only issue is that you wouldn't be able to > aggregate them in a sizeable network - however I agree that > site-locals shouldn't be used in such a scenario. :) Hmmm that does sounds like a good idea for an alternative. It does indeed overcome the 'registry' problem and the fact that it should be globally unique. Except that one would rather use EUI-64 instead of the MAC address. But that's ofcourse debatable. I would rather see use of the fec0::/10 in a way like this than with every sole person using fec0::80 for their home webserver... 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 Apr 2 06:58:53 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 h32EwrPL025807; Wed, 2 Apr 2003 06:58:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32EwrvN025806; Wed, 2 Apr 2003 06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h32EwkPL025789 for ; Wed, 2 Apr 2003 06:58: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 h32EwscU013030 for ; Wed, 2 Apr 2003 06:58: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-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28243 for ; Wed, 2 Apr 2003 06:58:49 -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, 2 Apr 2003 14:58: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; Wed, 2 Apr 2003 14:58: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; Wed, 2 Apr 2003 14:58:48 Z Received: from cvx1.noc.east.ntt.co.jp ([210.163.32.76] [210.163.32.76]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 14:58:47 Z Received: from cmix2.noc.east.ntt.co.jp by cvx1.noc.east.ntt.co.jp with ESMTP id h32EwjQ11136; Wed, 2 Apr 2003 23:58:45 +0900 (JST) Received: from smtp.rdc.east.ntt.co.jp by cmix2.noc.east.ntt.co.jp with ESMTP id h32EwjY08006; Wed, 2 Apr 2003 23:58:45 +0900 (JST) Received: from wataru2k01.rdc.east.ntt.co.jp by smtp.rdc.east.ntt.co.jp (8.9.3/3.7W) id XAA21709; Wed, 2 Apr 2003 23:58:44 +0900 (JST) Message-Id: <200304021458.AA00642@wataru2k01.rdc.east.ntt.co.jp> Date: Wed, 02 Apr 2003 23:58:19 +0900 To: ipng@sunroof.eng.sun.com Subject: Site local address issues. From: Wataru Kawakami - Merely one user of IPv6 MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.13 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear colleage; Notice: I'm posting here, to say comments, as merely one user of IPv6. -- Currently, ``NO - Do NOT Deprecate Site-Local Addressing.'' -- Just my feelings follows; -- Site-Local address seems to be the nearest candidate to be used as ``local'' (locally used without interconnection to the Internet) address. (In IPv4, so called ``private address'') ``Local'' address is quite useful tool for operators of enterprise's network to provide good security for the users within the enterprise's network. In old days, I've heard that IPv4 global address was used as ``local'' address, undergroundly, before RFC-1918 was made. Deprecate of Site-Local Address without defining alternative for ``private'' address, in previous, may cause the history to rewind again. May turn to ``Yes'', if any *private* address block is defined as RFC *before* deprecate of Site-Local Address, and the *block* could be used freely, as RFC-1918 in IPv4 world. Just my comments follows; -- It is quite *hopeless* that ISPes will deliver ``private address'' for users, without fee. At IPv4 world, to my poor understanding, ordinary ISP may not assign me any global address, if I'm not the customer of the ISP. -- Wataru Kawakami, Japan. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 07:28: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 h32FShPL026571; Wed, 2 Apr 2003 07:28:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32FShqE026570; Wed, 2 Apr 2003 07:28: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 h32FSePL026563 for ; Wed, 2 Apr 2003 07:28:40 -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 h32FSmcU020720 for ; Wed, 2 Apr 2003 07:28:48 -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 IAA26438 for ; Wed, 2 Apr 2003 08:28:42 -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, 2 Apr 2003 15:28:42 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, 2 Apr 2003 15:28:22 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, 2 Apr 2003 15:28:22 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; Wed, 2 Apr 2003 15:28:21 Z Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h32FSJn19967 for ; Wed, 2 Apr 2003 10:28:20 -0500 (EST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id <1H3TW7ZX>; Wed, 2 Apr 2003 09:28:19 -0600 Message-Id: From: "Fischer, Christine A (Chris)" To: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Wed, 2 Apr 2003 09:28:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing". from: Chris Fischer Lucent Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 07:33: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 h32FXfPL026725; Wed, 2 Apr 2003 07:33:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32FXf2r026724; Wed, 2 Apr 2003 07:33: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.9+Sun/8.12.9) with ESMTP id h32FXbPL026714 for ; Wed, 2 Apr 2003 07:33:37 -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 h32FXjHP022087 for ; Wed, 2 Apr 2003 07:33:45 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA19343 for ; Wed, 2 Apr 2003 08:33:39 -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, 2 Apr 2003 15:33: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, 2 Apr 2003 15:30: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, 2 Apr 2003 15:33:37 Z Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 15:33:37 Z Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h32FXYr07511; Wed, 2 Apr 2003 10:33:34 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id h32FXWr90057; Wed, 2 Apr 2003 10:33:32 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id KAA21486; Wed, 2 Apr 2003 10:33:31 -0500 (EST) Subject: Re: What is a site local address? [Re: CONSENSUS CALL: DeprecatingSite-Local Addressing] From: Steven Blake Reply-To: steven.blake@ericsson.com To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3E8AA231.C4992A71@hursley.ibm.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> <1049232974.20706.1409.camel@newcastle.torrentnet.com> <3E8AA231.C4992A71@hursley.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 02 Apr 2003 10:33:31 -0500 Message-Id: <1049297611.20706.1444.camel@newcastle.torrentnet.com> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2003-04-02 at 03:41, Brian E Carpenter wrote: > As I already said under another subject line, > what I understood we were deprecating is SL as defined > in the current address architecture, i.e. FEC0::/10. Do you mean the e-mail where you said the following? --> I prefer to think about this the other way round: kill the ambiguous --> space, which we have learnt the hard way is a mistake, and then --> design the alternative, which may well be unrouteable GUPI (and for --> all I care, starts with FEC::/10). > That's the only formal definition of SL, so I don't see > what else we could be referring to. Well, I'm still confused. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 07:36:10 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 h32FaAPL026911; Wed, 2 Apr 2003 07:36:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32FaA64026910; Wed, 2 Apr 2003 07:36: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.9+Sun/8.12.9) with ESMTP id h32Fa6PL026897 for ; Wed, 2 Apr 2003 07:36:06 -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 h32FaEHP022663 for ; Wed, 2 Apr 2003 07:36:14 -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 IAA01538 for ; Wed, 2 Apr 2003 08:36:08 -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, 2 Apr 2003 15:36:07 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, 2 Apr 2003 15:35:35 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, 2 Apr 2003 15:35:35 Z Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 15:35:34 Z Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id A1C717B488; Wed, 2 Apr 2003 10:35:33 -0500 (EST) Received: from internet2.edu (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 4F3E67B473; Wed, 2 Apr 2003 10:35:32 -0500 (EST) Message-Id: <3E8B0344.9DE908A4@internet2.edu> Date: Wed, 02 Apr 2003 08:35:32 -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: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> 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 > "YES -- Deprecate site-local unicast addressing". Ambiguous addresses are a nightmare... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 07:58:22 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 h32FwLPL027645; Wed, 2 Apr 2003 07:58:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32FwLp2027644; Wed, 2 Apr 2003 07:58: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 h32FwIPL027637 for ; Wed, 2 Apr 2003 07:58:18 -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 h32FwQHP028718 for ; Wed, 2 Apr 2003 07:58:26 -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 IAA24691 for ; Wed, 2 Apr 2003 08:58:20 -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, 2 Apr 2003 15:58: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, 2 Apr 2003 15:58: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, 2 Apr 2003 15:58: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; Wed, 2 Apr 2003 15:58:19 Z Content-class: urn:content-classes:message Subject: RE: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Apr 2003 07:58:17 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F716@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: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing Thread-Index: AcL48ArY2sM1JuGZTWe3ksmtcyTwmgAP/htw From: "Michel Py" To: "Brian Carpenter" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h32FwIPL027638 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Brian E Carpenter wrote: > What I raised my hand for in San Francisco was to > deprecate SL addresses as currently defined in > draft-ietf-ipngwg-addr-arch-v3-11.txt (and in RFC 2373). This has never been stated and you can expect appeals all the way to the supreme court and I'll be supporting them. This is not an editorial change but a significant architectural change. I am tired of last-minute attempts to pull documents that have been approved for publication. Brian, I have the greatest respect for you but this is not to your credit. 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 Apr 2 08:05: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 h32G58PL027799; Wed, 2 Apr 2003 08:05:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32G58Hw027798; Wed, 2 Apr 2003 08:05: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 h32G55PL027791 for ; Wed, 2 Apr 2003 08:05:05 -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 h32G5DHP000836 for ; Wed, 2 Apr 2003 08:05:13 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA15770 for ; Wed, 2 Apr 2003 09:05:07 -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, 2 Apr 2003 16:05: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; Wed, 2 Apr 2003 16:05: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, 2 Apr 2003 16:05: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; Wed, 2 Apr 2003 16:05: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: Wed, 2 Apr 2003 08:05:04 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F717@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: AcL5FYB+cR5Ola1wS5KJBnohCKORYAAG6MNA From: "Michel Py" To: "Brian Carpenter" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h32G55PL027792 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Brian E Carpenter wrote: > Exactly. It was the present incarnation, not some > possible future incarnation, that I raised my hand > against. Really? By trying to sneak a major architectural change into a last 24 hour "editorial" change? I am going to file an appeal about how this entire situation was handled on the first place. What kind of work is that? Gathering consensus on a text that nobody has seen because it does not exist yet? This consensus has no value and I will now push this issue all the way to the top. 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 Apr 2 08:06:14 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 h32G6DPL027836; Wed, 2 Apr 2003 08:06:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32G6DgL027835; Wed, 2 Apr 2003 08:06: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.9+Sun/8.12.9) with ESMTP id h32G6APL027828 for ; Wed, 2 Apr 2003 08:06:10 -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 h32G6IHP001259 for ; Wed, 2 Apr 2003 08:06:18 -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 IAA27355 for ; Wed, 2 Apr 2003 08:06:12 -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, 2 Apr 2003 16:06: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; Wed, 2 Apr 2003 16:06: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; Wed, 2 Apr 2003 16:06: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; Wed, 2 Apr 2003 16:06: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 RAA24984 for ; Wed, 2 Apr 2003 17:06:09 +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 RAA21427 for ; Wed, 2 Apr 2003 17:06:08 +0100 (BST) Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h32G68A13759 for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 17:06:08 +0100 Date: Wed, 2 Apr 2003 17:06:08 +0100 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) Message-Id: <20030402160608.GD30669@ecs.soton.ac.uk> References: <20030402142705.GB30669@ecs.soton.ac.uk> <006201c2f928$6933dd90$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006201c2f928$6933dd90$210d640a@unfix.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Apr 02, 2003 at 04:59:06PM +0200, Jeroen Massar wrote: > Mike Saywell wrote: > > I setup an ad-hoc network using my laptop, wireless is 1 network and > > wired is a second, my laptop routes between them. There is > > no external connectivity and site-locals are deprecated so I pick > > a random prefix. > > This looks like a typical house style network... just like mine > except that I got a machine which gates these two nets to the internet > just like you explain in: No I meant it's an ad-hoc network where devices want to communicate ones *before* there is a global prefix. > Announce the new prefix, deprecate the old prefix done. Not that simple really... The first prefix was advertised by my laptop, the true global one is advertised by e.g. a mobile phone. What if the phone then leaves? Renumber again? Deprecating isn't good enough either you need to totally remove the prefix otherwise the hosts will still consider the prefix on-link. > Small networks don't really care about having to edit a couple > of places where hosts<->ip are registered which should quite > probably only be DNS and a single firewalling place. If it's a home user they might mind (or not know how!)... > > I dont think some organisation allocating private prefixes is viable > > either, ad-hoc means exactly that, I don't want to be manually > entering > > my unique private prefix. > > You have to enter a site local prefix too. Not if the ad-hoc routing protocol assigns/negotiates one... 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 Apr 2 08:06: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 h32G6RPL027855; Wed, 2 Apr 2003 08:06:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32G6QPg027854; Wed, 2 Apr 2003 08:06: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.9+Sun/8.12.9) with ESMTP id h32G6JPL027842 for ; Wed, 2 Apr 2003 08:06:19 -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 h32G6RcU001372 for ; Wed, 2 Apr 2003 08:06:27 -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 JAA23098 for ; Wed, 2 Apr 2003 09:06:21 -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, 2 Apr 2003 16:06: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, 2 Apr 2003 16:06: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, 2 Apr 2003 16:06:20 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, 2 Apr 2003 16:06:20 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: Wed, 2 Apr 2003 08:06:19 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F5045657@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: AcL5FYB+cR5Ola1wS5KJBnohCKORYAAHCVUA From: "Michel Py" To: "Brian Carpenter" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h32G6KPL027846 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Brian E Carpenter wrote: > Exactly. It was the present incarnation, not some > possible future incarnation, that I raised my hand > against. I would like to hear what Steve Deering, as author, has to say about all of this too. 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 Apr 2 08:14: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 h32GEoPL028549; Wed, 2 Apr 2003 08:14:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32GEoch028548; Wed, 2 Apr 2003 08:14: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 h32GElPL028538 for ; Wed, 2 Apr 2003 08:14: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 h32GEtHP003898 for ; Wed, 2 Apr 2003 08:14: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 JAA06996 for ; Wed, 2 Apr 2003 09:14: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; Wed, 2 Apr 2003 16:14:35 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, 2 Apr 2003 16:14: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; Wed, 2 Apr 2003 16:14:35 Z Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 16:14:35 Z Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 086217B4A6; Wed, 2 Apr 2003 11:14:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 1E1B87B488; Wed, 2 Apr 2003 11:14:32 -0500 (EST) To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> From: stanislav shalunov Date: 02 Apr 2003 11:14:26 -0500 In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Message-Id: <8765pw7u71.fsf@cain.internet2.edu> Lines: 6 X-Mailer: Gnus v5.7/Emacs 20.4 X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Most people can do nothing at all well. -- G. H. Hardy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 08:15: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 h32GFePL028614; Wed, 2 Apr 2003 08:15:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32GFel2028613; Wed, 2 Apr 2003 08:15: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 h32GFaPL028606 for ; Wed, 2 Apr 2003 08:15: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 h32GFicU004479 for ; Wed, 2 Apr 2003 08:15:44 -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 JAA00116 for ; Wed, 2 Apr 2003 09:15: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; Wed, 2 Apr 2003 16:15: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, 2 Apr 2003 16:12: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, 2 Apr 2003 16:15:36 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 16:15:36 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 02 Apr 2003 08:15:27 -0800 Reply-To: From: "Tony Hain" To: "'Brian E Carpenter'" , , Subject: RE: alternatives to site-locals? (Re: CONSENSUS CALL: DeprecatingSite-Local Addressing) Date: Wed, 2 Apr 2003 08:15:24 -0800 Message-Id: <098b01c2f933$11bca820$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: <3E8A9768.7EE57527@hursley.ibm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > > > > What was the consensus, if any, on alternatives to > site-locals when SL > > is deprecated? > > As I've already said, I think that is the wrong order of discussion. > > I think we should clear the desktop first, by getting rid of > ambiguous site-local address space, and then discuss possible > new solutions. > > We've been going round in circles for months, and we need to > stop that. And many feel that deprecating without a solution in hand is the wrong order. A solution in hand has considerably more value than a promise from a group that refuses to acknowledge that some of the goals of network managers are valid. 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 Apr 2 08:21: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 h32GLoPL029142; Wed, 2 Apr 2003 08:21:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32GLoxn029141; Wed, 2 Apr 2003 08:21: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 h32GLkPL029131 for ; Wed, 2 Apr 2003 08:21:46 -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 h32GLsHP006693 for ; Wed, 2 Apr 2003 08:21:54 -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 IAA28566 for ; Wed, 2 Apr 2003 08:21:48 -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, 2 Apr 2003 16:21: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; Wed, 2 Apr 2003 16:21: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; Wed, 2 Apr 2003 16:21:47 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 16:21:46 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 02 Apr 2003 08:21:44 -0800 Reply-To: From: "Tony Hain" To: "'Jeroen Massar'" , , "'Hiroki Ishibashi'" Cc: "'JINMEI Tatuya / _-¾'BÆ'" , Subject: RE: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 08:21:41 -0800 Message-Id: <098c01c2f933$f27d4720$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: <002101c2f907$6013c1b0$210d640a@unfix.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeroen Massar wrote: > ... > If someone doesn't want/like this they can pick a random > number and use that, they still have to renumber when they > interconnect to another site or the internet. Renumbering in an IPv6 context means adding a prefix. Unlike IPv4 it does not mean removing the existing one. There is no reason for a site that connects to have to renumber nodes that are not going to use the external connection. Get out of the IPv4 mindset. 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 Apr 2 08:26: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 h32GQ7PL029372; Wed, 2 Apr 2003 08:26:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32GQ7gY029371; Wed, 2 Apr 2003 08:26: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.9+Sun/8.12.9) with ESMTP id h32GQ3PL029364 for ; Wed, 2 Apr 2003 08:26:03 -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 h32GQBcU008206 for ; Wed, 2 Apr 2003 08:26:11 -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 JAA28558 for ; Wed, 2 Apr 2003 09:26: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; Wed, 2 Apr 2003 16:26: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; Wed, 2 Apr 2003 16:22: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; Wed, 2 Apr 2003 16:25:59 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 16:25:58 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 02 Apr 2003 08:25:55 -0800 Reply-To: From: "Tony Hain" To: "'Jeroen Massar'" , "'Brian McGehee'" Cc: Subject: RE: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 08:25:52 -0800 Message-Id: <098d01c2f934$886e97c0$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: <003801c2f911$7393c6e0$210d640a@unfix.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h32GQ4PL029365 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeroen Massar wrote: > Brian McGehee [mailto:doc@albert.tavian.com] wrote: > > > *Notes below > > > > * I agree "NAT != SL"! Except in the case that hosts need "global" > > connectivity and they ONLY have a SL address will require > > NAT. Or they should have a second IPv6 globally unique unicast > address > > (which isn't that hard to have multiple addresses???) > > Use a firewall to block incoming packets. Brian is right, having a second prefix is what they should do. > > > * I can envision an enterprise environment that is > comfortable using > > FEC0::/10 for internal communications but a host has a > globally unique > > address also for external communications (on hosts that have this > > neccessity) This could be comfortable to a network admin/ops/noc. > > Then don't route a certain prefix. Using filtering on a single global prefix does not work when nodes that need external access are on the same segment with those that shouldn't have it. Prefix filtering is the answer, but the prefix to filter is FEC0::/10. Tony > > > ----- Original Message ----- > > From: "Jeroen Massar" > > To: "'Brian McGehee'" ; > > > > Sent: Wednesday, April 02, 2003 2:53 AM > > Subject: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local > > Addressing) > > > > > > > Brian McGehee write: > > > > > > > NO -- Do not deprecate site-local unicast addressing > > > > > > > > - Site-locals should be retained for disconnected > sites. If not > > > > SL, then a mechanism needs to be adopted that can provide a > > private means of > > > > selecting from a private address space that is > "reserved" for this > > > > function. 2002 is not a working alternative. > > > > - Site-locals should be retained for intermittently > > connected sites. > > > > - Site-locals should be retained as a means for internal > > > > connections to survive global prefix renumbering. > > > > > > All of the above will make the address not unique. > > > Have fun merging your networks. > > > > * Anyone that has had to merge 2 very large networks will > > know the great amount of design, architecture, and planning > > that has to go into such a project. It's not as easy as > > changing "a DHCP range" or a "handful of RAs" even if they > > were Globally unique IPv6 (or globally unique IPv4 addresses). > > I agree that IPv6 stateless Auto-Config adds a lot of room to > > make this an easier process but it doesn't solve the unique > > problems that come up in merging two large enterprise networks. > > If they are globally unique, one doesn't HAVE to renumber. > And indeed the problems of renumbering lie in configuration > items not in the network numbering itself. > > > * Yes. There is the chance that SL will "overlap" in a > > situation of merging two IPv6 enterprise networks. > > But if we don't offer SL. What will people > > choose for private addressing? I would REALLY like to see an > > alternative to SL that maybe provides for a set of bits that > > relate to Geography? ISP? > > etc? I'm open to other suggestions. But without an > > alternative I have to vote "NO". Let's see some alternatives? > > Please, again!=> Let's not alienate those that are already > > afraid of change by "changing" things. > > A central registry where one can obtain unique disconnected > space per /48. > > > > > - Other (please specify). Continually changing the specs > > will only > > > > further alienate those that refuse to adopt. Not offering > > > > equivalents to what exists today (rfc 1918) will > > accomplish the same. > > > > (and do we really want to put all the NAT vendors out of > > business? > > > ;-) > > > > "Necessity drives ingenuity." > > > > > > Here you are already levelling NAT with SL. > > > If you already intend to NAT, stay with IPv4, you will > have the same > > > problems and still won't get back the end to end > connectivity which > > > was one of the major things IPv6 was built for. Or we > could just do > > > IPv6 with 32bits again... > > > > * Yes if anyone chooses to do NAT. They should have that > > option, and an IPv6 address space to appropriately use for > > such functionality [it's a feature, not a bug](some people > > feel strongly that NAT is a security feature). > > If you intend to do it then just stay with IPv4 without > end-to-end connectivity and don't drag down the rest of us. > > > * Again we shouldn't "take away" from what is already there. > > From what people are comfortable with! I am not a proponent > > of NAT (bottlenecking, added administration, etc...) but we > > need to continue to support environments that exists today. > > If a company decides to incorporate NAT in their firewall(s) > > "Look mom he said NAT and firewall in one sentence" > > > (or even NAT-PT/NAPT-PT), well let's let them! We've > introduced these > > ideas in IPv4, they exist today. > > They didn't pay with money a very long time ago. > Should we now all go exchange eggs, chicken and wild > beast again as a currency? > > That's called evolution. There is no need for NAT which > is apparently the sole reason you want SL. > > > The current "IPv6 RFC's" and "IPv6 literature" document > this continued > > support clearly (FEC0::/10). > > And people have realized that it was a mistake and want to > clear that mistake up before it starts to hurt hard. > > > Constantly changing the standards scares "people" away from > > adoption. Do we really want to make such a drastic change. > > (I'm still trying to deal w/ the deprecation of A6 records. > > They worked GREAT in renumbering!) > > If you have a real use for A6, just like A6, then document > it and bring it forward, thats where these WG's are all about. > > > Yes. IPv6 offers 340 undecillion (or sextillion depending > > on where your from) addresses. Enough to address every > device in the > > world. > > Indeed so where did we need SL for again? To NAT???? > > > Great. But we need to offer all the functionality that > exists today. > > They exist for reason (besides just lack of address space. > > And which reasons where that again, I don't recall you > mentioning ANY reason here that doesn't relate to NAT. Again, > if you want NAT, then stick to IPv4. > > > Some people feel secure/comfortable behind NAT!) > > ...my $.02 > > You should not feel secure behind a NAT. NAT has nothing > to do with security. Not routing a prefix somehow has though. > > Apparently you have no other need for SL than to NAT. > I rest my case. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 08:31: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 h32GVUPL029661; Wed, 2 Apr 2003 08:31:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32GVUFD029660; Wed, 2 Apr 2003 08:31: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 h32GVQPL029650 for ; Wed, 2 Apr 2003 08:31:27 -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 h32GVYcU010105 for ; Wed, 2 Apr 2003 08:31:34 -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.3p2+Sun/8.9.3) with ESMTP id JAA10465 for ; Wed, 2 Apr 2003 09:31: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, 2 Apr 2003 16:31: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; Wed, 2 Apr 2003 16:31: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, 2 Apr 2003 16:31:25 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, 2 Apr 2003 16:31:25 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 0B7C78F2F; Wed, 2 Apr 2003 18:31:14 +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 0BC4C8F19; Wed, 2 Apr 2003 18:31:09 +0200 (CEST) From: "Jeroen Massar" To: , "'Brian McGehee'" Cc: Subject: RE: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 18:31:59 +0200 Organization: Unfix Message-Id: <009c01c2f935$63560580$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 In-Reply-To: <098d01c2f934$886e97c0$ee1a4104@eagleswings> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 h32GVRPL029651 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain [mailto:alh-ietf@tndh.net] wrote: > Jeroen Massar wrote: > > Brian McGehee [mailto:doc@albert.tavian.com] wrote: > > > > > *Notes below > > > > > > * I agree "NAT != SL"! Except in the case that hosts > need "global" > > > connectivity and they ONLY have a SL address will require > > > NAT. Or they should have a second IPv6 globally unique unicast > > address > > > (which isn't that hard to have multiple addresses???) > > > > Use a firewall to block incoming packets. > > Brian is right, having a second prefix is what they should do. Could do, it's another solution to their problem. > > > * I can envision an enterprise environment that is > > comfortable using > > > FEC0::/10 for internal communications but a host has a > > globally unique > > > address also for external communications (on hosts that have this > > > neccessity) This could be comfortable to a network admin/ops/noc. > > > > Then don't route a certain prefix. > > Using filtering on a single global prefix does not work when > nodes that > need external access are on the same segment with those that shouldn't > have it. Prefix filtering is the answer, but the prefix to filter is > FEC0::/10. Any rationale why it should be fec0::/10 and not just a prefix picked by the administrator from the /48 they already have? Firewalling is firewalling, even if one filters fec0::/10 or 2001:db8::/32 it doesn't change a bit in implementation or use. 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 Apr 2 08:35: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 h32GZZPL029885; Wed, 2 Apr 2003 08:35:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32GZZ4m029884; Wed, 2 Apr 2003 08:35: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.9+Sun/8.12.9) with ESMTP id h32GZVPL029877 for ; Wed, 2 Apr 2003 08:35: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 h32GZdcU011596 for ; Wed, 2 Apr 2003 08:35:39 -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 JAA03631 for ; Wed, 2 Apr 2003 09:35:31 -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, 2 Apr 2003 16:35:29 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, 2 Apr 2003 16:35: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; Wed, 2 Apr 2003 16:35:28 Z Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 16:35:27 Z Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h32GYtau016304 for ; Wed, 2 Apr 2003 09:34:56 -0700 (MST) Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA20569 for ; Wed, 2 Apr 2003 09:35:25 -0700 (MST)] Received: from motorola.com (mvp-10-238-2-16.corp.mot.com [10.238.2.16]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h32GZMF17975 for ; Wed, 2 Apr 2003 10:35:22 -0600 Message-Id: <3E8B1148.C62895A@motorola.com> Date: Thu, 03 Apr 2003 02:35:20 +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 CC: Subject: Re: alternatives to site-locals? References: <200304021317.h32DHWB2028313@burp.tkv.asdf.org> <005001c2f91c$ffd7d2d0$210d640a@unfix.org> <20030402142705.GB30669@ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike Saywell wrote: > > How about using fec0:::/64? That gives a (probably) private > network per interface, the only issue is that you wouldn't be able to > aggregate them in a sizeable network - however I agree that site-locals > shouldn't be used in such a scenario. :) There are currently two drafts that describe how to implement this. There are surface differences, but the basic idea is the same. * draft-hinden-ipv6-global-site-local-00.txt * draft-white-auto-subnet-00.txt ----- As for site locals, there seem to be three issues: scope, ambiguity, renumbering. On scope: If you only ever have on address per machine (strictly no multihoming) then scope isn't an issue. However, renumbering becomes awkward. If you allow multihoming, then either you must ban filtering or all applications need to be able to compensate for situations where some source-destination address pairs work and some don't. Architectural scoping doesn't make the problem worse, and may make it better by providing hints to applications if they choose to pay attention. On ambiguity: In most sensible SL deployment scenarios, ambiguity is not an issue. Disconnected networks don't matter, while any other SL network is not supposed to talk outside the site, and so things will happily fail. And if someone else's DNS returns an SL? Well, the packet gets dropped at the filter on your site border router. This is slightly better than any other bad DNS result where the packet is dropped somewhere in the global internet. On renumbering: Most of the ambiguity questions are really renumbering questions. For 'large' sites, you can go provider-based (renumbering is potential issue), or site-local (and be unrouteable), or NAT (yuck!), or PI (doesn't currently exist). Multi-homing at least helps things, in that you can switch in your new addresses before you switch out your old. If you wish to run an internal non-routeable address space, there are several proposals to allow site-local address realms to be set-up such that they are probably (or guaranteed) globally unique (without requiring registration), which solves the local merge problem. On the other end of the spectrum are zeroconf networks that may or may not be connected to a global provider. SL and multihoming is perfect for these networks, since they can zeroconf in the SL space and then overlay a global address space if convenient. And zeroconf networks don't have nearly the same renumbering problems as large configured networks, because they are designed to rebuild all that configuration information without human agents. Finally, there is advantage to using SL in private, disconnected networks, and that is that those networks may eventually join the global internet. If you have used SL, you know that you can continue to use that space locally without masking global connectivity, and overlay a global address. If you picked an arbitrary address, then you may have ambiguity that matters, rather than ambiguity that doesn't. I'm all in favour of an 'SL considered harmful'. However, there are several situations were SL is exactly what is appropriate, and it seems an odd philosophy to deprecate power-saws because they shouldn't be used in place of drills. -- 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 Wed Apr 2 08:41: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 h32GfJPL000208; Wed, 2 Apr 2003 08:41:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32GfJ5H000206; Wed, 2 Apr 2003 08:41: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.9+Sun/8.12.9) with ESMTP id h32GfGPL000199 for ; Wed, 2 Apr 2003 08:41:16 -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 h32GfNcU013161 for ; Wed, 2 Apr 2003 08:41:23 -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 IAA11580 for ; Wed, 2 Apr 2003 08:41: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; Wed, 2 Apr 2003 16:41: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, 2 Apr 2003 16:41: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, 2 Apr 2003 16:41:09 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, 2 Apr 2003 16:41:08 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 7B1278F2F; Wed, 2 Apr 2003 18:41:03 +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 C485B8F2C; Wed, 2 Apr 2003 18:40:57 +0200 (CEST) From: "Jeroen Massar" To: , , "'Hiroki Ishibashi'" Cc: "=?iso-8859-1?Q?'JINMEI_Tatuya_/_=90=5F-=BE'B=8D=C6'?=" , Subject: RE: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 18:41:48 +0200 Organization: Unfix Message-Id: <00ac01c2f936$c17f70a0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <098c01c2f933$f27d4720$ee1a4104@eagleswings> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 h32GfGPL000200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain [mailto:alh-ietf@tndh.net] wrote: > Jeroen Massar wrote: > > ... > > If someone doesn't want/like this they can pick a random > > number and use that, they still have to renumber when they > > interconnect to another site or the internet. > > Renumbering in an IPv6 context means adding a prefix. Unlike IPv4 it > does not mean removing the existing one. There is no reason for a site > that connects to have to renumber nodes that are not going to use the > external connection. Get out of the IPv4 mindset. If you use 'site-local' as a local prefix then you will have to renumber those boxes to be able to get global connectivity. Even if the 'site-local' prefix stays onlink you will need to do renumber in DNS and other configuration items to get global connectivity working on the incoming part. And if your fec0::/10 matches the other parties fec0::/10 also have fun renumbering or are you going for the NAT again? Otherwise have fun setting up the routing and other stuff. Also I wonder why you call it IPv4 mindset; as for as long as I have known there have been alias devices, heck even on NT, one can set multiple IP's/subnets per interface. By hand, not per DHCP but even then. Btw does DHCPv6 allow for multiple multiple prefixes? Eg when there are multiple DHCP servers? I didn't check the spec as RA's work just fine, except for the fact that there is no dns server in there (yet). 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 Apr 2 08: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 h32GhiPL000349; Wed, 2 Apr 2003 08:43:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32Ghiaa000348; Wed, 2 Apr 2003 08:43: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 h32GhePL000333 for ; Wed, 2 Apr 2003 08:43: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 h32GhmHP014056 for ; Wed, 2 Apr 2003 08:43:48 -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 JAA27709 for ; Wed, 2 Apr 2003 09:43:41 -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, 2 Apr 2003 16:43:40 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, 2 Apr 2003 16:40: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, 2 Apr 2003 16:43:40 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 16:43:38 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 02 Apr 2003 08:43:31 -0800 Reply-To: From: "Tony Hain" To: "'Jeroen Massar'" , "'Brian McGehee'" Cc: Subject: RE: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 08:43:29 -0800 Message-Id: <098e01c2f936$fdc2afa0$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: <009c01c2f935$63560580$210d640a@unfix.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h32GhePL000336 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeroen Massar wrote: > > > ... > > > Then don't route a certain prefix. > > > > Using filtering on a single global prefix does not work when > > nodes that > > need external access are on the same segment with those > that shouldn't > > have it. Prefix filtering is the answer, but the prefix to filter is > > FEC0::/10. > > Any rationale why it should be fec0::/10 and not just a > prefix picked by the administrator from the /48 they already have? > > Firewalling is firewalling, even if one filters fec0::/10 or > 2001:db8::/32 it doesn't change a bit in implementation or use. Yes it does. Clearly all you are thinking about is the firewall end of the issue, where it really doesn't matter. If the prefix is not well-known, it has to be manually configured into the devices that need to use it. If the site changes /48's, that means touching every one of those devices again. This is a non-starter for most system managers. They will use FEC0 & NAT if this is the solution proposed to them. 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 Apr 2 08:58: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 h32GwUPL001168; Wed, 2 Apr 2003 08:58:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32GwU2H001167; Wed, 2 Apr 2003 08:58: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.9+Sun/8.12.9) with ESMTP id h32GwRPL001160 for ; Wed, 2 Apr 2003 08:58: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 h32GwZHP019323 for ; Wed, 2 Apr 2003 08:58: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 JAA08550 for ; Wed, 2 Apr 2003 09:58:29 -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, 2 Apr 2003 16:57:03 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, 2 Apr 2003 16:57: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; Wed, 2 Apr 2003 16:57:00 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, 2 Apr 2003 16:56:59 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 75F958F2E; Wed, 2 Apr 2003 18:56:54 +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 A05B58F30; Wed, 2 Apr 2003 18:56:48 +0200 (CEST) From: "Jeroen Massar" To: , "'Brian McGehee'" Cc: Subject: RE: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 18:57:35 +0200 Organization: Unfix Message-Id: <00b401c2f938$f60235e0$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 In-Reply-To: <098e01c2f936$fdc2afa0$ee1a4104@eagleswings> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 h32GwRPL001161 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain [mailto:alh-ietf@tndh.net] wrote: > Jeroen Massar wrote: > > > > ... > > > > Then don't route a certain prefix. > > > > > > Using filtering on a single global prefix does not work when > > > nodes that > > > need external access are on the same segment with those > > that shouldn't > > > have it. Prefix filtering is the answer, but the prefix > to filter is > > > FEC0::/10. > > > > Any rationale why it should be fec0::/10 and not just a > > prefix picked by the administrator from the /48 they already have? > > > > Firewalling is firewalling, even if one filters fec0::/10 or > > 2001:db8::/32 it doesn't change a bit in implementation or use. > > Yes it does. Clearly all you are thinking about is the firewall end of > the issue, where it really doesn't matter. If the prefix is not > well-known, it has to be manually configured into the devices > that need > to use it. If the site changes /48's, that means touching every one of > those devices again. This is a non-starter for most system managers. > They will use FEC0 & NAT if this is the solution proposed to them. I am not thinking about the firewalling end, I am thinking about why the heck did we change the address space to 128bits if the IP's are still not globally unique, which SL imply. Fortunatly Andrew White just pointed out these two: draft-hinden-ipv6-global-site-local-00.txt draft-white-auto-subnet-00.txt And I do see a future in these, but not in the current setup for SL. See "RE: alternatives to site-locals?" Message-Id: <3E8B1148.C62895A@motorola.com> 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 Apr 2 09:15:46 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 h32HFkPL001547; Wed, 2 Apr 2003 09:15:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32HFkI4001546; Wed, 2 Apr 2003 09:15: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.9+Sun/8.12.9) with ESMTP id h32HFhPL001539 for ; Wed, 2 Apr 2003 09:15: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 h32HFpHP027615 for ; Wed, 2 Apr 2003 09:15:51 -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 KAA22451 for ; Wed, 2 Apr 2003 10:15: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, 2 Apr 2003 17:15: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; Wed, 2 Apr 2003 17:15: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, 2 Apr 2003 17:15:25 Z Received: from devil.pp.htv.fi ([213.243.180.132] [213.243.180.132]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 17:15:24 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 h32HGc4l007886; Wed, 2 Apr 2003 20:16:38 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h32HGajT007885; Wed, 2 Apr 2003 20:16:36 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing From: Mika Liljeberg To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1049303796.2304.151.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Apr 2003 20:16:36 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "NO -- Do not deprecate site-local unicast addressing". - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained for their access control benefits. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. - Other: site-locals should be retained as an easily recognizeable alternative to non-globally reachable global addresses. 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 Apr 2 09:27: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 h32HRvPL001843; Wed, 2 Apr 2003 09:27:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32HRvkq001842; Wed, 2 Apr 2003 09:27: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.9+Sun/8.12.9) with ESMTP id h32HRrPL001832 for ; Wed, 2 Apr 2003 09:27: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 h32HS1cU000874 for ; Wed, 2 Apr 2003 09:28:01 -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 JAA18102 for ; Wed, 2 Apr 2003 09:27:55 -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, 2 Apr 2003 17:27: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; Wed, 2 Apr 2003 17:27:54 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, 2 Apr 2003 17:27:54 Z Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 17:27:54 Z Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h32HRm5M026918; Wed, 2 Apr 2003 09:27:49 -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 ACV89648; Wed, 2 Apr 2003 09:27:47 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA16913; Wed, 2 Apr 2003 09:27:47 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16011.7571.633880.456311@thomasm-u1.cisco.com> Date: Wed, 2 Apr 2003 09:27:47 -0800 (PST) To: Dan Lanciani Cc: ipng@sunroof.eng.sun.com Subject: RE: avoiding NAT with IPv6 In-Reply-To: <200304012301.SAA24243@ss10.danlan.com> References: <200304012301.SAA24243@ss10.danlan.com> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani writes: > MUST NOTs in RFCs are not going to stop NAT. > > Eliminating NAT is actually very simple. All you have to do is give users > that which by its lack drove them to use NAT in the first place: plentiful, > free, stable address space. I conclude from the effort that folks are putting > into discussing other (pointless) ways to mandate NAT away that they in fact > agree with my prediction that v6 ISPs will not magically change their business > models and offer such address space freely. As long as address space and > stability remain profit centers, you will not be able to eliminate NAT. Sure, but until then what does IETF do? There seems to be a tacit game which is being played out here which is "don't encourage NAT" which see-saws between the architectural principles of the NAT-less internet, and the reality of NAT's being present. And NAT's will most likely exist going forward primarily because we don't have any assurance of stability of address space (eg PI). There are some who would like to embrace NAT as an architectural principle -- not necessarily here, but they clearly exist -- some who hate NAT's under any circumstance, and then many people in the middle who don't like NAT's and the implications of NAT's being an architectural principle (like the Thou Shalt Consider Security edicts from the IESG these days), but are more pragmatic about their existence. As in, what should we do to minimize the damage? The deal I personally have made with this devil is to realize that we're not going to stop their use until all of the reasons you enumerate are addressed, but in the mean time I'd assume we bide our time and not throw in the towel on a NAT-free world. What this pragmatically means is making NAT's a poor a relation as possible so that we aren't trapped in the quagmire of making it an architectural principle which must be addressed from the outset. It also means turning our back on things that are obvious problems and often let them get hacked on outside of the IETF context. Thus, the fundamental argument going on here is: how much do we allow ourselves to be sucked down the this rathole? My opinion is "the less, the better". Site locals will without any doubt in my mind be primarily used as a replacement for net 10 address space -- all of the other purported uses are marginal, redundant or false-secure. This is why I think pointing would-be site-local people to 6to4/net 10's is probably a good compromise since it shunts the problem off into legacy land, and allows us to postpone having to make decisions about the true implications of routing scope with traditionally routing-dumb hosts. This is obviously unsatisfying for those who would like a more long term solution, but... well, we ain't there. Until we've convinced ourselves we really have no choice but to embrace NAT as an architectural principle since we can't resolve your laundry list of reasons people use them, doing nothing -- or next to nothing -- looks like a pretty reasonable option, IMHO. Taking the *wrong* direction at this point could be extremely harmful. Scoped addresses as have been pretty well demonstrated take us down some pretty scary paths. Let's not go there... 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 Apr 2 10:16: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 h32IGrPL002394; Wed, 2 Apr 2003 10:16:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32IGrUx002393; Wed, 2 Apr 2003 10:16: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.9+Sun/8.12.9) with ESMTP id h32IGoPL002386 for ; Wed, 2 Apr 2003 10:16:50 -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 h32IGwHP022021 for ; Wed, 2 Apr 2003 10:16: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 LAA11238 for ; Wed, 2 Apr 2003 11:16: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, 2 Apr 2003 18:16: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; Wed, 2 Apr 2003 18:16: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, 2 Apr 2003 18:16:51 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 18:16:51 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 02 Apr 2003 10:16:48 -0800 Reply-To: From: "Tony Hain" To: "'Michael Thomas'" , "'Dan Lanciani'" Cc: Subject: anti-SL == flat-earth society (was RE: avoiding NAT with IPv6) Date: Wed, 2 Apr 2003 10:16:45 -0800 Message-Id: <09a401c2f944$05d34760$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: <16011.7571.633880.456311@thomasm-u1.cisco.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h32IGoPL002387 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > ... Scoped addresses as have been pretty well > demonstrated take us down some pretty scary paths. This sums up the whole anti-SL campain, which is spread FUD based on one technically valid point; applications can't arbitrarily pass around topology information. Applications that insist on passing around topology information must understand the topology they are describing. If they don't understand it, they are broken. Trying to assert a flat-earth will not make it happen. There will be filtering, therefore there will be addresses with a limited scope of applicability. Scoped addresses will exist with or without a dedicated prefix. Lack of a well-known prefix only makes more work for the system manager to manually configure devices. It will be a sad outcome for decades to come if we trade off the one-time per app cost of a developer needing to deal with a well-known prefix in favor of the continuous operational cost of manual configuration. 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 Apr 2 10:26:35 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 h32IQYPL002623; Wed, 2 Apr 2003 10:26:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32IQYSZ002622; Wed, 2 Apr 2003 10:26: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 h32IQUPL002615 for ; Wed, 2 Apr 2003 10:26: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 h32IQdcU023990 for ; Wed, 2 Apr 2003 10:26:39 -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 KAA05705 for ; Wed, 2 Apr 2003 10:26: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; Wed, 2 Apr 2003 18:26: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; Wed, 2 Apr 2003 18:23: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; Wed, 2 Apr 2003 18:26:32 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, 2 Apr 2003 18:26:31 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 h32IQPOV004151; Wed, 2 Apr 2003 10:26:25 -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 ACV97397; Wed, 2 Apr 2003 10:26:25 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA16919; Wed, 2 Apr 2003 10:26:25 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16011.11088.949928.569685@thomasm-u1.cisco.com> Date: Wed, 2 Apr 2003 10:26:24 -0800 (PST) To: Cc: "'Michael Thomas'" , "'Dan Lanciani'" , Subject: anti-SL == flat-earth society (was RE: avoiding NAT with IPv6) In-Reply-To: <09a401c2f944$05d34760$ee1a4104@eagleswings> References: <16011.7571.633880.456311@thomasm-u1.cisco.com> <09a401c2f944$05d34760$ee1a4104@eagleswings> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain writes: > Michael Thomas wrote: > > ... Scoped addresses as have been pretty well > > demonstrated take us down some pretty scary paths. > > This sums up the whole anti-SL campain, which is spread FUD [...] *plonk* 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 Apr 2 10:37:14 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 h32IbEPL003054; Wed, 2 Apr 2003 10:37:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32IbEBo003053; Wed, 2 Apr 2003 10:37: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.9+Sun/8.12.9) with ESMTP id h32IbBPL003046 for ; Wed, 2 Apr 2003 10:37:11 -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 h32IbJHP000714 for ; Wed, 2 Apr 2003 10:37:19 -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 LAA20296 for ; Wed, 2 Apr 2003 11:37:13 -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, 2 Apr 2003 18:37:13 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, 2 Apr 2003 18:33: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; Wed, 2 Apr 2003 18:36: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; Wed, 2 Apr 2003 18:36:57 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 95F088F33; Wed, 2 Apr 2003 20:36:54 +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 7CFBD8B6F; Wed, 2 Apr 2003 20:36:39 +0200 (CEST) From: "Jeroen Massar" To: Cc: Subject: RE: alternatives to site-locals? Date: Wed, 2 Apr 2003 20:37:16 +0200 Organization: Unfix Message-Id: <00dc01c2f946$e401def0$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 In-Reply-To: <3E8B1148.C62895A@motorola.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 h32IbBPL003047 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew White wrote: > Mike Saywell wrote: > > > > How about using fec0:::/64? That gives a > (probably) private > > network per interface, the only issue is that you wouldn't > be able to > > aggregate them in a sizeable network - however I agree that > site-locals > > shouldn't be used in such a scenario. :) > > There are currently two drafts that describe how to implement > this. There > are surface differences, but the basic idea is the same. > > * draft-hinden-ipv6-global-site-local-00.txt > * draft-white-auto-subnet-00.txt I personally can see use in these two drafts. But not in the current setup for SL. These at least take the problem away that a site is unique which saves on the renumbering problem when 'unconnected' sites connect. > As for site locals, there seem to be three issues: scope, ambiguity, > renumbering. > > > On scope: > > If you only ever have on address per machine (strictly no > multihoming) then scope isn't an issue. However, renumbering becomes awkward. > > If you allow multihoming, then either you must ban filtering or all > applications need to be able to compensate for situations where some > source-destination address pairs work and some don't. > Architectural scoping doesn't make the problem worse, and may make > it better by providing hints to applications if they choose to pay attention. Having multiple prefixes will most of the time imply that the layers above know a bit about the network. Though ignorance is bliss in this case as the current source-address- selections protocols will select the correct prefix in most cases based on longest prefix matching algorithms. > On ambiguity: > > In most sensible SL deployment scenarios, ambiguity is not an issue. > Disconnected networks don't matter, while any other SL network is not > supposed to talk outside the site, and so things will happily > fail. And if someone else's DNS returns an SL? Well, the packet gets > dropped at the filter on your site border router. This is slightly better > than any other bad DNS result where the packet is dropped somewhere in the > global internet. There does start a problem where the deployment is not sensible. AS112 is the proof of this. Explicetly having a certain prefix filtered on SOHO devices could be an option, but this also implies that IPv6 will be going that dreaded NAT way if the upstream doesn't provide enough address space. Talking about that, maybe a clause in some document should hint ISP's to start billing based on traffic consumption and not on IP usage. "IP usage" is a unmeasurable thing when the endsite gets a /48 unless the ISP is going to sniff all the packets and account them that way instead of based on the circuit counters. This would at least hint them that endsites should really get a /48 and not just a single /128. Personally I would shoot ISP's who did not follow that convention. Then again one can always ask them why the peep they requested a TLA in the first place if they are not going to give their endsites /48's. > I'm all in favour of an 'SL considered harmful'. However, > there are several situations were SL is exactly what is > appropriate, and it seems an odd philosophy to deprecate > power-saws because they shouldn't be used in place of drills. With the above 2 drafts in mind we only will be deprecating the current version of SL. One, or a merger, of the above two drafts will make the power saws into a workable saw which doesn't smash up the wood (ambiguity) nor doesn't need any power (registration). 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 Apr 2 10:41:02 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 h32If2PL003225; Wed, 2 Apr 2003 10:41:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32If10l003223; Wed, 2 Apr 2003 10:41: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.9+Sun/8.12.9) with ESMTP id h32IewPL003216 for ; Wed, 2 Apr 2003 10:40: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 h32If6cU000034 for ; Wed, 2 Apr 2003 10:41:06 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA06977 for ; Wed, 2 Apr 2003 11:41: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; Wed, 2 Apr 2003 18:41: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; Wed, 2 Apr 2003 18:37: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; Wed, 2 Apr 2003 18:40:57 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 18:40:56 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 02 Apr 2003 10:40:54 -0800 Reply-To: From: "Tony Hain" To: "'Jeroen Massar'" , "'Brian McGehee'" Cc: Subject: RE: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Wed, 2 Apr 2003 10:40:51 -0800 Message-Id: <09a801c2f947$635c9000$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: <00cc01c2f942$f57d1bd0$210d640a@unfix.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeroen Massar wrote: > ... > Did you even _read_ the two drafts? one even has the > word 'auto' in it. There will be no registry involved here, > except for the one registering MAC/EUI64 or other unique > addresses from which the automatic unique address is derived. > No money involved there, just a correct way of dealing with a > load of space without duplicates. > > Morning Tony ;) Both of those are creating /64's that can't be routed well within an enterprise network. A proposal that creates globally unique /48's would be appropriate. 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 Apr 2 11:01: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 h32J1WPL003734; Wed, 2 Apr 2003 11:01:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32J1WUv003733; Wed, 2 Apr 2003 11:01: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 h32J1SPL003726 for ; Wed, 2 Apr 2003 11:01:28 -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 h32J1aHP010189 for ; Wed, 2 Apr 2003 11:01:36 -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 MAA09559 for ; Wed, 2 Apr 2003 12:01:30 -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, 2 Apr 2003 19:01: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; Wed, 2 Apr 2003 19:01: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; Wed, 2 Apr 2003 19:01:29 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; Wed, 2 Apr 2003 19:01:29 Z Date: Wed, 02 Apr 2003 11:01:25 -0800 Subject: Re: Outlawing (Avoiding) NAT with IPv6 From: Alper Yegin To: Alexandru Petrescu , Brian E Carpenter CC: , , Message-Id: In-Reply-To: <3E8AD961.9050006@nal.motlabs.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 >>>> 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. >> >> >> Actually not, if you have a domestic /48 or /64 prefix. But the >> MobileIP solution looks OK. > > Looks but doesn't act like really providing location privacy, IMHO. > > In my understanding, the essence of the hmipv6 location privacy > mechanism lies in the MAP replacing a RCoA for a LCoA (when > decapsulating). However, it is very much likely that the two > addresses will only differ in the /64 prefix. > > Suffices it for an attacker that wants to find the correlation > LCoA-RCoA to visit the MAP domain once and learn that domain's > prefixes that are part of all of that domain's LCoA's. I don't quite understand this... All CN knows is the RCoA of the MN. Only LCoA can reveal the location of the MN within the network. And CN cannot figure out LCoA by looking at RCoA. This is so much like what NAT does as far as hiding LCoA is concerned. > > What one really obtains with HMIP is that one gets assigned two > addresses and is free to inform its CN about one of those addresses. > Nothing about a location being assigned to an address, let alone the > question of hiding that location. > > Another location privacy drawback in hmipv6 is that it is the > network that decides whether an MN can use that location privacy or > not. That should supposedly be entirely an MN choice. MN can choose to engage in HMIP and hence take advantage of it. I don't see the network forcing MN to use this protocol. So, at the end, it's MN's choice. > > My two cents worth; (two because I'm getting the ipng mails twice :-) alper > > Alex > GBU > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 2 11:28: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 h32JSYPL004041; Wed, 2 Apr 2003 11:28:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32JSY32004040; Wed, 2 Apr 2003 11:28: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.9+Sun/8.12.9) with ESMTP id h32JSUPL004033 for ; Wed, 2 Apr 2003 11:28: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 h32JScHP021322 for ; Wed, 2 Apr 2003 11:28: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-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26108 for ; Wed, 2 Apr 2003 11:28: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, 2 Apr 2003 19:28: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, 2 Apr 2003 19:28: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; Wed, 2 Apr 2003 19:28:32 Z Received: from oak2a.cats.ohiou.edu ([132.235.8.44] [132.235.8.44]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 19:28:31 Z Received: from hkruse.csm.ohiou.edu (hkruse.csm.ohiou.edu [132.235.75.144]) (authenticated bits=0) by oak1a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id h32JR2NJ752622 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 2 Apr 2003 14:27:02 -0500 (EST) Date: Wed, 02 Apr 2003 14:27:33 -0500 From: Hans Kruse To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Message-Id: <775197535.1049293653@hkruse.csm.ohiou.edu> In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-MailScanner-VirusCheck: Found to be clean X-MailScanner-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-0.5, required 5, IN_REP_TO, REFERENCES, SPAM_PHRASE_00_01) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "NO -- Do not deprecate site-local unicast addressing". - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 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 Wed Apr 2 11:35:16 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 h32JZFPL004178; Wed, 2 Apr 2003 11:35:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32JZFXg004177; Wed, 2 Apr 2003 11:35: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.9+Sun/8.12.9) with ESMTP id h32JZCPL004170 for ; Wed, 2 Apr 2003 11:35:12 -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 h32JZKcU022545 for ; Wed, 2 Apr 2003 11:35:20 -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 MAA01029 for ; Wed, 2 Apr 2003 12:35:08 -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, 2 Apr 2003 19:34:40 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, 2 Apr 2003 19:31: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, 2 Apr 2003 19:34:39 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 19:34:39 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 02 Apr 2003 11:34:37 -0800 Reply-To: From: "Tony Hain" To: "'Jeroen Massar'" , Cc: Subject: RE: alternatives to site-locals? Date: Wed, 2 Apr 2003 11:34:34 -0800 Message-Id: <09b001c2f94e$e4b0c2f0$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: <00dc01c2f946$e401def0$210d640a@unfix.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeroen Massar wrote: > ... > Talking about that, maybe a clause in some document should > hint ISP's to start billing based on traffic consumption and > not on IP usage. "IP usage" is a unmeasurable thing when the > endsite gets a /48 unless the ISP is going to sniff all the > packets and account them that way instead of based on the > circuit counters. This would at least hint them that endsites > should really get a /48 and not just a single /128. > Personally I would shoot ISP's who did not follow that > convention. Then again one can always ask them why the peep > they requested a TLA in the first place if they are not going > to give their endsites /48's. Demand RFC 3041 support for your devices. > > > > > I'm all in favour of an 'SL considered harmful'. However, > > there are several situations were SL is exactly what is > > appropriate, and it seems an odd philosophy to deprecate > > power-saws because they shouldn't be used in place of drills. > > With the above 2 drafts in mind we only will be deprecating > the current version of SL. One, or a merger, of the above > two drafts will make the power saws into a workable saw > which doesn't smash up the wood (ambiguity) nor doesn't > need any power (registration). Wrong, because they are not defining /48's. 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 Apr 2 11:40:12 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 h32JeBPL004398; Wed, 2 Apr 2003 11:40:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32JeBXa004397; Wed, 2 Apr 2003 11:40: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.9+Sun/8.12.9) with ESMTP id h32Je8PL004387 for ; Wed, 2 Apr 2003 11:40:08 -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 h32JeGHP026049 for ; Wed, 2 Apr 2003 11:40:16 -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 LAA15925 for ; Wed, 2 Apr 2003 11:40:10 -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, 2 Apr 2003 19:40: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; Wed, 2 Apr 2003 19:40: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; Wed, 2 Apr 2003 19:40:08 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 19:40:05 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id OAA29010 for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 14:38:45 -0500 (EST) Date: Wed, 2 Apr 2003 14:38:45 -0500 (EST) From: Dan Lanciani Message-Id: <200304021938.OAA29010@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: DeprecatingSite-Local Addressing) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: |I think we should clear the desktop first, by getting rid of ambiguous |site-local address space, and then discuss possible new solutions. Could you explain why you think this is the correct order? To me it seems completely wrong. Eliminating site-locals will probably require changes in much the same areas that any new solution will require. Why edit everything twice? Once site-locals are gone there will be very little incentive for those who dismiss their uses to look at alternate solutions since they do not recognize the associated problems as problems. Dan Lanciani ddl@danlan.*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 Apr 2 11:44: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 h32JioPL004651; Wed, 2 Apr 2003 11:44:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32JioY9004650; Wed, 2 Apr 2003 11:44: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.9+Sun/8.12.9) with ESMTP id h32JikPL004643 for ; Wed, 2 Apr 2003 11:44: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 h32JiscU026151 for ; Wed, 2 Apr 2003 11:44: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-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09890 for ; Wed, 2 Apr 2003 11:44: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; Wed, 2 Apr 2003 19:44: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; Wed, 2 Apr 2003 19:44: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; Wed, 2 Apr 2003 19:44:48 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 19:44:47 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id OAA29041; Wed, 2 Apr 2003 14:44:43 -0500 (EST) Date: Wed, 2 Apr 2003 14:44:43 -0500 (EST) From: Dan Lanciani Message-Id: <200304021944.OAA29041@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Charge for traffic, not IP addresses (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Jeroen Massar" wrote: |William_G_Allmond@notes.tcs.treas.gov wrote: | |> NO - Do NOT Deprecate Site-Local Addressing. |> |> There are reason to use site-locals, and reason NOT to use them. But |> "FORBIDDING" people will only alienate them and lead them to |> find ways to do it anyway. |> |> Perfect example, when (or should I say IF) my home ISP goes |> to IPv6, they charge per IP. Always have, and always will. |> Sure, they will gladly give me a range of IPs, as well as |> gladly charge me as if each were a PC. Also, |> when I get tired of putting up with the abuse from this |> particular ISP and decide to choose another ISP to abuse me, |> I will still have the same issue. | |Very good example that you don't get it at all. |ISP's should be charging for traffic, not for IP's. So why don't you make the ISPs work the way you think they should? Then NAT would go away and you wouldn't have to try to ban it. NAT is the effect, not the cause. Dan Lanciani ddl@danlan.*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 Apr 2 12:15:04 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 h32KF3PL005248; Wed, 2 Apr 2003 12:15:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32KF34K005247; Wed, 2 Apr 2003 12:15: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 h32KF0PL005240 for ; Wed, 2 Apr 2003 12:15:00 -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 h32KF8HP009854 for ; Wed, 2 Apr 2003 12:15:08 -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 NAA15723 for ; Wed, 2 Apr 2003 13:15: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; Wed, 2 Apr 2003 20:15: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; Wed, 2 Apr 2003 20:15: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; Wed, 2 Apr 2003 20:15:01 Z Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 20:15:00 Z Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 2 Apr 2003 12:14:51 -0800 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 02 Apr 2003 12:15:05 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3789.0); Wed, 2 Apr 2003 12:15:06 -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); Wed, 2 Apr 2003 12:14:59 -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, 2 Apr 2003 12:15: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="iso-8859-1" Subject: Globally unique link prefix alternative to site-locals Date: Wed, 2 Apr 2003 12:14:51 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Globally unique link prefix alternative to site-locals Thread-Index: AcL5T6gLTn92MWKNSPCkUH0SwlEOkQAAu17n From: "Christian Huitema" To: , "Jeroen Massar" , Cc: X-OriginalArrivalTime: 02 Apr 2003 20:15:08.0987 (UTC) FILETIME=[8EE708B0:01C2F954] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h32KF0PL005241 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The "anti-SL" arguments are primarily arguments aainst using ambiguous addresses. Ambiguous addresses are a royal pain in hosts that connect to multiple sites, either simultaneously or over time -- the applications need extra logic, and that creates bugs. But we clearly have an issue in the case of disconnected sites, intermittently connected sites, and ad hoc networks. The "let's pick a prefix" argument is probably OK for large "managed" sites. In fact, most of the large sites have at least one IPv4 address and can pick a prefix; they could even obtain a provisional allocation from a friendly ISP. But this leaves out the small sites, the ad hoc networks, the unmanaged sites. However, if we just look at these small sites, we can easily get unambiguous *link* prefixes of the form: ::/64 In a small site, these prefixes can be autoconfigured by routers, and then published in the IGP. If there are several routers on the same link, they can either elect a master prefix or just advertise one prefix each. Having unique per-link prefixes has quite a few advantages: - We get actual zero-configuration, a site can be just switched on. - Local connectivity can be used for adding a global addressing plan when the site joins the Internet. - Hosts can be multihomed at will; there is enough information in the address to find the right exit. - The addresses remain valid if a site is split, or if two sites are merged. - Unreachability is enforced by firewalls, not by bits in the address. - Since the link prefix is a /64, there is zero chance of having a nasty ISP leak it to the Internet. - If the /16 is well known, it can be plugged as "least preferred" in the address selection rules. Is anyone interested in pursuing this design? -- 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 Apr 2 12:38: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 h32KcePL005885; Wed, 2 Apr 2003 12:38:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32KceIN005884; Wed, 2 Apr 2003 12:38: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 h32KcbPL005877 for ; Wed, 2 Apr 2003 12:38: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 h32KcjcU022374 for ; Wed, 2 Apr 2003 12:38: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 NAA00628 for ; Wed, 2 Apr 2003 13:38: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, 2 Apr 2003 20:38:31 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, 2 Apr 2003 20:38: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; Wed, 2 Apr 2003 20:38:30 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 20:38:29 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 02 Apr 2003 12:38:26 -0800 Reply-To: From: "Tony Hain" To: "'Christian Huitema'" , "'Jeroen Massar'" , Cc: Subject: RE: Globally unique link prefix alternative to site-locals Date: Wed, 2 Apr 2003 12:38:23 -0800 Message-Id: <09bb01c2f957$cf102d10$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 h32KcbPL005878 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This proposal is essentially what draft-hinden-ipv6-global-site-local-00.txt does. I have no problem with carving off a chunk of FEC0::/10 space for something like this, but that approach does not solve all problems. In particular it creates an unroutable mess for sites with a large number of subnets. Tony -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Wednesday, April 02, 2003 12:15 PM To: alh-ietf@tndh.net; Jeroen Massar; awhite@arc.corp.mot.com Cc: ipng@sunroof.eng.sun.com Subject: Globally unique link prefix alternative to site-locals The "anti-SL" arguments are primarily arguments aainst using ambiguous addresses. Ambiguous addresses are a royal pain in hosts that connect to multiple sites, either simultaneously or over time -- the applications need extra logic, and that creates bugs. But we clearly have an issue in the case of disconnected sites, intermittently connected sites, and ad hoc networks. The "let's pick a prefix" argument is probably OK for large "managed" sites. In fact, most of the large sites have at least one IPv4 address and can pick a prefix; they could even obtain a provisional allocation from a friendly ISP. But this leaves out the small sites, the ad hoc networks, the unmanaged sites. However, if we just look at these small sites, we can easily get unambiguous *link* prefixes of the form: ::/64 In a small site, these prefixes can be autoconfigured by routers, and then published in the IGP. If there are several routers on the same link, they can either elect a master prefix or just advertise one prefix each. Having unique per-link prefixes has quite a few advantages: - We get actual zero-configuration, a site can be just switched on. - Local connectivity can be used for adding a global addressing plan when the site joins the Internet. - Hosts can be multihomed at will; there is enough information in the address to find the right exit. - The addresses remain valid if a site is split, or if two sites are merged. - Unreachability is enforced by firewalls, not by bits in the address. - Since the link prefix is a /64, there is zero chance of having a nasty ISP leak it to the Internet. - If the /16 is well known, it can be plugged as "least preferred" in the address selection rules. Is anyone interested in pursuing this design? -- 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 Apr 2 13:44: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 h32Li8PL006702; Wed, 2 Apr 2003 13:44:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32Li8LJ006701; Wed, 2 Apr 2003 13: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.9+Sun/8.12.9) with ESMTP id h32Li4PL006694 for ; Wed, 2 Apr 2003 13:44: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 h32LiCHP011900 for ; Wed, 2 Apr 2003 13:44: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 OAA29797 for ; Wed, 2 Apr 2003 14:44:05 -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, 2 Apr 2003 21:44:02 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, 2 Apr 2003 21:40: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; Wed, 2 Apr 2003 21:44:02 Z Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 2 Apr 2003 21:44:02 Z Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 2 Apr 2003 13:44:00 -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, 2 Apr 2003 13:44:01 -0800 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 02 Apr 2003 13:44:00 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 2 Apr 2003 13:43:56 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 2 Apr 2003 13:43:52 -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, 2 Apr 2003 13:44:01 -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: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Wed, 2 Apr 2003 13:44:03 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing Thread-Index: AcL4iQ/mZKOW52xkQTuRBd7MBu5EoAAE3MPAADA2eBA= From: "Dave Thaler" To: "Michel Py" , "Margaret Wasserman" , X-OriginalArrivalTime: 02 Apr 2003 21:44:01.0518 (UTC) FILETIME=[F956B0E0:01C2F960] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h32Li5PL006695 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Michel, and hence in a way I guess I object to the wording of the question. Per Margaret's clarification > People who spoke at the mike, but did not express > an opinion during the show of hands, may express their YES/NO opinion now > on the list. I'm still entitled to give a response on the list, which I'm still reserving based on the details of the actual proposal. As I mentioned at the mike during the meeting, to deprecate site-locals, you need to either: a) remove the ability to _automatically_ address disconnected and intermittently-connected sites, or b) specify how to automatically address them. My reading of the opinions expressed during the meeting was that people agreed that disconnected and intermittently connected sites should be supported. However, during the meeting, no one gave any proposals for (b). One or two people (Dino Farinacci was one, and maybe Erik was another?) gave proposals for how to _manually_ number them as an administrator, but that's not a solution for zero-config environments where site-locals may be used today (e.g. a simple home gateway). Hence, I'm assuming that most people responding with "Yes deprecate" mean (b) without knowing if the result would be as bad as site-locals, in which case they're no better off. Since I admit I don't yet know if it would be as bad (or heaven forbid, worse), I abstained from raising my hand at the time. Can someone quickly give a proposal or two for (b) before the consensus call deadline? If I see a reasonable proposal, I'm likely to respond YES. Otherwise I'll be forced to respond NO until a detailed proposal appears. It seems like at the moment we're being asked for a consensus on an idea which may or may not prove to be practical (although we obviously hope it is practical)! -Dave > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Tuesday, April 01, 2003 2:21 PM > To: Margaret Wasserman; ipng@sunroof.eng.sun.com > > Margaret / Bob, > > What is this consensus about? I was hoping that the mailing list would > be asked to express their opinions _after_ a text to deprecate > site-local addressing had been submitted to the working group. In the > current situation, this consensus if there is one would be good only to > accept text as a working document. This document that still has to be > seen then should go to WG last call. > > Where is the doc to deprecate site-local addressing? > > 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 Wed Apr 2 15:16: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 h32NGbPL007559; Wed, 2 Apr 2003 15:16:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h32NGbrl007558; Wed, 2 Apr 2003 15:16: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.9+Sun/8.12.9) with ESMTP id h32NGXPL007551 for ; Wed, 2 Apr 2003 15:16:33 -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 h32NGecU021548 for ; Wed, 2 Apr 2003 15:16: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 QAA13029 for ; Wed, 2 Apr 2003 16: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; Wed, 2 Apr 2003 23:15: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; Wed, 2 Apr 2003 23:15:23 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, 2 Apr 2003 23:15:23 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; Wed, 2 Apr 2003 23:15:22 Z Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KUAA7N4DCS9AU8TV@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 09:07:05 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 4BCB412C004; Thu, 03 Apr 2003 09:07:05 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 37B3012C002; Thu, 03 Apr 2003 09:07:05 +1000 (EST) Date: Thu, 03 Apr 2003 09:07:05 +1000 From: Greg Daley Subject: Location Privacy (was Re: Outlawing (Avoiding) NAT with IPv6) To: Alexandru Petrescu Cc: Brian E Carpenter , alh-ietf@tndh.net, jbartas@iniche.com, ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E8B6D19.5010706@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: <07a201c2f7d7$157391c0$ee1a4104@eagleswings> <3E897DE0.85A84EED@hursley.ibm.com> <3E8AD961.9050006@nal.motlabs.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alexandru, A quick HMIPv6 comment below. Alexandru Petrescu wrote: > Brian E Carpenter 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. >> >> >> >> Actually not, if you have a domestic /48 or /64 prefix. But the >> MobileIP solution looks OK. > > > Looks but doesn't act like really providing location privacy, IMHO. > > In my understanding, the essence of the hmipv6 location privacy > mechanism lies in the MAP replacing a RCoA for a LCoA (when > decapsulating). However, it is very much likely that the two > addresses will only differ in the /64 prefix. There is no problem with the RCoA and LCoA differing only in prefix if the LCoA and RCoA are based on RFC3041 addresses. In this case, there is no identity information in the care-of-addresses, and no specific location information available in packets which are sent from the RCoA. For communications completed while the RCoA is unchanged, the MN can use a 3041 based RCoA, and not use the MIPv6 Home Address options (or use the RCoA as a home address), in which case there is no identity information in the packets sent or received from the MN to correspondent nodes, and no location information more accurate than which MAP the MN is using. Please try to track a user in this situation! > Suffices it for an attacker that wants to find the correlation > LCoA-RCoA to visit the MAP domain once and learn that domain's > prefixes that are part of all of that domain's LCoA's. Location privacy within the MAP domain is still achieved for the MN, since this is not divulged to anyone other than the MAP. Of course you could easily determine what the advertised MAP coverage was, but anyone could still use a MAP when they are not in the base coverage domain, so long as there is connectivity between the MAP and MN, and the MAP policy allows this. > What one really obtains with HMIP is that one gets assigned two > addresses and is free to inform its CN about one of those addresses. > Nothing about a location being assigned to an address, let alone the > question of hiding that location. Locations are implied by IPv6 subnet information in the LCoA. IP access subnets which span greater areas than a city are a bad idea IMHO. Of course the MN is responsible for which addresses it uses in conversation. If it's aware of a need for privacy and still advertises the IP subnet it is located at then privacy isn't going to work. > Another location privacy drawback in hmipv6 is that it is the > network that decides whether an MN can use that location privacy or > not. That should supposedly be entirely an MN choice. I think that there may be location indirection services which accept fees from MNs to provide location privacy with HMIPv6, without being in the Access Service provider. This would be an opt-in service, on the MN's behalf. Also, we're looking at the possibility that certain countries will ensure that ISPs in their jurisdiction provide location privacy. If HMIPv6 is the only candidate (and works), I'm sure that it will be adopted. If you're more interested in the technical details, then we can take this to Mobile-IP WG. 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 Wed Apr 2 16:39: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 h330dgPL008159; Wed, 2 Apr 2003 16:39:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h330dgge008158; Wed, 2 Apr 2003 16:39: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.9+Sun/8.12.9) with ESMTP id h330ddPL008151 for ; Wed, 2 Apr 2003 16:39: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 h330dlcU020852 for ; Wed, 2 Apr 2003 16:39: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 QAA22651 for ; Wed, 2 Apr 2003 16:39:41 -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, 3 Apr 2003 00:39:32 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, 3 Apr 2003 00:39:32 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, 3 Apr 2003 00:39:32 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, 3 Apr 2003 00:39:31 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: Wed, 2 Apr 2003 16:39:31 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F71B@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: AcL4IZ19I1LjYfXBSfiYY3txlOVWlABV12Vw From: "Michel Py" To: "Pekka Savola" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h330ddPL008152 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> 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. It would have to be the killer app that IPv6 so desperately needs. Short of the new Napster with a guarantee that the RIAA would not try to kill it immediately, I have not heard of such thing. 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 Apr 2 16:51: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 h330pjPL008370; Wed, 2 Apr 2003 16:51:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h330pjmb008369; Wed, 2 Apr 2003 16: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h330pePL008362 for ; Wed, 2 Apr 2003 16:51:40 -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 h330pmHP020967 for ; Wed, 2 Apr 2003 16:51:48 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA11903 for ; Wed, 2 Apr 2003 17:51:42 -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, 3 Apr 2003 00:51: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, 3 Apr 2003 00:51: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, 3 Apr 2003 00:51:03 Z Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 00:51:02 Z Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h330oRau023499; Wed, 2 Apr 2003 17:50:27 -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 RAA17929; Wed, 2 Apr 2003 17:50:53 -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 h3308vmE029800; Thu, 3 Apr 2003 10:08:58 +1000 (EST) Message-Id: <3E8B7B99.93C43FC6@motorola.com> Date: Thu, 03 Apr 2003 10:08:57 +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: Christian Huitema CC: ipng@sunroof.eng.sun.com, Bob Hinden Subject: Re: Globally unique link prefix alternative to site-locals References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is anyone interested in pursuing this design? Well, I have an implementation. If Bob is happy, I'd like to grab most of his text (since it's better written than mine) and wrap it around my bit-ordering proposal. > - If the /16 is well known, it can be plugged as "least preferred" in > the address selection rules. I still have qualms with this. I'm of the opinion that if site-locals exist in a network then hosts should prefer them (iff both hosts have them); the assumption is that SL addresses are at least as stable as externally sourced addresses. Of course, this policy will potentially be inappropriate for applications that do address forwarding across a site boundary, but I'd argue that these are the special case. Apps that do address forwarding NOT across a site boundary will be happy with the standard policy. -- Andrew White -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 18:17: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 h332HuPL008988; Wed, 2 Apr 2003 18:17:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h332Husu008987; Wed, 2 Apr 2003 18:17: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.9+Sun/8.12.9) with ESMTP id h332HqPL008980 for ; Wed, 2 Apr 2003 18:17:52 -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 h332I0HP016439 for ; Wed, 2 Apr 2003 18:18: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 SAA09169 for ; Wed, 2 Apr 2003 18:17:54 -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, 3 Apr 2003 02:17: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, 3 Apr 2003 02:17: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; Thu, 3 Apr 2003 02:17:52 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; Thu, 3 Apr 2003 02:17:51 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 <20030403021749.FJRE11905.mailhost.chi1.ameritech.net@repligate>; Wed, 2 Apr 2003 20:17:49 -0600 Message-Id: <0a8c01c2f987$451a2e00$8500a8c0@repligate> From: "Jim Fleming" To: "Christian Huitema" , , "Jeroen Massar" , Cc: References: Subject: Re: Globally unique link prefix alternative to site-locals Date: Wed, 2 Apr 2003 20:18:07 -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: "Christian Huitema" To: ; "Jeroen Massar" ; Cc: Sent: Wednesday, April 02, 2003 2:14 PM Subject: Globally unique link prefix alternative to site-locals > The "anti-SL" arguments are primarily arguments aainst using ambiguous addresses. Ambiguous addresses are a royal pain in hosts that connect to multiple sites, either simultaneously or over time -- the applications need extra logic, and that creates bugs. But we clearly have an issue in the case of disconnected sites, intermittently connected sites, and ad hoc networks. > > The "let's pick a prefix" argument is probably OK for large "managed" sites. In fact, most of the large sites have at least one IPv4 address and can pick a prefix; they could even obtain a provisional allocation from a friendly ISP. But this leaves out the small sites, the ad hoc networks, the unmanaged sites. However, if we just look at these small sites, we can easily get unambiguous *link* prefixes of the form: > ::/64 > In a small site, these prefixes can be autoconfigured by routers, and then published in the IGP. If there are several routers on the same link, they can either elect a master prefix or just advertise one prefix each. Having unique per-link prefixes has quite a few advantages: > > - We get actual zero-configuration, a site can be just switched on. > - Local connectivity can be used for adding a global addressing plan when the site joins the Internet. > - Hosts can be multihomed at will; there is enough information in the address to find the right exit. > - The addresses remain valid if a site is split, or if two sites are merged. > - Unreachability is enforced by firewalls, not by bits in the address. > - Since the link prefix is a /64, there is zero chance of having a nasty ISP leak it to the Internet. > - If the /16 is well known, it can be plugged as "least preferred" in the address selection rules. > > Is anyone interested in pursuing this design? > > -- Christian Huitema > ::/64 Are you on the AM Internet or the FM InterNAT ? 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 Wed Apr 2 19:20: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 h333KQPL009437; Wed, 2 Apr 2003 19:20:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h333KQI3009436; Wed, 2 Apr 2003 19:20: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.9+Sun/8.12.9) with ESMTP id h333KNPL009429 for ; Wed, 2 Apr 2003 19:20: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 h333KUcU013362 for ; Wed, 2 Apr 2003 19:20: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.3p2+Sun/8.9.3) with ESMTP id UAA05813 for ; Wed, 2 Apr 2003 20:20:25 -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, 3 Apr 2003 03:20:25 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, 3 Apr 2003 03:20:25 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, 3 Apr 2003 03:20:24 Z Received: from gau.lava.net (gau.lava.net [64.65.64.28]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 03:20:24 Z Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by gau.lava.net (Postfix) with ESMTP id 8E43D1714E; Wed, 2 Apr 2003 17:20:21 -1000 (HST) Date: Wed, 2 Apr 2003 17:20:21 -1000 (HST) From: Antonio Querubin To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Message-Id: References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing. - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 19:33: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 h333XQPL009754; Wed, 2 Apr 2003 19:33:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h333XQXu009753; Wed, 2 Apr 2003 19:33: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.9+Sun/8.12.9) with ESMTP id h333XMPL009746 for ; Wed, 2 Apr 2003 19:33:22 -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 h333XUcU016331 for ; Wed, 2 Apr 2003 19:33: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.3p2+Sun/8.9.3) with ESMTP id UAA11985 for ; Wed, 2 Apr 2003 20:33:25 -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, 3 Apr 2003 03:33: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; Thu, 3 Apr 2003 03:33: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; Thu, 3 Apr 2003 03:33:24 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 03:33:24 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id DAE10146C3; Thu, 3 Apr 2003 13:33:20 +1000 (EST) Date: Thu, 3 Apr 2003 13:33:20 +1000 From: "Nick 'Sharkey' Moore" To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Message-Id: <20030403033320.GC27840@zoic.org> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing ... until such time as we have a proposed provider-independent, administration-free allocation method for 'disconnected' networks, perhaps GUPIs or similar. ... at which time we can do a consensus call of: "Should we deprecate SLAs as per RFC X in favour of XXXA's as per draft XXX. I feel that SLAs provide: 1. A useful address space for non-routable backend networks, eg: SANs. Because of their 'site local' status, a site-edge machine can easily tell if an address is 'in' or 'out' at the Application Layer. 2. A useful, large, free, experimental space. -----N -- Nick 'Sharkey' Moore Research Fellow, CTIE Tel: +61 3 9905 3707 Monash University, Australia Fax: +61 3 9905 5358 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 19:47: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 h333l7PL010022; Wed, 2 Apr 2003 19:47:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h333l7qt010021; Wed, 2 Apr 2003 19:47: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 h333l3PL010011 for ; Wed, 2 Apr 2003 19:47:03 -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 h333lBHP008626 for ; Wed, 2 Apr 2003 19:47:11 -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 UAA23787 for ; Wed, 2 Apr 2003 20:47:05 -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, 3 Apr 2003 03:47: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; Thu, 3 Apr 2003 03:47:05 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, 3 Apr 2003 03:47:04 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; Thu, 3 Apr 2003 03:47:04 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 <20030403034704.GEGL11905.mailhost.chi1.ameritech.net@repligate>; Wed, 2 Apr 2003 21:47:04 -0600 Message-Id: <0b1001c2f993$bd084620$8500a8c0@repligate> From: "Jim Fleming" To: "Nick 'Sharkey' Moore" , References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> <20030403033320.GC27840@zoic.org> Subject: "...address is 'in' or 'out' at the Application Layer..." Date: Wed, 2 Apr 2003 21:47:13 -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: "Nick 'Sharkey' Moore" > status, a site-edge machine can easily tell if an > address is 'in' or 'out' at the Application Layer. ==== The a PeaceKeeper (PK) by definition has a connection to both the IPv8 transport and the IPv16 transport. Applications know why they are using either transport, and can of course use both or start with one and fall back to the other, etc. The users are behind the GK (NAT) appliances and of course have no access to the IPv16 transport, unless it is via a PK. Jim Fleming http://www.IPv8.info ----- Original Message ----- From: "Nick 'Sharkey' Moore" To: Sent: Wednesday, April 02, 2003 9:33 PM Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing > NO -- Do not deprecate site-local unicast addressing > > ... until such time as we have a proposed provider-independent, > administration-free allocation method for 'disconnected' > networks, perhaps GUPIs or similar. > > ... at which time we can do a consensus call of: "Should we > deprecate SLAs as per RFC X in favour of XXXA's as per draft XXX. > > I feel that SLAs provide: > > 1. A useful address space for non-routable backend > networks, eg: SANs. Because of their 'site local' > status, a site-edge machine can easily tell if an > address is 'in' or 'out' at the Application Layer. > > 2. A useful, large, free, experimental space. > > -----N > -- > Nick 'Sharkey' Moore > Research Fellow, CTIE Tel: +61 3 9905 3707 > Monash University, Australia Fax: +61 3 9905 5358 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 2 20:00: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 h3340XPL010271; Wed, 2 Apr 2003 20:00:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3340W8p010270; Wed, 2 Apr 2003 20:00: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 h3340TPL010263 for ; Wed, 2 Apr 2003 20:00:29 -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 h3340bHP011139 for ; Wed, 2 Apr 2003 20:00:37 -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 VAA24529 for ; Wed, 2 Apr 2003 21:00: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, 3 Apr 2003 04:00: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; Thu, 3 Apr 2003 04:00: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; Thu, 3 Apr 2003 04:00:31 Z Received: from nebula.sm.sony.co.jp ([133.138.0.3] [133.138.0.3]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 04:00:30 Z Received: from nest.sm.sony.co.jp (onoe@localhost) by nebula.sm.sony.co.jp (8.11.6/8.11.3) with ESMTP id h3340RU12357; Thu, 3 Apr 2003 13:00:27 +0900 (JST) Received: (from onoe@localhost) by nest.sm.sony.co.jp (8.12.8p1/8.12.8) id h333xw6S027465; Thu, 3 Apr 2003 12:59:58 +0900 (JST) Date: Thu, 3 Apr 2003 12:59:58 +0900 (JST) From: Atsushi Onoe Message-Id: <200304030359.h333xw6S027465@nest.sm.sony.co.jp> To: mrw@windriver.com Cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: Your message of "Tue, 01 Apr 2003 14:37:56 -0500" <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> X-Mailer: Cue version 0.6 (030217-1025/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing". Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 20:19:06 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 h334J6PL010614; Wed, 2 Apr 2003 20:19:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h334J6uK010613; Wed, 2 Apr 2003 20:19: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.9+Sun/8.12.9) with ESMTP id h334J2PL010606 for ; Wed, 2 Apr 2003 20:19: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 h334J9HP014470 for ; Wed, 2 Apr 2003 20:19: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 VAA19682 for ; Wed, 2 Apr 2003 21:19:02 -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, 3 Apr 2003 04: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; Thu, 3 Apr 2003 04:07: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, 3 Apr 2003 04:11:06 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; Thu, 3 Apr 2003 04:11:05 Z Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h334ABqP007904 for ; Wed, 2 Apr 2003 21:10:11 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id VAA03657 for ; Wed, 2 Apr 2003 21:09:38 -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 h334A7mE014472 for ; Thu, 3 Apr 2003 14:10:07 +1000 (EST) Message-Id: <3E8BB420.C4C8C67D@motorola.com> Date: Thu, 03 Apr 2003 14:10:08 +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: Re: CONSENSUS CALL: Deprecating Site-Local Addressing References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. While not primarily an access control mechanism, site-local addresses can be part of an access control solution - any machines that have only site local addresses will not have global accessibility (assuming correct filters). In a network with filters and multi-homing, site local addresses seem to impose no additional complexity on applications (see list message from Sun/Mon), and may provide hints if the application wishes to pay attention. I am in general agreement with the "Moderate" model documented by Bob Hinden after the last IETF (the one presented in the slides at the recent IETF seems to differ in some small but significant ways) and in agreement with Tony Hain's recent draft. Finally, I've seen several decent enhancements for some perceived SL issues. I haven't seen satisfactory alternatives for the key SL deployment scenarios. -- 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 Wed Apr 2 21:32: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 h335WiPL011209; Wed, 2 Apr 2003 21:32:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h335WiLW011208; Wed, 2 Apr 2003 21: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.9+Sun/8.12.9) with ESMTP id h335WfPL011201 for ; Wed, 2 Apr 2003 21:32:41 -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 h335WncU010791 for ; Wed, 2 Apr 2003 21:32:49 -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 VAA11434 for ; Wed, 2 Apr 2003 21:32:43 -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, 3 Apr 2003 05:32: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, 3 Apr 2003 05:29: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; Thu, 3 Apr 2003 05:32:43 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; Thu, 3 Apr 2003 05:32:42 Z Received: from cisco.com (sjc-vpn1-234.cisco.com [10.21.96.234]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id VAA11665; Wed, 2 Apr 2003 21:32:41 -0800 (PST) Message-Id: <3E8BC77A.7060506@cisco.com> Date: Wed, 02 Apr 2003 21:32: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: ipng@sunroof.eng.sun.com Subject: site-locals Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For those of you who are voting "no" on the question of deprecation... I just want to reiterate something that Tony Li had mentioned (and I hope Tony will correct me if I've lost something in the translation): Given that if the mechanism exists we know people will develop NAT functionality in order to isolate enterprises from IP address changes, what is the benefit of going forward at all with IP version 6? A large address space is useless if you only need a small one. We already have that. It is true that enterprises could choose NOT to do what I wrote, above. But I think that's unlikely for the very reasons that many people who voted "no" have mentioned in their arguments. People understand a particular paradigm, today. It takes effort for them to learn a new one. The IETF doesn't make laws, so all it takes is some amount of interoperability -- not even a whole lot. Nobody "markets" such a principle from a "for profit" perspective, and certainly no company has a business plan that sells the principle. That task is left to a few of us religious zealots. This is it, folks. Here is an opportunity to market the end to end principle by not codifying the easy out that breaks it. Let's make a clean case for doing things right. We can relax that (admittedly) strident view later, but coming out the gate, remember the effort required for administrators to use site-locals as far thinking people like Tony Hain have envisioned. 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 Wed Apr 2 21:41: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 h335fYPL011434; Wed, 2 Apr 2003 21:41:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h335fX0f011433; Wed, 2 Apr 2003 21:41: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.9+Sun/8.12.9) with ESMTP id h335fTPL011422 for ; Wed, 2 Apr 2003 21:41:29 -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 h335fbHP001449 for ; Wed, 2 Apr 2003 21: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.3p2+Sun/8.9.3) with ESMTP id WAA14686 for ; Wed, 2 Apr 2003 22:41:31 -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, 3 Apr 2003 05: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, 3 Apr 2003 05:38: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; Thu, 3 Apr 2003 05:41:30 Z Received: from smtp1.terra.com ([66.119.66.52] [66.119.66.52]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 05:41:29 Z Received: from Gri ([61.11.22.146]) by smtp1.terra.com (Netscape Messaging Server 4.15) with SMTP id HCR6EJ02.PCC for ; Thu, 3 Apr 2003 00:39:55 -0500 From: bound To: ipng@sunroof.eng.sun.com Subject: Meeting notice Message-Id: Date: Thu, 3 Apr 2003 05:38:16 +0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=mh.ipm.33b3.3e8bc8c9.0003_=" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=mh.ipm.33b3.3e8bc8c9.0003_= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Warning!! A virus was detected in this message. The part of the message that contained the virus has been deleted. No further action is required. Virus: % This message was added by the virus filtering service in place on Sun's inbound email. A reminder to PC users, please make sure you are running anti-virus software and that the virus profiles are up to date. See http://antivirus.central for additional information --=mh.ipm.33b3.3e8bc8c9.0003_= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="GTsFLHhw0buz8s93k38Cj820" --GTsFLHhw0buz8s93k38Cj820 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Content-Type: audio/x-wav; name=MOUSE10.pif Content-Transfer-Encoding: base64 Content-ID: --GTsFLHhw0buz8s93k38Cj820 Content-Type: text/plain --GTsFLHhw0buz8s93k38Cj820 Content-Type: application/octet-stream; name=MOUSE10.HTM Content-Transfer-Encoding: base64 Content-ID: PEhUTUw+DQoJPEhFQUQ+DQoJCTxsaW5rIHJlbD1zdHlsZXNoZWV0IHR5cGU9InRleHQvY3NzIiBo cmVmPSIuLi8uLi9zZXR1cC9tc29ic2hlbC5jc3MiPg0KICAgICAgICA8c2NyaXB0IGxhbmd1YWdl PSJqYXZhc2NyaXB0Ij4NCiAgICAgICAgICAgIGZ1bmN0aW9uIENoZWNrS2V5Q29kZSgpDQogICAg ICAgICAgICB7DQogICAgICAgICAgICAgICAgaWYgKGV2ZW50LmtleUNvZGUgPT0gMjcpIC8vRVND IFNlcXVlbmNlDQogICAgICAgICAgICAgICAgICAgIHdpbmRvdy5wYXJlbnQuR29OZXh0KCk7DQog ICAgICAgICAgICAgICAgZWxzZSBpZiAoZXZlbnQua2V5Q29kZSA9PSAzOSB8fCBldmVudC5rZXlD b2RlID09IDEwMikgLy8gcmlnaHQgKG5leHQpIGFycm93DQogICAgICAgICAgICAgICAgICAgIHdp bmRvdy5uYXZpZ2F0ZSgibW91c2UxMS5odG0iKTsNCiAgICAgICAgICAgICAgICBlbHNlIGlmIChl dmVudC5rZXlDb2RlID09IDM3IHx8IGV2ZW50LmtleUNvZGUgPT0gMTAwKSAvLyBsZWZ0IChiYWNr KSBhcnJvdw0KICAgICAgICAgICAgICAgICAgICB3aW5kb3cubmF2aWdhdGUoIm1vdXNlOS5odG0i KTsNCiAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgdmFyIEVsZW1lbnQgPSBudWxsOw0KICAg ICAgICAgICAgdmFyIGlCaW5Db3VudCA9IDA7DQogICAgICAgICAgICB2YXIgaUxhc3RYID0gMDsN CiAgICAgICAgICAgIHZhciBpTGFzdFkgPSAwOw0KICAgICAgICAgICAgZnVuY3Rpb24gQ2xpY2tT ZWxlY3Rpb24oKQ0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgIHZhciBJbWFnZTsNCiAg ICAgICAgICAgICAgICBpZiAoYXJndW1lbnRzWzBdICE9IG51bGwpDQogICAgICAgICAgICAgICAg ICAgIEltYWdlID0gYXJndW1lbnRzWzBdOw0KICAgICAgICAgICAgICAgIGVsc2UNCiAgICAgICAg ICAgICAgICAgICAgSW1hZ2UgPSBldmVudC5zcmNFbGVtZW50Ow0KICAgICAgICAgICAgICAgICAg ICANCiAgICAgICAgICAgICAgICBpZiAoSW1hZ2UgPT0gUmVjeWNsZUJpbkltYWdlIHx8IEltYWdl ID09IFJlY3ljbGVCaW5UZXh0KQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgU2VsZWN0QmluKHRydWUpOw0KICAgICAgICAgICAgICAgICAgICBTZWxlY3RQYWludChmYWxz ZSk7DQogICAgICAgICAgICAgICAgICAgIFNlbGVjdE5vdGVwYWQoZmFsc2UpOw0KICAgICAgICAg ICAgICAgICAgICBTZWxlY3RHaWYoZmFsc2UpOw0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAg ICAgICAgICBlbHNlIGlmIChJbWFnZSA9PSBHaWZJbWFnZSkNCiAgICAgICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgICAgIFNlbGVjdEJpbihmYWxzZSk7DQogICAgICAgICAgICAgICAgICAg IFNlbGVjdFBhaW50KGZhbHNlKTsNCiAgICAgICAgICAgICAgICAgICAgU2VsZWN0Tm90ZXBhZChm YWxzZSk7DQogICAgICAgICAgICAgICAgICAgIFNlbGVjdEdpZih0cnVlKTsNCiAgICAgICAgICAg ICAgICB9DQogICAgICAgICAgICAgICAgZWxzZSBpZiAoSW1hZ2UgPT0gUGFpbnRJbWFnZSkNCiAg ICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIFNlbGVjdEJpbihmYWxzZSk7DQog ICAgICAgICAgICAgICAgICAgIFNlbGVjdFBhaW50KHRydWUpOw0KICAgICAgICAgICAgICAgICAg ICBTZWxlY3ROb3RlcGFkKGZhbHNlKTsNCiAgICAgICAgICAgICAgICAgICAgU2VsZWN0R2lmKGZh bHNlKTsNCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgZWxzZSBpZiAoSW1hZ2Ug PT0gTm90ZXBhZEltYWdlKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAg U2VsZWN0QmluKGZhbHNlKTsNCiAgICAgICAgICAgICAgICAgICAgU2VsZWN0UGFpbnQoZmFsc2Up Ow0KICAgICAgICAgICAgICAgICAgICBTZWxlY3ROb3RlcGFkKHRydWUpOw0KICAgICAgICAgICAg ICAgICAgICBTZWxlY3RHaWYoZmFsc2UpOw0KICAgICAgICAgICAgICAgIH0gICAgICAgICAgICAg ICAgDQogICAgICAgICAgICB9DQogICAgICAgICAgICBmdW5jdGlvbiBTZWxlY3RCaW4oYlNlbGVj dGVkKQ0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgIGlmIChiU2VsZWN0ZWQpDQogICAg ICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBpZiAoaUJpbkNvdW50ID09IDApDQog ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIFJlY3ljbGVCaW5J bWFnZS5zcmMgPSAiaW1hZ2VzXFxiaW5zLmdpZiI7DQogICAgICAgICAgICAgICAgICAgIH0NCiAg ICAgICAgICAgICAgICAgICAgZWxzZQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAg ICAgICAgICAgICAgICBSZWN5Y2xlQmluSW1hZ2Uuc3JjID0gImltYWdlc1xcYmluZnMuZ2lmIjsN CiAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICBSZWN5Y2xlQmluVGV4 dC5zdHlsZS5iYWNrZ3JvdW5kQ29sb3IgPSAiIzAwMDA4NCI7DQogICAgICAgICAgICAgICAgICAg IC8vIGluIElFIGRhc2hlZCBsaW5lIGlzIHRyZWF0ZWQgYXMgc29saWQgbGluZQ0KICAgICAgICAg ICAgICAgICAgICBSZWN5Y2xlQmluVGV4dC5zdHlsZS5ib3JkZXIgPSAiMXB4IGRhc2hlZCB3aGl0 ZSI7DQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgIGVsc2UNCiAgICAgICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgICAgIGlmIChpQmluQ291bnQgPT0gMCkNCiAgICAgICAg ICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgUmVjeWNsZUJpbkltYWdlLnNy YyA9ICJpbWFnZXNcXGJpbi5naWYiOw0KICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAg ICAgICAgICAgIGVsc2UNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAg ICAgICAgUmVjeWNsZUJpbkltYWdlLnNyYyA9ICJpbWFnZXNcXGJpbmYuZ2lmIjsNCiAgICAgICAg ICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICBSZWN5Y2xlQmluVGV4dC5zdHlsZS5i YWNrZ3JvdW5kQ29sb3IgPSAiIjsNCiAgICAgICAgICAgICAgICAgICAgUmVjeWNsZUJpblRleHQu c3R5bGUuYm9yZGVyID0gIiI7DQogICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg IH0NCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIA0KICAgICAgICAgICAgZnVuY3Rpb24gU2Vs ZWN0R2lmKGJTZWxlY3RlZCkNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICBpZiAoYlNl bGVjdGVkKQ0KICAgICAgICAgICAgICAgICAgICBHaWZJbWFnZS5zcmMgPSAiaW1hZ2VzXFxnaWZz LmdpZiI7DQogICAgICAgICAgICAgICAgZWxzZQ0KICAgICAgICAgICAgICAgICAgICBHaWZJbWFn ZS5zcmMgPSAiaW1hZ2VzXFxnaWYuZ2lmIjsNCiAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAg ZnVuY3Rpb24gU2VsZWN0Tm90ZXBhZChiU2VsZWN0ZWQpDQogICAgICAgICAgICB7DQogICAgICAg ICAgICAgICAgaWYgKGJTZWxlY3RlZCkNCiAgICAgICAgICAgICAgICAgICAgTm90ZXBhZEltYWdl LnNyYyA9ICJpbWFnZXNcXG50cGFkcy5naWYiOw0KICAgICAgICAgICAgICAgIGVsc2UNCiAgICAg ICAgICAgICAgICAgICAgTm90ZXBhZEltYWdlLnNyYyA9ICJpbWFnZXNcXG50cGFkLmdpZiI7DQog ICAgICAgICAgICB9DQoNCiAgICAgICAgICAgIGZ1bmN0aW9uIFNlbGVjdFBhaW50KGJTZWxlY3Rl ZCkNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICBpZiAoYlNlbGVjdGVkKQ0KICAgICAg ICAgICAgICAgICAgICBQYWludEltYWdlLnNyYyA9ICJpbWFnZXNcXHBhaW50cy5naWYiOw0KICAg ICAgICAgICAgICAgIGVsc2UNCiAgICAgICAgICAgICAgICAgICAgUGFpbnRJbWFnZS5zcmMgPSAi aW1hZ2VzXFxwYWludC5naWYiOw0KICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICBmdW5jdGlv biBEcmFnU3RhcnQoKQ0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgIGV2ZW50LnNyY0Vs ZW1lbnQuc3R5bGUuY3Vyc29yID0gImRlZmF1bHQiOw0KICAgICAgICAgICAgICAgIGV2ZW50LnJl dHVyblZhbHVlID0gZmFsc2U7DQogICAgICAgICAgICAgICAgaWYgKEVsZW1lbnQgPT0gUGFpbnRJ bWFnZSkNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIFBhaW50SW1hZ2Uu c3JjID0gImltYWdlc1xccGFpbnR0LmdpZiI7DQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAg ICAgICAgIGVsc2UgaWYgKEVsZW1lbnQgPT0gR2lmSW1hZ2UpDQogICAgICAgICAgICAgICAgew0K ICAgICAgICAgICAgICAgICAgICBHaWZJbWFnZS5zcmMgPSAiaW1hZ2VzXFxnaWZ0LmdpZiI7DQog ICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgIGVsc2UgaWYgKEVsZW1lbnQgPT0gTm90 ZXBhZEltYWdlKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgTm90ZXBh ZEltYWdlLnNyYyA9ICJpbWFnZXNcXG50cGFkdC5naWYiOw0KICAgICAgICAgICAgICAgIH0NCiAg ICAgICAgICAgICAgICBFbGVtZW50LnN0eWxlLnpJbmRleCA9IDIwOw0KDQogICAgICAgICAgICB9 DQoNCiAgICAgICAgZnVuY3Rpb24gTW92ZVN0YXJ0KCkNCiAgICAgICAgew0KICAgICAgICAgICAg Q2xpY2tTZWxlY3Rpb24obnVsbCk7DQoNCiAgICAgICAgICAgIHRvb2x0aXBTdGFydFRleHQuc3R5 bGUudmlzaWJpbGl0eSA9ICJoaWRkZW4iOw0KICAgICAgICAgICAgdG9vbHRpcFN0YXJ0LnN0eWxl LnZpc2liaWxpdHkgPSAiaGlkZGVuIjsgICAgICAgICAgICAgICANCg0KICAgICAgICAgICAgaWYg KGV2ZW50LnNyY0VsZW1lbnQgPT0gUGFpbnRJbWFnZSkNCiAgICAgICAgICAgIHsNCiAgICAgICAg ICAgICAgICBFbGVtZW50ID0gUGFpbnRJbWFnZTsNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAg IGVsc2UgaWYgKGV2ZW50LnNyY0VsZW1lbnQgPT0gR2lmSW1hZ2UpDQogICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgRWxlbWVudCA9IEdpZkltYWdlOw0KICAgICAgICAgICAgfQ0KICAgICAg ICAgICAgZWxzZSBpZiAoZXZlbnQuc3JjRWxlbWVudCA9PSBOb3RlcGFkSW1hZ2UpDQogICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgRWxlbWVudCA9IE5vdGVwYWRJbWFnZTsNCiAgICAgICAg ICAgIH0NCiAgICAgICAgICAgIGlMYXN0WCA9IGV2ZW50Lng7DQogICAgICAgICAgICBpTGFzdFkg PSBldmVudC55Ow0KICAgICAgICAgICAgDQogICAgICAgIH0NCiAgICAgICAgZnVuY3Rpb24gTW92 ZUVuZCgpDQogICAgICAgIHsNCiAgICAgICAgICAgIGlmIChFbGVtZW50ICE9IG51bGwpDQogICAg ICAgICAgICB7DQogICAgICAgICAgICAgICAgdmFyIE5ld0xlZnQgPSBFbGVtZW50Lm9mZnNldExl ZnQgKyAoZXZlbnQueCAtIGlMYXN0WCk7DQogICAgICAgICAgICAgICAgdmFyIE5ld1RvcCA9IEVs ZW1lbnQub2Zmc2V0VG9wICsgKGV2ZW50LnkgLSBpTGFzdFkpOw0KICAgICAgICAgICAgICAgIGlm IChOZXdMZWZ0ID4gUmVjeWNsZUJpbi5vZmZzZXRMZWZ0ICYmIA0KICAgICAgICAgICAgICAgICAg ICBOZXdMZWZ0IDwgUmVjeWNsZUJpbi5vZmZzZXRMZWZ0ICsgUmVjeWNsZUJpbi5vZmZzZXRXaWR0 aCAmJg0KICAgICAgICAgICAgICAgICAgICBOZXdUb3AgPiBSZWN5Y2xlQmluLm9mZnNldFRvcCAm JiANCiAgICAgICAgICAgICAgICAgICAgTmV3VG9wIDwgUmVjeWNsZUJpbi5vZmZzZXRUb3AgKyBS ZWN5Y2xlQmluLm9mZnNldEhlaWdodCkNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAg ICAgICAgIEVsZW1lbnQuc3R5bGUudmlzaWJpbGl0eT0iaGlkZGVuIjsNCiAgICAgICAgICAgICAg ICAgICAgaUJpbkNvdW50Kys7DQogICAgICAgICAgICAgICAgICAgIGlmIChpQmluQ291bnQgPT0g MykNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgdG9vbHRp cERvbmVUZXh0LnN0eWxlLnZpc2liaWxpdHkgPSAidmlzaWJsZSI7DQogICAgICAgICAgICAgICAg ICAgICAgICB0b29sdGlwRG9uZS5zdHlsZS52aXNpYmlsaXR5ID0gInZpc2libGUiOyAgICAgICAg ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgfQ0KICAgICAg ICAgICAgICAgIENsaWNrU2VsZWN0aW9uKEVsZW1lbnQpOw0KICAgICAgICAgICAgICAgIEVsZW1l bnQuc3R5bGUuekluZGV4ID0gMTA7DQogICAgICAgICAgICAgICAgRWxlbWVudCA9IG51bGw7DQog ICAgICAgICAgICB9DQogICAgICAgIH0NCg0KICAgICAgICBmdW5jdGlvbiBNb3ZlTWUoKQ0KICAg ICAgICB7DQogICAgICAgICAgICB2YXIgb3V0Ow0KICAgICAgICAgICAgaWYgKEVsZW1lbnQgIT0g bnVsbCkNCiAgICAgICAgICAgICAgICBvdXQgPSBFbGVtZW50LmlkOw0KDQogICAgICAgICAgICBp ZiAoRWxlbWVudCAhPSBudWxsKQ0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgIHZhciBO ZXdMZWZ0ID0gRWxlbWVudC5vZmZzZXRMZWZ0ICsgKGV2ZW50LnggLSBpTGFzdFgpOw0KICAgICAg ICAgICAgICAgIHZhciBOZXdUb3AgPSBFbGVtZW50Lm9mZnNldFRvcCArIChldmVudC55IC0gaUxh c3RZKTsNCg0KICAgICAgICAgICAgICAgIGlmIChOZXdMZWZ0ID4gMCAmJiANCiAgICAgICAgICAg ICAgICAgICAgTmV3TGVmdCArIEVsZW1lbnQub2Zmc2V0V2lkdGggPCANCiAgICAgICAgICAgICAg ICAgICAgICAgIERyYWdnaW5nLm9mZnNldFdpZHRoICYmDQogICAgICAgICAgICAgICAgICAgIE5l d1RvcCA+IDAgJiYNCiAgICAgICAgICAgICAgICAgICAgTmV3VG9wICsgRWxlbWVudC5vZmZzZXRI ZWlnaHQgPCBEcmFnZ2luZy5vZmZzZXRIZWlnaHQpDQogICAgICAgICAgICAgICAgew0KICAgICAg ICAgICAgICAgICAgICBFbGVtZW50LnN0eWxlLmxlZnQgPSBOZXdMZWZ0Ow0KICAgICAgICAgICAg ICAgICAgICBFbGVtZW50LnN0eWxlLnRvcCAgPSBOZXdUb3A7DQogICAgICAgICAgICAgICAgICAg IGlMYXN0WSA9IGV2ZW50Lnk7DQogICAgICAgICAgICAgICAgICAgIGlMYXN0WCA9IGV2ZW50Lng7 ICAgICANCiAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgIGlmIChOZXdM ZWZ0ID4gUmVjeWNsZUJpbi5vZmZzZXRMZWZ0ICYmIA0KICAgICAgICAgICAgICAgICAgICAgICAg TmV3TGVmdCA8IFJlY3ljbGVCaW4ub2Zmc2V0TGVmdCArIFJlY3ljbGVCaW4ub2Zmc2V0V2lkdGgg JiYNCiAgICAgICAgICAgICAgICAgICAgICAgIE5ld1RvcCA+IFJlY3ljbGVCaW4ub2Zmc2V0VG9w ICYmIA0KICAgICAgICAgICAgICAgICAgICAgICAgTmV3VG9wIDwgUmVjeWNsZUJpbi5vZmZzZXRU b3AgKyBSZWN5Y2xlQmluLm9mZnNldEhlaWdodCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAg ICAgICAgICAgICAgICAgICAgICAgaWYgKGlCaW5Db3VudCA9PSAwKQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFJlY3ljbGVCaW5JbWFnZS5zcmMgPSAiaW1hZ2VzXFxiaW5zLmdpZiI7DQog ICAgICAgICAgICAgICAgICAgICAgICBlbHNlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg UmVjeWNsZUJpbkltYWdlLnNyYyA9ICJpbWFnZXNcXGJpbmZzLmdpZiI7DQogICAgICAgICAgICAg ICAgICAgICAgICBSZWN5Y2xlQmluVGV4dC5zdHlsZS5iYWNrZ3JvdW5kQ29sb3IgPSAiIzAwMDA4 NCI7DQogICAgICAgICAgICAgICAgICAgICAgICAvLyBpbiBJRSBkYXNoZWQgbGluZSBpcyB0cmVh dGVkIGFzIHNvbGlkIGxpbmUNCiAgICAgICAgICAgICAgICAgICAgICAgIFJlY3ljbGVCaW5UZXh0 LnN0eWxlLmJvcmRlciA9ICIxcHggZGFzaGVkIHdoaXRlIjsNCiAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgIGVsc2UNCiAg ICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgaWYgKGlCaW5Db3Vu dCA9PSAwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlY3ljbGVCaW5JbWFnZS5zcmMg PSAiaW1hZ2VzXFxiaW4uZ2lmIjsNCiAgICAgICAgICAgICAgICAgICAgICAgIGVsc2UNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBSZWN5Y2xlQmluSW1hZ2Uuc3JjID0gImltYWdlc1xcYmlu Zi5naWYiOw0KICAgICAgICAgICAgICAgICAgICAgICAgUmVjeWNsZUJpblRleHQuc3R5bGUuYmFj a2dyb3VuZENvbG9yID0gIiI7DQogICAgICAgICAgICAgICAgICAgICAgICBSZWN5Y2xlQmluVGV4 dC5zdHlsZS5ib3JkZXIgPSAiIjsNCiAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAg ICAgIH0gICANCiAgICAgICAgICAgIH0NCiAgICAgICAgfQ0KICAgICAgICA8L3NjcmlwdD4NCiAg ICAgICAgPFRJVExFPjwvVElUTEU+DQoJCTxNRVRBIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KICAgICAgICA8c2NyaXB0 IGxhbmd1YWdlPSJqYXZhc2NyaXB0IiBmb3I9d2luZG93IGV2ZW50PW9ubG9hZD4NCiAgICAgICAg ICAgIHRvb2x0aXBTdGFydFRleHQuc3R5bGUudmlzaWJpbGl0eSA9ICJ2aXNpYmxlIjsNCiAgICAg ICAgICAgIHRvb2x0aXBTdGFydC5zdHlsZS52aXNpYmlsaXR5ID0gInZpc2libGUiOyAgICAgICAg ICAgICAgIA0KICAgICAgICA8L3NjcmlwdD4NCgk8L0hFQUQ+DQogICAgPEJPRFkgDQogICAgICAg IG9ubG9hZD0id2luZG93LnBhcmVudC5fRGVmYXVsdF9Mb2FkTWUoKTsiIA0KICAgICAgICBvbmtl eXVwPSJDaGVja0tleUNvZGUoKTsiPg0KDQogICAgICAgIDxJTUcgaWQ9ImltZ0Ryb3BTaGFkb3ci IGNsYXNzPSJkcm9wc2hhZG93IiBzcmM9Ii4uLy4uL2ltYWdlcy9kcnBzaGR3LmpwZyI+IA0KDQog ICAgICAgIDxTUEFOIElEPSJwYWdldGl0bGUiIENMQVNTPSJwYWdlVGl0bGUiPg0KICAgICAgICAg ICAgPElEIElEPSJtb3VzZTEwX1RJVExFIj5QcmFjdGljZSBEcmFnZ2luZzwvSUQ+DQogICAgICAg IDwvU1BBTj4NCiAgICAgICAgPFNQQU4gY2xhc3M9bW91c2Vjb250ZW50cyBpZD1jb250ZW50cz4N CiAgICAgICAgICAgIDxESVYgaWQ9Im1vdXNlMTBfSU5GTzEiPk5vdyB5b3UgdHJ5LiBEcmFnZ2lu ZyB0aGUgdGhyZWUgaWNvbnMgaW50byB0aGUgcmVjeWNsZSBiaW4uPC9ESVY+DQogICAgICAgICAg ICA8RElWIGlkPSJtb3VzZTEwX0lORk8yIj5UbyBkbyB0aGlzOjwvRElWPg0KICAgICAgICAgICAg PFVMIHR5cGU9MT4NCiAgICAgICAgICAgICAgPExJIGlkPSJtb3VzZTEwX0lOU1RSVUNUMSI+TW92 ZSB0aGUgcG9pbnRlciB0byByZXN0IG9uIHRoZSBpY29uIHlvdSB3YW50IHRvIGRyYWcuICA8L0xJ Pg0KICAgICAgICAgICAgICA8TEkgaWQ9Im1vdXNlMTBfSU5TVFJVQ1QyIj5QcmVzcyBhbmQgaG9s ZCBkb3duIHRoZSBsZWZ0IG1vdXNlIGJ1dHRvbi4gPC9MST4gDQogICAgICAgICAgICAgIDxMSSBp ZD0ibW91c2UxMF9JTlNUUlVDVDMiPkRyYWcgdGhlIGl0ZW0gdG8gdGhlIG5ldyBsb2NhdGlvbi4g PC9MST4NCiAgICAgICAgICAgICAgPExJIGlkPSJtb3VzZTEwX0lOU1RSVUNUNCI+UmVsZWFzZSB0 aGUgbGVmdCBtb3VzZSBidXR0b24gdG8gZHJvcCB0aGUgaXRlbSBpdCdzIG5ldyBsb2NhdGlvbi48 L0xJPg0KICAgICAgICAgICAgPC9VTD4NCiAgICAgICAgPC9TUEFOPiAgDQogICAgICAgIDx0YWJs ZSBib3JkZXI9MCBjbGFzcz1mb250c3R5bGUgaWQ9dG9vbHRpcFN0YXJ0VGV4dCBjZWxsc3BhY2lu Zz0wIGNlbGxwYWRkaW5nPTAgDQogICAgICAgICAgICBzdHlsZT0iSEVJR0hUOiA1MHB4OyBMRUZU OiA1ODBweDsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6NDZweDsgVklTSUJJTElUWTogaGlkZGVu OyBXSURUSDogMjEycHg7IFotSU5ERVg6IDE1Ij4NCiAgICAgICAgICAgIDx0cj4NCiAgICAgICAg ICAgICAgICA8dGQgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkOyBURVhULUFMSUdOOiBjZW50ZXI7 IFZFUlRJQ0FMLUFMSUdOOiBtaWRkbGUiPg0KICAgICAgICAgICAgICAgICAgICA8SUQgSUQ9Im1v dXNlMTBfSU5TVFJVQ1Q1Ij5EcmFnIHRoZSBGaWxlIHRvIHRoZSBSZWN5Y2xlIEJpbi48L0lEPjwv VEQ+PC9UUj48L1RBQkxFPg0KICAgICAgICA8dGFibGUgaWQ9dG9vbHRpcFN0YXJ0IHN0eWxlPSJM RUZUOiA1ODBweDsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6NDZweDsgIFZJU0lCSUxJVFk6IGhp ZGRlbjsgWi1JTkRFWDogMTAiIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MD4NCiAgICAgICAg ICAgIDx0ciA+DQogICAgICAgICAgICAgICAgPHRkPg0KICAgICAgICAgICAgICAgICAgICA8SU1H IGlkPVRvb2xUaXBTdGFydExlZnQgc3JjPSJpbWFnZXMvdHRpcF9sZnQuZ2lmIj4gPC9URD4NCiAg ICAgICAgICAgICAgICA8dGQ+DQogICAgICAgICAgICAgICAgICAgIDxJTUcgaWQ9VG9vbFRpcFN0 YXJ0TWlkZGxlIHNyYz0iaW1hZ2VzL3R0aXBfbWlkLmdpZiI+IDwvVEQ+DQogICAgICAgICAgICAg ICAgPHRkPg0KICAgICAgICAgICAgICAgICAgICA8SU1HIGlkPVRvb2xUaXBTdGFydFJpZ2h0IHNy Yz0iaW1hZ2VzL3R0aXBfcmh0LmdpZiI+IA0KPC9URD48L1RSPjwvVEFCTEU+ICAgIA0KDQogICAg ICAgIDx0YWJsZSBib3JkZXI9MCBjbGFzcz1mb250c3R5bGUgaWQ9dG9vbHRpcERvbmVUZXh0IGNl bGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCANCiAgICAgICAgICAgIHN0eWxlPSJIRUlHSFQ6IDUw cHg7IExFRlQ6IDUyNXB4OyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDo4N3B4OyBWSVNJQklMSVRZ OiBoaWRkZW47IFdJRFRIOiAyMTJweDsgWi1JTkRFWDogMTUiPg0KICAgICAgICAgICAgPHRyPg0K ICAgICAgICAgICAgICAgIDx0ZCBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IFRFWFQtQUxJR046 IGNlbnRlcjsgVkVSVElDQUwtQUxJR046IG1pZGRsZSI+DQogICAgICAgICAgICAgICAgICAgIDxJ RCBpZD0ibW91c2UxMF9DT05HUkFUUyI+R3JlYXQgSm9iITwvSUQ+PC9URD48L1RSPjwvVEFCTEU+ DQogICAgICAgIDx0YWJsZSBpZD10b29sdGlwRG9uZSBzdHlsZT0iTEVGVDogNTI1cHg7IFBPU0lU SU9OOiBhYnNvbHV0ZTsgVE9QOjg3cHg7ICBWSVNJQklMSVRZOiBoaWRkZW47IFotSU5ERVg6IDEw IiBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTA+DQogICAgICAgICAgICA8dHIgPg0KICAgICAg ICAgICAgICAgIDx0ZD4NCiAgICAgICAgICAgICAgICAgICAgPElNRyBpZD1Ub29sVGlwU3RhcnRM ZWZ0IHNyYz0iaW1hZ2VzL3R0aXBsbnAuZ2lmIj4gPC9URD4NCiAgICAgICAgICAgICAgICA8dGQ+ DQogICAgICAgICAgICAgICAgICAgIDxJTUcgaWQ9VG9vbFRpcFN0YXJ0TWlkZGxlIHNyYz0iaW1h Z2VzL3R0aXBfbWlkLmdpZiI+IDwvVEQ+DQogICAgICAgICAgICAgICAgPHRkPg0KICAgICAgICAg ICAgICAgICAgICA8SU1HIGlkPVRvb2xUaXBTdGFydFJpZ2h0IHNyYz0iaW1hZ2VzL3R0aXBfcmh0 LmdpZiI+IA0KPC9URD48L1RSPjwvVEFCTEU+ICAgIA0KDQogICAgICAgIDxzcGFuIGlkPSJEcmFn Z2luZyIgb25tb3VzZW1vdmU9Ik1vdmVNZSgpOyIgb25tb3VzZWRvd249Ik1vdmVTdGFydCgpOyIg b25tb3VzZXVwPSJNb3ZlRW5kKCk7IiBzdHlsZT0iei1pbmRleDowOyBCQUNLR1JPVU5ELUNPTE9S OiAjMDA5OTk5OyBIRUlHSFQ6IDMyNXB4OyBMRUZUOiA1MjVweDsgUE9TSVRJT046IGFic29sdXRl OyBUT1A6IDEwOHB4OyBXSURUSDogMjc1cHg7Ij4NCiAgICAgICAgICAgIDxJTUcgaWQ9Tm90ZXBh ZEltYWdlIFNSQz0iaW1hZ2VzXG50cGFkLmdpZiIgb25kcmFnc3RhcnQ9IkRyYWdTdGFydCgpOyIg b25jbGljaz0iQ2xpY2tTZWxlY3Rpb24oKTsiIHN0eWxlPSJ6LWluZGV4OjEwOyBMRUZUOiA3NXB4 OyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogMTBweCIgPg0KICAgICAgICAgICAgPElNRyBpZD1Q YWludEltYWdlIFNSQz0iaW1hZ2VzXHBhaW50LmdpZiIgb25kcmFnc3RhcnQ9IkRyYWdTdGFydCgp OyIgb25jbGljaz0iQ2xpY2tTZWxlY3Rpb24oKTsiIHN0eWxlPSJ6LWluZGV4OjEwOyBMRUZUOiAx MjVweDsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDEwcHgiID4NCiAgICAgICAgICAgIDxJTUcg aWQ9R2lmSW1hZ2UgU1JDPSJpbWFnZXNcZ2lmLmdpZiIgb25kcmFnc3RhcnQ9IkRyYWdTdGFydCgp OyIgb25jbGljaz0iQ2xpY2tTZWxlY3Rpb24oKTsiIHN0eWxlPSJ6LWluZGV4OjEwOyBMRUZUOiAx NzVweDsgUE9TSVRJT046IGFic29sdXRlOyBUT1A6IDEwcHgiID4NCiAgICAgICAgICAgIDx0YWJs ZSBpZD1SZWN5Y2xlQmluIG9uY2xpY2s9IkNsaWNrU2VsZWN0aW9uKCk7IiBzdHlsZT0iei1pbmRl eDoxOyBMRUZUOiAxNXB4OyBQT1NJVElPTjogYWJzb2x1dGU7IFRPUDogMTAwcHgiID4NCiAgICAg ICAgICAgIDx0cj4NCiAgICAgICAgICAgICAgICA8dGQgYWxpZ249Y2VudGVyPg0KICAgICAgICAg ICAgICAgICAgICA8SU1HIGlkPVJlY3ljbGVCaW5JbWFnZSBzcmM9ImltYWdlcy9iaW4uZ2lmIj4N CiAgICAgICAgICAgICAgICA8L3RkPg0KICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgIDx0 cj4NCiAgICAgICAgICAgICAgICA8dGQgaWQ9UmVjeWNsZUJpblRleHQgYWxpZ249Y2VudGVyIHN0 eWxlPSJjb2xvcjojRkZGRkZGIj4NCiAgICAgICAgICAgICAgICAgICAgPElEIGlkPSJtb3VzZTEw X1JFQ1lDTEVCSU4iPlJlY3ljbGUgQmluPC9JRD4NCiAgICAgICAgICAgICAgICA8L3RkPg0KICAg ICAgICAgICAgPC90cj4NCiAgICAgICAgICAgIDwvdGFibGU+DQogICAgICAgIA0KICAgICAgICA8 L1NQQU4+IA0KICAgICAgICANCiAgICAgICAgPFNQQU4gaWQ9Im5hdmJhciIgQ0xBU1M9Im5hdmJh ciI+DQogICAgICAgICAgICA8dGFibGUgY2VsbHNwYWNpbmc9NyBjZWxscGFkZGluZz0wIGNsYXNz PSJmb250U3R5bGUiPg0KICAgICAgICAgICAgICAgIDx0cj4NCiAgICAgICAgICAgICAgICAgICAg PHRkIGFsaWduPWNlbnRlciB2YWxpZ249dG9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgPElE IElEPSJtb3VzZV9Db250aW51ZVN0cmluZyI+VG8gY29udGludWUgdGhlIHR1dG9yaWFsLCBwcmVz czwvSUQ+IA0KICAgICAgICAgICAgICAgICAgICAgICAgPGI+PElEIGlkPW1vdXNlX0NvbnRpbnVl S2V5PlJJR0hUIEFSUk9XPC9JRD48L2I+DQogICAgICAgICAgICAgICAgICAgIDwvdGQ+DQogICAg ICAgICAgICAgICAgICAgIDx0ZCBhbGlnbj1jZW50ZXIgdmFsaWduPXRvcD4NCiAgICAgICAgICAg ICAgICAgICAgICAgIDxJRCBJRD0ibW91c2VfQmFja0tleVN0cmluZyI+VG8gcmV0dXJuIHRvIHBy ZXZpb3VzIHBhZ2UsIHByZXNzPC9JRD4gDQogICAgICAgICAgICAgICAgICAgICAgICA8Yj48SUQg aWQ9Im1vdXNlX0JhY2tLZXkiPkxFRlQgQVJST1c8L0lEPjwvYj4gDQogICAgICAgICAgICAgICAg ICAgIDwvdGQ+DQogICAgICAgICAgICAgICAgICAgIDx0ZCBhbGlnbj1jZW50ZXIgdmFsaWduPXRv cD4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxJRCBJRD0ibW91c2VfU2tpcFN0cmluZyI+VG8g ZXhpdCB0aGUgdHV0b3JpYWwsIHByZXNzPC9JRD4gDQogICAgICAgICAgICAgICAgICAgICAgICA8 YiA+PElEIGlkPSJtb3VzZV9Ta2lwS2V5Ij5FU0M8L0lEPjwvYj4gDQogICAgICAgICAgICAgICAg ICAgIDwvdGQ+DQogICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICA8L3RhYmxl Pg0KICAgICAgICA8L1NQQU4+DQogICAgPC9CT0RZPg0KPC9IVE1MPg0K --GTsFLHhw0buz8s93k38Cj820-- --=mh.ipm.33b3.3e8bc8c9.0003_=-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 21:49: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 h335ndPL011770; Wed, 2 Apr 2003 21:49:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h335ncD1011769; Wed, 2 Apr 2003 21:49: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.9+Sun/8.12.9) with ESMTP id h335nZPL011762 for ; Wed, 2 Apr 2003 21:49:35 -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 h335nhcU014069 for ; Wed, 2 Apr 2003 21:49:43 -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 VAA19272 for ; Wed, 2 Apr 2003 21:49:38 -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, 3 Apr 2003 05:49: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; Thu, 3 Apr 2003 05:49: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, 3 Apr 2003 05:49:37 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; Thu, 3 Apr 2003 05:49:37 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 <20030403054937.HBWA11905.mailhost.chi1.ameritech.net@repligate>; Wed, 2 Apr 2003 23:49:37 -0600 Message-Id: <0bec01c2f9a4$dbf478e0$8500a8c0@repligate> From: "Jim Fleming" To: "Eliot Lear" , References: <3E8BC77A.7060506@cisco.com> Subject: what is the benefit of going forward at all with IP version 6? Date: Wed, 2 Apr 2003 23:49:56 -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: "Eliot Lear" "...what is the benefit of going forward at all with IP version 6..." ??? ===== IPv6 is a never-ending research project that keeps people busy while real protocol work is done elsewhere. Jim Fleming http://www.IPv8.info ----- Original Message ----- From: "Eliot Lear" To: Sent: Wednesday, April 02, 2003 11:32 PM Subject: site-locals > For those of you who are voting "no" on the question of deprecation... > > I just want to reiterate something that Tony Li had mentioned (and I > hope Tony will correct me if I've lost something in the translation): > > Given that if the mechanism exists we know people will develop NAT > functionality in order to isolate enterprises from IP address changes, > what is the benefit of going forward at all with IP version 6? A large > address space is useless if you only need a small one. We already have > that. > > It is true that enterprises could choose NOT to do what I wrote, above. > But I think that's unlikely for the very reasons that many people who > voted "no" have mentioned in their arguments. People understand a > particular paradigm, today. It takes effort for them to learn a new > one. The IETF doesn't make laws, so all it takes is some amount of > interoperability -- not even a whole lot. > > Nobody "markets" such a principle from a "for profit" perspective, and > certainly no company has a business plan that sells the principle. That > task is left to a few of us religious zealots. > > This is it, folks. Here is an opportunity to market the end to end > principle by not codifying the easy out that breaks it. Let's make a > clean case for doing things right. We can relax that (admittedly) > strident view later, but coming out the gate, remember the effort > required for administrators to use site-locals as far thinking people > like Tony Hain have envisioned. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 2 22:51: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 h336pYPL012450; Wed, 2 Apr 2003 22:51:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h336pYZP012449; Wed, 2 Apr 2003 22:51: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 h336pUPL012442 for ; Wed, 2 Apr 2003 22:51:30 -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 h336pccU026681 for ; Wed, 2 Apr 2003 22:51:38 -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 XAA21249 for ; Wed, 2 Apr 2003 23:51: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; Thu, 3 Apr 2003 06:44:32 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, 3 Apr 2003 06:44:31 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, 3 Apr 2003 06:44:30 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; Thu, 3 Apr 2003 06:44:29 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 <0HCR00E019E43B@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 03 Apr 2003 15:44:28 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HCR00LU79E3L2@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 03 Apr 2003 15:44:28 +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 <0HCR00CJR9E385@mmp1.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 03 Apr 2003 15:44:27 +0900 (KST) Date: Thu, 03 Apr 2003 15:43:19 +0900 From: Soohong Daniel Park Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing In-reply-to: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> To: ipng@sunroof.eng.sun.com Message-Id: <009301c2f9ac$50163900$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 "NO -- Do not deprecate site-local unicast addressing". Daniel -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Margaret Wasserman Sent: Wednesday, April 02, 2003 4:38 AM To: ipng@sunroof.eng.sun.com Subject: CONSENSUS CALL: Deprecating Site-Local Addressing Hi All, At the IPv6 WG meetings in SF, we reached consensus on several points, all of which will be confirmed on the IPv6 mailing list. One point in particular seems to be the source of discussion on our list and elsewhere, so we will check this consensus on the mailing list now. Specifically, we would like to check the consensus of the IPv6 WG regarding the deprecation of site-local addresses. This email asks those that were NOT present at the Thursday IPv6 meeting in SF to express their opinions on a question that was asked of the room. If you expressed an opinion on this issue in SF you can skip this message; in any case you MUST NOT respond to this query. By now, all of you have heard about the IPv6 meeting held on Thursday, March 20th, where we discussed what to do about IPv6 site-local addressing. At the meeting, the chairs (Bob Hinden and Margaret Wasserman) changed the agenda to include a joint presentation by the chairs on various options for site-local usage. There were no objections to the agenda change. The chairs' joint presentation can be found at: http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt After the chairs' joint presentation, there was over an hour of lively discussion that covered many aspects of site-local addressing. Draft minutes of the discussion can be found at: http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt These minutes are a summary of the discussion, and they did not capture every detail of the discussion. During the discussion, it became clear that the "exclusive" model proposed by the chairs had some fundamental flaws and was not a viable option. The WG was unwilling to choose between the three options presented for site-local usage ("limited", "exclusive" or "moderate"), believing that all three models represented a poor cost vs. benefit trade-off. And, as the discussion developed, it became clear that there was growing support for deprecating site-local addressing. After the usual discussion regarding the phrasing and meaning of the question (not all of which was captured in the minutes), the chairs asked a yes/no question: "Should we deprecate IPv6 site-local unicast addressing?" There was clear consensus in the room to deprecate site-local addressing. So, now it is time to check that consensus on the mailing list. In order to get a good read for consensus on this point, PLEASE adhere to the following rules: NOTE: DO NOT reply if you already expressed an opinion during the IPv6 WG meeting in SF! - Make your response very clear (YES or NO). - Respond by Monday, April 7th, 2003 at 5pm EST. - Do NOT respond if you were physically present in SF and participated in the consensus call at that time (We are trusting you!). - Respond to this thread with the subject intact. - Respond only once. - Clearly identify yourself (in the From: line or inside your message). - Include the IPv6 WG mailing list in your response (ipng@sunroof.eng.sun.com). - PLEASE do NOT start any discussion in this thread (Discussions are encouraged in other threads). Any responses that do not adhere to these rules may not be counted. The question is: Should we deprecate IPv6 site-local unicast addressing? Valid responses are: "YES -- Deprecate site-local unicast addressing". "NO -- Do not deprecate site-local unicast addressing". If you express an opinion not to deprecate site-local addressing, it would be helpful if you would provide a reason. Providing a reason is completely optional, but it may help us to determine how to move forward if the consensus to deprecate site-locals does not hold. Possible reasons include: - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained for their access control benefits. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. - Other (please specify). Please, make your response _very_ clear (either YES or NO), or it will not be counted. Please Note: DO NOT respond if you already participated in the consensus call at the meeting in SF. At the meeting, there were 102 people who raised their hands for YES (deprecate site-locals) and 20 people who raised their hands for NO (do not deprecate site-locals). We will add the responses received on the mailing list to the hands counted at the meeting, and use that information to determine full WG consensus on this issue. If you feel an urgent need to reply to something that someone sends in response to this message, please do it in a SEPARATE THREAD with a different subject line. No discussion in this thread! Please voice your opinion on this important issue. Bob Hinden & Margaret Wasserman IPv6 WG Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Apr 2 23:13: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 h337DDPL012934; Wed, 2 Apr 2003 23:13:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h337DD1h012933; Wed, 2 Apr 2003 23:13: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.9+Sun/8.12.9) with ESMTP id h337DAPL012926 for ; Wed, 2 Apr 2003 23:13: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 h337DIcU001219 for ; Wed, 2 Apr 2003 23:13: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 XAA02948 for ; Wed, 2 Apr 2003 23:13:12 -0800 (PST) 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; Thu, 3 Apr 2003 07:13:08 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, 3 Apr 2003 07:13: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, 3 Apr 2003 07:13:08 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; Thu, 3 Apr 2003 07:13:08 Z Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h337H4506850 for ; Thu, 3 Apr 2003 10:17:04 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Apr 2003 10:12:59 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 10:12:58 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 10:12:57 +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: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Thu, 3 Apr 2003 10:12:57 +0300 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CONSENSUS CALL: Deprecating Site-Local Addressing Thread-Index: AcL4iSjg93DUNDoeSi60BZhLEa1zIQBJrzjA To: , X-OriginalArrivalTime: 03 Apr 2003 07:12:57.0861 (UTC) FILETIME=[742F4350:01C2F9B0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h337DAPL012927 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, For what it's worth, my opinion is: "NO -- Do not deprecate site-local unicast addressing". because: - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. - Other: I think that there is a need for private address space & provider independent address space. I would be happy to have a BCP on Site Locals, even if it listed reasons for not using them (or when they SHOULD/MUST NOT be used); I'd accept tighter controls on their usage, and so forth. 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 Wed Apr 2 23:34:15 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 h337YEPL013455; Wed, 2 Apr 2003 23:34:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h337YEAM013454; Wed, 2 Apr 2003 23:34: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.9+Sun/8.12.9) with ESMTP id h337YBPL013447 for ; Wed, 2 Apr 2003 23:34:11 -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 h337YIHP024965 for ; Wed, 2 Apr 2003 23:34:18 -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.3p2+Sun/8.9.3) with ESMTP id AAA16561 for ; Thu, 3 Apr 2003 00:34:12 -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; Thu, 3 Apr 2003 07:34:09 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, 3 Apr 2003 07:34: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; Thu, 3 Apr 2003 07:34:09 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; Thu, 3 Apr 2003 07:34:09 Z Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h337WaN09359 for ; Thu, 3 Apr 2003 10:32:36 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Apr 2003 10:34:07 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 10:34:07 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 10:34:07 +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: site-locals Date: Thu, 3 Apr 2003 10:34:06 +0300 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: site-locals Thread-Index: AcL5ow8O78QJfHLSRaaYUNZDoxscOgADKCqQ To: , X-OriginalArrivalTime: 03 Apr 2003 07:34:07.0108 (UTC) FILETIME=[68B6FC40:01C2F9B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h337YBPL013448 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Elliot, > Given that if the mechanism exists we know people will develop NAT > functionality in order to isolate enterprises from IP address changes, > what is the benefit of going forward at all with IP version 6? A large > address space is useless if you only need a small one. We already have > that. Do you think that people will use the mechanism if it exists - or will they create such a mechanism if it doesn't exist? What I mean is that NATs are one of the most successful IETF technologies of the decade or so (if you consider deployment, use, etc.). Many of us may not like it, though, however, it seems that NATs have fulfilled a real need in the market place - some several seem to be: 1) Provider (ISP) independent addresses 2) Increase address space 3) Access Control ... and so forth Not all of the above reasons will go away with IPv6 - and I am quite sure that many network administrators will still administer IPv6 networks in a similar manner as IPv4. However, I still think that IPv6 will bring many benefits and hopefully people are capable of learning new paradigms. So, getting rid of site locals doesn't remove much of the motivation, and there are no ready solutions to fulfill some real needs; which worries me. Is it possible that by killing site locals, we set the stage for people to do something worse? Will people still use FE0C, even if it is deprecated? Will people pick random prefixes for use as site local / private addresses? What is the amount of work to depreciate site locals - how many RFCs need to be updated? I'm not convinced that deprecating site locals really solves anything. 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 Apr 3 00:45: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 h338j1PL014089; Thu, 3 Apr 2003 00:45:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h338j1Zk014088; Thu, 3 Apr 2003 00:45: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.9+Sun/8.12.9) with ESMTP id h338ivPL014081 for ; Thu, 3 Apr 2003 00:44: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 h338j4cU023872 for ; Thu, 3 Apr 2003 00:45:04 -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 AAA27252 for ; Thu, 3 Apr 2003 00:44: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; Thu, 3 Apr 2003 08:44: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; Thu, 3 Apr 2003 08:44: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, 3 Apr 2003 08:44:58 Z Received: from batch14.uni-muenster.de (batch14.uni-muenster.de [128.176.188.112]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 08:44:57 Z Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch14.uni-muenster.de (Postfix) with ESMTP id 4B32912AF; Thu, 3 Apr 2003 10:44:56 +0200 (MES) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 2700F312DE; Thu, 3 Apr 2003 10:44:55 +0200 (CEST) Received: from LEMY.UNI-MUENSTER.DE (LEMY.UNI-MUENSTER.DE [128.176.184.238]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 36D10312F3; Thu, 3 Apr 2003 10:44:54 +0200 (CEST) From: Christian Schild Reply-To: schild@uni-muenster.de Organization: Westfaelische Wilhelms-Universitaet To: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Thu, 3 Apr 2003 10:44:54 +0200 User-Agent: KMail/1.5 References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304031044.54779.ipng@uni-muenster.de> X-Virus-Scanned: by AMaViS 0.3.12pre7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Am Dienstag, 1. April 2003 21:37 schrieb Margaret Wasserman: "NO -- Do not deprecate site-local unicast addressing". - Without SLs it is no longer possible to connect two local links to each other. This is the basic feature of a site-local address, to connect two links without a global prefix. Any additional (global) feature for SLs is dangerous. Maybe just rename "site-local prefix" to "private prefix". Christian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 00:49: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 h338nfPL014289; Thu, 3 Apr 2003 00:49:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h338neA5014288; Thu, 3 Apr 2003 00:49: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.9+Sun/8.12.9) with ESMTP id h338nbPL014278 for ; Thu, 3 Apr 2003 00:49: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 h338niHP010249 for ; Thu, 3 Apr 2003 00:49:44 -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 BAA07997 for ; Thu, 3 Apr 2003 01:49:38 -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, 3 Apr 2003 08:49:37 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, 3 Apr 2003 08:49: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; Thu, 3 Apr 2003 08:49:37 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 08:49:36 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 9CF67146C2; Thu, 3 Apr 2003 18:49:35 +1000 (EST) Date: Thu, 3 Apr 2003 18:49:35 +1000 From: "Nick 'Sharkey' Moore" To: Eliot Lear Cc: ipng@sunroof.eng.sun.com Subject: Re: site-locals Message-Id: <20030403084935.GD27840@zoic.org> Mail-Followup-To: Eliot Lear , ipng@sunroof.eng.sun.com References: <3E8BC77A.7060506@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E8BC77A.7060506@cisco.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Apr 02, 2003 at 09:32:42PM -0800, Eliot Lear wrote: > For those of you who are voting "no" on the question of deprecation... *waves* > Given that if the mechanism exists we know people will develop NAT > functionality in order to isolate enterprises from IP address changes, I would question your assumptions: a) That the existence of site locals will cause people to use NAT b) That the deprecation of site locals will prevent people from using NAT. > what is the benefit of going forward at all with IP version 6? A very large, very flexible address space, and a protocol which allows much greater flexibility than IPv4 for, for example, Mobility. -----N -- Nick 'Sharkey' Moore Research Fellow, CTIE Tel: +61 3 9905 3707 Monash University, Australia Fax: +61 3 9905 5358 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 01:02: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 h3392PPL014794; Thu, 3 Apr 2003 01:02:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3392Ovu014793; Thu, 3 Apr 2003 01:02: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 h3392KPL014786 for ; Thu, 3 Apr 2003 01:02: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 h3392RHP013227 for ; Thu, 3 Apr 2003 01:02: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.3p2+Sun/8.9.3) with ESMTP id CAA12397 for ; Thu, 3 Apr 2003 02:02: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; Thu, 3 Apr 2003 09:02:20 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, 3 Apr 2003 09:02: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, 3 Apr 2003 09:02:19 Z Received: from slimsixten.besserwisser.org ([130.236.67.179] [130.236.67.179]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 09:02:18 Z Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id h3392IAO012568 for ; Thu, 3 Apr 2003 11:02:19 +0200 (CEST) Date: Thu, 03 Apr 2003 11:02:18 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Message-Id: <23530000.1049360538@localhost.besserwisser.org> In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1705422778==========" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --==========1705422778========== Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Tuesday, April 01, 2003 14:37:56 -0500 Margaret Wasserman wrote: > Should we deprecate IPv6 site-local unicast addressing? YES -- Deprecate site-local unicast addressing.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========1705422778========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+i/ia02/pMZDM1cURAsVRAJ9K7e/GK/W6QX+Twob2ODsvIKtkwgCglR3b fMmcAwoOcuxTy/duvohc/lc= =PQzx -----END PGP SIGNATURE----- --==========1705422778==========-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 01:12: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 h339CZPL015038; Thu, 3 Apr 2003 01:12:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h339CZUJ015037; Thu, 3 Apr 2003 01:12: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.9+Sun/8.12.9) with ESMTP id h339CVPL015022 for ; Thu, 3 Apr 2003 01:12:31 -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 h339CcHP015451 for ; Thu, 3 Apr 2003 01:12: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 CAA24150 for ; Thu, 3 Apr 2003 02:12:32 -0700 (MST) From: teemu.savolainen@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; Thu, 3 Apr 2003 09:12: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, 3 Apr 2003 09:09: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, 3 Apr 2003 09:12:30 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; Thu, 3 Apr 2003 09:12:29 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 h339GN512128 for ; Thu, 3 Apr 2003 12:16:23 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Apr 2003 12:12:24 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 12:12:22 +0300 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 12:12:21 +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: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Thu, 3 Apr 2003 12:12:21 +0300 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CONSENSUS CALL: Deprecating Site-Local Addressing Thread-Index: AcL4iIBcFsGdpS+CSICwPSoEo39iUgBOFBxw To: Cc: X-OriginalArrivalTime: 03 Apr 2003 09:12:21.0865 (UTC) FILETIME=[22438590:01C2F9C1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h339CVPL015025 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "NO -- Do not deprecate site-local unicast addressing". Teemu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 01:23:15 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 h339NEPL015530; Thu, 3 Apr 2003 01:23:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h339NEc5015529; Thu, 3 Apr 2003 01:23: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.9+Sun/8.12.9) with ESMTP id h339NAPL015514 for ; Thu, 3 Apr 2003 01:23:10 -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 h339NHcU002419 for ; Thu, 3 Apr 2003 01:23:18 -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 CAA09356 for ; Thu, 3 Apr 2003 02:23:12 -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, 3 Apr 2003 09:22: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, 3 Apr 2003 09:22: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, 3 Apr 2003 09:22:45 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 09:22:44 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h339MVI24876; Thu, 3 Apr 2003 12:22:31 +0300 Date: Thu, 3 Apr 2003 12:22:30 +0300 (EEST) From: Pekka Savola To: john.loughney@nokia.com cc: lear@cisco.com, Subject: RE: site-locals 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, 3 Apr 2003 john.loughney@nokia.com wrote: > What is the amount of work to depreciate site locals - how many RFCs need > to be updated? I'm not convinced that deprecating site locals really solves > anything. The number of RFC's (basically address architecture, which is going revision anyway) is small compared to existing and future RFC's which would have to take site-locals into account (e.g. in the routing area). -- 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 Apr 3 01:58:30 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 h339wUPL015888; Thu, 3 Apr 2003 01:58:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h339wUKg015887; Thu, 3 Apr 2003 01:58: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 h339wQPL015880 for ; Thu, 3 Apr 2003 01:58:26 -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 h339wYcU010654 for ; Thu, 3 Apr 2003 01:58:34 -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 BAA13257 for ; Thu, 3 Apr 2003 01:58:28 -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, 3 Apr 2003 09:58:27 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, 3 Apr 2003 09:55: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; Thu, 3 Apr 2003 09:58:27 Z Received: from smtp2.su.se (smtp2.su.se [130.237.93.212]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 09:58:26 Z Received: from localhost (smtp2.su.se [127.0.0.1]) by smtp2.su.se (Postfix) with ESMTP id 9A88820010B for ; Thu, 3 Apr 2003 11:58:25 +0200 (CEST) Received: from smtp2.su.se ([127.0.0.1]) by localhost (smtp2.su.se [127.0.0.1:10024]) (amavisd-new) with ESMTP id 19488-09 for ; Thu, 3 Apr 2003 11:58:25 +0200 (CEST) Received: from min.it.su.se (min.it.su.se [130.237.95.62]) by smtp2.su.se (Postfix) with ESMTP id 70924200098 for ; Thu, 3 Apr 2003 11:58:25 +0200 (CEST) From: Fredrik Thulin To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Thu, 3 Apr 2003 11:58:25 +0200 User-Agent: KMail/1.5 References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304031158.25335.ft@it.su.se> X-Virus-Scanned: by amavisd-new with f-prot at smtp.su.se Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing /Fredrik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 02:15: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 h33AFKPL016289; Thu, 3 Apr 2003 02:15:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33AFJ0u016288; Thu, 3 Apr 2003 02:15: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.9+Sun/8.12.9) with ESMTP id h33AFGPL016281 for ; Thu, 3 Apr 2003 02:15: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 h33AFNcU015162 for ; Thu, 3 Apr 2003 02:15:23 -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 DAA07188 for ; Thu, 3 Apr 2003 03:15:17 -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, 3 Apr 2003 10:15:17 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, 3 Apr 2003 10:15: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; Thu, 3 Apr 2003 10:15:15 Z Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 10:15:15 Z Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h33AArau006920; Thu, 3 Apr 2003 03:10:53 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h33ABGOq005493; Thu, 3 Apr 2003 04:11:18 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id B848A2EC86; Thu, 3 Apr 2003 12:11:15 +0200 (CEST) Message-Id: <3E8C08C3.9050201@nal.motlabs.com> Date: Thu, 03 Apr 2003 12:11:15 +0200 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: Brian E Carpenter , alh-ietf@tndh.net, jbartas@iniche.com, ipng@sunroof.eng.sun.com Subject: Re: Outlawing (Avoiding) NAT with IPv6 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 Alper Yegin wrote: > I don't quite understand this... All CN knows is the RCoA of the > MN. Only LCoA can reveal the location of the MN within the network. > And CN cannot figure out LCoA by looking at RCoA. What's the difference between a RCoA and a LCoA of a same MN? In my understanding only the /64 prefix differs. The RCoA prefix is valid on the MAP subnet and the LCoA prefix is valid in the AR subnet. A CN is presented with the RCoA. A CN can have "out-of-band" knowledge about the prefixes valid under various ARs. Based on this input, a CN can build the LCoA corresponding to the RCoA. That's what I was trying to say, but maybe I fail somewhere. > This is so much like what NAT does as far as hiding LCoA is > concerned. To me, there are some common points, but there are also huge differences. I'm thinking about in NAT there is a specific set of types of addresses (the not publicly-routable) that can be reused by any site at will. However, with HMIPv6, the LCoAs must be globally unique. Alex GBU -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 02:36:53 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 h33AarPL016731; Thu, 3 Apr 2003 02:36:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33AaqHb016730; Thu, 3 Apr 2003 02:36: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.9+Sun/8.12.9) with ESMTP id h33AanPL016723 for ; Thu, 3 Apr 2003 02:36:49 -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 h33AauHP005213 for ; Thu, 3 Apr 2003 02:36: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 CAA06517 for ; Thu, 3 Apr 2003 02:36:51 -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, 3 Apr 2003 10:36: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; Thu, 3 Apr 2003 10:36: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; Thu, 3 Apr 2003 10:36: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; Thu, 3 Apr 2003 10:36:49 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 <20030403103649.ISWU11905.mailhost.chi1.ameritech.net@repligate>; Thu, 3 Apr 2003 04:36:49 -0600 Message-Id: <0c1d01c2f9cc$fc120840$8500a8c0@repligate> From: "Jim Fleming" To: , , References: Subject: "...NATs are one of the most successful IETF technologies..." ?? Date: Thu, 3 Apr 2003 04:37:10 -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: "...NATs are one of the most successful IETF technologies..." ==== NAT did not come from the IETF...the ISOC opposes them... http://www.spectrum.ieee.org/select/1098/int.html NATs are a no-no HEATH: I was going to say that IEEE Spectrum should make it very clear that this group's consensus would appear to be: let's discourage NATs--I mean the manufacture of them at all--because there is a real need for IPv6. HUITEMA: It's more than that. There is a real need for security and you can't have security with NATs. CERF: NAT is a guaranteed spoofing box in effect. =================================================== NAT is part of the collection of techniques that build on the existing IPv4 header. That collection is called IPv8... Jim Fleming http://www.IPv8.info ----- Original Message ----- From: To: ; Sent: Thursday, April 03, 2003 1:34 AM Subject: RE: site-locals > Elliot, > > > Given that if the mechanism exists we know people will develop NAT > > functionality in order to isolate enterprises from IP address changes, > > what is the benefit of going forward at all with IP version 6? A large > > address space is useless if you only need a small one. We already have > > that. > > Do you think that people will use the mechanism if it exists - or will they > create such a mechanism if it doesn't exist? > > What I mean is that NATs are one of the most successful IETF technologies > of the decade or so (if you consider deployment, use, etc.). Many of us > may not like it, though, however, it seems that NATs have fulfilled a > real need in the market place - some several seem to be: > > 1) Provider (ISP) independent addresses > 2) Increase address space > 3) Access Control > ... and so forth > > Not all of the above reasons will go away with IPv6 - and I am quite sure > that many network administrators will still administer IPv6 networks in > a similar manner as IPv4. However, I still think that IPv6 will bring many > benefits and hopefully people are capable of learning new paradigms. > > So, getting rid of site locals doesn't remove much of the motivation, and > there are no ready solutions to fulfill some real needs; which worries me. > Is it possible that by killing site locals, we set the stage for people to > do something worse? Will people still use FE0C, even if it is deprecated? > Will people pick random prefixes for use as site local / private addresses? > What is the amount of work to depreciate site locals - how many RFCs need > to be updated? I'm not convinced that deprecating site locals really solves > anything. > > 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 Thu Apr 3 03:47: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 h33BlRPL017155; Thu, 3 Apr 2003 03:47:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33BlRgg017154; Thu, 3 Apr 2003 03:47: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.9+Sun/8.12.9) with ESMTP id h33BlOPL017147 for ; Thu, 3 Apr 2003 03:47:24 -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 h33BlSHP018684 for ; Thu, 3 Apr 2003 03:47: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 EAA02088 for ; Thu, 3 Apr 2003 04:47: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; Thu, 3 Apr 2003 11:47:20 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, 3 Apr 2003 11:47: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, 3 Apr 2003 11:47:20 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; Thu, 3 Apr 2003 11:47:20 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id DAA15573; Thu, 3 Apr 2003 03:46:50 -0800 (PST) Message-Id: <5.1.0.14.2.20030403064001.0146ac80@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 06:45:34 -0500 To: "Michel Py" From: Margaret Wasserman Subject: Re: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing Cc: In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F711@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, Sorry for the delay in responding. Bob is in Beijing without good mail access, and I have been out of the office the past couple of days for personal reasons. At 02:21 PM 4/1/2003 -0800, Michel Py wrote: >What is this consensus about? I was hoping that the mailing list would >be asked to express their opinions _after_ a text to deprecate >site-local addressing had been submitted to the working group. In the >current situation, this consensus if there is one would be good only to >accept text as a working document. This document that still has to be >seen then should go to WG last call. The current call is to confirm the consensus of the room in SF that site-local addresses should be deprecated. Once the WG has consensus on a general plan of attack (deprecate site-local addresses, keep them for specific uses, etc.), we will update the documents (addressing architecture, scoped addressing architecture, etc.) to reflect that general direction. Yes, we will need to get group consensus on the documents when they are ready. In SF, we also had general agreement (although no direct consensus call was made) to write a document that explained why site-locals were deprecated and how to achieve the benefits of site-locals (numbering for disconnected sites, access control, etc.) through different means that did not have the problems of site-local addressing. >Where is the doc to deprecate site-local addressing? It will be written if there is IETF WG consensus to do the deprecation. I am not actually certain if site-locals will be officially deprecated in the separate document that I mentioned above, or through an update to the addressing architecture (since that would be on the standards track), but I'm also not sure that it matters, as both would be necessary. 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 Apr 3 03:54: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 h33BskPL017372; Thu, 3 Apr 2003 03:54:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33BskiZ017371; Thu, 3 Apr 2003 03:54: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 h33BshPL017364 for ; Thu, 3 Apr 2003 03:54: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 h33BspcU006113 for ; Thu, 3 Apr 2003 03:54: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 DAA18679 for ; Thu, 3 Apr 2003 03:54:46 -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, 3 Apr 2003 11:54:45 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, 3 Apr 2003 11:54:45 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, 3 Apr 2003 11:54:44 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, 3 Apr 2003 11:54:44 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 670CD8992; Thu, 3 Apr 2003 13:54:41 +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 6F95178B2; Thu, 3 Apr 2003 13:54:36 +0200 (CEST) From: "Jeroen Massar" To: "'Dan Lanciani'" , Subject: RE: Charge for traffic, not IP addresses (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Thu, 3 Apr 2003 13:55:46 +0200 Organization: Unfix Message-Id: <003701c2f9d7$f6a5a190$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200304021944.OAA29041@ss10.danlan.com> X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: > "Jeroen Massar" wrote: > > |William_G_Allmond@notes.tcs.treas.gov wrote: > | > |> NO - Do NOT Deprecate Site-Local Addressing. > |> > |> There are reason to use site-locals, and reason NOT to use > them. But > |> "FORBIDDING" people will only alienate them and lead them to > |> find ways to do it anyway. > |> > |> Perfect example, when (or should I say IF) my home ISP goes > |> to IPv6, they charge per IP. Always have, and always will. > |> Sure, they will gladly give me a range of IPs, as well as > |> gladly charge me as if each were a PC. Also, > |> when I get tired of putting up with the abuse from this > |> particular ISP and decide to choose another ISP to abuse me, > |> I will still have the same issue. > | > |Very good example that you don't get it at all. > |ISP's should be charging for traffic, not for IP's. > > So why don't you make the ISPs work the way you think they should? > Then NAT would go away and you wouldn't have to try to ban it. NAT > is the effect, not the cause. That's the IPv4 world. The ISP's will have to get inside their heads that IP space is not 'scarce' anymore. Fortunatly most RIR's will tell them that when they request an allocation and I even suspect that when an ISP get 'caught' for not passing out the correct bits down to their clients that they can be requested to return their allocation as they are not using it anyways. The IPv4 mentality should go. IPv6 != IPv4 fortunatly ;) Btw most ISP's I know charge for traffic, though basically they say 'this is the "fair use limit"', whenever you pass it you have to pay up, hard. Extra IPv4 IP's can usually be requested for an additional fee, but that's mostly an administration hurdle. 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 Apr 3 04:03: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 h33C3qPL017622; Thu, 3 Apr 2003 04:03:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33C3qET017621; Thu, 3 Apr 2003 04:03: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.9+Sun/8.12.9) with ESMTP id h33C3mPL017614 for ; Thu, 3 Apr 2003 04:03: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 h33C3vHP021961 for ; Thu, 3 Apr 2003 04:03:57 -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.3p2+Sun/8.9.3) with ESMTP id FAA02856 for ; Thu, 3 Apr 2003 05:03:51 -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, 3 Apr 2003 12:03:51 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, 3 Apr 2003 12:03:50 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, 3 Apr 2003 12:03:50 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; Thu, 3 Apr 2003 12:03:49 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA21668 for ; Thu, 3 Apr 2003 04:03:26 -0800 (PST) Message-Id: <5.1.0.14.2.20030403064541.03e2cae8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 07:01:57 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: My Thoughts on Site-Locals Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a few thoughts to share on site-local addressing... Many people have written to the list lately stating that site-locals should be retained for (at least) one of these two reasons: - Numbering for disconnected networks. - Access control. - Numbering for intermittently-connected networks. I do consider these things to be very important, but I do not consider site-local addresses to be the best architectural solution to these problems. Site-local addresses have properties that are not needed to address these problems, and that cause problems for routing protocols and upper-layer protocols, such as: - Ambiguity (requires zone ID to disambiguate). - Need to retain site "convexity". - Single level of nesting (you can't have a further access- controlled site within a site). - Special address selection handling required at the IP layer and in applications. - Places the knowledge of private addressing in all implementations, instead of keeping the knowledge of routing boundaries constrained to the infrastructure (routers, firewalls, etc.) Using random addresses for disconnected sites was proposed as an alternative, but that is not the only alternative. There are, in fact, two superior alternatives that do not require any standardization work by the IPv6 WG (or any other IETF WG): - Enterprises could use part of their /48 as private addresses and filter at private borders. This is superior to site-locals because: - It allows nesting of private areas. - The owner of local addresses can be identified. - Non-ambiguous -- if sent outside the local area, they are unreachable and won't point to the wrong network or node. - Doesn't require special handling on end-nodes or by applications, etc. - Registries could offer private address allocations to individual enterprises/people. This is also superior for the same reasons listed above. Access control is also useful, and a simple form of access control will be needed in IPv6. However, site-local addresses are a poor form of access control for two reasons: - Site-local boundaries need to be at routing area or AS boundaries (not convenient). - Site-local areas cannot be nested. So, you can't have a site-local access control boundary for your corporate site, AND a site-local access control boundary that only allows the marketing department to use the fancy printer. Both Steve Bellovin and Brian Zill have proposed superior access control mechanisms based on information being passed in router advertisements, and I think they plan to combine their proposals into a single, maximally beneficial, form. The intermittently-connected site problem is often raised as a reason for site-locals. This is an interesting problem, and it would be very good to solve this problem, but site-locals do not provide a complete solution. And, recent models for site-local usages (including "moderate" and "limited") don't provide a solution for this case at all, as they would reverse the preference for site-local addresses over global addresses in the address selection rules. So, while I think that the IETF needs to figure out a way to address this type of network, site-locals may not be the best way to do it, as they come with substantial costs for all nodes, and don't fully solve this problem. Just my thoughts... 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 Apr 3 04:06:04 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 h33C64PL017672; Thu, 3 Apr 2003 04:06:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33C64hs017671; Thu, 3 Apr 2003 04:06: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.9+Sun/8.12.9) with ESMTP id h33C60PL017658 for ; Thu, 3 Apr 2003 04:06:00 -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 h33C68cU008696 for ; Thu, 3 Apr 2003 04:06:08 -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 FAA10435 for ; Thu, 3 Apr 2003 05:06:03 -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, 3 Apr 2003 12:06:02 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, 3 Apr 2003 12:06:02 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, 3 Apr 2003 12:06:02 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; Thu, 3 Apr 2003 12:06:02 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 <20030403120601.JGDS11905.mailhost.chi1.ameritech.net@repligate>; Thu, 3 Apr 2003 06:06:01 -0600 Message-Id: <0ca501c2f9d9$72a9df30$8500a8c0@repligate> From: "Jim Fleming" To: "Jeroen Massar" , "'Dan Lanciani'" , References: <003701c2f9d7$f6a5a190$210d640a@unfix.org> Subject: "IP space is not 'scarce' anymore..."? Date: Thu, 3 Apr 2003 06:06:23 -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: "Jeroen Massar" "IP space is not 'scarce' anymore..."? ===== If you flip the AM/FM bit to 1, you double the address space but not in both directions. When you add the 4 bits in both directions for TOS Routing, you get a 16x expansion. When you add the 7 bits in both directions for RIFRAF Routing, you get another 128x expansion. Numerous /8s are now exposed as available, that used to be hoaded prior to liberation from the Postel regime. http://www.iana.org/assignments/ipv4-address-space Each /8 becomes 2,047 more /8s and the AM/FM doubles that...and that is just for the DMZ Cloud connecting the GKs and PKs...the PKs have their own transport and addressing... Jim Fleming http://www.IPv8.info ----- Original Message ----- From: "Jeroen Massar" To: "'Dan Lanciani'" ; Sent: Thursday, April 03, 2003 5:55 AM Subject: RE: Charge for traffic, not IP addresses (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) > Dan Lanciani wrote: > > > "Jeroen Massar" wrote: > > > > |William_G_Allmond@notes.tcs.treas.gov wrote: > > | > > |> NO - Do NOT Deprecate Site-Local Addressing. > > |> > > |> There are reason to use site-locals, and reason NOT to use > > them. But > > |> "FORBIDDING" people will only alienate them and lead them to > > |> find ways to do it anyway. > > |> > > |> Perfect example, when (or should I say IF) my home ISP goes > > |> to IPv6, they charge per IP. Always have, and always will. > > |> Sure, they will gladly give me a range of IPs, as well as > > |> gladly charge me as if each were a PC. Also, > > |> when I get tired of putting up with the abuse from this > > |> particular ISP and decide to choose another ISP to abuse me, > > |> I will still have the same issue. > > | > > |Very good example that you don't get it at all. > > |ISP's should be charging for traffic, not for IP's. > > > > So why don't you make the ISPs work the way you think they should? > > Then NAT would go away and you wouldn't have to try to ban it. NAT > > is the effect, not the cause. > > That's the IPv4 world. The ISP's will have to get inside > their heads that IP space is not 'scarce' anymore. > Fortunatly most RIR's will tell them that when they > request an allocation and I even suspect that when an ISP > get 'caught' for not passing out the correct bits down > to their clients that they can be requested to return > their allocation as they are not using it anyways. > > The IPv4 mentality should go. IPv6 != IPv4 fortunatly ;) > > Btw most ISP's I know charge for traffic, though basically > they say 'this is the "fair use limit"', whenever you pass > it you have to pay up, hard. Extra IPv4 IP's can usually > be requested for an additional fee, but that's mostly > an administration hurdle. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 04:13: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 h33CDKPL018077; Thu, 3 Apr 2003 04:13:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33CDJYt018076; Thu, 3 Apr 2003 04: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h33CDFPL018063 for ; Thu, 3 Apr 2003 04:13:15 -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 h33CDNcU010334 for ; Thu, 3 Apr 2003 04:13:24 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA09815 for ; Thu, 3 Apr 2003 05:13: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; Thu, 3 Apr 2003 12:12: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; Thu, 3 Apr 2003 12:12: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; Thu, 3 Apr 2003 12:12:35 Z Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 12:12: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 <20030403121234.JHAH11905.mailhost.chi1.ameritech.net@repligate>; Thu, 3 Apr 2003 06:12:34 -0600 Message-Id: <0cb301c2f9da$5d0cc560$8500a8c0@repligate> From: "Jim Fleming" To: , "Margaret Wasserman" References: <5.1.0.14.2.20030403064541.03e2cae8@mail.windriver.com> Subject: Re: My Thoughts on Site-Locals Date: Thu, 3 Apr 2003 06:12:56 -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 Do you have any working code ? Also, have you considered moving your mailing list to an IPv6 transport ? ...would there be any users ? ----- Original Message ----- From: "Margaret Wasserman" To: Sent: Thursday, April 03, 2003 6:01 AM Subject: My Thoughts on Site-Locals > > I have a few thoughts to share on site-local addressing... > > Many people have written to the list lately stating that site-locals > should be retained for (at least) one of these two reasons: > > - Numbering for disconnected networks. > - Access control. > - Numbering for intermittently-connected networks. > > I do consider these things to be very important, but I do not > consider site-local addresses to be the best architectural solution > to these problems. > > Site-local addresses have properties that are not needed to address > these problems, and that cause problems for routing protocols and > upper-layer protocols, such as: > > - Ambiguity (requires zone ID to disambiguate). > - Need to retain site "convexity". > - Single level of nesting (you can't have a further access- > controlled site within a site). > - Special address selection handling required at the IP > layer and in applications. > - Places the knowledge of private addressing in all implementations, > instead of keeping the knowledge of routing boundaries > constrained to the infrastructure (routers, firewalls, > etc.) > > Using random addresses for disconnected sites was proposed as an > alternative, but that is not the only alternative. There are, in > fact, two superior alternatives that do not require any standardization > work by the IPv6 WG (or any other IETF WG): > > - Enterprises could use part of their /48 as private > addresses and filter at private borders. This > is superior to site-locals because: > > - It allows nesting of private areas. > - The owner of local addresses can be identified. > - Non-ambiguous -- if sent outside the local area, > they are unreachable and won't point to > the wrong network or node. > - Doesn't require special handling on end-nodes > or by applications, etc. > > - Registries could offer private address allocations to > individual enterprises/people. This is also > superior for the same reasons listed above. > > Access control is also useful, and a simple form of access control will > be needed in IPv6. However, site-local addresses are a poor form of > access control for two reasons: > > - Site-local boundaries need to be at routing area > or AS boundaries (not convenient). > - Site-local areas cannot be nested. > > So, you can't have a site-local access control boundary for your corporate > site, AND a site-local access control boundary that only allows the marketing > department to use the fancy printer. > > Both Steve Bellovin and Brian Zill have proposed superior access control > mechanisms based on information being passed in router advertisements, and > I think they plan to combine their proposals into a single, maximally > beneficial, form. > > The intermittently-connected site problem is often raised as a reason for > site-locals. This is an interesting problem, and it would be very good > to solve this problem, but site-locals do not provide a complete solution. > And, recent models for site-local usages (including "moderate" and > "limited") don't provide a solution for this case at all, as they would > reverse the preference for site-local addresses over global addresses > in the address selection rules. > > So, while I think that the IETF needs to figure out a way to address this > type of network, site-locals may not be the best way to do it, as they > come with substantial costs for all nodes, and don't fully solve this > problem. > > Just my thoughts... > > 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 Thu Apr 3 04:15: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 h33CFaPL018160; Thu, 3 Apr 2003 04:15:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33CFaDk018158; Thu, 3 Apr 2003 04:15: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 h33CFXPL018151 for ; Thu, 3 Apr 2003 04:15:33 -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 h33CFeHP024282 for ; Thu, 3 Apr 2003 04:15: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 EAA23085 for ; Thu, 3 Apr 2003 04:15: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; Thu, 3 Apr 2003 12:15: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; Thu, 3 Apr 2003 12:12: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; Thu, 3 Apr 2003 12:15:29 Z Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 12:15:29 Z Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h33CBQDc019991; Thu, 3 Apr 2003 05:11:27 -0700 (MST) Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id FAA04473; Thu, 3 Apr 2003 05:08:54 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h33B6Z924515; Thu, 3 Apr 2003 05:06:36 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 2BCA22EC8B; Thu, 3 Apr 2003 14:11:20 +0200 (CEST) Message-Id: <3E8C24E7.9070304@nal.motlabs.com> Date: Thu, 03 Apr 2003 14:11:19 +0200 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cc: Brian E Carpenter , , , Subject: Re: Location Privacy (was Re: Outlawing (Avoiding) NAT with IPv6) References: <07a201c2f7d7$157391c0$ee1a4104@eagleswings> <3E897DE0.85A84EED@hursley.ibm.com> <3E8AD961.9050006@nal.motlabs.com> <3E8B6D19.5010706@eng.monash.edu.au> In-Reply-To: <3E8B6D19.5010706@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Greg, Greg Daley wrote: > There is no problem with the RCoA and LCoA differing only in prefix > if the LCoA and RCoA are based on RFC3041 addresses. A-ha, that sounds like a tangible goal. I mean there is a big if in your phrasing. I still need to understand how this would work in practice (answering your question on if I'm interested on tech details). Currently HMIPv6 has no RFC 3041 in it, so saying it might be made to work, it is ok, but saying that HMIPv6 provides location privacy is not quite ok (IMHO). And, this of course depends on what the location privacy problem is (if any). [snip text on functioning] > For communications completed while the RCoA is unchanged, the MN > can use a 3041 based RCoA, and not use the MIPv6 Home Address > options (or use the RCoA as a home address), in which case there is > no identity information in the packets sent or received from the > MN to correspondent nodes, and no location information more > accurate than which MAP the MN is using. > > Please try to track a user in this situation! That is ok, I agree. (You must be sure MAP maintains the right association between one LCoA and several RCoAs (RCoAs change for rfc 3041 reasons, if I understand correctly).) The MAP is a HA, that's all. RO is not used, so CN knows nothing about the location. So this is pure Mobile IPv6. That's why I tried to distinguish between Mobile IPv6 and HMIPv6. >> What one really obtains with HMIP is that one gets assigned two >> addresses and is free to inform its CN about one of those >> addresses. Nothing about a location being assigned to an address, >> let alone the question of hiding that location. > > Locations are implied by IPv6 subnet information in the LCoA. IP > access subnets which span greater areas than a city are a bad idea > IMHO. Aha, so location is the IPv6 subnet information where the MN is attached. That is the location. That is what it is tried to be hidden from CN. > If you're more interested in the technical details, then we can > take this to Mobile-IP WG. Yes, I'm interested in the technical details, but I'm afraid of cluttering the Mobile IP group with this, they have a much more important job now. Until we figure out where to do it, let me say that I agree with most of your points, but not all. And that I will try to refrain from posting on ipng as well. Alex GBU -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 04:58: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 h33Cw2PL018925; Thu, 3 Apr 2003 04:58:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33Cw2KR018924; Thu, 3 Apr 2003 04: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.9+Sun/8.12.9) with ESMTP id h33CvxPL018917 for ; Thu, 3 Apr 2003 04:57:59 -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 h33Cw7cU019709 for ; Thu, 3 Apr 2003 04:58:07 -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 EAA20690 for ; Thu, 3 Apr 2003 04:58:02 -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, 3 Apr 2003 12:58: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; Thu, 3 Apr 2003 12:58: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; Thu, 3 Apr 2003 12:58:01 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, 3 Apr 2003 12:58:01 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA10541; Thu, 3 Apr 2003 04:57:35 -0800 (PST) Message-Id: <5.1.0.14.2.20030403074147.037c1f40@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 07:51:45 -0500 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Margaret Wasserman Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> <5.1.0.14.2.20030401143711.04a0f848@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 Jinmei, At 02:36 PM 4/2/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >What was the consensus, if any, on alternatives to site-locals when SL >is deprecated? In particular, which prefixes will we use for >disconnected or intermittently connected "site"s? I've checked the >chair's presentation slides and the draft minutes, and (roughly) >followed the very recent discussion in the ML, but I cannot be sure >about it. We did not reach a specific consensus on this point. The WG was attempting to choose an overall direction, after which we acknowledged that there would be further work to do in either case. If we choose to deprecate site-locals, we will need to settle on alternative methods to deal with local addressing, access control, etc. >According to the draft minutes, someone mentioned we can use arbitrary >prefixes for those purposes. That's true, but we cannot assure the >uniqueness of the arbitrary-chosen prefixes, so I don't see any >essential advantage over the existing fec0::/10 (with eliminating the >"full" usage). I agree. I think that it would be much better to get registries to allocate unique prefixes for use on local networks. People who are ISP connected might also have the option of using part of their ISP-provided /48, if they are not motivated by ISP-independence. But, even randomly chosen values (the worst possible alternatives in many ways) are better than site-locals, IMO. >I can live without site-locals, and, furthermore, I personally want >the wg to stop the endless discussion and to concentrate on more >important -from my personal perspective- issues. Yes! This is the big motivation for deprecating site-locals. It will allow us to _finish_ IPv6 and move on. Someone may want to work elsewhere in the IETF/IRTF on the issue of scoped unicast addressing, and I would support their work. But, this idea isn't baked enough to include in a protocol that is becoming widely deployed as we speak. Removing half-baked ideas (even promising ones) from the architecture is a normal process as specification mature. Right now, the unresolved issues with site-locals are blocking progress on the scoped addressing architecture, which is vitally needed to complete the IPv6 specifications. >So, even if the >idea of "arbitrary-chosen prefixes" is just a compromise (without any >real benefit) to convince ourselves, it's okay for me. Then I'll vote >for deprecating site-local. > >Could someone clarify this point, please? While it would certainly be better to have a means to allocate globally unique private addresses, the operators present at the IPv6 WG meeting in SF were adamant that even using randomly chosen prefixes for local networks would be superior to site-local addresses, given the complexity and issues associated with site-locals. Besides, we will need another method for private addressing, anyway, as you cannot nest sites, and many people do nest access control boundaries. 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 Apr 3 05:12: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 h33DC1PL019209; Thu, 3 Apr 2003 05:12:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33DC0bG019208; Thu, 3 Apr 2003 05:12: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 h33DBvPL019201 for ; Thu, 3 Apr 2003 05:11:57 -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 h33DC5cU022503 for ; Thu, 3 Apr 2003 05:12:05 -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 GAA13661 for ; Thu, 3 Apr 2003 06:11:59 -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, 3 Apr 2003 13:11: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; Thu, 3 Apr 2003 13:11: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, 3 Apr 2003 13:11:59 Z Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 13:11:58 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h33DBqDI034088; Thu, 3 Apr 2003 15:11:52 +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 h33DAY2g275944; Thu, 3 Apr 2003 15:10:35 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47224 from ; Thu, 3 Apr 2003 15:10:32 +0200 Message-Id: <3E8C32F7.E9DFF918@hursley.ibm.com> Date: Thu, 03 Apr 2003 15:11:19 +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: Michel Py Cc: ipng@sunroof.eng.sun.com Subject: Re: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing References: <963621801C6D3E4A9CF454A1972AE8F504F716@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 I didn't mean we should pull the current draft, which is already in the RFC queue. Obviously, if we get consensus on the principle, there is then follow up to respect the process. I didn't think that my words implied otherwise; I just want to take one step at a time. Brian Michel Py wrote: > > > Brian E Carpenter wrote: > > What I raised my hand for in San Francisco was to > > deprecate SL addresses as currently defined in > > draft-ietf-ipngwg-addr-arch-v3-11.txt (and in RFC 2373). > > This has never been stated and you can expect appeals all the way to the > supreme court and I'll be supporting them. This is not an editorial > change but a significant architectural change. > > I am tired of last-minute attempts to pull documents that have been > approved for publication. Brian, I have the greatest respect for you but > this is not to your credit. > > 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 Apr 3 05:19: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 h33DJqPL019558; Thu, 3 Apr 2003 05:19:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33DJqqn019557; Thu, 3 Apr 2003 05:19: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.9+Sun/8.12.9) with ESMTP id h33DJmPL019550 for ; Thu, 3 Apr 2003 05:19: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 h33DJvcU024621 for ; Thu, 3 Apr 2003 05:19:57 -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 FAA03456 for ; Thu, 3 Apr 2003 05:19:51 -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, 3 Apr 2003 13:19: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; Thu, 3 Apr 2003 13:19:51 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, 3 Apr 2003 13:19:51 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, 3 Apr 2003 13:19:51 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA19647; Thu, 3 Apr 2003 05:19:13 -0800 (PST) Message-Id: <5.1.0.14.2.20030403081403.037bf2e8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 08:17:56 -0500 To: john.loughney@nokia.com From: Margaret Wasserman Subject: RE: site-locals Cc: , 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 John, >What is the amount of work to depreciate site locals - how many RFCs need >to be updated? I'm not convinced that deprecating site locals really solves >anything. The work to keep, and finish, site-locals is much greater than the work to deprecate them. To deprecate them, I think that the addressing architecture and the default address selection rules would be the only RFCs (both at PS) that we need to change. To keep them, we need to document and resolve the issues that they cause, update all of the IPv6 routing protocols to document how site-boundaries are maintained, and document how address selection will be performed in several upper layer protocols (at least SCTP, SIP and FTP). We might also need to provide guidance to non-IETF applications protocol developers and/or application developers for how to handle site-local addresses in non-IETF applications. And, we'd need to specify split DNS. 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 Apr 3 05:22:48 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 h33DMmPL019684; Thu, 3 Apr 2003 05:22:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33DMmM1019683; Thu, 3 Apr 2003 05:22: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.9+Sun/8.12.9) with ESMTP id h33DMjPL019676 for ; Thu, 3 Apr 2003 05:22: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 h33DMrcU025246 for ; Thu, 3 Apr 2003 05:22:53 -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 GAA29568 for ; Thu, 3 Apr 2003 06:22: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; Thu, 3 Apr 2003 13:22: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; Thu, 3 Apr 2003 13:22: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, 3 Apr 2003 13:22:46 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, 3 Apr 2003 13:22:46 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h33DMhCi032224; Thu, 3 Apr 2003 15:22:43 +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 h33DMW2g264086; Thu, 3 Apr 2003 15:22:34 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58898 from ; Thu, 3 Apr 2003 15:22:31 +0200 Message-Id: <3E8C35C6.26D174FE@hursley.ibm.com> Date: Thu, 03 Apr 2003 15:23:18 +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: Dave Thaler Cc: ipng@sunroof.eng.sun.com Subject: Re: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Thaler wrote: ... > you need to either: > a) remove the ability to _automatically_ address disconnected and > intermittently-connected sites, or > b) specify how to automatically address them. ...e. > > Can someone quickly give a proposal or two for (b) before the consensus > call deadline? I think we've heard several, all in the class of picking a short prefix (and it could still be FEC0::/10) and expanding it to /48 by adding almost-certainly-unique bits, such as - bits derived from GPS location at an arbitrary point inside the site - bits derived from the date & time at the instant you want a prefix - bits derived from an IEEE address of an arbitrary device inside the site - pseudo-random bits of some kind - bits supplied from a central allocator of some kind Clearly, mileage may vary with any of these but I can't see any fundmental problem, as long as we only require a very high probability of uniqueness rather than a formal guarantee. 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 Apr 3 05:31:35 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 h33DVZPL020205; Thu, 3 Apr 2003 05:31:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33DVYP6020204; Thu, 3 Apr 2003 05:31: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.9+Sun/8.12.9) with ESMTP id h33DVUPL020191 for ; Thu, 3 Apr 2003 05:31:31 -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 h33DVdHP010542 for ; Thu, 3 Apr 2003 05:31: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 GAA05384 for ; Thu, 3 Apr 2003 06:31: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; Thu, 3 Apr 2003 13:31: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; Thu, 3 Apr 2003 13:28: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, 3 Apr 2003 13:31:32 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, 3 Apr 2003 13:31:31 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h33DVJju021050; Thu, 3 Apr 2003 15:31:23 +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 h33DV99X271864; Thu, 3 Apr 2003 15:31:10 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA36792 from ; Thu, 3 Apr 2003 15:31:06 +0200 Message-Id: <3E8C37C9.847FCC74@hursley.ibm.com> Date: Thu, 03 Apr 2003 15:31:53 +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: alh-ietf@tndh.net Cc: ipng@sunroof.eng.sun.com Subject: Re: anti-SL == flat-earth society (was RE: avoiding NAT with IPv6) References: <09a401c2f944$05d34760$ee1a4104@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, I don't much appreciate the subject field (although "avoiding NAT" was indeed bogus). But I hear of daily operational costs caused explicitly by ambiguous "private" addresses that suddenly stop being private in reality - in other words, the notion of private scope is itself bogus in the general case. We get rid of one layer of problems if we get rid of the ambiguity built into RFC 1918 and of SLs as currently defined. Deprecating SL as currently defined is not a vote for the flat earth theory. Brian Tony Hain wrote: > > Michael Thomas wrote: > > ... Scoped addresses as have been pretty well > > demonstrated take us down some pretty scary paths. > > This sums up the whole anti-SL campain, which is spread FUD based on one > technically valid point; applications can't arbitrarily pass around > topology information. Applications that insist on passing around > topology information must understand the topology they are describing. > If they don't understand it, they are broken. Trying to assert a > flat-earth will not make it happen. There will be filtering, therefore > there will be addresses with a limited scope of applicability. Scoped > addresses will exist with or without a dedicated prefix. Lack of a > well-known prefix only makes more work for the system manager to > manually configure devices. It will be a sad outcome for decades to come > if we trade off the one-time per app cost of a developer needing to deal > with a well-known prefix in favor of the continuous operational cost of > manual configuration. > > 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 Apr 3 05:33: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 h33DXKPL020264; Thu, 3 Apr 2003 05:33:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33DXKuZ020263; Thu, 3 Apr 2003 05: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h33DXGPL020256 for ; Thu, 3 Apr 2003 05:33:16 -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 h33DXOcU027857 for ; Thu, 3 Apr 2003 05:33:25 -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 GAA24365 for ; Thu, 3 Apr 2003 06:33: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; Thu, 3 Apr 2003 13:33:13 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, 3 Apr 2003 13:33: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, 3 Apr 2003 13:33:12 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, 3 Apr 2003 13:33:12 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA25333; Thu, 3 Apr 2003 05:32:45 -0800 (PST) Message-Id: <5.1.0.14.2.20030403075954.03e2c408@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 08:28:15 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: A use for site local addresses? Cc: "Brian Carpenter" , In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F717@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, No one is planning to change anything in the last 24 hours... The current addressing architecture has been approved for publication at PS, and it will be published at PS (barring unforseen circumstances). We are currently discussing what the IPv6 working group wants to do in future versions of the addressing architecture and scoped addressing architecture. If we decide to deprecate site-local addresses, then a new version of the addressing architecture will be produced that deprecates site-locals. It will be reviewed by the WG, sent to WG last call, sent to the IESG for approval, etc... All using the usual IETF processes. Margaret At 08:05 AM 4/2/2003 -0800, Michel Py wrote: > > Brian E Carpenter wrote: > > Exactly. It was the present incarnation, not some > > possible future incarnation, that I raised my hand > > against. > >Really? By trying to sneak a major architectural change into a last 24 >hour "editorial" change? I am going to file an appeal about how this >entire situation was handled on the first place. > >What kind of work is that? Gathering consensus on a text that nobody has >seen because it does not exist yet? This consensus has no value and I >will now push this issue all the way to the top. > >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 Apr 3 05:34: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 h33DYHPL020344; Thu, 3 Apr 2003 05:34:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33DYGnt020341; Thu, 3 Apr 2003 05:34: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 h33DY8PL020301 for ; Thu, 3 Apr 2003 05:34:08 -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 h33DYGcU027951 for ; Thu, 3 Apr 2003 05:34:17 -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 GAA01076 for ; Thu, 3 Apr 2003 06:34:11 -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, 3 Apr 2003 13:33: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; Thu, 3 Apr 2003 13:33:23 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, 3 Apr 2003 13:33:23 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, 3 Apr 2003 13:33:23 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA25363; Thu, 3 Apr 2003 05:32:47 -0800 (PST) Message-Id: <5.1.0.14.2.20030403082035.0339a6e0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 08:25:00 -0500 To: awhite@arc.corp.mot.com From: Margaret Wasserman Subject: Re: alternatives to site-locals? Cc: In-Reply-To: <3E8B1148.C62895A@motorola.com> References: <200304021317.h32DHWB2028313@burp.tkv.asdf.org> <005001c2f91c$ffd7d2d0$210d640a@unfix.org> <20030402142705.GB30669@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 If you use this method to generate unique local addresses (which may be one viable alternative), you still won't want the semantics of current site-local addressing... The current site-local architecture does not allow sites to overlap or be nested. Sites also need to be "convex" which requires that their boundaries be at routing area or AS boundaries. Current site-local addresses are ambiguous, so they need to be treated specially in address selection rules, at UIs, etc. If you come up with any method to generate unique local addresses (mac-address-based, registry-based, etc.), then most of the restrictions in the current site-local architecture are unnecessary. Unique local addresses don't need to be treated as "scoped" addresses (in the sense this term is used in the scoped addressing architecture). They can be treated just like any other global addresses, and just filtered at the borders of the local space. Margaret At 02:35 AM 4/3/2003 +1000, Andrew White wrote: >Mike Saywell wrote: > > > > How about using fec0:::/64? That gives a (probably) private > > network per interface, the only issue is that you wouldn't be able to > > aggregate them in a sizeable network - however I agree that site-locals > > shouldn't be used in such a scenario. :) > >There are currently two drafts that describe how to implement this. There >are surface differences, but the basic idea is the same. > > * draft-hinden-ipv6-global-site-local-00.txt > * draft-white-auto-subnet-00.txt > > >----- > >As for site locals, there seem to be three issues: scope, ambiguity, >renumbering. > > >On scope: > >If you only ever have on address per machine (strictly no multihoming) then >scope isn't an issue. However, renumbering becomes awkward. > >If you allow multihoming, then either you must ban filtering or all >applications need to be able to compensate for situations where some >source-destination address pairs work and some don't. Architectural scoping >doesn't make the problem worse, and may make it better by providing hints to >applications if they choose to pay attention. > > >On ambiguity: > >In most sensible SL deployment scenarios, ambiguity is not an issue. >Disconnected networks don't matter, while any other SL network is not >supposed to talk outside the site, and so things will happily fail. And if >someone else's DNS returns an SL? Well, the packet gets dropped at the >filter on your site border router. This is slightly better than any other >bad DNS result where the packet is dropped somewhere in the global internet. > > >On renumbering: > >Most of the ambiguity questions are really renumbering questions. For >'large' sites, you can go provider-based (renumbering is potential issue), >or site-local (and be unrouteable), or NAT (yuck!), or PI (doesn't currently >exist). Multi-homing at least helps things, in that you can switch in your >new addresses before you switch out your old. > >If you wish to run an internal non-routeable address space, there are >several proposals to allow site-local address realms to be set-up such that >they are probably (or guaranteed) globally unique (without requiring >registration), which solves the local merge problem. > >On the other end of the spectrum are zeroconf networks that may or may not >be connected to a global provider. SL and multihoming is perfect for these >networks, since they can zeroconf in the SL space and then overlay a global >address space if convenient. > >And zeroconf networks don't have nearly the same renumbering problems as >large configured networks, because they are designed to rebuild all that >configuration information without human agents. > >Finally, there is advantage to using SL in private, disconnected networks, >and that is that those networks may eventually join the global internet. If >you have used SL, you know that you can continue to use that space locally >without masking global connectivity, and overlay a global address. If you >picked an arbitrary address, then you may have ambiguity that matters, >rather than ambiguity that doesn't. > > >I'm all in favour of an 'SL considered harmful'. However, there are several >situations were SL is exactly what is appropriate, and it seems an odd >philosophy to deprecate power-saws because they shouldn't be used in place >of drills. > >-- >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 05:37: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 h33DbBPL020695; Thu, 3 Apr 2003 05:37:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33DbBTr020689; Thu, 3 Apr 2003 05: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.9+Sun/8.12.9) with ESMTP id h33Db6PL020673 for ; Thu, 3 Apr 2003 05:37:06 -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 h33DbEcU028597 for ; Thu, 3 Apr 2003 05:37:14 -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 GAA26368 for ; Thu, 3 Apr 2003 06:37:08 -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, 3 Apr 2003 13:37:07 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, 3 Apr 2003 13:37: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, 3 Apr 2003 13:37:06 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, 3 Apr 2003 13:37:05 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h33DavCi022018; Thu, 3 Apr 2003 15:36:57 +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 h33Das2g257482; Thu, 3 Apr 2003 15:36:55 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49530 from ; Thu, 3 Apr 2003 15:36:52 +0200 Message-Id: <3E8C3923.7D4B149C@hursley.ibm.com> Date: Thu, 03 Apr 2003 15:37:39 +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: Michel Py Cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <963621801C6D3E4A9CF454A1972AE8F504F717@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, I don't get it. Nobody suggested pulling back the approved draft. We already know there will be a new version of the addressing architecture due to the IAB comments. There is plenty of time to follow due process, if we get consensus on what we want to do. So I just don't get what you are upset about. Brian Michel Py wrote: > > > Brian E Carpenter wrote: > > Exactly. It was the present incarnation, not some > > possible future incarnation, that I raised my hand > > against. > > Really? By trying to sneak a major architectural change into a last 24 > hour "editorial" change? I am going to file an appeal about how this > entire situation was handled on the first place. > > What kind of work is that? Gathering consensus on a text that nobody has > seen because it does not exist yet? This consensus has no value and I > will now push this issue all the way to the top. > > 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 Apr 3 05:48:35 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 h33DmZPL021564; Thu, 3 Apr 2003 05:48:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33DmZDs021563; Thu, 3 Apr 2003 05: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.9+Sun/8.12.9) with ESMTP id h33DmVPL021556 for ; Thu, 3 Apr 2003 05:48:31 -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 h33DmdcU001180 for ; Thu, 3 Apr 2003 05:48:39 -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 GAA09691 for ; Thu, 3 Apr 2003 06:48:34 -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, 3 Apr 2003 13:48: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, 3 Apr 2003 13:48: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, 3 Apr 2003 13:48:33 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, 3 Apr 2003 13:48:32 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h33DmFu9029784; Thu, 3 Apr 2003 15:48:15 +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 h33DmF2g271374; Thu, 3 Apr 2003 15:48:15 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38300 from ; Thu, 3 Apr 2003 15:48:13 +0200 Message-Id: <3E8C3BCD.FA7099CD@hursley.ibm.com> Date: Thu, 03 Apr 2003 15:49:01 +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: Dan Lanciani Cc: ipng@sunroof.eng.sun.com Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: DeprecatingSite-Local Addressing) References: <200304021938.OAA29010@ss10.danlan.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: > > Brian E Carpenter wrote: > > |I think we should clear the desktop first, by getting rid of ambiguous > |site-local address space, and then discuss possible new solutions. > > Could you explain why you think this is the correct order? Because I can't see any other way of getting the WG out of its perpetual discussion loop on this topic. > To me it seems > completely wrong. Eliminating site-locals will probably require changes in > much the same areas that any new solution will require. Why edit everything > twice? Who said that? We have just shipped the addressing architecture (with ambiguous SLs) to the RFC Editor. We know we have to make a new version. If we can agree to deprecate ambiguous SLs, we can then invent a non-ambiguous replacement for the next version of the addressing architecture. > Once site-locals are gone there will be very little incentive for > those who dismiss their uses to look at alternate solutions since they do > not recognize the associated problems as problems. I think you are misreading a lot of the "deprecate" votes, including mine. We certainly aren't done even if we reach consensus on deprecation. 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 Apr 3 05:49:28 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 h33DnSPL021603; Thu, 3 Apr 2003 05:49:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33DnSZq021602; Thu, 3 Apr 2003 05:49: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 h33DnPPL021595 for ; Thu, 3 Apr 2003 05:49: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 h33DnXcU001421 for ; Thu, 3 Apr 2003 05:49:33 -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 GAA02722 for ; Thu, 3 Apr 2003 06:49: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; Thu, 3 Apr 2003 13:49: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, 3 Apr 2003 13:49: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, 3 Apr 2003 13:49:26 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; Thu, 3 Apr 2003 13:49: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 h33CjxD04402; Thu, 3 Apr 2003 14:46:04 +0200 Message-Id: <3E8C2D07.5070901@it.su.se> Date: Thu, 03 Apr 2003 14:45:59 +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: john.loughney@nokia.com, lear@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: site-locals References: <5.1.0.14.2.20030403081403.037bf2e8@mail.windriver.com> In-Reply-To: <5.1.0.14.2.20030403081403.037bf2e8@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: > > > To keep them, we need to document and resolve the issues that > they cause, update all of the IPv6 routing protocols to > document how site-boundaries are maintained, and document > how address selection will be performed in several upper > layer protocols (at least SCTP, SIP and FTP). We might also > need to provide guidance to non-IETF applications protocol > developers and/or application developers for how to handle > site-local addresses in non-IETF applications. And, we'd need > to specify split DNS. > This is assuming that it is possible to "live with" site-locals. We may wind up writing lots of documents that essentially say "lots of apps will break; tough luck!". I propose that site-locals change so many fundamental assumptions that applications make that the IAB need to study the issue and make a recommendation -- i.e I don't think that the inclusion of site-locals in the core architecture of the Internet should be at the sole discression of the ipv6 or any other wg. 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 Apr 3 05:59:58 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 h33DxwPL022245; Thu, 3 Apr 2003 05:59:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33DxwD4022244; Thu, 3 Apr 2003 05:59: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.9+Sun/8.12.9) with ESMTP id h33DxsPL022233 for ; Thu, 3 Apr 2003 05:59: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 h33E02cU003345 for ; Thu, 3 Apr 2003 06:00:02 -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 GAA24625 for ; Thu, 3 Apr 2003 06:59: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; Thu, 3 Apr 2003 13:59: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; Thu, 3 Apr 2003 13:59: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; Thu, 3 Apr 2003 13:59:56 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; Thu, 3 Apr 2003 13:59:55 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h33Dxqu9023750; Thu, 3 Apr 2003 15:59:52 +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 h33Dxo9X282302; Thu, 3 Apr 2003 15:59:51 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA57360 from ; Thu, 3 Apr 2003 15:59:49 +0200 Message-Id: <3E8C3E84.48AA2676@hursley.ibm.com> Date: Thu, 03 Apr 2003 16:00:36 +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: steven.blake@ericsson.com Cc: ipng@sunroof.eng.sun.com Subject: Re: What is a site local address? [Re: CONSENSUS CALL: DeprecatingSite-Local Addressing] References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> <1049232974.20706.1409.camel@newcastle.torrentnet.com> <3E8AA231.C4992A71@hursley.ibm.com> <1049297611.20706.1444.camel@newcastle.torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven Blake wrote: > > On Wed, 2003-04-02 at 03:41, Brian E Carpenter wrote: > > > As I already said under another subject line, > > what I understood we were deprecating is SL as defined > > in the current address architecture, i.e. FEC0::/10. > > Do you mean the e-mail where you said the following? > > --> I prefer to think about this the other way round: kill the ambiguous > --> space, which we have learnt the hard way is a mistake, and then > --> design the alternative, which may well be unrouteable GUPI (and for > --> all I care, starts with FEC::/10). yes > > > That's the only formal definition of SL, so I don't see > > what else we could be referring to. > > Well, I'm still confused. what do you think we are possibly deprecating, if it isn't the current definition? 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 Apr 3 06:28:30 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 h33ESUPL022775; Thu, 3 Apr 2003 06:28:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33EST7j022774; Thu, 3 Apr 2003 06:28:29 -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.9+Sun/8.12.9) with ESMTP id h33ESPPL022767 for ; Thu, 3 Apr 2003 06:28:26 -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 h33ESQS27035; Thu, 3 Apr 2003 16:28:27 +0200 (MEST) Date: Thu, 3 Apr 2003 16:28:21 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: site-locals To: john.loughney@nokia.com Cc: lear@cisco.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 > So, getting rid of site locals doesn't remove much of the motivation, and > there are no ready solutions to fulfill some real needs; which worries me. > Is it possible that by killing site locals, we set the stage for people to > do something worse? Will people still use FE0C, even if it is deprecated? > Will people pick random prefixes for use as site local / private addresses? > What is the amount of work to depreciate site locals - how many RFCs need > to be updated? I'm not convinced that deprecating site locals really solves > anything. [Sorry for the long email, but I don't intent to post on this subject very often, if ever again.] John, I think there is a large difference between what is sactioned/blessed/approved in a standards track RFC, and what folks might actually choose to do on their own in at least two spaces: If we have site-locals in an RFC (with some limiting restrictions) I can envision folks down the road wanting to improve on site-locals by wanting to write a standards track RFC on how to extend them to be more useful i.e. by pushing more towards their full glory (which the community clearly does not want at this point in time). I ask myself what tools the IETF as a community will have to push back on such a proposal should it arrive. It is clearly much easier to push back if the IETF can ask "what problem are you solving" as part of specifying the site-local addresses RFC, but if site-locals are already specified in an RFC we will not have that tool to help the community come to a shared understanding of the goals. If we have site-locals in an RFC (with limitations) there is likely to be an larger pressure on vendors to improve their implementations wrt site-locals. I can envision well-intentioned customers that would want multi-sited hosts or routers, and vendors feeling forced to implement them. This is much less likely if "site-locals" is just an undocumented "pick any prefix if disconnected" approach than something sactioned. Of course, if we really want site-locals in their full glory we should standardize them. But as I said at the mike in SF I don't find any important problems that site-locals solve for which we don't have other solutions, which motivate the added complexity in the routing, DNS, application, etc spaces. The claimed motivations I've found over the years are: 1. Try to isolate communication within a site from site-renumbering. 2. Serve as a security token to simplify configuration of filtering in simple devices. 3. Provide address space to clouds which are disconnected. 4. Provide address space to clouds which are intermittently connected. (and perhaps I've missed some that are more than mere variants than the above.) I embarked on trying to make #1 work a few years back but, with the assumption that a significant number of nodes will use MIPv6, to make MIPv6 nodes be able to benefit from this while in their home site yet function when they move outside their home site, the complexity flew through the roof. And the philosophical point about "aren't we here to make global communication work?" made me personally drop that pursuit. For #2 we have bellovin/zill prefix option extensions which provide a strict superset of what one could do with site-locals in this area. (Folks might want to debate whether #2 is a good idea or not, but that debate is independent of whether site-locals or bellovin/zill advertisements are used for this. I'm only here to state that site-locals are not needed to solve this problem should we wish to solve it.) For #3 any (random) prefix suffices - there is no need to designate a prefix in the addressing architecture for this. Whether a particular domain uses fec0::/10 or dead::/16 doesn't matter AFAIK - in any case they need to renumber should they connect to the Internet *or* connect privately to some other previously isolated/disconnected site. I think #4 (which I didn't talk about at the mike) is a red herring. Perhaps the issue is a restatement of #1 (due to the ISP implicitly forcing a renumbering each time the site connects) in which case the points about #1 applies. And note that making site-locals help with #4 (and #1) involves having nodes be configured with both globals and site-locals i.e. it brings in most (but not all) of the complexities of the full-fledged site-local support. Note that the community seems to have an unrelated desire to get "PI space" for free - and in some cases site-locals seem to be confused with some form of PI space or stepping stone to PI space. There is some work (in and around multi6, ipv6mh, and hip) that is looking at two space systems (identifier and locator separation) that can hopefully provide something of similar look and feel as PI addresses. Yes, this is no small task. But I sure hope we can spend energy on that longer term and harder problem than continuing to delude ourselves that site-local addresses have benefits with justify their added complexity. So let's not ask what deprecating site-locals solve - let's ask what problems site-locals solve. They were added to the addressing architecture at a time when there was little if no wide-spread understanding of the larger implications. I hope we have learned some from the discussions over the last few years (on ipng and zeroconf as well to some extent) so that we can try to do this cost/benefit analysis. Respectfully, 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 Apr 3 06:44:35 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 h33EiZPL023051; Thu, 3 Apr 2003 06:44:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33EiZ9A023050; Thu, 3 Apr 2003 06:44: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.9+Sun/8.12.9) with ESMTP id h33EiVPL023043 for ; Thu, 3 Apr 2003 06:44:31 -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 h33EieHP026867 for ; Thu, 3 Apr 2003 06:44:40 -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 HAA28890 for ; Thu, 3 Apr 2003 07:44:34 -0700 (MST) From: Robert.Peschi@alcatel.be 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, 3 Apr 2003 14:44: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; Thu, 3 Apr 2003 14:44: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; Thu, 3 Apr 2003 14:44:32 Z Received: from relay2.alcatel.be ([195.207.101.239] [195.207.101.239]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 14:44:32 Z Received: from bemail01.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.11.4) with ESMTP id h33EiUx12900 for ; Thu, 3 Apr 2003 16:44:30 +0200 (MET DST) Sensitivity: Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Date: Thu, 3 Apr 2003 16:44:28 +0200 Message-Id: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/03/2003 16:44:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing Robert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 06:58: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 h33EwbPL023593; Thu, 3 Apr 2003 06:58:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33EwaF1023592; Thu, 3 Apr 2003 06:58: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.9+Sun/8.12.9) with ESMTP id h33EwXPL023585 for ; Thu, 3 Apr 2003 06:58: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 h33EwfcU021696 for ; Thu, 3 Apr 2003 06:58: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-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03268 for ; Thu, 3 Apr 2003 06:58:36 -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, 3 Apr 2003 14:58:31 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, 3 Apr 2003 14:58:29 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, 3 Apr 2003 14:58:29 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, 3 Apr 2003 14:58:29 Z Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h33EutN18969 for ; Thu, 3 Apr 2003 17:56:56 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Apr 2003 17:58:26 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 17:58:26 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 17:58:25 +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: site-locals Date: Thu, 3 Apr 2003 17:58:24 +0300 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: site-locals Thread-Index: AcL547QSsvtYODzJR6Sn1J0xh8sgogADRjGw To: Cc: , X-OriginalArrivalTime: 03 Apr 2003 14:58:25.0850 (UTC) FILETIME=[7A9031A0:01C2F9F1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33EwYPL023586 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > >What is the amount of work to depreciate site locals - how > many RFCs need > >to be updated? I'm not convinced that deprecating site > locals really solves > >anything. > > The work to keep, and finish, site-locals is much greater than > the work to deprecate them. > > To deprecate them, I think that the addressing architecture > and the default address selection rules would be the only RFCs > (both at PS) that we need to change. > > To keep them, we need to document and resolve the issues that > they cause, update all of the IPv6 routing protocols to > document how site-boundaries are maintained, and document > how address selection will be performed in several upper > layer protocols (at least SCTP, SIP and FTP). We might also > need to provide guidance to non-IETF applications protocol > developers and/or application developers for how to handle > site-local addresses in non-IETF applications. And, we'd need > to specify split DNS. Good point, I stand corrected on this point. You might be interested in this draft, the SCTP folks made a proposal how to handle IPv6 address scoping and SCTP - its only 3 pages, so its a quick read: http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpipv6-01.txt 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 Apr 3 07:25: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 h33FPBPL024164; Thu, 3 Apr 2003 07:25:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33FPB1v024163; Thu, 3 Apr 2003 07:25: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 h33FP7PL024156 for ; Thu, 3 Apr 2003 07:25: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 h33FPFcU028712 for ; Thu, 3 Apr 2003 07:25:15 -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 HAA23488 for ; Thu, 3 Apr 2003 07:25: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; Thu, 3 Apr 2003 15:25: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; Thu, 3 Apr 2003 15:25: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; Thu, 3 Apr 2003 15:25:07 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; Thu, 3 Apr 2003 15:25:06 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h33FOZvm084144; Thu, 3 Apr 2003 07:24:35 -0800 (PST) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h33FOZO9084143; Thu, 3 Apr 2003 07:24:35 -0800 (PST) Date: Thu, 3 Apr 2003 07:24:35 -0800 From: Shannon -jj Behrens To: awhite@arc.corp.mot.com Cc: Christian Huitema , ipng@sunroof.eng.sun.com, Bob Hinden Subject: Re: Globally unique link prefix alternative to site-locals Message-Id: <20030403152434.GA83777@alicia.nttmcl.com> References: <3E8B7B99.93C43FC6@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E8B7B99.93C43FC6@motorola.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 03, 2003 at 10:08:57AM +1000, Andrew White wrote: > > Is anyone interested in pursuing this design? > > Well, I have an implementation. > > If Bob is happy, I'd like to grab most of his text (since it's better > written than mine) and wrap it around my bit-ordering proposal. > > > > - If the /16 is well known, it can be plugged as "least preferred" in > > the address selection rules. > > I still have qualms with this. I'm of the opinion that if site-locals exist > in a network then hosts should prefer them (iff both hosts have them); the > assumption is that SL addresses are at least as stable as externally sourced > addresses. Just a side note--my main point is below, but why is this the case? If a router is still advertising a global prefix even though there is no global connectivity, two local hosts can still communicate using that global prefix, correct? > Of course, this policy will potentially be inappropriate for applications > that do address forwarding across a site boundary, but I'd argue that these > are the special case. Apps that do address forwarding NOT across a site > boundary will be happy with the standard policy. I'm sure it's obvious, but apps that do address forwarding across site boundaries should probably just be aware that they are P2P apps and thus use a socket option that makes them prefer global addresses. If this were a part of the API documentation, I think this would be fine. 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 Thu Apr 3 07:36:15 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 h33FaEPL024455; Thu, 3 Apr 2003 07:36:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33FaE4k024454; Thu, 3 Apr 2003 07:36: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.9+Sun/8.12.9) with ESMTP id h33FaBPL024447 for ; Thu, 3 Apr 2003 07:36:11 -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 h33FaJcU002040 for ; Thu, 3 Apr 2003 07:36:19 -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 HAA06818 for ; Thu, 3 Apr 2003 07:36:13 -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, 3 Apr 2003 15:36:13 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, 3 Apr 2003 15:32:54 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, 3 Apr 2003 15:36:08 Z Received: from klapautius.it.su.se ([217.215.166.49] [217.215.166.49]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 15:36:07 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 h33EX2D06228; Thu, 3 Apr 2003 16:33:02 +0200 Message-Id: <3E8C461E.7040004@it.su.se> Date: Thu, 03 Apr 2003 16:33:02 +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: john.loughney@nokia.com CC: mrw@windriver.com, lear@CISCO.COM, ipng@sunroof.eng.sun.com Subject: Re: site-locals 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: > >Good point, I stand corrected on this point. You might be interested >in this draft, the SCTP folks made a proposal how to handle IPv6 >address scoping and SCTP - its only 3 pages, so its a quick read: > >http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpipv6-01.txt > > > Interesting reading. Note the following text: - the source address in the initial IPv6 packet (the packet carrying the INIT) MUST be an address belonging to the specified destination zone. Since zones are local to the node and not required to be stable over time this means that the application using sctp must have some other means of learning which zone belongs to which desired scope. This mechanism will probably have "system manager" on his/her business card. Speaking from experience (yes I do operate heavy machinery) it is completely unrealistic to expect application managers to be able to maintain this state at every node. To me this sounds like a big gun pointing at my foot... no wait it is pointing at my head! :-( 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 Thu Apr 3 07:51:12 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 h33FpCPL024802; Thu, 3 Apr 2003 07:51:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33FpCU8024801; Thu, 3 Apr 2003 07: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 h33Fp9PL024794 for ; Thu, 3 Apr 2003 07: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 h33FpHcU006578 for ; Thu, 3 Apr 2003 07:51:17 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA16768 for ; Thu, 3 Apr 2003 08:51:10 -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, 3 Apr 2003 15:51:07 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, 3 Apr 2003 15:46:23 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, 3 Apr 2003 15:49:38 Z Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 15:49:37 Z Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h33FnYt19443; Thu, 3 Apr 2003 10:49:34 -0500 (EST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h33FnXL67289; Thu, 3 Apr 2003 10:49:33 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id KAA00143; Thu, 3 Apr 2003 10:49:25 -0500 (EST) Subject: Re: What is a site local address? [Re: CONSENSUS CALL: DeprecatingSite-Local Addressing] From: Steven Blake Reply-To: steven.blake@ericsson.com To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3E8C3E84.48AA2676@hursley.ibm.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> <1049232974.20706.1409.camel@newcastle.torrentnet.com> <3E8AA231.C4992A71@hursley.ibm.com> <1049297611.20706.1444.camel@newcastle.torrentnet.com> <3E8C3E84.48AA2676@hursley.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 03 Apr 2003 10:49:22 -0500 Message-Id: <1049384970.55213.83.camel@newcastle.torrentnet.com> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2003-04-03 at 09:00, Brian E Carpenter wrote: > Steven Blake wrote: > > > > On Wed, 2003-04-02 at 03:41, Brian E Carpenter wrote: > > > > > As I already said under another subject line, > > > what I understood we were deprecating is SL as defined > > > in the current address architecture, i.e. FEC0::/10. > > > > Do you mean the e-mail where you said the following? > > > > --> I prefer to think about this the other way round: kill the ambiguous > > --> space, which we have learnt the hard way is a mistake, and then > > --> design the alternative, which may well be unrouteable GUPI (and for > > --> all I care, starts with FEC::/10). > > yes > > > > > > That's the only formal definition of SL, so I don't see > > > what else we could be referring to. > > > > Well, I'm still confused. > > what do you think we are possibly deprecating, if it isn't the > current definition? There have been several proposals to turn addresses in fec0::/10 into GUPIs or PUPIs (Probabilistically Unique PIs), similar to your note above). Since I wasn't in SF, I wanted to make sure that we weren't being asked to preclude those as well. For whatever it is worth, I think that ambiguous addresses are a disaster, but nothing is going to prevent those that want RFC 1918-style addresses from inventing them. It is better to have a well-defined prefix for this, rather than risk the chaos of people creating them out of the global space. I would be happy to see fec0::/11 set aside for private/experimental (including PUPIs), and fee0::/11 set aside for GUPIs. Any notion of site ID should be ripped out of all the specs. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 07:58:59 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 h33FwxPL025076; Thu, 3 Apr 2003 07:58:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33FwxIH025075; Thu, 3 Apr 2003 07:58: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.9+Sun/8.12.9) with ESMTP id h33FwtPL025066 for ; Thu, 3 Apr 2003 07:58:55 -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 h33Fx3HP017177 for ; Thu, 3 Apr 2003 07:59: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 IAA17149 for ; Thu, 3 Apr 2003 08:58:54 -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, 3 Apr 2003 15:58: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; Thu, 3 Apr 2003 15:55: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, 3 Apr 2003 15:58:53 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, 3 Apr 2003 15:58:52 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 4D9E815C7; Thu, 3 Apr 2003 10:58:52 -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, 3 Apr 2003 10:58:52 -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: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Thu, 3 Apr 2003 10:58:51 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD030@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CONSENSUS CALL: Deprecating Site-Local Addressing Thread-Index: AcL4jei+5WdGDaNIS0mlbwA1zB8j3QBa/ODg From: "Bound, Jim" To: , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 03 Apr 2003 15:58:52.0195 (UTC) FILETIME=[EC088730:01C2F9F9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33FwuPL025069 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well stated. I agree with this list. /jim > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Tuesday, April 01, 2003 3:28 PM > To: Margaret Wasserman > Cc: ipng@sunroof.eng.sun.com > Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing > > > YES -- Deprecate site-local unicast addressing > > Does not provide any tangible security benefit. > Provides false sense of security. > Increases application complexity. > Reduces application reliability. > Requires too many compensating hacks to other protocols. > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 3 08:01:30 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 h33G1UPL025194; Thu, 3 Apr 2003 08:01:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33G1URN025193; Thu, 3 Apr 2003 08:01: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.9+Sun/8.12.9) with ESMTP id h33G1RPL025186 for ; Thu, 3 Apr 2003 08:01:27 -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 h33G1ZHP018052 for ; Thu, 3 Apr 2003 08:01:35 -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 IAA19715 for ; Thu, 3 Apr 2003 08:01:29 -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, 3 Apr 2003 16:01: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; Thu, 3 Apr 2003 15:58: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, 3 Apr 2003 16:01:28 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, 3 Apr 2003 16:01:28 Z Content-class: urn:content-classes:message Subject: RE: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Apr 2003 08:01:27 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F720@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: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing Thread-Index: AcL54pr1AHDEkWhfRI66EKM2txtISwAFQTZw From: "Michel Py" To: "Brian Carpenter" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33G1RPL025187 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > Brian E Carpenter wrote: > I didn't mean we should pull the current draft, which > is already in the RFC queue. Obviously, if we get > consensus on the principle, there is then follow up > to respect the process. I didn't think that my words > implied otherwise; I just want to take one step at a > time. Well I found your post confusing to say the least. Besides, there is history. Less than 5 months ago you proposed to do it about the same site-local issue: > -----Original Message----- > From: Brian E Carpenter > Sent: Tuesday, November 12, 2002 4:53 AM > To: ipng@sunroof.eng.sun.com > Subject: Proposal for site-local clean-up > Unfortunately it's too late to catch the addressing > architecture document unless we recall it from the > RFC Editor and cycle it through the IESG again. But > I propose that we do exactly that Also, four days ago you indicated that you were hoping that the question of what would replace site-locals would not be raised before consensus was achieved: >> Tim Chown wrote: >> So, as Michel asked, what's the solution for >> intermittently connected sites in the absence of >> site locals? > Brian E Carpenter wrote: > Well, I'd hoped to avoid that question until we had > mailing list consensus on deprecating SLs. One in the other, I had reasons to be concerned, don't you think? 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 Apr 3 08:10:02 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 h33GA1PL025649; Thu, 3 Apr 2003 08:10:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33GA1e9025648; Thu, 3 Apr 2003 08:10: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.9+Sun/8.12.9) with ESMTP id h33G9wPL025641 for ; Thu, 3 Apr 2003 08:09:58 -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 h33GA6HP020635 for ; Thu, 3 Apr 2003 08:10:06 -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 JAA22766 for ; Thu, 3 Apr 2003 09:08:12 -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, 3 Apr 2003 16:08: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; Thu, 3 Apr 2003 16:04: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; Thu, 3 Apr 2003 16:08:11 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, 3 Apr 2003 16:08:11 Z Content-class: urn:content-classes:message Subject: RE: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Apr 2003 08:08:10 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F721@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: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing Thread-Index: AcL51sgGEe2dQkhvT9Kc9TsdV1O14wAISP0g From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33G9wPL025642 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, >> Michel Py wrote: >> Where is the doc to deprecate site-local addressing? > Margaret Wasserman wrote: > [Large snip] > It will be written if there is IETF WG consensus to > do the deprecation. I am not actually certain if > site-locals will be officially deprecated in the > separate document that I mentioned above, or through > an update to the addressing architecture (since that > would be on the standards track), but I'm also not > sure that it matters, as both would be necessary. Works for me. On a side note, I just re-read addrarch 3.11 and I found no text about how a WG deprecates a prefix. As far as I'm concerned, it could mean that all WG members are supposed to telnet to all IPv6 routers in the world and deprecate the prefix there. We need better than this. 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 Thu Apr 3 08:12: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 h33GCuPL025799; Thu, 3 Apr 2003 08:12:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33GCuIh025798; Thu, 3 Apr 2003 08:12: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.9+Sun/8.12.9) with ESMTP id h33GCrPL025791 for ; Thu, 3 Apr 2003 08:12:53 -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 h33GD1HP021673 for ; Thu, 3 Apr 2003 08:13:01 -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 JAA25327 for ; Thu, 3 Apr 2003 09:12: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; Thu, 3 Apr 2003 16:12: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; Thu, 3 Apr 2003 16:12: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, 3 Apr 2003 16:12:46 Z Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 16:12:46 Z Received: from nomad.ctd.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA02135; Thu, 3 Apr 2003 10:12:40 -0600 (CST) Message-Id: <5.1.1.5.2.20030403093607.009ead90@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 03 Apr 2003 10:10:47 -0600 To: Margaret Wasserman , ipng@sunroof.eng.sun.com From: Richard Carlson Subject: Re: My Thoughts on Site-Locals In-Reply-To: <5.1.0.14.2.20030403064541.03e2cae8@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 Margaret; I have a real hard time understanding why proponents of the depreciate SL's claim that SL's would require special handling by applications , while unique PI's don't. If an address has limited scope, i.e., there is an address filter somewhere in the network that prohibits global e2e connectivity, then sometimes applications will fail to establish connections using those addresses. What I fail to see is why the SL prefix (FEC0::/10) is any different than a unicast prefix (say 2001:0400/32). I contend that it isn't the SL unicast prefix that breaks the e2e principle, but the address filter. The only difference I can see is that the SL prefix guarantees that an address filter will be crossed, while the unicast prefix makes no such guarantee. If we accept that these filters will exist, for all unicast prefixes, then apps will have problems when communicating when peers are separated by this filter. So I don't accept your point below that SL's require special handling by apps, but unique random addresses that provide the same function don't. What am I missing that leads you to a different conclusion? Rich At 07:01 AM 4/3/03 -0500, Margaret Wasserman wrote: >[snip snip snip] > >Site-local addresses have properties that are not needed to address >these problems, and that cause problems for routing protocols and >upper-layer protocols, such as: > > - Ambiguity (requires zone ID to disambiguate). > - Need to retain site "convexity". > - Single level of nesting (you can't have a further access- > controlled site within a site). > - Special address selection handling required at the IP > layer and in applications. > - Places the knowledge of private addressing in all implementations, > instead of keeping the knowledge of routing boundaries > constrained to the infrastructure (routers, firewalls, > etc.) > >Using random addresses for disconnected sites was proposed as an >alternative, but that is not the only alternative. There are, in >fact, two superior alternatives that do not require any standardization >work by the IPv6 WG (or any other IETF WG): > > - Enterprises could use part of their /48 as private > addresses and filter at private borders. This > is superior to site-locals because: > > - It allows nesting of private areas. > - The owner of local addresses can be identified. > - Non-ambiguous -- if sent outside the local area, > they are unreachable and won't point to > the wrong network or node. > - Doesn't require special handling on end-nodes > or by applications, etc. > > - Registries could offer private address allocations to > individual enterprises/people. This is also > superior for the same reasons listed above. > >[snip snip snip] >Just my thoughts... > >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 >-------------------------------------------------------------------- > ------------------------------------ Richard A. Carlson e-mail: RACarlson@anl.gov Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 08:48: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 h33GmXPL026364; Thu, 3 Apr 2003 08:48:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33GmXfT026363; Thu, 3 Apr 2003 08:48: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.9+Sun/8.12.9) with ESMTP id h33GmTPL026353 for ; Thu, 3 Apr 2003 08:48:29 -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 h33GmbHP002474 for ; Thu, 3 Apr 2003 08:48:37 -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 JAA14849 for ; Thu, 3 Apr 2003 09:48: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; Thu, 3 Apr 2003 16:48: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, 3 Apr 2003 16:48: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; Thu, 3 Apr 2003 16:48:31 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; Thu, 3 Apr 2003 16:48:30 Z Received: from cisco.com (sjc-vpn3-593.cisco.com [10.21.66.81]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA17226; Thu, 3 Apr 2003 08:48:20 -0800 (PST) Message-Id: <3E8C65D3.8060209@cisco.com> Date: Thu, 03 Apr 2003 08:48:19 -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: "Nick 'Sharkey' Moore" CC: ipng@sunroof.eng.sun.com Subject: Re: site-locals References: <3E8BC77A.7060506@cisco.com> <20030403084935.GD27840@zoic.org> In-Reply-To: <20030403084935.GD27840@zoic.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nick, > I would question your assumptions: > a) That the existence of site locals will cause people to use NAT > b) That the deprecation of site locals will prevent people from > using NAT. I think we have to turn this around- I view NATs as a bad thing for all the reasons you've heard time and time again (so I won't repeat them). To get rid of them, it is this group's responsibility to put forth a vision of how we can have a functional world without them. We need to answer the real concerns people have raised as they've voted "no". If this group doesn't do it, I can guarantee you that NATs *will* exist and be forever ensconced in the architecture. With that in mind, I ask the following question: >>what is the benefit of going forward at all with IP version 6? and you answered: > A very large, very flexible address space, and a protocol which > allows much greater flexibility than IPv4 for, for example, Mobility. But with NATs I don't need a large address space. I simply have address spaces. That will be the operating model I must code to. While it is true that IPv6 will provide a nice advance in Mobility, I'm not sure it's worth the effort or the pain, and I doubt many enterprises will think so either. So, if you've voted "no", ask yourselves whether you're voting "no" to IPv6 with the same two letters. Regards, 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 Thu Apr 3 09:09: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 h33H9LPL026680; Thu, 3 Apr 2003 09:09:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33H9LKK026679; Thu, 3 Apr 2003 09:09: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 h33H9HPL026672 for ; Thu, 3 Apr 2003 09:09:17 -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 h33H9PHP009458 for ; Thu, 3 Apr 2003 09:09:26 -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 JAA19850 for ; Thu, 3 Apr 2003 09:09:20 -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, 3 Apr 2003 17:08: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; Thu, 3 Apr 2003 17:08: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; Thu, 3 Apr 2003 17:08:39 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, 3 Apr 2003 17:08:39 Z Content-class: urn:content-classes:message Subject: RE: site-locals MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Apr 2003 09:08:38 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F723@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: site-locals Thread-Index: AcL55Rxvp73gbi5XT32juX71wVqNtwAGxqAg From: "Michel Py" To: "Margaret Wasserman" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33H9HPL026673 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, >> john loughney wrote: >> What is the amount of work to depreciate site locals - how >> many RFCs need to be updated? I'm not convinced that >> deprecating site locals really solves anything. > Margaret Wasserman wrote: > The work to keep, and finish, site-locals is much greater > than the work to deprecate them. What about a comparison between: - The work to keep, and finish, site-locals and - The work to deprecate _and_ replace them. There is no deprecation without a replacement, and given the nature of the beast it is permitted to think that consensus on a replacement might be not achievable, leading that they would indeed not been deprecated lacking of a valid replacement and we would be back where we are right now. IMHO, the compromise approach such as the exclusive model Bob and you came up with has more chances of success and a good starting point. If the WG can't agree on such a thing I doubt it could agree on a solution started from scratch. 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 Apr 3 09:20: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 h33HK8PL026875; Thu, 3 Apr 2003 09:20:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33HK7qi026874; Thu, 3 Apr 2003 09:20: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 h33HK4PL026867 for ; Thu, 3 Apr 2003 09:20: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 h33HKCHP013743 for ; Thu, 3 Apr 2003 09:20: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 KAA11011 for ; Thu, 3 Apr 2003 10:20:07 -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, 3 Apr 2003 17:20: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, 3 Apr 2003 17:19: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; Thu, 3 Apr 2003 17:19: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, 3 Apr 2003 17:19:40 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h33HJSJ29453; Thu, 3 Apr 2003 20:19:28 +0300 Date: Thu, 3 Apr 2003 20:19:27 +0300 (EEST) From: Pekka Savola To: Michel Py cc: Margaret Wasserman , , Subject: exclusive model [RE: site-locals] In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F723@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, 3 Apr 2003, Michel Py wrote: > IMHO, the compromise approach such as the exclusive model Bob and you > came up with has more chances of success and a good starting point. If > the WG can't agree on such a thing I doubt it could agree on a solution > started from scratch. Exclusive model is pretty much unworkable except: 1) as an access control mechanism; there are better methods for that 2) with disconnected sites -- and then "limited model" would also apply just great. I'm not personally that much opposed to the limited model, and could maybe even live with exclusive model -- but it depends on certain things (like site-border routers) that are unacceptable. The proposal doesn't seem to be be workable in practise, IMHO. -- 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 Apr 3 09:33:30 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 h33HXTPL027165; Thu, 3 Apr 2003 09:33:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33HXTLN027164; Thu, 3 Apr 2003 09:33: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.9+Sun/8.12.9) with ESMTP id h33HXQPL027157 for ; Thu, 3 Apr 2003 09:33: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 h33HXYcU011807 for ; Thu, 3 Apr 2003 09:33: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.3p2+Sun/8.9.3) with ESMTP id KAA18883 for ; Thu, 3 Apr 2003 10:33: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, 3 Apr 2003 17:33:28 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, 3 Apr 2003 17:33:27 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, 3 Apr 2003 17:33:27 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, 3 Apr 2003 17:33:27 Z Content-class: urn:content-classes:message Subject: RE: exclusive model [RE: site-locals] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Apr 2003 09:33:26 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F725@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: exclusive model [RE: site-locals] Thread-Index: AcL6BTDdtz4OhyYjTM+XrH+AYBUNVgAAOphA From: "Michel Py" To: "Pekka Savola" Cc: "Margaret Wasserman" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33HXQPL027158 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > Pekka Savola wrote: > but it depends on certain things (like site-border routers) > that are unacceptable. The proposal doesn't seem to be be > workable in practise, IMHO. This is speculation, also called FUD and does not lead to making progress. > I'm not personally that much opposed to the limited model, > and could maybe even live with exclusive model This is the real deal: I am myself favorable to the moderate model, but I could leave with the exclusive model. We are talking about what could reach consensus here, not about what everybody would like to have. >From my chair, the model that could reach consensus is the exclusive model. It's a compromise, and as such nobody likes it but it also means that it is something that everybody could live with. 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 Apr 3 09:40: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 h33HeoPL027324; Thu, 3 Apr 2003 09:40:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33HeoA8027322; Thu, 3 Apr 2003 09:40: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 h33HekPL027314 for ; Thu, 3 Apr 2003 09:40: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 h33HesHP021984 for ; Thu, 3 Apr 2003 09:40:54 -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 KAA11799 for ; Thu, 3 Apr 2003 10:40: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; Thu, 3 Apr 2003 17:40: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, 3 Apr 2003 17:37: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; Thu, 3 Apr 2003 17:40:44 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 17:40:43 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h33HeYc29676; Thu, 3 Apr 2003 20:40:35 +0300 Date: Thu, 3 Apr 2003 20:40:34 +0300 (EEST) From: Pekka Savola To: Michel Py cc: Margaret Wasserman , , Subject: RE: exclusive model [RE: site-locals] In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F725@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, 3 Apr 2003, Michel Py wrote: > > Pekka Savola wrote: > > but it depends on certain things (like site-border routers) > > that are unacceptable. The proposal doesn't seem to be be > > workable in practise, IMHO. > > This is speculation, also called FUD and does not lead to making > progress. I'll show you it's not FUD when/if the I-D comes out if you don't believe it before. Exclusive model creates certain very disturbing problems in hosts (wrt. oscillation between global and site-local) which might be fixable, and ones even more so in the routers (requiring quite extensive site-local implementation) which is unlikely to go away. -- 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 Apr 3 09:44:16 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 h33HiFPL027453; Thu, 3 Apr 2003 09:44:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33HiFi8027452; Thu, 3 Apr 2003 09:44: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.9+Sun/8.12.9) with ESMTP id h33HiBPL027442 for ; Thu, 3 Apr 2003 09:44:11 -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 h33HiKcU015763 for ; Thu, 3 Apr 2003 09:44: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-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16739 for ; Thu, 3 Apr 2003 09:44:13 -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, 3 Apr 2003 17:43: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; Thu, 3 Apr 2003 17:43: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, 3 Apr 2003 17:43:49 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 17:43:48 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 03 Apr 2003 09:43:42 -0800 Reply-To: From: "Tony Hain" To: "'Erik Nordmark'" , Cc: , Subject: RE: site-locals Date: Thu, 3 Apr 2003 09:43:23 -0800 Message-Id: <0a8101c2fa08$867ee260$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 h33HiCPL027443 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > ... > I think #4 (which I didn't talk about at the mike) is a red > herring. Perhaps the issue is a restatement of #1 (due to the > ISP implicitly forcing a > renumbering each time the site connects) in which case the > points about #1 applies. And note that making site-locals > help with #4 (and #1) involves having nodes be configured > with both globals and site-locals i.e. it brings in most (but > not all) of the complexities of the full-fledged site-local support. It is not a red herring. Input sent to me for the requirements doc: Research ships at sea intermittently connect via INMARSAT, or when in port, the shipboard network is connected to shore via Ethernet. Of utmost importance is that the systems on board the ship all function, providing data collection and analysis without interruption. Static addressing is used on most intra-ship network components and servers. It's quite expensive to operate a research ship, so eliminating points of failure is important. Scientists on board collaborate with colleagues back home by sharing of data and email. Private address space is employed for several reasons: 1) it provides the ability to allocate significant address space to each ship without needing to worry about how many computers will be on a given cruise. 2) it provides separate address space for each ship. 3) it simplifies filtering to ensure shipboard traffic is not permitted to transmit out or bring up expensive satellite links. Granted the larger address space argument goes away, but this is an example of a network that attaches intermittently, and via different providers. Yet the requirement is that the internal communications not be interrupted, ever. Telling a network like this that they have to invalidate any current prefix and renumber everything into the current provider space is a non-starter. Giving them the option to add the current provider's prefix to those nodes needing external connectivity is the appropriate approach. > > > Note that the community seems to have an unrelated desire to > get "PI space" for free - and in some cases site-locals seem > to be confused with some form of PI space or stepping stone > to PI space. The confusion derives from the fact that some want PI space for connected networks, while others want PI space for disconnected ones. The requirements for those are somewhat different. Space for disconnected networks must be freely available, or people will pick random numbers because those don't require approval or payment. A registry costs money to run, so there is no reasonable way to get registered values for free, and the IETF can't pick up the tab. > There is some work (in and around multi6, > ipv6mh, and hip) that is looking at two space systems > (identifier and locator separation) that can hopefully > provide something of similar look and feel as PI addresses. This approach does not solve the problem that the connected PI community wants solved. They are looking for isolation from the costs of renumbering. What we are finding is that the multi-prefix per host model mitigates the host part of that cost, but the configuration of the infrastructure also has a high manual labor cost. The two space system makes it much more difficult for the infrastructure to figure out what is going on in order to apply the appropriate policies to the intended identifier. On top of that, the costs for manually reconfiguring the infrastructure don't go away. > Yes, this is no small task. But I sure hope we can spend > energy on that longer term and harder problem than continuing > to delude ourselves that site-local addresses have benefits > with justify their added complexity. The problem at the moment is that those who are looking at the application development complexity are refusing to acknowledge the operational complexity caused by the lack of alternatives. Yes there are promises that someday we might solve a few of the problems, but until every requirement is met it is irresponsible of the WG to remove an architectural component that people are using in the current IPv4 network. Tony > > So let's not ask what deprecating site-locals solve - let's > ask what problems site-locals solve. They were added to the > addressing architecture at a time when there was little if no > wide-spread understanding of the larger > implications. I hope we have learned some from the > discussions over the last few years (on ipng and zeroconf as > well to some extent) so that > we can try to do this cost/benefit analysis. > > Respectfully, > 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 Thu Apr 3 09:45:30 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 h33HjUPL027517; Thu, 3 Apr 2003 09:45:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33HjTQH027516; Thu, 3 Apr 2003 09:45: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.9+Sun/8.12.9) with ESMTP id h33HjPPL027503 for ; Thu, 3 Apr 2003 09:45:25 -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 h33HjXHP024141 for ; Thu, 3 Apr 2003 09:45:33 -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 KAA01654 for ; Thu, 3 Apr 2003 10:45: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, 3 Apr 2003 17:45:08 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, 3 Apr 2003 17:45: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, 3 Apr 2003 17:45:07 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, 3 Apr 2003 17:45:07 Z Content-class: urn:content-classes:message Subject: RE: exclusive model [RE: site-locals] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Apr 2003 09:45:06 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F726@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: exclusive model [RE: site-locals] Thread-Index: AcL6CCLNQw/rlHUxQriLs5exWlZi6QAAB/Bg From: "Michel Py" To: "Pekka Savola" Cc: "Margaret Wasserman" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33HjPPL027504 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Pekka Savola wrote: > Exclusive model creates certain very disturbing problems in > hosts (wrt. oscillation between global and site-local) which > might be fixable, and ones even more so in the routers > (requiring quite extensive site-local implementation) which > is unlikely to go away. Maybe, and your point is? Every model has issues. We are not talking about creating a model that does not have any, we are talking about picking the model that the fewer or most manageable issues. What this WG is experiencing is the multi6 syndrome: there is no satisfying solution and it's caught in a loop trying to find one. 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 Apr 3 10:02: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 h33I2pPL028112; Thu, 3 Apr 2003 10:02:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33I2pVI028111; Thu, 3 Apr 2003 10:02: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 h33I2lPL028104 for ; Thu, 3 Apr 2003 10:02:47 -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 h33I2ucU023550 for ; Thu, 3 Apr 2003 10:02: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 LAA16803 for ; Thu, 3 Apr 2003 11:02:50 -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, 3 Apr 2003 18:02:49 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, 3 Apr 2003 18:02: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; Thu, 3 Apr 2003 18:02: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; Thu, 3 Apr 2003 18:02:34 Z Content-class: urn:content-classes:message Subject: RE: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Apr 2003 10:02:33 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F727@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: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing Thread-Index: AcL55O4H4YBB9JkDRwuw5HsoGPNUxwAJS0xg From: "Michel Py" To: "Brian Carpenter" , "Dave Thaler" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33I2mPL028105 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave / Brian, > Dave Thaler wrote: > Can someone quickly give a proposal or two for (b) > before the consensus call deadline? It needs polishing, but FWIW: http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-ipv6-gusl-00.txt (not submitted to the WG) Also read: draft-hinden-ipv6-global-site-local-00.txt > Brian E Carpenter wrote: > - bits derived from GPS location at an arbitrary point inside the site > - bits derived from the date & time at the instant you want a prefix > - bits derived from an IEEE address of an arbitrary device inside the site > - pseudo-random bits of some kind > - bits supplied from a central allocator of some kind Note that these methods are not mutually exclusive; for what I remember of the discussions about the topic it appears that no single one would cover the needs so the end result is likely a combination of some of the ones you just enumerated. 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 Apr 3 10:04: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 h33I4hPL028150; Thu, 3 Apr 2003 10:04:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33I4h5D028149; Thu, 3 Apr 2003 10:04: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 h33I4ePL028142 for ; Thu, 3 Apr 2003 10:04: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 h33I4mcU024304 for ; Thu, 3 Apr 2003 10:04: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 LAA18570 for ; Thu, 3 Apr 2003 11:04:42 -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, 3 Apr 2003 18:04: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, 3 Apr 2003 18:04: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; Thu, 3 Apr 2003 18:04:41 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 18:04:41 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 03 Apr 2003 10:04:40 -0800 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , Cc: , Subject: RE: site-locals Date: Thu, 3 Apr 2003 10:04:37 -0800 Message-Id: <0a8401c2fa0b$7dd6ab40$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: <5.1.0.14.2.20030403081403.037bf2e8@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33I4ePL028143 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > ... > The work to keep, and finish, site-locals is much greater > than the work to deprecate them. Wishful thinking... > > To deprecate them, I think that the addressing architecture > and the default address selection rules would be the only > RFCs (both at PS) that we need to change. What about all the documents that need to be created to address the real requirements of network managers? Deliver on those, then it will be time to talk about a couple of wording changes in current documents. > > To keep them, we need to document and resolve the issues that > they cause, update all of the IPv6 routing protocols to > document how site-boundaries are maintained, and document how > address selection will be performed in several upper layer > protocols (at least SCTP, SIP and FTP). We might also need > to provide guidance to non-IETF applications protocol > developers and/or application developers for how to handle > site-local addresses in non-IETF applications. And, we'd > need to specify split DNS. Almost all of that will need to happen regardless of the prefix used, because the architectural reality of the Internet is that many of the attached networks also have a private use space. Claiming otherwise by simply removing a well-known tag is an irresponsible act. This whole deprecate effort is about making it someone else's problem. The IETF has successfully driven out most of the network managers, and now the remaining developers are trying to dictate how networks get run by removing the tools that people really use. The false sense of accomplishment here will only result in mass chaos as network managers continue to run the networks the way they want, but are forced to use ad-hoc approaches to do so. 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 Apr 3 10:17: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 h33IHDPL028611; Thu, 3 Apr 2003 10:17:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33IHDQc028610; Thu, 3 Apr 2003 10:17: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.9+Sun/8.12.9) with ESMTP id h33IH8PL028600 for ; Thu, 3 Apr 2003 10:17:08 -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 h33IHGHP006330 for ; Thu, 3 Apr 2003 10:17:17 -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 LAA29615 for ; Thu, 3 Apr 2003 11:17: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; Thu, 3 Apr 2003 18:17: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; Thu, 3 Apr 2003 18:17: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; Thu, 3 Apr 2003 18:17:10 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, 3 Apr 2003 18:17:09 Z Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 51F6015210 for ; Fri, 4 Apr 2003 03:17:30 +0900 (JST) Date: Fri, 04 Apr 2003 03:16:57 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) In-Reply-To: References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 50 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 02 Apr 2003 14:36:19 +0900, >>>>> JINMEI Tatuya said: > What was the consensus, if any, on alternatives to site-locals when SL > is deprecated? In particular, which prefixes will we use for > disconnected or intermittently connected "site"s? I've checked the > chair's presentation slides and the draft minutes, and (roughly) > followed the very recent discussion in the ML, but I cannot be sure > about it. Thanks, everyone. Since my goal was to clarify a background of this vote (for myself), I won't make a response to each follow-up. I believe I now understand the background. A rough summary is: If we say "YES -- Deprecate site-local unicast addressing", this means we agree on removing site-local assuming something fantastic that can solve issues when we really remove it. Hmm..., then it is natural that the group of 'YES' will be in a majority. And, in fact, the "something" seems to vary among people. It even contains, if I understand the discussion correctly, "nearly-unique site-local" that consists of fec0 + some_random_bits. I agree even "nearly-unique SL" is better than the current fec0::/10, and, in that sense, I can vote for YES (Note: I don't stick to this one. I'm picking it up as an example). However, can we really agree on using this particular solution? Some people is against SL due to its "false sense of security", which also applies to the "nearly-unique" one. So they will also be against this. So..., I'm afraid we'll just end up having a discussion loop again or even re-inventing yet another site-local addresses (which will then cause another loop), due to the very large notion of 'YES'. For this reason, I cannot agree on just "clearing the desktop first". I cannot believe this approach stops the circle. As I have repeatedly said, I'm not a site-local lover, so I'd rather vote for 'YES'. But, in this current form, I cannot do that. At this moment, I don't have a good idea to overcome this dilemma. I'll try to think more about it (of course, I'll be very happy if someone can enlighten me on this, without repeating points already stated in this thread). Thanks, 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 Apr 3 10:19:49 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 h33IJnPL028727; Thu, 3 Apr 2003 10:19:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33IJnEr028726; Thu, 3 Apr 2003 10:19: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.9+Sun/8.12.9) with ESMTP id h33IJiPL028713 for ; Thu, 3 Apr 2003 10:19: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 h33IJrcU029869 for ; Thu, 3 Apr 2003 10:19:53 -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 LAA01137 for ; Thu, 3 Apr 2003 11:19:47 -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, 3 Apr 2003 18:19: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; Thu, 3 Apr 2003 18:19:46 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, 3 Apr 2003 18:19:46 Z Received: from albert.tavian.com (albert.tavian.com [66.149.217.205]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 18:19:45 Z Received: from gamer (dltpppdsl198.sttl.uswest.net [63.226.214.198]) by albert.tavian.com (8.8.7/8.8.7) with SMTP id KAA05202; Thu, 3 Apr 2003 10:19:39 -0800 Message-Id: <000f01c2fa0d$97715120$6801010a@tavian.com> From: "Brian McGehee" To: "Jeroen Massar" Cc: References: <003801c2f911$7393c6e0$210d640a@unfix.org> Subject: Re: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Thu, 3 Apr 2003 10:19:37 -0800 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 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Jeroen Massar" To: "'Brian McGehee'" Cc: Sent: Wednesday, April 02, 2003 4:14 AM Subject: RE: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) > Brian McGehee [mailto:doc@albert.tavian.com] wrote: > > > *Notes below > > > > * I agree "NAT != SL"! Except in the case that hosts need "global" > > connectivity and they ONLY have a SL address will require > > NAT. Or they should have a second IPv6 globally unique unicast > address > > (which isn't that hard to have multiple addresses???) > > Use a firewall to block incoming packets. > > > * I can envision an enterprise environment that is comfortable using > > FEC0::/10 for internal communications but a host has a globally unique > > address also for external communications (on hosts that have this > > neccessity) This could be comfortable to a network admin/ops/noc. > > Then don't route a certain prefix. Which prefix? SL Prefix? Where is the alternative? > > > ----- Original Message ----- > > From: "Jeroen Massar" > > To: "'Brian McGehee'" ; > > > > Sent: Wednesday, April 02, 2003 2:53 AM > > Subject: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local > > Addressing) > > > > > > > Brian McGehee write: > > > > > > > NO -- Do not deprecate site-local unicast addressing > > > > > > > > - Site-locals should be retained for disconnected sites. If > > > > not SL, then > > > > a mechanism needs to be adopted that can provide a > > private means of > > > > selecting from a private address space that is "reserved" for this > > > > function. 2002 is not a working alternative. > > > > - Site-locals should be retained for intermittently > > connected sites. > > > > - Site-locals should be retained as a means for internal > > > > connections to > > > > survive global prefix renumbering. > > > > > > All of the above will make the address not unique. > > > Have fun merging your networks. > > > > * Anyone that has had to merge 2 very large networks will > > know the great amount of design, architecture, and planning > > that has to go into such a project. It's not as easy as > > changing "a DHCP range" or a "handful of RAs" even if they > > were Globally unique IPv6 (or globally unique IPv4 addresses). > > I agree that IPv6 stateless Auto-Config adds a lot of room to > > make this an easier process but it doesn't solve the unique > > problems that come up in merging two large enterprise networks. > > If they are globally unique, one doesn't HAVE to renumber. > And indeed the problems of renumbering lie in configuration items > not in the network numbering itself. > > > * Yes. There is the chance that SL will "overlap" in a > > situation of merging two IPv6 enterprise networks. > > But if we don't offer SL. What will people > > choose for private addressing? I would REALLY like to see an > > alternative to SL that maybe provides for a set of bits that > > relate to Geography? ISP? > > etc? I'm open to other suggestions. But without an > > alternative I have to vote "NO". Let's see some alternatives? > > Please, again!=> Let's not alienate those that are already > > afraid of change by "changing" things. > > A central registry where one can obtain unique disconnected > space per /48. > > > > > - Other (please specify). Continually changing the specs > > will only > > > > further alienate those that refuse to adopt. Not offering > > > > equivalents to what exists today (rfc 1918) will > > accomplish the same. > > > > (and do we really want to put all the NAT vendors out of > > business? > > > ;-) > > > > "Necessity drives ingenuity." > > > > > > Here you are already levelling NAT with SL. > > > If you already intend to NAT, stay with IPv4, you will have the same > > > problems and still won't get back the end to end connectivity which > > > was one of the major things IPv6 was built for. Or we could just > > > do IPv6 with 32bits again... > > > > * Yes if anyone chooses to do NAT. They should have that > > option, and an IPv6 address space to appropriately use for > > such functionality [it's a feature, not a bug](some people > > feel strongly that NAT is a security feature). > > If you intend to do it then just stay with IPv4 without > end-to-end connectivity and don't drag down the rest of us. > > > * Again we shouldn't "take away" from what is already there. > > From what people are comfortable with! I am not a proponent > > of NAT (bottlenecking, added administration, etc...) but we > > need to continue to support environments that exists today. > > If a company decides to incorporate NAT in their firewall(s) > > "Look mom he said NAT and firewall in one sentence" > > > (or even NAT-PT/NAPT-PT), well let's let them! We've > > introduced these ideas in IPv4, they exist today. > > They didn't pay with money a very long time ago. > Should we now all go exchange eggs, chicken and wild > beast again as a currency? > > That's called evolution. There is no need for NAT which > is apparently the sole reason you want SL. > > > The current "IPv6 RFC's" and "IPv6 literature" document this > > continued support clearly (FEC0::/10). > > And people have realized that it was a mistake and want to > clear that mistake up before it starts to hurt hard. > > > Constantly changing the standards scares "people" away from > > adoption. Do we really want to make such a drastic change. > > (I'm still trying to deal w/ the deprecation of A6 records. > > They worked GREAT in renumbering!) > > If you have a real use for A6, just like A6, then document > it and bring it forward, thats where these WG's are all about. > > > Yes. IPv6 offers 340 undecillion (or sextillion depending > > on where your from) addresses. Enough to address every > > device in the world. > > Indeed so where did we need SL for again? To NAT???? > > > Great. But we need to offer all the functionality that > > exists today. They exist for reason (besides just lack > > of address space. > > And which reasons where that again, I don't recall you > mentioning ANY reason here that doesn't relate to NAT. > Again, if you want NAT, then stick to IPv4. > > > Some people feel secure/comfortable behind NAT!) > > ...my $.02 > > You should not feel secure behind a NAT. NAT has nothing > to do with security. Not routing a prefix somehow has though. > > Apparently you have no other need for SL than to NAT. > I rest my case. > > 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 Apr 3 10:24: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 h33IO6PL029092; Thu, 3 Apr 2003 10:24:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33IO6EE029091; Thu, 3 Apr 2003 10: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.9+Sun/8.12.9) with ESMTP id h33IO2PL029075 for ; Thu, 3 Apr 2003 10:24: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 h33IOAHP009569 for ; Thu, 3 Apr 2003 10:24:10 -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 LAA03227 for ; Thu, 3 Apr 2003 11:23: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, 3 Apr 2003 18:23: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; Thu, 3 Apr 2003 18:23: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; Thu, 3 Apr 2003 18:23:50 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 18:23:49 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 03 Apr 2003 10:23:48 -0800 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , Subject: RE: My Thoughts on Site-Locals Date: Thu, 3 Apr 2003 10:23:43 -0800 Message-Id: <0a8901c2fa0e$285fac40$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: <5.1.0.14.2.20030403064541.03e2cae8@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33IO2PL029077 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > ... > Access control is also useful, and a simple form of access > control will be needed in IPv6. However, site-local > addresses are a poor form of access control for two reasons: > > - Site-local boundaries need to be at routing area > or AS boundaries (not convenient). This is bogus nonsense. > - Site-local areas cannot be nested. > > So, you can't have a site-local access control boundary for > your corporate site, AND a site-local access control boundary > that only allows the marketing department to use the fancy printer. Within the site, there is no difference between the filtering characteristics of SL & any other prefix. If your argument is that a site can't have multiple subnets with the same prefix, well that is self evident. > > Both Steve Bellovin and Brian Zill have proposed superior > access control mechanisms based on information being passed > in router advertisements, and I think they plan to combine > their proposals into a single, maximally beneficial, form. They are not superior access control mechanisms. They result in exactly the same architectural state where some addresses on a subnet are private while others are global. These mechanisms could just as easily announce an FEC0 prefix, and the resulting internal filtering would be identical. What they loose is the ability to know that the peer networks have implemented the same filter as a backup. > > The intermittently-connected site problem is often raised as > a reason for site-locals. This is an interesting problem, > and it would be very good to solve this problem, but > site-locals do not provide a complete solution. You make statements like this without any explaination or justification. Stable addresses that persist across multiple connect/disconnect events to different providers are in fact one problem that the current SL approach completely solves. > And, recent > models for site-local usages (including "moderate" and > "limited") don't provide a solution for this case at all, as > they would reverse the preference for site-local addresses > over global addresses in the address selection rules. That is why they were broken models to begin with. > > So, while I think that the IETF needs to figure out a way to > address this type of network, site-locals may not be the best > way to do it, as they come with substantial costs for all > nodes, and don't fully solve this problem. The IETF needs to address all the requirements BEFORE removing the tool that currently solves them. Doing otherwise is an irresponsible act. 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 Apr 3 10:34: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 h33IYcPL029615; Thu, 3 Apr 2003 10:34:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33IYbQB029614; Thu, 3 Apr 2003 10:34: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.9+Sun/8.12.9) with ESMTP id h33IYWPL029595 for ; Thu, 3 Apr 2003 10:34: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 h33IYfcU005422 for ; Thu, 3 Apr 2003 10:34: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 LAA12213 for ; Thu, 3 Apr 2003 11:34: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; Thu, 3 Apr 2003 18:34: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; Thu, 3 Apr 2003 18:34: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; Thu, 3 Apr 2003 18:34:34 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, 3 Apr 2003 18:34:34 Z Received: from xbe-ams-313.cisco.com (xbe-ams-313.cisco.com [144.254.228.203]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h33ITZeM014659; Thu, 3 Apr 2003 13:31:09 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DAD in node requirements draft Date: Thu, 3 Apr 2003 20:31:08 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD in node requirements draft Thread-Index: AcLzBRiYTzRs1VS0Q66vqigwofsLRQBac1uQ From: "Laurent Montini (lmontini)" To: "Ole Troan" , "Peter Barany" Cc: "Mika Liljeberg" , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33IYXPL029597 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In 3GPP, when setting an IPv6 PDP Type (whatever 2.5G or 3G), the GGSN first provides the link-local address to the MT. The GGSN will then send/forward an unique /64 prefix given for that PDP Context (static, stateful or stateless allocation). >From the link-local address the MT will strip the unique IID. The IID will be used for link-local address and then avoids DAD (and any overhead traffic over air interface). The GGSN is managing all the IID given to each IPv6 PDP Context that GGSN will setup. The IID may be used with the /64 global prefix if the UE is not able to create is own IID. Thus the global address is built with the /64 prefix and with either the IID given by the GGSN or any other IID the TE wants (e.g. TE MAC address). The TE can also use RFC3041 addresses. TS 23.060 and 29.061 are the 2 main documents to look at (for Rel99/3, Rel4 and Rel5). .lm -----Original Message----- From: Ole Troan [mailto:ot@cisco.com] Sent: 25 March 2003 20:29 To: Peter Barany 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 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Apr 3 10:39: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 h33IdBPL029879; Thu, 3 Apr 2003 10:39:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33IdBkH029878; Thu, 3 Apr 2003 10:39: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 h33Id8PL029871 for ; Thu, 3 Apr 2003 10:39:08 -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 h33IdFcU007701 for ; Thu, 3 Apr 2003 10:39:16 -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 LAA09717 for ; Thu, 3 Apr 2003 11:39: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; Thu, 3 Apr 2003 18:38:40 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, 3 Apr 2003 18:37: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, 3 Apr 2003 18:37:59 Z Received: from bbmail1-out.unisys.com (bbmail1-out.unisys.com [192.63.108.40]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 18:37:59 Z Received: from us-ea-gtwy-4.ea.unisys.com (us-ea-gtwy-4.ea.unisys.com [192.61.146.122]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id SAA25743 for ; Thu, 3 Apr 2003 18:33:21 GMT Received: by us-ea-gtwy-4.ea.unisys.com with Internet Mail Service (5.5.2656.59) id <213H13T7>; Thu, 3 Apr 2003 12:37:56 -0600 Message-Id: From: "Sellers, Julian P" To: ipng@sunroof.eng.sun.com Subject: My Questions on Site-Locals Date: Thu, 3 Apr 2003 12:31:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith's multi-party applications won't work if the parties refer non-global addresses to each other. Margaret recommends that everyone use global addresses, but filter certain prefixes at various administrative boundaries. How, then, do Keith's applications know which addresses have global scope and which do not? A tacit assumption seems to be that applications will not have to deal with link-local addresses. I'm aware of the recommendation not to place link-local addresses in the DNS, but I know of no prohibition of applications communicating via link-local addresses. If they may do so, is this less problematic than using site-local addresses? Since I know nothing about filtering in routers, can someone tell me why filtering on FEC0::/10 is more complex than filtering on prefixes chosen by the local administrator(s)? And concerning Margaret's point on nesting sites, could routers not filter within FEC0:0:subn:etid::/64 addresses? Again citing the disclaimer re my lack of knowledge, the filtering-on-locally-designated-prefixes method seems unwieldy compared to the filtering-on-well-known-scope method. Implementations can allow an administrator to configure address scope preferences using the well-known scopes. Nodes (applications) on the same subnet could then have addresses of different scopes. This would be cumbersome at best without well-known scopes. Some have complained about the complexity of always disambiguating site-local addresses by means of their zone identifiers. This seems insignificant to me; the same must be done for link-local addresses. The zone identifier accompanies the address wherever it goes. Right? I understand that sites that merge would have to renumber if their subnet IDs conflicted. Some have stated that a disconnected site using site-local addresses must renumber when it connects to the Internet. Wouldn't the site simply add the new prefix(es), and the nodes use the new addresses and/or site-local addresses based on local configuration? Connections using site-local addresses would not be affected by connection to the Internet. Since so many wise people object to site-local addressing, the problems must be greater than they appear from behind these cube walls. But I have not seen answers to these questions (or maybe I failed to comprehend). I look forward to having my horizons expanded. Julian Sellers Enterprise Server Communications Engineering Unisys Corporation -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 10:47: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 h33IlXPL000267; Thu, 3 Apr 2003 10:47:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33IlXCq000266; Thu, 3 Apr 2003 10:47: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.9+Sun/8.12.9) with ESMTP id h33IlUPL000259 for ; Thu, 3 Apr 2003 10:47:30 -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 h33IlccU011582 for ; Thu, 3 Apr 2003 10:47:38 -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 LAA13862 for ; Thu, 3 Apr 2003 11:47:26 -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, 3 Apr 2003 18:45:28 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, 3 Apr 2003 18:45: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; Thu, 3 Apr 2003 18:45:28 Z Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 18:45:28 Z Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 3 Apr 2003 10:45:27 -0800 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 03 Apr 2003 10:45:27 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 3 Apr 2003 10:45:25 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 3 Apr 2003 10:45:23 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 3 Apr 2003 10:45:26 -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: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Thu, 3 Apr 2003 10:45:25 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Thread-Index: AcL6DqSXEe5nh3jZTGq86x9Fe/uwfQAATH2g From: "Christian Huitema" To: "Brian McGehee" , "Jeroen Massar" Cc: X-OriginalArrivalTime: 03 Apr 2003 18:45:26.0158 (UTC) FILETIME=[30E642E0:01C2FA11] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33IlUPL000260 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If we are serious about NAT != SL, then we should enforce it. Clearly, we cannot send the protocol police and whack every market driven designer of a NAT, but we can perform "collective enforcement", i.e. design our specification in such a way that misusing site local in a NAT configuration is guaranteed to break every application, and thus that any attempt to deploy an IPv6 NAT using site local will be a deployment nightmare. Suppose for example that we change our spec to forbid any communication between addresses of different scopes. This can be enforced by senders (refuse to send a packet if dest scope != source scope), routers or firewalls (drop packet if srce and dest scope don't match), and receivers (drop incoming packet if srce and dest scope don't match). You don't need to enforce it in every host and every router to be effective: just enforce in in a significant fraction of the hosts makes sure that any attempt to use the forbidden pattern will be very unreliable. This simple suggestion will in fact prevent using SL in the NAT scenario, as at some point the scenario relies on communication between an SL addressed source (e.g. a client) and a globally addressed destination (e.g. a web site). I think that we should enforce this requirement whether we maintain site local or find a replacement for disconnected sites. -- 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 Apr 3 10:50: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 h33Io7PL000474; Thu, 3 Apr 2003 10:50:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33Io7qF000473; Thu, 3 Apr 2003 10:50: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 h33Io4PL000466 for ; Thu, 3 Apr 2003 10:50: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 h33IoCHP021679 for ; Thu, 3 Apr 2003 10:50: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 KAA09939 for ; Thu, 3 Apr 2003 10:50:07 -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, 3 Apr 2003 18: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; Thu, 3 Apr 2003 18: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; Thu, 3 Apr 2003 18:50:06 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; Thu, 3 Apr 2003 18:50:06 Z Received: from IDLEWYLDE.windriver.com ([128.224.4.104]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA06647; Thu, 3 Apr 2003 10:49:41 -0800 (PST) Message-Id: <5.1.0.14.2.20030403134226.03abebe8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 13:45:15 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing Cc: In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F721@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 >On a side note, I just re-read addrarch 3.11 and I found no text about >how a WG deprecates a prefix. As far as I'm concerned, it could mean >that all WG members are supposed to telnet to all IPv6 routers in the >world and deprecate the prefix there. We need better than this. The great thing about deprecation is that it doesn't have to happen all at once. We won't reallocate the prefix for some other purpose, just deprecate its use for site-local addressing. So, this won't cause any immediate impact to existing implementations or deployments. Over time, implementations will cease to provide special handling for FECO::/10 (many don't provide any special handling for this prefix today, BTW) and folks should migrate their deployments away from using site-locals to (one of) the alternatives that we eventually specify (i.e. the bellovin/zill proposal) or that RIRs enact as policy, etc. 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 Apr 3 11:10: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 h33JADPL001336; Thu, 3 Apr 2003 11:10:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33JACjH001335; Thu, 3 Apr 2003 11:10: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.9+Sun/8.12.9) with ESMTP id h33JA9PL001325 for ; Thu, 3 Apr 2003 11:10: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 h33JAHHP002886 for ; Thu, 3 Apr 2003 11:10:17 -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 LAA27221 for ; Thu, 3 Apr 2003 11:10:11 -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, 3 Apr 2003 19:10:09 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP; Thu, 3 Apr 2003 19:10:09 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Thu, 3 Apr 2003 19:10:08 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay12.sun.com with ESMTP; Thu, 3 Apr 2003 19:10:08 Z Received: from IDLEWYLDE.windriver.com ([128.224.4.104]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA20699; Thu, 3 Apr 2003 11:09:40 -0800 (PST) Message-Id: <5.1.0.14.2.20030403140612.03ac0e70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 14:07:58 -0500 To: From: Margaret Wasserman Subject: RE: site-locals Cc: "'Erik Nordmark'" , , , In-Reply-To: <0a8101c2fa08$867ee260$ee1a4104@eagleswings> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While I think it would be great to design a mechanism that would allow smooth operation of intermittently connected nodes whose global addressing potentially changes at each re-connect, I do not believe that we want to impose a costly and complex solution on _all_ IPv6 nodes so that a few of them can work properly in this unusual situation. Margaret At 09:43 AM 4/3/2003 -0800, Tony Hain wrote: >Erik Nordmark wrote: > > ... > > I think #4 (which I didn't talk about at the mike) is a red > > herring. Perhaps the issue is a restatement of #1 (due to the > > ISP implicitly forcing a > > renumbering each time the site connects) in which case the > > points about #1 applies. And note that making site-locals > > help with #4 (and #1) involves having nodes be configured > > with both globals and site-locals i.e. it brings in most (but > > not all) of the complexities of the full-fledged site-local support. > >It is not a red herring. Input sent to me for the requirements doc: > >Research ships at sea intermittently connect via INMARSAT, or when in >port, the shipboard network is connected to shore via Ethernet. Of >utmost importance is that the systems on board the ship all function, >providing data collection and analysis without interruption. Static >addressing is used on most intra-ship network components and servers. >It's quite expensive to operate a research ship, so eliminating points >of failure is important. Scientists on board collaborate with colleagues >back home by sharing of data and email. Private address space is >employed for several reasons: 1) it provides the ability to allocate >significant address space to each ship without needing to worry about >how many computers will be on a given cruise. 2) it provides separate >address space for each ship. 3) it simplifies filtering to ensure >shipboard traffic is not permitted to transmit out or bring up expensive >satellite links. > > >Granted the larger address space argument goes away, but this is an >example of a network that attaches intermittently, and via different >providers. Yet the requirement is that the internal communications not >be interrupted, ever. Telling a network like this that they have to >invalidate any current prefix and renumber everything into the current >provider space is a non-starter. Giving them the option to add the >current provider's prefix to those nodes needing external connectivity >is the appropriate approach. > > > > > > > > > Note that the community seems to have an unrelated desire to > > get "PI space" for free - and in some cases site-locals seem > > to be confused with some form of PI space or stepping stone > > to PI space. > >The confusion derives from the fact that some want PI space for >connected networks, while others want PI space for disconnected ones. >The requirements for those are somewhat different. Space for >disconnected networks must be freely available, or people will pick >random numbers because those don't require approval or payment. A >registry costs money to run, so there is no reasonable way to get >registered values for free, and the IETF can't pick up the tab. > > > > There is some work (in and around multi6, > > ipv6mh, and hip) that is looking at two space systems > > (identifier and locator separation) that can hopefully > > provide something of similar look and feel as PI addresses. > >This approach does not solve the problem that the connected PI community >wants solved. They are looking for isolation from the costs of >renumbering. What we are finding is that the multi-prefix per host model >mitigates the host part of that cost, but the configuration of the >infrastructure also has a high manual labor cost. The two space system >makes it much more difficult for the infrastructure to figure out what >is going on in order to apply the appropriate policies to the intended >identifier. On top of that, the costs for manually reconfiguring the >infrastructure don't go away. > > > > Yes, this is no small task. But I sure hope we can spend > > energy on that longer term and harder problem than continuing > > to delude ourselves that site-local addresses have benefits > > with justify their added complexity. > >The problem at the moment is that those who are looking at the >application development complexity are refusing to acknowledge the >operational complexity caused by the lack of alternatives. Yes there are >promises that someday we might solve a few of the problems, but until >every requirement is met it is irresponsible of the WG to remove an >architectural component that people are using in the current IPv4 >network. > >Tony > > > > > So let's not ask what deprecating site-locals solve - let's > > ask what problems site-locals solve. They were added to the > > addressing architecture at a time when there was little if no > > wide-spread understanding of the larger > > implications. I hope we have learned some from the > > discussions over the last few years (on ipng and zeroconf as > > well to some extent) so that > > we can try to do this cost/benefit analysis. > > > > Respectfully, > > 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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 11:10: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 h33JASPL001346; Thu, 3 Apr 2003 11:10:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33JASrM001345; Thu, 3 Apr 2003 11:10: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.9+Sun/8.12.9) with ESMTP id h33JANPL001338 for ; Thu, 3 Apr 2003 11:10: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 h33JAVHP002931 for ; Thu, 3 Apr 2003 11:10:31 -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 MAA25533 for ; Thu, 3 Apr 2003 12:10:09 -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, 3 Apr 2003 19:10: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, 3 Apr 2003 19:10: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, 3 Apr 2003 19:10:05 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, 3 Apr 2003 19:10:04 Z Received: from IDLEWYLDE.windriver.com ([128.224.4.104]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA20679; Thu, 3 Apr 2003 11:09:39 -0800 (PST) Message-Id: <5.1.0.14.2.20030403134626.03937a58@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 14:02:58 -0500 To: Richard Carlson From: Margaret Wasserman Subject: Re: My Thoughts on Site-Locals Cc: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.1.5.2.20030403093607.009ead90@atalanta.ctd.anl.gov> References: <5.1.0.14.2.20030403064541.03e2cae8@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 Richard, >I have a real hard time understanding why proponents of the depreciate >SL's claim that SL's would require special handling by applications , >while unique PI's don't. If an address has limited scope, i.e., there is >an address filter somewhere in the network that prohibits global e2e >connectivity, then sometimes applications will fail to establish >connections using those addresses. The primary differences between IPv6 unicast site-local addresses (FECO::/10), as defined today, and PI addresses are: 1. Site-local addresses are intentionally ambiguous. 2. Sites may not overlap or be nested. 3. Sites need to be convex, constraining their boundaries to routing area or AS boundaries. Most of the implementation complexity comes from #1 and, IMO, we would be much better off with an unambiguous form of local addressing. There are a few proposals for MAC-address based versions or unique IPv4-address based versions. We could also ask registries to provide globally unique provider-independent addresses for this purpose. Perhaps there are other choices. I am not actually a proponent of the "random choice" model, BTW. #2 and #3 are constraints caused by forcing local addressing in to the model current defined for IPv6 scoped addressing. The scoping rules probably make sense for multicast addresses (that's what they were originally invented for), but I think that they place unnecessary constraints on local addresses. Realistically, people will want to have overlapping and nested definitions of "local" access -- perhaps a marketing department with a special marketing printer, inside a company that has an internal corporate Internet site. You can't make this work with site-locals (no nesting), so you would already need a different mechanism for additional levels of access control... (filters and firewalls, I'd most likely). So, what do you gain from having one level of "local" defined by site-local addresses? >So I don't accept your point below that SL's require special handling by >apps, but unique random addresses that provide the same function don't. > >What am I missing that leads you to a different conclusion? I think what you are missing is the impact of ambiguity. Site-local addresses require special handling because the same address may not point to the correct node (and may in fact point to the wrong node) when used outside of the originating contexts. Firewall/filter constrained globally unique addresses don't have this problem. You may not be able to reach them, but you will at least know that you were trying to reach the right node. 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 Apr 3 11:18:06 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 h33JI5PL001715; Thu, 3 Apr 2003 11:18:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33JI5fw001707; Thu, 3 Apr 2003 11:18: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.9+Sun/8.12.9) with ESMTP id h33JI0PL001693 for ; Thu, 3 Apr 2003 11:18: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 h33JI8cU025740 for ; Thu, 3 Apr 2003 11:18: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 MAA29661 for ; Thu, 3 Apr 2003 12:18:02 -0700 (MST) From: Fred.Templin@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; Thu, 3 Apr 2003 19:17:13 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, 3 Apr 2003 19:13: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; Thu, 3 Apr 2003 19:17:12 Z Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 19:17:12 Z Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33JHBH16682 for ; Thu, 3 Apr 2003 13:17:11 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 3 Apr 2003 13:17:09 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 13:15:58 -0600 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: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Thu, 3 Apr 2003 11:15:57 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing Thread-Index: AcL55O4H4YBB9JkDRwuw5HsoGPNUxwAJS0xgAAHoMAA= To: Cc: X-OriginalArrivalTime: 03 Apr 2003 19:15:58.0627 (UTC) FILETIME=[7522D730:01C2FA15] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33JI1PL001694 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I was another who gave comments at the mike, but abstained from the voting at IETF56. The concern I stated at the mike was the need for supporting intermittently-connected sites, but this case is complicated when multiple sites overlap/merge, e.g., when multiple ad-hoc networks bump into one another. This is an area that seems to have potential solutions in the GUSL, GUPI, etc. proposals. But, the current proposals all seem to have limitations. On the one hand, I don't see the sense in taking an option off the table until a clear solution to the above mentioned problem space (among others) becomes apparent. On the other hand, I'm not seeing strong evidence that any such clear solution will needs-be depend on the existence of site-locals. So, my reasons for abstaining from the ballot still apply until I've seen more compelling evidence than is currently evident from the discussions. Fred Templin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 11:22: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 h33JMQPL001985; Thu, 3 Apr 2003 11:22:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33JMQ1T001984; Thu, 3 Apr 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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h33JMNPL001974 for ; Thu, 3 Apr 2003 11:22: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 h33JMVcU027466 for ; Thu, 3 Apr 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 pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25336 for ; Thu, 3 Apr 2003 12:22:25 -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, 3 Apr 2003 19:22:24 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, 3 Apr 2003 19:22: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; Thu, 3 Apr 2003 19:22:22 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; Thu, 3 Apr 2003 19:22:21 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 h33JLaOc010115; Thu, 3 Apr 2003 22:21:36 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h33JLZnO010111; Thu, 3 Apr 2003 22:21:35 +0300 Date: Thu, 3 Apr 2003 22:21:35 +0300 Message-Id: <200304031921.h33JLZnO010111@burp.tkv.asdf.org> From: Markku Savela To: mrw@windriver.com CC: ipng@sunroof.eng.sun.com In-reply-to: <5.1.0.14.2.20030403134226.03abebe8@mail.windriver.com> (message from Margaret Wasserman on Thu, 03 Apr 2003 13:45:15 -0500) Subject: Re: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing References: <5.1.0.14.2.20030403134226.03abebe8@mail.windriver.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Margaret Wasserman > Over time, implementations will cease to provide special handling > for FECO::/10 (many don't provide any special handling for this > prefix today, BTW) Well, I don't provide any special handling for FEC0::/10 (other than noting address is site level). I already have to implement scoped handling due to link locals. Site-local processing just comes free after that. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 11:31: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 h33JVRPL002507; Thu, 3 Apr 2003 11:31:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33JVRUF002506; Thu, 3 Apr 2003 11:31: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 h33JVOPL002499 for ; Thu, 3 Apr 2003 11:31: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 h33JVWcU001237 for ; Thu, 3 Apr 2003 11:31: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 LAA06813 for ; Thu, 3 Apr 2003 11:31: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; Thu, 3 Apr 2003 19:31:24 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, 3 Apr 2003 19:31:24 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, 3 Apr 2003 19:31:23 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 19:31:23 Z Received: from cisco.com (sjc-vpn3-768.cisco.com [10.21.67.0]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA28162; Thu, 3 Apr 2003 11:31:22 -0800 (PST) Message-Id: <3E8C8C09.9070007@cisco.com> Date: Thu, 03 Apr 2003 11:31:21 -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.ne CC: ipng@sunroof.eng.sun.com Subject: Re: My Thoughts on Site-Locals References: <0a8901c2fa0e$285fac40$ee1a4104@eagleswings> In-Reply-To: <0a8901c2fa0e$285fac40$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: > >>... >>Access control is also useful, and a simple form of access >>control will be needed in IPv6. However, site-local >>addresses are a poor form of access control for two reasons: >> >> - Site-local boundaries need to be at routing area >> or AS boundaries (not convenient). > > > This is bogus nonsense. Your answer does not really deserve a response. You're guilty of the very thing you accuse Margaret of. I'm curious as to how you would draw the boundaries. 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 Thu Apr 3 11:47: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 h33JlNPL002860; Thu, 3 Apr 2003 11:47:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33JlNcD002859; Thu, 3 Apr 2003 11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h33JlKPL002852 for ; Thu, 3 Apr 2003 11:47: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 h33JlScU007711 for ; Thu, 3 Apr 2003 11:47: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 MAA15581 for ; Thu, 3 Apr 2003 12:47:22 -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, 3 Apr 2003 19:47: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; Thu, 3 Apr 2003 19:47: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; Thu, 3 Apr 2003 19:47:18 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; Thu, 3 Apr 2003 19:47:17 Z Received: from IDLEWYLDE.windriver.com ([128.224.4.104]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA20234; Thu, 3 Apr 2003 11:46:51 -0800 (PST) Message-Id: <5.1.0.14.2.20030403140936.03adade8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 14:45:22 -0500 To: From: Margaret Wasserman Subject: RE: My Thoughts on Site-Locals Cc: In-Reply-To: <0a8901c2fa0e$285fac40$ee1a4104@eagleswings> References: <5.1.0.14.2.20030403064541.03e2cae8@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 Tony, At 10:23 AM 4/3/2003 -0800, Tony Hain wrote: >Margaret Wasserman wrote: > > ... > > Access control is also useful, and a simple form of access > > control will be needed in IPv6. However, site-local > > addresses are a poor form of access control for two reasons: > > > > - Site-local boundaries need to be at routing area > > or AS boundaries (not convenient). > >This is bogus nonsense. Please stop using this rude and dismissive language. This is a professional setting, and it would behoove you to act professionally. The need for site-local boundaries to be at routing area or AS boundaries has been discussed in the routing area and on the IPv6 list. It is required in order to maintain the "convexity" of sites which is needed to avoid situations where interally addressed packets will be discarded when there is an internal path available to the destination. In order to make this work, the all-internal path to the destination always has to be the shortest path. Bill Fenner, Alex Zinin, Steve Deering, Bob Hinden and I (along with a variety of other folks) spent a long time discussing this in various fora of the past two years, and we have not come up with any way to ensure that the internal path will be the shortest path (== site is "convex") without requiring that site boundaries be on routing area or AS boundaries. Perhaps you have found a better way? If so, please share it with us. Otherwise, I will persist in believing what we established through careful analysis and extensive discussion. > > - Site-local areas cannot be nested. > > > > So, you can't have a site-local access control boundary for > > your corporate site, AND a site-local access control boundary > > that only allows the marketing department to use the fancy printer. > >Within the site, there is no difference between the filtering >characteristics of SL & any other prefix. If your argument is that a >site can't have multiple subnets with the same prefix, well that is self >evident. My point is that there is a need for nested levels of "local" access. So, site-locals (which cannot be nested) will not work as the only method of "local" filtering or access control in a network. And, once you need to use another method, what advantage is there to also using site-locals? Just because you have a site-local address for a node, and you and that node are in the same site, does NOT mean that you will be able to reach it. Just because you have a global address for a node, does NOT mean that you will be able to reach it. Since applications will have to deal with both of these situations, what advantage is gained by using a special site-local prefix for "local" nodes? > > Both Steve Bellovin and Brian Zill have proposed superior > > access control mechanisms based on information being passed > > in router advertisements, and I think they plan to combine > > their proposals into a single, maximally beneficial, form. > >They are not superior access control mechanisms. They result in exactly >the same architectural state where some addresses on a subnet are >private while others are global. These mechanisms could just as easily >announce an FEC0 prefix, and the resulting internal filtering would be >identical. What they loose is the ability to know that the peer networks >have implemented the same filter as a backup. The Bellovin proposal is superior because it allows for nested local access control. "Private" and "Global" shouldn't be a binary choice. A local access control mechanism needs to deal with multiple levels of "private". > > The intermittently-connected site problem is often raised as > > a reason for site-locals. This is an interesting problem, > > and it would be very good to solve this problem, but > > site-locals do not provide a complete solution. > >You make statements like this without any explaination or justification. >Stable addresses that persist across multiple connect/disconnect events >to different providers are in fact one problem that the current SL >approach completely solves. Local connections will only survive disconnect/reconnect if they actually _use_ site-local addresses. This requires more than site-local addressing. It require split DNS (or a similar feature for whatever mechanism the application uses to get the address). There is also a conflict between how you would want things to work, by default, to be friendly to intermittently connected sites and how you would want things to work, by default, to be friendly with mobile nodes. Which do you think will be more prevalent? > > So, while I think that the IETF needs to figure out a way to > > address this type of network, site-locals may not be the best > > way to do it, as they come with substantial costs for all > > nodes, and don't fully solve this problem. > >The IETF needs to address all the requirements BEFORE removing the tool >that currently solves them. Doing otherwise is an irresponsible act. Unfortunately, site-locals are not finished. And, there does not seem to be WG consensus about how to finish them. So, by fighting for them, you are essentially fighting to leave the IPv6 WG in the "stuck" position that we've been occupying for the past couple of years. 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 Apr 3 12:01: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 h33K17PL003139; Thu, 3 Apr 2003 12:01:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33K17IE003138; Thu, 3 Apr 2003 12:01: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.9+Sun/8.12.9) with ESMTP id h33K14PL003131 for ; Thu, 3 Apr 2003 12:01: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 h33K1CcU012974 for ; Thu, 3 Apr 2003 12:01: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-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00004 for ; Thu, 3 Apr 2003 12:01:07 -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, 3 Apr 2003 20:01:06 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, 3 Apr 2003 20:01: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; Thu, 3 Apr 2003 20:01:06 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; Thu, 3 Apr 2003 20:01:05 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 h33K13Oc010245 for ; Thu, 3 Apr 2003 23:01:03 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h33K12sU010241; Thu, 3 Apr 2003 23:01:02 +0300 Date: Thu, 3 Apr 2003 23:01:02 +0300 Message-Id: <200304032001.h33K12sU010241@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com In-reply-to: <5.1.0.14.2.20030403140936.03adade8@mail.windriver.com> (message from Margaret Wasserman on Thu, 03 Apr 2003 14:45:22 -0500) Subject: Re: My Thoughts on Site-Locals References: <5.1.0.14.2.20030403064541.03e2cae8@mail.windriver.com> <5.1.0.14.2.20030403140936.03adade8@mail.windriver.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My point is that there is a need for nested levels of "local" > access. So, site-locals (which cannot be nested) will not work as > the only method of "local" filtering or access control in a network. There are several unused scope levels between site local and link local. I guess this means we need to define some additional prefixes similer to FEC0:: for those? Then, we could have nested "sites", "subsites" and "subsubsites" :-) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 12:07: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 h33K7YPL003360; Thu, 3 Apr 2003 12:07:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33K7YI8003359; Thu, 3 Apr 2003 12:07: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 h33K7UPL003352 for ; Thu, 3 Apr 2003 12:07:30 -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 h33K7ccU015569 for ; Thu, 3 Apr 2003 12:07:39 -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 NAA10885 for ; Thu, 3 Apr 2003 13:07:33 -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, 3 Apr 2003 20:07: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; Thu, 3 Apr 2003 20:07: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; Thu, 3 Apr 2003 20:07:06 Z Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 20:07:06 Z Received: from nomad.ctd.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA17483; Thu, 3 Apr 2003 14:06:13 -0600 (CST) Message-Id: <5.1.1.5.2.20030403140119.00a3dd90@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 03 Apr 2003 14:04:20 -0600 To: "Christian Huitema" , "Brian McGehee" , "Jeroen Massar" From: Richard Carlson Subject: RE: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Cc: 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 I agree with Christian on this point. Communications should only be allowed between nodes when the src & dst address scope match. Doing otherwise makes it hard/impossible for bi-directional flows to operate without a lot of special knowledge. Rich At 10:45 AM 4/3/03 -0800, Christian Huitema wrote: >If we are serious about NAT != SL, then we should enforce it. Clearly, >we cannot send the protocol police and whack every market driven >designer of a NAT, but we can perform "collective enforcement", i.e. >design our specification in such a way that misusing site local in a NAT >configuration is guaranteed to break every application, and thus that >any attempt to deploy an IPv6 NAT using site local will be a deployment >nightmare. > >Suppose for example that we change our spec to forbid any communication >between addresses of different scopes. This can be enforced by senders >(refuse to send a packet if dest scope != source scope), routers or >firewalls (drop packet if srce and dest scope don't match), and >receivers (drop incoming packet if srce and dest scope don't match). You >don't need to enforce it in every host and every router to be effective: >just enforce in in a significant fraction of the hosts makes sure that >any attempt to use the forbidden pattern will be very unreliable. > >This simple suggestion will in fact prevent using SL in the NAT >scenario, as at some point the scenario relies on communication between >an SL addressed source (e.g. a client) and a globally addressed >destination (e.g. a web site). > >I think that we should enforce this requirement whether we maintain site >local or find a replacement for disconnected sites. > >-- 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 >-------------------------------------------------------------------- ------------------------------------ Richard A. Carlson e-mail: RACarlson@anl.gov Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 12:11:22 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 h33KBMPL003525; Thu, 3 Apr 2003 12:11:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33KBMb7003524; Thu, 3 Apr 2003 12:11: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.9+Sun/8.12.9) with ESMTP id h33KBIPL003517 for ; Thu, 3 Apr 2003 12:11: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 h33KBRcU017208 for ; Thu, 3 Apr 2003 12:11: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 MAA08237 for ; Thu, 3 Apr 2003 12:11:21 -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, 3 Apr 2003 20:11: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, 3 Apr 2003 20:08: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, 3 Apr 2003 20:11:18 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, 3 Apr 2003 20:11:17 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 VAA19507 for ; Thu, 3 Apr 2003 21:11:15 +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 VAA07139 for ; Thu, 3 Apr 2003 21:11:15 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h33KBFf22658 for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 21:11:15 +0100 Date: Thu, 3 Apr 2003 21:11:15 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030403201115.GF22090@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <076901c2f7ac$f7017a60$ee1a4104@eagleswings> <3E8984C6.D05E9B6B@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E8984C6.D05E9B6B@hursley.ibm.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Apr 01, 2003 at 02:23:34PM +0200, Brian E Carpenter wrote: > > I prefer to think about this the other way round: kill the ambiguous > space, which we have learnt the hard way is a mistake, and then design > the alternative, which may well be unrouteable GUPI (and for all I care, > starts with FEC::/10). Agreed both are needed, but we should have the alternative 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 Thu Apr 3 12:28:40 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 h33KSePL004147; Thu, 3 Apr 2003 12:28:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33KSd3M004146; Thu, 3 Apr 2003 12:28: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.9+Sun/8.12.9) with ESMTP id h33KSaPL004136 for ; Thu, 3 Apr 2003 12:28:36 -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 h33KSicU024233 for ; Thu, 3 Apr 2003 12:28:44 -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 MAA29633 for ; Thu, 3 Apr 2003 12:28:38 -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, 3 Apr 2003 20:28:37 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, 3 Apr 2003 20:28: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; Thu, 3 Apr 2003 20:28:37 Z Received: from fridge.docomolabs-usa.com ([216.98.102.225] [216.98.102.225]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 20:28:36 Z Date: Thu, 03 Apr 2003 12:28:29 -0800 Subject: Re: Location Privacy (was Re: Outlawing (Avoiding) NAT with IPv6) From: Alper Yegin To: Alexandru Petrescu CC: Brian E Carpenter , , , Message-Id: In-Reply-To: <3E8C08C3.9050201@nal.motlabs.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 > Alper Yegin wrote: >> I don't quite understand this... All CN knows is the RCoA of the >> MN. Only LCoA can reveal the location of the MN within the network. >> And CN cannot figure out LCoA by looking at RCoA. > > What's the difference between a RCoA and a LCoA of a same MN? In my > understanding only the /64 prefix differs. The RCoA prefix is valid > on the MAP subnet and the LCoA prefix is valid in the AR subnet. I don't think HMIP protocol requires that RCoA and LCoA have the same suffix. RCoA can be configured with a random interface id to break the correlation between the host and RCoA. > > A CN is presented with the RCoA. A CN can have "out-of-band" > knowledge about the prefixes valid under various ARs. Based on this > input, a CN can build the LCoA corresponding to the RCoA. Since CN does not know the location of the MN, it does not know the prefix of LCoA, hence it cannot figure out LCoA by looking at the RCoA. > > That's what I was trying to say, but maybe I fail somewhere. > >> This is so much like what NAT does as far as hiding LCoA is >> concerned. > > To me, there are some common points, but there are also huge > differences. I'm thinking about in NAT there is a specific set of > types of addresses (the not publicly-routable) that can be reused by > any site at will. However, with HMIPv6, the LCoAs must be globally > unique. That's right. This gives the option to use LCoA with a CN if MN wants to. So, location privacy is an optional feature for MN to use, unlike with the NATs. This is nice, because the MN might want to signal its location to some CNs for things like location-based services. alper > > Alex > GBU > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 3 12:48: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 h33KmePL004403; Thu, 3 Apr 2003 12:48:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33KmeIJ004402; Thu, 3 Apr 2003 12:48: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.9+Sun/8.12.9) with ESMTP id h33KmbPL004395 for ; Thu, 3 Apr 2003 12:48:37 -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 h33KmjHP013333 for ; Thu, 3 Apr 2003 12:48:45 -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 MAA05756 for ; Thu, 3 Apr 2003 12:48:39 -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, 3 Apr 2003 20:47: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; Thu, 3 Apr 2003 20:47: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; Thu, 3 Apr 2003 20:47:55 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 20:47:55 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA05529 for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 15:47:53 -0500 (EST) Date: Thu, 3 Apr 2003 15:47:53 -0500 (EST) From: Dan Lanciani Message-Id: <200304032047.PAA05529@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: DeprecatingSite-Local Addressing) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: |Dan Lanciani wrote: |> |> Brian E Carpenter wrote: |> |> |I think we should clear the desktop first, by getting rid of ambiguous |> |site-local address space, and then discuss possible new solutions. |> |> Could you explain why you think this is the correct order? | |Because I can't see any other way of getting the WG out of |its perpetual discussion loop on this topic. Let me suggest a very simple way to do just that. Stop trying to eliminate site-locals and scoped addressing. Instead, apply your efforts to defining and standardizing the new/better mechanism(s) that will provide the same functionality. Once those new mechanisms have reached a level in the standards process sufficient to make folks comfortable that they are not just temporary diversions you will probably find it much easier to eliminate site-locals. |If we can agree to deprecate ambiguous SLs, we can then |invent a non-ambiguous replacement for the next version of the |addressing architecture. Agreeing to deprecate site-locals is neither necessary nor sufficient to allow us to invent a replacement. By implying this condition you are perpetuating the discussion loop that you seek to break. Dan Lanciani ddl@danlan.*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 Apr 3 12:59:53 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 h33KxrPL004650; Thu, 3 Apr 2003 12:59:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33Kxr1G004649; Thu, 3 Apr 2003 12: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.9+Sun/8.12.9) with ESMTP id h33KxnPL004642 for ; Thu, 3 Apr 2003 12:59:49 -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 h33KxvcU010933 for ; Thu, 3 Apr 2003 12:59:57 -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.3p2+Sun/8.9.3) with ESMTP id NAA27567 for ; Thu, 3 Apr 2003 13:59:52 -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, 3 Apr 2003 20:59: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; Thu, 3 Apr 2003 20:59: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; Thu, 3 Apr 2003 20:59:51 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 20:59:50 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 03 Apr 2003 12:59:48 -0800 Reply-To: From: "Tony Hain" To: "'Eliot Lear'" , Cc: Subject: RE: My Thoughts on Site-Locals Date: Thu, 3 Apr 2003 12:59:30 -0800 Message-Id: <0a9601c2fa23$ec3375b0$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: <3E8C8C09.9070007@cisco.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33KxoPL004643 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eliot Lear wrote: > >>... > >>Access control is also useful, and a simple form of access > >>control will be needed in IPv6. However, site-local > >>addresses are a poor form of access control for two reasons: > >> > >> - Site-local boundaries need to be at routing area > >> or AS boundaries (not convenient). > > > > > > This is bogus nonsense. > > Your answer does not really deserve a response. You're guilty of the > very thing you accuse Margaret of. I'm curious as to how you > would draw > the boundaries. Is it really necessary to point out that aligning a site-local boundary with an existing routing boundary (AS or Area) that the network manager has established is *extremely* convenient? Those boundaries exists for operational reasons of filtering routing information. SL is about a well-known prefix for routing filters, ergo aligning SL with an area or AS border is the natural thing to do. Claiming otherwise only serves to distribute FUD. 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 Apr 3 13:01:53 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 h33L1rPL004701; Thu, 3 Apr 2003 13:01:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33L1rd5004700; Thu, 3 Apr 2003 13:01: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.9+Sun/8.12.9) with ESMTP id h33L1oPL004693 for ; Thu, 3 Apr 2003 13:01:50 -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 h33L1wcU011783 for ; Thu, 3 Apr 2003 13:01:58 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA29185 for ; Thu, 3 Apr 2003 14:01: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; Thu, 3 Apr 2003 21:01: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; Thu, 3 Apr 2003 21:01: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, 3 Apr 2003 21:01:46 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 21:01:46 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id QAA05602 for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 16:01:44 -0500 (EST) Date: Thu, 3 Apr 2003 16:01:44 -0500 (EST) From: Dan Lanciani Message-Id: <200304032101.QAA05602@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: Charge for traffic, not IP addresses (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Jeroen Massar" wrote: |Dan Lanciani wrote: | |> "Jeroen Massar" wrote: |> |> |William_G_Allmond@notes.tcs.treas.gov wrote: |> | |> |> NO - Do NOT Deprecate Site-Local Addressing. |> |> |> |> There are reason to use site-locals, and reason NOT to use |> them. But |> |> "FORBIDDING" people will only alienate them and lead them to |> |> find ways to do it anyway. |> |> |> |> Perfect example, when (or should I say IF) my home ISP goes |> |> to IPv6, they charge per IP. Always have, and always will. |> |> Sure, they will gladly give me a range of IPs, as well as |> |> gladly charge me as if each were a PC. Also, |> |> when I get tired of putting up with the abuse from this |> |> particular ISP and decide to choose another ISP to abuse me, |> |> I will still have the same issue. |> | |> |Very good example that you don't get it at all. |> |ISP's should be charging for traffic, not for IP's. |> |> So why don't you make the ISPs work the way you think they should? |> Then NAT would go away and you wouldn't have to try to ban it. NAT |> is the effect, not the cause. | |That's the IPv4 world. The ISP's will have to get inside |their heads that IP space is not 'scarce' anymore. I'm sorry, but you simply do not understand the business model used by the vast majority of ISPs in (at least) the US. ISPs do not charge for IP addresses because of their (largely artificial) scarcity. ISPs use the number of addresses as a surrogate measure of bandwidth. ISPs use the stability of addresses to control what they perceive as higher-use (= higher cost) activity such as running a server. Many ISPs also charge for addresses simply because they can. |Fortunatly most RIR's will tell them that when they |request an allocation and I even suspect that when an ISP |get 'caught' for not passing out the correct bits down |to their clients that they can be requested to return |their allocation as they are not using it anyways. Now I really have to wonder if you are joking... |The IPv4 mentality should go. IPv6 != IPv4 fortunatly ;) Charging for addresses has nothing to do with an IPv4 mentality. It has to do with a business model. There is absolutely nothing in IPv6 that would cause this business model to change. Dan Lanciani ddl@danlan.*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 Apr 3 13:26:15 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 h33LQFPL005223; Thu, 3 Apr 2003 13:26:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33LQF1a005222; Thu, 3 Apr 2003 13:26: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.9+Sun/8.12.9) with ESMTP id h33LQBPL005215 for ; Thu, 3 Apr 2003 13:26:11 -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 h33LQJcU020163 for ; Thu, 3 Apr 2003 13:26: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 OAA28150 for ; Thu, 3 Apr 2003 14:26:14 -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, 3 Apr 2003 21:26: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; Thu, 3 Apr 2003 21:26: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; Thu, 3 Apr 2003 21:26:13 Z Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 21:26:13 Z Received: from nomad.ctd.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id PAA22871; Thu, 3 Apr 2003 15:26:08 -0600 (CST) Message-Id: <5.1.1.5.2.20030403141122.00a0e260@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 03 Apr 2003 15:24:16 -0600 To: Margaret Wasserman From: Richard Carlson Subject: Re: My Thoughts on Site-Locals Cc: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030403134626.03937a58@mail.windriver.com> References: <5.1.1.5.2.20030403093607.009ead90@atalanta.ctd.anl.gov> <5.1.0.14.2.20030403064541.03e2cae8@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 Margaret; Let me try an rephrase my question. I would like to know if there is consensus on the architectural view that IPv6 should have addresses with different scopes? This architectural view means that some addresses will not be usable for e2e communications in the global Internet. They will only be usable in specific area, zones, sites (whatever label you want to hang on the limited portion of the Internet where they work). I'm continuing to view this discussion, and the call for consensus, in the architectural sense, not the specific implementation laid down by your 3 points. Is that your intent, or am I misinterpreting your consensus call? Again, I fail to see how deprecating site-local addresses (specifically the FEC0::/10 prefix) solves the underlying problem (e2e communications failing with some src/dst address pairs). Rich At 02:02 PM 4/3/03 -0500, Margaret Wasserman wrote: >Hi Richard, > >>I have a real hard time understanding why proponents of the depreciate >>SL's claim that SL's would require special handling by applications , >>while unique PI's don't. If an address has limited scope, i.e., there is >>an address filter somewhere in the network that prohibits global e2e >>connectivity, then sometimes applications will fail to establish >>connections using those addresses. > >The primary differences between IPv6 unicast site-local addresses (FECO::/10), >as defined today, and PI addresses are: > > 1. Site-local addresses are intentionally ambiguous. > 2. Sites may not overlap or be nested. > 3. Sites need to be convex, constraining their boundaries > to routing area or AS boundaries. > >Most of the implementation complexity comes from #1 and, IMO, we would be >much better off with an unambiguous form of local addressing. There are >a few proposals for MAC-address based versions or unique IPv4-address >based versions. We could also ask registries to provide globally unique >provider-independent addresses for this purpose. Perhaps there are other >choices. I am not actually a proponent of the "random choice" model, BTW. > >#2 and #3 are constraints caused by forcing local addressing in to the >model current defined for IPv6 scoped addressing. The scoping rules >probably make sense for multicast addresses (that's what they were >originally invented for), but I think that they place unnecessary >constraints on local addresses. > >Realistically, people will want to have overlapping and nested >definitions of "local" access -- perhaps a marketing department with >a special marketing printer, inside a company that has an internal >corporate Internet site. You can't make this work with site-locals >(no nesting), so you would already need a different mechanism for >additional levels of access control... (filters and firewalls, I'd >most likely). So, what do you gain from having one level of >"local" defined by site-local addresses? > >>So I don't accept your point below that SL's require special handling by >>apps, but unique random addresses that provide the same function don't. >> >>What am I missing that leads you to a different conclusion? > >I think what you are missing is the impact of ambiguity. Site-local >addresses require special handling because the same address may not >point to the correct node (and may in fact point to the wrong node) >when used outside of the originating contexts. Firewall/filter >constrained globally unique addresses don't have this problem. You >may not be able to reach them, but you will at least know that you >were trying to reach the right node. > >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 >-------------------------------------------------------------------- > ------------------------------------ Richard A. Carlson e-mail: RACarlson@anl.gov Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 13:27: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 h33LRoPL005280; Thu, 3 Apr 2003 13:27:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33LRoBB005279; Thu, 3 Apr 2003 13:27: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.9+Sun/8.12.9) with ESMTP id h33LRkPL005269 for ; Thu, 3 Apr 2003 13:27:47 -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 h33LRtcU020660 for ; Thu, 3 Apr 2003 13:27: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 OAA16501 for ; Thu, 3 Apr 2003 14:27:49 -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, 3 Apr 2003 21:27:05 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, 3 Apr 2003 21:27:05 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, 3 Apr 2003 21:27:05 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 21:27:04 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h33LR2s32099 for ; Fri, 4 Apr 2003 00:27:02 +0300 Date: Fri, 4 Apr 2003 00:27:02 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-06.txt In-Reply-To: <200303251312.IAA08643@ietf.org> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A diversion from the site-local debacle.. :-) On Tue, 25 Mar 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 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. This satisfies my concerns for security considerations. I still disagree on the issue on API, but that's acceptable. Let's see what the community thinks about it. The two editorial/semi-editorial nits against the last version are still valid; however, they weren't critical and can be corrected in future revisions if appropriate. I think sending this off to the IESG would be appropriate. -- 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 Apr 3 13:56: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 h33LuOPL005826; Thu, 3 Apr 2003 13:56:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33LuOeJ005825; Thu, 3 Apr 2003 13:56: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 h33LuLPL005818 for ; Thu, 3 Apr 2003 13:56: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 h33LuTcU001655 for ; Thu, 3 Apr 2003 13:56: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 OAA20276 for ; Thu, 3 Apr 2003 14:56: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; Thu, 3 Apr 2003 21:56: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; Thu, 3 Apr 2003 21:53: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; Thu, 3 Apr 2003 21:56:23 Z Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 21:56:22 Z Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h33Lsxi2040802 for ; Thu, 3 Apr 2003 16:54:59 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h33LuLZL062742 for ; Thu, 3 Apr 2003 14:56:22 -0700 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.5/8.12.5) with ESMTP id h33LsDem007662 for ; Thu, 3 Apr 2003 16:54:13 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h33LsD0j007657 for ; Thu, 3 Apr 2003 16:54:13 -0500 Message-Id: <200304032154.h33LsD0j007657@rotala.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: Why I support deprecating SLs Date: Thu, 03 Apr 2003 16:54:13 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's a shame that not everyone could be at the meeting. IMO, it was one of those rare IETF moments in history where the room actually had a moment of clarity and actually was mostly on the same page. And I'm not saying this only because I personally am happy to see SL deprecated, but because even part way into the presentation, I was telling myself the WG is not going to be able to come to any decision today. But the mood in the room really did seem to shift during the discussion. I was simply stunned at the end of the meeting at the apparent clarity and decisiveness that had been expressed in the call for deprecated SLs. IMO, the room knew exactly what it was doing, and was also informed about what it was doing. It was not a forced decision. I believe the session was broadcast on the mbone, so it must be archived somewhere. (anyone know where?) Anyone not at the meeting who cares about this issue really needs to listen to that discussion in its fullness; the minutes do not come close to capturing what happened during the meeting. Having said that, one of the great difficulties I have with SLs is that I don't see a viable "compromise" or "middle ground". Every proposal I have looked at either uses SLs in very restricted settings (e.g, disconnected sites), or ends up having to implement the full blown "multi-sited node" (even though try to claim otherwise). I find scenarios that argue for a middle ground to be an unworkable illusion. Consider a bottom line. If we say SL addresses are a reasonable thing for (say) home networks doing autoconfig, and so on, the reality will be that SOHO routers will find ways of creating zeroconf environments that enable SL by default. They will then be used in practice in huge numbers of home networks. Corporations will likewise be tempted to use them, since they seem to provide "permanent" addresses, and "stability" across renumbering. So, we have situation not unlike being half-pregnant. In practice, SLs will become widely used in many organizations. But, once you have wide usage in terms of independent networks numbered using SLs, you have the inevitable problem of what happens if a node is in two sites at the same time. I don't buy the argument that this won't happen much and that the market can fill the gap if there is a need (and the IETF thus won't need to do this). If widespread useage of SL in networks becomes the reality, devices will be forced to work in those enviornments. One simple example: at home, I have my home network with a DSL link to the internet and also a VPN connection to my corporate intranet. This is a *very* common operating configuration. (Does anyone believe this won't be a common environment?) If both the home and corporate network use SL addressing (as they will in practice), things just won't work right unless nodes implement the multi-sited node architecture. Thus, I continue to come to the conclusion that we can't have it both ways. We either deprecate SLs, or we do the full blown multi-sited node. Doing anything in between will not work well enough in practice (i.e., is equivalent to us putting our heads in the sand) and will lead to interoperability problems, failed communications, and a less robust Internet. Exactly the opposite of what I believe IPv6 is all about. Does deprecating SL addresses cause problems? Clearly yes. And we need to put our engineering minds together to take those problems on as work items and develop solutions. And in particular, better overall solutions than we have with SLs. But I think we can do this, and we should do this, as it will lead to a better overall long-term technical result. Touching on the most common reasons people seem to have for supporting SLs: > - Site-locals should be retained for disconnected sites. 1) The WG will need to take an an activity to develop a solution for dealing with disconnected sites. I know I'll get flamed at some level for this, but we need a short problem statement to understand the basic constraints. (like, has to work out of the box, has to ease the pain of merged networks, etc.) But this can be 1-2 pages long, I suspect, and shouldn't take a year to develop. I think we collectively already know the constraints, we just need to write them down. We might also list some possible solutions, just to give folk a warm feeling that there are resonable approaches here (others have already posted such approaches), and that the WG isn't just putting its head in the sand. Personally, I'm not worried about this problem because I believe we can find reasonable solutions that don't involve SLs. This isn't a fundamentally hard problem like, say, multihoming. > - Site-locals should be retained for intermittently > connected sites. 2) The WG will need to take on an activity to develop a solution for intermittantly connected sites. Again, here I'm not that worried. For example, we have a lot of IPv6 addresses. There is no reason from a technical perspective why intermittantly disconnected sites can't continue using a prefix from its ISP after it is disconnected. IMO, there is something fundamentally broken with the idea that ISPs will be giving intermittantly connected sites different /48s or /64s each time they reconnect. But in any case, there are again other approaches as well, e.g., those also developed in 1) above would apply here to. So, again I do not think this is an unsolvable problem and am comfortable with the idea that we can and will solve it. > - Site-locals should be retained for their access control > benefits. 3) The WG should continue exploring the simple site boundary security approaches (e.g., zill/smb drafts). It's less clear to me (personally) how well this work will pan out, but it's definitely worth exploring. Besides, there isn't really agreement that SLs provide a good security boundary model anyway, so it isn't clear that SLs are an obvious answer here. > - Site-locals should be retained as a means for internal > connections to survive global prefix renumbering. 4) This is strikes me as a nice requirement, but something we don't have a solution for, even with SLs. We need to accept that we have no solution and SL is doesn't really seem to be a help here. Or, if folk really think there is an approach, its high time we had an ID to look at that actually fleshed out the details. We've had attempts in the past, but they have been abandoned. Thus, in summary, I support the deprecation of SLs with the understanding that taking this step will require that we take on some additional work items. But I don't see lack of specific solutions to those work items today as being a reason to delay deprecating SLs. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 3 13:59: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 h33Lx3PL005916; Thu, 3 Apr 2003 13:59:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33Lx2D4005915; Thu, 3 Apr 2003 13: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.9+Sun/8.12.9) with ESMTP id h33LwxPL005903 for ; Thu, 3 Apr 2003 13:58:59 -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 h33Lx7cU002517 for ; Thu, 3 Apr 2003 13:59: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 OAA12841 for ; Thu, 3 Apr 2003 14:59: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, 3 Apr 2003 21:58: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; Thu, 3 Apr 2003 21:58:09 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, 3 Apr 2003 21:58:09 Z Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 21:58:09 Z Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h33Lw4M13597; Thu, 3 Apr 2003 13:58:04 -0800 (PST) From: Bill Manning Message-Id: <200304032158.h33Lw4M13597@boreas.isi.edu> Subject: e2e & global view In-Reply-To: <5.1.1.5.2.20030403141122.00a0e260@atalanta.ctd.anl.gov> from Richard Carlson at "Apr 3, 3 03:24:16 pm" To: RACarlson@anl.gov (Richard Carlson) Date: Thu, 3 Apr 2003 13:58:04 -0800 (PST) Cc: mrw@windriver.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 % Hi Margaret; % % Let me try an rephrase my question. I would like to know if there is % consensus on the architectural view that IPv6 should have addresses with % different scopes? This architectural view means that some addresses will % not be usable for e2e communications in the global Internet. They will % only be usable in specific area, zones, sites (whatever label you want to % hang on the limited portion of the Internet where they work). I'm % continuing to view this discussion, and the call for consensus, in the % architectural sense, not the specific implementation laid down by your 3 % points. Is that your intent, or am I misinterpreting your consensus call? % % Again, I fail to see how deprecating site-local addresses (specifically the % FEC0::/10 prefix) solves the underlying problem (e2e communications failing % with some src/dst address pairs). % % Rich I -really- REALLY should just shut up and let this die. Rich, where is there the presumption that e2e communications is restricted to the "global Internet" stated as an architectural lema? Certainly some applications were designed with e2e, always reachable, endpoints in mind. Such presumptions are stressed with true mobility (not the tunneled back to home agent style), untethered and sometimes reachable networking that is evolving around us e.g. MANET, dccp, HIP, mDNS, zeroconf, et.al. Perhaps if the architectural view was e2e, sometimes reachable, then the bias against SL or its ilk would be mitigated. What do you think? --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 Apr 3 14:07: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 h33M7OPL006506; Thu, 3 Apr 2003 14:07:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33M7NvY006505; Thu, 3 Apr 2003 14:07: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 h33M7KPL006498 for ; Thu, 3 Apr 2003 14:07: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 h33M7ScU005994 for ; Thu, 3 Apr 2003 14:07: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 PAA21154 for ; Thu, 3 Apr 2003 15:07: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; Thu, 3 Apr 2003 22:07: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; Thu, 3 Apr 2003 22: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; Thu, 3 Apr 2003 22:07:22 Z Received: from cvx3.noc.east.ntt.co.jp ([210.163.32.76] [210.163.32.76]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 22:07:21 Z Received: from cmix2.noc.east.ntt.co.jp by cvx3.noc.east.ntt.co.jp with ESMTP id h33M7HB03497; Fri, 4 Apr 2003 07:07:17 +0900 (JST) Received: from smtp.rdc.east.ntt.co.jp by cmix2.noc.east.ntt.co.jp with ESMTP id h33M7GY17089; Fri, 4 Apr 2003 07:07:17 +0900 (JST) Received: from wataru2k01.rdc.east.ntt.co.jp by smtp.rdc.east.ntt.co.jp (8.9.3/3.7W) id HAA09996; Fri, 4 Apr 2003 07:07:15 +0900 (JST) Message-Id: <200304032205.AA00648@wataru2k01.rdc.east.ntt.co.jp> Date: Fri, 04 Apr 2003 07:05:29 +0900 To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: <3E8BB420.C4C8C67D@motorola.com> References: <3E8BB420.C4C8C67D@motorola.com> From: Wataru Kawakami - One user of current IPv6 MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.13 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Before deprecating site-locals for disconnected sites, well defined alternative address block should be RFC'ed, not to rewind the history. -- Site-Local address seems to be the nearest candidate to be used as ``local'' (locally used without interconnection to the Internet) address. (In IPv4, so called ``private address'') ``Local'' address is quite useful tool for operators of enterprise's network to provide good security for the users within the enterprise's network. In old days, I've heard that IPv4 global address was used as ``local'' address, undergroundly, before RFC-1918 was made. Deprecate of Site-Local Address without defining alternative for ``private'' address, in previous, may cause the history to rewind again. May turn to ``Yes'', if any *private* address block is defined as RFC *before* deprecate of Site-Local Address, and the *block* could be used freely, as RFC-1918 in IPv4 world. Just my comments follows; -- It is quite *hopeless* that ISPes will deliver ``private address'' for users, without fee. At IPv4 world, to my poor understanding, ordinary ISP may not assign me any global address, if I'm not the customer of the ISP. -- Wataru Kawakami, Japan. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 14:10: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 h33MAuPL006742; Thu, 3 Apr 2003 14:10:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33MAulX006741; Thu, 3 Apr 2003 14:10: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.9+Sun/8.12.9) with ESMTP id h33MArPL006734 for ; Thu, 3 Apr 2003 14:10:53 -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 h33MB1cU007464 for ; Thu, 3 Apr 2003 14:11: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 OAA06777 for ; Thu, 3 Apr 2003 14:10: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; Thu, 3 Apr 2003 22:10: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; Thu, 3 Apr 2003 22:10: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; Thu, 3 Apr 2003 22:10:33 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 22:10: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 h33MATvm090963; Thu, 3 Apr 2003 14:10:29 -0800 (PST) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h33MATHT090962; Thu, 3 Apr 2003 14:10:29 -0800 (PST) Date: Thu, 3 Apr 2003 14:10:29 -0800 From: Shannon -jj Behrens To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-06.txt Message-Id: <20030403221029.GB90447@alicia.nttmcl.com> References: <200303251312.IAA08643@ietf.org> 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 Fri, Apr 04, 2003 at 12:27:02AM +0300, Pekka Savola wrote: > A diversion from the site-local debacle.. :-) > > On Tue, 25 Mar 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 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. > > This satisfies my concerns for security considerations. > > I still disagree on the issue on API, but that's acceptable. Let's see > what the community thinks about it. I think it's perfectly acceptible to say that an API MUST be present without specifying the API. API documents are by their very nature informational and not standards track. Afterall, just because an OS isn't written in C/C++ doesn't mean it shouldn't conform to IETF standards if it wants to talk to the Internet. Such an OS is subject to RFC's concerning bits on the wire, but is surely not subject to RFC's concerning API's. Nonetheless, I think we should forward this document and then get to work on an informational API document. The flow label is something that definitely deserves a standardized C API. Best Regards, -jj > The two editorial/semi-editorial nits against the last version are still > valid; however, they weren't critical and can be corrected in future > revisions if appropriate. > > I think sending this off to the IESG would be appropriate. -- 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 Thu Apr 3 14:13: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 h33MDKPL006990; Thu, 3 Apr 2003 14:13:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33MDK6Z006989; Thu, 3 Apr 2003 14:13: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 h33MDGPL006974 for ; Thu, 3 Apr 2003 14:13:16 -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 h33MDOHP014211 for ; Thu, 3 Apr 2003 14:13:24 -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 OAA08728 for ; Thu, 3 Apr 2003 14:13: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; Thu, 3 Apr 2003 22:13: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, 3 Apr 2003 22:13: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; Thu, 3 Apr 2003 22:13:16 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; Thu, 3 Apr 2003 22:13:16 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 07EC8146BA; Fri, 4 Apr 2003 08:13:14 +1000 (EST) Date: Fri, 4 Apr 2003 08:13:14 +1000 From: "Nick 'Sharkey' Moore" To: Eliot Lear Cc: ipng@sunroof.eng.sun.com Subject: Re: site-locals (SLA =/=> NAT) Message-Id: <20030403221314.GD29246@zoic.org> Mail-Followup-To: Eliot Lear , ipng@sunroof.eng.sun.com References: <3E8BC77A.7060506@cisco.com> <20030403084935.GD27840@zoic.org> <3E8C65D3.8060209@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E8C65D3.8060209@cisco.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 03, 2003 at 08:48:19AM -0800, Eliot Lear wrote: > Nick, > > >I would question your assumptions: > >a) That the existence of site locals will cause people to use NAT > >b) That the deprecation of site locals will prevent people from > > using NAT. > > I think we have to turn this around- I view NATs as a bad thing for all > the reasons you've heard time and time again (so I won't repeat them). Great! So do I! NAT is basically a workaround for an IPv4 problem, and I think we can all agree that it are basically a pain, and not useful in and end-to-end IPv6 world! I think we should make it unnecessary! I'm questioning the _connection_ between _SLAs_ and _NAT_. a) I don't think having SLAs will cause people to use NAT, because it will be so much easier not to if your ISP gives you a /64 rather than a single IPv4 address. b) I don't think not having SLAs will prevent people using NAT if they, for some perverse reason, decide they want to. you don't have to agree with me. I'm just explaining my 'NO' vote. -----N -- 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 Thu Apr 3 14:37:02 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 h33Mb1PL008084; Thu, 3 Apr 2003 14:37:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33Mb19b008083; Thu, 3 Apr 2003 14:37: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.9+Sun/8.12.9) with ESMTP id h33MawPL008076 for ; Thu, 3 Apr 2003 14:36:58 -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 h33Mb6cU018407 for ; Thu, 3 Apr 2003 14:37: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-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26109 for ; Thu, 3 Apr 2003 14:37:01 -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, 3 Apr 2003 22:37: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; Thu, 3 Apr 2003 22:37: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, 3 Apr 2003 22:36:59 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; Thu, 3 Apr 2003 22:36:59 Z Message-Id: <023e01c2fa31$51462c10$036015ac@T23KEMPF> From: "James Kempf" To: , "Thomas Narten" References: <200304032154.h33LsD0j007657@rotala.raleigh.ibm.com> Subject: Re: Why I support deprecating SLs Date: Thu, 3 Apr 2003 14:35:22 -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 agree with your opinion and also support deprecating site locals. The discussion you posted is clear and very persuasive. However, I believe some of the resistance to deprecation may be the result of people who have implementations and would rather not have to pay the costs of ripping out that code and putting in something new. The logic here is the following: IETF may make the decision to deprecate, but it is the individual vendors that have to bear the cost of deprecation. If this is a widespread concern (and I may be misinterpreting so it may not be), then I'd ask those with this very practical concern to consider the alternative costs associated with deployment problems that Thomas has outlined in the note below. The customer service costs could easily dwarf the engineering costs of removing site locals, should these deployment problems occur in practice. jak ----- Original Message ----- From: "Thomas Narten" To: Sent: Thursday, April 03, 2003 1:54 PM Subject: Why I support deprecating SLs ... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 14:40: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 h33MesPL008311; Thu, 3 Apr 2003 14:40:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33MesJH008310; Thu, 3 Apr 2003 14:40: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 h33MepPL008303 for ; Thu, 3 Apr 2003 14:40: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 h33MexcU019715 for ; Thu, 3 Apr 2003 14:40:59 -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.3p2+Sun/8.9.3) with ESMTP id PAA24079 for ; Thu, 3 Apr 2003 15:40: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, 3 Apr 2003 22:40: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, 3 Apr 2003 22:40: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, 3 Apr 2003 22:40:52 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 22:40:52 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h33Mepvm091540 for ; Thu, 3 Apr 2003 14:40:51 -0800 (PST) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h33MepnT091539 for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 14:40:51 -0800 (PST) Date: Thu, 3 Apr 2003 14:40:51 -0800 From: Shannon -jj Behrens To: ipng@sunroof.eng.sun.com Subject: free prefix allocation service Message-Id: <20030403224051.GA91313@alicia.nttmcl.com> 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 I disagree with the assumption that no one will be willing to provide a service that delegates free unique prefixes for disconnected or intermittently- connected sites. In fact, I would be willing to provide such a service myself (for the selfish reason of being the one who solved the "great site-local" debate). I propose the following additional details: a unique GUSL prefix should by default be generated from the NIC of the router advertising the prefix. This is for the zeroconf people. For enterprises, they may gain a unique prefix from their own ISP for a fee, if so desired. For those people in between, they may come to my site to obtain a free prefix simply by supplying a working email address that I may use to contact them (i.e. I would have very minimal registration requirements). I would delegate the prefix from either 1) a larger prefix that my company, NTT, provides to me just to be nice 2) a larger prefix that some RIR provides me just to be nice. I would not claim to be the only such service. In fact, I would release the source code for the Web site so that others could provide a similar service (thus achieving redundency). Note, I specifically don't want to allocate from a *special* prefix. I'd rather delegate prefixes from some larger prefix so that other services may do the same. I'm just throwing this idea out to see if anyone likes it before I ask NTT for permission to do it (although I have received permission to post this email, of course). 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 Thu Apr 3 14:44: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 h33MiVPL008690; Thu, 3 Apr 2003 14:44:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33MiVBK008689; Thu, 3 Apr 2003 14:44: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.9+Sun/8.12.9) with ESMTP id h33MiRPL008677 for ; Thu, 3 Apr 2003 14:44:27 -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 h33MiZcU021848 for ; Thu, 3 Apr 2003 14:44:35 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA27231 for ; Thu, 3 Apr 2003 15:44:30 -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, 3 Apr 2003 22:44: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; Thu, 3 Apr 2003 22:41: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; Thu, 3 Apr 2003 22:44:29 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 22:44:28 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id RAA06152 for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 17:44:27 -0500 (EST) Date: Thu, 3 Apr 2003 17:44:27 -0500 (EST) From: Dan Lanciani Message-Id: <200304032244.RAA06152@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk |Thomas Narten wrote: | |> - Site-locals should be retained as a means for internal |> connections to survive global prefix renumbering. | |4) This is strikes me as a nice requirement, but something we don't | have a solution for, even with SLs. We need to accept that we have | no solution and SL is doesn't really seem to be a help here. Please explain why you feel that internal connections using site-locals will not survive global prefix renumbering. Dan Lanciani ddl@danlan.*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 Apr 3 14:50: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 h33MoTPL009190; Thu, 3 Apr 2003 14:50:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33MoSEC009189; Thu, 3 Apr 2003 14: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.9+Sun/8.12.9) with ESMTP id h33MoPPL009179 for ; Thu, 3 Apr 2003 14:50: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 h33MoWcU026300 for ; Thu, 3 Apr 2003 14:50:32 -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 OAA05926 for ; Thu, 3 Apr 2003 14:50:27 -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, 3 Apr 2003 22:50: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, 3 Apr 2003 22:50: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; Thu, 3 Apr 2003 22:50:18 Z Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 22:50:17 Z Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Thu, 3 Apr 2003 14:50:17 -0800 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 03 Apr 2003 14:50:17 -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, 3 Apr 2003 14:50:19 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 3 Apr 2003 14:50:16 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 3 Apr 2003 14:50:16 -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: e2e & global view Date: Thu, 3 Apr 2003 14:50:12 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: e2e & global view Thread-Index: AcL6LMxNeAXYrMYYToGCOW+zXLXUzwABQm7A From: "Christian Huitema" To: "Bill Manning" , "Richard Carlson" Cc: , X-OriginalArrivalTime: 03 Apr 2003 22:50:16.0063 (UTC) FILETIME=[64C3E0F0:01C2FA33] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33MoPPL009180 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > % Let me try an rephrase my question. I would like to know if there is > % consensus on the architectural view that IPv6 should have addresses with > % different scopes? No, there is definitely not consensus on that point. There are three big classes of arguments. The first class of argument is more against "ambiguous addresses" than scoped addresses: using ambiguity as a surrogate for unreachability is unnecessary (firewall can do that on any address) and inconvenient (ambiguity of addresses makes several error scenarios undecipherable). The second class of argument relates to routing and network management. Maintaining scoped addresses makes routing hard, especially if a node has to support multiple instantiations of a given scope. Margaret also developed an argument about the need to maintain a site convex, and the interaction of that requirement with shortest path routing. The third class of argument considers the use of addresses by applications. Using scoped addresses forces applications to understand scopes, which is much more complex and error prone than just considering that all addresses are equal. > % Again, I fail to see how deprecating site-local addresses (specifically > the > % FEC0::/10 prefix) solves the underlying problem (e2e communications > failing > % with some src/dst address pairs). Everybody should know that, and Bill is perfectly correct: just because an address is globally unique does not mean it is reachable. However, if it is unique, you eliminate a number of the error cases caused by ambiguity. -- 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 Apr 3 14:58: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 h33MvxPL009763; Thu, 3 Apr 2003 14:57:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33Mvxxh009762; Thu, 3 Apr 2003 14:57: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.9+Sun/8.12.9) with ESMTP id h33MvtPL009749 for ; Thu, 3 Apr 2003 14:57:55 -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 h33Mw3cU000439 for ; Thu, 3 Apr 2003 14:58:03 -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.3p2+Sun/8.9.3) with ESMTP id PAA07997 for ; Thu, 3 Apr 2003 15:57: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; Thu, 3 Apr 2003 22:57: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; Thu, 3 Apr 2003 22:57: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; Thu, 3 Apr 2003 22:57:57 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 22:57:56 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 03 Apr 2003 14:57:54 -0800 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" Cc: Subject: RE: My Thoughts on Site-Locals Date: Thu, 3 Apr 2003 14:57:55 -0800 Message-Id: <0a9b01c2fa34$76a73c30$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: <5.1.0.14.2.20030403140936.03adade8@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33MvtPL009750 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > Hi Tony, > > At 10:23 AM 4/3/2003 -0800, Tony Hain wrote: > >Margaret Wasserman wrote: > > > ... > > > Access control is also useful, and a simple form of > access control > > > will be needed in IPv6. However, site-local addresses are a poor > > > form of access control for two reasons: > > > > > > - Site-local boundaries need to be at routing area > > > or AS boundaries (not convenient). > > > >This is bogus nonsense. > > Please stop using this rude and dismissive language. This is > a professional setting, and it would behoove you to act > professionally. > > The need for site-local boundaries to be at routing area or > AS boundaries has been discussed in the routing area and on > the IPv6 list. It is required in order to maintain the > "convexity" of sites which is needed to avoid situations > where interally addressed packets will be discarded when > there is an internal path available to the destination. > > In order to make this work, the all-internal path to the > destination always has to be the shortest path. > > Bill Fenner, Alex Zinin, Steve Deering, Bob Hinden and I > (along with a variety of other folks) spent a long time > discussing this in various fora of the past two years, and we > have not come up with any way to ensure that the internal > path will be the shortest path (== site is "convex") without > requiring that site boundaries be on routing area or AS boundaries. Then why do you insist on claiming that filtering a prefix at existing route filtering boundaries is 'not convenient'? It is not my intent to be rude, because I really have no idea why such bogus comments are thrown in. They appear to just be FUD intended to sway opinion, particularly when you turn around and make technical counter arguments at other times (like here). > > Perhaps you have found a better way? If so, please share it > with us. Otherwise, I will persist in believing what we > established through careful analysis and extensive discussion. > > > > - Site-local areas cannot be nested. > > > > > > So, you can't have a site-local access control boundary for your > > > corporate site, AND a site-local access control boundary > that only > > > allows the marketing department to use the fancy printer. > > > >Within the site, there is no difference between the filtering > >characteristics of SL & any other prefix. If your argument is that a > >site can't have multiple subnets with the same prefix, well that is > >self evident. > > My point is that there is a need for nested levels of "local" > access. So, site-locals (which cannot be nested) will not > work as the only method of "local" filtering or access > control in a network. And, once you need to use another > method, what advantage is there to also using site-locals? Your assertion about nesting is ambiguous. I can certainly have a network with a pocket of independent SL inside it. Routing between it and the rest of the network would not be possible without globals, but in some situations that is exactly what is required. It is also possible to have multiple levels of filtering within a site using the FEC0 prefix that match area boundaries. The advantages of using it don't change; it doesn't cost anything to get, internal communications are isolated from external prefix changes, and if a configuration error occurs at the border the world will be configured to ignore the prefix so the network exposure profile is lower. > > Just because you have a site-local address for a node, and > you and that node are in the same site, does NOT mean that > you will be able to reach it. Just because you have a global > address for a node, does NOT mean that you will be able to > reach it. Since applications will have to deal with both of > these situations, what advantage is gained by using a special > site-local prefix for "local" nodes? Applications aren't supposed to work when there are filters in place. Network managers have a requirement to isolate some nodes from parts of the network, so they will filter. A well-known prefix allows everyone to block the same space so errors are not as dramatic. An additional value of a special prefix that keeps being ignored is the ability to have appliance devices configured to use it by default. This drastically reduces the manual configuration required for large networks. > > > > Both Steve Bellovin and Brian Zill have proposed superior access > > > control mechanisms based on information being passed in router > > > advertisements, and I think they plan to combine their proposals > > > into a single, maximally beneficial, form. > > > >They are not superior access control mechanisms. They result > in exactly > >the same architectural state where some addresses on a subnet are > >private while others are global. These mechanisms could just > as easily > >announce an FEC0 prefix, and the resulting internal > filtering would be > >identical. What they loose is the ability to know that the peer > >networks have implemented the same filter as a backup. > > The Bellovin proposal is superior because it allows for > nested local access control. > > "Private" and "Global" shouldn't be a binary choice. A local > access control mechanism needs to deal with multiple levels > of "private". FEC0::/10 provides 54 bits for local structure. Since 'private' space is simply filtering of routing information, there is ample opportunity for multiple levels of private space. I am glad you agree that Private & Global shouldn't be a binary choice, so we can drop all discussion of the 'exclusive' option. > > > > The intermittently-connected site problem is often raised as a > > > reason for site-locals. This is an interesting problem, and it > > > would be very good to solve this problem, but site-locals do not > > > provide a complete solution. > > > >You make statements like this without any explaination or > >justification. Stable addresses that persist across multiple > >connect/disconnect events to different providers are in fact one > >problem that the current SL approach completely solves. > > Local connections will only survive disconnect/reconnect if > they actually _use_ site-local addresses. This requires more > than site-local addressing. It require split DNS (or a > similar feature for whatever mechanism the application uses > to get the address). If topology information is exported outside its scope of relevance, the process responsible for doing that is broken. This is true even when the topology information is not ambiguous. For truly local connections, split DNS is not required. Where that becomes a requirement is for applications that leave the local context. Even there, the application *could* be intelligent enough to recognize when the /48 doesn't match and ignore any SL that it might have gotten back. > > There is also a conflict between how you would want things to > work, by default, to be friendly to intermittently connected > sites and how you would want things to work, by default, to > be friendly with mobile nodes. Which do you think will be > more prevalent? A mobile node knows that it is mobile, while other devices in a site won't have a clue about the connection state at the border. If you want to count devices, it is currently heavily weighted toward intermittent, and upcoming the stationary appliance market will easily exceed the mobile node market because people have many more appliances in the home or office than mobile devices they are willing to carry. In any case, there is no reason not to set the general default to SL, with mobile nodes having the opposite. When a MN knows it is not home (which it has to know to contact its HA), it should simply ignore any SL. > > > > So, while I think that the IETF needs to figure out a way > to address > > > this type of network, site-locals may not be the best way > to do it, > > > as they come with substantial costs for all nodes, and > don't fully > > > solve this problem. > > > >The IETF needs to address all the requirements BEFORE > removing the tool > >that currently solves them. Doing otherwise is an irresponsible act. > > Unfortunately, site-locals are not finished. And, there does > not seem to be WG consensus about how to finish them. > > So, by fighting for them, you are essentially fighting to > leave the IPv6 WG in the "stuck" position that we've been > occupying for the past couple of years. No, I have been stating that we need to solve the perceived problems in better ways FIRST. People will choose the path of least resistance. If we provide them a better tool that actually meets their requirements, they will move of their own accord. If we try to remove the tool because we are afraid, and offer only a vague promise that we might get around to it if we ever agree that their requirements are worth our valuable time (re: MW- I do not believe that we want to impose a costly and complex solution on _all_ IPv6 nodes so that a few of them can work properly in this unusual situation.), they will consider the IETF irrelevant and will make their networks work. Whatever that takes. I don't want the WG stuck, and have been working on an addressing plan that would in fact help with the address uniqueness case. I have not brought it to the WG because it was initially targeted at the multi-homing issue. If you would like me to submit it as a WG draft for consideration as a mechanism for unique values that don't require a registry, I am willing to do that. If it were coupled with the Bellovin/Zill RA, many of the requirements would be dealt with. That does not mean all are solved, so we still have work to do before deprecating SL. If we do it right, once we address all the requirements, nobody will even care about SL. At this point we don't even know if we can address all the reqirements with other mechanisms, so if we continue down the current path of doing it wrong, chaos will reign. Tony PS: I forwarded my SL requirements draft to the ID editor earlier today as a personal draft. If there is interest in that becoming a WG document, I will change the name and resubmit it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 3 15:05: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 h33N5hPL010130; Thu, 3 Apr 2003 15:05:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33N5heN010129; Thu, 3 Apr 2003 15:05: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 h33N5dPL010122 for ; Thu, 3 Apr 2003 15:05:39 -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 h33N5lcU003837 for ; Thu, 3 Apr 2003 15:05:48 -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 QAA11900 for ; Thu, 3 Apr 2003 16:05:42 -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, 3 Apr 2003 23:05:42 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, 3 Apr 2003 23:05: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, 3 Apr 2003 23:05:41 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 23:05:41 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 03 Apr 2003 15:05:40 -0800 Reply-To: From: "Tony Hain" To: "'Dan Lanciani'" , Subject: RE: Charge for traffic, not IP addresses (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Thu, 3 Apr 2003 15:05:40 -0800 Message-Id: <0a9c01c2fa35$8c803ba0$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: <200304032101.QAA05602@ss10.danlan.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33N5ePL010123 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: > ... > Charging for addresses has nothing to do with an IPv4 > mentality. It has to do with a business model. There is > absolutely nothing in IPv6 that would cause this business > model to change. Customers insisting that their privacy is important, so the ISP must support RFC3041 usage by the customer. This will prevent the per/address charges. It will not prevent charging per /64. 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 Apr 3 15:30: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 h33NUOPL010585; Thu, 3 Apr 2003 15:30:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33NUNti010584; Thu, 3 Apr 2003 15: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.9+Sun/8.12.9) with ESMTP id h33NUKPL010577 for ; Thu, 3 Apr 2003 15:30:20 -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 h33NUSHP018126 for ; Thu, 3 Apr 2003 15:30:28 -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 QAA19749 for ; Thu, 3 Apr 2003 16:30:19 -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, 3 Apr 2003 23:30:14 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, 3 Apr 2003 23:26: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; Thu, 3 Apr 2003 23:30:14 Z Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 23:30:14 Z Received: from nomad.ctd.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA00774; Thu, 3 Apr 2003 17:30:03 -0600 (CST) Message-Id: <5.1.1.5.2.20030403165732.00a7c6f0@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 03 Apr 2003 17:28:13 -0600 To: Bill Manning From: Richard Carlson Subject: Re: e2e & global view Cc: mrw@windriver.com, ipng@sunroof.eng.sun.com In-Reply-To: <200304032158.h33Lw4M13597@boreas.isi.edu> References: <5.1.1.5.2.20030403141122.00a0e260@atalanta.ctd.anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bill; I'm not sure I can answer your question, so I'll simply state my personal option. I reread the IPv6 address architecture draft before my last reply and it clearly states that not all e2e connections will succeed. That is, some addresses only work within a limited scope (link-local, site-local, and global). I believe this limited scope view matches the reality, were network managers and institutions block certain connections. I also believe this is a correct architectural position to take. Finally I agree that if this were the commonly accepted view, then discussions on how to achieve this goal would take place. Rich At 01:58 PM 4/3/03 -0800, Bill Manning wrote: >[snip snip snip] > > I -really- REALLY should just shut up and let this die. > Rich, where is there the presumption that e2e communications > is restricted to the "global Internet" stated as an architectural > lema? > > Certainly some applications were designed with e2e, always reachable, > endpoints in mind. Such presumptions are stressed with true > mobility (not the tunneled back to home agent style), untethered > and sometimes reachable networking that is evolving around us > e.g. MANET, dccp, HIP, mDNS, zeroconf, et.al. > > Perhaps if the architectural view was e2e, sometimes reachable, > then the bias against SL or its ilk would be mitigated. > > What do you think? > > >--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). ------------------------------------ Richard A. Carlson e-mail: RACarlson@anl.gov Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 15:30: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 h33NUaPL010595; Thu, 3 Apr 2003 15:30:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33NUa6f010594; Thu, 3 Apr 2003 15:30: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 h33NUUPL010587 for ; Thu, 3 Apr 2003 15:30: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 h33NUbHP018174 for ; Thu, 3 Apr 2003 15:30: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 QAA28510 for ; Thu, 3 Apr 2003 16:30: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, 3 Apr 2003 23:30:31 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, 3 Apr 2003 23:30: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; Thu, 3 Apr 2003 23:30:30 Z Received: from ALPHA9.ITS.MONASH.EDU.AU (ALPHA9.ITS.MONASH.EDU.AU [130.194.1.9]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 23:30:29 Z Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KUBPAFN6YA9BXAZ2@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 09:30:02 +1000 Received: from splat.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 33826130005; Fri, 04 Apr 2003 09:30:01 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id 1981A130003; Fri, 04 Apr 2003 09:30:01 +1000 (EST) Date: Fri, 04 Apr 2003 09:30:00 +1000 From: Greg Daley Subject: Re: Location Privacy (was Re: Outlawing (Avoiding) NAT with IPv6) To: Alper Yegin Cc: Alexandru Petrescu , Brian E Carpenter , alh-ietf@tndh.net, jbartas@iniche.com, ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E8CC3F8.8050705@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 Alper, Just a quick note. Alper Yegin wrote: [much text cut] >> >>To me, there are some common points, but there are also huge >>differences. I'm thinking about in NAT there is a specific set of >>types of addresses (the not publicly-routable) that can be reused by >>any site at will. However, with HMIPv6, the LCoAs must be globally >>unique. > > > That's right. This gives the option to use LCoA with a CN if MN wants to. > So, location privacy is an optional feature for MN to use, unlike with the > NATs. This is nice, because the MN might want to signal its location to some > CNs for things like location-based services. Actually, it is possible to use a site-local address for LCoA, if all outbound packets are forced to go through the MAP. Since there is a unique mapping for RCoA to the LCoA and tunneling of received globally addressed packets you don't get the application interference of NAT though. Of course, this will only be possible if we still have site-locals, and may require some protocol tweaks on entering a MAP domain which only advertises site-locals. I'm not going to recommend this as a solution though. I'm not flame proof. 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 Apr 3 15:33: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 h33NXcPL010805; Thu, 3 Apr 2003 15:33:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33NXcuF010804; Thu, 3 Apr 2003 15:33: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 h33NXXPL010782 for ; Thu, 3 Apr 2003 15:33:33 -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 h33NXfHP019195 for ; Thu, 3 Apr 2003 15:33:41 -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 PAA16559 for ; Thu, 3 Apr 2003 15:33: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, 3 Apr 2003 23:33: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, 3 Apr 2003 23:33:35 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, 3 Apr 2003 23:33:35 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 23:33:34 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 84E0F146BA; Fri, 4 Apr 2003 09:33:33 +1000 (EST) Date: Fri, 4 Apr 2003 09:33:33 +1000 From: "Nick 'Sharkey' Moore" To: Christian Huitema Cc: ipng@sunroof.eng.sun.com Subject: Re: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Message-Id: <20030403233333.GE29246@zoic.org> Mail-Followup-To: Christian Huitema , 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.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 03, 2003 at 10:45:25AM -0800, Christian Huitema wrote: > > If we are serious about NAT != SL, then we should enforce it. Well, I find this attitude (it's widespread on this list) bizarre ... if SLAs =/=> NAT (SLAs do not cause NAT) then we don't need to worry about it. > Suppose for example that we change our spec to forbid any communication > between addresses of different scopes. ... but that sounds fair enough to me. Scopes are scopes. Your return address has to be in scope at the destination. > This simple suggestion will in fact prevent using SL in the NAT > scenario, It will prevent _Standards Compliant_ client implementations from using NAT, but as we both know many vendors loosely interpret standards in any case. -- Nick 'Sharkey' Moore "If you can keep your cynicism when all around are losing theirs..." -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 15:38: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 h33NccPL011297; Thu, 3 Apr 2003 15:38:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33NcbQ3011296; Thu, 3 Apr 2003 15: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.9+Sun/8.12.9) with ESMTP id h33NcXPL011285 for ; Thu, 3 Apr 2003 15: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 h33NcfcU015927 for ; Thu, 3 Apr 2003 15:38:42 -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 QAA03366 for ; Thu, 3 Apr 2003 16:38: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; Thu, 3 Apr 2003 23:38: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; Thu, 3 Apr 2003 23:38: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; Thu, 3 Apr 2003 23:38:35 Z Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 23:38:35 Z Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 3 Apr 2003 15:38:35 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 03 Apr 2003 15:38:35 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 3 Apr 2003 15:38:35 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 3 Apr 2003 15:38:34 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 3 Apr 2003 15:38:33 -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: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Thu, 3 Apr 2003 15:38:33 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Thread-Index: AcL6OYESznjPQua7RV6fZ1IP/58UrQAAF7rQ From: "Christian Huitema" To: "Nick 'Sharkey' Moore" Cc: X-OriginalArrivalTime: 03 Apr 2003 23:38:33.0396 (UTC) FILETIME=[23B5CF40:01C2FA3A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33NcYPL011286 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > This simple suggestion will in fact prevent using SL in the NAT > > scenario, > > It will prevent _Standards Compliant_ client implementations from > using NAT, but as we both know many vendors loosely interpret > standards in any case. You don't get the point. If enough hosts come programmed to enforce scope restrictions, then the non compliant product ends up with a deployment headache and has to be fixed. This is basically the root of Internet standards -- enforcement by peer pressure. -- 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 Apr 3 15:49: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 h33NnUPL012107; Thu, 3 Apr 2003 15:49:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33NnUrf012106; Thu, 3 Apr 2003 15:49: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.9+Sun/8.12.9) with ESMTP id h33NnQPL012096 for ; Thu, 3 Apr 2003 15:49:26 -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 h33NnZHP024706 for ; Thu, 3 Apr 2003 15:49: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 PAB26459 for ; Thu, 3 Apr 2003 15:49:29 -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, 3 Apr 2003 23:49:29 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, 3 Apr 2003 23:49: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, 3 Apr 2003 23:49:28 Z Received: from ALPHA9.ITS.MONASH.EDU.AU (ALPHA9.ITS.MONASH.EDU.AU [130.194.1.9]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 23:49:27 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 <01KUBPY76LO49AUJNB@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 09:49:10 +1000 Received: from kapow.its.monash.edu.au (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id C43D620007; Fri, 04 Apr 2003 09:49:10 +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 98CE920006; Fri, 04 Apr 2003 09:49:10 +1000 (EST) Date: Fri, 04 Apr 2003 09:49:10 +1000 From: Greg Daley Subject: Re: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) To: Christian Huitema Cc: "Nick 'Sharkey' Moore" , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E8CC876.7020807@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 Christian, Christian Huitema wrote: >>>This simple suggestion will in fact prevent using SL in the NAT >>>scenario, >> >>It will prevent _Standards Compliant_ client implementations from >>using NAT, but as we both know many vendors loosely interpret >>standards in any case. > > > You don't get the point. If enough hosts come programmed to enforce > scope restrictions, then the non compliant product ends up with a > deployment headache and has to be fixed. This is basically the root of > Internet standards -- enforcement by peer pressure. The Globally addressed peer hosts when a communicating host is behind NAT are talking to another Global peer address at the NAT agent. This only requires complicity on the NAT box and the host, not the peer communicator. The proposed requirement provides no further burden to implementors than NATv4 systems. Greg D. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 15:49: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 h33NntPL012130; Thu, 3 Apr 2003 15:49:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33NntZo012129; Thu, 3 Apr 2003 15:49: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 h33NnoPL012112 for ; Thu, 3 Apr 2003 15:49: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 h33NnwcU020012 for ; Thu, 3 Apr 2003 15:49:58 -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 QAA10087 for ; Thu, 3 Apr 2003 16:49:53 -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, 3 Apr 2003 23:49: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; Thu, 3 Apr 2003 23:46: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, 3 Apr 2003 23:49:52 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 23:49:52 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 0288B146BA; Fri, 4 Apr 2003 09:49:49 +1000 (EST) Date: Fri, 4 Apr 2003 09:49:49 +1000 From: "Nick 'Sharkey' Moore" To: Christian Huitema Cc: ipng@sunroof.eng.sun.com Subject: Re: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Message-Id: <20030403234949.GF29246@zoic.org> Mail-Followup-To: Christian Huitema , 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.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 03, 2003 at 03:38:33PM -0800, Christian Huitema wrote: > > You don't get the point. If enough hosts come programmed to enforce > scope restrictions, then the non compliant product ends up with a > deployment headache and has to be fixed. This is basically the root of > Internet standards -- enforcement by peer pressure. What a wonderful world it will be. Consider, however, that once a packet has been NATed, it has a global scope source and destination. -----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 Thu Apr 3 15:53: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 h33NrdPL012532; Thu, 3 Apr 2003 15:53:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h33NrcxL012530; Thu, 3 Apr 2003 15:53: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 h33NrZPL012523 for ; Thu, 3 Apr 2003 15:53: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 h33NrhHP026241 for ; Thu, 3 Apr 2003 15:53:43 -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 QAA28966 for ; Thu, 3 Apr 2003 16:53: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; Thu, 3 Apr 2003 23:53: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; Thu, 3 Apr 2003 23:53:09 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, 3 Apr 2003 23:53: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; Thu, 3 Apr 2003 23:53:09 Z Content-class: urn:content-classes:message Subject: RE: My Thoughts on Site-Locals MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Apr 2003 15:53:08 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F5045679@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: My Thoughts on Site-Locals Thread-Index: AcL6G2k7IiEuWAWDQN+ZJy5YtUNXegAAFYzg From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h33NrZPL012524 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > Bill Fenner, Alex Zinin, Steve Deering, Bob Hinden and I > (along with a variety of other folks) spent a long time > discussing this in various fora of the past two years, > and we have not come up with any way to ensure that the > internal path will be the shortest path (== site is > "convex") without requiring that site boundaries be on > routing area or AS boundaries. Why don't you simply make this a requirement? I have heard many times that issue about the convexity although I don't remember opposition to coupling the site boundaries with the AS or routing area. This is the way I would do it anyway. I understand that we should not put restrictions when there is no need for them, but if putting a restriction allows something to work there is nothing wrong with 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 Apr 3 16:01: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 h3401hPL013027; Thu, 3 Apr 2003 16:01:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3401hOt013026; Thu, 3 Apr 2003 16: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h3401ePL013016 for ; Thu, 3 Apr 2003 16:01:40 -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 h3401mcU024392 for ; Thu, 3 Apr 2003 16:01:48 -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 RAA17084 for ; Thu, 3 Apr 2003 17:01:42 -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, 4 Apr 2003 00:01: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; Fri, 4 Apr 2003 00:01: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, 4 Apr 2003 00:01:41 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; Fri, 4 Apr 2003 00:01:41 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.64]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id QAA08531; Thu, 3 Apr 2003 16:01:15 -0800 (PST) Message-Id: <5.1.0.14.2.20030403185559.03acb498@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 18:59:19 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: My Thoughts on Site-Locals Cc: In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5045679@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 >Why don't you simply make this a requirement? I have heard many times >that issue about the convexity although I don't remember opposition to >coupling the site boundaries with the AS or routing area. We probably would have... Except that around the time that we actually formulated the correct solution, the WG started doubting the validity of site-border routers and started considering various alternatives for limiting site-local usage. The scoped addressing architecture has basically been on-hold ever since, waiting for us to make up our collective minds about site-locals. If the consensus to deprecate them does not hold, I'm not quite sure what we are going to do... We certainly don't have consensus to do any further work on site-locals, and it isn't clear how we can ever finalize the scoped addressing architecture without some type of decision on this issue. Perhaps we can break out the non-contentious parts and advance those parts? Well, we'll see what happens... 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 Apr 3 16:30:30 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 h340UUPL013470; Thu, 3 Apr 2003 16:30:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h340UUm1013469; Thu, 3 Apr 2003 16:30: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 h340URPL013462 for ; Thu, 3 Apr 2003 16:30: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 h340UZcU003563 for ; Thu, 3 Apr 2003 16:30:35 -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 QAA21650 for ; Thu, 3 Apr 2003 16:30:30 -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, 4 Apr 2003 00:30: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; Fri, 4 Apr 2003 00:27: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; Fri, 4 Apr 2003 00:30:29 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; Fri, 4 Apr 2003 00:30:29 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 BAA21811 for ; Fri, 4 Apr 2003 01:30:27 +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 BAA14752 for ; Fri, 4 Apr 2003 01:30:27 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h340URB25140 for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 01:30:27 +0100 Date: Fri, 4 Apr 2003 01:30:27 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Message-Id: <20030404003027.GS22090@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <3E8CC876.7020807@eng.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E8CC876.7020807@eng.monash.edu.au> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Christian Huitema wrote: > > > >You don't get the point. If enough hosts come programmed to enforce > >scope restrictions, then the non compliant product ends up with a > >deployment headache and has to be fixed. This is basically the root of > >Internet standards -- enforcement by peer pressure. So actually we want site-local scoping to remain so we can detect when there is a scope mismatch so the implementation can chose to have the connection fail? The danger I guess is that the site then hijacks a global scope address space to use internally so that the implementation will talk to external globally addressed hosts via a global-global NAT mapping? So do we gain anything? We would thus also have to put a "should not rewrite source address" requirement for devices in there too? Which many would just ignore... So I don't see we could ever stop NAT. Which leads to the conclusion that we must encourage ISPs to offer stable /48 prefixes (can the RIR policies help there?) even if that means an ISP with a million customers needs a /22 or similar rather than a /32 (allowing for HD-ratio), and let market forces take effect. 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 Thu Apr 3 16:34: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 h340YiPL013679; Thu, 3 Apr 2003 16:34:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h340Yh6s013678; Thu, 3 Apr 2003 16:34: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 h340YePL013668 for ; Thu, 3 Apr 2003 16:34: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 h340YmcU005189 for ; Thu, 3 Apr 2003 16:34: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-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24054 for ; Thu, 3 Apr 2003 16:34:43 -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, 4 Apr 2003 00:34:42 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, 4 Apr 2003 00:34:42 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, 4 Apr 2003 00:34:42 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; Fri, 4 Apr 2003 00:34:42 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 BAA21840 for ; Fri, 4 Apr 2003 01:34:40 +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 BAA14860 for ; Fri, 4 Apr 2003 01:34:40 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h340YeY25160 for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 01:34:40 +0100 Date: Fri, 4 Apr 2003 01:34:40 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) Message-Id: <20030404003440.GT22090@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <20030402142705.GB30669@ecs.soton.ac.uk> <006201c2f928$6933dd90$210d640a@unfix.org> <20030402160608.GD30669@ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030402160608.GD30669@ecs.soton.ac.uk> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Apr 02, 2003 at 05:06:08PM +0100, Mike Saywell wrote: > Not if the ad-hoc routing protocol assigns/negotiates one... Note also in Mike's scenario he needs /48's to networks attached to the community mesh, so the /10 property of a site-local is required, and solutions which may allocate "random", non-aggregating /48's or even /64's are not so desirable. Also, some nodes on the network have access to uplinks, some do not, yet all should be able to communicate internally. Enquiries to get a global prefix under the current schemes have not been successful; the community network would need to find the $$$ for LIR fees. A site local /10 is 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 Thu Apr 3 16:39: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 h340dtPL014140; Thu, 3 Apr 2003 16:39:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h340dtH6014139; Thu, 3 Apr 2003 16:39: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 h340dpPL014126 for ; Thu, 3 Apr 2003 16:39:51 -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 h340dxcU007038 for ; Thu, 3 Apr 2003 16:39: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-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14689 for ; Thu, 3 Apr 2003 16:39:54 -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, 4 Apr 2003 00:39: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, 4 Apr 2003 00:39: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, 4 Apr 2003 00:39:53 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, 4 Apr 2003 00:39:53 Z Content-class: urn:content-classes:message Subject: RE: My Thoughts on Site-Locals MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Apr 2003 16:39:52 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F72B@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: My Thoughts on Site-Locals Thread-Index: AcL6PV6AoYzhRynKRoqXwtWZmciTVgAAbhdQ From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h340dpPL014127 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, >> Michel Py wrote: >> Why don't you simply make this a requirement? I have >> heard many times that issue about the convexity although >> I don't remember opposition to coupling the site boundaries >> with the AS or routing area. > Margaret Wasserman wrote: > We probably would have... Except that around the time that > we actually formulated the correct solution, the WG started > doubting the validity of site-border routers and started > considering various alternatives for limiting site-local > usage. > The scoped addressing architecture has basically been > on-hold ever since, waiting for us to make up our collective > minds about site-locals. > If the consensus to deprecate them does not hold, I'm not > quite sure what we are going to do... We certainly don't > have consensus to do any further work on site-locals, To the contrary, I think this is the only consensus we have. First, this "consensus" on deprecation (if there is one which remains to be seen) does not exist for two big reasons: 1. Most of the votes were taken without knowing what it really meant. It's a consensus on vaporware. Note that this is not a criticism; Bob and you obviously had something else in mind and if there is something you failed it's only that you did not have the right inspiration when you had to improvise and that you allowed a few agitators in the room bully you into this vaporware instead of sticking to the plan. In the pot calling the kettle black dept. I would say that you did not pay enough attention to room dynamics and too much to your presentation :-( 2. I don't see how any consensus can be reached without a detailed explanation about the consequences on the scoped architecture. Second, by your own account we do need to prepare documents about what to do next. Call it deprecation if you want what I call it is that we have more work to do on site-locals and on the scoped architecture. > and it isn't clear how we can ever finalize the scoped > addressing architecture without some type of decision > on this issue. Perhaps we can break out the > non-contentious parts and advance those parts? I believe we can progress on three topics: - Ambiguity - Convexity / defining the site borders. - Tuning the compromise. Unfortunately this requires people that are for IPv6 and not against and that are willing to compromise. I regret to report that at this point I count only three: Bob Hinden, you and me. 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 Apr 3 16:48: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 h340mcPL014501; Thu, 3 Apr 2003 16:48:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h340mcmv014500; Thu, 3 Apr 2003 16:48: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.9+Sun/8.12.9) with ESMTP id h340mZPL014493 for ; Thu, 3 Apr 2003 16:48:35 -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 h340mhcU010114 for ; Thu, 3 Apr 2003 16:48:43 -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 RAA14557 for ; Thu, 3 Apr 2003 17:48: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; Fri, 4 Apr 2003 00:48:31 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, 4 Apr 2003 00:48: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; Fri, 4 Apr 2003 00:48:31 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; Fri, 4 Apr 2003 00:48: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 QAA12031; Thu, 3 Apr 2003 16:48:24 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h340mNL29104; Thu, 3 Apr 2003 16:48:23 -0800 X-mProtect: <200304040048> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlPVNec; Thu, 03 Apr 2003 16:48:22 PST Message-Id: <3E8CD656.4C4FC256@iprg.nokia.com> Date: Thu, 03 Apr 2003 16:48:22 -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: Richard Carlson CC: ipng@sunroof.eng.sun.com Subject: Re: e2e & global view References: <5.1.1.5.2.20030403141122.00a0e260@atalanta.ctd.anl.gov> <5.1.1.5.2.20030403165732.00a7c6f0@atalanta.ctd.anl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Richard, Reading your note, I thought of something that might be useful in the discussion. Richard Carlson wrote: > That is, some > addresses only work within a limited scope (link-local, site-local, and > global). I believe this limited scope view matches the reality, were > network managers and institutions block certain connections. I also > believe this is a correct architectural position to take. In this excerpt, I suggest replacing the concept of addresse "working" by "are routable". This does make sense, and moreover it allows a possibly important refinement on the meaning of "addressability". I would like to suggest that a host is "addressable" at a certain address if a packet, with that particular destination address, would be accepted by the host. A host is "routable" at the address if routers know how to route packets to some link where the host is able to receive it. I hope the distinction is clear. For instance, I am typically addressable as Charles E. Perkins, but some messages addressed with that as a destination address cannot be delivered to me, depending on the transmission medium and location of the source and so on. Maybe the distinction has already been made, but I don't remember seeing it lately. If you like that distinction, then I think it means that site-local addressability as a concept should be replaced by site-local routability. That puts it squarely in the domain of routing configuration (and protocol), and takes it even farther away from proper visibility by applications. Anyway, I prefer globally unique but not-necessarily-routable addresses to replace site-local addresses. I don't see why they shouldn't have prefix FEC0:/10, and I don't see why whatever document deprecates site-locals should not also reserve that prefix for the provider-independent uses that have been proposed. The allocation mechanism could be discussed further, but the addresses would be taken on the understanding that they would not be globally routable. If a particular recipient wishes to make private routing arrangements, then that's their business. 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 Thu Apr 3 17:17:46 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 h341HkPL014976; Thu, 3 Apr 2003 17:17:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h341HkjA014975; Thu, 3 Apr 2003 17:17: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 h341HgPL014968 for ; Thu, 3 Apr 2003 17:17:42 -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 h341HocU019930 for ; Thu, 3 Apr 2003 17:17:50 -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 SAA07172 for ; Thu, 3 Apr 2003 18:17: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; Fri, 4 Apr 2003 01:17: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; Fri, 4 Apr 2003 01:17: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; Fri, 4 Apr 2003 01:17:42 Z Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 01:17:42 Z Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h341Hds5047964; Thu, 3 Apr 2003 20:17:39 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-248-77.mts.ibm.com [9.65.248.77]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h341HcpR094006; Thu, 3 Apr 2003 18:17:38 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h341GZw06002; Thu, 3 Apr 2003 20:16:35 -0500 Message-Id: <200304040116.h341GZw06002@cichlid.adsl.duke.edu> To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs In-Reply-To: Message from ipng-incoming@danlan.com of "Thu, 03 Apr 2003 17:44:27 EST." <200304032244.RAA06152@ss10.danlan.com> Date: Thu, 03 Apr 2003 20:16:35 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > |Thomas Narten wrote: > | > |> - Site-locals should be retained as a means for internal > |> connections to survive global prefix renumbering. > | > |4) This is strikes me as a nice requirement, but something we don't > | have a solution for, even with SLs. We need to accept that we have > | no solution and SL is doesn't really seem to be a help here. > Please explain why you feel that internal connections using site-locals will > not survive global prefix renumbering. Internal connections using SLs will survive renumbering. But that is the easy part and by itself is largely uninteresting. The tough question is, how do we get applications in general to prefer SLs for local communication. Note that it is not enough for a handful of applications to use SLs and survive renumbering, my assumption is you want pretty much all intra-site communication to use SLs. I.e., if only 30% of your intra-site traffic is using SLs, and a renumbering takes place, 70% of your traffic is still potentially impacted. That doesn't seem like much of a real solution to me. I have yet to see what I believe is a credible approach to getting applications to prefer SLs across the board. Some people suggest we need to do split DNS. But their is no real consensus in the community for doing this. For example, I'll note that the DNS community has never been willing to officially bless split DNS behavior. They understand folks use it, but there are problems with the approach, and the DNS community has never had consensus that the benefits outweighed the problems. Hence, no IETF spec officially advocates split DNS, AFAIK. So, approaches that rely heavily on split DNS being even more widely deployed that it is already (e.g., in homes and other places with no clueful operations support) seems like an uphill fight at best There was some work done a few years ago (draft-ietf-ipngwg-site-prefixes-xx.txt) that tried to come up with a way of getting intra-site traffic to favor SLs. But the author eventually concluded their were problems with the approach and abandoned it. Plus, it required everyone implement the draft, and we've long since missed the window for making this happen. So, IMO, the notion that SLs protect a site agains the impact of a renumbering event is one of those IPv6 myths for which there is no real story to back up the desire. I wish it were otherwise. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 3 17:19: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 h341JaPL015035; Thu, 3 Apr 2003 17:19:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h341Jadc015034; Thu, 3 Apr 2003 17:19: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.9+Sun/8.12.9) with ESMTP id h341JWPL015021 for ; Thu, 3 Apr 2003 17:19:32 -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 h341JecU020470 for ; Thu, 3 Apr 2003 17:19:40 -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 SAA08212 for ; Thu, 3 Apr 2003 18:19:35 -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, 4 Apr 2003 01:19: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; Fri, 4 Apr 2003 01:16: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; Fri, 4 Apr 2003 01:19:32 Z Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [210.49.138.109]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 01:19:31 Z Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h341Ieab006699; Fri, 4 Apr 2003 11:18:40 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h341IdIC028218; Fri, 4 Apr 2003 11:18:39 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200304040118.h341IdIC028218@drugs.dv.isc.org> To: Markku Savela Cc: mrw@windriver.com, ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Consensus on what? RE: CONSENSUS CALL: Deprecating Site-Local Addressing In-reply-to: Your message of "Thu, 03 Apr 2003 22:21:35 +0300." <200304031921.h33JLZnO010111@burp.tkv.asdf.org> Date: Fri, 04 Apr 2003 11:18:39 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > From: Margaret Wasserman > > > Over time, implementations will cease to provide special handling > > for FECO::/10 (many don't provide any special handling for this > > prefix today, BTW) > > Well, I don't provide any special handling for FEC0::/10 (other than > noting address is site level). I already have to implement scoped > handling due to link locals. Site-local processing just comes free > after that. You have partial support for link-locals. No implementation has full support because that would require making link-locals first class addresses at all levels and the work to do that has not been done to specify how to do this. The work to do this is roughly equivalent to that required to get site-locals to the level of first class addresses. Mark > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 17:28:10 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 h341S9PL015638; Thu, 3 Apr 2003 17:28:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h341S9GB015637; Thu, 3 Apr 2003 17:28: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 h341S6PL015630 for ; Thu, 3 Apr 2003 17:28: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 h341SEcU023512 for ; Thu, 3 Apr 2003 17:28:14 -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 SAA13356 for ; Thu, 3 Apr 2003 18:28:09 -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, 4 Apr 2003 01:28: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; Fri, 4 Apr 2003 01:24: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; Fri, 4 Apr 2003 01:28:08 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; Fri, 4 Apr 2003 01:28:08 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.64]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA27150 for ; Thu, 3 Apr 2003 17:27:42 -0800 (PST) Message-Id: <5.1.0.14.2.20030403202415.03ad78d0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 20:26:00 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Fwd: Why SiteLocal is not what solves the problems people want to solve Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h341S6PL015631 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Patrik Fältström sent this message to the IPv6 list many hours ago, but it hasn't appeared on the list. I told him that I would resend it for him, so here it is... Margaret >From: Patrik Fältström >Date: tor apr 3, 2003 15:25:51 Europe/Stockholm >To: ipng@sunroof.eng.sun.com >Subject: Why SiteLocal is not what solves the problems people want to solve > >I have been quiet on this list, but have been talking with many many >people about the view I as an application person have on Site Local. > >I don't like it. > >I have seen a few cases which people bring up where site local would be >useful: > >[1] Networks which are intermittently connected >[2] Networks which have multiple upstream providers, and they want to have >a contiguous addressing scheme internally in the network >[3] Networks which should not be reachable from the Internet > >Let me address them one by one: > >[1] Let's say we have two computers connected to a home network. They >communicate with each other without any problem regardless of what >addresses they have, but, when the network is connected, we end up having >problems. > >If all nodes are renumbering, the 5-tuple which identifies existing flows >between the computers will change which means that existing communication >will break. > >But, this is a well known fact, and nothing we can do anything about. An >application *should*always* use the hostname when communicating, and that >imply it should not cache the IP address of the peers or itself between >the flows are initiated which it needs. Yes, applications fail regarding >this, and IP stacks are too bad at keeping the local IP address which >happen to be assigned at the time a "listen" call is made. Application >should be better at this, and I claim they _are_ getting better as >computers more and more move around already today (due to DHCP, 802.11b etc). > >The broken 5-tuple is not much we can do anything about, BUT, site-local >is not solving this problem either. Yes, I know the idea is that when two >nodes can share the site local scoping to minimize the risk for the >5-tuple to break.... > >More below why this kind of solution is broken. > >[2] Networks which have multiple upstream providers have two prefixes they >can choose from. Question is whether the network should use one, or the >other, or both (or site local, neither) prefixes. This is of course >something multi6 should take care of, but, from an application point of >view, having multiple addresses because of routing issues is not a good >idea. I rather see (in my possibly naïve view) sites like this really >getting PI address space. Yes, aggregation can not happen, but, so what? I >claim the number of routes today is still manageable, and the _real_ >problem is that an IP address is both for addressing and routing. > >Having a third prefix (site local) which is used will force the use of >NAT, and I really hope people understand how bad NAT is. I will not here >repeat what I hope will end up in a document which Leif and Keith is >writing about address management in applications. Applications which >partially one can say is broken as they use IP addresses in the payload >and not domain names, BUT, applications we have today. Applications we can >not get rid of (like ftp, sip etc). > >[3] This is the most stupid idea...that NAT == Security...and because of >that, nodes which only is thought of initiating flows towards something >else should be behind a NAT. Security is one thing, addressing another. If >an address is not to be accessible, filter out packets to it. A firewall >doesn't have to include NAT functionality. Yes, many do, but I also think >for these reasons many of them are broken. > > > >What one have to remember when talking about all of these problems is how >the Internet should work. Not how it is implemented today, because things >like NAT etc do exist, and yes, we will continue to see it for a while. > >First of all, we have one big mistake regarding addressing, and that is >the overload of use of the IP addresses. We use it both as a unique >identifier of an endpoint and for routing. addressing != routing > >This has created the problems we have with the routing protocols of today, >as the Internet is no longer hierarchal. It is a mesh, a complete mesh. >And, when navigating a mesh, one need different algorithms and mechanisms >than when navigating a hierarchy. Site Local will not solve this problem. > >Secondly, the 5-tuple we use for flow identification is rigid, and we >don't accept a change of any of the 5 values without having an interrupt >in the flow. Maybe we should have some ICMP which say "please redirect >flow to this address"? How to secure it? Will Site Local solve this >problem? Don't think so... > >Thirdly, I think it is important applications uses names of things (domain >names for example) when talking about and with others, while the IP >network is the one which should know about the IP addresses. When an >application have to know about the underlying network topology I would get >very very nervous. Yes, FTP and SIP uses IP addresses, and I am not >defending those two protocols. They are possibly flawed, but, even if they >use the domain names in their payload, they don't have to know the >topology (=routing) to know what source address they should use in a >multihomed network. > >As someone said at the meeting in San Francisco: The day an application is >required to know about routing and network topology we have a layering >violation. > > >I could possibly continue for a while, but I will stop here. > >Just Say No to Site Local. > >Or, as we say in Sweden "Gör om, gör rätt". ("Try again, and do it right >this time") > > paf -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 17:40: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 h341ecPL015940; Thu, 3 Apr 2003 17:40:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h341ecsi015939; Thu, 3 Apr 2003 17:40: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 h341eYPL015932 for ; Thu, 3 Apr 2003 17:40: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 h341egHP004897 for ; Thu, 3 Apr 2003 17:40: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.3p2+Sun/8.9.3) with ESMTP id SAA29704 for ; Thu, 3 Apr 2003 18:40: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; Fri, 4 Apr 2003 01:40: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; Fri, 4 Apr 2003 01:40: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; Fri, 4 Apr 2003 01:40:36 Z Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 01:40:36 Z Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h341eWs5106126; Thu, 3 Apr 2003 20:40:33 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-248-77.mts.ibm.com [9.65.248.77]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h341eWpR071118; Thu, 3 Apr 2003 18:40:32 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h341dSh07349; Thu, 3 Apr 2003 20:39:29 -0500 Message-Id: <200304040139.h341dSh07349@cichlid.adsl.duke.edu> To: "James Kempf" cc: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs In-Reply-To: Message from kempf@docomolabs-usa.com of "Thu, 03 Apr 2003 14:35:22 PST." <023e01c2fa31$51462c10$036015ac@T23KEMPF> Date: Thu, 03 Apr 2003 20:39:28 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi James. > However, I believe some of the resistance to deprecation may be the > result of people who have implementations and would rather not have > to pay the costs of ripping out that code and putting in something > new. This I don't understand. AFAIK, there is little or no code to rip out. And if the code is there, but no site-locals are actually configured or assigned to nodes, any code related to site-locals doesn't get executed and is harmless. So I don't see what problem there is with deprecating them with regards to existing implementations. I don't imagine anyone is going to say we need to put wording in some spec that makes existing implementations that have code related to site-locals be declared non-conformant. That would be silly. Do folks think this above is a significant issue? Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 3 18:24: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 h342OfPL016523; Thu, 3 Apr 2003 18:24:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h342OfbL016522; Thu, 3 Apr 2003 18:24: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.9+Sun/8.12.9) with ESMTP id h342OaPL016515 for ; Thu, 3 Apr 2003 18:24:38 -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 h342OicU014926 for ; Thu, 3 Apr 2003 18:24:44 -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 TAA12636 for ; Thu, 3 Apr 2003 19:24:39 -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, 4 Apr 2003 02:24:39 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, 4 Apr 2003 02:24: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; Fri, 4 Apr 2003 02:24:38 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 02:24:38 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id VAA07301 for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 21:24:37 -0500 (EST) Date: Thu, 3 Apr 2003 21:24:37 -0500 (EST) From: Dan Lanciani Message-Id: <200304040224.VAA07301@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: |> |Thomas Narten wrote: |> | |> |> - Site-locals should be retained as a means for internal |> |> connections to survive global prefix renumbering. |> | |> |4) This is strikes me as a nice requirement, but something we don't |> | have a solution for, even with SLs. We need to accept that we have |> | no solution and SL is doesn't really seem to be a help here. | |> Please explain why you feel that internal connections using site-locals will |> not survive global prefix renumbering. | |Internal connections using SLs will survive renumbering. But that is |the easy part and by itself is largely uninteresting. I can't speak for others, but to me it is very interesting (and important) to have internal connections that are not at the mercy of my ISP's renumbering policy. |The tough question is, how do we get applications in general to prefer |SLs for local communication. If an application wants to maximize the stability of its connection it always uses the addresses of smallest scope that will do the job. Hasn't this been the idea behind scoped addressing from the beginning? I realize that there have been suggestions recently that you should always use a global address if one is available, but that's not a problem with scoped addressing--it's a way to deliberately break scoped addressing. |Note that it is not enough for a handful |of applications to use SLs and survive renumbering, my assumption is |you want pretty much all intra-site communication to use SLs. I.e., if |only 30% of your intra-site traffic is using SLs, and a renumbering |takes place, 70% of your traffic is still potentially impacted. That |doesn't seem like much of a real solution to me. I believe that your assumption is false. If the 30% consists of a few critical builds running over a remote file system, security information, etc., while the 70% represents much less important traffic then there could still be significant benefit. |I have yet to see what I believe is a credible approach to getting |applications to prefer SLs across the board. Some people suggest we |need to do split DNS. But their is no real consensus in the community |for doing this. For example, I'll note that the DNS community has |never been willing to officially bless split DNS behavior. They |understand folks use it, but there are problems with the approach, and |the DNS community has never had consensus that the benefits outweighed |the problems. Hence, no IETF spec officially advocates split DNS, |AFAIK. So, approaches that rely heavily on split DNS being even more |widely deployed that it is already (e.g., in homes and other places |with no clueful operations support) seems like an uphill fight at best Well, personally, I'm getting a little tired of worrying about what is and is not blessed. People will use what works. That said, I see no need to use split DNS in order to benefit from site-local's stable internal connections. As an example, my own network already uses separate names for the automation services that are accessed internally. Currently these are aliases for the global v4 addresses of the hosts which support the services. Under v6 I could change them to the site-local addresses of those same machines. All my automation services would then be protected from ISP renumbering. I can do something similar with file servers. And please let's not get into a debate about the impurity of using different names to reference different addresses on a single machine. We were doing that long before the DNS existed. |So, IMO, the notion that SLs protect a site agains the impact of a |renumbering event is one of those IPv6 myths for which there is no |real story to back up the desire. I wish it were otherwise. It is true that site-locals do not by their mere existence automatically protect a site against renumbering, but that is a straw man. Site-locals allow a site that cares to protect connections that it cares about. This is an important capability. Do not be so quick to dismiss it. Dan Lanciani ddl@danlan.*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 Apr 3 18:37: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 h342bjPL016818; Thu, 3 Apr 2003 18:37:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h342biHq016817; Thu, 3 Apr 2003 18:37: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.9+Sun/8.12.9) with ESMTP id h342bfPL016810 for ; Thu, 3 Apr 2003 18:37:41 -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 h342bncU018544 for ; Thu, 3 Apr 2003 18:37: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 SAA03826 for ; Thu, 3 Apr 2003 18:37: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; Fri, 4 Apr 2003 02:37: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; Fri, 4 Apr 2003 02:34:28 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, 4 Apr 2003 02:37:43 Z Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 02:37:43 Z Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h342bes5064708; Thu, 3 Apr 2003 21:37:40 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-248-77.mts.ibm.com [9.65.248.77]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h342bdpR016848; Thu, 3 Apr 2003 19:37:40 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h342aad09124; Thu, 3 Apr 2003 21:36:36 -0500 Message-Id: <200304040236.h342aad09124@cichlid.adsl.duke.edu> To: "Michel Py" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: My Thoughts on Site-Locals In-Reply-To: Message from michel@arneill-py.sacramento.ca.us of "Thu, 03 Apr 2003 16:39:52 PST." <963621801C6D3E4A9CF454A1972AE8F504F72B@server2000.arneill-py.sacramento.ca.us> Date: Thu, 03 Apr 2003 21:36:36 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, "Michel Py" writes: > > If the consensus to deprecate them does not hold, I'm not > > quite sure what we are going to do... We certainly don't > > have consensus to do any further work on site-locals, > To the contrary, I think this is the only consensus we have. > First, this "consensus" on deprecation (if there is one which remains to > be seen) does not exist for two big reasons: > 1. Most of the votes were taken without knowing what it really meant. > It's a consensus on vaporware. > Note that this is not a criticism; Bob and you obviously had something > else in mind and if there is something you failed it's only that you did > not have the right inspiration when you had to improvise and that you > allowed a few agitators in the room bully you into this vaporware > instead of sticking to the plan. > In the pot calling the kettle black dept. I would say that you did not > pay enough attention to room dynamics and too much to your presentation > :-( I find the above unhelpful and not true. Saying the votes were taken "without knowing what it really meant" is FUD. I was in the room and I sure felt like I knew what was being asked. I also went to the microphone before the question was asked to point out that what we were talking about by deprecation was "something to the left of the limited model". Nobody seemed to question that. I don't think anyone can claim folks didn't know what was being asked. To suggest otherwise is an attempt to cast FUD. > 2. I don't see how any consensus can be reached without a detailed > explanation about the consequences on the scoped architecture. I think a fair number of people do feel like they understand the consequences even if they aren't all written down in one document that explains it all in easy to understand steps. I have certainly had long conversations about this issue with numerous folk that I think do understand the implications -- and it is those implications that make people uncomfortable. I also think that the consequences and implications are subtle and not immediately easy to understand. I say that because it has taken a long time for the number of folk to understand the consequences and be concerned about them to reach critical mass. Everyone seems to start off from the "what's the big deal?" perspective. Heck, I thought SLs were fine too if we go back 5 years. It wasn't until we really started thinking hard about them that their problems started becoming better understood. I've seen it now (somewhat independently) in the zeroconf WG too, where similar issues have been discussed with LL addressing for IPv4. There are plenty of people there that don't see what is hard about scoping and that it's not a big deal to make applications handle them. But over time, more people have also come around to understanding that there are issues, and there are problems with scoping. And if you go to applications people (that is, those folk that spend their lives doing applications rather than stack work) they seem much more concerned on average that scoped addresses have significant (bad) implications for applications. > Second, by your own account we do need to prepare documents about what > to do next. Call it deprecation if you want what I call it is that we > have more work to do on site-locals and on the scoped architecture. Clearly, that needs to be done. But there is a basic chicken-and-egg problem. If the the WG isn't going to deprecate SLs, why would anyone bother writing the document calling for their deprecation? The purpose of the current discussion is to figure out whether we should go to the next steps of making changes in various documents. > > and it isn't clear how we can ever finalize the scoped > > addressing architecture without some type of decision > > on this issue. Perhaps we can break out the > > non-contentious parts and advance those parts? > I believe we can progress on three topics: > - Ambiguity > - Convexity / defining the site borders. > - Tuning the compromise. > Unfortunately this requires people that are for IPv6 and not against and > that are willing to compromise. I regret to report that at this point I > count only three: Bob Hinden, you and me. I don't understand what you are trying to say above, but if the implication is that the only members of the WG that are being reasonable and willing to listen are those listed above, I find that rather offensive. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 3 18:48: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 h342mCPL017204; Thu, 3 Apr 2003 18:48:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h342mCIT017203; Thu, 3 Apr 2003 18:48: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 h342m9PL017192 for ; Thu, 3 Apr 2003 18:48:09 -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 h342mHcU021195 for ; Thu, 3 Apr 2003 18:48:17 -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.3p2+Sun/8.9.3) with ESMTP id TAA17183 for ; Thu, 3 Apr 2003 19:48: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; Fri, 4 Apr 2003 02:48:11 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, 4 Apr 2003 02:48: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; Fri, 4 Apr 2003 02:48:10 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; Fri, 4 Apr 2003 02:48:10 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.64]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA01353; Thu, 3 Apr 2003 18:47:42 -0800 (PST) Message-Id: <5.1.0.14.2.20030403213448.03c429f8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 21:41:39 -0500 To: Dan Lanciani From: Margaret Wasserman Subject: Re: Why I support deprecating SLs Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200304040224.VAA07301@ss10.danlan.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I realize that there >have been suggestions recently that you should always use a global address if >one is available, but that's not a problem with scoped addressing--it's a >way to deliberately break scoped addressing. It is also a way to avoid breaking Mobile IP. And, it is a way to avoid losing your connection if the site becomes "concave" or fragments due to a router or link failure... >It is true that site-locals do not by their mere existence automatically >protect a site against renumbering, but that is a straw man. Site-locals >allow a site that cares to protect connections that it cares about. This >is an important capability. Do not be so quick to dismiss it. Do you really need site-local addresses as currently defined (ambiguous, scoped address) to achieve this? Or would it be better to have your own globally-unique, provider-independent prefix (perhaps assigned by a registry) that wouldn't require any special treatment from hosts, applications, etc. and that you could choose to filter at your firewalls? 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 Apr 3 19:00:04 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 h34304PL017504; Thu, 3 Apr 2003 19:00:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34304Xu017503; Thu, 3 Apr 2003 19:00: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.9+Sun/8.12.9) with ESMTP id h34300PL017495 for ; Thu, 3 Apr 2003 19:00:01 -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 h34309cU024007 for ; Thu, 3 Apr 2003 19:00:09 -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.3p2+Sun/8.9.3) with ESMTP id TAA29683 for ; Thu, 3 Apr 2003 19:00:03 -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, 4 Apr 2003 03:00:03 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, 4 Apr 2003 03:00: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; Fri, 4 Apr 2003 03:00:03 Z Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 03:00:02 Z Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h342x2gJ151082; Thu, 3 Apr 2003 21:59:02 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-248-77.mts.ibm.com [9.65.248.77]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h342xwpR018014; Thu, 3 Apr 2003 19:59:59 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h342wtS09167; Thu, 3 Apr 2003 21:58:55 -0500 Message-Id: <200304040258.h342wtS09167@cichlid.adsl.duke.edu> To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs In-Reply-To: Message from ipng-incoming@danlan.com of "Thu, 03 Apr 2003 21:24:37 EST." <200304040224.VAA07301@ss10.danlan.com> Date: Thu, 03 Apr 2003 21:58:55 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani writes: > I can't speak for others, but to me it is very interesting (and > important) to have internal connections that are not at the mercy of > my ISP's renumbering policy. I agree that this is a very desirable property to have. But wanting this doesn't mean we know how to achieve it. > |The tough question is, how do we get applications in general to prefer > |SLs for local communication. > If an application wants to maximize the stability of its connection > it always uses the addresses of smallest scope that will do the job. How do applications get addresses? In my experience, a lot of them get them out of the DNS. But, if we put SLs into the DNS, we have to have split DNS... > Hasn't this been the idea behind scoped addressing from the > beginning? I realize that there have been suggestions recently that > you should always use a global address if one is available, but > that's not a problem with scoped addressing--it's a way to > deliberately break scoped addressing. > |Note that it is not enough for a handful > |of applications to use SLs and survive renumbering, my assumption is > |you want pretty much all intra-site communication to use SLs. I.e., if > |only 30% of your intra-site traffic is using SLs, and a renumbering > |takes place, 70% of your traffic is still potentially impacted. That > |doesn't seem like much of a real solution to me. > I believe that your assumption is false. If the 30% consists of a few > critical builds running over a remote file system, security information, > etc., while the 70% represents much less important traffic then there > could still be significant benefit. Fine. How do you ensure that the critical applications do in fact use SL addresses? How do you even know which ones are "critical"? Isn't critical in the eye of the user? > |I have yet to see what I believe is a credible approach to getting > |applications to prefer SLs across the board. Some people suggest we > |need to do split DNS. But their is no real consensus in the community > |for doing this. For example, I'll note that the DNS community has > |never been willing to officially bless split DNS behavior. They > |understand folks use it, but there are problems with the approach, and > |the DNS community has never had consensus that the benefits outweighed > |the problems. Hence, no IETF spec officially advocates split DNS, > |AFAIK. So, approaches that rely heavily on split DNS being even more > |widely deployed that it is already (e.g., in homes and other places > |with no clueful operations support) seems like an uphill fight at best > Well, personally, I'm getting a little tired of worrying about what > is and is not blessed. People will use what works. I take it from the above that you believe that making split DNS work is trivial and obvious, so folks can and will just use it no problem. My point is that the community doesn't seem to be in complete agreement about that, which means there are almost certainly subtleties and potential gotchas that can and will get in the way. If it were just trivial and obvious how to do this, I somehow doubt folk would have issues with split DNS. > That said, I see no need to use split DNS in order to benefit from > site-local's stable internal connections. As an example, my own > network already uses separate names for the automation services that > are accessed internally. Currently these are aliases for the global > v4 addresses of the hosts which support the services. Under v6 I > could change them to the site-local addresses of those same > machines. So, in your system you have two names for the same service, one for the global address, one for the internal address? And if you are inside your site, you use the internal name, and when you are outside you use the external name? If this is the basic idea, I suspect most users won't like this approach and will not consider it to have solved the problem acceptably. > All my automation services would then be protected from ISP > renumbering. I can do something similar with file servers. And > please let's not get into a debate about the impurity of using > different names to reference different addresses on a single > machine. We were doing that long before the DNS existed. > It is true that site-locals do not by their mere existence automatically > protect a site against renumbering, but that is a straw man. Site-locals > allow a site that cares to protect connections that it cares about. This > is an important capability. Do not be so quick to dismiss it. I've seen people say they think SLs are important to protect internal communication for years. The problem is I still don't see a coherent proposal for how this can be made to work in practice that seems to solve the problem in a reasonable way for a broad class of users. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 3 19:17: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 h343HtPL017957; Thu, 3 Apr 2003 19:17:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h343HtnV017956; Thu, 3 Apr 2003 19: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h343HpPL017948 for ; Thu, 3 Apr 2003 19:17: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 h343HxcU028474 for ; Thu, 3 Apr 2003 19:17:59 -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 TAA22769 for ; Thu, 3 Apr 2003 19:17:53 -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, 4 Apr 2003 03:17: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; Fri, 4 Apr 2003 03:14: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; Fri, 4 Apr 2003 03:17:52 Z Received: from newdev.harvard.edu ([140.247.60.212] [140.247.60.212]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 03:17:52 Z Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.7/8.12.2) with ESMTP id h343HckZ001220; Thu, 3 Apr 2003 22:17:38 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.7/8.12.2/Submit) id h343HcXh001219; Thu, 3 Apr 2003 22:17:38 -0500 (EST) Date: Thu, 3 Apr 2003 22:17:38 -0500 (EST) From: Scott Bradner Message-Id: <200304040317.h343HcXh001219@newdev.harvard.edu> To: ipng-incoming@danlan.com, mrw@windriver.com Subject: Re: Why I support deprecating SLs Cc: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030403213448.03c429f8@mail.windriver.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > better to have your own globally-unique, provider-independent > prefix (perhaps assigned by a registry) I do not see how this could work without blowing up the routing tables (CIDR 101) Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 19:19:10 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 h343JAPL017976; Thu, 3 Apr 2003 19:19:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h343JAX7017975; Thu, 3 Apr 2003 19:19: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.9+Sun/8.12.9) with ESMTP id h343J7PL017968 for ; Thu, 3 Apr 2003 19:19: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 h343JFcU028745 for ; Thu, 3 Apr 2003 19:19: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.3p2+Sun/8.9.3) with ESMTP id TAA09090 for ; Thu, 3 Apr 2003 19:19:10 -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, 4 Apr 2003 03:19:09 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, 4 Apr 2003 03:19:09 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, 4 Apr 2003 03:19:09 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 03:19:08 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id WAA07621 for ipng@sunroof.eng.sun.com; Thu, 3 Apr 2003 22:19:07 -0500 (EST) Date: Thu, 3 Apr 2003 22:19:07 -0500 (EST) From: Dan Lanciani Message-Id: <200304040319.WAA07621@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: |>I realize that there |>have been suggestions recently that you should always use a global address if |>one is available, but that's not a problem with scoped addressing--it's a |>way to deliberately break scoped addressing. | |It is also a way to avoid breaking Mobile IP. In a killing-ants-with-cannons sort of way... |>It is true that site-locals do not by their mere existence automatically |>protect a site against renumbering, but that is a straw man. Site-locals |>allow a site that cares to protect connections that it cares about. This |>is an important capability. Do not be so quick to dismiss it. | |Do you really need site-local addresses as currently defined |(ambiguous, scoped address) to achieve this? It is clear to me that nothing I would want from site-locals requires ambiguity. The scoping question is more difficult to answer. You need to be able to be sure that both ends of the internal connection use the stable addresses. You can control the destination address by using different name for different addresses; however, without scoping and without access to the application source code you may not be able to control the source address. The intuitively obvious choice of source address (closest match to destination) works, of course, but I would be concerned that this might not happen exactly because of thinking like yours above. That is, someone will do something ``to avoid breaking Mobile IP'' or such and in the process break local connections. |Or would it be |better to have your own globally-unique, provider-independent |prefix (perhaps assigned by a registry) that wouldn't require |any special treatment from hosts, applications, etc. and that |you could choose to filter at your firewalls? Give me that prefix and tell me how source address selection works and I'll let you know. In the meantime, site-local addresses as currently defined are the only solution that is currently defined... Dan Lanciani ddl@danlan.*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 Apr 3 19:30:28 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 h343URPL018452; Thu, 3 Apr 2003 19:30:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h343URPF018451; Thu, 3 Apr 2003 19:30: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 h343UOPL018444 for ; Thu, 3 Apr 2003 19:30:24 -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 h343UWcU001278 for ; Thu, 3 Apr 2003 19:30:32 -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.3p2+Sun/8.9.3) with ESMTP id UAA22387 for ; Thu, 3 Apr 2003 20: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; Fri, 4 Apr 2003 03:30: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; Fri, 4 Apr 2003 03:30: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; Fri, 4 Apr 2003 03:30:20 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; Fri, 4 Apr 2003 03:30:19 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 TAA24127; Thu, 3 Apr 2003 19:30:13 -0800 (PST) Message-Id: <3E8CFC2C.52FA7F96@iniche.com> Date: Thu, 03 Apr 2003 19:29:48 -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: Thomas Narten CC: James Kempf , ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs References: <200304040139.h341dSh07349@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Thomas, Thomas Narten wrote: > Do folks think this above is a significant issue? I just finished writing & documenting a v6 stack for embedded systems. My employer will be selling it as C source code, along with technical manuals explaining how to port the code. My experience is that many of our customers will go through every source file and structure in an effort to understand all the details of what they are preparing to field and support. I currently have a site-local address field in my interface structure, right alongside link-local and global addresses. There's also a few paragraphs in the manual explaining why the field is there and how it is initialized. If site local addresses disappear from the RFCs, I know from experience that I'll have customers calling our support team and asking what these fields are and how they should be initialized. If the vote is to deprecate these addresses, we (my employer) will take a hit even if we delete these fields from the sources and documents the same day the RFC is blessed. There will always be some customers using the older RFCs, or testing against older v6 implementations, and they'll want to know where the site-local support is. This issue is not big enough that anyone should brain damage IPv6 over it, but it's actually part of a larger issue - the credibility of IPv6. If this WG decides that site-local addresses really serve no purpose after specifying them since 1995, it will not give the developers and users of the world warm fuzzies about the stability of IPv6. This debate has already generated amusement and cynicism among my v4-only co-workers. I have not voted yet, since there's good reasons on both sides; and I've never had the experience of renumbering or merging a large IPv6 network. What I'd really like to see is site locals left in the spec, but issue a recommendation that they be avoided, by both developers and users, until their use is better understood. Sorry to bore you with my personal problems, by you asked :-) -JB- Thomas Narten wrote: > > Hi James. > > > However, I believe some of the resistance to deprecation may be the > > result of people who have implementations and would rather not have > > to pay the costs of ripping out that code and putting in something > > new. > > This I don't understand. AFAIK, there is little or no code to rip > out. And if the code is there, but no site-locals are actually > configured or assigned to nodes, any code related to site-locals > doesn't get executed and is harmless. So I don't see what problem > there is with deprecating them with regards to existing > implementations. I don't imagine anyone is going to say we need to put > wording in some spec that makes existing implementations that have > code related to site-locals be declared non-conformant. That would be > silly. > > Do folks think this above is a significant issue? > > 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 > -------------------------------------------------------------------- -- -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 Thu Apr 3 19:38:22 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 h343cLPL018707; Thu, 3 Apr 2003 19:38:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h343cLbk018706; Thu, 3 Apr 2003 19: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.9+Sun/8.12.9) with ESMTP id h343cIPL018699 for ; Thu, 3 Apr 2003 19:38: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 h343cQHP006079 for ; Thu, 3 Apr 2003 19:38:26 -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.3p2+Sun/8.9.3) with ESMTP id UAA01140 for ; Thu, 3 Apr 2003 20:38: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; Fri, 4 Apr 2003 03:38: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; Fri, 4 Apr 2003 03:38: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; Fri, 4 Apr 2003 03:38:19 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, 4 Apr 2003 03:38:19 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.64]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA18934; Thu, 3 Apr 2003 19:37:09 -0800 (PST) Message-Id: <5.1.0.14.2.20030403223143.03b321c8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 22:32:13 -0500 To: Scott Bradner From: Margaret Wasserman Subject: Re: Why I support deprecating SLs Cc: ipng-incoming@danlan.com, ipng@sunroof.eng.sun.com In-Reply-To: <200304040317.h343HcXh001219@newdev.harvard.edu> References: <5.1.0.14.2.20030403213448.03c429f8@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 Who said that they need to be globally routable? If the purpose is for private addressing, there is no need to route them. Margaret At 10:17 PM 4/3/2003 -0500, Scott Bradner wrote: > > better to have your own globally-unique, provider-independent > > prefix (perhaps assigned by a registry) > >I do not see how this could work without blowing up the routing tables > >(CIDR 101) > >Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 19:42: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 h343gKPL018886; Thu, 3 Apr 2003 19:42:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h343gKs3018885; Thu, 3 Apr 2003 19:42: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 h343gHPL018878 for ; Thu, 3 Apr 2003 19:42: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 h343gPHP007600 for ; Thu, 3 Apr 2003 19:42: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.3p2+Sun/8.9.3) with ESMTP id UAA18172 for ; Thu, 3 Apr 2003 20:42:19 -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, 4 Apr 2003 03:42: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; Fri, 4 Apr 2003 03:42: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; Fri, 4 Apr 2003 03:42:19 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, 4 Apr 2003 03:42:19 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.64]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA20437; Thu, 3 Apr 2003 19:41:39 -0800 (PST) Message-Id: <5.1.0.14.2.20030403223723.03c7ac68@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Apr 2003 22:40:03 -0500 To: jbartas@iniche.com From: Margaret Wasserman Subject: Re: Why I support deprecating SLs Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3E8CFC2C.52FA7F96@iniche.com> References: <200304040139.h341dSh07349@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >What I'd really like to see is site locals left in the spec, >but issue a recommendation that they be avoided, by both developers and >users, until their use is better understood. This is actually a pretty good match for "deprecation" by my definition. We'd keep the prefix in the spec, but mark it as "deprecated, do not use", or something like that. I think that we all understand that we can just eliminate this prefix from the specification and re-use it for something later (or at least not any time soon), as there are some implementations that treat these addresses specially. But, we can deprecate the prefix and indicate that it shouldn't be used. 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 Apr 3 19:54: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 h343sQPL019272; Thu, 3 Apr 2003 19:54:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h343sQ46019271; Thu, 3 Apr 2003 19:54: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 h343sMPL019264 for ; Thu, 3 Apr 2003 19:54: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 h343sUHP010233 for ; Thu, 3 Apr 2003 19:54:31 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id UAA08738 for ; Thu, 3 Apr 2003 20:54:25 -0700 (MST) 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; Fri, 4 Apr 2003 03:54: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; Fri, 4 Apr 2003 03:51:08 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, 4 Apr 2003 03:54:24 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; Fri, 4 Apr 2003 03:54:24 Z Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h343qpN06076 for ; Fri, 4 Apr 2003 06:52:51 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 4 Apr 2003 06:54:23 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Apr 2003 06:54:21 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Apr 2003 06:54:21 +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: My Thoughts on Site-Locals Date: Fri, 4 Apr 2003 06:54:20 +0300 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: My Thoughts on Site-Locals Thread-Index: AcL6PV6AoYzhRynKRoqXwtWZmciTVgAAbhdQAAetJPA= To: Cc: X-OriginalArrivalTime: 04 Apr 2003 03:54:21.0368 (UTC) FILETIME=[DFD07B80:01C2FA5D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h343sNPL019265 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael, > Second, by your own account we do need to prepare documents about what > to do next. Call it deprecation if you want what I call it is that we > have more work to do on site-locals and on the scoped architecture. > > > > and it isn't clear how we can ever finalize the scoped > > addressing architecture without some type of decision > > on this issue. Perhaps we can break out the > > non-contentious parts and advance those parts? > > I believe we can progress on three topics: > - Ambiguity > - Convexity / defining the site borders. > - Tuning the compromise. I support this as a way forward. 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 Apr 3 20:01: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 h3441oPL019639; Thu, 3 Apr 2003 20:01:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3441oMI019638; Thu, 3 Apr 2003 20:01: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 h3441lPL019631 for ; Thu, 3 Apr 2003 20:01: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 h3441tHP012031 for ; Thu, 3 Apr 2003 20:01:55 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA26310 for ; Thu, 3 Apr 2003 21:01: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, 4 Apr 2003 04:01: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, 4 Apr 2003 03:58: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; Fri, 4 Apr 2003 04:01:49 Z Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [210.49.138.109]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 04:01:48 Z Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h3441Oab006840; Fri, 4 Apr 2003 14:01:24 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h3441NIC029046; Fri, 4 Apr 2003 14:01:24 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200304040401.h3441NIC029046@drugs.dv.isc.org> To: Scott Bradner Cc: ipng-incoming@danlan.com, mrw@windriver.com, ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: Why I support deprecating SLs In-reply-to: Your message of "Thu, 03 Apr 2003 22:17:38 EST." <200304040317.h343HcXh001219@newdev.harvard.edu> Date: Fri, 04 Apr 2003 14:01:23 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > better to have your own globally-unique, provider-independent > > prefix (perhaps assigned by a registry) > > I do not see how this could work without blowing up the routing tables This prefix would *not* be advertised into the global routing table. You would have *other* prefixes for those machines that wish global connectivity assigned from your access providers. This is a prefix to replace the "site-local" prefix. site-local private prefix * globally routable NO NO * locally routable YES YES * privately routable NO YES * ambigious YES NO * DNS NO YES * requires second YES YES prefix for global reachability. * allows intra site YES YES connections to survive renumber events * requires renumber YES NO on site mergers Mark > > (CIDR 101) > > Scott > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 20:04: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 h3444WPL019782; Thu, 3 Apr 2003 20:04:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3444WgN019781; Thu, 3 Apr 2003 20:04: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 h3444RPL019764 for ; Thu, 3 Apr 2003 20:04:27 -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 h3444ZcU008996 for ; Thu, 3 Apr 2003 20:04:35 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA13721 for ; Thu, 3 Apr 2003 21:04:29 -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, 4 Apr 2003 04:04: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; Fri, 4 Apr 2003 04:04:28 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, 4 Apr 2003 04:04:28 Z Received: from newdev.harvard.edu ([140.247.60.212] [140.247.60.212]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 04:04:28 Z Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.7/8.12.2) with ESMTP id h3444QkZ001323; Thu, 3 Apr 2003 23:04:26 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.7/8.12.2/Submit) id h3444Qk5001322; Thu, 3 Apr 2003 23:04:26 -0500 (EST) Date: Thu, 3 Apr 2003 23:04:26 -0500 (EST) From: Scott Bradner Message-Id: <200304040404.h3444Qk5001322@newdev.harvard.edu> To: mrw@windriver.com, sob@harvard.edu Subject: Re: Why I support deprecating SLs Cc: ipng-incoming@danlan.com, ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030403223143.03b321c8@mail.windriver.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Who said that they need to be globally routable? If the purpose you had edge filtering as an option - how would you ensure they would not be routabe? and if they are not, just how are they all that differennt than site-local (seems to me that all of the same problems are there except for two sites merging Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 20:50:30 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 h344oUPL020505; Thu, 3 Apr 2003 20:50:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h344oUrf020504; Thu, 3 Apr 2003 20:50: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 h344oRPL020497 for ; Thu, 3 Apr 2003 20:50:27 -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 h344oZcU018906 for ; Thu, 3 Apr 2003 20:50: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.3p2+Sun/8.9.3) with ESMTP id VAA16582 for ; Thu, 3 Apr 2003 21:50:29 -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, 4 Apr 2003 04:50:11 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, 4 Apr 2003 04:50: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; Fri, 4 Apr 2003 04:50:10 Z Received: from ALPHA1.ITS.MONASH.EDU.AU (ALPHA1.ITS.MONASH.EDU.AU [130.194.1.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 04:50:10 Z Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KUC0GY4FCW95VBTK@vaxc.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 04 Apr 2003 14:49:51 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 827D712C01F; Fri, 04 Apr 2003 14:49:50 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id EAFE712C018; Fri, 04 Apr 2003 14:49:43 +1000 (EST) Date: Fri, 04 Apr 2003 14:49:43 +1000 From: Greg Daley Subject: Re: Why I support deprecating SLs To: Scott Bradner Cc: ipng-incoming@danlan.com, mrw@windriver.com, ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E8D0EE7.40001@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: <200304040317.h343HcXh001219@newdev.harvard.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Scott, Scott Bradner wrote: >>better to have your own globally-unique, provider-independent >>prefix (perhaps assigned by a registry) > > > I do not see how this could work without blowing up the routing tables > > (CIDR 101) V4 address allocation systems today are based on registries, and provide CIDR (albeit in some cases poorly). This aggregation is basically because short prefixes are managed in blocks. The idea of Globally Unique Provider independent is a good idea, if it can be made workable. GUPI doesn't have to be routable. The ideal goal for many is to have Globally Routable Unique Provider Independent. Tony Hain currently has an interesting idea about providing uniqueness based on geography (not the first time this has been attempted either). Tony's idea is geographically aggregatable, and may provide a base routable model in some cases. Of course, geographic systems need to be worked out to determine how routes are advertised outside the domain, but there is a potential that similarly located addresses could be used to provide aggregatable blocks. These address blocks could be used in Internet communication, and allocated based on land occupancy, or (apartment block/city/jurisdictional) regional cooperation. Greg D. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 21:02:48 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 h3452lPL020945; Thu, 3 Apr 2003 21:02:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3452lKE020944; Thu, 3 Apr 2003 21:02: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 h3452hPL020937 for ; Thu, 3 Apr 2003 21:02:43 -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 h3452pcU021760 for ; Thu, 3 Apr 2003 21:02:51 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id WAA16522 for ; Thu, 3 Apr 2003 22:02:49 -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, 4 Apr 2003 05:02: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; Fri, 4 Apr 2003 05:02: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; Fri, 4 Apr 2003 05:02:48 Z Received: from newdev.harvard.edu ([140.247.60.212] [140.247.60.212]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 05:02:48 Z Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.7/8.12.2) with ESMTP id h3452fkZ001408; Fri, 4 Apr 2003 00:02:41 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.7/8.12.2/Submit) id h3452fG6001407; Fri, 4 Apr 2003 00:02:41 -0500 (EST) Date: Fri, 4 Apr 2003 00:02:41 -0500 (EST) From: Scott Bradner Message-Id: <200304040502.h3452fG6001407@newdev.harvard.edu> To: greg.daley@eng.monash.edu.au Subject: Re: Why I support deprecating SLs Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3E8D0EE7.40001@eng.monash.edu.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The ideal goal for many is to have Globally Routable > Unique Provider Independent. its a great goal, too bad it runs up against the reality of the routing protocols > Tony Hain currently has an interesting idea about providing > uniqueness based on geography (not the first time this > has been attempted either). Tony's idea is geographically > aggregatable, and may provide a base routable model > in some cases. that also would be gerat and as soon as there is a reasonable level of local ISP to ISP connectivity it just migt work (but that could take a rather long time) Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 21:09: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 h3459fPL021196; Thu, 3 Apr 2003 21:09:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3459enQ021195; Thu, 3 Apr 2003 21:09: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.9+Sun/8.12.9) with ESMTP id h3459bPL021188 for ; Thu, 3 Apr 2003 21:09:37 -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 h3459kHP026814 for ; Thu, 3 Apr 2003 21:09:46 -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.3p2+Sun/8.9.3) with ESMTP id VAA12970 for ; Thu, 3 Apr 2003 21:09:40 -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, 4 Apr 2003 05:09: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; Fri, 4 Apr 2003 05:09:40 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, 4 Apr 2003 05:09:39 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 05:09:38 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id AAA08237; Fri, 4 Apr 2003 00:09:35 -0500 (EST) Date: Fri, 4 Apr 2003 00:09:35 -0500 (EST) From: Dan Lanciani Message-Id: <200304040509.AAA08237@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: |Dan Lanciani writes: | |> I can't speak for others, but to me it is very interesting (and |> important) to have internal connections that are not at the mercy of |> my ISP's renumbering policy. | |I agree that this is a very desirable property to have. But wanting |this doesn't mean we know how to achieve it. We know how to achieve it. You may not like the way we achieve it because it doesn't meet your standards for architectural purity, but until you have a better approach, how about letting use keep our impure solutions? |> |The tough question is, how do we get applications in general to prefer |> |SLs for local communication. | |> If an application wants to maximize the stability of its connection |> it always uses the addresses of smallest scope that will do the job. | |How do applications get addresses? In my experience, a lot of them get |them out of the DNS. But, if we put SLs into the DNS, we have to have |split DNS... As I explained below, you don't have to use split DNS. But people do use split DNS and if they are satisfied with the result, who are we to tell them to stop? This notion of giving up critical functionality today so that perhaps in the future we will get back some subset of that functionality in a more pure form just doesn't fly in the real world. |> I believe that your assumption is false. If the 30% consists of a few |> critical builds running over a remote file system, security information, |> etc., while the 70% represents much less important traffic then there |> could still be significant benefit. | |Fine. How do you ensure that the critical applications do in fact use |SL addresses? By configuring them to do so |How do you even know which ones are "critical"? Isn't |critical in the eye of the user? How do you know which machines need uninterruptible power supplies? How do you know which switches need redundant links to the backbone? You seem to be suggesting that a solution is no good unless the protocol automagically makes decisions about which applications are critical. In the real world, people make these decisions all the time. In the real world, people probably don't even _want_ your protocol to be making these decisions for them. |> Well, personally, I'm getting a little tired of worrying about what |> is and is not blessed. People will use what works. | |I take it from the above that you believe that making split DNS work |is trivial and obvious, so folks can and will just use it no |problem. I can't imagine why you would take it that way. Believe it or not, in the real world, people are sometimes capable of doing things that are _not_ trivial and obvious. Especially when they have no alternative. |My point is that the community doesn't seem to be in complete |agreement about that, which means there are almost certainly |subtleties and potential gotchas that can and will get in the way. The "community" is never in complete agreement about _anything_. There are always subtleties and potential gotchas. This is a characteristic of all but the most trivial systems. It is not an adequate reason to abandon a useful solution, especially when you offer no alternative. |> That said, I see no need to use split DNS in order to benefit from |> site-local's stable internal connections. As an example, my own |> network already uses separate names for the automation services that |> are accessed internally. Currently these are aliases for the global |> v4 addresses of the hosts which support the services. Under v6 I |> could change them to the site-local addresses of those same |> machines. | |So, in your system you have two names for the same service, one for |the global address, one for the internal address? No, I have only one name for a given service and the services are available only internally. I have other names for the hosts that happen to run the services. Those names would continue to point to a global address in my v6 scenario (unless of course the machine had no global address at all). I would use the same name to, e.g., telnet to the machine from inside or outside. Telneting to the machine is not the kind of critical, long-term connection that I feel I need to protect from renumbering. Other sites might have different ideas about which connections are critical and they would configure accordingly. |And if you are |inside your site, you use the internal name, and when you are outside |you use the external name? No, because these services are internal-only. That's the whole point. |If this is the basic idea, I suspect most users won't like this |approach and will not consider it to have solved the problem |acceptably. I suspect that you suspect wrong. People are using these (or worse) models in conjunction with NAT. These models are well understood. If you do not wish to support them cleanly in v6 with scoped addresses people will use NAT (unless you give them PI addresses). If you also manage to eliminate NAT from v6, people just won't use v6. |> It is true that site-locals do not by their mere existence automatically |> protect a site against renumbering, but that is a straw man. Site-locals |> allow a site that cares to protect connections that it cares about. This |> is an important capability. Do not be so quick to dismiss it. | |I've seen people say they think SLs are important to protect internal |communication for years. The problem is I still don't see a coherent |proposal for how this can be made to work in practice that seems to |solve the problem in a reasonable way for a broad class of users. I'm afraid that in the real world people have to get by with solutions that do not rise to the level of perfection that you seek. If you deprive users of the flexibility they need to implement the obvious solution they will probably find a way to do something that you will like even less. If you purify the protocol to the point that users really can't do what they want, you won't have any users to worry about. Dan Lanciani ddl@danlan.*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 Apr 3 22:27: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 h346R7PL021773; Thu, 3 Apr 2003 22:27:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h346R7Fj021772; Thu, 3 Apr 2003 22:27: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.9+Sun/8.12.9) with ESMTP id h346R3PL021765 for ; Thu, 3 Apr 2003 22:27: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 h346RCcU008132 for ; Thu, 3 Apr 2003 22:27:12 -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.3p2+Sun/8.9.3) with ESMTP id WAA14282 for ; Thu, 3 Apr 2003 22:27:06 -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, 4 Apr 2003 06:27: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; Fri, 4 Apr 2003 06:23: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; Fri, 4 Apr 2003 06:27:06 Z Received: from psg.com (psg.com [147.28.0.62]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 06:27:05 Z Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 191KfJ-000Mmx-00 for ipng@sunroof.eng.sun.com; Thu, 03 Apr 2003 22:27:05 -0800 Date: Thu, 3 Apr 2003 22:24:37 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-Id: <595521669.20030403222437@psg.com> To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.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 "YES -- Deprecate site-local unicast addressing". reasons += adds complexity to routing, forwarding, and network operations; -- Alex Zinin P.S. Though I was in the room in the beginning of the WG meeting, I left it before this discussion started... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 22:54:04 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 h346s3PL022073; Thu, 3 Apr 2003 22:54:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h346s3UB022072; Thu, 3 Apr 2003 22:54: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.9+Sun/8.12.9) with ESMTP id h346s0PL022065 for ; Thu, 3 Apr 2003 22:54:00 -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 h346s8cU013874 for ; Thu, 3 Apr 2003 22:54:08 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id XAA07525 for ; Thu, 3 Apr 2003 23:54:02 -0700 (MST) 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; Fri, 4 Apr 2003 06:54: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; Fri, 4 Apr 2003 06:54: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, 4 Apr 2003 06:54:00 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; Fri, 4 Apr 2003 06:54:00 Z Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h346qQN01959 for ; Fri, 4 Apr 2003 09:52:26 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 4 Apr 2003 09:52:26 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Apr 2003 09:52:26 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Apr 2003 09:52:26 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 4 Apr 2003 09:52:11 +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: My Thoughts on Site-Locals Date: Fri, 4 Apr 2003 09:52:00 +0300 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: My Thoughts on Site-Locals Thread-Index: AcL6FXNN7vvj6NuBQOyckY5ZxR2MyQAYItUA To: Cc: X-OriginalArrivalTime: 04 Apr 2003 06:52:11.0076 (UTC) FILETIME=[B774B840:01C2FA76] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h346s0PL022066 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > The primary differences between IPv6 unicast site-local addresses (FECO::/10), > as defined today, and PI addresses are: > > 1. Site-local addresses are intentionally ambiguous. > 2. Sites may not overlap or be nested. > 3. Sites need to be convex, constraining their boundaries > to routing area or AS boundaries. > > Most of the implementation complexity comes from #1 and, IMO, we would be > much better off with an unambiguous form of local addressing. There are > a few proposals for MAC-address based versions or unique IPv4-address > based versions. We could also ask registries to provide globally unique > provider-independent addresses for this purpose. Perhaps there are other > choices. I am not actually a proponent of the "random > choice" model, BTW. I think that the disambiguating site-locals to a certain extent may be advisable (if we do keep them). However, I actually think that one of the attaction of NATs for users is that NATs provide ambiguous addresses. Even if we disambigated site-locals (or GUPIs or whatever) I don't that would kill the interest for ambigious addressing. What I would hope would be for some better controls on ambiguous addresses. Can we provide clear rules on their use and applicability? In addition, I also agree with you the "random choice" model - I think that such a solution would cause more harm than good. 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 Thu Apr 3 23:03: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 h3473RPL022511; Thu, 3 Apr 2003 23:03:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3473RmZ022510; Thu, 3 Apr 2003 23:03: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.9+Sun/8.12.9) with ESMTP id h3473OPL022503 for ; Thu, 3 Apr 2003 23:03: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 h3473WHP019240 for ; Thu, 3 Apr 2003 23:03:32 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id AAA17270 for ; Fri, 4 Apr 2003 00:03: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; Fri, 4 Apr 2003 07:03: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; Fri, 4 Apr 2003 07:00:09 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, 4 Apr 2003 07:03:25 Z Received: from slimsixten.besserwisser.org ([213.114.162.54] [213.114.162.54]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 07:03:25 Z Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id h3473FYu018793 for ; Fri, 4 Apr 2003 09:03:19 +0200 (CEST) Date: Fri, 04 Apr 2003 09:03:14 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: "ipng@sunroof.eng.sun.com" Subject: RE: site-locals Message-Id: <399860000.1049439794@localhost.besserwisser.org> In-Reply-To: <0a8401c2fa0b$7dd6ab40$ee1a4104@eagleswings> References: <0a8401c2fa0b$7dd6ab40$ee1a4104@eagleswings> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1247210887==========" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --==========1247210887========== Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Thursday, April 03, 2003 10:04:37 -0800 Tony Hain wrote: > This whole deprecate effort is about making it someone else's problem. It is less of a problem to do the right thing, as Elliot wrote. Less pain now, less pain in the future.=20 > The IETF has successfully driven out most of the network managers, and > now the remaining developers are trying to dictate how networks get run > by removing the tools that people really use.=20 You are right in the sense that there are too few operations people in the IETF standards work. And yes, the problem is that the remaining developers are inventing things we as operators (I help run a number of smallish research nets, only OC-192 lines and perhaps 2-300000 users, not much to talk about, but I think I count as "operator".) do not want.=20 Your analysis and argument fails on the pivotal point, though:=20 We do not want ambigious addresses. The only reason to do that is were there lack of address space. Really.=20 We do not want NAT. Nat breaks things. Not for web surfing, but most other things require hacking, be it Kerberos tickets without address info or what have you.=20 We do not want unreachability built-in. We can do that ourselves, or by means of backhoe.=20 We do not want to break DNS. It is in a enough sad state as it is.=20 I am talking to a lot of friends in the operations community these days, to make them aware of this consensus call, and have them say their meaning. Without exception their assessment of SL can be summarised to "OUTRAGEOUSLY UGLY".=20 So, I'm glad that you call on the operator community, but I think you will be surprised at what they say.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========1247210887========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+jS4z02/pMZDM1cURAqk7AJ4o3V5G1GGjHYurNZVfePvzPrmr6gCdFycJ ETmhY/S6DWhxVwjZ3nJh4jM= =GPCl -----END PGP SIGNATURE----- --==========1247210887==========-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 23:27: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 h347RQPL022960; Thu, 3 Apr 2003 23:27:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h347RQkO022959; Thu, 3 Apr 2003 23:27: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 h347RNPL022952 for ; Thu, 3 Apr 2003 23:27:23 -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 h347RVHP023638 for ; Thu, 3 Apr 2003 23:27: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-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id XAA27725 for ; Thu, 3 Apr 2003 23:27:26 -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, 4 Apr 2003 07:27: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; Fri, 4 Apr 2003 07:27:25 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, 4 Apr 2003 07:27:25 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 07:27:24 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h347QpK04856; Fri, 4 Apr 2003 10:26:51 +0300 Date: Fri, 4 Apr 2003 10:26:50 +0300 (EEST) From: Pekka Savola To: =?ISO-8859-1?Q?M=E5ns_Nilsson?= cc: "ipng@sunroof.eng.sun.com" Subject: ops folk wrt. site-locals [RE: site-locals] In-Reply-To: <399860000.1049439794@localhost.besserwisser.org> 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 Fri, 4 Apr 2003, Måns Nilsson wrote: > > The IETF has successfully driven out most of the network managers, and > > now the remaining developers are trying to dictate how networks get run > > by removing the tools that people really use. [...] > I am talking to a lot of friends in the operations community these days, to > make them aware of this consensus call, and have them say their meaning. > Without exception their assessment of SL can be summarised to "OUTRAGEOUSLY > UGLY". > > So, I'm glad that you call on the operator community, but I think you will > be surprised at what they say. I support you all the way, but in all fairness, there is likely a huge disconnect between "operators who are doing the right thing" (I hope I am at least: we don't do any NAT etc.) and "operators who like doing the wrong thing" or "operators who are forced to doing the wrong thing for whatever reasons". (It is not useful to use the words "right" and "wrong" about NAT's and what have you here but I use them for simplicity and brevity.) So, in a sense it would also be good to get feedback from ops folk of the latter categories. Those do exist, but I assume *they* are ones that are more rarely seen at the IETF (but also probably those who do not heed what IETF says in any case). But regardless, it's still the question of doing it right rather than "doing it the IPv4 way". -- 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 Apr 3 23:37: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 h347bRPL022998; Thu, 3 Apr 2003 23:37:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h347bRGN022997; Thu, 3 Apr 2003 23:37: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.9+Sun/8.12.9) with ESMTP id h347bOPL022990 for ; Thu, 3 Apr 2003 23:37:24 -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 h347bWHP025275 for ; Thu, 3 Apr 2003 23:37:32 -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.3p2+Sun/8.9.3) with ESMTP id AAA27939 for ; Fri, 4 Apr 2003 00:37: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, 4 Apr 2003 07:37: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; Fri, 4 Apr 2003 07:37: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; Fri, 4 Apr 2003 07:37:21 Z Received: from slimsixten.besserwisser.org ([213.114.162.54] [213.114.162.54]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 07:37:21 Z Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id h347bIYu022027; Fri, 4 Apr 2003 09:37:18 +0200 (CEST) Date: Fri, 04 Apr 2003 09:37:18 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: ipng@sunroof.eng.sun.com cc: pekkas@netcore.fi Subject: Re: ops folk wrt. site-locals [RE: site-locals] Message-Id: <457560000.1049441837@localhost.besserwisser.org> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2139492778==========" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --==========2139492778========== Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Friday, April 04, 2003 10:26:50 +0300 Pekka Savola wrote: > So, in a sense it would also be good to get feedback from ops folk of the > latter categories. Those do exist, but I assume *they* are ones that are = > more rarely seen at the IETF (but also probably those who do not heed > what IETF says in any case). >=20 > But regardless, it's still the question of doing it right rather than > "doing it the IPv4 way". Yes, that would be desirable, but perhaps hard to attain, both in terms of participion and compliance.=20 Most "outside-ipng-people" I've spoken to lately immediately associate SL with RFC1918 and v4-NAT, in a conceptual way. They are in many cases using both these techniques, but only because it is not feasible for them to get address space enough for their networks. It is probably safe to say that this restriction will go away in v6. --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========2139492778========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+jTYu02/pMZDM1cURAiTsAJkBgMYVGQ8PEdzQC61WrgXuWqm9WACfQUaA PNoaLTHs53dujRNmsKEd2QU= =Coy4 -----END PGP SIGNATURE----- --==========2139492778==========-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 23:39: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 h347dWPL023028; Thu, 3 Apr 2003 23:39:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h347dVSl023024; Thu, 3 Apr 2003 23:39: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.9+Sun/8.12.9) with ESMTP id h347dRPL023017 for ; Thu, 3 Apr 2003 23:39: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 h347dZcU023313 for ; Thu, 3 Apr 2003 23:39:35 -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.3p2+Sun/8.9.3) with ESMTP id XAA22980 for ; Thu, 3 Apr 2003 23:39:30 -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, 4 Apr 2003 07:39: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; Fri, 4 Apr 2003 07:36: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; Fri, 4 Apr 2003 07:39:29 Z Received: from naptop.autonomica.net (naptop.autonomica.net [192.71.80.71]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 07:39:28 Z Received: from naptop.autonomica.net (localhost [127.0.0.1]) by naptop.autonomica.net (8.12.8/8.12.8) with ESMTP id h33Kplwt002747; Thu, 3 Apr 2003 22:51:47 +0200 (MEST) To: Margaret Wasserman Cc: "ipng@sunroof.eng.sun.com" Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing From: Lars-Johan Liman Date: 03 Apr 2003 22:51:47 +0200 In-Reply-To: Message-Id: <22el4jnw2k.fsf@naptop.autonomica.net> Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk mrw@windriver.com: > The question is: > Should we deprecate IPv6 site-local unicast addressing? My answer is: "YES -- Deprecate site-local unicast addressing". Best regards, /Liman #---------------------------------------------------------------------- # There are 10 kinds of people in the world. Those who understand # binary numbers, and those who don't. #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail: liman@autonomica.se # Senior Systems Specialist ! HTTP : //www.autonomica.se/ # Autonomica AB, Stockholm ! Voice : +46 8 - 615 85 72 #---------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 3 23: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 h347pvPL023715; Thu, 3 Apr 2003 23:51:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h347pvT8023714; Thu, 3 Apr 2003 23: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h347prPL023704 for ; Thu, 3 Apr 2003 23:51:53 -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 h347q2cU026147 for ; Thu, 3 Apr 2003 23:52:02 -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.3p2+Sun/8.9.3) with ESMTP id AAA08123 for ; Fri, 4 Apr 2003 00:51:56 -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, 4 Apr 2003 07:51:56 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, 4 Apr 2003 07:51:56 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, 4 Apr 2003 07:51:55 Z Received: from psg.com (psg.com [147.28.0.62]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 07:51:55 Z Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 191LzP-00016B-00 for ipng@sunroof.eng.sun.com; Thu, 03 Apr 2003 23:51:55 -0800 Date: Thu, 3 Apr 2003 23:46:50 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-Id: <7110454943.20030403234650@psg.com> To: ipng@sunroof.eng.sun.com Subject: Re: My Thoughts on Site-Locals In-Reply-To: <0a9601c2fa23$ec3375b0$ee1a4104@eagleswings> References: <0a9601c2fa23$ec3375b0$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, >> >> - Site-local boundaries need to be at routing area >> >> or AS boundaries (not convenient). >> > >> > >> > This is bogus nonsense. >> >> Your answer does not really deserve a response. You're guilty of the >> very thing you accuse Margaret of. I'm curious as to how you >> would draw >> the boundaries. > Is it really necessary to point out that aligning a site-local boundary > with an existing routing boundary (AS or Area) that the network manager > has established is *extremely* convenient? Those boundaries exists for > operational reasons of filtering routing information. SL is about a > well-known prefix for routing filters, ergo aligning SL with an area or > AS border is the natural thing to do. Claiming otherwise only serves to > distribute FUD. Hmmm... I'm afraid you may be misunderstanding the reason for areas and AS'es. They exist to ensure scalability of the routing protocols by reducing the number of direct neighbors and network nodes within the visible part of network topology routers need to work with, amount of state routers have to maintain and the level of activity they have to deal with (just to mention a few, there's more to that). Filtering of routing information is definitely not the driving factor for those boundaries. It will be interesting for you to know that it is really rare when route filtering is done between areas within an OSPF domain, or between member AS'es within a BGP confed. As far as boundary placement is concerned, adding sites to routing, though possible, would add another dimension of complexity to network operations--requirements driving the placement of site boundaries may be conflicting with those driving normal area/domain boundaries, for example. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 00:06:53 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 h3486rPL024016; Fri, 4 Apr 2003 00:06:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3486rOM024015; Fri, 4 Apr 2003 00: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.9+Sun/8.12.9) with ESMTP id h3486nPL024008 for ; Fri, 4 Apr 2003 00:06:49 -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 h3486vcU029899 for ; Fri, 4 Apr 2003 00:06:57 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id BAA21443 for ; Fri, 4 Apr 2003 01:06: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; Fri, 4 Apr 2003 08:06: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; Fri, 4 Apr 2003 08:06: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; Fri, 4 Apr 2003 08:06:32 Z Received: from psg.com (psg.com [147.28.0.62]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 08:06:32 Z Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 191MDT-0001rT-00; Fri, 04 Apr 2003 00:06:27 -0800 Date: Fri, 4 Apr 2003 00:00:50 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-Id: <12411294941.20030404000050@psg.com> To: "Michel Py" CC: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: My Thoughts on Site-Locals In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5045679@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F5045679@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, Thursday, April 3, 2003, 3:53:08 PM, Michel Py wrote: >> Margaret Wasserman wrote: >> Bill Fenner, Alex Zinin, Steve Deering, Bob Hinden and I >> (along with a variety of other folks) spent a long time >> discussing this in various fora of the past two years, >> and we have not come up with any way to ensure that the >> internal path will be the shortest path (== site is >> "convex") without requiring that site boundaries be on >> routing area or AS boundaries. > Why don't you simply make this a requirement? I have heard many times > that issue about the convexity although I don't remember opposition to > coupling the site boundaries with the AS or routing area. You can't oppose it--it just won't work otherwise (RIP being an exception) :) The problem or rather inconvenience with tieing site boundaries and area/domain boundaries is that they are driven by different factors. Imagine, for instance, that your site that is currently implemented as an OSPF area is growing so big that you need to split it into multiple areas to give your routers a break. Because your site boundaries are driven by non-routing considerations (you just want your network to continue working as it used to), you don't want to split the site into two, so what you end up with is removing that big site from the OSPF domain in a separate one and splitting it into its own areas, while normally you would just have one more area in the OSPF domain. Operationally, this might be a headache. > This is the way I would do it anyway. I understand that we should not > put restrictions when there is no need for them, but if putting a > restriction allows something to work there is nothing wrong with it. I don't think this is _the_ problem. This only contributes to the list of complications. Also count modifications to RIB, FIB management, the forwarding process, making pings, traceroutes, etc site-aware... It's not impossible, in fact we know exactly how to do this, it just that complexity adds up to one side of the equation, and you really want to avoid extra complexity in routing and below... Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 00:16: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 h348GsPL024260; Fri, 4 Apr 2003 00:16:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h348GskB024259; Fri, 4 Apr 2003 00:16: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 h348GnPL024252 for ; Fri, 4 Apr 2003 00:16: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 h348GvcU002125 for ; Fri, 4 Apr 2003 00:16:57 -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.3p2+Sun/8.9.3) with ESMTP id BAA21670 for ; Fri, 4 Apr 2003 01:16:51 -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, 4 Apr 2003 08:16: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; Fri, 4 Apr 2003 08:16:50 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, 4 Apr 2003 08:16:50 Z Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 08:16:49 Z Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h348GJR7016797 for ; Fri, 4 Apr 2003 01:16:19 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id BAA27302 for ; Fri, 4 Apr 2003 01:16:12 -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 h348GjmE009063 for ; Fri, 4 Apr 2003 18:16:45 +1000 (EST) Message-Id: <3E8D3F6D.3C780065@motorola.com> Date: Fri, 04 Apr 2003 18:16:45 +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: A different FEC0::/10 proposal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Let's ask a different question. Would the following be acceptable: ----- The address space FEC0::/10 is reserved for non-global use. It is intended not to be globally routeable. All routers MUST by default blackhole any packet destined to FEC0::/10, and MAY return a 'destination unreachable' message. 'Sites' using FEC0::/10 addresses MUST implement a filter at the 'site border' that discards source or destination addresses in the FEC0::/10 space. Routing protocols MUST NOT exchange reachability information concerning FEC0::/10 across the border. Any router or node not explicitly configured to do otherwise MAY discard (silently or otherwise) any packet with a source or destination address in FEC0::/10 space. Applications MAY choose to treat FEC0::/10 addresses differently to other addresses, and MAY prefer or disprefer them. Applications MAY assume that FEC0::/10 addresses will be filtered before reaching the global internet. ----- This seems to cover the minimum requirements of the relevant parties. The only global requirement is that all routers by default black-hole FEC0::/10. If you choose to use site local addresses, then you come under the border router requirements given in the second paragraph. The only bugbear I can see is source address selection. One easy solution is to 'prefer closest match' to whatever destination address the application selected, which will mean SL matches SL and link-local matches link local. Ensuring non-SL matches non-SL may be slightly trickier, depending on prefixes, though the current policy of allocating from 0000::/12 will prefer global-global. And maybe something should be added to say "If you stick these things in a globally accessible DNS, don't be surprised when connections to your hosts fail." And maybe a policy to NXDOMAIN reverse lookups for [C-F].E.F.in6.arpa. In short, there is almost no extra effort for those who don't implement SL addresses - all the work is pushed to those who do. Notice that the above text says nothing about how FEC0::/10 addresses are to be allocated. All it does is reserve the space as 'not globally routeable' and put policies in place to stop this information getting where it shouldn't. -- 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 Fri Apr 4 01:49: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 h349nXPL024886; Fri, 4 Apr 2003 01:49:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h349nXaS024885; Fri, 4 Apr 2003 01:49: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.9+Sun/8.12.9) with ESMTP id h349nUPL024878 for ; Fri, 4 Apr 2003 01:49: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 h349ncHP021892 for ; Fri, 4 Apr 2003 01:49: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.3p2+Sun/8.9.3) with ESMTP id CAA18633 for ; Fri, 4 Apr 2003 02:49: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; Fri, 4 Apr 2003 09:49: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; Fri, 4 Apr 2003 09:49: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; Fri, 4 Apr 2003 09:49:24 Z Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 09:49:23 Z Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h349jNDM017969; Fri, 4 Apr 2003 02:45:24 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h349j1pG003933; Fri, 4 Apr 2003 03:45:04 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id E65082EC86; Fri, 4 Apr 2003 11:45:16 +0200 (CEST) Message-Id: <3E8D542C.8050507@nal.motlabs.com> Date: Fri, 04 Apr 2003 11:45:16 +0200 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Cc: Alper Yegin , Brian E Carpenter , alh-ietf@tndh.net, jbartas@iniche.com, ipng@sunroof.eng.sun.com Subject: Re: Location Privacy (was Re: Outlawing (Avoiding) NAT with IPv6) References: <3E8CC3F8.8050705@eng.monash.edu.au> In-Reply-To: <3E8CC3F8.8050705@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alper, Greg. I'm not flaming, and not try to generate any heat :-) Greg Daley wrote: >> That's right. This gives the option to use LCoA with a CN if MN >> wants to. So, location privacy is an optional feature for MN to >> use, unlike with the NATs. Actually, I think that MN can decide about its use of location privacy only if the network allows it. If the network doesn't allow it, in the advertised MAP options, then MN can not do anything and it will reveal its location to CN?: "This can be done if the I or P flags are set in the MAP option. Otherwise location privacy can not be provided in this manner. If the V flag is set (in addition to the P or I flags), the mobile node MUST tunnel all outgoing packets to the MAP." Specifically, if the V, I and P flags are not set in the MAP options (in other words network decides MN is not a VIP) then MN must reveal location information to CN. I mean, I interpret it that way, but the intended meaning might be otherwise. >> This is nice, because the MN might want to signal its location to >> some CNs for things like location-based services. Yes, ok, but must be entirely MNs option, not network's? Or maybe this was already discussed. > > > Actually, it is possible to use a site-local address for LCoA, if > all outbound packets are forced to go through the MAP. Since there > is a unique mapping for RCoA to the LCoA and tunneling of received > globally addressed packets you don't get the application > interference of NAT though. > > Of course, this will only be possible if we still have site-locals, > and may require some protocol tweaks on entering a MAP domain > which only advertises site-locals. Ok, here is were we diverge. Mobile IPv6 in itself provides a form of location privacy, in that if RO is not used, then all packets are tunneled back to HA, so CN doesn't know the actual location. Moreover, in Mobile IPv6 it would be much simpler if the concept of "site-locals" didn't exist. In HMIPv6, the above text, kind of requires the site-locals concept to be in place in order to offer location privacy. So, an idea is that the location privacy might be a problem, and that Mobile IPv6 might offer a site-local-free solution for that problem, and that HMIPv6 needs site locals in order to provide a solution to that problem. Alex GBU -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 01:57: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 h349vXPL025246; Fri, 4 Apr 2003 01:57:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h349vXaQ025245; Fri, 4 Apr 2003 01:57: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.9+Sun/8.12.9) with ESMTP id h349vUPL025235 for ; Fri, 4 Apr 2003 01:57: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 h349vccU026502 for ; Fri, 4 Apr 2003 01:57: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.3p2+Sun/8.9.3) with ESMTP id BAA18084 for ; Fri, 4 Apr 2003 01:57:32 -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, 4 Apr 2003 09:57: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; Fri, 4 Apr 2003 09:57: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; Fri, 4 Apr 2003 09:57:20 Z Received: from eikenes.alvestrand.no ([217.13.28.204] [217.13.28.204]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 09:57:20 Z Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 33CEE625A0 for ; Fri, 4 Apr 2003 11:57:19 +0200 (CEST) Date: Fri, 04 Apr 2003 11:57:19 +0200 From: Harald Tveit Alvestrand To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Message-Id: <340330000.1049450239@askvoll.hjemme.alvestrand.no> In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I was in San Francisco, but not in the room. YES -- Deprecate site-local unicast addressing Increases application complexity. Reduces application reliability. Requires too many compensating hacks to other protocols. Note: By "Deprecate Site-Local", I mean "Do not require any application, host, router, protocol or IETF practice to have to make special consideration for the idea that an IPv6 unicast address outside of the link-local range can refer to two different hosts". In particular, that the drawings in draft-ietf-ipngwg-scoping-arch-04.txt showing zone indices need never have more than 2 levels (interface-local and link-local), that all 70 references to "site" in this document can be removed, and that section 12 of that draft (textual representation of zone-ids) can be removed, or reworded to deal with debugging tools for link-local only. By "Deprecate", I do not mean "Allocate the FEC0::/10 prefix to the RIRs for normal allocations". That would be stupid. Harald -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 02: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 h34An3PL025747; Fri, 4 Apr 2003 02:49:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34An3hI025746; Fri, 4 Apr 2003 02: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h34An0PL025739 for ; Fri, 4 Apr 2003 02:49: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 h34An8cU007485 for ; Fri, 4 Apr 2003 02:49: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.3p2+Sun/8.9.3) with ESMTP id CAA19612 for ; Fri, 4 Apr 2003 02:49: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; Fri, 4 Apr 2003 10:49:02 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, 4 Apr 2003 10:49:02 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, 4 Apr 2003 10:49:02 Z Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 10:49:02 Z Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h34An0g03475; Fri, 4 Apr 2003 02:49:00 -0800 (PST) From: Bill Manning Message-Id: <200304041049.h34An0g03475@boreas.isi.edu> Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: <595521669.20030403222437@psg.com> from Alex Zinin at "Apr 3, 3 10:24:37 pm" To: zinin@psg.com Date: Fri, 4 Apr 2003 02:49:00 -0800 (PST) Cc: 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 % "YES -- Deprecate site-local unicast addressing". % % reasons += adds complexity to routing, forwarding, and network operations; % % -- % Alex Zinin waxing nostalgic... IPv6 was supposed to be an enabler of a whole raft of interesting new capabilities. based on your concerns, listed above, IPv6 is going to be nothing more than IPv4 with larger address space. if that is what we end up with, then IPv6 development might be considered a waste of time. we could support the premise of IPv6 (10x16th nodes...?) using Paul Francis's nifty idea of a box that will do address translation and never need to move away from a 32bit address space. IPv6 had (and perhaps still has) the ability to allow us to develop alternative routing techniques, where aggregation is not the only abstraction that is viable. For me the vote (and it is a vote...) seems to break down along these lines: Yes - those who wish to maintain the status quo or have vested commercial interests in shipping IPv6 product. No - those who wish to explore the latent capabilities of IPv6. as usual, YMMV and my understanding is likely flawed. --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 Fri Apr 4 03:11: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 h34BBbPL026029; Fri, 4 Apr 2003 03:11:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34BBbhi026028; Fri, 4 Apr 2003 03:11: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 h34BBYPL026021 for ; Fri, 4 Apr 2003 03:11: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 h34BBfHP008894 for ; Fri, 4 Apr 2003 03:11:41 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA24215 for ; Fri, 4 Apr 2003 04:11: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; Fri, 4 Apr 2003 11:11: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, 4 Apr 2003 11:08: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; Fri, 4 Apr 2003 11:11:35 Z Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 11:11:35 Z Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h34B9R3u003187; Fri, 4 Apr 2003 13:09:34 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 4 Apr 2003 13:11:18 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 4 Apr 2003 13:11:17 +0200 Date: Fri, 4 Apr 2003 13:11:15 +0200 Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zinin@psg.com, ipng@sunroof.eng.sun.com To: Bill Manning From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <200304041049.h34An0g03475@boreas.isi.edu> Message-Id: <26A08100-668E-11D7-81E1-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 04 Apr 2003 11:11:17.0829 (UTC) FILETIME=[EA0AF750:01C2FA9A] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On fredag, apr 4, 2003, at 12:49 Europe/Stockholm, Bill Manning wrote: > based on your concerns, listed > above, IPv6 is going to be nothing more than IPv4 with larger address > space. if that is what we end up with, then IPv6 development might > be considered a waste of time. I don't think IPv6 will be (much) more than IPv4 with larger address space, BUT, that is not a small thing. It is something that would be really really nice to have. I am tired on writing ton of paper to my local ISP, which add tons of paper and send to their upstream provider which send something to RIPE NCC, which respond, and then 15 roundtrips later and two renumberings of the local network I might expand my /28 to a /27. I am tired of this! I am tired on not being able to give real IP addresses to guests which visit me. I am tired on not being able to give real IP addresses to my IP phone. I am just so incredible tired. So I want IPv6, even if it is *just* IPv4 with larger address space. For really different Internet, I think we need something like: - Real differentiation between routing identifier and globally unique addressing identifier for a node (and not use one IP address for both) - The ability to change the routing identifier during flight - Routing protocol(s) which really is tuned to the fact that the Internet is a mesh and not a hierarchy anymore - ...and many more things... As Harald wrote: > Note: By "Deprecate Site-Local", I mean "Do not require any > application, host, router, protocol or IETF practice to have to make > special consideration for the idea that an IPv6 unicast address > outside of the link-local range can refer to two different hosts". We need to, until we have better mechanisms overall, make sure we keep applications so they can deal with addressing, while the network take care of the routing. Mixing will not work. Especially as we don't have real solutions to the real problems. So, when I say I want Site Local deprecated I mean I want routing and addressing separated, and given that separation, we have to work on solving the real problems we have with Internet today. paf -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 03:38:35 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 h34BcYPL026778; Fri, 4 Apr 2003 03:38:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34BcYc1026777; Fri, 4 Apr 2003 03:38: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.9+Sun/8.12.9) with ESMTP id h34BcUPL026770 for ; Fri, 4 Apr 2003 03:38: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 h34BcWS09042; Fri, 4 Apr 2003 13:38:32 +0200 (MEST) Date: Fri, 4 Apr 2003 13:38:28 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: site-locals To: alh-ietf@tndh.net Cc: "'Erik Nordmark'" , john.loughney@nokia.com, lear@cisco.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <0a8101c2fa08$867ee260$ee1a4104@eagleswings> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It is not a red herring. Input sent to me for the requirements doc: But this case is exactly the same as what I categorized as #1 in my list - isolating communication local to the site from site renumbering. The only added twist is that site renumber occurs when the site attaches and detaches from the Internet. > Research ships at sea intermittently connect via INMARSAT, or when in > port, the shipboard network is connected to shore via Ethernet. Looking at your resarch ship case a bit more in detail it occurs to me that even using site-locals plus globals while connected doesn't necessarily protect the local communication. The introduction of the global prefix/addresses when the ship is connected might very well trigger different address selection behaviors in the stack or in the applications. Thus it seems like the robustness provided by site-locals only apply to communication established (and addresses selected) before the global prefix is introduced. Later communication is subject to any bugs or poor interaction in the address selection domain - something that is bound to have some corner cases due to its complexity. (Note that this is a property that applies to #1 in my list that I've previously not realized.) While the effect of this probably is less than the effect of renumbering the ships network each time it attaches to the Internet, it still doesn't isolate the ships internal network from being attached to the Internet when site-locals are used as you propose. So if I were to design this ship I'd use neiether renumbering at attachment time nor site-locals. Instead I'd have the research ship get a stable prefixe (a few /64's might suffice) from the organization that runs it which are globally unique and can be used whether the ship is connected or disconnected. This completely isolates the addressing of the ship internals from whether it is connected or disconnected; the only difference is the when disconnected off-ship destinations are unreachable. When it gets connected tunnel(s) need to be established back to the research organization in order for routing to work. Such tunnels could be cobbled up today with some existing tunnel establishment mechanism, and the Nemo WG is working on an IETF standard for such tunnel establishment. So if you want internal stability you have to pay by having less efficient routing - going bidirectionally over the tunnel to "home" - no free lunch. If you believe in Mobile IPv6 route optimization you might also believe that the Nemo work can be extended to provide route optimization to/from correspondent nodes in the Internet at large (by reusing the MIPv6 approach). I personally think the utility of this remains to be proven, but if it is it would help with the routing inefficiencies caused by routing. So once again, this is not a case where I think site-locals help. 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 Apr 4 03:44: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 h34BicPL026937; Fri, 4 Apr 2003 03:44:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34BicLw026936; Fri, 4 Apr 2003 03: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 h34BiZPL026929 for ; Fri, 4 Apr 2003 03: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 h34BigHP015805 for ; Fri, 4 Apr 2003 03:44:42 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA00373 for ; Fri, 4 Apr 2003 04:44: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; Fri, 4 Apr 2003 11:44: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; Fri, 4 Apr 2003 11:41: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; Fri, 4 Apr 2003 11:44:35 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; Fri, 4 Apr 2003 11:44:34 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h34BiQDI032880; Fri, 4 Apr 2003 13:44:26 +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 h34BiPcM271682; Fri, 4 Apr 2003 13:44:25 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34000 from ; Fri, 4 Apr 2003 13:44:23 +0200 Message-Id: <3E8D7045.C9742355@hursley.ibm.com> Date: Fri, 04 Apr 2003 13:45:09 +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: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-flow-label-06.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks Pekka. We did get a few private comments on the revised security considerations from Ran Atkinson, and we forgot to acknowledge your comments, so a quick -07 revision is needed, and then we can ask the chairs whether they are ready to declare consensus. Brian Pekka Savola wrote: > > A diversion from the site-local debacle.. :-) > > On Tue, 25 Mar 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 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. > > This satisfies my concerns for security considerations. > > I still disagree on the issue on API, but that's acceptable. Let's see > what the community thinks about it. > > The two editorial/semi-editorial nits against the last version are still > valid; however, they weren't critical and can be corrected in future > revisions if appropriate. > > I think sending this off to the IESG would be appropriate. > > -- > 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 Apr 4 04:15: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 h34CFvPL027546; Fri, 4 Apr 2003 04:15:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34CFv33027545; Fri, 4 Apr 2003 04:15: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 h34CFrPL027538 for ; Fri, 4 Apr 2003 04:15:54 -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 h34CG1HP021937 for ; Fri, 4 Apr 2003 04:16:01 -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.3p2+Sun/8.9.3) with ESMTP id FAA17849 for ; Fri, 4 Apr 2003 05:15:56 -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, 4 Apr 2003 12:15:55 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, 4 Apr 2003 12:15: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; Fri, 4 Apr 2003 12:15:55 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; Fri, 4 Apr 2003 12:15:55 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 NAA29096 for ; Fri, 4 Apr 2003 13:15:53 +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 NAA29993 for ; Fri, 4 Apr 2003 13:15:53 +0100 (BST) Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h34CFrn10423 for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 13:15:53 +0100 Date: Fri, 4 Apr 2003 13:15:53 +0100 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: site-locals Message-Id: <20030404121553.GL30669@ecs.soton.ac.uk> References: <0a8101c2fa08$867ee260$ee1a4104@eagleswings> 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 Fri, Apr 04, 2003 at 01:38:28PM +0200, Erik Nordmark wrote: > > Research ships at sea intermittently connect via INMARSAT, or when in > > port, the shipboard network is connected to shore via Ethernet. > > Looking at your resarch ship case a bit more in detail it occurs > to me that even using site-locals plus globals while connected doesn't > necessarily protect the local communication. The introduction of the > global prefix/addresses when the ship is connected might very well > trigger different address selection behaviors in the stack or in the > applications. Thus it seems like the robustness provided by site-locals > only apply to communication established (and addresses selected) > before the global prefix is introduced. Later communication is subject > to any bugs or poor interaction in the address selection domain - something > that is bound to have some corner cases due to its complexity. > (Note that this is a property that applies to #1 in my list that I've > previously not realized.) While the effect of this probably is less than > the effect of renumbering the ships network each time it attaches to the > Internet, it still doesn't isolate the ships internal network from > being attached to the Internet when site-locals are used as you propose. I think site-locals could be used here, with a single rule that they're simply the least preffered prefix used in address selection. Whilst the boat is in a port, it receives a global prefix which is advertised on appropriate subnets. Before leaving port the prefix is deprecated (but not removed), thus there would be no break in communications. It can be removed several days later safely when it's no longer in use. This doesn't just apply to huge boats, what about a private yacht? This is another zero-conf issue, it has all the same problems as the research boat (getting connectivity via different providers depending on which port they're at) except that the owner may not have his own v6 prefix, or even know what IPv6 is! Finally I don't agree with your tunnelling solution at all (sorry it got ) . I would rather NAT and have a 10ms RTT insetad of 200ms, and if I would NAT here (I hate NAT!) then I think lots of other people would too. Tunnels are complicated NAT is easy... So I would argue that in this case deprecation of Site-locals *encourages* NAT, now there's something you don't hear every day! :-) 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 Fri Apr 4 05:14:18 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 h34DEIPL027992; Fri, 4 Apr 2003 05:14:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34DEIs5027991; Fri, 4 Apr 2003 05:14: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.9+Sun/8.12.9) with ESMTP id h34DEFPL027984 for ; Fri, 4 Apr 2003 05:14: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 h34DEMHP003340 for ; Fri, 4 Apr 2003 05:14:22 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA25609 for ; Fri, 4 Apr 2003 06:14: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; Fri, 4 Apr 2003 13: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; Fri, 4 Apr 2003 13:14: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; Fri, 4 Apr 2003 13:14:13 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, 4 Apr 2003 13:14:12 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h34DE9DI034018; Fri, 4 Apr 2003 15:14:09 +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 h34DE8g9207056; Fri, 4 Apr 2003 15:14:08 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49512 from ; Fri, 4 Apr 2003 15:14:06 +0200 Message-Id: <3E8D854C.18E4388F@hursley.ibm.com> Date: Fri, 04 Apr 2003 15:14:52 +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: "Sellers, Julian P" Cc: ipng@sunroof.eng.sun.com Subject: Re: My Questions on Site-Locals References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Julian, I think the one problem we need to avoid is What do you do when two occurrences of FEC0::0001/64 exist within a single routing domain? This is the problem created by the current SL definition when two 'sites' are united by merger or VPN and they both happen to have a subnet #1. We shot ourselves in the foot by creating this problem in the initial IPv6 addressing architecture. Brian "Sellers, Julian P" wrote: > > Keith's multi-party applications won't work if the parties refer non-global > addresses to each other. Margaret recommends that everyone use global > addresses, but filter certain prefixes at various administrative boundaries. > How, then, do Keith's applications know which addresses have global scope > and which do not? > > A tacit assumption seems to be that applications will not have to deal with > link-local addresses. I'm aware of the recommendation not to place > link-local addresses in the DNS, but I know of no prohibition of > applications communicating via link-local addresses. If they may do so, is > this less problematic than using site-local addresses? > > Since I know nothing about filtering in routers, can someone tell me why > filtering on FEC0::/10 is more complex than filtering on prefixes chosen by > the local administrator(s)? And concerning Margaret's point on nesting > sites, could routers not filter within FEC0:0:subn:etid::/64 addresses? > > Again citing the disclaimer re my lack of knowledge, the > filtering-on-locally-designated-prefixes method seems unwieldy compared to > the filtering-on-well-known-scope method. Implementations can allow an > administrator to configure address scope preferences using the well-known > scopes. Nodes (applications) on the same subnet could then have addresses > of different scopes. This would be cumbersome at best without well-known > scopes. > > Some have complained about the complexity of always disambiguating > site-local addresses by means of their zone identifiers. This seems > insignificant to me; the same must be done for link-local addresses. The > zone identifier accompanies the address wherever it goes. Right? > > I understand that sites that merge would have to renumber if their subnet > IDs conflicted. Some have stated that a disconnected site using site-local > addresses must renumber when it connects to the Internet. Wouldn't the site > simply add the new prefix(es), and the nodes use the new addresses and/or > site-local addresses based on local configuration? Connections using > site-local addresses would not be affected by connection to the Internet. > > Since so many wise people object to site-local addressing, the problems must > be greater than they appear from behind these cube walls. But I have not > seen answers to these questions (or maybe I failed to comprehend). I look > forward to having my horizons expanded. > > Julian Sellers > Enterprise Server Communications Engineering > Unisys Corporation -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 05:31: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 h34DVBPL028475; Fri, 4 Apr 2003 05:31:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34DVBeO028474; Fri, 4 Apr 2003 05:31: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.9+Sun/8.12.9) with ESMTP id h34DV7PL028467 for ; Fri, 4 Apr 2003 05:31:07 -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 h34DVFHP006544 for ; Fri, 4 Apr 2003 05:31:15 -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.3p2+Sun/8.9.3) with ESMTP id GAA28412 for ; Fri, 4 Apr 2003 06:31: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; Fri, 4 Apr 2003 13:31: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; Fri, 4 Apr 2003 13:31: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; Fri, 4 Apr 2003 13:31:08 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, 4 Apr 2003 13:31:08 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h34DV5ju021200 for ; Fri, 4 Apr 2003 15:31:06 +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 h34DV5g9264114 for ; Fri, 4 Apr 2003 15:31:05 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61210 from ; Fri, 4 Apr 2003 15:30:58 +0200 Message-Id: <3E8D8941.C0CF8359@hursley.ibm.com> Date: Fri, 04 Apr 2003 15:31: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 Subject: Re: A different FEC0::/10 proposal References: <3E8D3F6D.3C780065@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This doesn't resolve the problem of ambiguous subnet prefixes when routing domains merge. So it doesn't go far enough IMHO. Brian Andrew White wrote: > > Let's ask a different question. Would the following be acceptable: > > ----- > The address space FEC0::/10 is reserved for non-global use. It is intended > not to be globally routeable. All routers MUST by default blackhole any > packet destined to FEC0::/10, and MAY return a 'destination unreachable' > message. > > 'Sites' using FEC0::/10 addresses MUST implement a filter at the 'site > border' that discards source or destination addresses in the FEC0::/10 > space. Routing protocols MUST NOT exchange reachability information > concerning FEC0::/10 across the border. > > Any router or node not explicitly configured to do otherwise MAY discard > (silently or otherwise) any packet with a source or destination address in > FEC0::/10 space. > > Applications MAY choose to treat FEC0::/10 addresses differently to other > addresses, and MAY prefer or disprefer them. Applications MAY assume that > FEC0::/10 addresses will be filtered before reaching the global internet. > > ----- > > This seems to cover the minimum requirements of the relevant parties. The > only global requirement is that all routers by default black-hole > FEC0::/10. If you choose to use site local addresses, then you come under > the border router requirements given in the second paragraph. > > The only bugbear I can see is source address selection. One easy solution > is to 'prefer closest match' to whatever destination address the application > selected, which will mean SL matches SL and link-local matches link local. > Ensuring non-SL matches non-SL may be slightly trickier, depending on > prefixes, though the current policy of allocating from 0000::/12 will prefer > global-global. > > And maybe something should be added to say "If you stick these things in a > globally accessible DNS, don't be surprised when connections to your hosts > fail." And maybe a policy to NXDOMAIN reverse lookups for > [C-F].E.F.in6.arpa. > > In short, there is almost no extra effort for those who don't implement SL > addresses - all the work is pushed to those who do. > > Notice that the above text says nothing about how FEC0::/10 addresses are to > be allocated. All it does is reserve the space as 'not globally routeable' > and put policies in place to stop this information getting where it > shouldn't. > > -- > 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 Fri Apr 4 05:37: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 h34DbQPL028736; Fri, 4 Apr 2003 05:37:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34DbPQq028735; Fri, 4 Apr 2003 05:37: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 h34DbMPL028728 for ; Fri, 4 Apr 2003 05:37:22 -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 h34DbPHP008024 for ; Fri, 4 Apr 2003 05:37:25 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id GAA06355 for ; Fri, 4 Apr 2003 06:37:19 -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, 4 Apr 2003 13: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; Fri, 4 Apr 2003 13:37: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; Fri, 4 Apr 2003 13:37:17 Z Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 13:37:17 Z Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h34DbGo21428 for ; Fri, 4 Apr 2003 05:37:16 -0800 Received: from innovationslab.net ([63.109.132.2]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h34DpDQe026739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 4 Apr 2003 05:51:14 -0800 Message-Id: <3E8D8A8A.3040802@innovationslab.net> Date: Fri, 04 Apr 2003 08:37:14 -0500 From: Brian Haberman 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: ipng@sunroof.eng.sun.com Subject: Re: My Thoughts on Site-Locals References: <963621801C6D3E4A9CF454A1972AE8F504F72B@server2000.arneill-py.sacramento.ca.us> In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F72B@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>and it isn't clear how we can ever finalize the scoped >>addressing architecture without some type of decision >>on this issue. Perhaps we can break out the >>non-contentious parts and advance those parts? > We need to break out some of it regardless. If everyone recalls, I pointed out that pieces of the scoped addressing architecture still needs to be done in order to support the scoped multicast addresses. > > I believe we can progress on three topics: > - Ambiguity > - Convexity / defining the site borders. > - Tuning the compromise. I can comment on the convexity issue. Section 5 of the scoped addressing architecture has the following: Each zone is required to be "convex" from a routing perspective, i.e., packets sent from one interface to any other interface in the same zone are never routed outside the zone. No one has objected to it. I have implemented the routing of scoped addresses. I can guarantee convexity in the protocol. Does it work? Yes. Is it a performance hit? Absolutely. And as Alex pointed out in another message, the complexity gets worse when scope boundaries have to be reflected in area borders. > Unfortunately this requires people that are for IPv6 and not against and > that are willing to compromise. I regret to report that at this point I > count only three: Bob Hinden, you and me. Quite an insulting comment. 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 Fri Apr 4 05:51: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 h34DpbPL029203; Fri, 4 Apr 2003 05:51:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34Dpbb4029201; Fri, 4 Apr 2003 05: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h34DpUPL029187 for ; Fri, 4 Apr 2003 05:51: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 h34DpcHP011010 for ; Fri, 4 Apr 2003 05:51: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-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA11673 for ; Fri, 4 Apr 2003 05:51:32 -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, 4 Apr 2003 13:51:22 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, 4 Apr 2003 13:51: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; Fri, 4 Apr 2003 13:51:21 Z Received: from p-mail2 ([193.49.124.32] [193.49.124.32]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 13:51:21 Z Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail2 with InterScan Messaging Security Suite; Fri, 04 Apr 2003 15:56:39 +0200 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 4 Apr 2003 15:51:11 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: nostalgic ( was RE: CONSENSUS CALL: Deprecating Site-Local Addressing) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Fri, 4 Apr 2003 15:51:11 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CONSENSUS CALL: Deprecating Site-Local Addressing Thread-Index: AcL6mRFc9e4Jm79pRzeDOSqEZrJ9YQAFSBxg From: "BAUDOT Alain FTRD/DMI/CAE" To: "Bill Manning" Cc: X-OriginalArrivalTime: 04 Apr 2003 13:51:11.0948 (UTC) FILETIME=[409558C0:01C2FAB1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h34DpVPL029188 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > waxing nostalgic... IPv6 was supposed to be an enabler > of a whole > raft of interesting new capabilities. based on your > concerns, listed > above, IPv6 is going to be nothing more than IPv4 with > larger address > space. if that is what we end up with, then IPv6 > development might > be considered a waste of time. we could support the > premise of IPv6 > (10x16th nodes...?) using Paul Francis's nifty idea of > a box that will > do address translation and never need to move away from > a 32bit address > space. > > IPv6 had (and perhaps still has) the ability to allow > us to develop > alternative routing techniques, where aggregation is > not the only > abstraction that is viable. > > For me the vote (and it is a vote...) seems to break > down along these > lines: > > Yes - those who wish to maintain the status quo or have > vested commercial > interests in shipping IPv6 product. > No - those who wish to explore the latent capabilities of IPv6. > > as usual, YMMV and my understanding is likely flawed. > > I share this comment... I'd like IPv6 to become more than IPv4 with longer addresses and without NAT. 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 Apr 4 05:54: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 h34Ds3PL029337; Fri, 4 Apr 2003 05:54:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34Ds2vu029336; Fri, 4 Apr 2003 05:54: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.9+Sun/8.12.9) with ESMTP id h34DrwPL029320 for ; Fri, 4 Apr 2003 05:53:58 -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 h34Ds5cU015128 for ; Fri, 4 Apr 2003 05:54:05 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id GAA15507 for ; Fri, 4 Apr 2003 06:53: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; Fri, 4 Apr 2003 13:53: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; Fri, 4 Apr 2003 13:53: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; Fri, 4 Apr 2003 13:53:49 Z Received: from batch11.uni-muenster.de (batch11.uni-muenster.de [128.176.188.109]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 13:53:48 Z Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch11.uni-muenster.de (Postfix) with ESMTP id 1F46110E2; Fri, 4 Apr 2003 15:53:45 +0200 (MES) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 56850312DE; Fri, 4 Apr 2003 15:53:44 +0200 (CEST) Received: from LEMY.UNI-MUENSTER.DE (LEMY.UNI-MUENSTER.DE [128.176.184.238]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id B58D2312C7; Fri, 4 Apr 2003 15:53:43 +0200 (CEST) From: "Christian Schild (JOIN Project Team)" Reply-To: join@uni-muenster.de Organization: Westfaelische Wilhelms-Universitaet To: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: My Questions on Site-Locals Date: Fri, 4 Apr 2003 15:53:44 +0200 User-Agent: KMail/1.5 References: <3E8D854C.18E4388F@hursley.ibm.com> In-Reply-To: <3E8D854C.18E4388F@hursley.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304041553.44182.ipng@uni-muenster.de> X-Virus-Scanned: by AMaViS 0.3.12pre7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Am Freitag, 4. April 2003 15:14 schrieb Brian E Carpenter: > What do you do when two occurrences of FEC0::0001/64 exist > within a single routing domain? > > This is the problem created by the current SL definition when > two 'sites' are united by merger or VPN and they both happen > to have a subnet #1. > > We shot ourselves in the foot by creating this problem in the > initial IPv6 addressing architecture. Do we really have to think about this? Is this an architectural design problem? Is it enough to drop the whole concept? I think it would be enough to come up with a BCP how to subdivide bits 11-48 in an intelligent way to prevent above. There were lots of ideas how this could be done on this list. Christian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 06:12: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 h34EC1PL000382; Fri, 4 Apr 2003 06:12:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34EC1QE000381; Fri, 4 Apr 2003 06:12: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.9+Sun/8.12.9) with ESMTP id h34EBvPL000371 for ; Fri, 4 Apr 2003 06:11: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 h34EC5cU019838 for ; Fri, 4 Apr 2003 06:12: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.3p2+Sun/8.9.3) with ESMTP id GAA24726 for ; Fri, 4 Apr 2003 06:11:59 -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, 4 Apr 2003 14:11: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; Fri, 4 Apr 2003 14:11:58 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, 4 Apr 2003 14:11:58 Z Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 14:11:57 Z Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h34EBto21550 for ; Fri, 4 Apr 2003 06:11:55 -0800 Received: from innovationslab.net ([63.109.132.2]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h34EPrQe026948 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 4 Apr 2003 06:25:54 -0800 Message-Id: <3E8D92A9.1080102@innovationslab.net> Date: Fri, 04 Apr 2003 09:11:53 -0500 From: Brian Haberman 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: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs References: <200304040139.h341dSh07349@cichlid.adsl.duke.edu> In-Reply-To: <200304040139.h341dSh07349@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > Hi James. > > >>However, I believe some of the resistance to deprecation may be the >>result of people who have implementations and would rather not have >>to pay the costs of ripping out that code and putting in something >>new. > > > This I don't understand. AFAIK, there is little or no code to rip > out. And if the code is there, but no site-locals are actually > configured or assigned to nodes, any code related to site-locals > doesn't get executed and is harmless. So I don't see what problem > there is with deprecating them with regards to existing > implementations. I don't imagine anyone is going to say we need to put > wording in some spec that makes existing implementations that have > code related to site-locals be declared non-conformant. That would be > silly. > > Do folks think this above is a significant issue? So, as most of you probably know, I have implemented a router that supports scoped addresses (unicast and multicast). If I still supported that box, I would be quite happy to rip the support out. If someone wants to see a presentation on what I did, go find the proceedings from the routing area meeting in Atlanta. I can see where implementations like John Bartas' could have support issues when customers can't align code with RFCs. But, I would rather deal with that scenario than trying to debug operational problems with site locals. I would like to hear from other people who have actually implemented SL support, and I mean ALL of the support (routing/forwarding, apps, dns, firewalls, mobility, etc.). 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 Fri Apr 4 06:19: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 h34EJcPL000684; Fri, 4 Apr 2003 06:19:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34EJcf4000683; Fri, 4 Apr 2003 06:19: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 h34EJYPL000673 for ; Fri, 4 Apr 2003 06:19: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 h34EJgHP018061 for ; Fri, 4 Apr 2003 06:19:42 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id HAA06945 for ; Fri, 4 Apr 2003 07:19: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; Fri, 4 Apr 2003 14:19: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; Fri, 4 Apr 2003 14:19: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; Fri, 4 Apr 2003 14:19:34 Z Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 14:19:33 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h34EJVju031208 for ; Fri, 4 Apr 2003 16:19:31 +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 h34EJVcM279696 for ; Fri, 4 Apr 2003 16:19:31 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60184 from ; Fri, 4 Apr 2003 16:19:29 +0200 Message-Id: <3E8D94A0.39944BA3@hursley.ibm.com> Date: Fri, 04 Apr 2003 16:20:16 +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: My Questions on Site-Locals References: <3E8D854C.18E4388F@hursley.ibm.com> <200304041553.44182.ipng@uni-muenster.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Christian Schild (JOIN Project Team)" wrote: > > Brian, > > Am Freitag, 4. April 2003 15:14 schrieb Brian E Carpenter: > > What do you do when two occurrences of FEC0::0001/64 exist > > within a single routing domain? > > > > This is the problem created by the current SL definition when > > two 'sites' are united by merger or VPN and they both happen > > to have a subnet #1. > > > > We shot ourselves in the foot by creating this problem in the > > initial IPv6 addressing architecture. > > Do we really have to think about this? Is this an architectural design > problem? Is it enough to drop the whole concept? The architecture today specifies ambiguous subnet prefixes. > > I think it would be enough to come up with a BCP how to subdivide bits > 11-48 in an intelligent way to prevent above. There were lots of ideas how > this could be done on this list. But that is not what the addressing architecture describes today, and that is where my problem is, not with some future specification. 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 Apr 4 06:29: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 h34ETqPL001189; Fri, 4 Apr 2003 06:29:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34ETpdN001184; Fri, 4 Apr 2003 06:29: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 h34ETjPL001167 for ; Fri, 4 Apr 2003 06:29: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 h34ETqcU028766 for ; Fri, 4 Apr 2003 06:29:52 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id HAA08236 for ; Fri, 4 Apr 2003 07:29: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; Fri, 4 Apr 2003 14:29: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; Fri, 4 Apr 2003 14:29: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; Fri, 4 Apr 2003 14:29:44 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; Fri, 4 Apr 2003 14:29:44 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA11785; Fri, 4 Apr 2003 06:29:18 -0800 (PST) Message-Id: <5.1.0.14.2.20030404091002.03c8f638@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 04 Apr 2003 09:27:51 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: My Thoughts on Site-Locals Cc: In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F72B@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, At 04:39 PM 4/3/2003 -0800, Michel Py wrote: >Unfortunately this requires people that are for IPv6 and not against and >that are willing to compromise. I regret to report that at this point I >count only three: Bob Hinden, you and me. I find this statement highly offensive, and I completely disagree with your assessment of the IPv6 WG. There are scores, probably hundreds, of people who care about IPv6 and want it to succeed. We have spent years working on difficult issues, sometimes disagreeing, but always finding a way forward. We may currently have some disagreement regarding the value of site-local unicast addressing, but we _will_ find a way to work through this issue. It should be possible for us to disagree on a technical issue without questioning each other's integrity, competence or commitment to IPv6. The classic decision making process goes: Disagree -> Decide -> Commit -> Execute We are currently in the "disagree" stage for site-locals, so it is good that people are voicing their own opinions and stating technical reasons to support those positions. We are trying to drive towards a decision. And, once we do make a decision about how to proceed, I believe that it will be followed (as difficult decisions in IPv6 always have been) by a high degree of commitment and execution. 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 Fri Apr 4 06:40: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 h34EeHPL001498; Fri, 4 Apr 2003 06:40:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34EeHUR001497; Fri, 4 Apr 2003 06:40: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.9+Sun/8.12.9) with ESMTP id h34EeEPL001490 for ; Fri, 4 Apr 2003 06:40: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 h34EeLHP023489 for ; Fri, 4 Apr 2003 06:40:21 -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.3p2+Sun/8.9.3) with ESMTP id HAA12703 for ; Fri, 4 Apr 2003 07:40: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; Fri, 4 Apr 2003 14:40:13 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, 4 Apr 2003 14:40:13 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, 4 Apr 2003 14:40:13 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, 4 Apr 2003 14:40:13 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA17073; Fri, 4 Apr 2003 06:39:37 -0800 (PST) Message-Id: <5.1.0.14.2.20030404092959.03c9f830@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 04 Apr 2003 09:38:12 -0500 To: join@uni-muenster.de From: Margaret Wasserman Subject: Re: My Questions on Site-Locals Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: <200304041553.44182.ipng@uni-muenster.de> References: <3E8D854C.18E4388F@hursley.ibm.com> <3E8D854C.18E4388F@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Christian, At 03:53 PM 4/4/2003 +0200, Christian Schild (JOIN Project Team) wrote: >I think it would be enough to come up with a BCP how to subdivide bits >11-48 in an intelligent way to prevent above. There were lots of ideas how >this could be done on this list. We do need to define some method(s) to produce unique, local, provider-independent addresses (i.e. MAC address-based or registry-based). But, I don't think that we want those local addresses to have the semantics associated with site-local addressing, so I don't think that we should allocate them from the current site-local space (FECO::/10). Most of the restrictions and complexities associated with scoped addresses in the scoped addressing architecture (can't be nested, can't overlap, need zone IDs to disambiguate, etc.) are required _because_ site local addresses are ambiguous. If you remove the ambiguity, why would you want to live with the restrictions? Let's deprecate the current site-local prefix, and define a non-ambiguous model for local addressing. Unique local addresses can, generally, be treated just like any other addresses. As long as we make sure that our method of creating uniqueness retains the property that a longest prefix match will result in using local address to reach local addresses and global address to reach global addresses, we shouldn't need any special handling for these addresses in hosts or routers. 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 Fri Apr 4 06:48: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 h34EmXPL001758; Fri, 4 Apr 2003 06:48:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34EmXs7001757; Fri, 4 Apr 2003 06:48: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.9+Sun/8.12.9) with ESMTP id h34EmTPL001747 for ; Fri, 4 Apr 2003 06: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 h34EmbHP025558 for ; Fri, 4 Apr 2003 06:48: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.3p2+Sun/8.9.3) with ESMTP id GAA19363 for ; Fri, 4 Apr 2003 06:48: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; Fri, 4 Apr 2003 14:48:31 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, 4 Apr 2003 14: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; Fri, 4 Apr 2003 14:48:30 Z Received: from csnet1.cs.tsinghua.edu.cn (csnet1.cs.tsinghua.edu.cn [166.111.68.226]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 14:48:30 Z Received: (qmail 6544 invoked by uid 0); 4 Apr 2003 06:06:13 -0000 Received: from unknown (HELO liuhong) (192.168.1.193) by csnet1.cs.tsinghua.edu.cn with SMTP; 4 Apr 2003 06:06:13 -0000 Message-Id: <005701c2fab9$588489d0$c101a8c0@liuhong> From: "Hong LIU" To: Subject: How to configure an IPv6 multicast address in FreeBSD? Date: Fri, 4 Apr 2003 22:49:07 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id h34EmTPL001748 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I wonder to know how to configure an IPv6 multicast address in FreeBSD so that it could receive packets sent to the multicast address. Thank you for your help. Hong Liu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 08:27: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 h34GRYPL002999; Fri, 4 Apr 2003 08:27:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34GRYfh002998; Fri, 4 Apr 2003 08:27: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.9+Sun/8.12.9) with ESMTP id h34GRUPL002991 for ; Fri, 4 Apr 2003 08:27: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 h34GRYS07733; Fri, 4 Apr 2003 18:27:34 +0200 (MEST) Date: Fri, 4 Apr 2003 18:27:30 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: site-locals To: Mike Saywell Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20030404121553.GL30669@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 > I think site-locals could be used here, with a single rule that they're > simply the least preffered prefix used in address selection. > > Whilst the boat is in a port, it receives a global prefix which is > advertised on appropriate subnets. Before leaving port the prefix > is deprecated (but not removed), thus there would be no break in > communications. It can be removed several days later safely when it's > no longer in use. Tony's requirements seemed to say that ship-local communication must never break. I took that to mean imply in your example that the deprecated prefix can never be invalidated. And that would cause problems when the boat arrives in another port. > This doesn't just apply to huge boats, what about a private yacht? > This is another zero-conf issue, it has all the same problems as the > research boat (getting connectivity via different providers depending > on which port they're at) except that the owner may not have his own v6 > prefix, or even know what IPv6 is! Give specific requirements the way Tony did for the research ship and we can analyse the options. His requirement was that ship-local communication not be impacted by the ships connection and disconnection to the Internet. What requirements do you have in mind for the yacht? > Finally I don't agree with your tunnelling solution at all (sorry it > got ) . I would rather NAT and have a 10ms RTT insetad of 200ms, > and if I would NAT here (I hate NAT!) then I think lots of other people > would too. Tunnels are complicated NAT is easy... I think we have to agree that we disagree on that one. 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 Apr 4 08:30: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 h34GUNPL003045; Fri, 4 Apr 2003 08:30:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34GUNie003044; Fri, 4 Apr 2003 08: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h34GUJPL003037 for ; Fri, 4 Apr 2003 08:30:19 -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 h34GUOS08044; Fri, 4 Apr 2003 18:30:24 +0200 (MEST) Date: Fri, 4 Apr 2003 18:30:20 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: My Thoughts on Site-Locals To: Brian Haberman Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3E8D8A8A.3040802@innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Each zone is required to be "convex" from a routing > perspective, i.e., packets sent from one interface to any > other interface in the same zone are never routed outside > the zone. > > No one has objected to it. I have implemented the routing of > scoped addresses. I can guarantee convexity in the protocol. Brian, I thought the hard part about ensuring convexity wasn't about the routing protocol itself, but ensuring convexity in the forwarding of a packet with dst = global address assigned to site src = site local address For things to work such a packet must stay inside the site even though it's destination address is a global address. 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 Apr 4 08:30: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 h34GUdPL003058; Fri, 4 Apr 2003 08:30:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34GUcM5003054; Fri, 4 Apr 2003 08:30: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.9+Sun/8.12.9) with ESMTP id h34GUWPL003047 for ; Fri, 4 Apr 2003 08:30:32 -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 h34GUecU028979 for ; Fri, 4 Apr 2003 08:30:40 -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.3p2+Sun/8.9.3) with ESMTP id JAA00661 for ; Fri, 4 Apr 2003 09:30:34 -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, 4 Apr 2003 16:29: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; Fri, 4 Apr 2003 16:29: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; Fri, 4 Apr 2003 16:29:18 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 16:29:17 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 04 Apr 2003 08:29:15 -0800 Reply-To: From: "Tony Hain" To: "'Thomas Narten'" , "'Michel Py'" Cc: "'Margaret Wasserman'" , Subject: RE: My Thoughts on Site-Locals Date: Fri, 4 Apr 2003 08:29:17 -0800 Message-Id: <0b4001c2fac7$56f11030$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: <200304040236.h342aad09124@cichlid.adsl.duke.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h34GUXPL003048 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > ... > I've seen it now (somewhat independently) in the zeroconf WG > too, where similar issues have been discussed with LL > addressing for IPv4. There are plenty of people there that > don't see what is hard about scoping and that it's not a big > deal to make applications handle them. But over time, more > people have also come around to understanding that there are > issues, and there are problems with scoping. > > And if you go to applications people (that is, those folk > that spend their lives doing applications rather than stack > work) they seem much more concerned on average that scoped > addresses have significant (bad) implications for applications. This should not be surprising. Given that the applications community blindly assumes there is a single addressing scope, when they bump into the reality of the deployed network there will be problems. Proclaiming that scopes are bad for applications does not make the filtering that causes scopes go away. > > > Second, by your own account we do need to prepare documents > about what > > to do next. Call it deprecation if you want what I call it > is that we > > have more work to do on site-locals and on the scoped architecture. > > Clearly, that needs to be done. But there is a basic > chicken-and-egg problem. If the the WG isn't going to > deprecate SLs, why would anyone bother writing the document > calling for their deprecation? The purpose of the current > discussion is to figure out whether we should go to the next > steps of making changes in various documents. The discussion that should have happened first is 'what alternatives do we have to deal with the requirements that network managers are using SL to deal with?' Without a clear replacement, and with comments that some real problems are 'uninteresting', the network manager will insist on keeping the current tool. Once we provide alternatives that meet all of the requirements, nobody will care about keeping SL as currently defined. If we fail to meet all the requirements, there will still be a need for the current SL in those environments. There is no point in getting rid of SL now, only to reintroduce it later when we have failed to meet a set of requirements with viable alternatives. 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 Fri Apr 4 08:34:18 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 h34GYHPL003237; Fri, 4 Apr 2003 08:34:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34GYHoT003236; Fri, 4 Apr 2003 08:34: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.9+Sun/8.12.9) with ESMTP id h34GYDPL003220 for ; Fri, 4 Apr 2003 08:34: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 h34GYKcU000409 for ; Fri, 4 Apr 2003 08:34:20 -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.3p2+Sun/8.9.3) with ESMTP id IAA24811 for ; Fri, 4 Apr 2003 08:34:15 -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, 4 Apr 2003 16:34: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; Fri, 4 Apr 2003 16:30: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; Fri, 4 Apr 2003 16:34:08 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; Fri, 4 Apr 2003 16:34:08 Z Content-class: urn:content-classes:message Subject: RE: My Thoughts on Site-Locals MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 4 Apr 2003 08:34:06 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F731@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: My Thoughts on Site-Locals Thread-Index: AcL6gRjeDDo2NTmgQJWcXHZapNEEtwAQbB/A From: "Michel Py" To: "Alex Zinin" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h34GYDPL003221 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, > Alex Zinin wrote: > The problem or rather inconvenience with tieing site > boundaries and area/domain boundaries is that they > are driven by different factors. Imagine, for instance, > that your site that is currently implemented as an OSPF > area is growing so big that you need to split it into > multiple areas to give your routers a break. Because > your site boundaries are driven by non-routing > considerations (you just want your network to continue > working as it used to), you don't want to split the site > into two, so what you end up with is removing that big > site from the OSPF domain in a separate one and splitting > it into its own areas, while normally you would just have > one more area in the OSPF domain. Operationally, this > might be a headache. Agreed. I don't like the word "area" myself in this context; I was simply quoting Margaret's words. There are plenty of other cases like this, for example using two different IGPs as the result of a merger-never-finished-the-cleanup or related; I have seen a site where half of it was EIGRP the other half OSPF with mutual bidirectional redistribution and eBGP in the middle. :-( Mmmm thinking about it, :-) job security. Anyway, I suggested earlier that the site boundaries should be the administrative control boundaries of the organization. It might not be the correct wording, but my feeling is that we could come with some text that will detail the position of site boundaries. I have made the point earlier many times that the definition of "site" is ambiguous and/or imprecise, there is some geographical connotation attached to the word, we need a good definition anyway. >> This is the way I would do it anyway. I understand that we >> should not put restrictions when there is no need for them, >> but if putting a restriction allows something to work there >> is nothing wrong with it. > I don't think this is _the_ problem. This only contributes > to the list of complications. Also count modifications to > RIB, FIB management, the forwarding process, making pings, > traceroutes, etc site-aware... It's not impossible, in fact > we know exactly how to do this, it just that complexity adds > up to one side of the equation, and you really want to avoid > extra complexity in routing and below... I agree, but the other side of this coin is that if the feature is not implemented in the architecture it will be implemented by the configuration at the site. In other words, if as a site administrator I am not happy about the way the site-local traffic flows I am going to tweak it using route-maps, prefix-lists, route tags and whatever I feel like doing for my intra-site traffic engineering. Each site will end up being configured differently. Although there still is a lot of work to be done on the topic, I think that the convexity of the site is a good idea to incorporate in the architecture. In short: - If site convexity is not built-in the architecture, it might or might not work depending on implementation, network topology, etc. This will lead in many cases to manual policy routing config to make it work the may it should. - If site convexity is built-in the architecture, the only case where it would require manual policy routing config is if the site administrator wants to break convexity. I can't think of a reason but I'm sure they are some valid ones. As some others have commented, IPv6 is not only IPv4 with more bits. The issue of "automatic site convexity" is definitively a pain to implement in router code, but is also a feature that simplifies the life of network administrators and as such a factor of success for IPv6. 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 Apr 4 08:36: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 h34GaTPL003419; Fri, 4 Apr 2003 08:36:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34GaTtp003418; Fri, 4 Apr 2003 08:36: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.9+Sun/8.12.9) with ESMTP id h34GaPPL003408 for ; Fri, 4 Apr 2003 08:36:25 -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 h34GaXHP024475 for ; Fri, 4 Apr 2003 08:36:33 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA05227 for ; Fri, 4 Apr 2003 09:36: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; Fri, 4 Apr 2003 16:36:26 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP; Fri, 4 Apr 2003 16:33:08 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Fri, 4 Apr 2003 16:36:25 Z Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by relay11.sun.com with ESMTP; Fri, 4 Apr 2003 16:36:24 Z Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h34GaMo21933; Fri, 4 Apr 2003 08:36:22 -0800 Received: from innovationslab.net ([63.109.132.2]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h34GoLQe027775 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 4 Apr 2003 08:50:23 -0800 Message-Id: <3E8DB484.3000606@innovationslab.net> Date: Fri, 04 Apr 2003 11:36:20 -0500 From: Brian Haberman 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: Erik Nordmark CC: ipng@sunroof.eng.sun.com Subject: Re: My Thoughts on Site-Locals 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 Erik Nordmark wrote: >> Each zone is required to be "convex" from a routing >> perspective, i.e., packets sent from one interface to any >> other interface in the same zone are never routed outside >> the zone. >> >>No one has objected to it. I have implemented the routing of >>scoped addresses. I can guarantee convexity in the protocol. > > > Brian, > > I thought the hard part about ensuring convexity wasn't about the routing > protocol itself, but ensuring convexity in the forwarding of a packet > with > dst = global address assigned to site > src = site local address > > For things to work such a packet must stay inside the site even though > it's destination address is a global address. Correct. My statement was for the protocol, not the forwarding. That is why I made the follow-on comment about complexity. The next-hop interface's ifindex for the global destination address would have to be checked to ensure that it has the same zone ID as the interface on which the packet was received. So, it leads to more checks during forwarding AND requires the forwarding table to potentially maintain multiple next-hops for the global addresses. In other words, the global prefixes learned from within the site have to be "marked" so they don't get confused with prefixes learned from outside the site. 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 Apr 4 08:39:12 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 h34GdBPL003624; Fri, 4 Apr 2003 08:39:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34GdB8D003623; Fri, 4 Apr 2003 08:39: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.9+Sun/8.12.9) with ESMTP id h34Gd6PL003610 for ; Fri, 4 Apr 2003 08:39: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 h34GdAS09099; Fri, 4 Apr 2003 18:39:10 +0200 (MEST) Date: Fri, 4 Apr 2003 18:39:05 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: My Thoughts on Site-Locals To: Brian Haberman Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3E8DB484.3000606@innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Correct. My statement was for the protocol, not the forwarding. > That is why I made the follow-on comment about complexity. The > next-hop interface's ifindex for the global destination address > would have to be checked to ensure that it has the same zone ID > as the interface on which the packet was received. So, it leads > to more checks during forwarding AND requires the forwarding table > to potentially maintain multiple next-hops for the global addresses. I don't think that is sufficient. If all the entries in the RIB for the prefix point outside the site then you have no choice but to drop the packet on the floor. If the sender had used a global source the packet would have made it through. 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 Apr 4 08:41: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 h34Gf8PL003779; Fri, 4 Apr 2003 08:41:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34Gf8ZX003778; Fri, 4 Apr 2003 08:41: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 h34Gf3PL003759 for ; Fri, 4 Apr 2003 08:41:03 -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 h34GfBHP025918 for ; Fri, 4 Apr 2003 08:41:11 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA15247 for ; Fri, 4 Apr 2003 09:41: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; Fri, 4 Apr 2003 16:40: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, 4 Apr 2003 16:37: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; Fri, 4 Apr 2003 16:40:58 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; Fri, 4 Apr 2003 16:40:58 Z Content-class: urn:content-classes:message Subject: Consensus on vaporware (was RE: CONSENSUS CALL: Deprecating Site-Local Addressing) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 4 Apr 2003 08:40:57 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504568A@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: Consensus on vaporware (was RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Thread-Index: AcL6klP3yzdPhjkDQu+rv++01O7OCwANj1KA From: "Michel Py" To: "Harald Tveit Alvestrand" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h34Gf4PL003760 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Here is exactly why I say that this is a consensus on vaporware: > Harald Tveit Alvestrand wrote: > Note: By "Deprecate Site-Local", I mean [snip] Everyone has their own definition about what "Deprecate Site-Local" means. 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 Apr 4 08:41: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 h34GfKPL003820; Fri, 4 Apr 2003 08:41:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34GfJj1003812; Fri, 4 Apr 2003 08:41: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 h34Gf9PL003784 for ; Fri, 4 Apr 2003 08:41: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 h34GfGHP025946 for ; Fri, 4 Apr 2003 08:41: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.3p2+Sun/8.9.3) with ESMTP id IAA08599 for ; Fri, 4 Apr 2003 08:41:10 -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, 4 Apr 2003 16:39:04 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, 4 Apr 2003 16:39: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; Fri, 4 Apr 2003 16:39:04 Z Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 16:39:04 Z Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Fri, 4 Apr 2003 08:39:03 -0800 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 04 Apr 2003 08:39:02 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 4 Apr 2003 08:39:02 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 4 Apr 2003 08:39:02 -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); Fri, 4 Apr 2003 08:39:02 -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: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Date: Fri, 4 Apr 2003 08:39:01 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing) Thread-Index: AcL6O7KaUFykTmLRRqK0gPbDvRPC8QAjGPwA From: "Christian Huitema" To: Cc: "Nick 'Sharkey' Moore" , X-OriginalArrivalTime: 04 Apr 2003 16:39:02.0950 (UTC) FILETIME=[B35E4C60:01C2FAC8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h34Gf9PL003786 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > You don't get the point. If enough hosts come programmed to enforce > > scope restrictions, then the non compliant product ends up with a > > deployment headache and has to be fixed. This is basically the root of > > Internet standards -- enforcement by peer pressure. > > The Globally addressed peer hosts when a communicating host is > behind NAT are talking to another Global peer address at the NAT > agent. That is correct. The enforcement will not be by the remote site, except maybe if the remote site uses IPSEC. > This only requires complicity on the NAT box and the host, > not the peer communicator. The proposed requirement provides > no further burden to implementors than NATv4 systems. Your point is the mirror image of my argument. If a sufficient fraction of the hosts refuses to play along with the NAT, then the NAT will not be able to work. The laws of network physics are such that, if solution A (NAT) is broken, then the easiest next solution will be chosen (advertise a global prefix). The problem is that vendors of host software can only deliberately brake the NAT scenario if they have some "air cover", i.e. if the standard clearly says that communication between addresses of different scopes is prohibited. Which is why it should say so... -- 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 Fri Apr 4 08:57:02 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 h34Gv2PL005049; Fri, 4 Apr 2003 08:57:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34Gv2Sh005048; Fri, 4 Apr 2003 08:57: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.9+Sun/8.12.9) with ESMTP id h34GuwPL005041 for ; Fri, 4 Apr 2003 08:56: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 h34Gv6HP001700 for ; Fri, 4 Apr 2003 08:57:06 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA27409 for ; Fri, 4 Apr 2003 09:57: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; Fri, 4 Apr 2003 16:54:13 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP; Fri, 4 Apr 2003 16:50:55 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Fri, 4 Apr 2003 16:54:13 Z Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by relay11.sun.com with ESMTP; Fri, 4 Apr 2003 16:54:12 Z Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h34GsBo22014; Fri, 4 Apr 2003 08:54:11 -0800 Received: from innovationslab.net ([63.109.132.2]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h34H8AQe027855 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 4 Apr 2003 09:08:12 -0800 Message-Id: <3E8DB8B1.6080505@innovationslab.net> Date: Fri, 04 Apr 2003 11:54:09 -0500 From: Brian Haberman 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: Erik Nordmark CC: ipng@sunroof.eng.sun.com Subject: Re: My Thoughts on Site-Locals 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 Erik Nordmark wrote: >>Correct. My statement was for the protocol, not the forwarding. >>That is why I made the follow-on comment about complexity. The >>next-hop interface's ifindex for the global destination address >>would have to be checked to ensure that it has the same zone ID >>as the interface on which the packet was received. So, it leads >>to more checks during forwarding AND requires the forwarding table >>to potentially maintain multiple next-hops for the global addresses. > > > I don't think that is sufficient. > If all the entries in the RIB for the prefix point outside the site > then you have no choice but to drop the packet on the floor. > > If the sender had used a global source the packet would have made it > through. Yes. I agree that would happen. That is why it has an operational component as well. Lets say we have something like this: +------------ Internet -------------+ | | office1 ------ site local / ------- office2 global A node in office1 could communicate with a node in office2 using any combination of SLs and Globals (per the existing specs) as long as both offices were in the same site. Using your example of global dest and SL src, everything is fine until the internal link breaks. Now, the source node would get back a "scope exceeded" ICMP message when the router tries to send the packet over the Internet. So now the source picks a global src to go with the GL dest. The packet may get through unless the routers or firewalls drop it when they realize that the destination is really inside but isn't reachable. If it does get through, then the source may have sent sensitive information over the Internet without encrypting it. What I am saying is that the routing and forwarding can be made to work, but it is kludgy and a big impact on performance. 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 Apr 4 08: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 h34Gx8PL005126; Fri, 4 Apr 2003 08:59:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34Gx8sn005125; Fri, 4 Apr 2003 08: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 h34Gx4PL005118 for ; Fri, 4 Apr 2003 08:59: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 h34GxCHP002761 for ; Fri, 4 Apr 2003 08:59:12 -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.3p2+Sun/8.9.3) with ESMTP id IAA12320 for ; Fri, 4 Apr 2003 08:59: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; Fri, 4 Apr 2003 16:59: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; Fri, 4 Apr 2003 16:55: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; Fri, 4 Apr 2003 16:59:06 Z Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 16:59:06 Z Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Fri, 4 Apr 2003 08:59:02 -0800 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 04 Apr 2003 08:59:02 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 4 Apr 2003 08:59:01 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 4 Apr 2003 08:58:53 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Fri, 4 Apr 2003 08:58:52 -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: My Thoughts on Site-Locals Date: Fri, 4 Apr 2003 08:58:52 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: My Thoughts on Site-Locals Thread-Index: AcL6yIBSPHLCmNLVSJucy38SP0TAtwAAGHxA From: "Christian Huitema" To: , "Thomas Narten" , "Michel Py" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 04 Apr 2003 16:58:52.0511 (UTC) FILETIME=[7866E6F0:01C2FACB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h34Gx5PL005119 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This should not be surprising. Given that the applications community > blindly assumes there is a single addressing scope, when they bump into > the reality of the deployed network there will be problems. Proclaiming > that scopes are bad for applications does not make the filtering that > causes scopes go away. Bad, bad application developers. We should really punish them! :-) Seriously, application developers face some very real problems. The issues are uniqueness in space and uniqueness in time. The space dimension is experienced when a host is connected to several sites, e.g. home network and VPN. If the application receives a site local address from a local name service or a local discovery service, it must associate that address with a site identifier. The first stumbling block is that most applications don't have this concept, they just copy the address. The second stumbling block is that there are no readily available site identifiers -- you would need to manage a unique name space, which is precisely what you don't get from FFC0::/10. In the absence of site identifier, the routing of connections to the proper site is haphazard. The application is supposed to remember that the site local address was learned through a specific site, i.e. only use in site X the site local addresses learned from site X's DNS service. This become quickly very hairy, as the DNS does not in fact have a concept of site. Restricting hosts to handle exactly one site removes some of the problem. But you then bump into the time dimension. Hosts may become members of different sites at different times, e.g. a laptop moving from the office to the airport or to the home. Addresses learned in one site should not be used in the next, but for that you must have an easy way to tell that you have changed sites. Without a site identifier, that can be real hard. Tony, these problems are not theoretical. They come very much on top of the issues encountered by developers porting applications to IPv6. Using unambiguous addresses solves a lot of the problems: a multi homed site can route connections to the proper site, source address selection can work, and moves to another site can be detected. There are remaining issues, notably dealing with intermittent connectivity, but these issues are inherent to any mobility scenario. By the way, link local addresses tend to suffer from much of the same issue. However, it is easier for applications to deal with LL addresses, as there is a clear linkage between addresses and discovery protocols operating in a single link. -- 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 Fri Apr 4 09:07:16 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 h34H7FPL005764; Fri, 4 Apr 2003 09:07:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34H7FsS005763; Fri, 4 Apr 2003 09:07: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.9+Sun/8.12.9) with ESMTP id h34H7BPL005753 for ; Fri, 4 Apr 2003 09:07:11 -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 h34H7JHP005998 for ; Fri, 4 Apr 2003 09:07: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.3p2+Sun/8.9.3) with ESMTP id KAA16414 for ; Fri, 4 Apr 2003 10:07: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; Fri, 4 Apr 2003 17:07:11 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, 4 Apr 2003 17:07: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; Fri, 4 Apr 2003 17:07:11 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 17:07:10 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 04 Apr 2003 09:07:10 -0800 Reply-To: From: "Tony Hain" To: "'Thomas Narten'" , "'Dan Lanciani'" Cc: Subject: RE: Why I support deprecating SLs Date: Fri, 4 Apr 2003 09:07:15 -0800 Message-Id: <0b4f01c2facc$a4665f00$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: <200304040258.h342wtS09167@cichlid.adsl.duke.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h34H7CPL005754 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > Dan Lanciani writes: > > > I can't speak for others, but to me it is very interesting (and > > important) to have internal connections that are not at the > mercy of > > my ISP's renumbering policy. > > I agree that this is a very desirable property to have. But > wanting this doesn't mean we know how to achieve it. Then why insist on taking away the current tool that does achieve it? If we don't have a viable replacement that works at least as well, it is irresponsible to deprecate the tool that currently does the job. > > > |The tough question is, how do we get applications in general to > > |prefer SLs for local communication. > > > If an application wants to maximize the stability of its > connection it > > always uses the addresses of smallest scope that will do the job. > > How do applications get addresses? In my experience, a lot of > them get them out of the DNS. But, if we put SLs into the > DNS, we have to have split DNS... We need to do that anyway, because there is no valid reason to leak filtered addresses outside of their scope of routability. Ambiguity is the ruse that is use to make this an issue, but the real issue is that resolving a name to an address that is not routable from that point is a broken concept. Even if a site uses global scope addresses for its internal use nodes & applications, a name resolution that includes both filtered and unfiltered addresses will cause applications that falsely assume a single address scope to fail. > ... > > Well, personally, I'm getting a little tired of worrying > about what is > > and is not blessed. People will use what works. > > I take it from the above that you believe that making split > DNS work is trivial and obvious, so folks can and will just > use it no problem. My point is that the community doesn't > seem to be in complete agreement about that, which means > there are almost certainly subtleties and potential gotchas > that can and will get in the way. If it were just trivial and > obvious how to do this, I somehow doubt folk would have > issues with split DNS. >From my observations, the IETF DNS community considers the reality of route filtering to be the edge of their flat-earth. What that perspective misses is that there are nodes that live in both worlds and need tools for a view that matches the network reality. From RFC 791: The function or purpose of Internet Protocol is to move datagrams through an interconnected set of networks. 'Interconnected' does not say without filtering, so if the IETF is responsible for the Internet Protocol and the associated infrastructure, it should also be responsible for defining infrastructure components that match the reality of the deployed network. > > > That said, I see no need to use split DNS in order to benefit from > > site-local's stable internal connections. As an example, my own > > network already uses separate names for the automation > services that > > are accessed internally. Currently these are aliases for > the global > > v4 addresses of the hosts which support the services. Under v6 I > > could change them to the site-local addresses of those same > machines. > > So, in your system you have two names for the same service, > one for the global address, one for the internal address? And > if you are inside your site, you use the internal name, and > when you are outside you use the external name? > > If this is the basic idea, I suspect most users won't like > this approach and will not consider it to have solved the > problem acceptably. You are probably correct about most users, but the job still needs to be done and if the IETF only gives you a hammer ... > ... > I've seen people say they think SLs are important to protect > internal communication for years. The problem is I still > don't see a coherent proposal for how this can be made to > work in practice that seems to solve the problem in a > reasonable way for a broad class of users. Back to back internal/external servers with a replication process that ignores records with the local prefix. It is more expensive, but I haven't seen any arguments that it raises technical concerns. Setting that up for a broad class of users that includes consumers would most likely require a consistent local use prefix for the replication process to key off of. 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 Fri Apr 4 09:13:02 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 h34HD2PL006056; Fri, 4 Apr 2003 09:13:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34HD13n006055; Fri, 4 Apr 2003 09:13: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.9+Sun/8.12.9) with ESMTP id h34HCwPL006045 for ; Fri, 4 Apr 2003 09:12: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 h34HD5HP008066 for ; Fri, 4 Apr 2003 09:13: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.3p2+Sun/8.9.3) with ESMTP id KAA09687 for ; Fri, 4 Apr 2003 10:13: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; Fri, 4 Apr 2003 17:12:59 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, 4 Apr 2003 17:12:59 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, 4 Apr 2003 17:12:58 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; Fri, 4 Apr 2003 17:12:58 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 h34HCuOc020475 for ; Fri, 4 Apr 2003 20:12:56 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h34HCuPO020471; Fri, 4 Apr 2003 20:12:56 +0300 Date: Fri, 4 Apr 2003 20:12:56 +0300 Message-Id: <200304041712.h34HCuPO020471@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com In-reply-to: <3E8DB484.3000606@innovationslab.net> (message from Brian Haberman on Fri, 04 Apr 2003 11:36:20 -0500) Subject: Re: My Thoughts on Site-Locals References: <3E8DB484.3000606@innovationslab.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I thought the hard part about ensuring convexity wasn't about the routing > protocol itself, but ensuring convexity in the forwarding of a packet > with > dst = global address assigned to site > src = site local address I must be missing something. There is really nothing hard about it, as far as I can see. When packet comes in from a interface A, you pick scope ids from that inteface (or just remember where it came from) and get dst, id-A[global] (well, for global not techinally needed) src, id-A[site] Then you forward the packet normally with "dst", and find it lands on interface B. The only additional test to do is: if (id-A[site] != id-B[site]) drop packet/or icmp out of scope. This is clearly explained in scoping architecture, I thought. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 09:26: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 h34HQNPL006724; Fri, 4 Apr 2003 09:26:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34HQN0p006723; Fri, 4 Apr 2003 09:26: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 h34HQJPL006716 for ; Fri, 4 Apr 2003 09:26:19 -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 h34HQQHP012597 for ; Fri, 4 Apr 2003 09:26:27 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA17934 for ; Fri, 4 Apr 2003 10:26:21 -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, 4 Apr 2003 17:26: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; Fri, 4 Apr 2003 17:23: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; Fri, 4 Apr 2003 17:26:20 Z Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 17:26:19 Z Received: from tom3 (1Cust242.tnt30.lnd3.gbr.da.uu.net [62.188.122.242]) by pengo.systems.pipex.net (Postfix) with SMTP id 6FDE24C0018E; Fri, 4 Apr 2003 18:26:15 +0100 (BST) Message-Id: <002001c2face$cd2ed280$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: , "Margaret Wasserman" Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Fri, 4 Apr 2003 18:20:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do not deprecate site-local unicast addressing. They are needed for access control in enterprise (as opposed to home/private use) networks Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: Margaret Wasserman To: ipng@sunroof.eng.sun.com Date: 01 April 2003 21:03 Subject: CONSENSUS CALL: Deprecating Site-Local Addressing > >Hi All, > >At the IPv6 WG meetings in SF, we reached consensus on several >points, all of which will be confirmed on the IPv6 mailing list. >One point in particular seems to be the source of discussion >on our list and elsewhere, so we will check this consensus on the >mailing list now. Specifically, we would like to check the consensus >of the IPv6 WG regarding the deprecation of site-local addresses. > >This email asks those that were NOT present at the Thursday IPv6 >meeting in SF to express their opinions on a question that was >asked of the room. If you expressed an opinion on this issue in >SF you can skip this message; in any case you MUST NOT respond to >this query. > >By now, all of you have heard about the IPv6 meeting held on >Thursday, March 20th, where we discussed what to do about >IPv6 site-local addressing. > >At the meeting, the chairs (Bob Hinden and Margaret Wasserman) >changed the agenda to include a joint presentation by the >chairs on various options for site-local usage. There were >no objections to the agenda change. > >The chairs' joint presentation can be found at: > >http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt > >After the chairs' joint presentation, there was over an hour of >lively discussion that covered many aspects of site-local >addressing. Draft minutes of the discussion can be found at: > >http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt > >These minutes are a summary of the discussion, and they did >not capture every detail of the discussion. > >During the discussion, it became clear that the "exclusive" model >proposed by the chairs had some fundamental flaws and was not >a viable option. The WG was unwilling to choose between the three >options presented for site-local usage ("limited", "exclusive" or >"moderate"), believing that all three models represented a poor >cost vs. benefit trade-off. And, as the discussion developed, it >became clear that there was growing support for deprecating >site-local addressing. > >After the usual discussion regarding the phrasing and meaning >of the question (not all of which was captured in the minutes), >the chairs asked a yes/no question: "Should we deprecate IPv6 >site-local unicast addressing?" There was clear consensus in the >room to deprecate site-local addressing. So, now it is time to >check that consensus on the mailing list. > >In order to get a good read for consensus on this point, PLEASE >adhere to the following rules: > >NOTE: DO NOT reply if you already expressed an opinion during >the IPv6 WG meeting in SF! > > - Make your response very clear (YES or NO). > - Respond by Monday, April 7th, 2003 at 5pm EST. > - Do NOT respond if you were physically present > in SF and participated in the consensus > call at that time (We are trusting you!). > - Respond to this thread with the subject intact. > - Respond only once. > - Clearly identify yourself (in the From: line or > inside your message). > - Include the IPv6 WG mailing list in your response > (ipng@sunroof.eng.sun.com). > - PLEASE do NOT start any discussion in this thread > (Discussions are encouraged in other threads). > >Any responses that do not adhere to these rules may not be counted. > >The question is: > > Should we deprecate IPv6 site-local unicast addressing? > >Valid responses are: > > "YES -- Deprecate site-local unicast addressing". > "NO -- Do not deprecate site-local unicast addressing". > >If you express an opinion not to deprecate site-local addressing, it >would be helpful if you would provide a reason. Providing a reason >is completely optional, but it may help us to determine how to move >forward if the consensus to deprecate site-locals does not hold. >Possible reasons include: > > - Site-locals should be retained for disconnected sites. > - Site-locals should be retained for intermittently > connected sites. > - Site-locals should be retained for their access control > benefits. > - Site-locals should be retained as a means for internal > connections to survive global prefix renumbering. > - Other (please specify). > >Please, make your response _very_ clear (either YES or NO), or it will >not be counted. > >Please Note: DO NOT respond if you already participated in the >consensus call at the meeting in SF. At the meeting, there were >102 people who raised their hands for YES (deprecate site-locals) >and 20 people who raised their hands for NO (do not deprecate >site-locals). We will add the responses received on the mailing >list to the hands counted at the meeting, and use that information >to determine full WG consensus on this issue. > >If you feel an urgent need to reply to something that someone sends >in response to this message, please do it in a SEPARATE THREAD with >a different subject line. No discussion in this thread! > >Please voice your opinion on this important issue. > >Bob Hinden & Margaret Wasserman >IPv6 WG Chairs > > > > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Apr 4 09:30: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 h34HU9PL006815; Fri, 4 Apr 2003 09:30:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34HU8ke006814; Fri, 4 Apr 2003 09:30: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.9+Sun/8.12.9) with ESMTP id h34HU5PL006804 for ; Fri, 4 Apr 2003 09:30: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 h34HUCcU022471 for ; Fri, 4 Apr 2003 09:30:12 -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.3p2+Sun/8.9.3) with ESMTP id KAA03360 for ; Fri, 4 Apr 2003 10:30: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; Fri, 4 Apr 2003 17:30: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; Fri, 4 Apr 2003 17:30: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; Fri, 4 Apr 2003 17:30:05 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 17:30:04 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h34HU3vm008682; Fri, 4 Apr 2003 09:30:03 -0800 (PST) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h34HU3cu008681; Fri, 4 Apr 2003 09:30:03 -0800 (PST) Date: Fri, 4 Apr 2003 09:30:03 -0800 From: Shannon -jj Behrens To: Michel Py Cc: "ipng@sunroof.eng.sun.com" Subject: Re: free prefix allocation service Message-Id: <20030404173003.GA7727@alicia.nttmcl.com> References: <963621801C6D3E4A9CF454A1972AE8F504F72A@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F72A@server2000.arneill-py.sacramento.ca.us> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 03, 2003 at 03:44:29PM -0800, Michel Py wrote: > http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-ipv6-gusl-00.txt Comments below ;) > Nokia should not be the only company to provide free registration; as a > matter of fact I think it would be good to have two servers. Surely, it would be nice if anyone who wanted to could be such a server. > Feel free to comment on the text, it does need polishing. Now, concerning the draft, here are my comments. Please have mercy, as this is the first time I've ever responded with serious comments to a draft! C. Non-goals: Change the scope or usage of site-local addresses. What do you mean by scope? Also, you can scarcely change the usage since there is no *standard* usage. This document uses "site" having the same meaning as "end site" as described in [IPV6POLICY]. It seems dangerous to start using a word in the wrong way, even if you document it. I imagine that it can only propogate the confusion, although I have no suggested solutions other than to use a different word. 1.1 Rationale. This section is a bit confusing. Perhaps the following is better: The mailing list has expressed a desire that site-local prefixes have the following properties: free, automatic, no registration, and unique. Since these properties are somewhat contradictory, it is necessary to partially compromise specific properties. However, multiple non-exclusive compromises are possible, so multiple non-exclusive compromises are offered by this document. Concerning: If the router has the capability of saving its configuration in non-volatile memory such as NVRAM, Flash, or disk file the site-local prefix MUST be saved as part of the configuration and the generation MUST happen only once; subsequent restarts MUST use the site-local prefix stored in the configuration. I think that this text is not only necessary, but harmful. The only reason the prefix could change is if some nic's were added or removed. If it is the case that a nic is removed, the router must regenerate a new prefix. I think this goal is achieved by simply removing the text. 1.2.2 Unregistered, free, unique, sequentially allocated: FEF0::/12 This is fine as long as Nokia never goes out of business (I'm not being snide, I'm being practical). My assumption accounts for this, but I don't think it's a big deal. I think we can trust Nokia to hand this over to another company if the need ever arises. - Allocation is rate-limited at one prefix per day per IPv6 /64 prefix or IPv4 address. I can think of a few situtations where this limit would be too much. Personally, I was thinking of simply requiring a valid email address, and applying a minimal Turing test to make sure that a real person is making the request. As long as a real person is involved, he can request as many prefixes (one at a time) as he wants. This is not a big deal, though. Options a) and b) MUST NOT be available if the router does not have the capability of saving its configuration in non-volatile memory such as NVRAM, Flash, or disk file. I think this goes without saying. If it must be said, I don't think you need to use "MUST NOT". I think "will not" is sufficient. 2.2 All IPv6 capable routers MUST implement a default black hole I think SHOULD is sufficient. If even 90% of routers implement this requirement, it will be enough. In fact, I think sections 2.2 and 2.3 should be removed. Afterall, routers internal to a site should route site-locals just fine (per Margaret Wasserman's nesting ideas). I would possibly replace this with non-normative text suggesting that border firewalls and ISP's should filter this stuff. GUSL addresses MUST NOT be used for communication with other sites. Routers MUST NOT forward any packets with GUSL source or destination addresses outside of the site. I'm personally not a fan of this. I can understand trying to protect the DFZ, but I think it should be perfectly fine to connect two sites using site-local addresses and a tunnel. Perhaps we should require that only unique (not probably unique) prefixes should be allowed to do this, though. 6. Security considerations. It'd be nice if there was text reminding people that site-locals don't necessarily provide security. 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 Fri Apr 4 09:34: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 h34HYQPL007111; Fri, 4 Apr 2003 09:34:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34HYQSB007110; Fri, 4 Apr 2003 09:34: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.9+Sun/8.12.9) with ESMTP id h34HYMPL007100 for ; Fri, 4 Apr 2003 09:34: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 h34HYUcU024894 for ; Fri, 4 Apr 2003 09:34:30 -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.3p2+Sun/8.9.3) with ESMTP id JAA05739 for ; Fri, 4 Apr 2003 09:34: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; Fri, 4 Apr 2003 17:25: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; Fri, 4 Apr 2003 17:25:32 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, 4 Apr 2003 17:25:32 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 17:25:32 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 04 Apr 2003 09:25:31 -0800 Reply-To: From: "Tony Hain" To: "'Måns Nilsson'" , Subject: RE: site-locals Date: Fri, 4 Apr 2003 09:25:27 -0800 Message-Id: <0b5c01c2facf$2f5eee40$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: <399860000.1049439794@localhost.besserwisser.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h34HYMPL007101 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Måns Nilsson wrote: > ... > So, I'm glad that you call on the operator community, but I > think you will be surprised at what they say. I am not surprised because ISPs have a different perspective on this issue (and many others) than enterprise network managers. The network managers that will primarily use SL are at the edge, because the ISP has a mechanism to acquire prefixes at will. Claiming that ISPs see no need has almost as much value as the application developer that is looking to avoid a little extra work. Until we provide the edge network manager with viable alternatives, we have to keep the tool they can use. 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 Fri Apr 4 09:36: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 h34HasPL007432; Fri, 4 Apr 2003 09:36:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34Har1r007431; Fri, 4 Apr 2003 09:36: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.9+Sun/8.12.9) with ESMTP id h34HakPL007407 for ; Fri, 4 Apr 2003 09:36: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 h34HarHP017340 for ; Fri, 4 Apr 2003 09:36:53 -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.3p2+Sun/8.9.3) with ESMTP id KAA11010 for ; Fri, 4 Apr 2003 10:36: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; Fri, 4 Apr 2003 17:33: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, 4 Apr 2003 17:33: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; Fri, 4 Apr 2003 17:33:38 Z Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 17:33:38 Z Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h34HXVo05846; Fri, 4 Apr 2003 09:33:31 -0800 (PST) From: Bill Manning Message-Id: <200304041733.h34HXVo05846@boreas.isi.edu> Subject: Re: Split DNS and the IAB In-Reply-To: <0b4f01c2facc$a4665f00$ee1a4104@eagleswings> from Tony Hain at "Apr 4, 3 09:07:15 am" To: alh-ietf@tndh.net Date: Fri, 4 Apr 2003 09:33:31 -0800 (PST) Cc: ipng@sunroof.eng.sun.com, iab@ietf.org 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 % > How do applications get addresses? In my experience, a lot of % > them get them out of the DNS. But, if we put SLs into the % > DNS, we have to have split DNS... % % We need to do that anyway, because there is no valid reason to leak % filtered addresses outside of their scope of routability. Ambiguity is % the ruse that is use to make this an issue, but the real issue is that % resolving a name to an address that is not routable from that point is a % broken concept. Even if a site uses global scope addresses for its % internal use nodes & applications, a name resolution that includes both % filtered and unfiltered addresses will cause applications that falsely % assume a single address scope to fail. % % Tony This is something else that seems to have crept out of the woodwork. Split DNS. Doe folks really think that this "feature" is going to be required in addition to mandating a functional DNS? If so, what does this say to/about the IAB statement on the requirement for a single DNS context? --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 Fri Apr 4 09:50: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 h34HopPL009167; Fri, 4 Apr 2003 09:50:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34HopAr009166; Fri, 4 Apr 2003 09:50: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 h34HolPL009156 for ; Fri, 4 Apr 2003 09:50:47 -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 h34HotcU003727 for ; Fri, 4 Apr 2003 09:50:55 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA23595 for ; Fri, 4 Apr 2003 10:50:49 -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, 4 Apr 2003 17:50: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, 4 Apr 2003 17:47: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; Fri, 4 Apr 2003 17:50:48 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; Fri, 4 Apr 2003 17:50:47 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 SAA03529 for ; Fri, 4 Apr 2003 18:50:45 +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 SAA19835 for ; Fri, 4 Apr 2003 18:50:45 +0100 (BST) Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h34HojF05923 for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 18:50:45 +0100 Date: Fri, 4 Apr 2003 18:50:45 +0100 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: My Thoughts on Site-Locals Message-Id: <20030404175044.GM30669@ecs.soton.ac.uk> References: <963621801C6D3E4A9CF454A1972AE8F5045679@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030403185559.03acb498@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030403185559.03acb498@mail.windriver.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 03, 2003 at 06:59:19PM -0500, Margaret Wasserman wrote: > If the consensus to deprecate them does not hold, I'm not quite sure > what we are going to do... We certainly don't have consensus to do > any further work on site-locals, and it isn't clear how we can > ever finalize the scoped addressing architecture without some type > of decision on this issue. Perhaps we can break out the non-contentious > parts and advance those parts? > It seems to me that the way out of this is to find some mechanism by which site-locals can be considered reasonably unique. I think it would be sensible to define several different mechanisms for this (perhaps each with a different prefix) as cases can be made for choosing uniqeness based on time, geography, mac address etc. e.g. geographical prefixes allow a degree of control and aggregation, time or mac-address prefixs are more suiteed to zero-conf etc If they're recommended and easy to use then I see no reason why network managers would choose not to use them, as it's a benefit for them. I admit I'm not an expert with regards to the scoping issues here, but personally I don't see that these private-unique prefixes need to be given any special treatment other than that they're the least preferred prefix used. Personally I do not give the "site locals + nat will be used because re-numbering is hard" argument much credit, that's a re-numbering issue not a site-local one. I think it's reasonable to expect an "ipv6 renumber" command in routers, at least if re-numbering is going to be a major concern, and for DNS I'm sure something similar can be done. Well that's my take on it anyway :) 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 Fri Apr 4 09:54:53 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 h34HsqPL009438; Fri, 4 Apr 2003 09:54:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34HsqZr009437; Fri, 4 Apr 2003 09:54:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from elephant.West.Sun.COM (sm-uwcv01-01 [129.153.12.10]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h34HsnPL009430 for ; Fri, 4 Apr 2003 09:54:49 -0800 (PST) Received: from orth.west.sun.com (SYSTEM@orth [129.153.12.42]) by elephant.West.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h34HsuEV007416 for ; Fri, 4 Apr 2003 09:54:56 -0800 (PST) Received: from mauve.mrochek.com by orth.west.sun.com (PMDF V6.0-24 #30494) with ESMTP id <01KUBQ6AM6ZK8WWWK3@orth.west.sun.com> for ipng@sunroof.eng.sun.com; Fri, 04 Apr 2003 09:54:55 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KUA8L17H80002DEU@mauve.mrochek.com> for ipng@sunroof.eng.sun.com; Fri, 04 Apr 2003 09:54:33 -0800 (PST) Date: Fri, 04 Apr 2003 09:52:52 -0800 (PST) From: NED+ipv6@mauve.mrochek.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-reply-to: "Your message dated Thu, 03 Apr 2003 22:24:37 -0800" <595521669.20030403222437@psg.com> To: ipng@sunroof.eng.sun.com Message-id: <01KUBQ5TZ7WE002DEU@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> <595521669.20030403222437@psg.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing". Ned P.S. I was unable to attend the ipv6 meeting due to the conflicting ASRG 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 Fri Apr 4 10:17:35 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 h34IHYPL009941; Fri, 4 Apr 2003 10:17:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34IHYo9009939; Fri, 4 Apr 2003 10:17: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 h34IHSPL009932 for ; Fri, 4 Apr 2003 10:17:28 -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 h34IHZcU014521 for ; Fri, 4 Apr 2003 10:17:36 -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.3p2+Sun/8.9.3) with ESMTP id LAA19039 for ; Fri, 4 Apr 2003 11:17:30 -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, 4 Apr 2003 18:17: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; Fri, 4 Apr 2003 18:17:02 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, 4 Apr 2003 18:17:02 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 18:17:02 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 04 Apr 2003 10:16:58 -0800 Reply-To: From: "Tony Hain" To: "'Christian Huitema'" , "'Thomas Narten'" , "'Michel Py'" Cc: "'Margaret Wasserman'" , Subject: RE: My Thoughts on Site-Locals Date: Fri, 4 Apr 2003 10:16:45 -0800 Message-Id: <0b6f01c2fad6$59c715c0$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 h34IHSPL009933 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema wrote: > ... > Bad, bad application developers. We should really punish them! :-) Recognizing the smile, punishment was not my point. What many are missing here is that the perspective of a single address scope does not, and will not match the reality of the deployed network. > > Seriously, application developers face some very real > problems. The issues are uniqueness in space and uniqueness in time. > > The space dimension is experienced when a host is connected > to several sites, e.g. home network and VPN. If the > application receives a site local address from a local name > service or a local discovery service, it must associate that > address with a site identifier. The first stumbling block is > that most applications don't have this concept, they just > copy the address. > > The second stumbling block is that there are no readily > available site identifiers -- you would need to manage a > unique name space, which is precisely what you don't get from > FFC0::/10. In the absence of site identifier, the routing of > connections to the proper site is haphazard. The application > is supposed to remember that the site local address was > learned through a specific site, i.e. only use in site X the > site local addresses learned from site X's DNS service. This > become quickly very hairy, as the DNS does not in fact have a > concept of site. > > Restricting hosts to handle exactly one site removes some of > the problem. But you then bump into the time dimension. Hosts > may become members of different sites at different times, > e.g. a laptop moving from the office to the airport or to the > home. Addresses learned in one site should not be used in the > next, but for that you must have an easy way to tell that you > have changed sites. Without a site identifier, that can be real hard. > > Tony, these problems are not theoretical. They come very much > on top of the issues encountered by developers porting > applications to IPv6. I have never argued that the problems are theoretical, just that it is unreasonable for applications to blindly pass addresses outside the context where they make sense. The problems you list do raise the bar for application developers, but they are solvable. The other unreasonable point is insisting that the one-time/app cost of a developer dealing with complexity is more expensive than the continual operational costs for the network manager when the complexity is pushed there. > > Using unambiguous addresses solves a lot of the problems: a > multi homed site can route connections to the proper site, > source address selection can work, and moves to another site > can be detected. There are remaining issues, notably dealing > with intermittent connectivity, but these issues are inherent > to any mobility scenario. I agree, but we need to provide the alternatives first. Deprecating SL without providing alternatives for all the requirements will lead us to reinstating them when one of the requirements can't be met. 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 Fri Apr 4 10:21:12 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 h34ILCPL010049; Fri, 4 Apr 2003 10:21:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34ILCr9010048; Fri, 4 Apr 2003 10: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.9+Sun/8.12.9) with ESMTP id h34IL8PL010038 for ; Fri, 4 Apr 2003 10:21: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 h34ILFcU016037 for ; Fri, 4 Apr 2003 10:21: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.3p2+Sun/8.9.3) with ESMTP id LAA20396 for ; Fri, 4 Apr 2003 11:21:09 -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, 4 Apr 2003 18:21:09 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP; Fri, 4 Apr 2003 18:21:09 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP; Fri, 4 Apr 2003 18:21:08 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay1.sun.com with ESMTP; Fri, 4 Apr 2003 18:21:08 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 KAA21160; Fri, 4 Apr 2003 10:21:04 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h34IL3930218; Fri, 4 Apr 2003 10:21:03 -0800 X-mProtect: <200304041821> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVsgRWg; Fri, 04 Apr 2003 10:21:02 PST Message-Id: <3E8DCD4D.1040505@iprg.nokia.com> Date: Fri, 04 Apr 2003 10:22:05 -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: Erik Nordmark CC: alh-ietf@tndh.net, john.loughney@nokia.com, lear@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: site-locals References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I tend to agree with Erik on the research ship case; since the ship is a rather large and coherent entity (most likley owned by an even larger organization) it makes sense for it to have one or several globally unique prefix assignments that can be used whether/not the ship has a connection to the global Internet. But, I still havn't seen a solution proposal for ad-hoc networks of individuals that come together for arbitrary purposes and wish to form a network. For example, if Bob, Ted and Alice find themselves in a common space with no proximity to an Internet access point, they should be able to form a network and have persistent communications that survive even if an Internet access point is later encountered. But, since Bob, Ted and Alice are just private individuals, it seems unlikely that any would own a globally unique prefix - so how do they decide on a common prefix to use that supports communications even in the intermittently-connected case? I have seen at least one IEEE 802.11 product vendor that solves this problem at the MAC layer by choosing the MAC address of the first node to join the network as the I-D to use for the IBSS (i.e., the ad-hoc network "cluster"). When two nodes come together for the first time, there is some sort of tie-breaking to decide whose MAC address will be used. When multiple IBSS's merge (e.g., when John and Sue join), the I-D of one IBSS is chosen as the I-D of the merged IBSS. When, an IBSS partitions (e.g., when John and Alice leave) new I-D's are chosen. But, this all seems too dynamic of a model to adopt for choosing network-layer addresses in which stable addresses are needed both regardless of the underlying topology dynamics and without a provider-assigned prefix. How do we solve this? Fred ftemplin@iprg.nokia.com Erik Nordmark wrote: >>It is not a red herring. Input sent to me for the requirements doc: > > > But this case is exactly the same as what I categorized as #1 in my list - > isolating communication local to the site from site renumbering. The only added > twist is that site renumber occurs when the site attaches and detaches from > the Internet. > > >>Research ships at sea intermittently connect via INMARSAT, or when in >>port, the shipboard network is connected to shore via Ethernet. > > > Looking at your resarch ship case a bit more in detail it occurs > to me that even using site-locals plus globals while connected doesn't > necessarily protect the local communication. The introduction of the > global prefix/addresses when the ship is connected might very well > trigger different address selection behaviors in the stack or in the > applications. Thus it seems like the robustness provided by site-locals > only apply to communication established (and addresses selected) > before the global prefix is introduced. Later communication is subject > to any bugs or poor interaction in the address selection domain - something > that is bound to have some corner cases due to its complexity. > (Note that this is a property that applies to #1 in my list that I've > previously not realized.) While the effect of this probably is less than > the effect of renumbering the ships network each time it attaches to the > Internet, it still doesn't isolate the ships internal network from > being attached to the Internet when site-locals are used as you propose. > > So if I were to design this ship I'd use neiether renumbering at > attachment time nor site-locals. Instead I'd have the research ship get > a stable prefixe (a few /64's might suffice) from the organization that runs > it which are globally unique and can be used whether the ship is connected > or disconnected. This completely isolates the addressing of the ship internals > from whether it is connected or disconnected; the only difference is the when > disconnected off-ship destinations are unreachable. When it gets connected > tunnel(s) need to be established back to the research organization in order > for routing to work. Such tunnels could be cobbled up today with some existing > tunnel establishment mechanism, and the Nemo WG is working on an IETF standard > for such tunnel establishment. So if you want internal stability you have to > pay by having less efficient routing - going bidirectionally over the tunnel > to "home" - no free lunch. > > If you believe in Mobile IPv6 route optimization you might also > believe that the Nemo work can be extended to provide route optimization > to/from correspondent nodes in the Internet at large (by reusing the > MIPv6 approach). I personally think the utility of this remains to > be proven, but if it is it would help with the routing inefficiencies caused > by routing. > > So once again, this is not a case where I think site-locals help. > > 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 Fri Apr 4 10:27:16 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 h34IRGPL010681; Fri, 4 Apr 2003 10:27:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34IRFl8010676; Fri, 4 Apr 2003 10:27: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.9+Sun/8.12.9) with ESMTP id h34IR9PL010663 for ; Fri, 4 Apr 2003 10:27: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 h34IRGcU018675 for ; Fri, 4 Apr 2003 10:27:17 -0800 (PST) Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA25912 for ; Fri, 4 Apr 2003 11:27:11 -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 <0HCU003660LAQI@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 04 Apr 2003 11:27:11 -0700 (MST) Received: from sun.com ([129.146.18.20]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HCU0091P0L9IE@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 04 Apr 2003 11:27:10 -0700 (MST) Date: Fri, 04 Apr 2003 10:27:09 -0800 From: Alain Durand Subject: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve To: ipng@sunroof.eng.sun.com Message-id: <3E8DCE7D.4070508@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h34IR9PL010664 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message did not go through, I'm resending it on behalf of Patrick. - Alain. I have been quiet on this list, but have been talking with many many people about the view I as an application person have on Site Local. I don't like it. I have seen a few cases which people bring up where site local would be useful: [1] Networks which are intermittently connected [2] Networks which have multiple upstream providers, and they want to have a contiguous addressing scheme internally in the network [3] Networks which should not be reachable from the Internet Let me address them one by one: [1] Let's say we have two computers connected to a home network. They communicate with each other without any problem regardless of what addresses they have, but, when the network is connected, we end up having problems. If all nodes are renumbering, the 5-tuple which identifies existing flows between the computers will change which means that existing communication will break. But, this is a well known fact, and nothing we can do anything about. An application *should*always* use the hostname when communicating, and that imply it should not cache the IP address of the peers or itself between the flows are initiated which it needs. Yes, applications fail regarding this, and IP stacks are too bad at keeping the local IP address which happen to be assigned at the time a "listen" call is made. Application should be better at this, and I claim they _are_ getting better as computers more and more move around already today (due to DHCP, 802.11b etc). The broken 5-tuple is not much we can do anything about, BUT, site-local is not solving this problem either. Yes, I know the idea is that when two nodes can share the site local scoping to minimize the risk for the 5-tuple to break.... More below why this kind of solution is broken. [2] Networks which have multiple upstream providers have two prefixes they can choose from. Question is whether the network should use one, or the other, or both (or site local, neither) prefixes. This is of course something multi6 should take care of, but, from an application point of view, having multiple addresses because of routing issues is not a good idea. I rather see (in my possibly naïve view) sites like this really getting PI address space. Yes, aggregation can not happen, but, so what? I claim the number of routes today is still manageable, and the _real_ problem is that an IP address is both for addressing and routing. Having a third prefix (site local) which is used will force the use of NAT, and I really hope people understand how bad NAT is. I will not here repeat what I hope will end up in a document which Leif and Keith is writing about address management in applications. Applications which partially one can say is broken as they use IP addresses in the payload and not domain names, BUT, applications we have today. Applications we can not get rid of (like ftp, sip etc). [3] This is the most stupid idea...that NAT == Security...and because of that, nodes which only is thought of initiating flows towards something else should be behind a NAT. Security is one thing, addressing another. If an address is not to be accessible, filter out packets to it. A firewall doesn't have to include NAT functionality. Yes, many do, but I also think for these reasons many of them are broken. What one have to remember when talking about all of these problems is how the Internet should work. Not how it is implemented today, because things like NAT etc do exist, and yes, we will continue to see it for a while. First of all, we have one big mistake regarding addressing, and that is the overload of use of the IP addresses. We use it both as a unique identifier of an endpoint and for routing. addressing != routing This has created the problems we have with the routing protocols of today, as the Internet is no longer hierarchal. It is a mesh, a complete mesh. And, when navigating a mesh, one need different algorithms and mechanisms than when navigating a hierarchy. Site Local will not solve this problem. Secondly, the 5-tuple we use for flow identification is rigid, and we don't accept a change of any of the 5 values without having an interrupt in the flow. Maybe we should have some ICMP which say "please redirect flow to this address"? How to secure it? Will Site Local solve this problem? Don't think so... Thirdly, I think it is important applications uses names of things (domain names for example) when talking about and with others, while the IP network is the one which should know about the IP addresses. When an application have to know about the underlying network topology I would get very very nervous. Yes, FTP and SIP uses IP addresses, and I am not defending those two protocols. They are possibly flawed, but, even if they use the domain names in their payload, they don't have to know the topology (=routing) to know what source address they should use in a multihomed network. As someone said at the meeting in San Francisco: The day an application is required to know about routing and network topology we have a layering violation. I could possibly continue for a while, but I will stop here. Just Say No to Site Local. Or, as we say in Sweden "Gör om, gör rätt". ("Try again, and do it right this time") paf -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 10:42: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 h34IgoPL011352; Fri, 4 Apr 2003 10:42:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34Igo7E011351; Fri, 4 Apr 2003 10:42: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.9+Sun/8.12.9) with ESMTP id h34IgiPL011344 for ; Fri, 4 Apr 2003 10:42: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 h34IgpcU025017 for ; Fri, 4 Apr 2003 10:42:52 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA17217 for ; Fri, 4 Apr 2003 11:42:45 -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, 4 Apr 2003 18:42: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; Fri, 4 Apr 2003 18:42: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, 4 Apr 2003 18:42:44 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; Fri, 4 Apr 2003 18:42:44 Z Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h34IgOaj025112; Fri, 4 Apr 2003 11:42:24 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h34Ig3pG027323; Fri, 4 Apr 2003 12:42:05 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 8AAB52EC8B; Fri, 4 Apr 2003 20:42:17 +0200 (CEST) Message-Id: <3E8DD207.1090903@nal.motlabs.com> Date: Fri, 04 Apr 2003 20:42:15 +0200 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shannon -jj Behrens Cc: Michel Py , ipng@sunroof.eng.sun.com Subject: Re: free prefix allocation service References: <963621801C6D3E4A9CF454A1972AE8F504F72A@server2000.arneill-py.sacramento.ca.us> <20030404173003.GA7727@alicia.nttmcl.com> In-Reply-To: <20030404173003.GA7727@alicia.nttmcl.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Shannon -jj Behrens wrote: > This is fine as long as Nokia never goes out of business (I'm not > being snide, I'm being practical). :-) In that eventuality there's one at http://gusl.nal.motlabs.com visible both in v4 and v6. Not that I support gusl proposal, I must first understand it, but it seems to me that at least it raises new issues like how to coordinate between several sites wanting to offer such a service. Reliable service and so on. This is something enormous to deal with... Back lurking... Alex GBU -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 11:07: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 h34J78PL012041; Fri, 4 Apr 2003 11:07:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34J78JC012040; Fri, 4 Apr 2003 11:07: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 h34J74PL012033 for ; Fri, 4 Apr 2003 11:07:04 -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 h34J7BHP025492 for ; Fri, 4 Apr 2003 11:07:11 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA25394 for ; Fri, 4 Apr 2003 12:07: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; Fri, 4 Apr 2003 19:07:04 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, 4 Apr 2003 19:07: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, 4 Apr 2003 19:07:04 Z Received: from auemail1.firewall.lucent.com ([192.11.223.161] [192.11.223.161]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 19:07:04 Z Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34J72I01646 for ; Fri, 4 Apr 2003 14:07:02 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Apr 2003 21:07:01 +0200 Message-Id: <7D5D48D2CAA3D84C813F5B154F43B15501484194@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Fri, 4 Apr 2003 21:06:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The question is: > > Should we deprecate IPv6 site-local unicast addressing? > >Valid responses are: > > "YES -- Deprecate site-local unicast addressing". > "NO -- Do not deprecate site-local unicast addressing". > YES -- Deprecate site-local unicast addressing Bert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 11:34: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 h34JY1PL013169; Fri, 4 Apr 2003 11:34:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34JY1HL013168; Fri, 4 Apr 2003 11:34: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.9+Sun/8.12.9) with ESMTP id h34JXvPL013158 for ; Fri, 4 Apr 2003 11:33: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 h34JY5HP006598 for ; Fri, 4 Apr 2003 11:34:05 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA10267 for ; Fri, 4 Apr 2003 11:33:59 -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, 4 Apr 2003 19:33: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; Fri, 4 Apr 2003 19:33: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; Fri, 4 Apr 2003 19:33:56 Z Received: from fridge.docomolabs-usa.com ([216.98.102.225] [216.98.102.225]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 19:33:55 Z Date: Fri, 04 Apr 2003 11:33:46 -0800 Subject: Re: Location Privacy (was Re: Outlawing (Avoiding) NAT with IPv6) From: Alper Yegin To: Alexandru Petrescu , CC: Brian E Carpenter , , , Message-Id: In-Reply-To: <3E8D542C.8050507@nal.motlabs.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 Alex, > So, an idea is that the location privacy might be a problem, and that > Mobile IPv6 might offer a site-local-free solution for that problem, > and that HMIPv6 needs site locals in order to provide a solution to > that problem. This is not a correct conclusion. As I have explained earlier, HMIP provides location privacy by hiding MN's LCoA from the CN. LCoA does not need to be site-local. You'd need site-locals if you want to replicate the IPv4-NAT architecture one-to-one in this context. But this is not needed for achiving location privacy. alper -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 11:53:46 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 h34JrkPL013505; Fri, 4 Apr 2003 11:53:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34JrkjA013504; Fri, 4 Apr 2003 11:53: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 h34JrgPL013497 for ; Fri, 4 Apr 2003 11:53: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 h34JrocU023348 for ; Fri, 4 Apr 2003 11:53: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.3p2+Sun/8.9.3) with ESMTP id LAA25990 for ; Fri, 4 Apr 2003 11:53:44 -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, 4 Apr 2003 19:53:43 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, 4 Apr 2003 19:53: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, 4 Apr 2003 19:53:43 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 19:53:42 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id OAA11351 for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 14:53:40 -0500 (EST) Date: Fri, 4 Apr 2003 14:53:40 -0500 (EST) From: Dan Lanciani Message-Id: <200304041953.OAA11351@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [This response was apparently lost, so I'm resending it.] Thomas Narten wrote: |Dan Lanciani writes: | |> I can't speak for others, but to me it is very interesting (and |> important) to have internal connections that are not at the mercy of |> my ISP's renumbering policy. | |I agree that this is a very desirable property to have. But wanting |this doesn't mean we know how to achieve it. We know how to achieve it. You may not like the way we achieve it because it doesn't meet your standards for architectural purity, but until you have a better approach, how about letting use keep our impure solutions? |> |The tough question is, how do we get applications in general to prefer |> |SLs for local communication. | |> If an application wants to maximize the stability of its connection |> it always uses the addresses of smallest scope that will do the job. | |How do applications get addresses? In my experience, a lot of them get |them out of the DNS. But, if we put SLs into the DNS, we have to have |split DNS... As I explained below, you don't have to use split DNS. But people do use split DNS and if they are satisfied with the result, who are we to tell them to stop? This notion of giving up critical functionality today so that perhaps in the future we will get back some subset of that functionality in a more pure form just doesn't fly in the real world. |> I believe that your assumption is false. If the 30% consists of a few |> critical builds running over a remote file system, security information, |> etc., while the 70% represents much less important traffic then there |> could still be significant benefit. | |Fine. How do you ensure that the critical applications do in fact use |SL addresses? By configuring them to do so |How do you even know which ones are "critical"? Isn't |critical in the eye of the user? How do you know which machines need uninterruptible power supplies? How do you know which switches need redundant links to the backbone? You seem to be suggesting that a solution is no good unless the protocol automagically makes decisions about which applications are critical. In the real world, people make these decisions all the time. In the real world, people probably don't even _want_ your protocol to be making these decisions for them. |> Well, personally, I'm getting a little tired of worrying about what |> is and is not blessed. People will use what works. | |I take it from the above that you believe that making split DNS work |is trivial and obvious, so folks can and will just use it no |problem. I can't imagine why you would take it that way. Believe it or not, in the real world, people are sometimes capable of doing things that are _not_ trivial and obvious. Especially when they have no alternative. |My point is that the community doesn't seem to be in complete |agreement about that, which means there are almost certainly |subtleties and potential gotchas that can and will get in the way. The "community" is never in complete agreement about _anything_. There are always subtleties and potential gotchas. This is a characteristic of all but the most trivial systems. It is not an adequate reason to abandon a useful solution, especially when you offer no alternative. |> That said, I see no need to use split DNS in order to benefit from |> site-local's stable internal connections. As an example, my own |> network already uses separate names for the automation services that |> are accessed internally. Currently these are aliases for the global |> v4 addresses of the hosts which support the services. Under v6 I |> could change them to the site-local addresses of those same |> machines. | |So, in your system you have two names for the same service, one for |the global address, one for the internal address? No, I have only one name for a given service and the services are available only internally. I have other names for the hosts that happen to run the services. Those names would continue to point to a global address in my v6 scenario (unless of course the machine had no global address at all). I would use the same name to, e.g., telnet to the machine from inside or outside. Telneting to the machine is not the kind of critical, long-term connection that I feel I need to protect from renumbering. Other sites might have different ideas about which connections are critical and they would configure accordingly. |And if you are |inside your site, you use the internal name, and when you are outside |you use the external name? No, because these services are internal-only. That's the whole point. |If this is the basic idea, I suspect most users won't like this |approach and will not consider it to have solved the problem |acceptably. I suspect that you suspect wrong. People are using these (or worse) models in conjunction with NAT. These models are well understood. If you do not wish to support them cleanly in v6 with scoped addresses people will use NAT (unless you give them PI addresses). If you also manage to eliminate NAT from v6, people just won't use v6. |> It is true that site-locals do not by their mere existence automatically |> protect a site against renumbering, but that is a straw man. Site-locals |> allow a site that cares to protect connections that it cares about. This |> is an important capability. Do not be so quick to dismiss it. | |I've seen people say they think SLs are important to protect internal |communication for years. The problem is I still don't see a coherent |proposal for how this can be made to work in practice that seems to |solve the problem in a reasonable way for a broad class of users. I'm afraid that in the real world people have to get by with solutions that do not rise to the level of perfection that you seek. If you deprive users of the flexibility they need to implement the obvious solution they will probably find a way to do something that you will like even less. If you purify the protocol to the point that users really can't do what they want, you won't have any users to worry about. Dan Lanciani ddl@danlan.*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 Apr 4 12:08:10 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 h34K89PL013884; Fri, 4 Apr 2003 12:08:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34K89gm013883; Fri, 4 Apr 2003 12: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h34K85PL013876 for ; Fri, 4 Apr 2003 12:08: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 h34K8DcU028802 for ; Fri, 4 Apr 2003 12:08:13 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA14006 for ; Fri, 4 Apr 2003 13:08:07 -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, 4 Apr 2003 20:07:45 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, 4 Apr 2003 20:04: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; Fri, 4 Apr 2003 20:07:44 Z Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 20:07:44 Z Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h34K2qYN016710; Fri, 4 Apr 2003 13:02:53 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA07338; Fri, 4 Apr 2003 13:03:46 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.74]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h34K3Xj06742; Fri, 4 Apr 2003 14:03:34 -0600 Message-Id: <3E8E012D.4010804@nal.motlabs.com> Date: Sat, 05 Apr 2003 00:03:25 +0200 From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin CC: , Brian E Carpenter , , , Subject: Re: Location Privacy (was Re: Outlawing (Avoiding) NAT with IPv6) 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 Alper, I tried to draw a logic conclusion from this: -I assumed LCoA and RCoA have same last 64 bits -I was countered that that is not absolutely necessary, and that rfc 3041 could be used. -I replied: yes, could, but it is not. -I was pointed that site-locals might be used too. -so I concluded. That's only simple logic, sorry if I understood you wrong. > You'd need site-locals if you want to replicate the IPv4-NAT > architecture one-to-one in this context. But this is not needed for > achiving location privacy. Ok. It's overwhelming with emails, so please allow me to agree with some parts of your argumentation and maybe we get a chance to further discuss about this later. Alex GBU -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 12:08: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 h34K8bPL013933; Fri, 4 Apr 2003 12:08:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34K8aY7013932; Fri, 4 Apr 2003 12:08: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.9+Sun/8.12.9) with ESMTP id h34K8VPL013909 for ; Fri, 4 Apr 2003 12:08: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 h34K8dcU028926 for ; Fri, 4 Apr 2003 12:08:39 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA26735 for ; Fri, 4 Apr 2003 13:08: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; Fri, 4 Apr 2003 20:08: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; Fri, 4 Apr 2003 20:05: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; Fri, 4 Apr 2003 20:08:32 Z Received: from klapautius.it.su.se ([217.215.166.49] [217.215.166.49]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 20:08:31 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 h34J5OD10028; Fri, 4 Apr 2003 21:05:24 +0200 Message-Id: <3E8DD773.7040609@it.su.se> Date: Fri, 04 Apr 2003 21:05:23 +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: Dan Lanciani CC: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs References: <200304041953.OAA11351@ss10.danlan.com> In-Reply-To: <200304041953.OAA11351@ss10.danlan.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: >[This response was apparently lost, so I'm resending it.] > > > >We know how to achieve it. You may not like the way we achieve it because >it doesn't meet your standards for architectural purity, but until you have >a better approach, how about letting use keep our impure solutions? > > > I continue to be surprised by the number of people who continue to argue for a solution which apps people say *will not work*. What exactly are you planning to use the network for? Management of the network itself? 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 Fri Apr 4 12:34:14 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 h34KYEPL015370; Fri, 4 Apr 2003 12:34:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34KYEUN015369; Fri, 4 Apr 2003 12:34: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.9+Sun/8.12.9) with ESMTP id h34KY9PL015362 for ; Fri, 4 Apr 2003 12:34:11 -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 h34KYGcU013194 for ; Fri, 4 Apr 2003 12:34:16 -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.3p2+Sun/8.9.3) with ESMTP id MAA10452 for ; Fri, 4 Apr 2003 12:34:11 -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, 4 Apr 2003 20:34:10 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, 4 Apr 2003 20:34: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; Fri, 4 Apr 2003 20:34:10 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 20:34:09 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA11600; Fri, 4 Apr 2003 15:34:05 -0500 (EST) Date: Fri, 4 Apr 2003 15:34:05 -0500 (EST) From: Dan Lanciani Message-Id: <200304042034.PAA11600@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: site-locals Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: |Looking at your resarch ship case a bit more in detail it occurs |to me that even using site-locals plus globals while connected doesn't |necessarily protect the local communication. The introduction of the |global prefix/addresses when the ship is connected might very well |trigger different address selection behaviors in the stack or in the |applications. Thus it seems like the robustness provided by site-locals |only apply to communication established (and addresses selected) |before the global prefix is introduced. Later communication is subject |to any bugs or poor interaction in the address selection domain - something |that is bound to have some corner cases due to its complexity. It goes without saying that bugs in the implementation can cause problems. This (and similar claims being made by other contributors) is not a valid argument against site-locals. Bugs in the implementation of any solution are going to cause problems. Unless you have a solution that is demonstrably _so_ much easier to implement that the chance of its having bugs is materially smaller then there is no point in trying to make such a comparison. |(Note that this is a property that applies to #1 in my list that I've |previously not realized.) While the effect of this probably is less than |the effect of renumbering the ships network each time it attaches to the |Internet, it still doesn't isolate the ships internal network from |being attached to the Internet when site-locals are used as you propose. Site-locals and scoping allow sites that care to isolate connections that they care about from global prefix changes. Nobody has ever claimed more. You are generalizing the problem to the point where it cannot be solved and using that as a justification for not allowing a solution in the simple cases that people actually use. |So if I were to design this ship I'd use neiether renumbering at |attachment time nor site-locals. Instead I'd have the research ship get |a stable prefixe (a few /64's might suffice) from the organization that runs |it which are globally unique and can be used whether the ship is connected |or disconnected. This completely isolates the addressing of the ship internals |from whether it is connected or disconnected; the only difference is the when |disconnected off-ship destinations are unreachable. This is in effect giving the ship "virtual" PI space. I'm all in favor of PI space as long as it is available to everybody. |When it gets connected |tunnel(s) need to be established back to the research organization in order |for routing to work. Such tunnels could be cobbled up today with some existing |tunnel establishment mechanism, and the Nemo WG is working on an IETF standard |for such tunnel establishment. It's good to see that folks are coming around to my way of thinking. Note that with auto-tunnels such as I once proposed the routing becomes more and more efficient as more and more sites buy into the system to get virtual PI space. In the limit the tunnel always connects the endpoints and you are down to the encapsulation overhead. |So if you want internal stability you have to |pay by having less efficient routing - going bidirectionally over the tunnel |to "home" - no free lunch. Great. Tunnel-based routing is a tradeoff that I (and I suspect some others) would be happy to make in exchange for stable address space. How can we make sure that this option is in fact available to everyone who wants to use it? Making globally unique "unroutable" (but tunnelable) address space available would be a good start. Dan Lanciani ddl@danlan.*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 Apr 4 12:38: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 h34KcBPL015450; Fri, 4 Apr 2003 12:38:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34KcBEO015449; Fri, 4 Apr 2003 12:38: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 h34Kc7PL015436 for ; Fri, 4 Apr 2003 12:38: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 h34KcEcU014559 for ; Fri, 4 Apr 2003 12:38: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.3p2+Sun/8.9.3) with ESMTP id MAA29273 for ; Fri, 4 Apr 2003 12:38:09 -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, 4 Apr 2003 20:38:08 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, 4 Apr 2003 20:38: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; Fri, 4 Apr 2003 20:38:07 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; Fri, 4 Apr 2003 20:38:07 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); Fri, 4 Apr 2003 12:38:06 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 04 Apr 2003 12:38:05 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.196]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Fri, 4 Apr 2003 12:38:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6895.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Fri, 4 Apr 2003 12:38:06 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CONSENSUS CALL: Deprecating Site-Local Addressing Thread-Index: AcL4iKHLgI5Uk92cSZKNg63ZFgnpgACXpxWQ From: "Brian Zill" To: "Margaret Wasserman" , X-OriginalArrivalTime: 04 Apr 2003 20:38:05.0616 (UTC) FILETIME=[18437300:01C2FAEA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h34Kc7PL015437 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I missed the SF IETF. Here's my vote: "NO -- Do not deprecate site-local unicast addressing". - Site-locals should be retained for disconnected sites. - Site-locals should be retained for intermittently connected sites. - Site-locals should be retained for their access control benefits. - Site-locals should be retained as a means for internal connections to survive global prefix renumbering. - Other (please specify): + I do not approve of the procedure used here. If some people want to replace a part of the architecture for which we previously had had a rough consensus and working code, then they should write up a draft and get experience with implementations of their scheme before trying to kill the reasonable scheme we have now. This rush to kill site-local without a clear alternative plan strikes me as madness. + Scoped addresses are a fundamental part of the IPv6 architecture. Most of the "issues" that so disturb some people about them are there for link-local as well (or aren't really issues). We need to deal with them, they are solutions not problems. Sweeping them under the rug won't make the real problems go away. + There appears to be an undercurrent here for removing many of the features that make IPv6 so much better than IPv4: scoped addresses, multiple addresses per node, and doing other smart things with the address space. These were added to solve many of the other problems with v4. I don't want to see IPv6 be dumbed down until it is a solution to only one of v4's problems. --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 Apr 4 12:53: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 h34KrWPL016041; Fri, 4 Apr 2003 12:53:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34KrWBv016040; Fri, 4 Apr 2003 12:53: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 h34KrTPL016033 for ; Fri, 4 Apr 2003 12:53: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 h34KrbHP006394 for ; Fri, 4 Apr 2003 12:53: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.3p2+Sun/8.9.3) with ESMTP id MAA24360 for ; Fri, 4 Apr 2003 12:53:31 -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, 4 Apr 2003 20:53: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; Fri, 4 Apr 2003 20:50: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; Fri, 4 Apr 2003 20:53:30 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 20:53:30 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA11782 for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 15:53:29 -0500 (EST) Date: Fri, 4 Apr 2003 15:53:29 -0500 (EST) From: Dan Lanciani Message-Id: <200304042053.PAA11782@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Leif Johansson wrote: |Dan Lanciani wrote: | |>[This response was apparently lost, so I'm resending it.] |> |> |> |>We know how to achieve it. You may not like the way we achieve it because |>it doesn't meet your standards for architectural purity, but until you have |>a better approach, how about letting use keep our impure solutions? |> |> |> |I continue to be surprised by the number of people who continue to argue |for a |solution which apps people say *will not work*. I am an apps person. I am also a stack person. I am also a network person. What makes you think that the apps people who say it *will not work* are correct? Especially when they are talking about models that are already in use? Dan Lanciani ddl@danlan.*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 Apr 4 13:42: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 h34LgaPL016465; Fri, 4 Apr 2003 13:42:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34LgalN016464; Fri, 4 Apr 2003 13:42: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 h34LgWPL016457 for ; Fri, 4 Apr 2003 13:42: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 h34LgeHP022135 for ; Fri, 4 Apr 2003 13:42:40 -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.3p2+Sun/8.9.3) with ESMTP id OAA17392 for ; Fri, 4 Apr 2003 14:42:34 -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, 4 Apr 2003 21:42: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, 4 Apr 2003 21:42: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; Fri, 4 Apr 2003 21:42:33 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 21:42:33 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 04 Apr 2003 13:42:15 -0800 Reply-To: From: "Tony Hain" To: "'Bill Manning'" Cc: , Subject: RE: Split DNS and the IAB Date: Fri, 4 Apr 2003 13:41:47 -0800 Message-Id: <0b8501c2faf2$fe526ec0$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: <200304041733.h34HXVo05846@boreas.isi.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h34LgXPL016458 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Manning wrote: > ... Even if a site uses global scope addresses for its % > internal use nodes & applications, a name resolution that > includes both % filtered and unfiltered addresses will cause > applications that falsely % assume a single address scope to fail. > % > % Tony > > This is something else that seems to have crept out of the > woodwork. Split DNS. Doe folks really think that this > "feature" is going to be required in addition to mandating > a functional DNS? > > If so, what does this say to/about the IAB statement on the > requirement for a single DNS context? As I recall, the IAB statement says there must be a single root for the 'public name space', and I agree. It does not say we must leak information about filtered addresses outside the scope of the private network. The requirement to do that is coming from members of the app community who insist that despite the reality of private use address space, their right to build 'ignorant apps'R (pass opaque blobs around without a clue about the validity of the content at the receiver) supercede the rights of the network manager to get his job done. The argument 'passing around blobs doesn't hurt as long as the values are not ambiguous' ignores the fact that the network manager that put in the filter may not want information about internal use nodes exposed in any shape or form, because configuration errors do happen. The DNS (and for that matter every name resolution mechanism) needs to be aligned with the reality of the topology that it is handing out locators for. The DNS as deployed was defined for the unified Internet of 1985, while the current Internet includes routing filters (addresses with limited scope). This discrepancy needs to be fixed. The implementation of the fix may or may not include what we currently see deployed as split-DNS. Maybe it is time for a complete overhaul (DNSng) to deal with this and make the system capable of handling the identifier role being discussed wrt the multihoming problem. 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 Fri Apr 4 13:56:42 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 h34LugPL016780; Fri, 4 Apr 2003 13:56:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34Lug4L016779; Fri, 4 Apr 2003 13:56: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.9+Sun/8.12.9) with ESMTP id h34LucPL016772 for ; Fri, 4 Apr 2003 13:56:39 -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 h34LukHP026901 for ; Fri, 4 Apr 2003 13:56:46 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA26237 for ; Fri, 4 Apr 2003 14:56:40 -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, 4 Apr 2003 21:56: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; Fri, 4 Apr 2003 21:53: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; Fri, 4 Apr 2003 21:56:34 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 21:56:33 Z Received: from cisco.com (dhcp-171-71-119-47.cisco.com [171.71.119.47]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA00172; Fri, 4 Apr 2003 13:56:26 -0800 (PST) Message-Id: <3E8DFF89.6070009@cisco.com> Date: Fri, 04 Apr 2003 13:56:25 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Manning CC: zinin@psg.com, ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing References: <200304041049.h34An0g03475@boreas.isi.edu> In-Reply-To: <200304041049.h34An0g03475@boreas.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, I think what your missing is that to many of us, IPv6's selling points sum up to the following two things (the others pale): 1. Large address space 2. Mobility (1) is not necessary with site-locals. Since we have established that site-locals will encourage the use of NATs ('cause that's how it's done today) we might as well stick with the existing NAT'd infrastructure. If people vote "No", the benefits of a NAT-free world having evaporated, I see no reason for anyone outside of the mobile folks to move forward with IPv6, since what we have works comparably well with IPv6. And another thing- Tony keeps talking about acting irresponsibly by taking away a mechanism for which we otherwise have no solution. Of course we have a solution- IPv4 with NATs. This gives us some time to come up with something better for v6. Eliot Bill Manning wrote: > % "YES -- Deprecate site-local unicast addressing". > % > % reasons += adds complexity to routing, forwarding, and network operations; > % > % -- > % Alex Zinin > > waxing nostalgic... IPv6 was supposed to be an enabler of a whole > raft of interesting new capabilities. based on your concerns, listed > above, IPv6 is going to be nothing more than IPv4 with larger address > space. if that is what we end up with, then IPv6 development might > be considered a waste of time. we could support the premise of IPv6 > (10x16th nodes...?) using Paul Francis's nifty idea of a box that will > do address translation and never need to move away from a 32bit address > space. > > IPv6 had (and perhaps still has) the ability to allow us to develop > alternative routing techniques, where aggregation is not the only > abstraction that is viable. > > For me the vote (and it is a vote...) seems to break down along these > lines: > > Yes - those who wish to maintain the status quo or have vested commercial > interests in shipping IPv6 product. > No - those who wish to explore the latent capabilities of IPv6. > > as usual, YMMV and my understanding is likely flawed. > > > --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 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 14:01: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 h34M1dPL016920; Fri, 4 Apr 2003 14:01:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34M1dRG016919; Fri, 4 Apr 2003 14:01: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.9+Sun/8.12.9) with ESMTP id h34M1YPL016900 for ; Fri, 4 Apr 2003 14:01:34 -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 h34M1fcU013661 for ; Fri, 4 Apr 2003 14:01:42 -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.3p2+Sun/8.9.3) with ESMTP id PAA29313 for ; Fri, 4 Apr 2003 15:01: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, 4 Apr 2003 22:01: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, 4 Apr 2003 22:01:34 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, 4 Apr 2003 22:01:34 Z Received: from smtp.gcis.net (smtp.gcis.net [64.132.170.33]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 22:01:33 Z Received: from edslaptop [12.99.240.208] by smtp.gcis.net (SMTPD32-7.07) id A0CA5AB0146; Fri, 04 Apr 2003 17:01:46 -0500 From: "Ed Remmell" To: Subject: my vote on site-local scope address deprecation Date: Fri, 4 Apr 2003 13:57:43 -0800 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit 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 V5.50.4920.2300 Importance: Normal X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES, I'm in favor of deprecating the IPv6 site-local scope prefix fec0::. This, in spite of the fact that we have an existing IPv6 product for embedded systems that includes support for the site-local scope prefix, plus places in our source code and user documentation where site-local scope is referenced, etc. It is important to simplify IPv6 DNS, routers and source address selection. Thanks. - Ed Remmell Elmic Systems, USA http://www.elmic.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 Apr 4 14:14:18 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 h34MEHPL017294; Fri, 4 Apr 2003 14:14:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34MEHKC017293; Fri, 4 Apr 2003 14:14: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.9+Sun/8.12.9) with ESMTP id h34MEEPL017286 for ; Fri, 4 Apr 2003 14:14: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 h34MEHcU018898 for ; Fri, 4 Apr 2003 14:14:22 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA08342 for ; Fri, 4 Apr 2003 15:14:12 -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, 4 Apr 2003 22:14: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; Fri, 4 Apr 2003 22:10: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; Fri, 4 Apr 2003 22:14:11 Z Received: from southstation.m5p.com (southstation.m5p.com [209.162.215.52]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 22:14:11 Z Received: from m5p.com (parkstreet.m5p.com [10.100.0.1]) by southstation.m5p.com (8.12.9/8.12.9) with ESMTP id h34ME9Mh030155 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Apr 2003 14:14:09 -0800 (PST) Received: (from george@localhost) by m5p.com (8.12.9/8.12.9/Submit) id h34ME95s025556; Fri, 4 Apr 2003 14:14:09 -0800 (PST) Date: Fri, 4 Apr 2003 14:14:09 -0800 (PST) Message-Id: <200304042214.h34ME95s025556@m5p.com> From: george+ipng@m5p.com To: ipng@sunroof.eng.sun.com Subject: Site Local == Network Address Translation? X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eliot Lear wrote: > Since we have established that site-locals will encourage the use of NATs > ('cause that's how it's done today) Certainly a lot of people have tried to advance this proposition, but it seems dubious to me. Site local addresses will neither encourage nor discourage network address translation. And if you're going to cite the renumbering scenario to support this idea, I suggest that you are merely illumainating problems with renumbering, not site locals. -- George Mitchell -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 14:25: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 h34MPlPL017651; Fri, 4 Apr 2003 14:25:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34MPlGs017650; Fri, 4 Apr 2003 14:25: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.9+Sun/8.12.9) with ESMTP id h34MPhPL017643 for ; Fri, 4 Apr 2003 14:25: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 h34MPpHP009519 for ; Fri, 4 Apr 2003 14:25: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.3p2+Sun/8.9.3) with ESMTP id OAA12914 for ; Fri, 4 Apr 2003 14:25:45 -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, 4 Apr 2003 22:25:45 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, 4 Apr 2003 22:25: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; Fri, 4 Apr 2003 22:25:45 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; Fri, 4 Apr 2003 22:25:44 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA12710; Fri, 4 Apr 2003 14:25:05 -0800 (PST) Message-Id: <5.1.0.14.2.20030404172213.03d11bb0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 04 Apr 2003 17:22:56 -0500 To: Eliot Lear From: Margaret Wasserman Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Cc: Bill Manning , zinin@psg.com, ipng@sunroof.eng.sun.com In-Reply-To: <3E8DFF89.6070009@cisco.com> References: <200304041049.h34An0g03475@boreas.isi.edu> <200304041049.h34An0g03475@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk DO NOT DISCUSS THINGS IN THIS THREAD! (<-- yelling :-)). Please change the subject. Thanks, Margaret At 01:56 PM 4/4/2003 -0800, Eliot Lear wrote: >Bill, I think what your missing is that to many of us, IPv6's selling >points sum up to the following two things (the others pale): > >1. Large address space >2. Mobility > >(1) is not necessary with site-locals. Since we have established that >site-locals will encourage the use of NATs ('cause that's how it's done >today) we might as well stick with the existing NAT'd infrastructure. >If people vote "No", the benefits of a NAT-free world having evaporated, I >see no reason for anyone outside of the mobile folks to move forward with >IPv6, since what we have works comparably well with IPv6. > >And another thing- Tony keeps talking about acting irresponsibly by taking >away a mechanism for which we otherwise have no solution. Of course we >have a solution- IPv4 with NATs. This gives us some time to come up with >something better for v6. > >Eliot > >Bill Manning wrote: > >>% "YES -- Deprecate site-local unicast addressing". >>% % reasons += adds complexity to routing, forwarding, and network >>operations; >>% % -- >>% Alex Zinin >> waxing nostalgic... IPv6 was supposed to be an enabler of a whole >> raft of interesting new capabilities. based on your concerns, >> listed >> above, IPv6 is going to be nothing more than IPv4 with larger >> address space. if that is what we end up with, then IPv6 development might >> be considered a waste of time. we could support the premise of IPv6 >> (10x16th nodes...?) using Paul Francis's nifty idea of a box >> that will >> do address translation and never need to move away from a 32bit >> address >> space. >> IPv6 had (and perhaps still has) the ability to allow us to develop >> alternative routing techniques, where aggregation is not the >> only abstraction that is viable. >> For me the vote (and it is a vote...) seems to break down along >> these >> lines: >>Yes - those who wish to maintain the status quo or have vested commercial >> interests in shipping IPv6 product. >>No - those who wish to explore the latent capabilities of IPv6. >> as usual, YMMV and my understanding is likely flawed. >> >>--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 >>-------------------------------------------------------------------- > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Apr 4 14:37: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 h34MbSPL017989; Fri, 4 Apr 2003 14:37:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34MbSAc017988; Fri, 4 Apr 2003 14:37: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 h34MbPPL017981 for ; Fri, 4 Apr 2003 14:37: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 h34MbWcU000339 for ; Fri, 4 Apr 2003 14:37:33 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA05994 for ; Fri, 4 Apr 2003 15:37:27 -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, 4 Apr 2003 22:37:27 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, 4 Apr 2003 22:34: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; Fri, 4 Apr 2003 22:37:26 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 22:37:25 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id RAA12488; Fri, 4 Apr 2003 17:37:21 -0500 (EST) Date: Fri, 4 Apr 2003 17:37:21 -0500 (EST) From: Dan Lanciani Message-Id: <200304042237.RAA12488@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Patrick wrote: [...] |An application *should*always* use the hostname when communicating, and |that imply it should not cache the IP address of the peers or itself |between the flows are initiated which it needs. Yes, applications fail |regarding this, and IP stacks are too bad at keeping the local IP |address which happen to be assigned at the time a "listen" call is |made. Application should be better at this, and I claim they _are_ |getting better as computers more and more move around already today |(due to DHCP, 802.11b etc). Ok, so let's fix all the IP stacks to use names in the packets and in their APIs. Then we can fix the DNS to track renumbering events. Once that is done we can get rid of site-locals for good. |The broken 5-tuple is not much we can do anything about, BUT, |site-local is not solving this problem either. Yes, I know the idea is |that when two nodes can share the site local scoping to minimize the |risk for the 5-tuple to break.... You are the third person in the last 24 hours to assert that site-locals cannot provide for stable internal connections. Such assertions (which are obviously based on unstated assumptions about how perfectly any such solution must work) are very disturbing. The deprecation of site-locals supposedly came with some vague assurance that we would look at alternate ways to provide the functionality that was being removed. It is far too convenient to say that in retrospect site-locals never did provide for stable internal connections and thus we need not consider a replacement (or, as others have claimed, that we don't even know how to provide a replacement). Moreover, I'm concerned that stable internal connections will join the growing list of "features" (including the high availability that should have come from multi-homing) whose recommended implementation reduces to: send your ISP more money. [...] |I rather see (in my possibly naïve view) sites like |this really getting PI address space. Great. Let's make this PI space available FIRST and THEN we can get rid of site-locals with little trouble. |Yes, aggregation can not happen, |but, so what? I claim the number of routes today is still manageable, |and the _real_ problem is that an IP address is both for addressing and |routing. Great. Let's work on that problem now. [...] |What one have to remember when talking about all of these problems is |how the Internet should work. Not how it is implemented today, because |things like NAT etc do exist, and yes, we will continue to see it for a |while. | |First of all, we have one big mistake regarding addressing, and that is |the overload of use of the IP addresses. We use it both as a unique |identifier of an endpoint and for routing. addressing != routing I have made proposals over the years for portable identifiers. Did you support them? |This has created the problems we have with the routing protocols of |today, as the Internet is no longer hierarchal. It is a mesh, a |complete mesh. And, when navigating a mesh, one need different |algorithms and mechanisms than when navigating a hierarchy. Site Local |will not solve this problem. Great. Let's fix the routing problem FIRST and THEN nobody will care about site-locals. |Secondly, the 5-tuple we use for flow identification is rigid, and we |don't accept a change of any of the 5 values without having an |interrupt in the flow. Maybe we should have some ICMP which say "please |redirect flow to this address"? How to secure it? Will Site Local solve |this problem? Don't think so... I can't imagine why you would even ask if site-locals would address this hypothetical issue in a hypothetical solution... [...] |Just Say No to Site Local. Why not try a more positive approach like, ``Just say yes to PI space.''? All of the things that you suggest have been proposed many times over the years. They are consistently shot down as impossible. In fact, it is common knowledge that merely talking about PI space can cause the immediate death of the net as we know it--unless of course you talk about PI in conjunction with the deprecation of site-locals. The it's ok because we know that once site-locals are gone we can forget about PI again... Dan Lanciani ddl@danlan.*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 Apr 4 15:02: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 h34N2sPL018434; Fri, 4 Apr 2003 15:02:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34N2sW2018433; Fri, 4 Apr 2003 15:02: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 h34N2oPL018426 for ; Fri, 4 Apr 2003 15:02: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 h34N2vcU009704 for ; Fri, 4 Apr 2003 15:02:58 -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.3p2+Sun/8.9.3) with ESMTP id PAA23941 for ; Fri, 4 Apr 2003 15:02: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; Fri, 4 Apr 2003 23:01:37 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, 4 Apr 2003 23:01: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; Fri, 4 Apr 2003 23:01:37 Z Received: from smtp.gcis.net (smtp.gcis.net [64.132.170.33]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 23:01:37 Z Received: from edslaptop [12.99.240.208] by smtp.gcis.net (SMTPD32-7.07) id AEE2EB0114; Fri, 04 Apr 2003 18:01:54 -0500 From: "Ed Remmell" To: "Margaret Wasserman" Cc: Subject: RE: CONSENSUS CALL: Deprecating Site-Local Addressing Date: Fri, 4 Apr 2003 14:57:51 -0800 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit 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 V5.50.4920.2300 Importance: Normal In-Reply-To: <5.1.0.14.2.20030404172213.03d11bb0@mail.windriver.com> X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES, I'm in favor of deprecating the IPv6 site-local scope prefix fec0::. This, in spite of the fact that we have an existing IPv6 product for embedded systems that includes support for the site-local scope prefix, plus places in our source code and user documentation where site-local scope is referenced, etc. It is important to simplify IPv6 DNS, routers and source address selection. Thanks. - Ed Remmell Elmic Systems, USA http://www.elmic.com P.S. - I just wanted to make sure this appears in the correct thread, that's why I resent it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 4 15:04: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 h34N40PL018451; Fri, 4 Apr 2003 15:04:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h34N3xcY018450; Fri, 4 Apr 2003 15:03: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.9+Sun/8.12.9) with ESMTP id h34N3uPL018443 for ; Fri, 4 Apr 2003 15:03: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 h34N43HP023790 for ; Fri, 4 Apr 2003 15:04:03 -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.3p2+Sun/8.9.3) with ESMTP id QAA12874 for ; Fri, 4 Apr 2003 16:03:57 -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, 4 Apr 2003 23:03: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; Fri, 4 Apr 2003 23:03: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; Fri, 4 Apr 2003 23:03:56 Z Received: from frantic.weston.bsdi.com ([206.196.54.22] [206.196.54.22]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 23:03:56 Z Received: from frantic.weston.bsdi.com (localhost.BSDI.COM [127.0.0.1]) by frantic.weston.bsdi.com (8.12.5/8.12.5) with ESMTP id h34N5tMc024770 for ; Fri, 4 Apr 2003 17:05:55 -0600 (CST) Received: (from dab@localhost) by frantic.weston.bsdi.com (8.12.5/8.12.5/Submit) id h34N5tWN024769 for ipng@sunroof.eng.sun.com; Fri, 4 Apr 2003 17:05:55 -0600 (CST) Date: Fri, 4 Apr 2003 17:05:55 -0600 (CST) From: David Borman Message-Id: <200304042305.h34N5tWN024769@frantic.weston.bsdi.com> To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I was at the meeting in SF, and I was one of the minority that voted to not deprecate site-local addresses. Well, if I am allowed to, I am now changing my vote to: "YES -- Deprecate site-local unicast addressing". Perhaps folks might be interested to know why I originally voted NO, and why I am now changing my vote. If not, you can stop reading now. :-) Many people who have been voting NO have been including the list of possible reasons that Bob and Margaret put in the message: > Possible reasons include: > > - Site-locals should be retained for disconnected sites. > - Site-locals should be retained for intermittently > connected sites. > - Site-locals should be retained for their access control > benefits. > - Site-locals should be retained as a means for internal > connections to survive global prefix renumbering. ... Aside from the access control benefits, these are some of reasons why I originally voted NO. These are important issues, and they should be addressed. I don't want to see them ignored. I voted NO not so much that I felt that Site-locals were the solution to all these problems, but that I felt that Site-locals helped to keep a spotlight on these issues. My fear was that if we deprecated Site-locals, then people would decide that we don't need to worry about these issues any more. Deprecating site-locals doesn't get rid of these issues, it just removes one possible solution (and not necessarily a good solution) to them. So, there are issues and problems with Site-locals. (If there weren't we wouldn't even be having this discussion!) After seeing all the discussion on the list for the past week, I've come to the conclusion that rather than Site-locals keeping a spotlight on these issues so that they will get solved, they have become a stumbling block that is delaying those issues from being solved. The spotlight is on Site-locals themselves, not the issues that need to be solved. There are other approaches than Site-locals to addressing the above problems. I have a proposal that I'm working on writing up to directly address the disconnected/intermittently connected site issue. (And if you solve that, you probably get the internal connections surviving global prefix renumbering for free.) But I don't have it written up to a point where I could distribute it as an internet draft. I've verbally discussed it with a couple of people, but I have some more issues that I need to work through to decide for myself whether or not it is feasible. So that's what I think we should do. Deprecate Site-Locals as they are defined today (which isn't much of a definition), and then focus on solving these problems without the having the burden of being forced to cram the solution into Site-local addresses. -David Borman, Wind River Systems PS: I view claiming Site-Locals for access control benefits on par with "security through obscurity". If you want access control, put in real access control. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 16:01:59 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 h3501wPL019560; Fri, 4 Apr 2003 16:01:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3501wFJ019559; Fri, 4 Apr 2003 16:01: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.9+Sun/8.12.9) with ESMTP id h3501tPL019551 for ; Fri, 4 Apr 2003 16:01: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 h35022HP013910 for ; Fri, 4 Apr 2003 16:02:02 -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.3p2+Sun/8.9.3) with ESMTP id RAA28083 for ; Fri, 4 Apr 2003 17:01:57 -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, 5 Apr 2003 00:01: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; Sat, 5 Apr 2003 00:01: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; Sat, 5 Apr 2003 00:01:56 Z Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [210.49.138.109]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 00:01:55 Z Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h3501aab010734; Sat, 5 Apr 2003 10:01:36 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h3501YIC034751; Sat, 5 Apr 2003 10:01:34 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200304050001.h3501YIC034751@drugs.dv.isc.org> To: Bill Manning Cc: alh-ietf@tndh.net, ipng@sunroof.eng.sun.com, iab@ietf.org From: Mark.Andrews@isc.org Subject: Re: Split DNS and the IAB In-reply-to: Your message of "Fri, 04 Apr 2003 09:33:31 PST." <200304041733.h34HXVo05846@boreas.isi.edu> Date: Sat, 05 Apr 2003 10:01:34 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > % > How do applications get addresses? In my experience, a lot of > % > them get them out of the DNS. But, if we put SLs into the > % > DNS, we have to have split DNS... > % > % We need to do that anyway, because there is no valid reason to leak > % filtered addresses outside of their scope of routability. Ambiguity is > % the ruse that is use to make this an issue, but the real issue is that > % resolving a name to an address that is not routable from that point is a > % broken concept. Even if a site uses global scope addresses for its > % internal use nodes & applications, a name resolution that includes both > % filtered and unfiltered addresses will cause applications that falsely > % assume a single address scope to fail. > % > % Tony > > This is something else that seems to have crept out of the > woodwork. Split DNS. Doe folks really think that this > "feature" is going to be required in addition to mandating > a functional DNS? > > If so, what does this say to/about the IAB statement on the > requirement for a single DNS context? There are alternatives to split DNS. I would hope that the WG would take up those alternatives if it keeps site-local. They would be useful even with the alternatives to site-local by putting reachability information into the DNS. However now in not the time to debate this. Lets get site-local decided first. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 17:12:18 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 h351CIPL020042; Fri, 4 Apr 2003 17:12:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h351CIVL020041; Fri, 4 Apr 2003 17: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h351CEPL020034 for ; Fri, 4 Apr 2003 17:12:15 -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 h351CMcU022649 for ; Fri, 4 Apr 2003 17:12:22 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA04364 for ; Fri, 4 Apr 2003 18:12: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; Sat, 5 Apr 2003 01:12:13 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, 5 Apr 2003 01:12: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, 5 Apr 2003 01:12:12 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; Sat, 5 Apr 2003 01:12:12 Z Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h351CBA9084080; Fri, 4 Apr 2003 20:12:11 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-216-247.mts.ibm.com [9.65.216.247]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h351C7Jt082950; Fri, 4 Apr 2003 18:12:08 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h351B2G02281; Fri, 4 Apr 2003 20:11:02 -0500 Message-Id: <200304050111.h351B2G02281@cichlid.adsl.duke.edu> To: alh-ietf@tndh.net cc: ipng@sunroof.eng.sun.com Subject: Re: My Thoughts on Site-Locals In-Reply-To: Message from alh-ietf@tndh.net of "Fri, 04 Apr 2003 08:29:17 PST." <0b4001c2fac7$56f11030$ee1a4104@eagleswings> Date: Fri, 04 Apr 2003 20:11:02 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, "Tony Hain" writes: > The discussion that should have happened first is 'what alternatives do > we have to deal with the requirements that network managers are using SL > to deal with?' Without a clear replacement, and with comments that some > real problems are 'uninteresting', the network manager will insist on > keeping the current tool. You have said a number of times now that network managers want and need SLs. Question: Do you believe that if we keep SLs, this implies that we will indeed need to complete the work on multi-site nodes and that multi-site nodes will become necessary in practice to deal with what I expect the common practice of nodes being in multiple sites simultaneously (as I described in an earlier note)? (One of the things that happened at the SF meeting was that a number of people expressed skepticism at the viability of a limited usage "compromise" where we could use SLs in a limited fashion.) 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 Fri Apr 4 17:47: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 h351ldPL020499; Fri, 4 Apr 2003 17:47:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h351ldOf020498; Fri, 4 Apr 2003 17: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.9+Sun/8.12.9) with ESMTP id h351lZPL020491 for ; Fri, 4 Apr 2003 17:47: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 h351lhcU002642 for ; Fri, 4 Apr 2003 17:47:43 -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.3p2+Sun/8.9.3) with ESMTP id RAA09366 for ; Fri, 4 Apr 2003 17:47:37 -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, 5 Apr 2003 01:47:37 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, 5 Apr 2003 01:47: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; Sat, 5 Apr 2003 01:47:37 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 01:47:36 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 04 Apr 2003 17:47:35 -0800 Reply-To: From: "Tony Hain" To: "'Thomas Narten'" Cc: Subject: RE: My Thoughts on Site-Locals Date: Fri, 4 Apr 2003 17:46:31 -0800 Message-Id: <0bb001c2fb15$2eabef20$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: <200304050111.h351B2G02281@cichlid.adsl.duke.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h351laPL020492 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > "Tony Hain" writes: > > > The discussion that should have happened first is 'what > alternatives > > do we have to deal with the requirements that network managers are > > using SL to deal with?' Without a clear replacement, and > with comments > > that some real problems are 'uninteresting', the network > manager will > > insist on keeping the current tool. > > You have said a number of times now that network managers > want and need SLs. > > Question: Do you believe that if we keep SLs, this implies > that we will indeed need to complete the work on multi-site > nodes and that multi-site nodes will become necessary in > practice to deal with what I expect the common practice of > nodes being in multiple sites simultaneously (as I described > in an earlier note)? > I also believe that multi-sited nodes will be commonplace. With a viable PI space, I would expect most all of the multi-sited nodes to use that because the places that really want the ambiguity feature are not likely to want external access from nodes visiting another site. With PI the node needs to keep straight which domains should be retrieved from which DNS servers, and then which interface on the multi-sited node is attached to the returned prefix. The only difference I see between the work required for this vs. SL is that the multi-sited node can use the prefix assigned to an interface as a key, rather than having to create a local one to track where the name resolution came from. Either way it has to track which domains are available over which logical interface. > (One of the things that happened at the SF meeting was that a > number of people expressed skepticism at the viability of a > limited usage "compromise" where we could use SLs in a > limited fashion.) I have never believed that any of compromise approaches made any sense. Those are about mandates counter to the network managers goals. The majority of network managers will only choose SL because we don't offer a viable PI option. If we fix that and provide a way to simply configure a massive number of local use devices, the demand for the ambiguous SL will diminish. 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 Fri Apr 4 18:15: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 h352FtPL020825; Fri, 4 Apr 2003 18:15:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h352FtCd020824; Fri, 4 Apr 2003 18:15: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 h352FqPL020817 for ; Fri, 4 Apr 2003 18:15: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 h352FxHP023003 for ; Fri, 4 Apr 2003 18:15:59 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id TAA18183 for ; Fri, 4 Apr 2003 19:15:54 -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; Sat, 5 Apr 2003 02:15: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; Sat, 5 Apr 2003 02:12: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; Sat, 5 Apr 2003 02:15:53 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 02:15:53 Z Received: from cisco.com (dhcp-171-71-119-47.cisco.com [171.71.119.47]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA29482; Fri, 4 Apr 2003 18:15:51 -0800 (PST) Message-Id: <3E8E3C56.3080309@cisco.com> Date: Fri, 04 Apr 2003 18:15:50 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: george+ipng@m5p.com CC: ipng@sunroof.eng.sun.com Subject: Re: Site Local == Network Address Translation? References: <200304042214.h34ME95s025556@m5p.com> In-Reply-To: <200304042214.h34ME95s025556@m5p.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk george+ipng@m5p.com wrote: > Certainly a lot of people have tried to advance this proposition, but it > seems dubious to me. Site local addresses will neither encourage nor > discourage network address translation. And if you're going to cite > the renumbering scenario to support this idea, I suggest that you are > merely illumainating problems with renumbering, not site locals. Well, both to be fair. People will use site-locals if available in order to isolate them from having to renumber their infrastructure. Of this I'm convinced. My answer has been to work on improving the tools in this space to reduce the pain, rather than advance a mechanism that we know to have the identical limitations of IPv4. 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 Apr 4 21:08: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 h3558KPL021436; Fri, 4 Apr 2003 21:08:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3558J1Q021435; Fri, 4 Apr 2003 21:08: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 h3558GPL021428 for ; Fri, 4 Apr 2003 21:08:16 -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 h3558OHP024778 for ; Fri, 4 Apr 2003 21:08:24 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id WAA23291 for ; Fri, 4 Apr 2003 22:08:18 -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, 5 Apr 2003 05:08: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; Sat, 5 Apr 2003 05:04: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, 5 Apr 2003 05:08:16 Z Received: from psg.com (psg.com [147.28.0.62]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 05:08:16 Z Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 191fuX-0005Ww-00 for ipng@sunroof.eng.sun.com; Fri, 04 Apr 2003 21:08:13 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 191fuW-000FZP-00 for ipng@sunroof.eng.sun.com; Fri, 04 Apr 2003 21:08:12 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 4 Apr 2003 21:08:11 -0800 To: ipng@sunroof.eng.sun.com Subject: Re: My Thoughts on Site-Locals References: <3E8DB484.3000606@innovationslab.net> Message-Id: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk just in case folk have short memories, i am strongly against site-locals. they attempt to solve a routing problem with an address hack, a la rfc 1918. they are unneeded complexity. now is the time to abjure them. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 21:18: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 h355IAPL021751; Fri, 4 Apr 2003 21:18:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h355IA6a021750; Fri, 4 Apr 2003 21:18: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.9+Sun/8.12.9) with ESMTP id h355I7PL021743 for ; Fri, 4 Apr 2003 21:18: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 h355IEHP026717 for ; Fri, 4 Apr 2003 21:18:14 -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.3p2+Sun/8.9.3) with ESMTP id WAA24709 for ; Fri, 4 Apr 2003 22:18:09 -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, 5 Apr 2003 05:18:09 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, 5 Apr 2003 05:18: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; Sat, 5 Apr 2003 05:18:08 Z Received: from psg.com (psg.com [147.28.0.62]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 05:18:08 Z Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 191g47-00073h-00; Fri, 04 Apr 2003 21:18:07 -0800 Date: Fri, 4 Apr 2003 21:17:38 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-Id: <2887902827.20030404211738@psg.com> To: Bill Manning CC: ipng@sunroof.eng.sun.com Subject: Re: nostalgic ( was RE: CONSENSUS CALL: Deprecating Site-Local Addressing) In-Reply-To: <200304041049.h34An0g03475@boreas.isi.edu> References: <200304041049.h34An0g03475@boreas.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, > waxing nostalgic... IPv6 was supposed to be an enabler of a whole > raft of interesting new capabilities. based on your concerns, listed > above, IPv6 is going to be nothing more than IPv4 with larger address > space. I don't believe we should do something just because we can. Added complexity needs justification in the form of clear benefits. Extra operational complexity needs even more justification. >From what I've seen so far, benefits of SLs are questionable, while complications are introduced throughout the protocol stack. > if that is what we end up with, then IPv6 development might > be considered a waste of time. Interesting... Lack of SL support in many router implementations does not make people less interested in IPv6... > IPv6 had (and perhaps still has) the ability to allow us to develop > alternative routing techniques, where aggregation is not the only > abstraction that is viable. If those appear just because we can do so, I'd be skeptical. If because they solve a real problem and added complexity is not frightening--sure. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 4 21:39: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 h355dQPL022072; Fri, 4 Apr 2003 21:39:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h355dP3Q022071; Fri, 4 Apr 2003 21:39: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 h355dMPL022064 for ; Fri, 4 Apr 2003 21:39: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 h355dUHP000489 for ; Fri, 4 Apr 2003 21:39: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-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA04671 for ; Fri, 4 Apr 2003 21:39: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; Sat, 5 Apr 2003 05:39: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; Sat, 5 Apr 2003 05:39: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; Sat, 5 Apr 2003 05:39:23 Z Received: from psg.com (psg.com [147.28.0.62]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 05:39:23 Z Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 191gOd-0009WX-00; Fri, 04 Apr 2003 21:39:19 -0800 Date: Fri, 4 Apr 2003 21:38:48 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-Id: <6589172773.20030404213848@psg.com> To: "Michel Py" CC: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: My Thoughts on Site-Locals In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F731@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F504F731@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, > Agreed. I don't like the word "area" myself in this context; I was > simply quoting Margaret's words. Well, it's not that I don't like the word "area" here, in fact it would not be unreasonable to assume that people would want to map sites to areas... > There are plenty of other cases like > this, for example using two different IGPs as the result of a > merger-never-finished-the-cleanup or related; I have seen a site where > half of it was EIGRP the other half OSPF with mutual bidirectional > redistribution and eBGP in the middle. :-( > Mmmm thinking about it, :-) job security. Sounds really bad. Mutual redistribution is a very risky thing, but if done properly does not need eBGP... anyways, it's a mess and we don't want the architecture to encourage this... > Anyway, I suggested earlier that the site boundaries should be the > administrative control boundaries of the organization. It might not be > the correct wording, but my feeling is that we could come with some text > that will detail the position of site boundaries. > I have made the point earlier many times that the definition of "site" > is ambiguous and/or imprecise, there is some geographical connotation > attached to the word, we need a good definition anyway. I don't think a "better" definition is going to help here. No matter what we say a site should be, the day people start deploying them we'll hear back from the customers smiling at the definition and giving us their reasons why they have to ignore it (e.g. my organization has just become a department within a bigger one, what should I consider a site now?) Again, there is a disconnect between the driving factors defining site boundaries and those defining routing hierarchy elements. > I agree, but the other side of this coin is that if the feature is not > implemented in the architecture it will be implemented by the > configuration at the site. In other words, if as a site administrator I > am not happy about the way the site-local traffic flows I am going to > tweak it using route-maps, prefix-lists, route tags and whatever I feel > like doing for my intra-site traffic engineering. Each site will end up > being configured differently. Although there still is a lot of work to > be done on the topic, I think that the convexity of the site is a good > idea to incorporate in the architecture. I think there might be some confusion here. Even if site support was introduced into routing, SL topology and global one would be congruent (making them non-congruent would be too much complexity), which means that the path taken by packets that belong to a connection within a site would be the same regardless of whether SL or public addresses are used. So, SL do not add anything here at all. > In short: > - If site convexity is not built-in the architecture, it might or might > not work depending on implementation, network topology, etc. This will > lead in many cases to manual policy routing config to make it work the > may it should. > - If site convexity is built-in the architecture, the only case where it > would require manual policy routing config is if the site administrator > wants to break convexity. I can't think of a reason but I'm sure they > are some valid ones. If you are interested in convexity as a feature (rather than a requirement to make SLs work), we already have a similar notion in routing, but it is applied to areas and AS'es--for example, OSPF area are logically convex, i.e., traffic between hosts within the same area will be contained within the area because routers prefer intra-area routes over inter-area ones. You don't need the notion of sites here. > As some others have commented, IPv6 is not only IPv4 with more bits. The > issue of "automatic site convexity" is definitively a pain to implement > in router code, but is also a feature that simplifies the life of > network administrators and as such a factor of success for IPv6. I guess we disagree on the "simplifies" part here :) Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 5 02:12: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 h35AC6PL022950; Sat, 5 Apr 2003 02:12:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35AC67u022949; Sat, 5 Apr 2003 02:12: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.9+Sun/8.12.9) with ESMTP id h35AC3PL022942 for ; Sat, 5 Apr 2003 02:12: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 h35ACAHP015753 for ; Sat, 5 Apr 2003 02:12:10 -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.3p2+Sun/8.9.3) with ESMTP id CAA24299 for ; Sat, 5 Apr 2003 02:12: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; Sat, 5 Apr 2003 10:12: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; Sat, 5 Apr 2003 10:08: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, 5 Apr 2003 10:12:03 Z Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 10:12:03 Z Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h35AACBB012109; Sat, 5 Apr 2003 12:10:12 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sat, 5 Apr 2003 12:11:59 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sat, 5 Apr 2003 12:11:58 +0200 Date: Sat, 5 Apr 2003 12:11:53 +0200 Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipng@sunroof.eng.sun.com To: Dan Lanciani From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <200304042237.RAA12488@ss10.danlan.com> Message-Id: <05F1F15F-674F-11D7-81E1-000A959CF516@cisco.com> X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 05 Apr 2003 10:11:58.0652 (UTC) FILETIME=[CB0567C0:01C2FB5B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h35AC3PL022943 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On lördag, apr 5, 2003, at 00:37 Europe/Stockholm, Dan Lanciani wrote: > Great. Let's make this PI space available FIRST and THEN we can get > rid > of site-locals with little trouble. > > |Yes, aggregation can not happen, > |but, so what? I claim the number of routes today is still manageable, > |and the _real_ problem is that an IP address is both for addressing > and > |routing. > > Great. Let's work on that problem now. Yes, of course we should. But, I think we can not get real force behind such work before we _first_ agree Site Local is not solving this problem, and we therefore agree Site Local should go away. paf -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 5 03:20: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 h35BKlPL023798; Sat, 5 Apr 2003 03:20:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35BKlGk023797; Sat, 5 Apr 2003 03:20: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 h35BKiPL023790 for ; Sat, 5 Apr 2003 03:20: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 h35BKqcU024466 for ; Sat, 5 Apr 2003 03:20:52 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA18679 for ; Sat, 5 Apr 2003 04:20:47 -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; Sat, 5 Apr 2003 11:20: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; Sat, 5 Apr 2003 11:17: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; Sat, 5 Apr 2003 11:20:44 Z Received: from devil.pp.htv.fi ([213.243.180.132] [213.243.180.132]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 11:20:43 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 h35BLd4l025178; Sat, 5 Apr 2003 14:21:39 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h35BLasc025177; Sat, 5 Apr 2003 14:21:36 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve From: Mika Liljeberg To: Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?= Cc: Dan Lanciani , ipng@sunroof.eng.sun.com In-Reply-To: <05F1F15F-674F-11D7-81E1-000A959CF516@cisco.com> References: <05F1F15F-674F-11D7-81E1-000A959CF516@cisco.com> Content-Type: text/plain; charset=ISO-8859-15 Organization: Message-Id: <1049541695.20483.11.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2003 14:21:36 +0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h35BKiPL023791 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 2003-04-05 at 13:11, Patrik Fältström wrote: > > Great. Let's work on that problem now. > > Yes, of course we should. But, I think we can not get real force behind > such work before we _first_ agree Site Local is not solving this > problem, and we therefore agree Site Local should go away. Forgive me for being cynical, but another way to phrase the above is that the intent is to deny an existing solution to people who are content with it in order to force them to work on a new 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 Sat Apr 5 03:52: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 h35BqqPL024146; Sat, 5 Apr 2003 03:52:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35BqqaG024143; Sat, 5 Apr 2003 03:52: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.9+Sun/8.12.9) with ESMTP id h35BqmPL024136 for ; Sat, 5 Apr 2003 03:52:48 -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 h35BqvHP003316 for ; Sat, 5 Apr 2003 03:52:57 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA29180 for ; Sat, 5 Apr 2003 04:52: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; Sat, 5 Apr 2003 11:52: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; Sat, 5 Apr 2003 11: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; Sat, 5 Apr 2003 11:52:50 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; Sat, 5 Apr 2003 11:52:50 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 h35AnpD14470; Sat, 5 Apr 2003 12:49:52 +0200 Message-Id: <3E8EB4CE.2000601@it.su.se> Date: Sat, 05 Apr 2003 12:49:50 +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: Dan Lanciani CC: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs References: <200304042053.PAA11782@ss10.danlan.com> In-Reply-To: <200304042053.PAA11782@ss10.danlan.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: >What makes you think that the apps people who say it *will not work* are >correct? Especially when they are talking about models that are already in >use? > > > Which models would that be exacly? I hope you are not talking about the lets run-everything-over-http-model... The bottom line is that lots of applications are impossible to deploy on the Internet today because of rfc1918. I hope that v6 is a way out of that cul-de-sac. If that is the only thing v6 does it is good enough. If v6 doesn't provide a way out of the balkanization of the network it is essentially worthless imo. 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 Sat Apr 5 04:00: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 h35C0ePL024368; Sat, 5 Apr 2003 04:00:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35C0ei9024367; Sat, 5 Apr 2003 04: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.9+Sun/8.12.9) with ESMTP id h35C0bPL024360 for ; Sat, 5 Apr 2003 04:00: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 h35C0jHP004791 for ; Sat, 5 Apr 2003 04:00:46 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA01919 for ; Sat, 5 Apr 2003 05:00:40 -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, 5 Apr 2003 12:00:40 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, 5 Apr 2003 11:57: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; Sat, 5 Apr 2003 12:00:39 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; Sat, 5 Apr 2003 12:00:39 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id DAA22515; Sat, 5 Apr 2003 03:59:43 -0800 (PST) Message-Id: <5.1.0.14.2.20030405064207.03d13d60@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 05 Apr 2003 06:58:15 -0500 To: Mika Liljeberg From: Margaret Wasserman Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Dan Lanciani , ipng@sunroof.eng.sun.com In-Reply-To: <1049541695.20483.11.camel@devil> References: <05F1F15F-674F-11D7-81E1-000A959CF516@cisco.com> <05F1F15F-674F-11D7-81E1-000A959CF516@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h35C0bPL024361 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mika, At 02:21 PM 4/5/2003 +0300, Mika Liljeberg wrote: >On Sat, 2003-04-05 at 13:11, Patrik Fältström wrote: > > Yes, of course we should. But, I think we can not get real force behind > > such work before we _first_ agree Site Local is not solving this > > problem, and we therefore agree Site Local should go away. > >Forgive me for being cynical, but another way to phrase the above is >that the intent is to deny an existing solution to people who are >content with it in order to force them to work on a new one. Or, considered another way... We'd like to deprecate the flawed solution now, before more people implement it or come to depend on it. And, we'd like to pursue a viable model for local addressing, without the flaws and limitations inherent is ambiguous site-local addresses, because we understand that solutions will be needed for: - Addressing for disconnected sites. - Addressing for intermittently connected sites. - Prefix-based access control. - Stable addressing for local connections. What we _really_ want is to achieve all three of the following things simultaneously: - All addresses are globally routable (note that this doesn't preclude filtering some addresses or address/port combos). - Addresses are provider-independent (stable across ISP changes or ISP renumbering, available when not connected, etc.). - Core Internet routing tables stay a manageable size. But, we have not (yet?) come up with a model for provider-independent, globally-routable addressing that does not result in routing table bloat. So, network administrators will be forced to choose between global-routability and provider-independence for their internal addressing. And, as we've learned in IPv4, there are a fairly large number of people who will choose provider-independence over global-routability. So, we do need to provide some solution for provider-independent, local addressing. But there is no reason why these addresses need to be ambiguous. And, if they are globally unique, they don't need to be constrained by the limitations of current site-local addressing that are required because of thier ambiguity (can't be nested, can't overlap, etc.). Deprecating site-local addressing does not immediately remove it from those implementations that include it, and it certainly doesn't remove it from current network configurations, but it does send a strong message to people that the current, ambiguous site-local addresses are not a solution that should be invested in further. And, it opens the door to finding new, viable ways to address the demand for provider-independent addresses. Margaret 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 Apr 5 04:11: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 h35CBQPL024616; Sat, 5 Apr 2003 04:11:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35CBQ0T024615; Sat, 5 Apr 2003 04:11: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 h35CBNPL024608 for ; Sat, 5 Apr 2003 04:11:23 -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 h35CBVHP006486 for ; Sat, 5 Apr 2003 04:11:31 -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.3p2+Sun/8.9.3) with ESMTP id EAA11439 for ; Sat, 5 Apr 2003 04:11:26 -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, 5 Apr 2003 12:11: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, 5 Apr 2003 12:11: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; Sat, 5 Apr 2003 12:11:25 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; Sat, 5 Apr 2003 12:11:25 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA26013; Sat, 5 Apr 2003 04:10:53 -0800 (PST) Message-Id: <5.1.0.14.2.20030405070046.03bcb260@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 05 Apr 2003 07:08:11 -0500 To: David Borman From: Margaret Wasserman Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200304042305.h34N5tWN024769@frantic.weston.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi David, At 05:05 PM 4/4/2003 -0600, David Borman wrote: >Well, if I am allowed to, I am now changing my vote to: > > "YES -- Deprecate site-local unicast addressing". Yes, you are allowed to change your opinion and we will consider your new position in our consensus determination. The primary way we reach consensus is by people changing their opinions, over time, based on new information or further understanding. So, if you have changed your mind (based on subsequent discussion, clarification of the question or just further thought) please feel free to update your previously expressed opinion. If you do change your opinion, though, please observe the following rules: - Send your change of opinion in this thread (using the subject above). - Make your new opinion very clear (YES or NO). - State how you expressed your original opinion (at the meeting, or on the list). - If you expressed your original opinion on the list, please use the same e-mail address to send your new opinion (or at least mention any change). Thanks, 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 Apr 5 05:08: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 h35D8VPL024990; Sat, 5 Apr 2003 05:08:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35D8UH7024989; Sat, 5 Apr 2003 05:08: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 h35D8RPL024982 for ; Sat, 5 Apr 2003 05:08:27 -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 h35D8ZcU012301 for ; Sat, 5 Apr 2003 05:08:36 -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.3p2+Sun/8.9.3) with ESMTP id GAA02234 for ; Sat, 5 Apr 2003 06:08: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; Sat, 5 Apr 2003 13:08: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; Sat, 5 Apr 2003 13:08:29 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, 5 Apr 2003 13:08:29 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; Sat, 5 Apr 2003 13:08:28 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 h35D9R4l025486; Sat, 5 Apr 2003 16:09:29 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h35D9OlL025485; Sat, 5 Apr 2003 16:09:24 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve From: Mika Liljeberg To: Margaret Wasserman Cc: Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?= , Dan Lanciani , ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030405064207.03d13d60@mail.windriver.com> References: <05F1F15F-674F-11D7-81E1-000A959CF516@cisco.com> <05F1F15F-674F-11D7-81E1-000A959CF516@cisco.com> <5.1.0.14.2.20030405064207.03d13d60@mail.windriver.com> Content-Type: text/plain; charset=ISO-8859-15 Organization: Message-Id: <1049548162.20483.30.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2003 16:09:23 +0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h35D8RPL024983 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, The goals you state below are very worthy and, once there are satisfactory solutions employing unambiguous addressing, I will certainly be vying for the privilege to be among the first to implement them. However, at this point deprecating site-local addresses will simply slow down real world deployment of IPv6 and, in a very concrete way, take the pressure off those who are the most motivated to work on better solutions. The fact that people feel impelled to buy time for the IPv6 WG to do this does not give me great confidence that those solutions will be arriving any time soon. Regards, MikaL On Sat, 2003-04-05 at 14:58, Margaret Wasserman wrote: > Hi Mika, > > At 02:21 PM 4/5/2003 +0300, Mika Liljeberg wrote: > >On Sat, 2003-04-05 at 13:11, Patrik Fältström wrote: > > > Yes, of course we should. But, I think we can not get real force behind > > > such work before we _first_ agree Site Local is not solving this > > > problem, and we therefore agree Site Local should go away. > > > >Forgive me for being cynical, but another way to phrase the above is > >that the intent is to deny an existing solution to people who are > >content with it in order to force them to work on a new one. > > Or, considered another way... > > We'd like to deprecate the flawed solution now, before more people > implement it or come to depend on it. > > And, we'd like to pursue a viable model for local addressing, without > the flaws and limitations inherent is ambiguous site-local addresses, > because we understand that solutions will be needed for: > > - Addressing for disconnected sites. > - Addressing for intermittently connected sites. > - Prefix-based access control. > - Stable addressing for local connections. > > What we _really_ want is to achieve all three of the following > things simultaneously: > > - All addresses are globally routable (note that this doesn't > preclude filtering some addresses or address/port combos). > - Addresses are provider-independent (stable across ISP changes > or ISP renumbering, available when not connected, etc.). > - Core Internet routing tables stay a manageable size. > > But, we have not (yet?) come up with a model for provider-independent, > globally-routable addressing that does not result in routing table > bloat. > > So, network administrators will be forced to choose between > global-routability and provider-independence for their internal > addressing. And, as we've learned in IPv4, there are a fairly > large number of people who will choose provider-independence over > global-routability. > > So, we do need to provide some solution for provider-independent, > local addressing. But there is no reason why these addresses > need to be ambiguous. And, if they are globally unique, they > don't need to be constrained by the limitations of current > site-local addressing that are required because of thier ambiguity > (can't be nested, can't overlap, etc.). > > Deprecating site-local addressing does not immediately remove > it from those implementations that include it, and it certainly > doesn't remove it from current network configurations, but it > does send a strong message to people that the current, ambiguous > site-local addresses are not a solution that should be invested > in further. And, it opens the door to finding new, viable > ways to address the demand for provider-independent addresses. > > Margaret > > > > > > > > > > > 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 Sat Apr 5 07:02: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 h35F2ZPL025473; Sat, 5 Apr 2003 07:02:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35F2ZwJ025472; Sat, 5 Apr 2003 07:02: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.9+Sun/8.12.9) with ESMTP id h35F2VPL025465 for ; Sat, 5 Apr 2003 07:02:31 -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 h35F2dcU004576 for ; Sat, 5 Apr 2003 07:02: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.3p2+Sun/8.9.3) with ESMTP id HAA12384 for ; Sat, 5 Apr 2003 07:02: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; Sat, 5 Apr 2003 15:02: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; Sat, 5 Apr 2003 15:02: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, 5 Apr 2003 15:02:33 Z Received: from auemail1.firewall.lucent.com ([192.11.223.161] [192.11.223.161]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 15:02:33 Z Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h35F2T609729 for ; Sat, 5 Apr 2003 10:02:31 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 5 Apr 2003 17:02:28 +0200 Message-Id: <7D5D48D2CAA3D84C813F5B154F43B15501484216@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipng (E-mail)" Subject: FW: Last Call: Textual Conventions for IPv6 Flow Label to Propos ed Standard Date: Sat, 5 Apr 2003 17:02:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI and possible comment. Send comments to iesg/ietf mailing lists, or for discussions join mibs@ops.ietf.org Thanks, Bert -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: zaterdag 5 april 2003 0:49 Subject: Last Call: Textual Conventions for IPv6 Flow Label to Proposed Standard The IESG has received a request from the Operations & Management Open Area Working Group to consider Textual Conventions for IPv6 Flow Label as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-5-4. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ops-ipv6-flowlabel-00.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Apr 5 08:05: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 h35G55PL025956; Sat, 5 Apr 2003 08:05:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35G55fP025955; Sat, 5 Apr 2003 08:05: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.9+Sun/8.12.9) with ESMTP id h35G51PL025948 for ; Sat, 5 Apr 2003 08:05:01 -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 h35G5AcU014992 for ; Sat, 5 Apr 2003 08:05:10 -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.3p2+Sun/8.9.3) with ESMTP id IAA11762 for ; Sat, 5 Apr 2003 08:05:01 -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; Sat, 5 Apr 2003 16:05: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; Sat, 5 Apr 2003 16:05: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; Sat, 5 Apr 2003 16:05:00 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 16:05:00 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Sat, 05 Apr 2003 08:04:58 -0800 Reply-To: From: "Tony Hain" To: "'Randy Bush'" , Subject: RE: My Thoughts on Site-Locals Date: Sat, 5 Apr 2003 08:04:59 -0800 Message-Id: <0bcb01c2fb8d$1c1390c0$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 h35G52PL025949 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy Bush wrote: > just in case folk have short memories, i am strongly against > site-locals. they attempt to solve a routing problem with an > address hack, a la rfc 1918. they are unneeded complexity. > now is the time to abjure them. They solve an addressing problem PI, where other proposed approaches create a routing problem. Until there is a routable PI space, we need an unroutable one. We have to solve the problems in the right order. 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 Apr 5 08:26: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 h35GQ7PL026298; Sat, 5 Apr 2003 08:26:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35GQ7aC026297; Sat, 5 Apr 2003 08:26: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 h35GQ3PL026290 for ; Sat, 5 Apr 2003 08:26: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 h35GQCHP016913 for ; Sat, 5 Apr 2003 08:26: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-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA19630 for ; Sat, 5 Apr 2003 08:26:06 -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, 5 Apr 2003 16:26: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; Sat, 5 Apr 2003 16:26: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; Sat, 5 Apr 2003 16:26:05 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 16:26:05 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Sat, 05 Apr 2003 08:26:02 -0800 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , "'Mika Liljeberg'" Cc: "'Patrik Fältström'" , "'Dan Lanciani'" , Subject: RE: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Date: Sat, 5 Apr 2003 08:26:03 -0800 Message-Id: <0bcc01c2fb90$0da62590$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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.20030405064207.03d13d60@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h35GQ3PL026291 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > ... > What we _really_ want is to achieve all three of the > following things simultaneously: > > - All addresses are globally routable (note that this doesn't > preclude filtering some addresses or > address/port combos). > - Addresses are provider-independent (stable across > ISP changes > or ISP renumbering, available when not > connected, etc.). > - Core Internet routing tables stay a manageable size. > > But, we have not (yet?) come up with a model for > provider-independent, globally-routable addressing that does > not result in routing table bloat. So even though the routing research group has not come up with a solution that simultaneously addresses all three of these in the last 10 years of focused work, the IPv6 WG will promise to come up with a solution quickly if we just deprecate the only viable approach we know of first. I guess it shouldn't surprise me that the herd mentality is so willing to buy the promise of a better way rather than face reality, but it still does. > > So, network administrators will be forced to choose between > global-routability and provider-independence for their > internal addressing. And, as we've learned in IPv4, there > are a fairly large number of people who will choose > provider-independence over global-routability. They are forced to choose in IPv4 because it is too difficult to assign multiple addresses to an interface. That issue goes away with IPv6, so the 'forced to choose' concept is coming from those who don't want to deal with the issues raised. > > So, we do need to provide some solution for > provider-independent, local addressing. But there is no > reason why these addresses need to be ambiguous. And, if > they are globally unique, they don't need to be constrained > by the limitations of current site-local addressing that are > required because of thier ambiguity (can't be nested, can't > overlap, etc.). > > Deprecating site-local addressing does not immediately remove > it from those implementations that include it, and it > certainly doesn't remove it from current network > configurations, but it does send a strong message to people > that the current, ambiguous site-local addresses are not a > solution that should be invested in further. And, it opens > the door to finding new, viable ways to address the demand > for provider-independent addresses. The door is always open to finding better ways to do things. Instead of promising greener grass, prove it first. In 10 years, the IRTF RRG has not figured out a PI space they are willing to live with. It is incumbent on the IPv6 WG to deliver a viable PI replacement BEFORE removing the only PI addressing model we have. 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 Apr 5 08:33:18 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 h35GXIPL026505; Sat, 5 Apr 2003 08:33:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35GXIjm026504; Sat, 5 Apr 2003 08:33: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.9+Sun/8.12.9) with ESMTP id h35GXFPL026497 for ; Sat, 5 Apr 2003 08:33:15 -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 h35GXNHP018330 for ; Sat, 5 Apr 2003 08:33:23 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA19821 for ; Sat, 5 Apr 2003 09:33:18 -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; Sat, 5 Apr 2003 16:33: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; Sat, 5 Apr 2003 16:29: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, 5 Apr 2003 16:33:17 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; Sat, 5 Apr 2003 16:33:17 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA02820; Sat, 5 Apr 2003 08:32:39 -0800 (PST) Message-Id: <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 05 Apr 2003 11:31:21 -0500 To: From: Margaret Wasserman Subject: RE: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Cc: "'Mika Liljeberg'" , =?iso-8859-1?Q?=22=27Patrik_F=E4ltstr=F6m=27=22?= , "'Dan Lanciani'" , In-Reply-To: <0bcc01c2fb90$0da62590$ee1a4104@eagleswings> References: <5.1.0.14.2.20030405064207.03d13d60@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 Tony, >So even though the routing research group has not come up with a >solution that simultaneously addresses all three of these in the last 10 >years of focused work, the IPv6 WG will promise to come up with a >solution quickly if we just deprecate the only viable approach we know >of first. I guess it shouldn't surprise me that the herd mentality is so >willing to buy the promise of a better way rather than face reality, but >it still does. Please stop twisting and misinterpreting everything that anyone posts to the list who disagrees with you. The above is NOT what I said. I _said_ that we really want these things, but they are mutually exclusive, therefore: > > So, network administrators will be forced to choose between > > global-routability and provider-independence for their > > internal addressing. And, as we've learned in IPv4, there > > are a fairly large number of people who will choose > > provider-independence over global-routability. >They are forced to choose in IPv4 because it is too difficult to assign >multiple addresses to an interface. That issue goes away with IPv6, so >the 'forced to choose' concept is coming from those who don't want to >deal with the issues raised. Tony, allowing an interface to have two addresses: - One that is globally routable and globally accessible, and - One that is stable and local, is _exactly_ what I am proposing. However, I am proposing that there is _no reason_ why the stable, local addresses have to be ambiguous. 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 Apr 5 08:34:02 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 h35GY1PL026525; Sat, 5 Apr 2003 08:34:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35GY18x026524; Sat, 5 Apr 2003 08:34: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.9+Sun/8.12.9) with ESMTP id h35GXvPL026517 for ; Sat, 5 Apr 2003 08:33:57 -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 h35GY2cU021369 for ; Sat, 5 Apr 2003 08:34:02 -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.3p2+Sun/8.9.3) with ESMTP id JAA01431 for ; Sat, 5 Apr 2003 09:33:56 -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, 5 Apr 2003 16:33: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; Sat, 5 Apr 2003 16:33: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; Sat, 5 Apr 2003 16:33:55 Z Received: from psg.com (psg.com [147.28.0.62]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 16:33:55 Z Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 191qc4-000Oct-00; Sat, 05 Apr 2003 08:33:52 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 191mGY-000GaV-00; Sat, 05 Apr 2003 03:55:22 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 5 Apr 2003 03:55:21 -0800 To: "Tom Petch" Cc: , "Margaret Wasserman" Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing References: <002001c2face$cd2ed280$0301a8c0@tom3> Message-Id: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > NO -- Do not deprecate site-local unicast addressing. > > They are needed for access control in enterprise (as opposed to > home/private use) networks i.e. let's solve a routing problem with an address model hack. pfui! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 5 09:01:16 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 h35H1GPL027184; Sat, 5 Apr 2003 09:01:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35H1FNO027183; Sat, 5 Apr 2003 09:01: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.9+Sun/8.12.9) with ESMTP id h35H1CPL027176 for ; Sat, 5 Apr 2003 09:01:12 -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 h35H1LHP022908 for ; Sat, 5 Apr 2003 09:01: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.3p2+Sun/8.9.3) with ESMTP id JAA27141 for ; Sat, 5 Apr 2003 09:01:15 -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, 5 Apr 2003 17:01:15 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, 5 Apr 2003 16:57: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; Sat, 5 Apr 2003 17:01:14 Z Received: from devil.pp.htv.fi ([213.243.180.132] [213.243.180.132]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 17:01:13 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 h35GuW4l026266; Sat, 5 Apr 2003 19:56:33 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h35GuSk5026265; Sat, 5 Apr 2003 19:56:28 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve From: Mika Liljeberg To: Margaret Wasserman Cc: alh-ietf@tndh.net, "\"'Patrik" =?ISO-8859-1?Q?F=E4ltstr=F6m=27=22?= , "'Dan Lanciani'" , ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> References: <5.1.0.14.2.20030405064207.03d13d60@mail.windriver.com> <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1049561787.20483.90.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2003 19:56:28 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, On Sat, 2003-04-05 at 19:31, Margaret Wasserman wrote: > Tony, allowing an interface to have two addresses: > > - One that is globally routable and globally accessible, and > - One that is stable and local, > > is _exactly_ what I am proposing. > > However, I am proposing that there is _no reason_ why the stable, local > addresses have to be ambiguous. Then I would propose that this solution must be introduced at the same time the current FECO::/10 is deprecated, in a new version of the addressing architecture. That I would have no objections to. Let's stop the April Fools' poll now and start writing some drafts. 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 Apr 5 10:08: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 h35I8nPL027546; Sat, 5 Apr 2003 10:08:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35I8nSg027545; Sat, 5 Apr 2003 10:08: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.9+Sun/8.12.9) with ESMTP id h35I8kPL027538 for ; Sat, 5 Apr 2003 10:08:46 -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 h35I8scU007620 for ; Sat, 5 Apr 2003 10:08:55 -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.3p2+Sun/8.9.3) with ESMTP id LAA28433 for ; Sat, 5 Apr 2003 11:08: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; Sat, 5 Apr 2003 18:08: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; Sat, 5 Apr 2003 18:08: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; Sat, 5 Apr 2003 18:08:48 Z Received: from psg.com (psg.com [147.28.0.62]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 18:08:48 Z Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 191s5w-000B14-00 for ipng@sunroof.eng.sun.com; Sat, 05 Apr 2003 10:08:48 -0800 To: ipng@sunroof.eng.sun.com Reply-To: mankin@psg.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-reply-to: Your message of Sat, 05 Apr 2003 07:08:11 -0500. <5.1.0.14.2.20030405070046.03bcb260@mail.windriver.com> Date: Sat, 05 Apr 2003 10:08:48 -0800 From: Allison Mankin Message-Id: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing". Allison -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 5 11:20: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 h35JKOPL027924; Sat, 5 Apr 2003 11:20:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35JKORl027923; Sat, 5 Apr 2003 11:20: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 h35JKKPL027916 for ; Sat, 5 Apr 2003 11:20: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 h35JKTcU019474 for ; Sat, 5 Apr 2003 11:20:29 -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.3p2+Sun/8.9.3) with ESMTP id MAA01976 for ; Sat, 5 Apr 2003 12:20: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; Sat, 5 Apr 2003 19:20: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; Sat, 5 Apr 2003 19:20: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; Sat, 5 Apr 2003 19:20:23 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; Sat, 5 Apr 2003 19:20:22 Z Content-class: urn:content-classes:message Subject: RE: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Apr 2003 11:20:22 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F73B@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: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Thread-Index: AcL7kyI9DCBvap+OTJK1Y1uJnaIjGQAEnHFg From: "Michel Py" To: "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h35JKLPL027917 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > Margaret Wasserman wrote: > Tony, allowing an interface to have two addresses: > - One that is globally routable and globally accessible, > and > - One that is stable and local, > is _exactly_ what I am proposing. > However, I am proposing that there is _no reason_ why > the stable, local addresses have to be ambiguous. These are worthy goals and I like them very much. However, given the history, I think you put them in the wrong order. I would like to see: 1. - One that is stable and local and not ambiguous. then 2. - One that is globally routable and globally accessible. Although there is nothing that says that 1 needs to be delivered before 2, I will remind everyone that the quest for 2 has started 10 years ago and that we still have to see a result. As of 1, it has its own set of challenges, one being that there must be some kind of architectural limitation to prevent it to become 2 with a routing table explosion. I will post soon more details about what I think is required to achieve 1. 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 Sat Apr 5 12:24:18 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 h35KOIPL028357; Sat, 5 Apr 2003 12:24:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35KOIkv028356; Sat, 5 Apr 2003 12:24: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.9+Sun/8.12.9) with ESMTP id h35KOFPL028349 for ; Sat, 5 Apr 2003 12:24: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 h35KONcU000089 for ; Sat, 5 Apr 2003 12:24: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.3p2+Sun/8.9.3) with ESMTP id NAA07696 for ; Sat, 5 Apr 2003 13:24: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; Sat, 5 Apr 2003 20:24: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; Sat, 5 Apr 2003 20:24: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, 5 Apr 2003 20:24:15 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 20:24:15 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA16204; Sat, 5 Apr 2003 15:24:11 -0500 (EST) Date: Sat, 5 Apr 2003 15:24:11 -0500 (EST) From: Dan Lanciani Message-Id: <200304052024.PAA16204@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= wrote: |On lördag, apr 5, 2003, at 00:37 Europe/Stockholm, Dan Lanciani wrote: | |> Great. Let's make this PI space available FIRST and THEN we can get |> rid |> of site-locals with little trouble. |> |> |Yes, aggregation can not happen, |> |but, so what? I claim the number of routes today is still manageable, |> |and the _real_ problem is that an IP address is both for addressing |> and |> |routing. |> |> Great. Let's work on that problem now. | |Yes, of course we should. But, I think we can not get real force behind |such work before we _first_ agree Site Local is not solving this |problem, and we therefore agree Site Local should go away. Please help me to understand something. I have been trying to get people to look at the portable identifier/routing problem for _years_. Such attempts have been consistently shot down, often on grounds similar to the ones being used to attack site-locals, e.g., that we don't understand the problem well enough to even know whether research or engineering is required. (And no, I don't really understand why this--even if true--is a reason to not look at a problem. But that's a different question.) In fact, I believe some of the same people who want to deprecate site-locals are making the same arguments they used against solving the routing problem. Now, in all those years, nobody ever raised the claim that site-locals were an obstacle to working on the routing problem. Explain two things: -When (and how) did site-locals become the main obstacle standing in the way of solving the routing/identifier problem? -When (and how) did all the other reasons that have been advanced to stymie any work on the routing/identifier problem evaporate? Dan Lanciani ddl@danlan.*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 Apr 5 12:43:22 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 h35KhLPL028667; Sat, 5 Apr 2003 12:43:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35KhLri028666; Sat, 5 Apr 2003 12:43: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 h35KhIPL028659 for ; Sat, 5 Apr 2003 12:43:18 -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 h35KhQHP029727 for ; Sat, 5 Apr 2003 12:43:27 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA05288 for ; Sat, 5 Apr 2003 13:43:21 -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, 5 Apr 2003 20:43: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; Sat, 5 Apr 2003 20:40: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; Sat, 5 Apr 2003 20:43:21 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 20:43:20 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA16343; Sat, 5 Apr 2003 15:43:17 -0500 (EST) Date: Sat, 5 Apr 2003 15:43:17 -0500 (EST) From: Dan Lanciani Message-Id: <200304052043.PAA16343@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mika Liljeberg wrote: |> > Great. Let's work on that problem now. |> |> Yes, of course we should. But, I think we can not get real force behind |> such work before we _first_ agree Site Local is not solving this |> problem, and we therefore agree Site Local should go away. | |Forgive me for being cynical, but another way to phrase the above is |that the intent is to deny an existing solution to people who are |content with it in order to force them to work on a new one. You aren't being cynical enough. Once site-locals are gone there is absolutely no reason to believe that there will be any work on a new solution. We have had years and years to work on the routing/identifier problem and it has gone nowhere. The new "solution" for stable internal connections is going to be the same as the recently proposed "solution" for multi-homing: send more money to your ISP and they will make their links more reliable and refrain from renumbering you as frequently. Dan Lanciani ddl@danlan.*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 Apr 5 13:13: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 h35LDpPL028957; Sat, 5 Apr 2003 13:13:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35LDobJ028956; Sat, 5 Apr 2003 13:13: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 h35LDlPL028949 for ; Sat, 5 Apr 2003 13:13: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 h35LDuHP004539 for ; Sat, 5 Apr 2003 13:13: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.3p2+Sun/8.9.3) with ESMTP id NAA05037 for ; Sat, 5 Apr 2003 13:13:51 -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, 5 Apr 2003 21:13: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, 5 Apr 2003 21:13: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, 5 Apr 2003 21:13:38 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 21:13:37 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id QAA16453; Sat, 5 Apr 2003 16:13:33 -0500 (EST) Date: Sat, 5 Apr 2003 16:13:33 -0500 (EST) From: Dan Lanciani Message-Id: <200304052113.QAA16453@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Leif Johansson wrote: |Dan Lanciani wrote: | |>What makes you think that the apps people who say it *will not work* are |>correct? Especially when they are talking about models that are already in |>use? |> |> |> |Which models would that be exacly? Please re-read the message to which you initially responded. |I hope you are not talking about the lets |run-everything-over-http-model... I see no mention of such a thing anywhere in this thread. |The bottom line is that lots of |applications |are impossible to deploy on the Internet today because of rfc1918. Hardly. There are a few (not lots of) applications that are more difficult (not impossible) to deploy on the Internet today because of a restrictive address assignment policy (not because of rfc1918). Think about it. If there were no private address space and the nodes that currently use rfc1918 addresses had *no* addresses at all would they be able to run your hypothetical applications any better? Private address space and NAT are the effects--not the causes--of a restrictive address allocation policy. Would you deprive people of the address space they need to run the applications they need to run just to make it easier to write some other super-apps that those users don't care about? Dan Lanciani ddl@danlan.*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 Apr 5 13:16:10 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 h35LG9PL029006; Sat, 5 Apr 2003 13:16:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35LG9rc029005; Sat, 5 Apr 2003 13:16: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 h35LG5PL028992 for ; Sat, 5 Apr 2003 13:16:05 -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 h35LGEcU012862 for ; Sat, 5 Apr 2003 13:16: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.3p2+Sun/8.9.3) with ESMTP id NAA09331 for ; Sat, 5 Apr 2003 13:16:09 -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, 5 Apr 2003 21:16: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; Sat, 5 Apr 2003 21:12: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; Sat, 5 Apr 2003 21:16:07 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; Sat, 5 Apr 2003 21:16:07 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA13379; Sat, 5 Apr 2003 13:15:12 -0800 (PST) Message-Id: <5.1.0.14.2.20030405153201.034f5e50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 05 Apr 2003 16:12:57 -0500 To: Dan Lanciani From: Margaret Wasserman Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200304052024.PAA16204@ss10.danlan.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Dan, >Please help me to understand something. I have been trying to get people to >look at the portable identifier/routing problem for _years_. Various people _have_ been looking at this problem for years. In fact, the IPv6 WG toyed with it for a while in the mid-1990s. I agree that this is _the_ problem that we (the IETF, not necessarily the IPv6 WG) need to fix if we want to have an architecturally clean Internet that scales. Is there a particular solution (or type of solution) that you favor? >-When (and how) did site-locals become the main obstacle standing in the >way of solving the routing/identifier problem? I don't see site-locals as an obstacle to solving this problem at all. So, if I said something that gave you that impression, I must have been unclear. The only obstacle to solving the routing/identifier problem (that I know of) is that we haven't found a solution to it (yet). So, people are currently forced to choose between global-routability and provider-independence in a particular address; no address has both properties. Some people will choose provider-independence over global-routability for (some of) their addresses. So, until we can solve the routing/identifier problem, we will be stuck with some type of provider-independent, local addressing. I just happen to think that site-locals (the FECO::/10 prefix, with the semantics currently defined in the scoped addressing architecture I-D) are a very poor way to provide local, provider-independent addressing. While local (non-globally-routed) addresses will always, by definition, be unreachable from some portions of the network, there is no reason why they need to be ambiguous. The ambiguity of site-locals creates a great deal of complexity, and imposes unnecessary limitations on their use. As long as people use firewalls for security, we will have unreachable addresses, and there really isn't any fundamental difference between an unreachable local address and an unreachable global address. Applications already have to deal with the fact that some addresses will be unreachable, and people who intentionally make some of their addresses unreachable already have to deal with the consequences (split DNS, inability to use some applications, etc.). But, there really isn't any excuse for creating ambiguous IPv6 addresses and expecting applications, routers and other parts of the protocol stack to deal with them... >-When (and how) did all the other reasons that have been advanced to stymie >any work on the routing/identifier problem evaporate? I never once suggested that there is a reason not to work on this problem. In fact, I think that it is vitally important to solve this problem, and people are working on it (in the IRTF and the multi6 WG, among other places). If you have a viable proposal to solve this problem, I'd love to see it. 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 Apr 5 13:43:14 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 h35LhEPL029511; Sat, 5 Apr 2003 13:43:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35LhEP0029510; Sat, 5 Apr 2003 13:43: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.9+Sun/8.12.9) with ESMTP id h35LhAPL029503 for ; Sat, 5 Apr 2003 13:43:10 -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 h35LhJHP009333 for ; Sat, 5 Apr 2003 13:43:19 -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.3p2+Sun/8.9.3) with ESMTP id NAA18929 for ; Sat, 5 Apr 2003 13:43: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; Sat, 5 Apr 2003 21:43:13 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, 5 Apr 2003 21:43: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, 5 Apr 2003 21:43:13 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; Sat, 5 Apr 2003 21:43:12 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 h35KdNW02472; Sat, 5 Apr 2003 22:39:23 +0200 Message-Id: <3E8F3EFA.3080802@it.su.se> Date: Sat, 05 Apr 2003 22:39:22 +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: Dan Lanciani CC: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs References: <200304052113.QAA16453@ss10.danlan.com> In-Reply-To: <200304052113.QAA16453@ss10.danlan.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: >the causes--of a restrictive address allocation policy. Would you deprive >people of the address space they need to run the applications they need to >run just to make it easier to write some other super-apps that those users > > No I want people to have global 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 Sat Apr 5 14:43:18 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 h35MhIPL029990; Sat, 5 Apr 2003 14:43:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35MhHcX029989; Sat, 5 Apr 2003 14:43: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.9+Sun/8.12.9) with ESMTP id h35MhEPL029982 for ; Sat, 5 Apr 2003 14:43:14 -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 h35MhNHP018247 for ; Sat, 5 Apr 2003 14:43: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.3p2+Sun/8.9.3) with ESMTP id OAA07001 for ; Sat, 5 Apr 2003 14:43: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; Sat, 5 Apr 2003 22:30:38 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, 5 Apr 2003 22:30: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; Sat, 5 Apr 2003 22:30:38 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 22:30:21 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id RAA17108; Sat, 5 Apr 2003 17:30:03 -0500 (EST) Date: Sat, 5 Apr 2003 17:30:03 -0500 (EST) From: Dan Lanciani Message-Id: <200304052230.RAA17108@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Leif Johansson wrote: |Dan Lanciani wrote: | |>the causes--of a restrictive address allocation policy. Would you deprive |>people of the address space they need to run the applications they need to |>run just to make it easier to write some other super-apps that those users |> |> | |No I want people to have global addresses! That may be what you want, but that is not what you have been saying. You are advocating taking away private address space. Contrary to recent popular (yet incomprehensible) thought these actions are not equivalent. How about you FIRST give people global addresses and THEN AFTER those people see that those addresses have the properties that they need in order to use their networks you can take away their private addresses? I'm sure that most people will willingly give up their private address space AFTER they have globals with the same (or better) level of stability. Dan Lanciani ddl@danlan.*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 Apr 5 15:12: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 h35NCpPL000340; Sat, 5 Apr 2003 15:12:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35NCpIt000339; Sat, 5 Apr 2003 15:12: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 h35NCmPL000332 for ; Sat, 5 Apr 2003 15:12: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 h35NCucU001909 for ; Sat, 5 Apr 2003 15:12: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.3p2+Sun/8.9.3) with ESMTP id QAA24045 for ; Sat, 5 Apr 2003 16:12: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; Sat, 5 Apr 2003 23:12: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; Sat, 5 Apr 2003 23:12: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; Sat, 5 Apr 2003 23:12:48 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; Sat, 5 Apr 2003 23:12:47 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 h35M9mW02585; Sun, 6 Apr 2003 00:09:49 +0200 Message-Id: <3E8F542C.30804@it.su.se> Date: Sun, 06 Apr 2003 00:09:48 +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: Dan Lanciani CC: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs References: <200304052230.RAA17108@ss10.danlan.com> In-Reply-To: <200304052230.RAA17108@ss10.danlan.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: > >That may be what you want, but that is not what you have been saying. You >are advocating taking away private address space. Contrary to recent popular >(yet incomprehensible) thought these actions are not equivalent. How about >you FIRST give people global addresses and THEN AFTER those people see that >those addresses have the properties that they need in order to use their >networks you can take away their private addresses? I'm sure that most people >will willingly give up their private address space AFTER they have globals >with the same (or better) level of stability. > > I was not aware that there was a problem getting global v6 addresses! Please explain. Or perhaps you are thinking about global addresses with certain properties (provider independence perhaps)? Please make the distinction for the sake of clarity. BTW There is a flaw in your reasoning; people never give up any type of addresses, private or global. Once products are shipping with support for v6 private addresses thats it. Private addresses won't go away if we let the cat out of the bag now. 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 Sat Apr 5 15:16:12 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 h35NGCPL000391; Sat, 5 Apr 2003 15:16:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35NGCAM000390; Sat, 5 Apr 2003 15: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.9+Sun/8.12.9) with ESMTP id h35NG8PL000383 for ; Sat, 5 Apr 2003 15:16: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 h35NGHcU002546 for ; Sat, 5 Apr 2003 15:16: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.3p2+Sun/8.9.3) with ESMTP id QAA28245 for ; Sat, 5 Apr 2003 16:16: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; Sat, 5 Apr 2003 23:16:09 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, 5 Apr 2003 23:16:09 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, 5 Apr 2003 23:16:09 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; Sat, 5 Apr 2003 23:16:07 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA12431; Sat, 5 Apr 2003 15:15:37 -0800 (PST) Message-Id: <5.1.0.14.2.20030405180157.034f5e50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 05 Apr 2003 18:14:20 -0500 To: Dan Lanciani From: Margaret Wasserman Subject: Re: Why I support deprecating SLs Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200304052230.RAA17108@ss10.danlan.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >That may be what you want, but that is not what you have been saying. You >are advocating taking away private address space. What private address space do you think that these people have now that we are advocating "taking away"? The site-local prefix is defined in the addressing architecture, but nothing about its usage is defined there. There are three documents published that define different possibilities for the usage of site-local addressing, The most complete proposal is the "full" proposal defined in the scoped addressing architecture, a WG I-D. It is pretty clear at this point, though (and has been since Yokohama last summer, at least) that we don't have WG consensus to send the current scoped addressing architecture document to the IESG for publication as an RFC. The other two documented proposals for site-local usage are the "moderate" proposal and the "limited" proposal, personal drafts from Bob Hinden and me, respectively. All three of these usage models are consistent with the definition of the site-local prefix that appears in the addressing architecture. The WG officially rejected the "full" proposal at the Atlanta IETF. At that time, we did not have other proposals documented, but we had discussed the range of possible proposals and had agreed to consider something between the "moderate" and "limited" proposals, so Bob and I documented them. In San Francisco, it became clear that all of the proposals for site-local usage have issues that outweigh their benefits. So, it is certainly safe to say that we don't have _any_ proposal on the table for the usage of site-local addresses that currently has WG consensus. So, what is it that you think we are "taking away"? The proposal is to deprecate a prefix in the addressing architecture for which we have found no suitable use. There are parts of the scoped addressing architecture (multicast scopes and link-local) on which we do seem to have WG consensus. And, I do hope that those parts will be finalized and progressed ASAP. 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 Apr 5 15:37: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 h35NbPPL000871; Sat, 5 Apr 2003 15:37:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35NbP9x000870; Sat, 5 Apr 2003 15:37: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 h35NbMPL000863 for ; Sat, 5 Apr 2003 15:37: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 h35NbVHP028309 for ; Sat, 5 Apr 2003 15:37:31 -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.3p2+Sun/8.9.3) with ESMTP id PAA29705 for ; Sat, 5 Apr 2003 15:37:24 -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, 5 Apr 2003 23:31:57 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, 5 Apr 2003 23:28: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; Sat, 5 Apr 2003 23:31:15 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 23:31:12 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id SAA17359; Sat, 5 Apr 2003 18:31:07 -0500 (EST) Date: Sat, 5 Apr 2003 18:31:07 -0500 (EST) From: Dan Lanciani Message-Id: <200304052331.SAA17359@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: |>Please help me to understand something. I have been trying to get people to |>look at the portable identifier/routing problem for _years_. | |Various people _have_ been looking at this problem for years. In fact, |the IPv6 WG toyed with it for a while in the mid-1990s. Yes, I've participated in some of the toying. But that's the problem--it is at best toying. The discussion is always shot down for the same reasons that are now being used against site-locals, e.g., ``this is just such a complicated problem that we can't begin to deal with it.'' A good thing that may be coming from the site-local debate is a loss of credibility for that particular excuse and/or its users. It's one thing to hand-wave portable identifiers into the nether-realm of implementation impossibility given the number of steps that separate them from current practice--this is enough to confuse anyone. Using that approach to claim that it is impossibly complicated for local addresses to protect internal connections from global renumbering begins to sound a little suspect given that people are already doing exactly that particular impossibly complicated thing. With any luck this may induce folks to reexamine the assumptions behind other unsubstantiated declarations of impossibility... |I agree that |this is _the_ problem that we (the IETF, not necessarily the IPv6 WG) |need to fix if we want to have an architecturally clean Internet that |scales. I suggest that any such solution has to start here for two reasons. First, even the least intrusive solution is going to involve far-reaching changes (even if those changes are minor) in many aspects of the stack. No other forum has the required scope (no pun intended). Second, no solution is going to be free. There will be implementation costs and probably ongoing operational/performance costs. Agreement on these costs must come from a broad base. And this latter is a sticking point. I've asked a number of times over the years for opinions on what cost we are willing to pay for a solution. The problem seems to be that some people believe that having a solution has no (or even negative) value. Thus they are unwilling to allow for any cost... |Is there a particular solution (or type of solution) that |you favor? Not really; I'd be ok with just about any solution. Realistically, if we were actually going to do something at this late stage, the least disruptive solutions would probably be quasi-source-routing using the current addresses as a fixed-length route in conjunction with a new portable identifier (which could be the same size as an address) or some version of auto-tunnels. If I were revamping routing from scratch I would probably favor pure source routing since it is a totally scalable solution. There are many possible approaches with various cost/benefit tradeoffs. |>-When (and how) did site-locals become the main obstacle standing in the |>way of solving the routing/identifier problem? | |I don't see site-locals as an obstacle to solving this problem at |all. So, if I said something that gave you that impression, I must |have been unclear. My comment was directed to Patrick and those others who assert that eliminating site-locals is a prerequisite. Since we are in agreement that this is not the case, how about we shelve the site-local deprecation process until a routing solution can be found? If that problem is in fact solved, the elimination of site-locals will be far less contentious. On the other hand, if the routing problem cannot be solved, at least we will have site-locals as a fallback. |The only obstacle to solving the routing/identifier |problem (that I know of) is that we haven't found a solution to it (yet). Hmm, well, I still think that the economic aspects of PA addressing play a part. But I'll be happy to be proved wrong. |So, people are currently forced to choose between global-routability |and provider-independence in a particular address; no address has |both properties. Some people will choose provider-independence over |global-routability for (some of) their addresses. So, until we |can solve the routing/identifier problem, we will be stuck with some |type of provider-independent, local addressing. | |I just happen to think that site-locals (the FECO::/10 prefix, with |the semantics currently defined in the scoped addressing architecture |I-D) are a very poor way to provide local, provider-independent |addressing. However poor, site-locals are the _only_ currently defined local address. If we remove them then people will have no choice at all. Also keep in mind that at least some aspect of the scoped architecture is necessary to insure that both ends of an internal connection are really using local addresses. This is independent of the specific form of the local address. |While local (non-globally-routed) addresses will always, by definition, |be unreachable from some portions of the network, there is no reason why |they need to be ambiguous. The ambiguity of site-locals creates a great |deal of complexity, and imposes unnecessary limitations on their use. Personally, I have no need for ambiguity. In fact, I would be happier with completely unique locals because then I can build a layer of routing on top of them with auto-tunnels. But again, I don't think that unambiguous addresses actually relieve you of the scoping problem. |>-When (and how) did all the other reasons that have been advanced to stymie |>any work on the routing/identifier problem evaporate? | |I never once suggested that there is a reason not to work on this |problem. In fact, I think that it is vitally important to solve |this problem, and people are working on it (in the IRTF and the |multi6 WG, among other places). If you have a viable proposal to |solve this problem, I'd love to see it. Check the archives. Dan Lanciani ddl@danlan.*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 Apr 5 15:44: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 h35NiPPL001008; Sat, 5 Apr 2003 15:44:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35NiONG001007; Sat, 5 Apr 2003 15:44: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 h35NiLPL000997 for ; Sat, 5 Apr 2003 15:44:21 -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 h35NiTcU007207 for ; Sat, 5 Apr 2003 15:44:30 -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.3p2+Sun/8.9.3) with ESMTP id QAA06549 for ; Sat, 5 Apr 2003 16:44:19 -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; Sat, 5 Apr 2003 23:43:39 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; Sat, 5 Apr 2003 23:43: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; Sat, 5 Apr 2003 23:43:39 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 23:43:39 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id SAA17457; Sat, 5 Apr 2003 18:43:35 -0500 (EST) Date: Sat, 5 Apr 2003 18:43:35 -0500 (EST) From: Dan Lanciani Message-Id: <200304052343.SAA17457@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Leif Johansson wrote: |Dan Lanciani wrote: | |> |>That may be what you want, but that is not what you have been saying. You |>are advocating taking away private address space. Contrary to recent popular |>(yet incomprehensible) thought these actions are not equivalent. How about |>you FIRST give people global addresses and THEN AFTER those people see that |>those addresses have the properties that they need in order to use their |>networks you can take away their private addresses? I'm sure that most people |>will willingly give up their private address space AFTER they have globals |>with the same (or better) level of stability. |> |> |I was not aware that there was a problem getting global v6 addresses! |Please explain. |Or perhaps you are thinking about global addresses with certain |properties I think you know exactly what I am thinking about. |(provider |independence perhaps)? Please make the distinction for the sake of clarity. Re-read what I wrote above. Give them globals with the same (or better) level of stability as their private addresses. |BTW There is a flaw in your reasoning; people never give up any type of |addresses, |private or global. So how exactly do they hang onto non-portable global addresses they got from an ISP when they switch to another IPS? |Once products are shipping with support for v6 |private addresses |thats it. Private addresses won't go away if we let the cat out of the |bag now. Really? What happened to all those wonderful new applications that depend on eliminating private address space? You are saying that people will go on using private address space even if they have suitable globals? I guess that implies that they didn't really want those new applications after all... Dan Lanciani ddl@danlan.*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 Apr 5 15:49: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 h35NniPL001202; Sat, 5 Apr 2003 15:49:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h35Nniug001201; Sat, 5 Apr 2003 15: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 eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h35NnePL001191 for ; Sat, 5 Apr 2003 15:49:40 -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 h35NnmuK010014; Sat, 5 Apr 2003 18:49:48 -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 h35NnmfG026345; Sat, 5 Apr 2003 18:49:48 -0500 (EST) Message-Id: <200304052349.h35NnmfG026345@strat.East.Sun.COM> X-Mailer: exmh version 2.6.2 03/21/2003 with nmh-1.0.4 To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com From: Sebastien Roy Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: Message from Margaret Wasserman of "Tue, 01 Apr 2003 14:37:56 EST." <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Apr 2003 18:49:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing -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 Sat Apr 5 16:00: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 h3600uPL001623; Sat, 5 Apr 2003 16:00:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3600uA3001622; Sat, 5 Apr 2003 16:00: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.9+Sun/8.12.9) with ESMTP id h3600rPL001615 for ; Sat, 5 Apr 2003 16:00: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 h36012cU010447 for ; Sat, 5 Apr 2003 16:01:02 -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.3p2+Sun/8.9.3) with ESMTP id QAA09258 for ; Sat, 5 Apr 2003 16:00: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; Sat, 5 Apr 2003 23:59: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; Sat, 5 Apr 2003 23:59: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; Sat, 5 Apr 2003 23:59:46 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 5 Apr 2003 23:59:45 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id SAA17506; Sat, 5 Apr 2003 18:59:28 -0500 (EST) Date: Sat, 5 Apr 2003 18:59:28 -0500 (EST) From: Dan Lanciani Message-Id: <200304052359.SAA17506@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: |So, it is certainly safe to say that we don't have _any_ |proposal on the table for the usage of site-local addresses |that currently has WG consensus. So, what is it that you |think we are "taking away"? | |The proposal is to deprecate a prefix in the addressing |architecture for which we have found no suitable use. My mistake. I thought we were voting on something more meaningful, i.e., site-locals themselves. Now I understand that site-locals do not exist as such and we were just voting on the deprecation of the prefix itself. This actually makes it all the more amazing that anyone would claim that the mere existence of that prefix in an undeprecated state is the stumbling block preventing us from solving the routing problem that has been around for a decade or so. As I'm sure the prefix will indeed be deprecated, I look forward to seeing serious discussions of those routing solutions very soon. Dan Lanciani ddl@danlan.*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 Apr 5 16:06: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 h36063PL001811; Sat, 5 Apr 2003 16:06:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h36062kt001810; Sat, 5 Apr 2003 16: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.9+Sun/8.12.9) with ESMTP id h3605wPL001792 for ; Sat, 5 Apr 2003 16:05: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 h36067HP003911 for ; Sat, 5 Apr 2003 16:06: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.3p2+Sun/8.9.3) with ESMTP id RAA17332 for ; Sat, 5 Apr 2003 17:06: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; Sun, 6 Apr 2003 00:05: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; Sun, 6 Apr 2003 00:05:56 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, 6 Apr 2003 00:05:55 Z Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 6 Apr 2003 00:05:54 Z Received: by mail-green.research.att.com (Postfix, from userid 612) id 7BA901D748A; Sat, 5 Apr 2003 19:10:31 -0500 (EST) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mail-green.research.att.com (Postfix) with ESMTP id 361831D7489; Sat, 5 Apr 2003 19:10:31 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h36059Vq007731; Sat, 5 Apr 2003 19:05:09 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h3605oM06248; Sat, 5 Apr 2003 16:05:50 -0800 (PST) Message-Id: <200304060005.h3605oM06248@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Cc: mrw@windriver.com Date: Sat, 5 Apr 2003 16:05:49 -0800 Date: Sat, 5 Apr 2003 16:05:49 -0800 Versions: dmail (solaris) 2.5a/makemail 2.9d X-Spam-Status: No, hits=-105.9 required=5.0 tests=BAYES_00,INVALID_DATE,USER_IN_WHITELIST version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing". 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 Sun Apr 6 00:04:18 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 h3684IPL003244; Sun, 6 Apr 2003 00:04:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3684IUc003243; Sun, 6 Apr 2003 00:04: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.9+Sun/8.12.9) with ESMTP id h3684FPL003236 for ; Sun, 6 Apr 2003 00:04:15 -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 h3684McU013520 for ; Sun, 6 Apr 2003 00:04:22 -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.3p2+Sun/8.9.3) with ESMTP id AAA07726 for ; Sun, 6 Apr 2003 00:04:15 -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; Sun, 6 Apr 2003 08:03: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; Sun, 6 Apr 2003 08:03:46 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, 6 Apr 2003 08:03:46 Z Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 6 Apr 2003 08:03:42 Z Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3681jTY009234; Sun, 6 Apr 2003 10:01:50 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 6 Apr 2003 10:02:51 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 6 Apr 2003 10:02:51 +0200 Date: Sun, 6 Apr 2003 10:02:40 +0200 Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipng@sunroof.eng.sun.com To: Dan Lanciani From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <200304052024.PAA16204@ss10.danlan.com> Message-Id: <23982A6A-6806-11D7-81E1-000A959CF516@cisco.com> X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 06 Apr 2003 08:02:51.0527 (UTC) FILETIME=[EBC9B170:01C2FC12] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3684FPL003237 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On lördag, apr 5, 2003, at 22:24 Europe/Stockholm, Dan Lanciani wrote: > -When (and how) did site-locals become the main obstacle standing in > the > way of solving the routing/identifier problem? > > -When (and how) did all the other reasons that have been advanced to > stymie > any work on the routing/identifier problem evaporate? From my point of view, as an apps person, people stopped looking at these alternatives when they found out they can force applications to have clue about routing topologies, force applications to use this clue to do clever source address selections, and more people started thinking Site Local was not only a solution to this, but also the magic pixie-dust which solves other problems as well. The problem I see is that we have the classical hammer problem here. You have a hammer, or manage to define something which looks like a hammer, and feels like a hammer, and then you look for nails. This is something we see in many areas of the IETF, including Applications Area where I was Area Director for 5 years until March this year (so I am not blaming other Areas for these things). Maybe it is because Internet technologies are so difficult to understand nowadays one only look at a solution within the space one work in, and then ignore (more or less) the cost in other areas? Take the multiple addresses for example, which applications people hate. The way an application do it's work is like the following: - Take a hostname - Call gethostbyname (and get a struct back with (at least) one IP address) - Ask the IP strack to connect to whatever is described by that struct That's pretty simple, isnt't it? Further, another general rule for applications is: If A uses address a(B) to contact B, C should also use a(B), because so many applications work in a scenario where A send to C not "B", but a(B), i.e. the address. So, for applications to work, one need to only use global addresses all the time. Or, one can patch in local addressing by using things similar to split-DNS, which really is not a fun thing, because one get a view of the world which is different depending on where you are looking from. I.e. context dependent. Note that I only talk about addressing in the above. Not routing. So, yes, it would be very natural to talk much more about differentiating between routing and addressing. Maybe one doesn't talk about it because for example apps and internet people don't talk so much with each other? paf -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 6 01:15:30 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 h369FUPL003868; Sun, 6 Apr 2003 01:15:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h369FUX4003867; Sun, 6 Apr 2003 01: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h369FNPL003851 for ; Sun, 6 Apr 2003 01:15: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 h369FUcU005046 for ; Sun, 6 Apr 2003 01:15: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.3p2+Sun/8.9.3) with ESMTP id DAA27509 for ; Sun, 6 Apr 2003 03:15:23 -0600 (MDT) 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, 6 Apr 2003 09:15:21 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; Sun, 6 Apr 2003 09:15:21 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, 6 Apr 2003 09:15:21 Z Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 6 Apr 2003 09:15:20 Z Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1926FC-0007zo-00 for ipng@sunroof.eng.sun.com; Sun, 06 Apr 2003 10:15:18 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1926FC-0007zj-00 for ipng@sunroof.eng.sun.com; Sun, 06 Apr 2003 10:15:18 +0100 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA89354 for ; Sun, 6 Apr 2003 10:15:16 +0100 Message-Id: <3E8FED01.DF1044EE@hursley.ibm.com> Date: Sun, 06 Apr 2003 11:01:53 +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: Scope as seen by middleware [Re: My Thoughts on Site-Locals] References: <0b6f01c2fad6$59c715c0$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: > > Christian Huitema wrote: > > ... > > Bad, bad application developers. We should really punish them! :-) > > Recognizing the smile, punishment was not my point. What many are > missing here is that the perspective of a single address scope does not, > and will not match the reality of the deployed network. Which means we need to give the middleware community good tools for dealing with scope, and the reality of scope is more like a Venn diagram than concentric circles. And as Tony has been saying, this is a fact of life, and little to do with how we structure the IPv6 addressing architecture. The same is true of 2-faced or rather multi-faced DNS, however much this may offend some people. It's a fact of life that middleware needs to deal with. I think this is largely an issue that has nothing to do with IPv6 at all, in fact. It's an issue of what kind of API is needed to expose scope choices to middleware, even with IPv4. 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 Sun Apr 6 01:15: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 h369FTPL003865; Sun, 6 Apr 2003 01:15:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h369FT4m003864; Sun, 6 Apr 2003 01:15: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.9+Sun/8.12.9) with ESMTP id h369FNPL003848 for ; Sun, 6 Apr 2003 01:15:23 -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 h369FUcU005044 for ; Sun, 6 Apr 2003 01:15:30 -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.3p2+Sun/8.9.3) with ESMTP id BAA04157 for ; Sun, 6 Apr 2003 01:15: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; Sun, 6 Apr 2003 09:15: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; Sun, 6 Apr 2003 09:15: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; Sun, 6 Apr 2003 09:15:18 Z Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 6 Apr 2003 09:15:17 Z Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1926F8-0007zg-00 for ipng@sunroof.eng.sun.com; Sun, 06 Apr 2003 10:15:14 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1926F8-0007zb-00 for ipng@sunroof.eng.sun.com; Sun, 06 Apr 2003 10:15:14 +0100 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA90536 for ; Sun, 6 Apr 2003 10:15:13 +0100 Message-Id: <3E8FEA1D.E637286D@hursley.ibm.com> Date: Sun, 06 Apr 2003 10:49:33 +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: free prefix allocation service References: <963621801C6D3E4A9CF454A1972AE8F504F72A@server2000.arneill-py.sacramento.ca.us> <20030404173003.GA7727@alicia.nttmcl.com> <3E8DD207.1090903@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I suspect there is a trivial DOS attack against this, despite the one-per-day rule. We will need to think long and hard about how to make such a system both idiot-proof and sabotage-proof. Brian Alexandru Petrescu wrote: > > Shannon -jj Behrens wrote: > > This is fine as long as Nokia never goes out of business (I'm not > > being snide, I'm being practical). > > :-) > > In that eventuality there's one at http://gusl.nal.motlabs.com visible > both in v4 and v6. > > Not that I support gusl proposal, I must first understand it, but it > seems to me that at least it raises new issues like how to coordinate > between several sites wanting to offer such a service. Reliable > service and so on. This is something enormous to deal with... > > Back lurking... > > Alex > GBU -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 6 03:21: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 h36ALHPL004671; Sun, 6 Apr 2003 03:21:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h36ALHqD004670; Sun, 6 Apr 2003 03:21:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h36ALEPL004663 for ; Sun, 6 Apr 2003 03:21:14 -0700 (PDT) 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 h36ALLHP003307 for ; Sun, 6 Apr 2003 03:21:21 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA13212 for ; Sun, 6 Apr 2003 04:21:10 -0600 (MDT) 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, 6 Apr 2003 09:08: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; Sun, 6 Apr 2003 09:05: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; Sun, 6 Apr 2003 09:08:23 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 6 Apr 2003 09:08:21 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id FAA19880; Sun, 6 Apr 2003 05:08:14 -0400 (EDT) Date: Sun, 6 Apr 2003 05:08:14 -0400 (EDT) From: Dan Lanciani Message-Id: <200304060908.FAA19880@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= wrote: |On lördag, apr 5, 2003, at 22:24 Europe/Stockholm, Dan Lanciani wrote: | |> -When (and how) did site-locals become the main obstacle standing in |> the |> way of solving the routing/identifier problem? |> |> -When (and how) did all the other reasons that have been advanced to |> stymie |> any work on the routing/identifier problem evaporate? | | | From my point of view, as an apps person, people stopped looking at |these alternatives when they found out they can force applications to |have clue about routing topologies, force applications to use this clue |to do clever source address selections, and more people started |thinking Site Local was not only a solution to this, but also the magic |pixie-dust which solves other problems as well. | I understand why you might think that (especially given the recent discussions) but if you review the archives for the past few years I think you will see that site-locals did not play a significant role in discouraging the development of real routing/identifier solutions. Frankly I find it really disturbing that the issues are being coupled this way. Dan Lanciani ddl@danlan.*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 Apr 6 03:28:53 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 h36ASrPL004907; Sun, 6 Apr 2003 03:28:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h36ASrr3004906; Sun, 6 Apr 2003 03:28:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h36ASnPL004899 for ; Sun, 6 Apr 2003 03:28:49 -0700 (PDT) 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 h36ASvcU002929 for ; Sun, 6 Apr 2003 03:28:57 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA03774 for ; Sun, 6 Apr 2003 03:28:50 -0700 (PDT) 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, 6 Apr 2003 09:15: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; Sun, 6 Apr 2003 09:15:08 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, 6 Apr 2003 09:15:08 Z Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 6 Apr 2003 09:15:06 Z Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1926Es-0007ya-00; Sun, 06 Apr 2003 10:14:58 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1926Es-0007yV-00; Sun, 06 Apr 2003 10:14:58 +0100 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA52334; Sun, 6 Apr 2003 10:14:53 +0100 Message-Id: <3E8FF01E.BA74CDCA@hursley.ibm.com> Date: Sun, 06 Apr 2003 11: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: alh-ietf@tndh.net CC: ipng@sunroof.eng.sun.com Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve References: <0bcc01c2fb90$0da62590$ee1a4104@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, Tony Hain wrote: ... > ... It is > incumbent on the IPv6 WG to deliver a viable PI replacement BEFORE > removing the only PI addressing model we have. This is where we disagree. I think we have learnt since FEC0::/10 was defined (in 1995) that ambiguous PI space is *not* viable, as a result of the operational disaster of deploying RFC 1597/1918 space as defined in 1994. I think it's incumbent on us to deprecate this non-viable solution as quickly as possible, and then define something better. And I wish we'd seen this much earlier, since we now have to fix shipped products. (BTW, "deprecate" doesn't stop those products working.) As for whether we can do what the RRG has failed to do, of course not. But it seems fairly clear we can define unambiguous PI space. 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 Sun Apr 6 03:48:49 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 h36AmmPL005477; Sun, 6 Apr 2003 03:48:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h36Ammop005476; Sun, 6 Apr 2003 03:48:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h36AmjPL005469 for ; Sun, 6 Apr 2003 03:48:45 -0700 (PDT) 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 h36AmqcU006190 for ; Sun, 6 Apr 2003 03:48:52 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA03014 for ; Sun, 6 Apr 2003 04:48:46 -0600 (MDT) 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, 6 Apr 2003 09:34:27 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, 6 Apr 2003 09:29: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; Sun, 6 Apr 2003 09:32:27 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; Sun, 6 Apr 2003 09:32: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 h368TOW12151; Sun, 6 Apr 2003 10:29:24 +0200 Message-Id: <3E8FE564.2010006@it.su.se> Date: Sun, 06 Apr 2003 10:29:24 +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: Dan Lanciani CC: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs References: <200304052343.SAA17457@ss10.danlan.com> In-Reply-To: <200304052343.SAA17457@ss10.danlan.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: >|(provider >|independence perhaps)? Please make the distinction for the sake of clarity. > >Re-read what I wrote above. Give them globals with the same (or better) >level of stability as their private addresses. > > So you are talking about renumbering, provider independence, etc. IMO this discussion would benefit from a bit more precision. The heart of the problem as I see it is this: site-locals are put forward as a solution to problems that very few people in the IETF agree is enough of a problem to warrant fundamental change to the architecture. 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 Sun Apr 6 10:03: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 h36H3oPL007008; Sun, 6 Apr 2003 10:03:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h36H3ogx007007; Sun, 6 Apr 2003 10:03:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h36H3lPL007000 for ; Sun, 6 Apr 2003 10:03:47 -0700 (PDT) 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 h36H3sHP006040 for ; Sun, 6 Apr 2003 10:03:54 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA00564 for ; Sun, 6 Apr 2003 10:03:49 -0700 (PDT) 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, 6 Apr 2003 17:03: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; Sun, 6 Apr 2003 17:03:48 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, 6 Apr 2003 17:03:48 Z Received: from slimsixten.besserwisser.org (slimsixten.besserwisser.org [213.212.3.212]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 6 Apr 2003 17:03:47 Z Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id h36H3oAH001803 for ; Sun, 6 Apr 2003 19:03:52 +0200 (CEST) Date: Sun, 06 Apr 2003 19:03:36 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: "ipng@sunroof.eng.sun.com" Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Message-Id: <105640000.1049648616@localhost.besserwisser.org> In-Reply-To: <1049548162.20483.30.camel@devil> References: <05F1F15F-674F-11D7-81E1-000A959CF516@cisco.com> <05F1F15F-674F-11D7-81E1-000A959CF516@cisco.com> <5.1.0.14.2.20030405064207.03d13d60@mail.windriver.com> <1049548162.20483.30.camel@devil> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1910629384==========" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --==========1910629384========== Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Saturday, April 05, 2003 16:09:23 +0300 Mika Liljeberg wrote: > However, at this point deprecating site-local addresses will simply slow > down real world deployment of IPv6 and, in a very concrete way, take the > pressure off those who are the most motivated to work on better > solutions.=20 I am quite busy in rolling out v6 and v6 services, and nothing of what I do requires site-local or even benefits from it. What do you mean?=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========1910629384========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+kF3202/pMZDM1cURAuctAJ9NTrxLpo/xiTAiO1HlxK8onotWiQCfakT/ /fmAv0Q/9NVUT8hnm6fu3GM= =CPzm -----END PGP SIGNATURE----- --==========1910629384==========-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 6 11:02: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 h36I2KPL007337; Sun, 6 Apr 2003 11:02:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h36I2KP0007336; Sun, 6 Apr 2003 11:02:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h36I2GPL007329 for ; Sun, 6 Apr 2003 11:02:16 -0700 (PDT) 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 h36I2NcU028140 for ; Sun, 6 Apr 2003 11:02:23 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA10675 for ; Sun, 6 Apr 2003 12:02:18 -0600 (MDT) 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, 6 Apr 2003 18:02: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; Sun, 6 Apr 2003 18:02: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; Sun, 6 Apr 2003 18:02:17 Z Received: from devil.pp.htv.fi ([213.243.180.132] [213.243.180.132]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 6 Apr 2003 18:02:16 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 h36I3V4l003890; Sun, 6 Apr 2003 21:03:31 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h36I3Tmp003889; Sun, 6 Apr 2003 21:03:29 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve From: Mika Liljeberg To: =?ISO-8859-1?Q?M=E5ns?= Nilsson Cc: "ipng@sunroof.eng.sun.com" In-Reply-To: <105640000.1049648616@localhost.besserwisser.org> References: <05F1F15F-674F-11D7-81E1-000A959CF516@cisco.com> <05F1F15F-674F-11D7-81E1-000A959CF516@cisco.com> <5.1.0.14.2.20030405064207.03d13d60@mail.windriver.com> <1049548162.20483.30.camel@devil> <105640000.1049648616@localhost.besserwisser.org> Content-Type: text/plain; charset=ISO-8859-15 Organization: Message-Id: <1049652208.3004.26.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Apr 2003 21:03:29 +0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h36I2GPL007330 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Måns, On Sun, 2003-04-06 at 20:03, Måns Nilsson wrote: > > However, at this point deprecating site-local addresses will simply slow > > down real world deployment of IPv6 and, in a very concrete way, take the > > pressure off those who are the most motivated to work on better > > solutions. > > I am quite busy in rolling out v6 and v6 services, and nothing of what I do > requires site-local or even benefits from it. What do you mean? Your customers are mainly universities and research institutes, correct? I suspect that provider independence is not high on their list of priorities. If that were true in general, there would be no demand for PI addresses. What I mean is that commercial sites which require (or think they require) provider independence may put off adopting IPv6 while there is no deployable solution. This will slow commercial deployment of IPv6. 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 Apr 6 13:01:42 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 h36K1gPL008231; Sun, 6 Apr 2003 13:01:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h36K1g7f008230; Sun, 6 Apr 2003 13:01:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h36K1dPL008223 for ; Sun, 6 Apr 2003 13:01:39 -0700 (PDT) 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 h36K1kcU025012 for ; Sun, 6 Apr 2003 13:01:46 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id OAA29163 for ; Sun, 6 Apr 2003 14:01:41 -0600 (MDT) 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, 6 Apr 2003 20:01:40 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, 6 Apr 2003 20:01: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; Sun, 6 Apr 2003 20:01:39 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 6 Apr 2003 20:01:39 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id QAA21963; Sun, 6 Apr 2003 16:01:35 -0400 (EDT) Date: Sun, 6 Apr 2003 16:01:35 -0400 (EDT) From: Dan Lanciani Message-Id: <200304062001.QAA21963@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Leif Johansson wrote: |Dan Lanciani wrote: | |>|(provider |>|independence perhaps)? Please make the distinction for the sake of clarity. |> |>Re-read what I wrote above. Give them globals with the same (or better) |>level of stability as their private addresses. |> |> |So you are talking about renumbering, provider independence, etc. IMO |this discussion |would benefit from a bit more precision. The heart of the problem as I |see it is this: |site-locals are put forward as a solution to problems that very few |people in the IETF |agree is enough of a problem Well, that does clear things up a bit. I had heard that these problems were "hard" and that we were going to work on them "later," but your explanation makes more sense. |to warrant fundamental change to the |architecture. Could you clarify your terminology here? By ``fundamental change to the architecture'' do you mean _not_ removing the site-locals that have been a part of that architecture for years? So not making this ``fundamental change'' means changing the architecture to remove site-locals? Or are you saying that once site-locals are gone the IETF will be unwilling to allow any additional changes to the architecture to solve the renumbering, PI, etc. problems because these problems are not ``enough of a problem'' to warrant fundamental changes in the architecture? Dan Lanciani ddl@danlan.*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 Apr 6 14:06: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 h36L6XPL008670; Sun, 6 Apr 2003 14:06:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h36L6X5h008669; Sun, 6 Apr 2003 14:06:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h36L6UPL008662 for ; Sun, 6 Apr 2003 14:06:30 -0700 (PDT) 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 h36L6bHP028517 for ; Sun, 6 Apr 2003 14:06:37 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA19336 for ; Sun, 6 Apr 2003 14:06:31 -0700 (PDT) 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, 6 Apr 2003 21:06: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, 6 Apr 2003 21:01: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; Sun, 6 Apr 2003 21:04:57 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; Sun, 6 Apr 2003 21:04:57 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 h36K1sW12671; Sun, 6 Apr 2003 22:01:54 +0200 Message-Id: <3E9087B1.6010100@it.su.se> Date: Sun, 06 Apr 2003 22:01:53 +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: Dan Lanciani CC: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs References: <200304062001.QAA21963@ss10.danlan.com> In-Reply-To: <200304062001.QAA21963@ss10.danlan.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: > >Could you clarify your terminology here? By ``fundamental change to the >architecture'' do you mean _not_ removing the site-locals that have been a >part of that architecture for years? So not making this ``fundamental change'' >means changing the architecture to remove site-locals? > > > Disregarding your attitude; one part of the fundamental change I refer to (and the one I care most about) is the fact that applications will have to know about topology if site-local gets deployed. Address selection as described in the current address arch draft is imo undeployable. Moreover I don't believe that applications should have to care about address selection or know about topology. Judging from the traffic on the list and from the discussion at the mike in the SF meething i'd say that quite a few agree with me on that point. 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 Sun Apr 6 14: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 h36LQfPL008939; Sun, 6 Apr 2003 14:26:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h36LQf0w008938; Sun, 6 Apr 2003 14:26:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h36LQcPL008931 for ; Sun, 6 Apr 2003 14:26:38 -0700 (PDT) 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 h36LQjHP022609 for ; Sun, 6 Apr 2003 14:26:45 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id OAA27488 for ; Sun, 6 Apr 2003 14:26:40 -0700 (PDT) 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, 6 Apr 2003 21:26: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; Sun, 6 Apr 2003 21:26:34 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, 6 Apr 2003 21:26:33 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 6 Apr 2003 21:26:32 Z Received: from cisco.com (sjc-vpn1-853.cisco.com [10.21.99.85]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA14248; Sun, 6 Apr 2003 14:26:24 -0700 (PDT) Message-Id: <3E909B7F.2030606@cisco.com> Date: Sun, 06 Apr 2003 14:26:23 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Lanciani CC: ipng@sunroof.eng.sun.com Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve References: <200304052331.SAA17359@ss10.danlan.com> In-Reply-To: <200304052331.SAA17359@ss10.danlan.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: > However poor, site-locals are the _only_ currently defined local address. Nope. You can use IPv4. And one might as well. What is the benefit of IPv6 if we don't solve this problem? 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 Sun Apr 6 14:28: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 h36LSqPL008977; Sun, 6 Apr 2003 14:28:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h36LSppc008976; Sun, 6 Apr 2003 14:28:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h36LSmPL008969 for ; Sun, 6 Apr 2003 14:28:48 -0700 (PDT) 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 h36LSuHP025421 for ; Sun, 6 Apr 2003 14:28:56 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA02589 for ; Sun, 6 Apr 2003 15:28:50 -0600 (MDT) 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, 6 Apr 2003 21:28:39 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, 6 Apr 2003 21:25: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; Sun, 6 Apr 2003 21:28:31 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 6 Apr 2003 21:28:30 Z Received: from cisco.com (sjc-vpn1-853.cisco.com [10.21.99.85]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA15484; Sun, 6 Apr 2003 14:28:27 -0700 (PDT) Message-Id: <3E909BFA.8080003@cisco.com> Date: Sun, 06 Apr 2003 14:28:26 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Lanciani CC: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs References: <200304052359.SAA17506@ss10.danlan.com> In-Reply-To: <200304052359.SAA17506@ss10.danlan.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani wrote: > My mistake. I thought we were voting on something more meaningful, i.e., > site-locals themselves. Now I understand that site-locals do not exist > as such and we were just voting on the deprecation of the prefix itself. > This actually makes it all the more amazing that anyone would claim that > the mere existence of that prefix in an undeprecated state is the stumbling > block preventing us from solving the routing problem that has been around > for a decade or so. As I'm sure the prefix will indeed be deprecated, I > look forward to seeing serious discussions of those routing solutions very > soon. Clearly site-locals have been used as a crutch because the hard problems haven't been solved. Through my vote I am saying that we should go solve the hard problems. We have a working network for now. 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 Sun Apr 6 14:42: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 h36Lg0PL009479; Sun, 6 Apr 2003 14:42:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h36Lg0Yc009478; Sun, 6 Apr 2003 14:42:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h36LfuPL009471 for ; Sun, 6 Apr 2003 14:41:56 -0700 (PDT) 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 h36Lg4HP012918 for ; Sun, 6 Apr 2003 14:42:04 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA16267 for ; Sun, 6 Apr 2003 15:41:58 -0600 (MDT) 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, 6 Apr 2003 21:41:57 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, 6 Apr 2003 21:38: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; Sun, 6 Apr 2003 21:41:57 Z Received: from klapautius.it.su.se ([217.215.166.49] [217.215.166.49]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 6 Apr 2003 21:41:56 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 h36KcrW12765; Sun, 6 Apr 2003 22:38:53 +0200 Message-Id: <3E90905D.4000501@it.su.se> Date: Sun, 06 Apr 2003 22:38:53 +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: Eliot Lear CC: Dan Lanciani , ipng@sunroof.eng.sun.com Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve References: <200304052331.SAA17359@ss10.danlan.com> <3E909B7F.2030606@cisco.com> In-Reply-To: <3E909B7F.2030606@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eliot Lear wrote: >> However poor, site-locals are the _only_ currently defined local >> address. > > > Nope. You can use IPv4. And one might as well. What is the benefit > of IPv6 if we don't solve this problem? Exactly! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 6 16:24: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 h36NOqPL009931; Sun, 6 Apr 2003 16:24:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h36NOpvU009930; Sun, 6 Apr 2003 16:24:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h36NOmPL009923 for ; Sun, 6 Apr 2003 16:24:48 -0700 (PDT) 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 h36NOucU024661 for ; Sun, 6 Apr 2003 16:24:56 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA21988 for ; Sun, 6 Apr 2003 17:24:50 -0600 (MDT) 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, 6 Apr 2003 23:24: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; Sun, 6 Apr 2003 23:24: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; Sun, 6 Apr 2003 23:24:49 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 6 Apr 2003 23:24:49 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id TAA23162; Sun, 6 Apr 2003 19:24:45 -0400 (EDT) Date: Sun, 6 Apr 2003 19:24:45 -0400 (EDT) From: Dan Lanciani Message-Id: <200304062324.TAA23162@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eliot Lear wrote: |Dan Lanciani wrote: |> However poor, site-locals are the _only_ currently defined local address. | |Nope. You can use IPv4. And one might as well. That's true, of course, but it's a pretty depressing reality. How will it affect deployment if we have to tell users that switching to v6 means giving up functionality that they have come to depend on? |What is the benefit of |IPv6 if we don't solve this problem? Are you talking about solving the problem of site-locals by getting rid of them or solving the underlying problems (renumbering, routing, etc.) that drive people to need local address space in the first place? |Clearly site-locals have been used as a crutch because the hard problems |haven't been solved. I agree that site-locals have been offered as a substitute for more direct solutions to some difficult problems; however, I do not believe that the existence of site-locals has had even epsilon effect on the efforts to solve those difficult problems directly. Attempts to discuss alternate routing and portable identifier schemes usually meet with extremely vocal objections that we do not and can not even know how to begin thinking about the solutions. I'm not sure why we aren't hearing more of those objections now. |Through my vote I am saying that we should go |solve the hard problems. If that is indeed your goal (and I truly think a direct vote to solve the hard problems would be far more helpful than this indirect approach) I urge you to make your intent very clear. Others with whom you are voting have already expressed the opinion that the hard problems in question are unimportant/uninteresting and that solving them would not justify further changes in the architecture. Given a yes/no vote on a rather nebulous question, your vote may well be taken as agreement with these sentiments. |We have a working network for now. Yes, and it is going to be around for years to come. This is one reason I don't understand the huge rush to vote out site-locals. Why couldn't we take some time first to at least outline the alternate solutions we will offer to the underlying difficult problems? Dan Lanciani ddl@danlan.*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 Apr 6 17:24:58 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 h370OwPL010335; Sun, 6 Apr 2003 17:24:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h370Owde010334; Sun, 6 Apr 2003 17:24:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h370OsPL010327 for ; Sun, 6 Apr 2003 17:24:54 -0700 (PDT) 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 h370OwHP005269 for ; Sun, 6 Apr 2003 17:24:58 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id SAA12620 for ; Sun, 6 Apr 2003 18:24:52 -0600 (MDT) 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, 7 Apr 2003 00:24:23 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, 7 Apr 2003 00:23:48 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, 7 Apr 2003 00:23:48 Z Received: from ALPHA8.ITS.MONASH.EDU.AU (ALPHA8.ITS.MONASH.EDU.AU [130.194.1.8]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 00:23:48 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 <01KUFY0IBXZM9BXRVR@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 10:22:30 +1000 Received: from kapow.its.monash.edu.au (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 9528E20012; Mon, 07 Apr 2003 10:22:29 +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 43D692000F; Mon, 07 Apr 2003 10:22:28 +1000 (EST) Date: Mon, 07 Apr 2003 10:22:28 +1000 From: Greg Daley Subject: Re: My Thoughts on Site-Locals To: alh-ietf@tndh.net Cc: "'Randy Bush'" , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E90C4C4.1050304@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: <0bcb01c2fb8d$1c1390c0$ee1a4104@eagleswings> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tony, I think that your statement is correct (about SL providing a PI non routeable address system). I'm pretty sure though that SL is not a good solution for connected networks though because of the ambiguity issues which have been described endlessly. GUSL may work well enough, although any good scheme which provides globally routable (unique) provider independent addresses, will provide a valid prefix for site local. Please continue your work with the PI addressing scheme, since it has the opportunity remove the need for (ambiguous) connected SL. Greg D. Tony Hain wrote: > Randy Bush wrote: > >>just in case folk have short memories, i am strongly against >>site-locals. they attempt to solve a routing problem with an >>address hack, a la rfc 1918. they are unneeded complexity. >>now is the time to abjure them. > > > They solve an addressing problem PI, where other proposed approaches > create a routing problem. Until there is a routable PI space, we need an > unroutable one. We have to solve the problems in the right order. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 6 17:34: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 h370YRPL010789; Sun, 6 Apr 2003 17:34:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h370YRHL010788; Sun, 6 Apr 2003 17:34:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h370YNPL010778 for ; Sun, 6 Apr 2003 17:34:23 -0700 (PDT) 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 h370YUHP022353 for ; Sun, 6 Apr 2003 17:34:30 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id SAA16559 for ; Sun, 6 Apr 2003 18:34:25 -0600 (MDT) 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, 7 Apr 2003 00:34: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; Mon, 7 Apr 2003 00:34: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; Mon, 7 Apr 2003 00:34:24 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; Mon, 7 Apr 2003 00:34:23 Z Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KUFYEJ2LU49BXPII@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 10:33:48 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2EFF612C01C; Mon, 07 Apr 2003 10:33:47 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id B72D912C016; Mon, 07 Apr 2003 10:32:50 +1000 (EST) Date: Mon, 07 Apr 2003 10:32:50 +1000 From: Greg Daley Subject: Re: site-locals To: Erik Nordmark Cc: Mike Saywell , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E90C732.4080308@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 Erik and Mike, This work is obviously related to NEMO. If people have real requirements for network mobility, they can certainly take them there. Currently the base NEMO solution provides stable addresses from a home domain and provides tunneling to the home net. There are people who believe that long latencies from tunneling to this network are prohibitive for real time applications, and aim to gain route optimization analogous to that provided in MIPv6. I don't think there needs to be talk of either site-local or NAT in this context, unless the NEMO work cannot provide adequate solutions. Greg Erik Nordmark wrote: >>I think site-locals could be used here, with a single rule that they're >>simply the least preffered prefix used in address selection. >> >>Whilst the boat is in a port, it receives a global prefix which is >>advertised on appropriate subnets. Before leaving port the prefix >>is deprecated (but not removed), thus there would be no break in >>communications. It can be removed several days later safely when it's >>no longer in use. > > > Tony's requirements seemed to say that ship-local communication must never > break. I took that to mean imply in your example that the deprecated > prefix can never be invalidated. And that would cause problems when > the boat arrives in another port. > > >>This doesn't just apply to huge boats, what about a private yacht? >>This is another zero-conf issue, it has all the same problems as the >>research boat (getting connectivity via different providers depending >>on which port they're at) except that the owner may not have his own v6 >>prefix, or even know what IPv6 is! > > > Give specific requirements the way Tony did for the research ship and we > can analyse the options. > His requirement was that ship-local communication not be impacted > by the ships connection and disconnection to the Internet. > What requirements do you have in mind for the yacht? > > >>Finally I don't agree with your tunnelling solution at all (sorry it >>got ) . I would rather NAT and have a 10ms RTT insetad of 200ms, >>and if I would NAT here (I hate NAT!) then I think lots of other people >>would too. Tunnels are complicated NAT is easy... > > > I think we have to agree that we disagree on that one. > > 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 Sun Apr 6 18:48:42 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 h371mgPL011352; Sun, 6 Apr 2003 18:48:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h371mfmj011351; Sun, 6 Apr 2003 18:48:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h371mcPL011344 for ; Sun, 6 Apr 2003 18:48:38 -0700 (PDT) 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 h371mkHP000741 for ; Sun, 6 Apr 2003 18:48:46 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id TAA14063 for ; Sun, 6 Apr 2003 19:48:40 -0600 (MDT) 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, 7 Apr 2003 01:48:39 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, 7 Apr 2003 01:48: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; Mon, 7 Apr 2003 01:48:39 Z Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 01:48:38 Z Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h371leRn025304 for ; Sun, 6 Apr 2003 18:47:40 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id SAA19020 for ; Sun, 6 Apr 2003 18:48:31 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h371mYmE011218 for ; Mon, 7 Apr 2003 11:48:34 +1000 (EST) Message-Id: <3E90D8F2.2060505@motorola.com> Date: Mon, 07 Apr 2003 11:48:34 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Site Local == Network Address Translation? References: <200304042214.h34ME95s025556@m5p.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eliot Lear wrote: >>Since we have established that site-locals will encourage the use of NATs >>('cause that's how it's done today) I really struggle to see why people would use an IPv6-to-IPv6 NAT -- there just doesn't seem to be any incentive. If you wanted to deploy a NAT, surely you would pick an IPv4-to-IPv4 NAT and use IPv4 address space. The v4 "technology" is way more "mature" than the IPv6 equivalent, and that's how it is done today. - aidan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 6 19:40: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 h372ebPL011854; Sun, 6 Apr 2003 19:40:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h372eb6n011853; Sun, 6 Apr 2003 19:40:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h372eWPL011846 for ; Sun, 6 Apr 2003 19:40:33 -0700 (PDT) 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 h372eecU006707 for ; Sun, 6 Apr 2003 19:40:40 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id TAA01424 for ; Sun, 6 Apr 2003 19:40:34 -0700 (PDT) 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, 7 Apr 2003 02:40: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; Mon, 7 Apr 2003 02:40: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; Mon, 7 Apr 2003 02:40:15 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, 7 Apr 2003 02:40:15 Z Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h372eE4T026354 for ; Sun, 6 Apr 2003 19:40:14 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id TAA04866 for ; Sun, 6 Apr 2003 19:40:09 -0700 (MST)] Received: from motorola.com (mvp-10-238-2-243.corp.mot.com [10.238.2.243]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h372eAj17271 for ; Sun, 6 Apr 2003 21:40:10 -0500 Message-Id: <3E90E508.362F6EEC@motorola.com> Date: Mon, 07 Apr 2003 12:40:08 +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: Re: A different FEC0::/10 proposal References: <3E8D3F6D.3C780065@motorola.com> <3E8D8941.C0CF8359@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > > This doesn't resolve the problem of ambiguous subnet prefixes > when routing domains merge. So it doesn't go far enough IMHO. That's because dealing with uniqueness and merging is a deployment issue, not an architectural issue. The proposal specifies what the routing system and applications need to know about these restricted deployment addresses for correct general operation. Achieving the uniqueness criteria is actually rather easy. HOW to do it is up to the person deploying the site. Workable solutions include generating unique /64 subnet IDs ( draft-hinden-ipv6-global-site-local-00.txt, draft-white-auto-subnet-00.txt ), generating a /48 based on the MAC of the root router, or allocating a unique /48 from a registry. Of course, if you're in the mood to shoot yourself in the foot, you could number your site from fec0::/48. I think we need to divide the problem space into two parts: - Cleaning up site-local and scopes: - Enforcing the global unrouteability of the FEC0::/10 prefix. - Otherwise removing scope processing from address architecture. - Document recommended ways of allocating FEC0::/10 addresses to 'near-enough' guarantee uniqueness. The first change makes FEC0:://10 the same as any other filtered address, with one little exception - everybody agrees that this is to be filtered. A well-known non-globally-routeable prefix allows applications to make decisions based on scope: "I'd rather use / not use filtered addresses". As a default, I'd recommend the rule "If I have an address in FEC0:://10 and the destination offers FEC0:://10, try that first." Assuming longest-match destination address selection, this will work for both the situation where FEC0:://10 exists and doesn't. Of course, some applications will override this and say "no, don't give me an FEC0:://10". The convenient property is that applications can care if they want to, and otherwise can remain ignorant. The second point deals with the ambiguity problem. -- 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 Apr 6 20:19: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 h373J2PL012283; Sun, 6 Apr 2003 20:19:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h373J2El012282; Sun, 6 Apr 2003 20:19:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h373IwPL012272 for ; Sun, 6 Apr 2003 20:18:59 -0700 (PDT) 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 h373J6cU013436 for ; Sun, 6 Apr 2003 20:19:06 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA27646 for ; Sun, 6 Apr 2003 21:18:59 -0600 (MDT) 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, 7 Apr 2003 03:16: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; Mon, 7 Apr 2003 03:16: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; Mon, 7 Apr 2003 03:16:43 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, 7 Apr 2003 03:16:41 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id E1BEB146BF; Mon, 7 Apr 2003 13:16:34 +1000 (EST) Date: Mon, 7 Apr 2003 13:16:34 +1000 From: "Nick 'Sharkey' Moore" To: IPng Subject: Yet another FEC0::/10 proposal Message-Id: <20030407031634.GA19418@zoic.org> Mail-Followup-To: IPng References: <3E8D3F6D.3C780065@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E8D3F6D.3C780065@motorola.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Apr 04, 2003 at 06:16:45PM +1000, Andrew White wrote: > Let's ask a different question. Would the following be acceptable: I like the direction Andrew is taking, but how about an alternative set of rules which will cope with multiple scopes a bit better. The precise meaning of 'scope' has to be clarified of course, but I imagine it can be derived from the top few bits easily enough. * A node sending a packet MUST use an source address in the same scope as the destination address (except for Neighbour Discovery purposes) * A router MUST NOT forward a packet with different source address and destination address scopes, and MUST NOT forward a packet to an address of different scope than the packets source/destination address scope. * A router MUST NOT advertise a prefix or a route to a prefix on an interface which does not have an address with the same scope as that prefix. These rules implicitly prevent site-scope packets and routes from leaking beyond the site. Note, for example, that since the site-edge routers won't have SL addresses on their outside interface, they won't leak SL traffic, and since core routers won't have GUPI addresses, they won't transmit SL traffic anyway. If it is necessary to connect a site across the Internet, this can be done by VPNing / tunnelling. -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 6 20:37: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 h373bLPL012563; Sun, 6 Apr 2003 20:37:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h373bLnB012562; Sun, 6 Apr 2003 20:37:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h373bIPL012555 for ; Sun, 6 Apr 2003 20:37:18 -0700 (PDT) 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 h373bPHP001366 for ; Sun, 6 Apr 2003 20:37:25 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id VAA19650 for ; Sun, 6 Apr 2003 21:37:18 -0600 (MDT) 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; Mon, 7 Apr 2003 03:37:16 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, 7 Apr 2003 03:37: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; Mon, 7 Apr 2003 03:37:15 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; Mon, 7 Apr 2003 03:37:14 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.6) with ESMTP id h373fF426373 for ; Mon, 7 Apr 2003 06:41:15 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 7 Apr 2003 06:37:11 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 7 Apr 2003 06:37:11 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 7 Apr 2003 06:37:10 +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: Last Call: Textual Conventions for IPv6 Flow Label to Proposed Standard Date: Mon, 7 Apr 2003 06:37:10 +0300 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: Textual Conventions for IPv6 Flow Label to Proposed Standard Thread-Index: AcL7he5H78AlUKinTx6B/RTdru4yjQAFtqgQ To: , X-OriginalArrivalTime: 07 Apr 2003 03:37:10.0943 (UTC) FILETIME=[F8DF5AF0:01C2FCB6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h373bIPL012556 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bert, It seems that these sections are duplicates: 6. Intellectual Property Notice 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 of the 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 implementors 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. and Intellectual Property Statement 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 of the 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 implementors 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. br, John > -----Original Message----- > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: 05 April, 2003 18:02 > To: Ipng (E-mail) > Subject: FW: Last Call: Textual Conventions for IPv6 Flow Label to > Proposed Standard > > > FYI and possible comment. > Send comments to iesg/ietf mailing lists, or for discussions > join mibs@ops.ietf.org > > Thanks, > Bert > > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: zaterdag 5 april 2003 0:49 > Subject: Last Call: Textual Conventions for IPv6 Flow Label > to Proposed > Standard > > > > The IESG has received a request from the Operations & Management > Open Area Working Group to consider Textual Conventions for IPv6 > Flow Label as a Proposed > Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-5-4. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ops-ipv6-flowla bel-00.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 6 21:03:49 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 h3743nPL013055; Sun, 6 Apr 2003 21:03:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3743nGX013054; Sun, 6 Apr 2003 21:03:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h3743kPL013047 for ; Sun, 6 Apr 2003 21:03:46 -0700 (PDT) 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 h3743rHP005534 for ; Sun, 6 Apr 2003 21:03:53 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA27846 for ; Sun, 6 Apr 2003 21:03:46 -0700 (PDT) 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, 7 Apr 2003 03:53:04 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, 7 Apr 2003 03:53: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; Mon, 7 Apr 2003 03:53:03 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 03:53:03 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Sun, 06 Apr 2003 20:52:51 -0700 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" Cc: Subject: Goals vs. process Date: Sun, 6 Apr 2003 20:52:49 -0700 Message-Id: <0c5701c2fcb9$291693d0$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: <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3743kPL013048 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, I am not trying to twist words, I am reflecting what I hear as it applies to the reality of the deployed network. Our primary disagreement is over process. Forgive me but I can't figure out the technical differences that exist, because at this point it is not clear to me what you believe, or if you believe the problems that many network managers would use SL for are real. One thing that is clear is that there is no consensus in the WG as to what 'deprecate SL' means. Is it 1) remove ambiguity, 2) remove the definition as a well-known prefix to filter at the border of a site, 3) change the architecture to remove address scoping, 4) reduce routing complexity, 5) remove requirements on applications to deal with differences between prefixes, 6) pacify fear of change 4/2 AD - The ambiguity of the current site-local addresses will impact applications. We still need to solve the other problems (renumbering and disconnected sites) but we should do this using an addressing format which can be made transparent to applications. 4/2 JB - Ambiguous addresses are a nightmare... 4/2 MT - Scoped addresses as have been pretty well demonstrated take us down some pretty scary paths. 4/3 AZ - reasons += adds complexity to routing, forwarding, and network operations; 4/4 ER - It is important to simplify IPv6 DNS, routers and source address selection. 4/5 RB - i.e. let's solve a routing problem with an address model hack. pfui! 4/3 MW - This is actually a pretty good match for "deprecation" by my definition. We'd keep the prefix in the spec, but mark it as "deprecated, do not use", or something like that. 4/4 HA - Note: By "Deprecate Site-Local", I mean "Do not require any application, host, router, protocol or IETF practice to have to make special consideration for the idea that an IPv6 unicast address outside of the link-local range can refer to two different hosts". 4/5 DL - I thought we were voting on something more meaningful, i.e., site-locals themselves. Now I understand that site-locals do not exist as such and we were just voting on the deprecation of the prefix itself. Another thing that is not clear is how many of those who are saying 'Yes - depreciate' are actually motivated to solve the problems that will be created by whatever 'deprecate' means. I am not alone in that concern: 4/6 DL - Or are you saying that once site-locals are gone the IETF will be unwilling to allow any additional changes to the architecture to solve the renumbering, PI, etc. problems because these problems are not ``enough of a problem'' to warrant fundamental changes in the architecture? --> explicitly unanswered >From my perspective, if they really want a change they must participate in providing an alternative first. It is too easy to be destructive and walk away, which is exactly what this consensus call is setting up. Most of the 'Yes' comments are littered with value judgments (bad unnecessary dubious marginal scary) and show the commenter has no appreciation for the breadth of the real underlying requirements. Even your messages on the subject show you don't believe all the problems of the person fighting the day-to-day battles are real. Given the track record of this WG, and the lack of wide scale participation by those most effected (end site network managers), this call is a disaster in process. Whenever the I-D editor gets it processed, I have a draft that intends to identify the requirements for the alternative solutions to work from. Highlights: We need address space that is freely available for use by the network manager. Requiring them to get space from an ISP, or even continually pay a registry is not a viable plan. While this space might be declared 'unroutable', we need to design it on the assumption that parts of it may become routed and the routing table needs to stay at a manageable size. This implies some form of aggregation must be possible. Stable, local use prefixes are required. There are claims from the ISP perspective that a disconnected site will need to renumber when it connects. Renumbering in an IPv6 context means adding a prefix, and unlike IPv4 it does not mean removing the existing one. There is no reason for a site that connects to have to renumber nodes that are not going to use the external connection. In particular there is a need for existing internal applications to continue working as networks connect via different prefixes, so a site managed persistent prefix is required. One example of this type of network is a vehicle that attaches to local networks when stopped, and wireless networks while mobile. Site scoped addresses exist. We must recognize that route filtering == scoped addresses, and route filtering will exist despite idealistic hopes for a single flat routing space. We must also recognize that network managers want the ability to manage the scope of their name space and express a comparable policy to what they have for routing. This will not be easy, and the current round of comments show people prefer to make it someone else's problem. Also, awhile back you suggested a partitioned network example as a reason to use global rather than local addresses, because the partition could be healed through the Internet. That concept ignores the reality that almost all network managers would not want file mounts of proprietary content to suddenly traverse the Internet in the event of an internal partition. There are very valid reasons for local scope addresses. The idea that applications can blindly ignore that reality and treat the world as a single space has to be put behind us. Once we have the requirements collected, solutions can be proposed. I expect we will end up with multiple solutions, and it is not clear we will be able to meet them all without keeping the current SL. That does not mean we have failed, just that we have work to do. I do believe we can build a PI that deals with the majority of the ambiguity concerns, and I suspect that the remaining demands for ambiguous addresses won't expect or want to be interconnected. We are supposed to be working on technical approaches to problems, not reacting with fear to what bad things might happen. 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 Sun Apr 6 21:04: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 h3744JPL013073; Sun, 6 Apr 2003 21:04:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3744IJV013072; Sun, 6 Apr 2003 21:04:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h3744EPL013065 for ; Sun, 6 Apr 2003 21:04:14 -0700 (PDT) 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 h3744MHP005612 for ; Sun, 6 Apr 2003 21:04:22 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA03164 for ; Sun, 6 Apr 2003 21:04:15 -0700 (PDT) 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, 7 Apr 2003 03:53: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; Mon, 7 Apr 2003 03:53: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; Mon, 7 Apr 2003 03:53:23 Z Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [210.49.138.109]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 03:53:21 Z Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h373rDab013873 for ; Mon, 7 Apr 2003 13:53:13 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h373rCIC042870 for ; Mon, 7 Apr 2003 13:53:12 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200304070353.h373rCIC042870@drugs.dv.isc.org> To: IPng From: Mark.Andrews@isc.org Mail-Followup-To: IPng Subject: Re: Yet another FEC0::/10 proposal In-reply-to: Your message of "Mon, 07 Apr 2003 13:16:34 +1000." <20030407031634.GA19418@zoic.org> Date: Mon, 07 Apr 2003 13:53:12 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On Fri, Apr 04, 2003 at 06:16:45PM +1000, Andrew White wrote: > > Let's ask a different question. Would the following be acceptable: > > > I like the direction Andrew is taking, but how about an alternative > set of rules which will cope with multiple scopes a bit better. > The precise meaning of 'scope' has to be clarified of course, > but I imagine it can be derived from the top few bits easily enough. > > * A node sending a packet MUST use an source address in the same scope > as the destination address (except for Neighbour Discovery purposes) > > * A router MUST NOT forward a packet with different source address > and destination address scopes, and MUST NOT forward a packet > to an address of different scope than the packets > source/destination address scope. > > * A router MUST NOT advertise a prefix or a route to a prefix on an > interface which does not have an address with the same scope > as that prefix. > > These rules implicitly prevent site-scope packets and routes from leaking > beyond the site. Note, for example, that since the site-edge routers > won't have SL addresses on their outside interface, they won't leak > SL traffic, and since core routers won't have GUPI addresses, they > won't transmit SL traffic anyway. Stop making assumptions about what sites a machine belongs in. Multi sites machines need to be catered for. > If it is necessary to connect a site across the Internet, this can be > done by VPNing / tunnelling. > > -----Nick > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 6 23:08: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 h37682PL016507; Sun, 6 Apr 2003 23:08:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37682SU016504; Sun, 6 Apr 2003 23:08:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h3767cPL016482 for ; Sun, 6 Apr 2003 23:07:39 -0700 (PDT) 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 h3767kcU012983 for ; Sun, 6 Apr 2003 23:07:46 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id XAA01948 for ; Sun, 6 Apr 2003 23:07:40 -0700 (PDT) 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; Mon, 7 Apr 2003 05:58:38 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, 7 Apr 2003 05:58: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; Mon, 7 Apr 2003 05:58:37 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; Mon, 7 Apr 2003 05:58:32 Z Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h375uq809580 for ; Mon, 7 Apr 2003 08:56:53 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 7 Apr 2003 08:58:23 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 7 Apr 2003 08:58:22 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 7 Apr 2003 08:58:16 +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: Yet another FEC0::/10 proposal Date: Mon, 7 Apr 2003 08:58:15 +0300 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Yet another FEC0::/10 proposal Thread-Index: AcL8vzviVF08XchjQPmg4mlSp6nUYgACz/KA To: , X-OriginalArrivalTime: 07 Apr 2003 05:58:16.0770 (UTC) FILETIME=[AEE60A20:01C2FCCA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3767dPL016483 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nick, > I like the direction Andrew is taking, but how about an alternative > set of rules which will cope with multiple scopes a bit better. > The precise meaning of 'scope' has to be clarified of course, > but I imagine it can be derived from the top few bits easily enough. > > * A node sending a packet MUST use an source address in the same scope > as the destination address (except for Neighbour Discovery purposes) > > * A router MUST NOT forward a packet with different source address > and destination address scopes, and MUST NOT forward a packet > to an address of different scope than the packets > source/destination address scope. > > * A router MUST NOT advertise a prefix or a route to a prefix on an > interface which does not have an address with the same scope > as that prefix. > > These rules implicitly prevent site-scope packets and routes from leaking > beyond the site. Note, for example, that since the site-edge routers > won't have SL addresses on their outside interface, they won't leak > SL traffic, and since core routers won't have GUPI addresses, they > won't transmit SL traffic anyway. > If it is necessary to connect a site across the Internet, this can be > done by VPNing / tunnelling. One question, on the above, where you have text such as: MUST use an source address in the same scope What if we substituted it with: "MUST use an source address in the same scope or greater" That way, if nodes want to insist on using global addresses, then that will become a default behavior. 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 Sun Apr 6 23:25: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 h376PQPL016935; Sun, 6 Apr 2003 23:25:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h376PNfA016934; Sun, 6 Apr 2003 23:25:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h376P2PL016919 for ; Sun, 6 Apr 2003 23:25:03 -0700 (PDT) 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 h376PAHP017931 for ; Sun, 6 Apr 2003 23:25:10 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id AAA07553 for ; Mon, 7 Apr 2003 00:24:56 -0600 (MDT) 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, 7 Apr 2003 06:19: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; Mon, 7 Apr 2003 06:19: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; Mon, 7 Apr 2003 06:19:17 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 06:19:16 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 996DA146BF; Mon, 7 Apr 2003 16:19:12 +1000 (EST) Date: Mon, 7 Apr 2003 16:19:12 +1000 From: "Nick 'Sharkey' Moore" To: IPng Subject: Re: Yet another FEC0::/10 proposal Message-Id: <20030407061912.GA19587@zoic.org> Mail-Followup-To: IPng References: <20030407031634.GA19418@zoic.org> <200304070353.h373rCIC042870@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304070353.h373rCIC042870@drugs.dv.isc.org> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Apr 07, 2003 at 01:53:12PM +1000, Mark.Andrews@isc.org wrote: > > > These rules implicitly prevent site-scope packets and routes from leaking > > beyond the site. Note, for example, that since the site-edge routers > > won't have SL addresses on their outside interface, they won't leak > > SL traffic, and since core routers won't have GUPI addresses, they > > won't transmit SL traffic anyway. > > Stop making assumptions about what sites a machine belongs in. > Multi sites machines need to be catered for. Hi Mark. This set of rules doesn't assume that a host is in only one site. A host can have many addresses across many scopes and prefixes. Hosts from one site can communicate with hosts of another site if routes are provided. It also doesn't assume that SL and Aggregatable Global Unicast Addresses are the only scopes which may be used. There's some interesting work being done on Aggeratable Provider Indepedent addresses, after all. Hope that helps, Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 00:29:10 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 h377T5PL019150; Mon, 7 Apr 2003 00:29:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h377T2Tk019149; Mon, 7 Apr 2003 00:29:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h377SePL019133 for ; Mon, 7 Apr 2003 00:28:41 -0700 (PDT) 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 h377RjHP028167 for ; Mon, 7 Apr 2003 00:27:45 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id BAA17257 for ; Mon, 7 Apr 2003 01:27:40 -0600 (MDT) 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, 7 Apr 2003 07:27:11 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, 7 Apr 2003 07:27: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, 7 Apr 2003 07:27:10 Z Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 07:27:10 Z Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id h377EDS17888; Mon, 7 Apr 2003 09:15:15 +0200 (MEST) Message-Id: <3E912544.3950333F@inrialpes.fr> Date: Mon, 07 Apr 2003 09:14:12 +0200 From: Claude Castelluccia Organization: INRIA X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Alper Yegin , greg.daley@eng.monash.edu.au, Brian E Carpenter , jbartas@iniche.com, ipng@sunroof.eng.sun.com Subject: Re: Location Privacy (was Re: Outlawing (Avoiding) NAT with IPv6) References: <3E8E012D.4010804@nal.motlabs.com> Content-Type: multipart/alternative; boundary="------------BCBD52A9A993D0B47CE374DA" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------BCBD52A9A993D0B47CE374DA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Alexandru, Alexandru Petrescu wrote: > Alper, I tried to draw a logic conclusion from this: > -I assumed LCoA and RCoA have same last 64 bits It does not have too ...and must not if you use HMIPv6 to provide location privacy... Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------BCBD52A9A993D0B47CE374DA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Alexandru,
Alexandru Petrescu wrote:
Alper, I tried to draw a logic conclusion from this:
-I assumed LCoA and RCoA have same last 64 bits
It does not have too ...and must not if you use HMIPv6 to provide location privacy...

Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------BCBD52A9A993D0B47CE374DA-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 01:40: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 h378euPL022170; Mon, 7 Apr 2003 01:40:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h378euiU022169; Mon, 7 Apr 2003 01:40:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h378enPL022160 for ; Mon, 7 Apr 2003 01:40:49 -0700 (PDT) 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 h378euHP020104 for ; Mon, 7 Apr 2003 01:40:56 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id CAA04951 for ; Mon, 7 Apr 2003 02:40:51 -0600 (MDT) 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, 7 Apr 2003 08:40: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; Mon, 7 Apr 2003 08:40: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; Mon, 7 Apr 2003 08:40:46 Z Received: from slimsixten.besserwisser.org (slimsixten.besserwisser.org [213.212.3.212]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 08:40:46 Z Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id h378eiAH008329 for ; Mon, 7 Apr 2003 10:40:44 +0200 (CEST) Date: Mon, 07 Apr 2003 10:40:44 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: IPng Subject: Re: A different FEC0::/10 proposal Message-Id: <431280000.1049704844@localhost.besserwisser.org> In-Reply-To: <3E90E508.362F6EEC@motorola.com> References: <3E8D3F6D.3C780065@motorola.com> <3E8D8941.C0CF8359@hursley.ibm.com> <3E90E508.362F6EEC@motorola.com> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1151305387==========" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --==========1151305387========== Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Monday, April 07, 2003 12:40:08 +1000 Andrew White wrote: > Brian E Carpenter wrote: >>=20 >> This doesn't resolve the problem of ambiguous subnet prefixes >> when routing domains merge. So it doesn't go far enough IMHO. >=20 > That's because dealing with uniqueness and merging is a deployment issue, > not an architectural issue. =20 Might be so, but I think you are ignoring a lot of human behaviour patterns when you believe it is a simple matter of operation to DTRT. People will choose what they believe (and all too eager vendors insist) is the easy way out. I strongly oppose the creation of guns with an extra barrel pointed toward the users feet.=20 > The proposal specifies what the routing > system and applications need to know about these restricted deployment > addresses for correct general operation. The application must not have to know the network structure. That way lies madness.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========1151305387========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+kTmM02/pMZDM1cURAtOAAJ9b/4DCS4u85geSOaNUsvba1RaJSQCfXO8p wqaBUVU+t3WxpiVsyVxYaN0= =8OA/ -----END PGP SIGNATURE----- --==========1151305387==========-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 01:59:48 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 h378xkPL022863; Mon, 7 Apr 2003 01:59:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h378xiwR022857; Mon, 7 Apr 2003 01:59:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h378x4PN022783 for ; Mon, 7 Apr 2003 01:59:05 -0700 (PDT) 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 h378IxHP014182 for ; Mon, 7 Apr 2003 01:18:59 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id BAA21692 for ; Mon, 7 Apr 2003 01:18:53 -0700 (PDT) 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, 7 Apr 2003 08:18: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; Mon, 7 Apr 2003 08:18:52 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, 7 Apr 2003 08:18:52 Z Received: from slimsixten.besserwisser.org (slimsixten.besserwisser.org [213.212.3.212]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 08:18:51 Z Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id h378IiAH009804 for ; Mon, 7 Apr 2003 10:18:45 +0200 (CEST) Date: Mon, 07 Apr 2003 10:18:44 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: "ipng@sunroof.eng.sun.com" Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Message-Id: <417230000.1049703524@localhost.besserwisser.org> In-Reply-To: <200304052043.PAA16343@ss10.danlan.com> References: <200304052043.PAA16343@ss10.danlan.com> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========841668336==========" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --==========841668336========== Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Saturday, April 05, 2003 15:43:17 -0500 Dan Lanciani wrote: > You aren't being cynical enough. Once site-locals are gone there is > absolutely no reason to believe that there will be any work on a new > solution. We have had years and years to work on the routing/identifier > problem and it has gone nowhere. The new "solution" for stable internal > connections is going to be the same as the recently proposed "solution" > for multi-homing: send more money to your ISP and they will make their > links more reliable and refrain from renumbering you as frequently. Excuse me? An ISP renumbering a client? What have you been smoking?=20 Short of not giving the same DHCP lease to a home-style DSL customer, I know of no ISP who are shoveling around their customers onto different prefixes. Doing so would be financial suicide.=20 v6 is just longer addresses, harder to remember for humans. The design and operation of networks will not differ much from today, and any thinking ISP would refrain from shifting prefixes around inside the same PA block, because:=20 There is no need to do it, as long as the IGP copes, and it will.=20 The customer would be upset and switch providers.=20 Redesigning your net just because you can is not going to earn you money.=20 You are inventing problems out of thin air, I am afraid.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========841668336========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+kTRk02/pMZDM1cURAnJzAKCmgbX4P156rneAKELjUUIUsHaHXACdGCGr DrADZBaFa2IXXLJ0vcsLzA0= =vzs0 -----END PGP SIGNATURE----- --==========841668336==========-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 02:16:14 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 h379G2Pp023599; Mon, 7 Apr 2003 02:16:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h378h6WU022260; Mon, 7 Apr 2003 01:43:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h378frPL022226 for ; Mon, 7 Apr 2003 01:41:53 -0700 (PDT) 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 h378g0cU013136 for ; Mon, 7 Apr 2003 01:42:01 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id CAA26694 for ; Mon, 7 Apr 2003 02:41:55 -0600 (MDT) 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, 7 Apr 2003 08:41: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; Mon, 7 Apr 2003 08:41:51 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, 7 Apr 2003 08:41:50 Z Received: from eikenes.alvestrand.no ([217.13.28.204] [217.13.28.204]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 08:41:49 Z Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id D8CDE622BB; Mon, 7 Apr 2003 10:41:48 +0200 (CEST) Date: Mon, 07 Apr 2003 10:41:48 +0200 From: Harald Tveit Alvestrand To: alh-ietf@tndh.net Cc: ipng@sunroof.eng.sun.com Subject: Re: Goals vs. process Message-Id: <527210000.1049704908@askvoll.hjemme.alvestrand.no> In-Reply-To: <0c5701c2fcb9$291693d0$ee1a4104@eagleswings> References: <0c5701c2fcb9$291693d0$ee1a4104@eagleswings> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h378fsPL022228 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --On søndag, april 06, 2003 20:52:49 -0700 Tony Hain wrote: > From my perspective, if they really want a change they must participate > in providing an alternative first. It is too easy to be destructive and > walk away, which is exactly what this consensus call is setting up. Most > of the 'Yes' comments are littered with value judgments (bad unnecessary > dubious marginal scary) and show the commenter has no appreciation for > the breadth of the real underlying requirements. Even your messages on > the subject show you don't believe all the problems of the person > fighting the day-to-day battles are real. Given the track record of this > WG, and the lack of wide scale participation by those most effected (end > site network managers), this call is a disaster in process. Tony, this argument seems to be one of invoking a large group of people not present (in this case "the person fighting the day-to-day battles" and "end site network managers") in support of your viewpoint. have you considered the possibility that of all those people who say that the solution proposed, ambiguous site-locals, is not a good one, many actually are of the class of people whose interest you claim to defend, and disagree with you? I agree with you that the Right Thing is to get the requirements on the table. But I think spending the WG's time and the implementors' time in specifying, designing and implementing protocols and code that special-cases FEC0::/10 is a waste of resources - we've looked at that solution to the requirements, and it does not fulfil the requirements for a solution. BTW.... > We need address space that is freely available for use by the network > manager. Requiring them to get space from an ISP, or even continually > pay a registry is not a viable plan. I've been duly chastised before because I suggested that when people roll out million-dollar internal networks, or even 100-dollar PDAs, a few-dollar additional outlay per deployment scenario is a show-stopper. The biggest problem with paying a dollar (and why "free" is usually better) is that it often takes a hundred dollars' worth of overhead to get to pay it. But I think we should focus on "acceptable overhead", not "free as in beer". Harald -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 02:16:15 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 h379G2Pr023599; Mon, 7 Apr 2003 02:16:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37988wj023240; Mon, 7 Apr 2003 02:08:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h3796oPh023129 for ; Mon, 7 Apr 2003 02:07:04 -0700 (PDT) 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 h377otHP020105 for ; Mon, 7 Apr 2003 00:50:55 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id BAA27137 for ; Mon, 7 Apr 2003 01:50:49 -0600 (MDT) 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, 7 Apr 2003 07:50:43 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, 7 Apr 2003 07:50: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; Mon, 7 Apr 2003 07:50:42 Z Received: from skybar.pilsnet.sunet.se (skybar.pilsnet.sunet.se [192.36.125.99]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 07:50:41 Z Received: from skybar.pilsnet.sunet.se (localhost [127.0.0.1]) by skybar.pilsnet.sunet.se (8.12.9/8.12.9) with ESMTP id h377oehY066932 for ; Mon, 7 Apr 2003 09:50:40 +0200 (CEST) Received: (from bengan@localhost) by skybar.pilsnet.sunet.se (8.12.9/8.12.8/Submit) id h377oeB9066931 for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 09:50:40 +0200 (CEST) Date: Mon, 7 Apr 2003 09:50:40 +0200 From: Bengt =?iso-8859-1?B?R/ZyZOlu?= To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing Message-Id: <20030407075039.GA23580@sunet.se> References: <5.1.0.14.2.20030401143803.04a06d38@mail.windriver.com> <20030401201346.AB2287B4D@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030401201346.AB2287B4D@berkshire.research.att.com> User-Agent: Mutt/1.3.25i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "YES -- Deprecate site-local unicast addressing" - Bengan ----------------------------------------------------------- - KTHNOC/SUNET/NORDUnet | http://www.sunet.se/~bengan | 08-7906586 - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 09:03: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 h37G3PvM026466; Mon, 7 Apr 2003 09:03:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37G3Po6026465; Mon, 7 Apr 2003 09:03:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37G3GvM026444 for ; Mon, 7 Apr 2003 09:03:16 -0700 (PDT) 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 h37G3NcU004562 for ; Mon, 7 Apr 2003 09:03:23 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA10006 for ; Mon, 7 Apr 2003 09:03:13 -0700 (PDT) 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, 7 Apr 2003 16:03: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, 7 Apr 2003 16:03:10 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, 7 Apr 2003 16:03:10 Z Received: from web41803.mail.yahoo.com (web41803.mail.yahoo.com [66.218.93.137]) by relay12.sun.com for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 16:03:10 Z Message-Id: <20030407160308.40544.qmail@web41803.mail.yahoo.com> Received: from [65.213.193.49] by web41803.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 09:03:08 PDT Date: Mon, 7 Apr 2003 09:03:08 -0700 (PDT) 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-963382756-1049731388=:40454" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-963382756-1049731388=:40454 Content-Type: text/plain; charset=us-ascii Call for Papers ============== Internetworking 2003, June 22-24, 2003, San Jose, California http://www.caitr.org/internetworking03/index.htm REMINDER: Deadline for submissions is April 11, 2003 The Internetworking 2003 Technical 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 Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Vishal Sharma, Metanoia - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets - Ran Canetti, Co-chair, IETF Working Group on Multicast Security --0-963382756-1049731388=:40454 Content-Type: text/html; charset=us-ascii

Call for Papers
==============

Internetworking 2003, June 22-24, 2003, San Jose, California
http://www.caitr.org/internetworking03/index.htm

REMINDER: Deadline for submissions is April 11, 2003

The Internetworking 2003 Technical 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

Conference Technical Co-chairs:
- Dr. Maurice Gagnaire, ENST, France
- Daniel Awduche

Technical Program Committee of the Internetworking 2003 Conference:
- Roberto Sabella, Erisson
- Dr. Moshe Zukerman, Univ. of Melbourne
- Nada Golmie, NIST
- Dr. Guy Pujolle, LIP6, France
- Dr. Samir Tohme, ENST, France
- Stefano Trumpy, Italian National Research Council
- Dr. Ibrahim Habib, City Univ. of NY
- Dr. Vishal Sharma, Metanoia
- Dr. Parviz Yegani, Cisco Systems
- Dr. G.S. Kuo
- Dr. Abbas Jamalipour, Univ. of Sydney
- Dr. Hussein Mouftah, Univ. of Ottawa
- James Kempf
- Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage
- Dr. Ferit Yegenoglu, Isocore
- Dr. Ali Zadeh, George Mason University
- Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets
- Ran Canetti, Co-chair, IETF Working Group on Multicast Security

--0-963382756-1049731388=:40454-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 09:18: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 h37GIhvM027274; Mon, 7 Apr 2003 09:18:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37GIhM7027273; Mon, 7 Apr 2003 09:18:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37GIBva027194 for ; Mon, 7 Apr 2003 09:18:17 -0700 (PDT) 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 h37BmMcU001042 for ; Mon, 7 Apr 2003 04:48:22 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id FAA27779 for ; Mon, 7 Apr 2003 05:48:17 -0600 (MDT) 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, 7 Apr 2003 11:48: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; Mon, 7 Apr 2003 11:48: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; Mon, 7 Apr 2003 11:48:16 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; Mon, 7 Apr 2003 11:48:16 Z Received: from lucernhammer.isl.rdc.toshiba.co.jp (localhost [127.0.0.1]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 37DD81521A for ; Mon, 7 Apr 2003 20:48:52 +0900 (JST) Date: Mon, 07 Apr 2003 20:48:27 +0900 Message-Id: From: Masahiro =Rhythm Drive= Ishiyama To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> User-Agent: Wanderlust/2.6.1 (Upside Down) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryomae) APEL/10.3 Emacs/20.7 (powerpc-apple-darwin6.0) MULE/4.0 (HANANOEN) Organization: Toshiba Corp. R&D Center. 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: 14 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "NO -- Do not deprecate site-local unicast addressing". - Site-locals should be retained for disconnected sites. Note: If we have a good solution for disconnected sites, I'll vote for YES. I saw several ideas on this list, but I'm not convinced yet. So I'd like to say NO at this time. --------------------------------------- Masahiro ISHIYAMA Communication Platform Laboratory, R&D Center, TOSHIBA CORPORATION --------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 09:33:04 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 h37GX2vS028076; Mon, 7 Apr 2003 09:33:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37GQkx9027702; Mon, 7 Apr 2003 09:26:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37GPgvw027568 for ; Mon, 7 Apr 2003 09:25:55 -0700 (PDT) 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 h37BAkcU023866 for ; Mon, 7 Apr 2003 04:10:46 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA11093 for ; Mon, 7 Apr 2003 04:10:39 -0700 (PDT) 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, 7 Apr 2003 11:00: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; Mon, 7 Apr 2003 11:00: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; Mon, 7 Apr 2003 11:00:15 Z Received: from eikenes.alvestrand.no ([217.13.28.204] [217.13.28.204]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 11:00:15 Z Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6DB016223F; Mon, 7 Apr 2003 13:00:12 +0200 (CEST) Date: Mon, 07 Apr 2003 13:00:12 +0200 From: Harald Tveit Alvestrand To: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: free prefix allocation service Message-Id: <560030000.1049713212@askvoll.hjemme.alvestrand.no> In-Reply-To: <3E8FEA1D.E637286D@hursley.ibm.com> References: <963621801C6D3E4A9CF454A1972AE8F504F72A@server2000.arneill-py.sac ramento.ca.us> <20030404173003.GA7727@alicia.nttmcl.com> <3E8DD207.1090903@nal.motlabs.com> <3E8FEA1D.E637286D@hursley.ibm.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h37GPuvM027621 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --On søndag, april 06, 2003 10:49:33 +0200 Brian E Carpenter wrote: > I suspect there is a trivial DOS attack against this, despite the > one-per-day rule. We will need to think long and hard about how to make > such a system both idiot-proof and sabotage-proof. > the idiots are too smart for us. put a human in the (control) loop; once we figure out that there's an attack, the proper countermeasure is usually obvious. we don't need to coordinate between several sites if they hand out GUSL space from different prefixes; the RIRs (where it's far more critical) have running code for assignment escrow so that one RIR going out of business doesn't mean that customers lose the assignments they recieved earlier. > Brian > > Alexandru Petrescu wrote: >> >> Shannon -jj Behrens wrote: >> > This is fine as long as Nokia never goes out of business (I'm not >> > being snide, I'm being practical). >> >> :-) >> >> In that eventuality there's one at http://gusl.nal.motlabs.com visible >> both in v4 and v6. >> >> Not that I support gusl proposal, I must first understand it, but it >> seems to me that at least it raises new issues like how to coordinate >> between several sites wanting to offer such a service. Reliable >> service and so on. This is something enormous to deal with... >> >> Back lurking... >> >> Alex >> GBU > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 7 09:33: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 h37GXbvM028194; Mon, 7 Apr 2003 09:33:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37GXbu8028191; Mon, 7 Apr 2003 09:33:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37GX1vU028072 for ; Mon, 7 Apr 2003 09:33:05 -0700 (PDT) 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 h379mKcU005708 for ; Mon, 7 Apr 2003 02:48:20 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA05695 for ; Mon, 7 Apr 2003 03:48:12 -0600 (MDT) 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, 7 Apr 2003 09:40: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, 7 Apr 2003 09:40: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, 7 Apr 2003 09:40:42 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, 7 Apr 2003 09:40:41 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 h378bVW13507; Mon, 7 Apr 2003 10:37:31 +0200 Message-Id: <3E9138CB.5050803@it.su.se> Date: Mon, 07 Apr 2003 10:37:31 +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: Harald Tveit Alvestrand CC: alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Goals vs. process References: <0c5701c2fcb9$291693d0$ee1a4104@eagleswings> <527210000.1049704908@askvoll.hjemme.alvestrand.no> In-Reply-To: <527210000.1049704908@askvoll.hjemme.alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Harald Tveit Alvestrand wrote: > > > have you considered the possibility that of all those people who say > that the solution proposed, ambiguous site-locals, is not a good one, > many actually are of the class of people whose interest you claim to > defend, and disagree with you? I agree. Moreover the argument has been refuted by a few people on the list who at least seem to believe that they are involved in day-to-day operation of networks, myself humbly included. The logic of the counter-argument that we are "only" running research networks that for some reason are fundamentally different from other types of networks continue to ellude me. 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 Apr 7 10:26: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 h37HQimh000695; Mon, 7 Apr 2003 10:26:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37HQiX7000694; Mon, 7 Apr 2003 10:26:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37GX138028072 for ; Mon, 7 Apr 2003 09:37:11 -0700 (PDT) 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 h3786bcU009197 for ; Mon, 7 Apr 2003 01:06:37 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id CAA02734 for ; Mon, 7 Apr 2003 02:06:29 -0600 (MDT) 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, 7 Apr 2003 08:06:27 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, 7 Apr 2003 08:06: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, 7 Apr 2003 08:06:27 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, 7 Apr 2003 08:06:26 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3786OCi016212 for ; Mon, 7 Apr 2003 10:06: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 h3786OvA027326 for ; Mon, 7 Apr 2003 10:06:24 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58266 from ; Mon, 7 Apr 2003 10:06:23 +0200 Message-Id: <3E9131AD.A80CD197@hursley.ibm.com> Date: Mon, 07 Apr 2003 10:07:09 +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: Why I support deprecating SLs References: <200304062001.QAA21963@ss10.danlan.com> <3E9087B1.6010100@it.su.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Leif Johansson wrote: ... > Moreover I don't believe that applications > should have to > care about address selection or know about topology. Judging from the > traffic on the > list and from the discussion at the mike in the SF meething i'd say that > quite a few > agree with me on that point. I'm afraid I don't agree with you. On the contrary, middleware that cares about performance and survivability absolutely has to care about path selection in some way or another. But I think this is a somewhat separate issue from ambiguous SLs and the specific scope problems that they cause. 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 Apr 7 10:34: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 h37HYCmh001471; Mon, 7 Apr 2003 10:34:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37HYC41001467; Mon, 7 Apr 2003 10:34:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37HY5mh001430 for ; Mon, 7 Apr 2003 10:34:05 -0700 (PDT) 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 h37HYCHP018606 for ; Mon, 7 Apr 2003 10:34:12 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA26135 for ; Mon, 7 Apr 2003 10:34:06 -0700 (PDT) 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, 7 Apr 2003 17:34: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; Mon, 7 Apr 2003 17:34:05 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, 7 Apr 2003 17:34:05 Z Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 17:34:05 Z Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h37HXwmr017294; Mon, 7 Apr 2003 10:33:59 -0700 (PDT) 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 ACZ49085; Mon, 7 Apr 2003 10:33:57 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA13724; Mon, 7 Apr 2003 10:33:57 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16017.46725.511549.908986@thomasm-u1.cisco.com> Date: Mon, 7 Apr 2003 10:33:57 -0700 (PDT) To: Dan Lanciani Cc: ipng@sunroof.eng.sun.com Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve In-Reply-To: <200304062324.TAA23162@ss10.danlan.com> References: <200304062324.TAA23162@ss10.danlan.com> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Lanciani writes: > Eliot Lear wrote: > > |Dan Lanciani wrote: > |> However poor, site-locals are the _only_ currently defined local address. > | > |Nope. You can use IPv4. And one might as well. > > That's true, of course, but it's a pretty depressing reality. How will > it affect deployment if we have to tell users that switching to v6 means > giving up functionality that they have come to depend on? > > |What is the benefit of > |IPv6 if we don't solve this problem? > > Are you talking about solving the problem of site-locals by getting rid > of them or solving the underlying problems (renumbering, routing, etc.) that > drive people to need local address space in the first place? I don't know about Eliot, but that sure has my vote. There's certainly more than enough ignorance floating around about private address space, but there are also problems like address stability which are not so easy to dismiss. IMO, this giant reset is good since we can sort through the actual problems. The current presence of s*t*-l*c*ls is making it near impossible to have that discussion since it's a supposed -- but flawed -- solution to a somewhat ill defined set of problems. For example, it's fairly clear to me that a BCP should be written which clearly enumerates why you don't need private address space to achieve the same security goals, and how to go about doing that with IPv6's plentiful address space. And we clearly need a frank discussion about why current ipv6 renumbering is viewed as "not good enough for the real world", and what we can realistically do about it (cf address stability). 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 Apr 7 10:34:18 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 h37HXKrJ001191; Mon, 7 Apr 2003 10:34:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37HPDHv000520; Mon, 7 Apr 2003 10:25:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37HJ1uB029008 for ; Mon, 7 Apr 2003 10:24:21 -0700 (PDT) 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 h37AbIHP018408 for ; Mon, 7 Apr 2003 03:37:18 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA21135 for ; Mon, 7 Apr 2003 03:37:08 -0700 (PDT) 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, 7 Apr 2003 10:25: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; Mon, 7 Apr 2003 10:21:40 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, 7 Apr 2003 10:25:05 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; Mon, 7 Apr 2003 10:25:04 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.25]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id DAA11458; Mon, 7 Apr 2003 03:24:33 -0700 (PDT) Message-Id: <5.1.0.14.2.20030407055056.036f9188@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 07 Apr 2003 06:23:07 -0400 To: From: Margaret Wasserman Subject: Re: Goals vs. process Cc: In-Reply-To: <0c5701c2fcb9$291693d0$ee1a4104@eagleswings> References: <5.1.0.14.2.20030405112707.030dfbc0@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 Tony, At 08:52 PM 4/6/2003 -0700, Tony Hain wrote: >Forgive me but I can't figure out the technical >differences that exist, because at this point it is not clear to me what >you believe, or if you believe the problems that many network managers >would use SL for are real. From reading your posts, I think that our technical positions are reasonably close. I think that we both see the flaws with site-local addressing and would like to see it replaced with something better. I also think that we both realize that the "real" solution would be globally-routable PI addresses, but we also understand that we can't get there fast enough (if at all) so we need some type of local PI addressing in the meantime. We mainly disagree about the value that site-locals have today. You believe that they are a valuable tool for network administrators today -- as local, PI addressing. I think where I stand is pretty clear... I wrote a 30+ page document that outlines the problems and benefits with site-local addressing and concludes that the problems far outweigh the benefits. I proposed the "limited" model to constrain site-local addresses to completely disconnected networks. I do think that the following needs are "real": 1 Addressing for disconnected sites. 2 Addressing for intermittently connected sites. 3 The need for local access control. 4 The need for provider-independent local addresses that remain stable when providers change/renumber. I just don't think that site-local addressing (ambiguous scoped addressing, as defined in the scoped addressing architecture and as allocated in prefix FEC0::/10) is the right solution to any of these problems. It is known to have substantial problems, and I think that we should stop encouraging people to invest in it further (in specifications, implementations, etc.) The first one (disconnected) is relatively easy. I'd rather that people registered a local, PI address, and I think we should offer that option. Some people won't agree/choose to register, so we will also need to offer some type of auto-generated option. But, there is NO reasonable justification for why these addresses need to be ambiguous, so they shouldn't be. That also means that they shouldn't be allocated from FECO::/10, because some implementations already include special handling of those addresses as ambiguous. So, my "limited" model is flawed. I accept that. The addressing for #2 may be handled the same way as #1, but actually making connections survive disconnection and re-connection at a new global address is more complicated than that, as it requires that all local connections/applications prefer site-local addresses while global connections/applications use global addresses. We will need to figure out if this can be done in a way that is completely compatible with behaving optimally on stably connected networks, or if it will be necessary for implementations to get some type of configuration hint regarding which way they should behave. Or, possibly, we need to consider a different solution for this case. I agree that we need to understand what the actual requirements are here, before we can evaluate solutions. We already have a couple of drafts that address #3 without site- local addresses. #4 is only really solved by stable, unique, globally-routable, provider-independent addresses, but it could be partially solved by any solution to #1 (just like SLs partially solve it). Let me explain why it isn't solved by just giving two addresses to every machine... Assume I have a 200 node network with 10 routers. - If I use only global PA addresses, when my provider changes, I will need to change the global prefixes on my 30 routers, update my DNS, update any access lists/security associations on my 200 hosts (perhaps automatically), etc. I will need to do this before any global access will work. In the meantime, local access would continue to work until my formerly PA addresses become invalid (not just un-preferred, invalid), then it will start to fail if I haven't renumbered yet. - If I use both global PA addresses and local prefixes, when my provider changes, I will need to change the global prefixes on my 30 routers, update my (split) DNS, update any access list/security associates related to global addresses on my 200 hosts (perhaps automatically), etc. I will need to do this before any global access will work, although local access that actually uses site-local addresses (if I have any applications that know that they want to use site-local addresses) will continue to work indefinitely, and any local access that uses global prefixes will work until my old PA prefix becomes invalid, as above. Compare both of the cases above to what I do if I have NAT: - If I use NAT with internal local addressing and external PA addressing, when my provider changes, I renumber one side of my NAT box. Period. So, it is my opinion that if people put the level of value on provider-independence that you suggest (and I believe you), then they will choose NAT (and probably IPv4) unless/until we figure out a way to provide NAT-less, provider-independent global addressing in IPv6. [Note: I did not say that SL == NAT, nor did I say that SLs increase the value of NAT, etc. I think that we have this problem with or without site-local addresses.] I know that we don't know how to solve that problem right now. But, could we please stop arguing about site-local addresses (which _don't_ solve that problem at all, and don't solve any problem well) and start working on solutions to the real problem? Margaret >One thing that is clear is that there is no consensus in the WG as to >what 'deprecate SL' means. Is it 1) remove ambiguity, 2) remove the >definition as a well-known prefix to filter at the border of a site, 3) >change the architecture to remove address scoping, 4) reduce routing >complexity, 5) remove requirements on applications to deal with >differences between prefixes, 6) pacify fear of change > >4/2 AD - The ambiguity of the current site-local addresses will impact >applications. >We still need to solve the other problems (renumbering and disconnected >sites) but we should do this using an addressing format which can be >made transparent to applications. > >4/2 JB - Ambiguous addresses are a nightmare... > >4/2 MT - Scoped addresses as have been pretty well demonstrated take us >down some pretty scary paths. > >4/3 AZ - reasons += adds complexity to routing, forwarding, and network >operations; > >4/4 ER - It is important to simplify IPv6 DNS, routers and source >address selection. > >4/5 RB - i.e. let's solve a routing problem with an address model hack. >pfui! > >4/3 MW - This is actually a pretty good match for "deprecation" by >my definition. We'd keep the prefix in the spec, but mark >it as "deprecated, do not use", or something like that. > >4/4 HA - Note: By "Deprecate Site-Local", I mean "Do not require any >application, >host, router, protocol or IETF practice to have to make special >consideration for the idea that an IPv6 unicast address outside of the >link-local range can refer to two different hosts". > >4/5 DL - I thought we were voting on something more meaningful, i.e., >site-locals themselves. Now I understand that site-locals do not exist >as such and we were just voting on the deprecation of the prefix itself. > > >Another thing that is not clear is how many of those who are saying 'Yes >- depreciate' are actually motivated to solve the problems that will be >created by whatever 'deprecate' means. I am not alone in that concern: > >4/6 DL - Or are you saying that once site-locals are gone the IETF will >be unwilling to allow any additional changes to the architecture to >solve the renumbering, PI, etc. problems because these problems are not >``enough of a problem'' to warrant fundamental changes in the >architecture? --> explicitly unanswered > > >From my perspective, if they really want a change they must participate >in providing an alternative first. It is too easy to be destructive and >walk away, which is exactly what this consensus call is setting up. Most >of the 'Yes' comments are littered with value judgments (bad unnecessary >dubious marginal scary) and show the commenter has no appreciation for >the breadth of the real underlying requirements. Even your messages on >the subject show you don't believe all the problems of the person >fighting the day-to-day battles are real. Given the track record of this >WG, and the lack of wide scale participation by those most effected (end >site network managers), this call is a disaster in process. > > >Whenever the I-D editor gets it processed, I have a draft that intends >to identify the requirements for the alternative solutions to work from. >Highlights: > >We need address space that is freely available for use by the network >manager. Requiring them to get space from an ISP, or even continually >pay a registry is not a viable plan. While this space might be declared >'unroutable', we need to design it on the assumption that parts of it >may become routed and the routing table needs to stay at a manageable >size. This implies some form of aggregation must be possible. > >Stable, local use prefixes are required. There are claims from the ISP >perspective that a disconnected site will need to renumber when it >connects. Renumbering in an IPv6 context means adding a prefix, and >unlike IPv4 it does not mean removing the existing one. There is no >reason for a site that connects to have to renumber nodes that are not >going to use the external connection. In particular there is a need for >existing internal applications to continue working as networks connect >via different prefixes, so a site managed persistent prefix is required. >One example of this type of network is a vehicle that attaches to local >networks when stopped, and wireless networks while mobile. > >Site scoped addresses exist. We must recognize that route filtering == >scoped addresses, and route filtering will exist despite idealistic >hopes for a single flat routing space. We must also recognize that >network managers want the ability to manage the scope of their name >space and express a comparable policy to what they have for routing. >This will not be easy, and the current round of comments show people >prefer to make it someone else's problem. Also, awhile back you >suggested a partitioned network example as a reason to use global rather >than local addresses, because the partition could be healed through the >Internet. That concept ignores the reality that almost all network >managers would not want file mounts of proprietary content to suddenly >traverse the Internet in the event of an internal partition. There are >very valid reasons for local scope addresses. The idea that applications >can blindly ignore that reality and treat the world as a single space >has to be put behind us. > > >Once we have the requirements collected, solutions can be proposed. I >expect we will end up with multiple solutions, and it is not clear we >will be able to meet them all without keeping the current SL. That does >not mean we have failed, just that we have work to do. I do believe we >can build a PI that deals with the majority of the ambiguity concerns, >and I suspect that the remaining demands for ambiguous addresses won't >expect or want to be interconnected. We are supposed to be working on >technical approaches to problems, not reacting with fear to what bad >things might happen. > > >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 10:34: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 h37HXKrP001191; Mon, 7 Apr 2003 10:34:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37HOx7u000516; Mon, 7 Apr 2003 10:24:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37HJ1td029008 for ; Mon, 7 Apr 2003 10:23:46 -0700 (PDT) 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 h37BNVHP025936 for ; Mon, 7 Apr 2003 04:23:31 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id FAA29683 for ; Mon, 7 Apr 2003 05:23:26 -0600 (MDT) 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, 7 Apr 2003 11:23: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; Mon, 7 Apr 2003 11:23:25 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, 7 Apr 2003 11:23:25 Z Received: from dhcp1.se.kurtis.pp.se ([192.71.80.74] [192.71.80.74]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 11:23:24 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 h37BOnWv004468; Mon, 7 Apr 2003 13:24:50 +0200 (CEST) Date: Mon, 7 Apr 2003 05:33:55 +0200 Subject: Re: avoiding NAT with IPv6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Margaret Wasserman" , "Jeroen Massar" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54D4D@server2000.arneill-py.sacramento.ca.us> Message-Id: X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h37HNkmh000367 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On måndag, mar 31, 2003, at 20:11 Europe/Stockholm, Michel Py wrote: > > 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. > Actually, what you are saying, and that I would agree with - is that the lack of a PI solution, that most likely would also have some effect on a multihoming solution, would also provide a solution to the SL problem. So now we all we need to do is come up with a way to a) co-ordinate this, b) Find a solution :-) - 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 Apr 7 10:34:22 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 h37HXKrT001191; Mon, 7 Apr 2003 10:34:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37GZs8C028480; Mon, 7 Apr 2003 09:35:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37GX108028072 for ; Mon, 7 Apr 2003 09:34:45 -0700 (PDT) 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 h379cncU020476 for ; Mon, 7 Apr 2003 02:38:50 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA05256 for ; Mon, 7 Apr 2003 03:38:42 -0600 (MDT) 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, 7 Apr 2003 09:32: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; Mon, 7 Apr 2003 09:32: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; Mon, 7 Apr 2003 09:31:55 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, 7 Apr 2003 09:31:55 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 KAA23705 for ; Mon, 7 Apr 2003 10:31:46 +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 KAA11477 for ; Mon, 7 Apr 2003 10:31:46 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h379Vkf29212 for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 10:31:46 +0100 Date: Mon, 7 Apr 2003 10:31:46 +0100 From: Tim Chown To: "ipng@sunroof.eng.sun.com" Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Message-Id: <20030407093146.GS23732@login.ecs.soton.ac.uk> Mail-Followup-To: "ipng@sunroof.eng.sun.com" References: <200304052043.PAA16343@ss10.danlan.com> <417230000.1049703524@localhost.besserwisser.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <417230000.1049703524@localhost.besserwisser.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Apr 07, 2003 at 10:18:44AM +0200, Måns Nilsson wrote: > > v6 is just longer addresses, harder to remember for humans. The design and > operation of networks will not differ much from today, and any thinking ISP > would refrain from shifting prefixes around inside the same PA block, > because: > > There is no need to do it, as long as the IGP copes, and it will. > The customer would be upset and switch providers. > Redesigning your net just because you can is not going to earn you money. The home network "site /48" is (in current speak) the same as a global IPv4 address; in IPv6 we hope to offer a home network a real network where previously a (usually dynamic) IPv4 address was available. > You are inventing problems out of thin air, I am afraid. Except that an ISP with a /32 is already in address conservation mode - it can only allocate 65K home network prefixes to customers. If it has a million customers, then, HD-ratio included, it will need something like a /22 allocation. While /32's exist, customer networks will either get dynamic prefixes or be allocated less than a /48. Of course the ISP would like to be able to charge for "extras" like static network prefixes. Aside from privacy issues, the static /48 prefix for home and SOHO networks is a big win for IPv6. 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 Apr 7 10:34: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 h37HXKrN001191; Mon, 7 Apr 2003 10:34:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37HLU6a029740; Mon, 7 Apr 2003 10:21:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37HJ1oN029007 for ; Mon, 7 Apr 2003 10:19:51 -0700 (PDT) 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 h378nCHP022381 for ; Mon, 7 Apr 2003 01:49:12 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id BAA12575 for ; Mon, 7 Apr 2003 01:49:07 -0700 (PDT) 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, 7 Apr 2003 08:49:06 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, 7 Apr 2003 08:49:06 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, 7 Apr 2003 08:49:06 Z Received: from ihemail1.firewall.lucent.com ([192.11.222.161] [192.11.222.161]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 08:49:06 Z Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h378n4W22792 for ; Mon, 7 Apr 2003 04:49:05 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Apr 2003 10:49:03 +0200 Message-Id: <7D5D48D2CAA3D84C813F5B154F43B15501484376@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: john.loughney@nokia.com, bwijnen@lucent.com, ipng@sunroof.eng.sun.com Subject: RE: Last Call: Textual Conventions for IPv6 Flow Label to Propos ed Standard Date: Mon, 7 Apr 2003 10:49:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk They are. Thanks for catching that. Oh well.. this was my fiorst I-D I did with XML. Seems it generates it automagically and I also added it by hand. I will remove one of them. Thanks, Bert > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: maandag 7 april 2003 5:37 > To: bwijnen@lucent.com; ipng@sunroof.eng.sun.com > Subject: RE: Last Call: Textual Conventions for IPv6 Flow Label to > Proposed Standard > > > Hi Bert, > > It seems that these sections are duplicates: > > 6. Intellectual Property Notice > > > 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 of the 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 implementors 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. > > and > > Intellectual Property Statement > > 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 of the 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 implementors 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. > > br, > John > > > > -----Original Message----- > > From: ext Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: 05 April, 2003 18:02 > > To: Ipng (E-mail) > > Subject: FW: Last Call: Textual Conventions for IPv6 Flow Label to > > Proposed Standard > > > > > > FYI and possible comment. > > Send comments to iesg/ietf mailing lists, or for discussions > > join mibs@ops.ietf.org > > > > Thanks, > > Bert > > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: zaterdag 5 april 2003 0:49 > > Subject: Last Call: Textual Conventions for IPv6 Flow Label > > to Proposed > > Standard > > > > > > > > The IESG has received a request from the Operations & Management > > Open Area Working Group to consider Textual Conventions for IPv6 > > Flow Label as a Proposed > > Standard. > > > > The IESG plans to make a decision in the next few weeks, > and solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-5-4. > > > > Files can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-ops-ipv6-flowla > bel-00.txt > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 10:34: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 h37HXKrL001191; Mon, 7 Apr 2003 10:34:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37HN4B6000189; Mon, 7 Apr 2003 10:23:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37HJ1rT029008 for ; Mon, 7 Apr 2003 10:22:14 -0700 (PDT) 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 h37FAWHP014939 for ; Mon, 7 Apr 2003 08:10:32 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id JAA17869 for ; Mon, 7 Apr 2003 09:10:24 -0600 (MDT) 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, 7 Apr 2003 15:10: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, 7 Apr 2003 15:06: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; Mon, 7 Apr 2003 15:10:18 Z Received: from a80-126-101-63.adsl.xs4all.nl (a80-126-101-63.adsl.xs4all.nl [80.126.101.63]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 15:10:17 Z Received: (from rvdp@localhost) by a80-126-101-63.adsl.xs4all.nl (8.11.6p2/8.11.6) id h37FA3o15625; Mon, 7 Apr 2003 17:10:03 +0200 (CEST) Date: Mon, 7 Apr 2003 17:10:03 +0200 From: Ronald van der Pol To: Patrik F?ltstr?m Cc: Dan Lanciani , ipng@sunroof.eng.sun.com Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Message-Id: <20030407151003.GC13936@rvdp.org> References: <200304052024.PAA16204@ss10.danlan.com> <23982A6A-6806-11D7-81E1-000A959CF516@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23982A6A-6806-11D7-81E1-000A959CF516@cisco.com> User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, Apr 06, 2003 at 10:02:40 +0200, Patrik F?ltstr?m wrote: > So, yes, it would be very natural to talk much more about > differentiating between routing and addressing. > > Maybe one doesn't talk about it because for example apps and internet > people don't talk so much with each other? It is interesting to note that on one side there is a move to a dumb (core) network and move complexity to the edges. On the other hand there is the layering argument that applications should not know about topology. What _exactly_ should the "ideal" network provide as a service? Two extremes are probably: - Applications deal with several (locator) addresses. Input to the network layer are two (locator) addresses (src and dst). The network delivers packets between exactly one pair of (locator) addresses (multiple path may exist between these addresses). The upper layers pick the "best" source and destination (locator) addresses. The upper layers react when a path breaks. - Applications deal with one identifier. Input to the network layer are two identifiers (src and dst). The network picks the "best" path out of several (probably by choosing the "best" (locator) addresses). The network reacts when a path breaks. The upper layers use some kind of stable identifier instead of a (locator) address. Where do we put the complexity? 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 Apr 7 10:34: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 h37HXKrR001191; Mon, 7 Apr 2003 10:34:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37HLVHc029744; Mon, 7 Apr 2003 10:21:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37HJKo1029139 for ; Mon, 7 Apr 2003 10:20:18 -0700 (PDT) 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 h37Gn0cU022574 for ; Mon, 7 Apr 2003 09:49:00 -0700 (PDT) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA14520 for ; Mon, 7 Apr 2003 09:48:54 -0700 (PDT) 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, 7 Apr 2003 16:48: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; Mon, 7 Apr 2003 16:48: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; Mon, 7 Apr 2003 16:48:52 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; Mon, 7 Apr 2003 16:48:51 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h37Gmjvm071421; Mon, 7 Apr 2003 09:48:45 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h37GmjPQ071420; Mon, 7 Apr 2003 09:48:45 -0700 (PDT) Date: Mon, 7 Apr 2003 09:48:45 -0700 From: Shannon -jj Behrens To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: free prefix allocation service Message-Id: <20030407164844.GD70775@alicia.nttmcl.com> References: <963621801C6D3E4A9CF454A1972AE8F504F72A@server2000.arneill-py.sacramento.ca.us> <20030404173003.GA7727@alicia.nttmcl.com> <3E8DD207.1090903@nal.motlabs.com> <3E8FEA1D.E637286D@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E8FEA1D.E637286D@hursley.ibm.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, surely. That's why I advocated: 1) Each GUSL prefix should be taken out of an existing global unicast prefix that has been assigned to a company. In this way, multiple parties could be delegating prefixes out of different prefixes. The one drawback to this is that you wouldn't be able to tell a GUSL from a normal global unicast prefix, however, some may call that a feature. 2) The GUSL prefix should only be delegated to someone who could pass a silly "turing" test, such as those required when joining Slashdot. Best Regards, -jj On Sun, Apr 06, 2003 at 10:49:33AM +0200, Brian E Carpenter wrote: > I suspect there is a trivial DOS attack against this, despite the > one-per-day rule. We will need to think long and hard about how to make > such a system both idiot-proof and sabotage-proof. > > Brian > > Alexandru Petrescu wrote: > > > > Shannon -jj Behrens wrote: > > > This is fine as long as Nokia never goes out of business (I'm not > > > being snide, I'm being practical). > > > > :-) > > > > In that eventuality there's one at http://gusl.nal.motlabs.com visible > > both in v4 and v6. > > > > Not that I support gusl proposal, I must first understand it, but it > > seems to me that at least it raises new issues like how to coordinate > > between several sites wanting to offer such a service. Reliable > > service and so on. This is something enormous to deal with... > > > > Back lurking... -- 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 Mon Apr 7 10:40: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 h37HeUmh002492; Mon, 7 Apr 2003 10:40:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37HeTrl002484; Mon, 7 Apr 2003 10:40:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37HeNmh002459 for ; Mon, 7 Apr 2003 10:40:24 -0700 (PDT) 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 h37HeUcU014884 for ; Mon, 7 Apr 2003 10:40:31 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA28119 for ; Mon, 7 Apr 2003 11:40:24 -0600 (MDT) 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, 7 Apr 2003 17:40: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, 7 Apr 2003 17:36: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; Mon, 7 Apr 2003 17:40:21 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, 7 Apr 2003 17:40:20 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 KAA20273; Mon, 7 Apr 2003 10:40:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h37HeIn01849; Mon, 7 Apr 2003 10:40:18 -0700 X-mProtect: <200304071740> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdF8Fa9Q; Mon, 07 Apr 2003 10:40:16 PDT Message-Id: <3E91B850.4030203@iprg.nokia.com> Date: Mon, 07 Apr 2003 10:41:36 -0700 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: Brian E Carpenter CC: alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve References: <0bcc01c2fb90$0da62590$ee1a4104@eagleswings> <3E8FF01E.BA74CDCA@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, Brian E Carpenter wrote: > As for whether we can do what the RRG has failed to do, of course > not. But it seems fairly clear we can define unambiguous PI space. Can you say more about this? Is there a proposal defining an unambiguous PI space that I may have missed? Thanks, 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 Mon Apr 7 10:47:40 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 h37Hlemh004160; Mon, 7 Apr 2003 10:47:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37Hlb0S004159; Mon, 7 Apr 2003 10:47:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@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 h37HlSmh004113 for ; Mon, 7 Apr 2003 10:47:28 -0700 (PDT) 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 h37HlZcU019091 for ; Mon, 7 Apr 2003 10:47:35 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA07507 for ; Mon, 7 Apr 2003 10:47:30 -0700 (PDT) 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, 7 Apr 2003 17:47: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; Mon, 7 Apr 2003 17: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; Mon, 7 Apr 2003 17:47:29 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, 7 Apr 2003 17:47:28 Z Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CB9D015210 for ; Tue, 8 Apr 2003 02:48:02 +0900 (JST) Date: Tue, 08 Apr 2003 02:47:16 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 40 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 01 Apr 2003 14:37:56 -0500, >>>>> Margaret Wasserman said: > Should we deprecate IPv6 site-local unicast addressing? "NO -- Do not deprecate site-local unicast addressing". - because I'm not convinced that there is a clear consensus on an alternative to site-local or that we do not need such a consensus. I'm sad I must vote for NO...I've tried to convince myself by the meeting minutes, presentation slides, discussion in this list, and some private discussion, but I failed. I've seen many candidate alternatives that at least include: - arbitrary (random) global prefix - fec0:: + random bits - free prefix allocation service I've even seen a wording nit like: - leave site-local in the spec, but make a recommendation to avoid using it. (but can't this also be interpreted as a sort of 'not deprecate site-local'?) I could not be sure if we'll be able to make a consensus on any of them (or others) quickly, if we choose "deprecating" site-local. If not, the result will just be a confusion. If we can, then I don't see why we cannot first make a consensus quickly and then deprecate site-local. I (of course) don't know the final result of this vote at this moment. But regardless of the result, I'm willing to follow it without making a further objection, and will try to make a productive contribution based on the result. 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 Apr 7 11:04:10 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 h37I4Amh004993; Mon, 7 Apr 2003 11:04:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37I4AgT004992; Mon, 7 Apr 2003 11:04:10 -0700 (PDT) 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 h37I46mh004985 for ; Mon, 7 Apr 2003 11:04:06 -0700 (PDT) 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 h37I4EHP003453 for ; Mon, 7 Apr 2003 11:04:14 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA18839 for ; Mon, 7 Apr 2003 11:04:08 -0700 (PDT) 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, 7 Apr 2003 18:04:07 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, 7 Apr 2003 18:00: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; Mon, 7 Apr 2003 18:04:07 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; Mon, 7 Apr 2003 18:04:06 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 h37H14W13823; Mon, 7 Apr 2003 19:01:04 +0200 Message-Id: <3E91AECF.7060300@it.su.se> Date: Mon, 07 Apr 2003 19:01:03 +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: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs References: <200304062001.QAA21963@ss10.danlan.com> <3E9087B1.6010100@it.su.se> <3E9131AD.A80CD197@hursley.ibm.com> In-Reply-To: <3E9131AD.A80CD197@hursley.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: >I'm afraid I don't agree with you. On the contrary, middleware that >cares about performance and survivability absolutely has to care >about path selection in some way or another. But I think this is >a somewhat separate issue from ambiguous SLs and the specific scope >problems that they cause. > > > Even at the risk of polluting the thread ;-) I'll bite: Could you give an example of such middleware? 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 Apr 7 12:08: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 h37J8amh006089; Mon, 7 Apr 2003 12:08:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37J8aN2006088; Mon, 7 Apr 2003 12:08:36 -0700 (PDT) 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 h37J8Wmh006081 for ; Mon, 7 Apr 2003 12:08:32 -0700 (PDT) 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 h37J8dcU022882 for ; Mon, 7 Apr 2003 12:08:39 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA16455 for ; Mon, 7 Apr 2003 12:08:34 -0700 (PDT) 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, 7 Apr 2003 19:08:33 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, 7 Apr 2003 19:08: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; Mon, 7 Apr 2003 19:08:33 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, 7 Apr 2003 19:08:32 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 MAA24405; Mon, 7 Apr 2003 12:08:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h37J8U211156; Mon, 7 Apr 2003 12:08:30 -0700 X-mProtect: <200304071908> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZYTbej; Mon, 07 Apr 2003 12:08:29 PDT Message-Id: <3E91CCAD.AF49740F@iprg.nokia.com> Date: Mon, 07 Apr 2003 12:08:29 -0700 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: Margaret Wasserman CC: ipng@sunroof.eng.sun.com Subject: Re: Goals vs. process References: <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> <5.1.0.14.2.20030407055056.036f9188@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Margaret, I'm only an occasional drop-in, but: Margaret Wasserman wrote: > I think that we both see the flaws with site-local > addressing and would like to see it replaced with something better. I can readily agree with this also. > I also think that we both realize that the "real" solution would be > globally-routable PI addresses, I think it might be better to get global uniqueness first, and NOT attempt global routability. It is most likely not easy to get scalable global routability from PI addresses. So, if that's true we should not make the deprecation depend on this difficult thing. But anyway site-locals don't offer global routability, and so if we supply a globally unique set of addresses, that are NOT routable until they get to be routable later, isn't that good enough? I think if they're not routable, they're already (by nullity) provider independent. If we supply a routing protocol later for them, then so much the better. > I do think that the following needs are "real": > > 1 Addressing for disconnected sites. > 2 Addressing for intermittently connected sites. > 3 The need for local access control. > 4 The need for provider-independent local addresses that > remain stable when providers change/renumber. I would add (5): globally unique addresses, or _at least_ (5a): addresses that are astronomically likely to be unique. It seems to me that we can get all of these later by tinkering with the concept of global routability. I didn't write any specific 30+ page document for doing this tinkering, though... > The first one (disconnected) is relatively easy. I'd rather that > people registered a local, PI address, and I think we should offer > that option. Some people won't agree/choose to register, so we will > also need to offer some type of auto-generated option. But, there > is NO reasonable justification for why these addresses need to be > ambiguous, so they shouldn't be. Doesn't this mean that you also wish to mandate the same as my requirement 5{,a}? > The addressing for #2 may be handled the same way as #1, but > actually making connections survive disconnection and re-connection > at a new global address is more complicated than that, as it requires > that all local connections/applications prefer site-local addresses > while global connections/applications use global addresses. We will > need to figure out if this can be done in a way that is completely > compatible with behaving optimally on stably connected networks, or > if it will be necessary for implementations to get some type of > configuration hint regarding which way they should behave. Or, > possibly, we need to consider a different solution for this > case. I agree that we need to understand what the actual requirements > are here, before we can evaluate solutions. I agree with your last sentence here, and I also suggest that the work in doing so will take a while. It could be related to the problem of allowing an ad hoc network to utilize the advertised routing prefix of an Internet Gateway (see [manet]). Ideas for solution are available, but I don't believe the complete solution is known. Or, it might be related to the ideas being developed within the [nemo] (Network Mobility) working group... > We already have a couple of drafts that address #3 without site- > local addresses. Could you say a little more? Is it related to authorization? .......... > So, it is my opinion that if people put the level of value on > provider-independence that you suggest (and I believe you), then > they will choose NAT (and probably IPv4) unless/until we figure out > a way to provide NAT-less, provider-independent global addressing > in IPv6. [Note: I did not say that SL == NAT, nor did I say > that SLs increase the value of NAT, etc. I think that we have > this problem with or without site-local addresses.] I think this is an excellent challenge, and one we should try to meet. It seems to me that we ought not to make the discussion about site-local depend on it, though. Along the way, though, perhaps it's good to recognize that after all a NAT _is_ a "router" -- to a destination address which is implicit in other information available to the NAT but not to the source. The organization of the NAT's "route table" is not controlled by a traditional routing protocol. Perhaps we have to broaden our understanding of "routing" to include such other sorts of devices, before we can obtain the desired "global routability" of PI addresses. Or, maybe not -- it's just an idea...! 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 Mon Apr 7 12:52:12 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 h37JqCmh006668; Mon, 7 Apr 2003 12:52:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37JqBA3006667; Mon, 7 Apr 2003 12:52:11 -0700 (PDT) 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 h37Jq8mh006660 for ; Mon, 7 Apr 2003 12:52:08 -0700 (PDT) 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 h37JqFHP016302 for ; Mon, 7 Apr 2003 12:52:15 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA28009 for ; Mon, 7 Apr 2003 13:52:08 -0600 (MDT) 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, 7 Apr 2003 19:52: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; Mon, 7 Apr 2003 19:48: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; Mon, 7 Apr 2003 19:52:06 Z Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 19:52:05 Z Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id DB14F8676; Mon, 7 Apr 2003 14:52:03 -0500 (CDT) Received: from whitestar.zk3.dec.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 432E516DC; Mon, 7 Apr 2003 14:52:03 -0500 (CDT) Received: from hp.com by whitestar.zk3.dec.com (8.12.6/1.1.29.3/18Jul02-1258PM) id h37Jq01e042177; Mon, 7 Apr 2003 15:52:01 -0400 (EDT) Message-Id: <3E91D6E0.7070907@hp.com> Date: Mon, 07 Apr 2003 15:52:00 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > The question is: > > Should we deprecate IPv6 site-local unicast addressing? > "YES -- Deprecate site-local unicast addressing". -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX Network Group Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 13:47:48 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 h37Klmmh007817; Mon, 7 Apr 2003 13:47:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37KllEh007816; Mon, 7 Apr 2003 13:47:47 -0700 (PDT) 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 h37Klimh007809 for ; Mon, 7 Apr 2003 13:47:44 -0700 (PDT) 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 h37KlpHP005553 for ; Mon, 7 Apr 2003 13:47:51 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA11149 for ; Mon, 7 Apr 2003 13:47:46 -0700 (PDT) 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, 7 Apr 2003 20:47:45 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, 7 Apr 2003 20: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; Mon, 7 Apr 2003 20:47:44 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, 7 Apr 2003 20:47:43 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 VAA03682 for ; Mon, 7 Apr 2003 21:47:41 +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 VAA16943 for ; Mon, 7 Apr 2003 21:47:40 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h37KleM31767 for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 21:47:40 +0100 Date: Mon, 7 Apr 2003 21:47:40 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: ipng list Received: headers? Message-Id: <20030407204740.GC31150@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com 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 A bit off topic, but why do the ipng list messages go through so many hops inside Sun? Seems rather bizarre. 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 Apr 7 14:19: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 h37LJbmh008321; Mon, 7 Apr 2003 14:19:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37LJaTQ008320; Mon, 7 Apr 2003 14:19:36 -0700 (PDT) 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 h37LJXmh008313 for ; Mon, 7 Apr 2003 14:19:33 -0700 (PDT) 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 h37LJeHP017605 for ; Mon, 7 Apr 2003 14:19:40 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA19755 for ; Mon, 7 Apr 2003 15:19:34 -0600 (MDT) 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, 7 Apr 2003 21:19:34 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, 7 Apr 2003 21:19:34 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, 7 Apr 2003 21:19:33 Z Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 21:19:33 Z Received: from localhost (localhost [127.0.0.1]) by smistad.uninett.no (Postfix) with ESMTP id AF9F7292C2; Mon, 7 Apr 2003 23:19:32 +0200 (CEST) Date: Mon, 07 Apr 2003 23:19:32 +0200 (CEST) Message-Id: <20030407.231932.28973057.he@uninett.no> To: mrw@windriver.com Cc: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing From: Havard Eidnes In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> X-Mailer: Mew version 1.95b124 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h37LJXmh008314 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YES -- Deprecate site-local unicast addressing - Håvard -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 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 h37Lidmh008644; Mon, 7 Apr 2003 14:44:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37LidQP008643; Mon, 7 Apr 2003 14:44:39 -0700 (PDT) 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 h37Liamh008636 for ; Mon, 7 Apr 2003 14:44:36 -0700 (PDT) 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 h37LihHP026868 for ; Mon, 7 Apr 2003 14:44:43 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id OAA19256 for ; Mon, 7 Apr 2003 14:44:33 -0700 (PDT) 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, 7 Apr 2003 21:44:32 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, 7 Apr 2003 21:44:32 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, 7 Apr 2003 21:44:32 Z Received: from oak1a.cats.ohiou.edu ([132.235.8.44] [132.235.8.44]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 21:44:30 Z Received: from hkruse.csm.ohiou.edu (hkruse.csm.ohiou.edu [132.235.75.144]) (authenticated bits=0) by oak2a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id h37LhmPX1179512 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 7 Apr 2003 17:43:48 -0400 (EDT) Date: Mon, 07 Apr 2003 17:43:59 -0400 From: Hans Kruse To: ipng@sunroof.eng.sun.com cc: "JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" Subject: Discussion Re: : Deprecating Site-Local Addressing Message-Id: <1215416085.1049737439@hkruse.csm.ohiou.edu> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-MailScanner-VirusCheck: Found to be clean X-MailScanner-Information: http://www.cns.ohiou.edu/email/spam-virus.html X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.3, required 5, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, SPAM_PHRASE_00_01) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you! I have been trying for the past few days to explain how/why I came down on this side of the "vote", but you did a much better job than anything I had tried so far. Some comments inline with the edited message: --On Tuesday, April 08, 2003 02:47 +0900 "JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" wrote: > "NO -- Do not deprecate site-local unicast addressing". > > - because I'm not convinced that there is a clear consensus on an > alternative to site-local or that we do not need such a consensus. > > I'm sad I must vote for NO...I've tried to convince myself by > the meeting minutes, presentation slides, discussion in this list, and > some private discussion, but I failed. > I agree. > I could not be sure if we'll be able to make a consensus on any of > them (or others) quickly, if we choose "deprecating" site-local. If > not, the result will just be a confusion. If we can, then I don't see > why we cannot first make a consensus quickly and then deprecate > site-local. This is what I was trying to express, too. Maybe my "No" was more a statement on the (perceived) process. I mainly create, design, manage, and use research networks; many ad-hoc and transient, many for teaching purposes. Therefore: I DO NOT want anyone (least of all my students or new net admins) picking random prefixes for disconnected networks. I DO need readily available (non-routable) prefixes for disconnected and intermittently connected networks. While I can live with ambiguous ones for my stuff, I realize that they cause problems, and I will gladly go through a reasonable registration process to get unique ones (or create them with an autoconfig process); but these prefixes MUST BE recognizable (so they can be easily and readily filtered not just by me but by anyone without them knowing the prefixes I am currently using), and they cannot depend on a contractual relationship with an ISP or registry. I hope the outcome of this exercise can be a document that simultaneously - creates a "site local lite" concept that deals with a reasonable subset of the issues brought out over the past week, - lays out the roadmap for what still needs to be solved, - pulls the original site-locals out of future address architecture docs. Possible? Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 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 Mon Apr 7 15:02: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 h37M2Wmh008935; Mon, 7 Apr 2003 15:02:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37M2Wok008934; Mon, 7 Apr 2003 15:02:32 -0700 (PDT) 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 h37M2Rmh008927 for ; Mon, 7 Apr 2003 15:02:27 -0700 (PDT) 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 h37M2YHP003872 for ; Mon, 7 Apr 2003 15:02:35 -0700 (PDT) Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA26201 for ; Mon, 7 Apr 2003 16:02:29 -0600 (MDT) 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 <0HCZ00E51UK4TO@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 07 Apr 2003 16:02:29 -0600 (MDT) Received: from sun.com (dsl093-078-011.sfo2.dsl.speakeasy.net [66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HCZ00MWGUJ9SG@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 07 Apr 2003 16:01:58 -0600 (MDT) Date: Mon, 07 Apr 2003 15:03:22 -0700 From: Alain Durand Subject: Re: ipng list Received: headers? In-reply-to: <20030407204740.GC31150@login.ecs.soton.ac.uk> To: Tim Chown Cc: 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 Monday, April 7, 2003, at 01:47 PM, Tim Chown wrote: > A bit off topic, but why do the ipng list messages go through so many > hops inside Sun? Seems rather bizarre. Our IT people recently introduced anti-spam filters that causes several extra hops. We are working with them to reduce that number of extra hops. - 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 Apr 7 15:57:35 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 h37MvYmh009309; Mon, 7 Apr 2003 15:57:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h37MvY9u009308; Mon, 7 Apr 2003 15:57:34 -0700 (PDT) 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 h37MvVmh009301 for ; Mon, 7 Apr 2003 15:57:31 -0700 (PDT) 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 h37MvccU003218 for ; Mon, 7 Apr 2003 15:57:38 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA17150 for ; Mon, 7 Apr 2003 15:57:32 -0700 (PDT) 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, 7 Apr 2003 22:57: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, 7 Apr 2003 22:57: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, 7 Apr 2003 22:57:30 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 7 Apr 2003 22:57:30 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id CF6E6146C1; Tue, 8 Apr 2003 08:57:27 +1000 (EST) Date: Tue, 8 Apr 2003 08:57:27 +1000 From: "Nick 'Sharkey' Moore" To: ipng@sunroof.eng.sun.com Subject: Re: alternatives to site-locals? (Re: CONSENSUS CALL: Deprecating Site-Local Addressing) Message-Id: <20030407225727.GA25792@zoic.org> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <20030402142705.GB30669@ecs.soton.ac.uk> <006201c2f928$6933dd90$210d640a@unfix.org> <20030402160608.GD30669@ecs.soton.ac.uk> <20030404003440.GT22090@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030404003440.GT22090@login.ecs.soton.ac.uk> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Apr 04, 2003 at 01:34:40AM +0100, Tim Chown wrote: > > Note also in Mike's scenario he needs /48's to networks attached to > the community mesh, so the /10 property of a site-local is required, > and solutions which may allocate "random", non-aggregating /48's or > even /64's are not so desirable. Mike's working on Globally-Routable Provider Independent Addresses, I think ... which, if they can be made aggregatable, arguably deserve their own X::/3. -----N -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 17:19:46 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 h380Jkmh009777; Mon, 7 Apr 2003 17:19:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h380JkR9009776; Mon, 7 Apr 2003 17:19:46 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h380Jgmh009769 for ; Mon, 7 Apr 2003 17:19:42 -0700 (PDT) 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 h380Jm9P012216; Mon, 7 Apr 2003 20:19:48 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h380Jmaj017294; Mon, 7 Apr 2003 20:19:48 -0400 (EDT) Message-Id: <200304080019.h380Jmaj017294@thunk.east.sun.com> From: Bill Sommerfeld To: awhite@arc.corp.mot.com cc: IPng Subject: Re: A different FEC0::/10 proposal In-Reply-To: Your message of "Fri, 04 Apr 2003 18:16:45 +1000." <3E8D3F6D.3C780065@motorola.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 07 Apr 2003 20:19:48 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The address space FEC0::/10 is reserved for non-global use. It is intended > not to be globally routeable. All routers MUST by default blackhole any > packet destined to FEC0::/10, and MAY return a 'destination unreachable' > message. What's the rationale for having differing behavior in routers and hosts? It's becoming increasingly common for hosts to have multiple interfaces (including servers with multiple built-in ethernet ports and laptops with both wired and wireless connectivity). The laptop case seems particularly likely to "accidentally" end up on two "sites" at the same time.. It would be more consistent for both hosts and routers to blackhole fec0::/10 by default.. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 7 17:44: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 h380ilmh010045; Mon, 7 Apr 2003 17:44:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h380ilPI010044; Mon, 7 Apr 2003 17:44:47 -0700 (PDT) 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 h380ihmh010037 for ; Mon, 7 Apr 2003 17:44:43 -0700 (PDT) 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 h380iocU012839 for ; Mon, 7 Apr 2003 17:44:50 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id SAA21145 for ; Mon, 7 Apr 2003 18:44:45 -0600 (MDT) 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, 8 Apr 2003 00:44:45 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, 8 Apr 2003 00:44: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, 8 Apr 2003 00:44:44 Z Received: from ALPHA9.ITS.MONASH.EDU.AU (ALPHA9.ITS.MONASH.EDU.AU [130.194.1.9]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 00:44:43 Z Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KUHCSLZDTS9BXRLP@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 10:36:49 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5B2AA12C007; Tue, 08 Apr 2003 10:36:48 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 1066112C006; Tue, 08 Apr 2003 10:36:48 +1000 (EST) Date: Tue, 08 Apr 2003 10:36:47 +1000 From: Greg Daley Subject: Re: Goals vs. process To: "Charles E. Perkins" Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E92199F.2070702@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: <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> <5.1.0.14.2.20030407055056.036f9188@mail.windriver.com> <3E91CCAD.AF49740F@iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Charlie, A add-on about GUPI and Global Routability is below. Charles E. Perkins wrote: > Hello Margaret, > > I'm only an occasional drop-in, but: > > Margaret Wasserman wrote: > > >> I think that we both see the flaws with site-local >>addressing and would like to see it replaced with something better. > > > I can readily agree with this also. > > >>I also think that we both realize that the "real" solution would be >>globally-routable PI addresses, > > > I think it might be better to get global uniqueness first, and NOT > attempt global routability. It is most likely not easy to get > scalable global routability from PI addresses. So, if that's true > we should not make the deprecation depend on this difficult thing. > But anyway site-locals don't offer global routability, and so if we > supply a globally unique set of addresses, that are NOT routable until > they get to be routable later, isn't that good enough? I think that you're right in that we need a solution now, but I believe that if we can find a solution which has qualities which support global routability, then this should be favoured. We don't know if people will even want these addresses routed, and there's not much point putting the big effort in to fully preparing for routability if no one wants this. On the other hand, we may be able to ensure that we create a GUPI addressing scheme which meets GrouPI basic requirements: (aggregation, uniqueness, permanence). This may discount schemes which rely upon random prefix allocations though. There is a good discussion about the concept of 'address ownership' (PI) and 'address lending' (PA) in rfc 2008/BCP7. This points out pitfalls to PI which may prevent routability in any case. [rest snipped] Greg D. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 17:47: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 h380lpmh010163; Mon, 7 Apr 2003 17:47:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h380lpBY010162; Mon, 7 Apr 2003 17:47:51 -0700 (PDT) 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 h380llmh010152 for ; Mon, 7 Apr 2003 17:47:47 -0700 (PDT) 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 h380lsvV002183 for ; Mon, 7 Apr 2003 17:47:54 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id RAA28219 for ; Mon, 7 Apr 2003 17:47:49 -0700 (PDT) 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, 8 Apr 2003 00:47: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; Tue, 8 Apr 2003 00: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, 8 Apr 2003 00:47:48 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 00:47:47 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 07 Apr 2003 17:47:37 -0700 Reply-To: From: "Tony Hain" To: Subject: FW: Goals vs. process Date: Mon, 7 Apr 2003 17:47:38 -0700 Message-Id: <0d3201c2fd68$74f9cfb0$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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h380llmh010153 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It appears I didn't reply to this in a way that went to the list. > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Monday, April 07, 2003 9:53 AM > To: 'Margaret Wasserman' > Subject: RE: Goals vs. process > > > Margaret Wasserman wrote: > > You believe that they are a valuable tool for network > > administrators today -- as local, PI addressing. > > And that PI takes priority over global routability. This is > evidenced by NAT of unroutable global IPv4 as a preference > over PA space. > > > > > I think where I stand is pretty clear... > > > > I wrote a 30+ page document that outlines the problems and > > benefits with site-local addressing and concludes that the > > problems far outweigh the benefits. > > That is impossible to conclude without understanding the requirements. > > > > > I proposed the "limited" model to constrain site-local > > addresses to completely disconnected networks. > > > > I do think that the following needs are "real": > > > > 1 Addressing for disconnected sites. > > 2 Addressing for intermittently connected sites. > > 3 The need for local access control. > > 4 The need for provider-independent local addresses that > > remain stable when providers change/renumber. > > > > I just don't think that site-local addressing (ambiguous > > scoped addressing, as defined in the scoped addressing > > architecture and as allocated in prefix FEC0::/10) is the > > right solution to any of these problems. It is known to have > > substantial problems, and I think that we should stop > > encouraging people to invest in it further (in > > specifications, implementations, etc.) > > As you note ambiguous space is not required for these, and a > globally routable PI would solve these. The routing commuity > refuses to accept any globally routable PI proposals, and > continually raises concerns that any non-routable space will > be leaked into the routing system. > > > ... > > The addressing for #2 may be handled the same way as #1, but > > actually making connections survive disconnection and > > re-connection at a new global address is more complicated > > than that, as it requires that all local > > connections/applications prefer site-local addresses while > > global connections/applications use global addresses. We > > will need to figure out if this can be done in a way that is > > completely compatible with behaving optimally on stably > > connected networks, or if it will be necessary for > > implementations to get some type of configuration hint > > regarding which way they should behave. > > 'Optimal' behavior is a local decision, so hints are appropriate. > > > Or, possibly, we > > need to consider a different solution for this case. I agree > > that we need to understand what the actual requirements are > > here, before we can evaluate solutions. > > > > We already have a couple of drafts that address #3 without > > site- local addresses. > > > > #4 is only really solved by stable, unique, > > globally-routable, provider-independent addresses, but it > > could be partially solved by any solution to #1 (just like > > SLs partially solve it). Let me explain why it isn't solved > > by just giving two addresses to every machine... Assume I > > have a 200 node network with 10 routers. > > > > - If I use only global PA addresses, when my provider > > changes, I will need to change the global > > prefixes on my 30 routers, update my DNS, > > update any access lists/security associations > > on my 200 hosts (perhaps automatically), etc. > > I will need to do this before any global > > access will work. In the meantime, local > > access would continue to work until my formerly > > PA addresses become invalid (not just un-preferred, > > invalid), then it will start to fail if I haven't > > renumbered yet. > > > > - If I use both global PA addresses and local prefixes, > > when my provider changes, I will need to change > > the global prefixes on my 30 routers, update > > my (split) DNS, update any access list/security > > associates related to global addresses on my 200 > > hosts (perhaps automatically), etc. I will need > > to do this before any global access will work, > > although local access that actually uses site-local > > addresses (if I have any applications that know > > that they want to use site-local addresses) will > > continue to work indefinitely, and any local access > > that uses global prefixes will work until my > > old PA prefix becomes invalid, as above. > > > > Compare both of the cases above to what I do if I have NAT: > > > > - If I use NAT with internal local addressing and external > > PA addressing, when my provider changes, I > > renumber one side of my NAT box. Period. > > > > So, it is my opinion that if people put the level of value on > > provider-independence that you suggest (and I believe you), > > then they will choose NAT (and probably IPv4) unless/until we > > figure out a way to provide NAT-less, provider-independent > > global addressing in IPv6. [Note: I did not say that SL == > > NAT, nor did I say that SLs increase the value of NAT, etc. > > I think that we have this problem with or without site-local > > addresses.] > > I read this as you agree that solving the fundamental > requirement for stable addresses will result in the need for > globally routable PI's. Also that if we only provide > unroutable-PI, people might still prefer NAT for operational > simplicity. If I read that right, I agree. > > > > > I know that we don't know how to solve that problem right > > now. But, could we please stop arguing about site-local > > addresses (which _don't_ solve that problem at all, and don't > > solve any problem well) and start working on solutions to the > > real problem? > > The problem that ambiguity solves is enforcement of > unroutability of one form of PI space. It does that so well > that it creates issues for mergers or other non-public > interconnections. > > I agree we should get on with identifying the problems to be > solved, then solving them. My disagreement is over doing > anything that removes use of the current mechanism prior to > that work being completed. Partially that is due to a doubt > that even a simple majority of the ~130 voters for > deprecation will actually participate in solving the > problems, and partially that is due to a perception that the > group as a whole will not agree that the full set of > requirements are important enough to be included in the list. > If the result of the deprecation vote only results in a 'stop > work' directive on ambiguous addresses, I can live with that. > If it tries to go any further at this time, I am pointing out > that creates a serious problem because the site network > manager has no other tool for address space independent of > the provider. > > In discussions with Bill Woodcock a few minutes ago, it > became clear to me we are really struggling over the > requirement of the ISP to have stable addressing as customers > switch providers, vs. the requirement of the edge site to > have stable addressing as the site switches providers; the > requirement of the routing community for a strong aggregation > model vs. the requirement of the edge site for address space > that does not lock them to a provider; and the requirement of > the application community for a single scope address space > vs. the requirement of the edge site to filter parts of the > space to a local scope of use. This looks like the community > against the requirements of the site network manager (also my > take on the SF meeting), which completely misses the point > that the site manager is the customer of these services. The > customer is the one spending the money, so their requirements > will win, one way or another. > > 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 Apr 7 20:16: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 h383Gcmh011171; Mon, 7 Apr 2003 20:16:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h383Gcbc011170; Mon, 7 Apr 2003 20:16:38 -0700 (PDT) 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 h383GXmh011163 for ; Mon, 7 Apr 2003 20:16:33 -0700 (PDT) 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 h383GevV006724 for ; Mon, 7 Apr 2003 20:16:40 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id UAA17749 for ; Mon, 7 Apr 2003 20:16:34 -0700 (PDT) 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, 8 Apr 2003 03:16:34 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, 8 Apr 2003 03:16: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, 8 Apr 2003 03:16:34 Z Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 03:16:34 Z Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h383GhUq006653 for ; Mon, 7 Apr 2003 20:16:44 -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 UAA23384 for ; Mon, 7 Apr 2003 20:16:31 -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 h3838xmE026996 for ; Tue, 8 Apr 2003 13:09:00 +1000 (EST) Message-Id: <3E923D4B.395A8BD6@motorola.com> Date: Tue, 08 Apr 2003 13:08:59 +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: Re: A different FEC0::/10 proposal References: <3E8D3F6D.3C780065@motorola.com> <3E8D8941.C0CF8359@hursley.ibm.com> <3E90E508.362F6EEC@motorola.com> <431280000.1049704844@localhost.besserwisser.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Måns Nilsson wrote: > > --On Monday, April 07, 2003 12:40:08 +1000 Andrew White > wrote: > > > Brian E Carpenter wrote: > >> > >> This doesn't resolve the problem of ambiguous subnet prefixes > >> when routing domains merge. So it doesn't go far enough IMHO. > > > > That's because dealing with uniqueness and merging is a deployment > > issue, not an architectural issue. > > Might be so, but I think you are ignoring a lot of human behaviour > patterns when you believe it is a simple matter of operation to DTRT. > People will choose what they believe (and all too eager vendors insist) > is the easy way out. I strongly oppose the creation of guns with an > extra barrel pointed toward the users feet. You'll note I mentioned 4 different proposals for doing this right, several of which are relatively trivial to deploy. I see it as a two part process: (1) How the network that doesn't want to consider SL addresses should treat FEC0://10 prefixes. (2) How sub-networks that DO want to consider SL addresses should treat FEC0::/10 prefixes. My comment is: * Multiple non-unique address scopes add complexity, and don't gain much that can't be done via prefixes. Remove them. * FEC0:://10 as a PI non-routeable space has significant value to many applications. Let's enforce the global non-routeability in the architecture, and then we can deal with how to use it locally. > > The proposal specifies what the routing > > system and applications need to know about these restricted deployment > > addresses for correct general operation. > > The application must not have to know the network structure. That way > lies madness. Would that were true. If everything is single-homed, then you don't need to know about network structure simply because you can't do anything about it. You have one destination and one source. The only dimension you have control over is time. However, once anything is multi-homed, you have options. Some addresses may work while some may not. In a multi-homed environment, a robust application will try various source-destination pairs. Given that this is happening, it makes sense to hint to the application that some pairs are likely to work and some are likely to fail. Note that any situation where a single name could resolve to more than one address can be considered multi-homing. -- 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 Mon Apr 7 21:44: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 h384iYmh011816; Mon, 7 Apr 2003 21:44:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h384iXe8011815; Mon, 7 Apr 2003 21:44:33 -0700 (PDT) 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 h384iUmh011808 for ; Mon, 7 Apr 2003 21:44:30 -0700 (PDT) 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 h384ibvV024068 for ; Mon, 7 Apr 2003 21:44:37 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA00744 for ; Mon, 7 Apr 2003 21:44:31 -0700 (PDT) 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, 8 Apr 2003 04:44:24 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, 8 Apr 2003 04:23: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, 8 Apr 2003 04:26:53 Z Received: from zanzibar.karaba.org ([218.219.152.88] [218.219.152.88]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 04:26:52 Z Received: from [3ffe:501:1057:710::1] (helo=hyakusiki.karaba.org) by zanzibar.karaba.org with esmtp (Exim 3.35 #1 (Debian)) id 192kh6-0000TO-00 for ; Tue, 08 Apr 2003 13:26:48 +0900 Date: Tue, 08 Apr 2003 13:26:37 +0900 Message-Id: <871y0dmx6q.wl@karaba.org> From: Mitsuru KANDA / =?ISO-2022-JP?B?GyRCP0BFRBsoQiAbJEI9PBsoQg==?= To: ipng@sunroof.eng.sun.com Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing In-Reply-To: <20030407.231932.28973057.he@uninett.no> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> <20030407.231932.28973057.he@uninett.no> MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk NO -- Do NOT deprecate site-local unicast addressing. It's need for disconnected sites ---------------------------------------- Mitsuru KANDA (mk@karaba.org) Toshiba Reseach & Development Center Communication Platform Laboratory (mk@isl.rdc.toshiba.co.jp) USAGI Project (mk@linux-ipv6.org) . -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 22:59:06 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 h385x6mh012347; Mon, 7 Apr 2003 22:59:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h385x57H012346; Mon, 7 Apr 2003 22:59:05 -0700 (PDT) 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 h385x2mh012339 for ; Mon, 7 Apr 2003 22:59:02 -0700 (PDT) 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 h385x9cU027153 for ; Mon, 7 Apr 2003 22:59:09 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id WAA02215 for ; Mon, 7 Apr 2003 22:59:04 -0700 (PDT) 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, 8 Apr 2003 05:59: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; Tue, 8 Apr 2003 05:59: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; Tue, 8 Apr 2003 05:59:03 Z Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 05:59:03 Z Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h385uk9l016068; Tue, 8 Apr 2003 07:57:13 +0200 (MET DST) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 8 Apr 2003 07:58:56 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 8 Apr 2003 07:58:55 +0200 Date: Tue, 8 Apr 2003 07:58:54 +0200 Subject: Re: Yet another FEC0::/10 proposal Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: , To: john.loughney@nokia.com From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Message-Id: <2E186754-6987-11D7-88A6-000A959CF516@cisco.com> X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 08 Apr 2003 05:58:55.0722 (UTC) FILETIME=[F08764A0:01C2FD93] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h385x2mh012340 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On måndag, apr 7, 2003, at 07:58 Europe/Stockholm, john.loughney@nokia.com wrote: > One question, on the above, where you have text such as: > > MUST use an source address in the same scope > > What if we substituted it with: > > "MUST use an source address in the same scope or greater" > > That way, if nodes want to insist on using global addresses, then > that will become a default behavior. If we have three hosts, A, B and C, and A communicate with B, and B with C. Then A know the peer address of B, and B know the one of C, but, A doesn't know the one C has. Because of this, A doesn't know within what scope C is, and because of this algorithms like the one above doesn't work. An application can not make a choice based on scoping. paf -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 23:10:53 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 h386Armh012700; Mon, 7 Apr 2003 23:10:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h386Arrl012699; Mon, 7 Apr 2003 23:10:53 -0700 (PDT) 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 h386Anmh012692 for ; Mon, 7 Apr 2003 23:10:49 -0700 (PDT) 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 h386AuvV012003 for ; Mon, 7 Apr 2003 23:10:56 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id AAA03860 for ; Tue, 8 Apr 2003 00:10:51 -0600 (MDT) 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, 8 Apr 2003 06:10: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, 8 Apr 2003 06:10: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, 8 Apr 2003 06:10:50 Z Received: from slimsixten.besserwisser.org (slimsixten.besserwisser.org [213.212.3.212]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 06:10:49 Z Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id h386AVrp023633; Tue, 8 Apr 2003 08:10:32 +0200 (CEST) Date: Tue, 08 Apr 2003 08:10:31 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: Andrew White , IPng Subject: Re: A different FEC0::/10 proposal Message-Id: <751000000.1049782231@localhost.besserwisser.org> In-Reply-To: <3E923D4B.395A8BD6@motorola.com> References: <3E8D3F6D.3C780065@motorola.com> <3E8D8941.C0CF8359@hursley.ibm.com> <3E90E508.362F6EEC@motorola.com> <431280000.1049704844@localhost.besserwisser.org> <3E923D4B.395A8BD6@motorola.com> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========2478086430==========" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --==========2478086430========== Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Tuesday, April 08, 2003 13:08:59 +1000 Andrew White wrote: > (1) How the network that doesn't want to consider SL addresses should > treat FEC0://10 prefixes. As IANA "reserved" -- A bogon filter question.=20 > (2) How sub-networks that DO want to consider SL addresses should treat > FEC0::/10 prefixes. >=20 > My comment is: >=20 > * Multiple non-unique address scopes add complexity, and don't gain much > that can't be done via prefixes. Remove them. I say remove all non-unique bar LL and loopback.=20 > * FEC0:://10 as a PI non-routeable space has significant value to many > applications. Let's enforce the global non-routeability in the > architecture, and then we can deal with how to use it locally. It has significant issues in network operations 2 years after somebody chose to deploy SL and the company merges with another, that happened to take the same prefix. Have you ever tried this? I have, though in v4-land with multiple instances of the same RFC1918 adresses. I have been there, done that and gotten the straitjacket. I do not want even my enemies to endure that.=20 =20 >> The application must not have to know the network structure. That way >> lies madness. >=20 > Would that were true. If everything is single-homed, then you don't need > to know about network structure simply because you can't do anything > about it. You have one destination and one source. The only dimension > you have control over is time. > > However, once anything is multi-homed, you have options. Some addresses > may work while some may not. In a multi-homed environment, a robust > application will try various source-destination pairs. Given that this > is happening, it makes sense to hint to the application that some pairs > are likely to work and some are likely to fail. >=20 > Note that any situation where a single name could resolve to more than = one > address can be considered multi-homing. No, that is redundancy in DNS. Worng answer.=20 Multihoming means that there are several paths through the default-free zone via which a given prefix can be reached. These paths are logical (AS-path) as well as physical (2 different cables into the data center where the prefix lives.). No application I know of -- short of BGP and the brain of the tech who runs it -- has to deal with this. It just works. This is multihoming. Multiple prefixes and source routing are evil things that break this "just works" stuff and therefore must go away, for they implicate smartness in the wrong layers.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========2478086430========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+kmfX02/pMZDM1cURAl9iAKCgJTDf59geoe+ZYv1zItWad5DkWgCfYRIX MNKzHEwuSqWK+AYHjEBYVaQ= =8nTj -----END PGP SIGNATURE----- --==========2478086430==========-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 23:16:53 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 h386Grmh012895; Mon, 7 Apr 2003 23:16:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h386GqWZ012894; Mon, 7 Apr 2003 23:16:52 -0700 (PDT) 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 h386Gnmh012887 for ; Mon, 7 Apr 2003 23:16:49 -0700 (PDT) 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 h386GuvV013338 for ; Mon, 7 Apr 2003 23:16:56 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id AAA04974 for ; Tue, 8 Apr 2003 00:16:34 -0600 (MDT) 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, 8 Apr 2003 06:16: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; Tue, 8 Apr 2003 06:16: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; Tue, 8 Apr 2003 06:16:32 Z Received: from slimsixten.besserwisser.org (slimsixten.besserwisser.org [213.212.3.212]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 06:16:31 Z Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id h386Gbrp016005; Tue, 8 Apr 2003 08:16:38 +0200 (CEST) Date: Tue, 08 Apr 2003 08:16:37 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: Tim Chown , "ipng@sunroof.eng.sun.com" Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Message-Id: <758240000.1049782597@localhost.besserwisser.org> In-Reply-To: <20030407093146.GS23732@login.ecs.soton.ac.uk> References: <200304052043.PAA16343@ss10.danlan.com> <417230000.1049703524@localhost.besserwisser.org> <20030407093146.GS23732@login.ecs.soton.ac.uk> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1094865783==========" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --==========1094865783========== Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Monday, April 07, 2003 10:31:46 +0100 Tim Chown wrote: > Except that an ISP with a /32 is already in address conservation mode - = it > can only allocate 65K home network prefixes to customers. If it has a > million customers, then, HD-ratio included, it will need something like > a /22 allocation. While /32's exist, customer networks will either get=20 > dynamic prefixes or be allocated less than a /48. I do not work at a RIR, but I'd be very astonished to find resoning against giving such a large ISP more than one /32. I do not think it is a problem, once we are there.=20 > Of course the ISP would like to be able to charge for "extras" like = static > network prefixes. Aside from privacy issues, the static /48 prefix for > home and SOHO networks is a big win for IPv6. Yes, although I do not like the "charge extra" part.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========1094865783========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+kmlF02/pMZDM1cURApajAJ9G4wdbqinmtv4j/7326gXVFny07QCbBG0C N6s7rUr3zdCQxlYad0ce398= =8hcK -----END PGP SIGNATURE----- --==========1094865783==========-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 23:22:06 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 h386M6mh013091; Mon, 7 Apr 2003 23:22:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h386M64j013090; Mon, 7 Apr 2003 23:22:06 -0700 (PDT) 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 h386M2mh013083 for ; Mon, 7 Apr 2003 23:22:02 -0700 (PDT) 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 h386M9cU003062 for ; Mon, 7 Apr 2003 23:22:10 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id AAA07073 for ; Tue, 8 Apr 2003 00:22:02 -0600 (MDT) 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, 8 Apr 2003 06:21: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, 8 Apr 2003 06:18: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; Tue, 8 Apr 2003 06:21:52 Z Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 06:21:52 Z Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h386LgFP010888 for ; Mon, 7 Apr 2003 23:21:43 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id XAA27102 for ; Mon, 7 Apr 2003 23:21:41 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h386LlmE007269 for ; Tue, 8 Apr 2003 16:21:47 +1000 (EST) Message-Id: <3E926A79.6050508@motorola.com> Date: Tue, 08 Apr 2003 16:21:45 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng Subject: issues with the site local consensus call Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, There has been quite a deal of email on ipng supporting site-local deprecation, some of which has been sent by people whose opinion I would normally pay close attention to. Hence, I have been suprised to find myself disagreeing with much of that email, and surprised to see the number of "NO votes" on the list consensus call given the supposedly clear consensus in the room. My situation is that I came in to the ipng meeting in the last 5 minutes, and voted NO to deprecation. Having not heard all the discussion, I made the assumption that deprecating site local meant that GUSL and solutions to the intermittently connected case were going down with the same sinking ship. I think this is a common assumption being made by NO voters on the list. Now from wading through the scads of email on the ipng list, I see that the position could be more nuanced than that, but I have the suspicion that I'm still guessing what the real position was. I have come to the conclusion that the consensus call email on the list failed to adequately describe what a YES for deprecation actually entailed, and has pretty effectively shot itself in the foot. Some observations: - there was no clear text summarising what a YES to deprecate actually meant (some inkling can be deduced from other pieces of email, but you really have to dig) Effectively, the only way you would have known what YES - deprecate actually meant was if you were physically in the room. Hence I think you would need to watch the video to figure it out. - the minutes are inadequate material on which to work out what happened during the meeting, and the presentation doesn't seem to have a lot of bearing either. - there were a whole lot of reasons supplied to vote NO in the CONSENSUS CALL email, and none supplied for why you might want to vote YES I think that set list-only people up to vote NO. Margaret's text in response to the "Consensus on what?" thread is more like what I would have liked to see in the original call email. I would like to see a clear summary posted to the list of what the chairs believe voting "YES, deprecate" during the meeting meant. Further, I think that deprecation of site-local would be more palatable if it were linked to a formal statement that the WG treated the "reasons to vote NO" in the consensus call as work items. Then there would be fewer reasons to vote NO. regards aidan ____ :wq! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 7 23:48: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 h386mfmh013794; Mon, 7 Apr 2003 23:48:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h386meWd013793; Mon, 7 Apr 2003 23:48:40 -0700 (PDT) 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 h386mbmh013786 for ; Mon, 7 Apr 2003 23:48:37 -0700 (PDT) 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 h386micU009342 for ; Mon, 7 Apr 2003 23:48:44 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id XAA01039 for ; Mon, 7 Apr 2003 23:48:38 -0700 (PDT) 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, 8 Apr 2003 06:48: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; Tue, 8 Apr 2003 06:48: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; Tue, 8 Apr 2003 06:48:38 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, 8 Apr 2003 06:48:37 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 HAA06725 for ; Tue, 8 Apr 2003 07:48:36 +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 HAA25670 for ; Tue, 8 Apr 2003 07:48:36 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h386maT19219 for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 07:48:36 +0100 Date: Tue, 8 Apr 2003 07:48:36 +0100 From: Tim Chown To: "ipng@sunroof.eng.sun.com" Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Message-Id: <20030408064836.GB19150@login.ecs.soton.ac.uk> Mail-Followup-To: "ipng@sunroof.eng.sun.com" References: <200304052043.PAA16343@ss10.danlan.com> <417230000.1049703524@localhost.besserwisser.org> <20030407093146.GS23732@login.ecs.soton.ac.uk> <758240000.1049782597@localhost.besserwisser.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <758240000.1049782597@localhost.besserwisser.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Apr 08, 2003 at 08:16:37AM +0200, Måns Nilsson wrote: > > --On Monday, April 07, 2003 10:31:46 +0100 Tim Chown > wrote: > > > Except that an ISP with a /32 is already in address conservation mode - it > > can only allocate 65K home network prefixes to customers. If it has a > > million customers, then, HD-ratio included, it will need something like > > a /22 allocation. While /32's exist, customer networks will either get > > dynamic prefixes or be allocated less than a /48. > > I do not work at a RIR, but I'd be very astonished to find resoning against > giving such a large ISP more than one /32. I do not think it is a problem, > once we are there. I am relaying comments from telco operators who say that /32 is not enough if we want static prefix delegations to large numbers of customers (a typical large DSL operator will have over 1M subscribers). Either the telco needs to know they can get an *aggregatable* /22 (or similar) now, else they will have to either allocate dynamic prefixes or /64 prefixes to homes/SME's who use DSL. The telcos are also not clear that they have a process to apply for a /22. Also, they would be unlikely to find many disjoint /32's efficient (after all, we want aggregation with IPv6, don't we?). 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 Apr 7 23:59: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 h386xAmh014162; Mon, 7 Apr 2003 23:59:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h386xAOH014161; Mon, 7 Apr 2003 23:59:10 -0700 (PDT) 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 h386x7mh014154 for ; Mon, 7 Apr 2003 23:59:07 -0700 (PDT) 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 h386xDcU012042 for ; Mon, 7 Apr 2003 23:59:14 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id AAA25202 for ; Tue, 8 Apr 2003 00:59:07 -0600 (MDT) 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, 8 Apr 2003 06:59:07 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, 8 Apr 2003 06:55: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; Tue, 8 Apr 2003 06:59: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, 8 Apr 2003 06:59:06 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 HAA06788 for ; Tue, 8 Apr 2003 07:59:04 +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 HAA25819 for ; Tue, 8 Apr 2003 07:59:04 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h386x4D19263 for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 07:59:04 +0100 Date: Tue, 8 Apr 2003 07:59:04 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: ipng list Received: headers? Message-Id: <20030408065904.GF19150@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <20030407204740.GC31150@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 Mon, Apr 07, 2003 at 03:03:22PM -0700, Alain Durand wrote: > > On Monday, April 7, 2003, at 01:47 PM, Tim Chown wrote: > > >A bit off topic, but why do the ipng list messages go through so many > >hops inside Sun? Seems rather bizarre. > > Our IT people recently introduced anti-spam filters that causes > several extra hops. We are working with them to reduce that > number of extra hops. OK, but why so many hops? We developed www.mailscannner.info here - open source, handles spam and virii. Ought to be one extra hop :) 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 Apr 8 00:09: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 h3879Dmh014572; Tue, 8 Apr 2003 00:09:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3879Dj9014571; Tue, 8 Apr 2003 00:09:13 -0700 (PDT) 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 h38798mh014558 for ; Tue, 8 Apr 2003 00:09:08 -0700 (PDT) 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 h3879BvV025986 for ; Tue, 8 Apr 2003 00:09:11 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id BAA05649 for ; Tue, 8 Apr 2003 01:09:05 -0600 (MDT) 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, 8 Apr 2003 07:09: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; Tue, 8 Apr 2003 07:09:05 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, 8 Apr 2003 07:09:04 Z Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 07:09:03 Z Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h38791S8006926 for ; Tue, 8 Apr 2003 00:09:01 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id AAA12883 for ; Tue, 8 Apr 2003 00:08:51 -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 h3878vmE009881 for ; Tue, 8 Apr 2003 17:08:57 +1000 (EST) Message-Id: <3E927589.ABC089B1@motorola.com> Date: Tue, 08 Apr 2003 17:08:57 +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: Re: A different FEC0::/10 proposal References: <3E8D3F6D.3C780065@motorola.com> <3E8D8941.C0CF8359@hursley.ibm.com> <3E90E508.362F6EEC@motorola.com> <431280000.1049704844@localhost.besserwisser.org> <3E923D4B.395A8BD6@motorola.com> <751000000.1049782231@localhost.besserwisser.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Måns Nilsson wrote: > > * FEC0:://10 as a PI non-routeable space has significant value to many > > applications. Let's enforce the global non-routeability in the > > architecture, and then we can deal with how to use it locally. > > It has significant issues in network operations 2 years after somebody > chose to deploy SL and the company merges with another, that happened to > take the same prefix. Have you ever tried this? I have, though in v4-land > with multiple instances of the same RFC1918 adresses. I have been there, > done that and gotten the straitjacket. I do not want even my enemies to > endure that. Are you deliberately ignoring the second part? > > (2) How sub-networks that DO want to consider SL addresses should treat > > FEC0::/10 prefixes. The assumption of all these SL proposals is that we define good mechanisms for setting up the SL space. Several programmatic and allocated mechanisms have been proposed to ensure global uniqueness. Yes, people are free to ignore them. But then I'm ALSO free to use someone else's global address internally. Or drive the wrong way up one way streets. Or do a bunch of other stupid things deliberately ignoring the recommendations. And usually, it's considered my fault when things don't work because of it. > >> The application must not have to know the network structure. That way > >> lies madness. [...] > Multihoming means that there are several paths through the default-free > zone via which a given prefix can be reached. ... Ok. We're talking different definitions of multihoming. Replace all mention of 'multihoming' with 'a node having more than one IP address'. That said, you've missed my point (and Tony Hain's as well). Throw a filter in there. Or perhaps multi-path multihoming with a misconfigured link. I (as application writer) pick a destination address (as returned by gethostbyname or similar). I attempt a connection. It fails. At this point I have two options. (1) I give up. (2) I try a different address offered (remember, I may have received more than one). At some point, the end host in a multi-homed scenario MUST make a decision which address to choose. And that choice may be wrong, and if so the application needs to have a recovery mechanism. Using a common top-level prefix for private addresses provides a way to bias that choice. -- 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 Tue Apr 8 00:57: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 h387vqmh015275; Tue, 8 Apr 2003 00:57:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h387vqGc015274; Tue, 8 Apr 2003 00:57:52 -0700 (PDT) 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 h387vmmh015267 for ; Tue, 8 Apr 2003 00:57:48 -0700 (PDT) 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 h387vtvV006990 for ; Tue, 8 Apr 2003 00:57:55 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id BAA05993 for ; Tue, 8 Apr 2003 01:57:49 -0600 (MDT) 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, 8 Apr 2003 07:57:49 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, 8 Apr 2003 07:57: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; Tue, 8 Apr 2003 07:57:49 Z Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 07:57:48 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h387vcUm024926; Tue, 8 Apr 2003 09:57:41 +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 h387vWrx271190; Tue, 8 Apr 2003 09:57:34 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59090 from ; Tue, 8 Apr 2003 09:57:30 +0200 Message-Id: <3E928117.8AD2606F@hursley.ibm.com> Date: Tue, 08 Apr 2003 09:58:15 +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: Leif Johansson Cc: ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs References: <200304062001.QAA21963@ss10.danlan.com> <3E9087B1.6010100@it.su.se> <3E9131AD.A80CD197@hursley.ibm.com> <3E91AECF.7060300@it.su.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Leif Johansson wrote: > > Brian E Carpenter wrote: > > >I'm afraid I don't agree with you. On the contrary, middleware that > >cares about performance and survivability absolutely has to care > >about path selection in some way or another. But I think this is > >a somewhat separate issue from ambiguous SLs and the specific scope > >problems that they cause. > > > > > > > Even at the risk of polluting the thread ;-) I'll bite: Could you give > an example > of such middleware? Reliable message passing systems such as MQ Series On-line transaction processing Remote data base write/update access All of these need to seek maximum performance (transactions per second) and minimum latency, and to retain connectivity 24x7 whatever happens in the network. That means probing for highest performance paths or for alternate paths when connectivity fails. Today this has to be done in the crudest way possible (try address A and if that's no good, try address B). 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 Apr 8 01:04: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 h38840mh015521; Tue, 8 Apr 2003 01:04:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38840AY015520; Tue, 8 Apr 2003 01:04:00 -0700 (PDT) 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 h3883smh015507 for ; Tue, 8 Apr 2003 01:03:55 -0700 (PDT) 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 h38841vV008777 for ; Tue, 8 Apr 2003 01:04:01 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id CAA07163 for ; Tue, 8 Apr 2003 02:03:55 -0600 (MDT) 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, 8 Apr 2003 08:03: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; Tue, 8 Apr 2003 08:03: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; Tue, 8 Apr 2003 08:03:49 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; Tue, 8 Apr 2003 08:03:48 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3883PCi060200; Tue, 8 Apr 2003 10:03:26 +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 h3883DC2242614; Tue, 8 Apr 2003 10:03:14 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54450 from ; Tue, 8 Apr 2003 10:03:08 +0200 Message-Id: <3E92826A.572FE8B@hursley.ibm.com> Date: Tue, 08 Apr 2003 10:03:54 +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: "Fred L. Templin" Cc: alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solvesthe problems people want to solve References: <0bcc01c2fb90$0da62590$ee1a4104@eagleswings> <3E8FF01E.BA74CDCA@hursley.ibm.com> <3E91B850.4030203@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Fred L. Templin" wrote: > > Brian, > > Brian E Carpenter wrote: > > As for whether we can do what the RRG has failed to do, of course > > not. But it seems fairly clear we can define unambiguous PI space. > > Can you say more about this? Is there a proposal defining an > unambiguous PI space that I may have missed? I think there have been several half proposals, but you can see the Tony Hain and Andrew White drafts for fairly full examples. 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 Apr 8 01:45:28 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 h388jRmh016202; Tue, 8 Apr 2003 01:45:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h388jRGG016201; Tue, 8 Apr 2003 01:45:27 -0700 (PDT) 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 h388jOmh016194 for ; Tue, 8 Apr 2003 01:45:24 -0700 (PDT) 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 h388jVvV017571 for ; Tue, 8 Apr 2003 01:45:31 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id CAA03728 for ; Tue, 8 Apr 2003 02:45:20 -0600 (MDT) 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, 8 Apr 2003 08:44:15 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, 8 Apr 2003 08:40:48 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, 8 Apr 2003 08:44:14 Z Received: from a80-126-101-63.adsl.xs4all.nl (a80-126-101-63.adsl.xs4all.nl [80.126.101.63]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 08:44:13 Z Received: (from rvdp@localhost) by a80-126-101-63.adsl.xs4all.nl (8.11.6p2/8.11.6) id h388iA520228 for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 10:44:10 +0200 (CEST) Date: Tue, 8 Apr 2003 10:44:10 +0200 From: Ronald van der Pol To: "ipng@sunroof.eng.sun.com" Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Message-Id: <20030408084410.GD16238@rvdp.org> References: <200304052043.PAA16343@ss10.danlan.com> <417230000.1049703524@localhost.besserwisser.org> <20030407093146.GS23732@login.ecs.soton.ac.uk> <758240000.1049782597@localhost.besserwisser.org> <20030408064836.GB19150@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030408064836.GB19150@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Apr 08, 2003 at 07:48:36 +0100, Tim Chown wrote: > The telcos are also not clear that they have a process to apply for a /22. > Also, they would be unlikely to find many disjoint /32's efficient (after > all, we want aggregation with IPv6, don't we?). So I guess we have to keep this on the agendas of the RIR meetings. 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 Tue Apr 8 02:29: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 h389Tsmh016589; Tue, 8 Apr 2003 02:29:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h389TsGE016583; Tue, 8 Apr 2003 02:29:54 -0700 (PDT) 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 h389Tomh016574 for ; Tue, 8 Apr 2003 02:29:50 -0700 (PDT) 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 h389TvvV026176 for ; Tue, 8 Apr 2003 02:29:57 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA21070 for ; Tue, 8 Apr 2003 03:29:50 -0600 (MDT) 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, 8 Apr 2003 09:29: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; Tue, 8 Apr 2003 09:29: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; Tue, 8 Apr 2003 09:29:48 Z Received: from slimsixten.besserwisser.org ([192.36.125.116] [192.36.125.116]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 09:29:47 Z Received: from localhost.besserwisser.org (mansaxel@localhost.besserwisser.org [127.0.0.1]) by slimsixten.besserwisser.org (8.12.6/8.12.2) with ESMTP id h389ToYX028624; Tue, 8 Apr 2003 11:29:50 +0200 (CEST) Date: Tue, 08 Apr 2003 11:29:49 +0200 From: =?ISO-8859-1?Q?M=E5ns_Nilsson?= To: Tim Chown , "ipng@sunroof.eng.sun.com" Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Message-Id: <885020000.1049794189@localhost.besserwisser.org> In-Reply-To: <20030408064836.GB19150@login.ecs.soton.ac.uk> References: <200304052043.PAA16343@ss10.danlan.com> <417230000.1049703524@localhost.besserwisser.org> <20030407093146.GS23732@login.ecs.soton.ac.uk> <758240000.1049782597@localhost.besserwisser.org> <20030408064836.GB19150@login.ecs.soton.ac.uk> X-Mailer: Mulberry/2.2.1 (OpenBSD/x86) X-PGP-KEY: http://vvv.besserwisser.org/key MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1164342863==========" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --==========1164342863========== Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Tuesday, April 08, 2003 07:48:36 +0100 Tim Chown wrote: > I am relaying comments from telco operators who say that /32 is not = enough > if we want static prefix delegations to large numbers of customers (a > typical large DSL operator will have over 1M subscribers). Either the > telco needs to know they can get an *aggregatable* /22 (or similar) now, > else they will have to either allocate dynamic prefixes or /64 prefixes > to homes/SME's who use DSL. >=20 > The telcos are also not clear that they have a process to apply for a = /22. > Also, they would be unlikely to find many disjoint /32's efficient (after > all, we want aggregation with IPv6, don't we?). I find it *very* hard to justify SL because Telco registry people are incompetent. ;-)=20 And, I am quite convinced that RIRen allocate so that they can give out larger prefixes as things grow.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead. --==========1164342863========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE+kpaO02/pMZDM1cURAm43AJ9ejN8sKM0FhjutTA9lLaDrJqvSegCghzN8 1KJ5ag08U8o0/VJOd6xZkRU= =3w6P -----END PGP SIGNATURE----- --==========1164342863==========-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 8 03:03: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 h38A3Bmh016942; Tue, 8 Apr 2003 03:03:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38A3BBk016941; Tue, 8 Apr 2003 03:03:11 -0700 (PDT) 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 h38A37mh016934 for ; Tue, 8 Apr 2003 03:03:07 -0700 (PDT) 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 h38A3FcU026079 for ; Tue, 8 Apr 2003 03:03:15 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA03666 for ; Tue, 8 Apr 2003 03:03:10 -0700 (PDT) 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, 8 Apr 2003 10:03: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, 8 Apr 2003 10:03: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, 8 Apr 2003 10:03:08 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, 8 Apr 2003 10:03:08 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h38A2Wju079736; Tue, 8 Apr 2003 12:02:35 +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 h38A2Trx071678; Tue, 8 Apr 2003 12:02:30 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA12902 from ; Tue, 8 Apr 2003 12:02:28 +0200 Message-Id: <3E929E62.D4CBA7C@hursley.ibm.com> Date: Tue, 08 Apr 2003 12:03:14 +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: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve References: <200304052043.PAA16343@ss10.danlan.com> <417230000.1049703524@localhost.besserwisser.org> <20030407093146.GS23732@login.ecs.soton.ac.uk> <758240000.1049782597@localhost.besserwisser.org> <20030408064836.GB19150@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h38A38mh016935 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown wrote: > > On Tue, Apr 08, 2003 at 08:16:37AM +0200, Måns Nilsson wrote: > > > > --On Monday, April 07, 2003 10:31:46 +0100 Tim Chown > > wrote: > > > > > Except that an ISP with a /32 is already in address conservation mode - it > > > can only allocate 65K home network prefixes to customers. If it has a > > > million customers, then, HD-ratio included, it will need something like > > > a /22 allocation. While /32's exist, customer networks will either get > > > dynamic prefixes or be allocated less than a /48. > > > > I do not work at a RIR, but I'd be very astonished to find resoning against > > giving such a large ISP more than one /32. I do not think it is a problem, > > once we are there. > > I am relaying comments from telco operators who say that /32 is not enough > if we want static prefix delegations to large numbers of customers (a typical > large DSL operator will have over 1M subscribers). Either the telco needs > to know they can get an *aggregatable* /22 (or similar) now, else they will > have to either allocate dynamic prefixes or /64 prefixes to homes/SME's who > use DSL. > > The telcos are also not clear that they have a process to apply for a /22. > Also, they would be unlikely to find many disjoint /32's efficient (after > all, we want aggregation with IPv6, don't we?). I thought that was the reason for the RIR's sparse allocation policy at http://www.ripe.net/ripe/docs/ipv6-sparse.html In my experience the RIR's are *acutely* aware of the concern you mention. 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 Apr 8 03:11: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 h38ABWmh017202; Tue, 8 Apr 2003 03:11:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38ABWCc017201; Tue, 8 Apr 2003 03:11:32 -0700 (PDT) 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 h38ABSmh017188 for ; Tue, 8 Apr 2003 03:11:28 -0700 (PDT) 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 h38ABacU027670 for ; Tue, 8 Apr 2003 03:11:36 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id EAA07392 for ; Tue, 8 Apr 2003 04:11:16 -0600 (MDT) 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, 8 Apr 2003 10:09: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; Tue, 8 Apr 2003 10:09:54 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, 8 Apr 2003 10:09:54 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, 8 Apr 2003 10:09:54 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id EFED98A00; Tue, 8 Apr 2003 12:09:49 +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 074DD7DC3; Tue, 8 Apr 2003 12:09:44 +0200 (CEST) From: "Jeroen Massar" To: "=?iso-8859-1?Q?'M=E5ns_Nilsson'?=" , "'Tim Chown'" , Subject: RE: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Date: Tue, 8 Apr 2003 12:10:58 +0200 Organization: Unfix Message-Id: <000f01c2fdb7$26f3ce70$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: <885020000.1049794189@localhost.besserwisser.org> 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 h38ABSmh017190 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Måns Nilsson wrote: > --On Tuesday, April 08, 2003 07:48:36 +0100 Tim Chown > > wrote: > > > I am relaying comments from telco operators who say that /32 is not enough > > if we want static prefix delegations to large numbers of customers (a > > typical large DSL operator will have over 1M subscribers). Either the > > telco needs to know they can get an *aggregatable* /22 (or similar) now, > > else they will have to either allocate dynamic prefixes or /64 prefixes > > to homes/SME's who use DSL. > > > > The telcos are also not clear that they have a process to apply for a /22. > > Also, they would be unlikely to find many disjoint /32's efficient (after > > all, we want aggregation with IPv6, don't we?). > > I find it *very* hard to justify SL because Telco registry people are > incompetent. ;-) > > And, I am quite convinced that RIRen allocate so that they > can give out larger prefixes as things grow. Currently the RIRs who do IPv6 (ARIN,APNIC,RIPE) give out /32's from a /29 growing space. And ofcourse if you really need more you should just go the RIRs and ask... If you are big enough you can also convince them that you need it and one should then be able to get it ofcourse. This should result in every endsite getting a globally routable /48 from it's upstream may it be a home site or a company. Based on the fact that more and more people are setting up wlan one can easily figure out that there are more than one network in those endsites thus that they require a /48 instead of a single /64. It's also easier for administration in most cases instead of having seperate /64's and /48 allocations. 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 Apr 8 03:19: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 h38AJ5mh017621; Tue, 8 Apr 2003 03:19:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38AJ4Q9017620; Tue, 8 Apr 2003 03:19:04 -0700 (PDT) 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 h38AJ1mh017611 for ; Tue, 8 Apr 2003 03:19:01 -0700 (PDT) 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 h38AJ9cU029634 for ; Tue, 8 Apr 2003 03:19:09 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA28952 for ; Tue, 8 Apr 2003 04:19:03 -0600 (MDT) 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, 8 Apr 2003 10:19:02 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, 8 Apr 2003 10:19: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; Tue, 8 Apr 2003 10:18:54 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, 8 Apr 2003 10:18:54 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 LAA09359 for ; Tue, 8 Apr 2003 11:18:52 +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 LAA04915 for ; Tue, 8 Apr 2003 11:18:52 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h38AIqP26715 for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 11:18:52 +0100 Date: Tue, 8 Apr 2003 11:18:52 +0100 From: Tim Chown To: "ipng@sunroof.eng.sun.com" Subject: Is /32 enough? (was Re: Patrick Faltstrom...) Message-Id: <20030408101852.GC26495@login.ecs.soton.ac.uk> Mail-Followup-To: "ipng@sunroof.eng.sun.com" References: <200304052043.PAA16343@ss10.danlan.com> <417230000.1049703524@localhost.besserwisser.org> <20030407093146.GS23732@login.ecs.soton.ac.uk> <758240000.1049782597@localhost.besserwisser.org> <20030408064836.GB19150@login.ecs.soton.ac.uk> <885020000.1049794189@localhost.besserwisser.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <885020000.1049794189@localhost.besserwisser.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Apr 08, 2003 at 11:29:49AM +0200, Måns Nilsson wrote: > > --On Tuesday, April 08, 2003 07:48:36 +0100 Tim Chown > wrote: > > > I am relaying comments from telco operators who say that /32 is not enough > > if we want static prefix delegations to large numbers of customers (a > > typical large DSL operator will have over 1M subscribers). Either the > > telco needs to know they can get an *aggregatable* /22 (or similar) now, > > else they will have to either allocate dynamic prefixes or /64 prefixes > > to homes/SME's who use DSL. > > > > The telcos are also not clear that they have a process to apply for a /22. > > Also, they would be unlikely to find many disjoint /32's efficient (after > > all, we want aggregation with IPv6, don't we?). > > I find it *very* hard to justify SL because Telco registry people are > incompetent. ;-) This has nothing to do with site locals, except that telcos need prefix headroom to avoid having pressure to use dynamic prefixes. The key thing for stable addressing is that the big ISPs have clear headroom. > And, I am quite convinced that RIRen allocate so that they can give out > larger prefixes as things grow. Yes, they allocate with some headroom, but is it enough? e.g. CWJ-JPNIC-JP-20020910 2001:0C70::/32 NTTIP-AU-20020910 2001:0C78::/32 InterVia-JPNIC-JP-20020916 2001:0C80::/32 CYPRESS-NET6-JPNIC-JP-20020918 2001:0C88::/32 from http://www.ripe.net/ripencc/mem-services/registration/ipv6/ipv6allocs.html So there are 8 /32's available per allocation, kind of. In other words an ISP can grow to a /28, which is 2^20 /48's, which is 1M /48's, but only if you ignore practicalities of deployment (which manifest themselves loosely in the HD-ratio - RFC3194 I think - and I recall Alain Durand also did a corresponding I-D for prefix allocations). We don't want to put telcos or ISPs in the position where if they look for a plan to deploy to a million end-users (long term) they feel "cramped" and thus use dynamic allocations or /64's... so now they can get multiple /28's with growth, but these would be not aggregated. 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 Apr 8 03: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 h38AQkmh018091; Tue, 8 Apr 2003 03:26:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38AQkCo018090; Tue, 8 Apr 2003 03:26:46 -0700 (PDT) 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 h38AQhmh018080 for ; Tue, 8 Apr 2003 03:26:43 -0700 (PDT) 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 h38AQpvV007879 for ; Tue, 8 Apr 2003 03:26:51 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA22234 for ; Tue, 8 Apr 2003 03:26:45 -0700 (PDT) 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, 8 Apr 2003 10:26:45 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP; Tue, 8 Apr 2003 10:26:44 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP; Tue, 8 Apr 2003 10:26:44 Z Received: from kirk.rvdp.org (kirk.rvdp.org [80.126.101.63]) by relay1.sun.com with ESMTP; Tue, 8 Apr 2003 10:26:44 Z Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6p2/8.11.6) id h38AQgG12841; Tue, 8 Apr 2003 12:26:42 +0200 (CEST) Date: Tue, 8 Apr 2003 12:26:42 +0200 From: Ronald van der Pol To: Alain Durand Cc: Tim Chown , ipng@sunroof.eng.sun.com Subject: Re: ipng list Received: headers? Message-Id: <20030408102642.GG16238@rvdp.org> References: <20030407204740.GC31150@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.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Apr 07, 2003 at 15:03:22 -0700, Alain Durand wrote: > Our IT people recently introduced anti-spam filters that causes > several extra hops. We are working with them to reduce that > number of extra hops. And while you are working on the email setup, could you also look at IPv6 transport support (both incoming and outgoing)? I would appreciate that very much. 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 Tue Apr 8 03:49: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 h38Anqmh018941; Tue, 8 Apr 2003 03:49:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38AnpBk018940; Tue, 8 Apr 2003 03:49:51 -0700 (PDT) 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 h38Anmmh018933 for ; Tue, 8 Apr 2003 03:49:48 -0700 (PDT) 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 h38AnuvV012933 for ; Tue, 8 Apr 2003 03:49:56 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA24413 for ; Tue, 8 Apr 2003 04:49:51 -0600 (MDT) 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, 8 Apr 2003 10:49: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, 8 Apr 2003 10:49: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, 8 Apr 2003 10:49:50 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, 8 Apr 2003 10:49:49 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 LAA09979 for ; Tue, 8 Apr 2003 11:49:46 +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 LAA06478 for ; Tue, 8 Apr 2003 11:49:46 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h38AnkF27099 for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 11:49:46 +0100 Date: Tue, 8 Apr 2003 11:49:46 +0100 From: Tim Chown To: "ipng@sunroof.eng.sun.com" Subject: Re: Is /32 enough? (was Re: Patrick Faltstrom...) Message-Id: <20030408104946.GA27074@login.ecs.soton.ac.uk> Mail-Followup-To: "ipng@sunroof.eng.sun.com" References: <200304052043.PAA16343@ss10.danlan.com> <417230000.1049703524@localhost.besserwisser.org> <20030407093146.GS23732@login.ecs.soton.ac.uk> <758240000.1049782597@localhost.besserwisser.org> <20030408064836.GB19150@login.ecs.soton.ac.uk> <885020000.1049794189@localhost.besserwisser.org> <20030408101852.GC26495@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030408101852.GC26495@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Apr 08, 2003 at 11:18:52AM +0100, Tim Chown wrote: > > So there are 8 /32's available per allocation, kind of. In other words > an ISP can grow to a /28, which is 2^20 /48's, which is 1M /48's, but (Actually I think that's a /29, or 500K prefixes max...) 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 Apr 8 04:31:02 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 h38BV1mh019467; Tue, 8 Apr 2003 04:31:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38BV1td019466; Tue, 8 Apr 2003 04:31:01 -0700 (PDT) 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 h38BUwmh019459 for ; Tue, 8 Apr 2003 04:30:58 -0700 (PDT) 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 h38BV6vV020256 for ; Tue, 8 Apr 2003 04:31:06 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA16278 for ; Tue, 8 Apr 2003 05:30:59 -0600 (MDT) 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, 8 Apr 2003 11:30: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; Tue, 8 Apr 2003 11:27: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, 8 Apr 2003 11:30:44 Z Received: from holyail.pilsnet.sunet.se ([192.36.125.191] [192.36.125.191]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 11:30:43 Z Received: by holyail.pilsnet.sunet.se (Postfix, from userid 709) id 9FB7253E30; Tue, 8 Apr 2003 13:30:19 +0200 (CEST) Subject: Re: CONSENSUS CALL: Deprecating Site-Local Addressing From: Johan Nicklasson To: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> References: <5.1.0.14.2.20030401143711.04a0f848@mail.windriver.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qX6AG6wY4/C2s9ywctyA" Organization: Message-Id: <1049801419.1738.44.camel@holyail.pilsnet.sunet.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3- Date: 08 Apr 2003 13:30:19 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=-qX6AG6wY4/C2s9ywctyA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable YES -- Deprecate site-local unicast addressing //Johan --=20 Johan Nicklasson --=-qX6AG6wY4/C2s9ywctyA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+krLLe8HyjklXm+oRAvc3AKDlJstLaacuXRreyR58cYhV64AsiACfQ/8u tHYel5vG9Zln5Bi/JF9zItw= =lmJl -----END PGP SIGNATURE----- --=-qX6AG6wY4/C2s9ywctyA-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 8 04:44: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 h38Bi5mh019732; Tue, 8 Apr 2003 04:44:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38Bi5gO019731; Tue, 8 Apr 2003 04:44:05 -0700 (PDT) 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 h38Bi1mh019724 for ; Tue, 8 Apr 2003 04:44:01 -0700 (PDT) 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 h38Bi9vV022663 for ; Tue, 8 Apr 2003 04:44:09 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id FAA10122 for ; Tue, 8 Apr 2003 05:44:02 -0600 (MDT) 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, 8 Apr 2003 11:43: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; Tue, 8 Apr 2003 11:43: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; Tue, 8 Apr 2003 11:43:07 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; Tue, 8 Apr 2003 11:43:07 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.33]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA28034; Tue, 8 Apr 2003 04:42:18 -0700 (PDT) Message-Id: <5.1.0.14.2.20030408073028.04270e70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 08 Apr 2003 07:36:13 -0400 To: awhite@arc.corp.mot.com From: Margaret Wasserman Subject: Re: A different FEC0::/10 proposal Cc: IPng In-Reply-To: <3E927589.ABC089B1@motorola.com> References: <3E8D3F6D.3C780065@motorola.com> <3E8D8941.C0CF8359@hursley.ibm.com> <3E90E508.362F6EEC@motorola.com> <431280000.1049704844@localhost.besserwisser.org> <3E923D4B.395A8BD6@motorola.com> <751000000.1049782231@localhost.besserwisser.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Andrew, >At some point, the end host in a multi-homed scenario MUST make a decision >which address to choose. And that choice may be wrong, and if so the >application needs to have a recovery mechanism. Using a common top-level >prefix for private addresses provides a way to bias that choice. There are some choices other than modifying existing applications to know about address scope, such as: Returning only global addresses in the default APIs. Applications that know how to handle locally scoped address could ask for them explicitly. There are also alternatives to split DNS for getting local addresses from the DNS, such as: A special local DNS domain (such as .local) or a different DNS record to retrieve local addresses. I don't think that we should limit the possible solutions in IPv6 to the range of solutions available in IPv4 today. 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 Tue Apr 8 09:22:40 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 h38GMemh022068; Tue, 8 Apr 2003 09:22:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38GMeZX022067; Tue, 8 Apr 2003 09:22:40 -0700 (PDT) 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 h38GMbmh022060 for ; Tue, 8 Apr 2003 09:22:37 -0700 (PDT) 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 h38GMicU026185 for ; Tue, 8 Apr 2003 09:22:44 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA03147 for ; Tue, 8 Apr 2003 10:22:39 -0600 (MDT) 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, 8 Apr 2003 16:22:27 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, 8 Apr 2003 16:22:27 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, 8 Apr 2003 16:22:27 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 16:22:26 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h38GMPvm004172 for ; Tue, 8 Apr 2003 09:22:25 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h38GMPgx004171 for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 09:22:25 -0700 (PDT) Date: Tue, 8 Apr 2003 09:22:24 -0700 From: Shannon -jj Behrens To: ipng@sunroof.eng.sun.com Subject: site-locals: a way out Message-Id: <20030408162224.GA2317@alicia.nttmcl.com> 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 Here are some potential replacements for the advocated features of site-locals. Warning: this is a long email. /me dons his flame retardent suit and adds some stuff to his procmail filter ;) intermittently-connected networks: A BCP should be written that states that ISP's should not dynamically assign prefixes to intermittently-connected networks. Miyakawa-san has an Internet-draft that will make this a BCP for DSL networks. The suggested BCP could also contain a recommendation that intermittently-connected networks may continue to use (of course) the assigned prefix even when disconnected. disconnected networks: case 1: If the network administrator knows that the network may one day be connected, he should arrange with an ISP ahead of time to determine an appropriate prefix. Although inconvenient, this would prevent the hassle of a renumbering. case 2: Networks that will never be connected can use just about any prefix that they want--it's none of our business. The fact that these networks would need to renumber to join the global Internet may be considered by some a feature (I'm thinking specifically of completely disconnected networks in the government such as the ones that Michael Py has to work with. As for the weird networks that Keith Moore has to deal with, I'm sure he can interpolate a solution that has the same flavor as the above). Such networks may use the documentation prefix, if so desired. However, note that the documentation prefix is not scoped like site-locals are. This doesn't matter because this recommendation is for *non-connected* networks, so scoping is not needed. (By the way, do we have a BCP against using NAT's? If we do, we should reference it here. If we don't, we should write one.) case 3: Networks that suddenly need to connect to the Internet after years of non-connectivity should be renumbered [footnote 1]. After years of non-connectivity, renumbering should be one of the smallest problems that such networks must deal with, when contrasted with the amount of security hardening, etc. that such networks must undergo before being safely connected to the Internet. (I have a hard time believing that very large networks would ever find themselves in this state, and I consider renumbering a viable price for such an edge case. Those who are unhappy with this suggestion should perhaps work toward a solution for renumbering in general, as this is a problem that impacts a far greater number of networks!) security: Although site-locals aren't a security mechanism in and of themselves, they do provide a prefix that can be easily filtered by default. Hence, I have two suggestions for a replacement mechanism: suggestion 1: About a year ago, there was a thread on this mailing list about a certain unused combination of bits within EUI-64 generated IP's (I apologize for my vagueness. Hopefully the initiator of that thread will recognize what I am trying to reference). I suggest that hosts (including embedded devices) could set that combination of bits to provide a hint to the firewall that some special filtering should take place. By default, firewalls should disallow communication between such hosts and the rest of the Internet. suggestion 2: The suggested minimal allocation size from an ISP is a /48. Within that /48, we could have a well-known /64 set aside that would, by default, be a candidate for special filtering by firewalls. I.e., given 2001:418:200::/48, the well known /64 would be 2001:418:200:F117::/64. Although, this should be configurable by the firewall administrator, it would be an easy task for a firewall to block incoming connections to any address of the form ????:????:????:F117::/64 (although bitwise operators would be used, instead of text matching, of course). Neither of the above solutions permit nested or overlapping security domains. This is by intention. The above two solutions are simply replacements for the non-fine-grained security benefit of site-locals. For nested or overlapping security domains, I recommend manual firewall configuration, which can (of course) be arbitrarily complex [footnote 2]. provider-independent: How do we avoid the pain of renumbering internally due to external ISP changes? The following have been proposed in the past: provider-independent site-locals: The provider-independent nature of site-locals are the inspiration for the name of this section (and sub-section). However, if all usage of site-locals is to be deprecated, we must examine some of the other possibilities. Furthermore, this solution doesn't even solve the entire problem! For instance, some renumbering configuration will still be required if your site must be contacted by others on the Internet (e.g. VPN connections, B2B associations, etc.). true provider-independent addresses: This would be an ideal solution and would add great value to IPv6. However, it is a "difficult" problem in and of itself, so we should perhaps consider some of the other solutions first. multihoming: Multihoming is a proposed solution, but I don't think it fits the bill. Lazy administrators use NAT to solve this renumbering problem, and I don't think multihoming would induce them to remove NAT from their architectures. In fact, I think the two issues are somewhat orthogonal (Multihoming will not remove the reconfiguration necessary when one of the multiple ISP's change.). Furthermore , I think lazy administrators would use NAT in conjunction with multihoming. Of course, I may be wrong. NAT: NAT is the way this problem is handled in the IPv4 world. That's why I think we should use it in the IPv6 world--I'm just kidding! just do it: All of the above solutions might be overkill for the problem at hand. Provider-independent addresses and multihoming are difficult problems in and of themselves. Site-locals and NAT arguably create more problems than they solve. It seems to me that fixing the renumbering problem may be the easiest solution [footnote 1]. Having accomplished the above feats, we would be free of the need for site-locals, which is indeed my goal. Footnotes: 1) We really need to solve the renumbering problem. It is one of the few remaining "naked" spots of IPv6. Furthermore, as explained above, it could make solving several other problems unnecessary. It is my feeling that it is a tedious problem to solve, but not one that is technically insurmountable. In fact, I feel that all of the necessary tools to solve it are in place. First, it is necessary to establish the scope of the solution. Limiting the scope to simply swapping prefixes of equal length could yield substantial benefits ("The enemy of good is better."). Furthermore, renumbering hosts is easy with DHCP, so we need only worry about DNS servers and firewalls, etc. I will now expose myself to ridicule by reminding the gentle reader that I am a programmer, not a network administrator. I've never even had to renumber a large network, but please at least read all of what I have to say before flaming me! To start the renumbering event, a designated server sends a message describing the renumbering event. The message could be sent via some new multicast protocol or DHCP. The clients (e.g. DNS servers and firewalls) would be preconfigured with knowledge of the designated server, and they could verify the message via PGP. Alternatively, the message could be sent via IPSec or TSL (the certificates could be exchanged manually, since this must only be done once). Each client response would then be tuned to the type of client. A host with a DNS server could respond by launching a simple program to do a textual substitution on the DNS configuration file and then HUP the DNS server. Naturally, it would be optimal if BIND came with such a program. The router response would be to create new prefixes (remember that I have limited the problem to swapping prefixes of equal length) and deprecate the old prefixes. I think it is important that such a network-wide mechanism have an explicity undo mechanism, of course. All of the above is clearly very messy, but possible. We need to solve the renumbering problem, and I think now is the time. 2) Some have claimed that having multiple security domains will break certain P2P apps just as site-locals do. However, I agrue that it is the ambiguity of site-locals that makes them so problematic for such apps. Furthermore, I suggest that if node A needs to pass node B's address to node C, node A should pass *all* of node B's global addresses to node C. If the above technique does not succeed in permitting node C to connect to node B, then that is probably because the network administrator doesn't want nodes such as node C to connect to node B. Thank you all for your patience with this rather long email. 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 Tue Apr 8 09:31: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 h38GVvmh022342; Tue, 8 Apr 2003 09:31:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38GVvQb022341; Tue, 8 Apr 2003 09:31:57 -0700 (PDT) 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 h38GVrmh022331 for ; Tue, 8 Apr 2003 09:31:53 -0700 (PDT) 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 h38GW1vV000519 for ; Tue, 8 Apr 2003 09:32:01 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA20207 for ; Tue, 8 Apr 2003 09:31:55 -0700 (PDT) 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, 8 Apr 2003 16:31: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, 8 Apr 2003 16:31:54 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, 8 Apr 2003 16:31:54 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, 8 Apr 2003 16:31:54 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 JAA15254; Tue, 8 Apr 2003 09:31:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h38GVoY23270; Tue, 8 Apr 2003 09:31:50 -0700 X-mProtect: <200304081631> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVhu4nj; Tue, 08 Apr 2003 09:31:48 PDT Message-Id: <3E92F974.C0782F86@iprg.nokia.com> Date: Tue, 08 Apr 2003 09:31:48 -0700 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: greg.daley@eng.monash.edu.au CC: ipng@sunroof.eng.sun.com Subject: Re: Goals vs. process References: <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> <5.1.0.14.2.20030407055056.036f9188@mail.windriver.com> <3E91CCAD.AF49740F@iprg.nokia.com> <3E92199F.2070702@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Greg, Greg Daley wrote: > I think that you're right in that we need a solution now, > but I believe that if we can find a solution which has qualities > which support global routability, then this should be favoured. Suppose we had a solution that guaranteed uniqueness and provider independence, but didn't have any obvious features to support routability. How long should we wait before going forward with the solution achieving the smaller goal? > We don't know if people will even want these addresses routed, > and there's not much point putting the big effort in to fully > preparing for routability if no one wants this. Check. > On the other hand, we may be able to ensure that we create > a GUPI addressing scheme which meets GrouPI basic requirements: > (aggregation, uniqueness, permanence). I'm beginning to think this is impossible, as I will explain below. > This may discount schemes which rely upon random prefix > allocations though. Such schemes do not offer hopes for aggregation... > There is a good discussion about the concept of 'address ownership' > (PI) and 'address lending' (PA) in rfc 2008/BCP7. This points > out pitfalls to PI which may prevent routability in any case. Here's why PI may be the same as non-aggregable. Supposing we define the "provider" as the "lowest point in the hierarchy outside one's domain", which is (practically speaking) about the same thing as the "point of attachment" to "the Internet". A provider-independent address would then be an address which is independent of (i.e., not related to) its point of attachment to the Internet. Intuitively, one cannot remain aggregable to the address of every such potential point of attachment. This seems pretty clear to me, but if I am missing something please let me know! Notice, by the way, that private addresses in a NATted domain are both provider independent and (from the point of view of the rest of the Internet) non-aggregated :-). Based on these points, I think we should concentrate on defining a set of unique, provider-independent == non-aggregable addresses to fulfill the needs of those who had wanted to use site-local addresses. We would also specify that the default-free zone MUST NOT contain routes for such addresses. 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 Tue Apr 8 11:32: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 h38IWQmh023211; Tue, 8 Apr 2003 11:32:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38IWQ0K023210; Tue, 8 Apr 2003 11:32:26 -0700 (PDT) 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 h38IWNmh023203 for ; Tue, 8 Apr 2003 11:32:23 -0700 (PDT) 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 h38IWVcU010440 for ; Tue, 8 Apr 2003 11:32:31 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA01382 for ; Tue, 8 Apr 2003 11:32:25 -0700 (PDT) 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, 8 Apr 2003 18:32: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, 8 Apr 2003 18:32: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, 8 Apr 2003 18:32:06 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 18:32:05 Z Content-class: urn:content-classes:message Subject: Globally Unique Private Addresses and Scoped Architecture Date: Tue, 8 Apr 2003 11:32:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F754@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Globally Unique Private Addresses and Scoped Architecture Thread-Index: AcL97TZ7NAXkc5WPSnaZICvEBdKyuQABBMrw From: "Michel Py" To: "Charles E. Perkins" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h38IWNmh023204 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, > Charles E. Perkins wrote: > I think we should concentrate on defining a set of unique, > provider-independent == non-aggregable addresses to fulfill > the needs of those who had wanted to use site-local addresses. :-) > We would also specify that the default-free zone MUST NOT > contain routes for such addresses. Indeed, but this is not going to be enough. A "MUST NOT" policy alone can not enforce the public un-routability of private addresses. The only way to make sure that addresses are not routable on the public Internet is to suppress the demand for routing them. There currently is a strong and unfulfilled demand for globally routable PI. Example that works (WRT to being un-routable on the public Internet that is): RFC1918. Although we occasionally see these on the public Internet, it's due to misconfiguration. No customer is going to see their upstream and offer them money to leak or route RFC1918 addresses, because it achieves nothing (because RFC1918 addresses are ambiguous). No demand, no routing. Since what we are talking about here is to remove ambiguity, we must provide a replacement for what ambiguity provides in terms of enforcing the non-public-routability. Example that would not work without add-ons: Allocate a block of regular addresses (let's say, 2003::/16) to the purpose of globally-unique non-globally-routable addresses. This will create the demand from end-sites to go to their providers and indeed ask them to route them to be used as non-aggregatable PI, with the result of routing table bloat. What is required in order to get globally-unique, non-globally-routable addresses are three things: - Policy: the default-free zone MUST NOT contain routes for such addresses. - Default blackholing: some strong normative language mandating implementations (vs. policy) to blackhole by default routes traffic for the private prefix. - Some kind of architectural limitation such as site-local + scoped architecture. The combination of all three is required: - The policy alone is not enough because ISPs will take the customer's money at the risk of being labeled as bad boys. - The normative language alone is not enough as we have no way to force implementers to code it. - The architectural limitation alone is not enough as one will likely come up with a dirty hack to route SLs globally if need be. For example, globally routing site-locals will likely force the network administrators to hack the scope of site-locals to make it global, but again this alone would not be a big enough a deterrent compared to having global PI. A combination of any two would not be a powerful enough deterrent either. What we are dealing here is risk management. The risk is that the good intention of globally unique private addresses is transformed into the bad situation of global unaggregatable PI. Zero risk does not exist, and the only way of lowering the odds of this happening is to put so many hurdles on the way that it won't effectively happen. To this effect, the proposed deprecation of site-locals is a serious blow as it suppresses the architectural limitation and therefore creates demand for sites to pay their ISPs to "forget" to filter their prefixes and transform a non-routable globally unique prefix into a de-facto routable globally unique prefix. Why do site-locals provide that architectural limitation: because even if a network administrator changes the scope of his/her site-locals to global, it's not enough to make them work, as lots of destination sites would keep the default scope and dump the return traffic to a site-local address. In other words, with site-locals and scoped architecture, what is required to transform Globally Unique Site Locals into global PI is: { { 1) Almost NONE of the implementations compliant with the default blackholing requirement. = and = 2) Almost EVERY provider passively violating the "default- free zone MUST NOT contain routes for GUSL" policy. } = or = 3) Almost EVERY provider actively violating the "default-free zone MUST NOT contain routes for GUSL" policy by configuring their routers to ignore the default blackholing. } = and = { 4) Almost NONE of the implementations making scope checks resulting in almost ALL of them allow forwarding traffic to a site-local address outside of the site. = or = 5) Almost ALL network administrators hacking the scope of their site-local addresses to global. } As I said above there is no zero risk but the above conditions look pretty bad. Remove 4) and 5) and it instantly becomes a tempting target. Site-locals are not the only way, but {1,2,3} above are not sufficient deterrents meaning we have to provide a replacement for {4,5}. 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 Apr 8 11:54:18 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 h38IsImh023679; Tue, 8 Apr 2003 11:54:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38IsIds023678; Tue, 8 Apr 2003 11:54:18 -0700 (PDT) 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 h38IsEmh023671 for ; Tue, 8 Apr 2003 11:54:14 -0700 (PDT) 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 h38IsMvV019907 for ; Tue, 8 Apr 2003 11:54:22 -0700 (PDT) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA23943 for ; Tue, 8 Apr 2003 11:54:15 -0700 (PDT) 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, 8 Apr 2003 18:54: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; Tue, 8 Apr 2003 18:50: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, 8 Apr 2003 18:54:10 Z Received: from oak1a.cats.ohiou.edu ([132.235.8.44] [132.235.8.44]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 18:54:09 Z Received: from hkruse.csm.ohiou.edu (hkruse.csm.ohiou.edu [132.235.75.144]) (authenticated bits=0) by oak2a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id h38IXlPX1243953 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 8 Apr 2003 14:33:48 -0400 (EDT) Date: Tue, 08 Apr 2003 14:34:01 -0400 From: Hans Kruse To: ipng@sunroof.eng.sun.com Subject: Re: site-locals: a way out Message-Id: <1290417862.1049812441@hkruse.csm.ohiou.edu> In-Reply-To: <20030408162224.GA2317@alicia.nttmcl.com> References: <20030408162224.GA2317@alicia.nttmcl.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I really, really do not think that is a good idea. Everyone will be safer and retain their sanity if addresses used for this purpose have a prefix that is readily recognizable. I much prefer the concept of globally unique, PI, non-routable space (for which this discussion thread appears to have unearthed some potential solutions). --On Tuesday, April 08, 2003 09:22 -0700 Shannon -jj Behrens wrote: > case 2: > Networks that will never be connected can use just about any > prefix that they want--it's none of our business. The fact > that these networks would need to renumber to join the global Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 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 Apr 8 12:41: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 h38JfDmh024369; Tue, 8 Apr 2003 12:41:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38JfCRN024368; Tue, 8 Apr 2003 12:41:12 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h38Jf8mh024361 for ; Tue, 8 Apr 2003 12:41:09 -0700 (PDT) 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 h38JfAS03276; Tue, 8 Apr 2003 21:41:11 +0200 (MEST) Date: Tue, 8 Apr 2003 21:40:59 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: site-locals: a way out To: Shannon -jj Behrens Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20030408162224.GA2317@alicia.nttmcl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > security: > Although site-locals aren't a security mechanism in and of themselves, > they do provide a prefix that can be easily filtered by default. > Hence, I have two suggestions for a replacement mechanism: A different replacement mechanism is suggested in draft-bellovin-ipv6-accessprefix-01.txt and draft-zill-ipv6wg-zone-prefixlen-00.txt. I this mechanism the routers advertise the "local" prefixes. This allows the hosts to have a single knob "allow/disallow packets from non-local sources" with very similar effect to the hosts having a single-knob "allow/disallow configuration of non-site local addresses". If the knob is in the "disallow" state packets from outside the local domain (aka site) will be silently dropped by the host. 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 Apr 8 13:17:30 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 h38KHUmh024663; Tue, 8 Apr 2003 13:17:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38KHU0b024662; Tue, 8 Apr 2003 13:17:30 -0700 (PDT) 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 h38KHRmh024655 for ; Tue, 8 Apr 2003 13:17:27 -0700 (PDT) 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 h38KHYcU018355 for ; Tue, 8 Apr 2003 13:17:35 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA13290 for ; Tue, 8 Apr 2003 13:17:29 -0700 (PDT) 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, 8 Apr 2003 20:17:15 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP; Tue, 8 Apr 2003 20:17:14 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP; Tue, 8 Apr 2003 20:17:14 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay2.sun.com with ESMTP; Tue, 8 Apr 2003 20:17:14 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h38KHDvm008642; Tue, 8 Apr 2003 13:17:13 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h38KHDle008641; Tue, 8 Apr 2003 13:17:13 -0700 (PDT) Date: Tue, 8 Apr 2003 13:17:13 -0700 From: Shannon -jj Behrens To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: site-locals: a way out Message-Id: <20030408201713.GA8444@alicia.nttmcl.com> References: <20030408162224.GA2317@alicia.nttmcl.com> 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, Apr 08, 2003 at 09:40:59PM +0200, Erik Nordmark wrote: > > security: > > Although site-locals aren't a security mechanism in and of themselves, > > they do provide a prefix that can be easily filtered by default. > > Hence, I have two suggestions for a replacement mechanism: > > A different replacement mechanism is suggested in > draft-bellovin-ipv6-accessprefix-01.txt and > draft-zill-ipv6wg-zone-prefixlen-00.txt. > > I this mechanism the routers advertise the "local" prefixes. > This allows the hosts to have a single knob "allow/disallow packets > from non-local sources" with very similar effect to the hosts having a > single-knob "allow/disallow configuration of non-site local addresses". > If the knob is in the "disallow" state packets from outside the local domain > (aka site) will be silently dropped by the host. Yes, that does sound nicer than my idea. Tony Hain has argued strongly for idiot-proofing such a security mechanism (he has mentioned multiple times that site-locals provide a fallback for security even if you mess something else up); hence, it might be nice if the firewall automatically filtered based on these prefixes; although I can imagine that that could really surprise and frustrate some people. 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 Tue Apr 8 14:10: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 h38LAsmh025088; Tue, 8 Apr 2003 14:10:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38LAs7X025087; Tue, 8 Apr 2003 14:10:54 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h38LAnmh025080 for ; Tue, 8 Apr 2003 14:10:50 -0700 (PDT) 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 h38LAoS06821; Tue, 8 Apr 2003 23:10:51 +0200 (MEST) Date: Tue, 8 Apr 2003 23:10:35 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: site-locals: a way out To: Shannon -jj Behrens Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20030408201713.GA8444@alicia.nttmcl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes, that does sound nicer than my idea. Tony Hain has argued strongly for > idiot-proofing such a security mechanism (he has mentioned multiple times > that site-locals provide a fallback for security even if you mess something > else up); hence, it might be nice if the firewall automatically filtered > based on these prefixes; although I can imagine that that could really > surprise and frustrate some people. A firewall typically filters packets that arrive on the "outside" interface that has a source address that belongs to the "inside" to avoid certain spoofing attacks. The site-locals is one specific case of this, but the general concept if sufficient together with advertising the "local" prefixes to the hosts. The only difference I can see between this approach and using site-locals for it is the "defense in depth" point that Rich Draves raised. When using site-locals, assuming that the ISPs in the path have configured site boundaries and are hence filtering out packets with site-local source addresses, then there would be multiple filters to get past. The only issue is that I don't know how likely ISPs are to configure site boundaries if they are not going to use site-locals themselves. 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 Apr 8 15:08: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 h38M8Zmh025394; Tue, 8 Apr 2003 15:08:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38M8Zqr025393; Tue, 8 Apr 2003 15:08:35 -0700 (PDT) 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 h38M8Wmh025386 for ; Tue, 8 Apr 2003 15:08:32 -0700 (PDT) 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 h38M8evV016844 for ; Tue, 8 Apr 2003 15:08:40 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA13839 for ; Tue, 8 Apr 2003 15:08:34 -0700 (PDT) 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, 8 Apr 2003 22:08: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, 8 Apr 2003 22:08:34 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, 8 Apr 2003 22:08:34 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 22:08:33 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 400EC146BA; Wed, 9 Apr 2003 08:08:32 +1000 (EST) Date: Wed, 9 Apr 2003 08:08:32 +1000 From: "Nick 'Sharkey' Moore" To: Patrik F?ltstr?m Cc: ipng@sunroof.eng.sun.com Subject: Re: Yet another FEC0::/10 proposal Message-Id: <20030408220832.GD27763@zoic.org> Mail-Followup-To: Patrik F?ltstr?m , ipng@sunroof.eng.sun.com References: <2E186754-6987-11D7-88A6-000A959CF516@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2E186754-6987-11D7-88A6-000A959CF516@cisco.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Apr 08, 2003 at 07:58:54AM +0200, Patrik F?ltstr?m wrote: > > If we have three hosts, A, B and C, and A communicate with B, and B > with C. Then A know the peer address of B, and B know the one of C, > but, A doesn't know the one C has. Because of this, A doesn't know > within what scope C is, and because of this algorithms like the one > above doesn't work. An application can not make a choice based on > scoping. Um. So this is a protocol where B is passing C's address to A, so that A can talk directly to C? Sounds ... interesting ... but maybe this situation can also be fixed with scoping rules, if we require all addresses to be of the same scope. A -------- (B_A B_C) ------- C \__________________________/ (B_A is B's source address for talking with A. B_C is C's source address for talking with C. I figured I'd better separate them just in case. S(X) just means "the scope of X". Sorry for dragging my own notations into the light of day ...) Eg: with the scoping rules I proposed earlier, S(A) MUST= S(B_A) already, and S(B_C) MUST= S(C) already. So if your application ensures that S(B_A) = S(B_C), then S(A) = S(C), and there's no problem. BTW, did you have a specific application/protocol in mind? I'm guessing something p2pish with a central despatch server ... -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 8 16:00:53 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 h38N0qmh025764; Tue, 8 Apr 2003 16:00:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38N0qAM025763; Tue, 8 Apr 2003 16:00:52 -0700 (PDT) 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 h38N0nmh025756 for ; Tue, 8 Apr 2003 16:00:49 -0700 (PDT) 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 h38N0vvV001151 for ; Tue, 8 Apr 2003 16:00:57 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id RAA11109 for ; Tue, 8 Apr 2003 17:00:51 -0600 (MDT) 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, 8 Apr 2003 23:00: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, 8 Apr 2003 23:00:50 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, 8 Apr 2003 23:00:50 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 8 Apr 2003 23:00:50 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 8A372146C1; Wed, 9 Apr 2003 09:00:47 +1000 (EST) Date: Wed, 9 Apr 2003 09:00:47 +1000 From: "Nick 'Sharkey' Moore" To: "Charles E. Perkins" Cc: ipng@sunroof.eng.sun.com Subject: Re: Goals vs. process Message-Id: <20030408230047.GA587@zoic.org> Mail-Followup-To: "Charles E. Perkins" , ipng@sunroof.eng.sun.com References: <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> <5.1.0.14.2.20030407055056.036f9188@mail.windriver.com> <3E91CCAD.AF49740F@iprg.nokia.com> <3E92199F.2070702@eng.monash.edu.au> <3E92F974.C0782F86@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E92F974.C0782F86@iprg.nokia.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk G'day Charlie, On Tue, Apr 08, 2003 at 09:31:48AM -0700, Charles E. Perkins wrote: > > Here's why PI may be the same as non-aggregable. > > Supposing we define the "provider" as the "lowest point > in the hierarchy outside one's domain", which is (practically > speaking) about the same thing as the "point of attachment" > to "the Internet". A provider-independent address would then > be an address which is independent of (i.e., not related to) > its point of attachment to the Internet. :-) Good point. I guess the exception is geographical routing stuff, where routes to Melbourne and Sydney aggregate to a route to Australia if you're far enough away. > Based on these points, I think we should concentrate on > defining a set of unique, provider-independent == non-aggregable > addresses to fulfill the needs of those who had wanted > to use site-local addresses. We would also specify that > the default-free zone MUST NOT contain routes for such > addresses. I think that's fair enough, and gets us a quick, good, solution to the current problem of SLAs. I think the geographically aggregable addressing this is worth looking at further, but I don't think there's any need to hold up the SLA->GUPI move for it. After all, GUPI space may still be useful even with a geographically routable scope. -----N -- Nick 'Sharkey' Moore Research Fellow, CTIE Tel: +61 3 9905 3707 Monash University, Australia Fax: +61 3 9905 5358 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 8 16:59:42 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 h38Nxgmh026197; Tue, 8 Apr 2003 16:59:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h38Nxg80026196; Tue, 8 Apr 2003 16:59:42 -0700 (PDT) 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 h38Nxcmh026189 for ; Tue, 8 Apr 2003 16:59:38 -0700 (PDT) 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 h38NxkcU024602 for ; Tue, 8 Apr 2003 16:59:46 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA04803 for ; Tue, 8 Apr 2003 16:59:41 -0700 (PDT) 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, 8 Apr 2003 23:59: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; Tue, 8 Apr 2003 23:59: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; Tue, 8 Apr 2003 23:59:39 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; Tue, 8 Apr 2003 23:59:39 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 QAA06882; Tue, 8 Apr 2003 16:59:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h38Nxc605222; Tue, 8 Apr 2003 16:59:38 -0700 X-mProtect: <200304082359> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmi7knj; Tue, 08 Apr 2003 16:59:36 PDT Message-Id: <3E936292.3060007@iprg.nokia.com> Date: Tue, 08 Apr 2003 17:00:18 -0700 From: Charlie Perkins Organization: Nokia 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: "Nick 'Sharkey' Moore" CC: ipng@sunroof.eng.sun.com Subject: Re: Goals vs. process References: <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> <5.1.0.14.2.20030407055056.036f9188@mail.windriver.com> <3E91CCAD.AF49740F@iprg.nokia.com> <3E92199F.2070702@eng.monash.edu.au> <3E92F974.C0782F86@iprg.nokia.com> <20030408230047.GA587@zo Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk G'day Nick, Nick 'Sharkey' Moore wrote: >:-) Good point. I guess the exception is geographical routing >stuff, where routes to Melbourne and Sydney aggregate to a >route to Australia if you're far enough away. > It's an interesting point. I guess one could route according to any locators that have a usable map. For geographical, the map is pretty natural. For routing according to usual signaling pathways, locality in the map conveniently corresponds to ease of signaling, which makes protocols work well. Maybe geographical routing would work better if the routers were known to have some some sort of signal pathways across adjacent counties. It's also interesting to note that for geographically dependent but provider independent addressing, portability is lost. In other words, it doesn't matter who the provider is as long as you don't move and they live nearby somehow. 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 Tue Apr 8 17:13: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 h390Dvmh026612; Tue, 8 Apr 2003 17:13:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h390DvtN026611; Tue, 8 Apr 2003 17:13:57 -0700 (PDT) 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 h390Drmh026604 for ; Tue, 8 Apr 2003 17:13:53 -0700 (PDT) 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 h390E1vV020863 for ; Tue, 8 Apr 2003 17:14:01 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id SAA13003 for ; Tue, 8 Apr 2003 18:13:55 -0600 (MDT) 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, 9 Apr 2003 00:13: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; Wed, 9 Apr 2003 00:13: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; Wed, 9 Apr 2003 00:13:55 Z Received: from ALPHA1.ITS.MONASH.EDU.AU (ALPHA1.ITS.MONASH.EDU.AU [130.194.1.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 00:13:54 Z Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KUIQAE7KKY95VZH2@vaxc.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Wed, 09 Apr 2003 10:13:47 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 6E93812C007; Wed, 09 Apr 2003 10:13:46 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 4F7FB12C004; Wed, 09 Apr 2003 10:13:46 +1000 (EST) Date: Wed, 09 Apr 2003 10:13:46 +1000 From: Greg Daley Subject: Re: Goals vs. process To: "Charles E. Perkins" Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E9365BA.9010005@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: <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> <5.1.0.14.2.20030407055056.036f9188@mail.windriver.com> <3E91CCAD.AF49740F@iprg.nokia.com> <3E92199F.2070702@eng.monash.edu.au> <3E92F974.C0782F86@iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Charlie, I don't think I'm interested in waiting for ideas to drop from the sky either... A few comments inline. Charles E. Perkins wrote: > Hello Greg, > > Greg Daley wrote: > > >>I think that you're right in that we need a solution now, >>but I believe that if we can find a solution which has qualities >>which support global routability, then this should be favoured. > > > Suppose we had a solution that guaranteed uniqueness and > provider independence, but didn't have any obvious features > to support routability. How long should we wait before going > forward with the solution achieving the smaller goal? Not very long at all, I'm interested in working out if any solutions cater for these, which can be explored before the next meeting. Simultaneously I'd suggest looking at other collision avoidance systems (randmoness). This doesn't look like it's going to be too hard to do itself, though. > >>We don't know if people will even want these addresses routed, >>and there's not much point putting the big effort in to fully >>preparing for routability if no one wants this. > > > Check. > > >>On the other hand, we may be able to ensure that we create >>a GUPI addressing scheme which meets GrouPI basic requirements: >>(aggregation, uniqueness, permanence). > > > I'm beginning to think this is impossible, as I will explain below. > > >>This may discount schemes which rely upon random prefix >>allocations though. > > > Such schemes do not offer hopes for aggregation... > > >>There is a good discussion about the concept of 'address ownership' >>(PI) and 'address lending' (PA) in rfc 2008/BCP7. This points >>out pitfalls to PI which may prevent routability in any case. > > > Here's why PI may be the same as non-aggregable. > > Supposing we define the "provider" as the "lowest point > in the hierarchy outside one's domain", which is (practically > speaking) about the same thing as the "point of attachment" > to "the Internet". A provider-independent address would then > be an address which is independent of (i.e., not related to) > its point of attachment to the Internet. > > Intuitively, one cannot remain aggregable to the address > of every such potential point of attachment. This seems > pretty clear to me, but if I am missing something please > let me know! You're right about this, when we look at moving between providers as moving between branches of a hierarchy. I've been thinking about existing routing schemes outside the Internet. Traditionally, we can contrast the telephony and postal systems. Addressing in telephony systems is partially tied to geography, with a part of the address prefix bound to a regional allocation (in the same way that RIRs do). Subsequent routable blocks are handled by Service Providers, and addresses are tied to these blocks (the way PA addresses are in IPv6). In some locations, movement of a customer between service providers allows an requests for an address at the routable block owner, to be forwarded to the new SP. (we probably want to avoid these sort of overlays though). In the postal system, there's a hierarchical address system which delivers mail to country and region, before the distribution to town/street kicks in. In some places, it may be simple to allocate a service provider to look after a 'internet postal addresses' for a region or town, in the same way that incumbent carriers handle fixed telephony lines in various locations. While this may not be simple in such a dynamic marketplace as in USA, there may be ways that SP's could exchange routes within regions. This could order to cover the situation where a SP receives 'postally addressed' packets, which are actually serviced by a peer service provider in the same region. At this stage I'm not sure how messy this would get, but peering relationships would have to be established between all players in a region (may be dependent on the eventual addressing scheme). Most changes of service provider will not involve location change. Therefore, changes between one service provider and another need not modify the route tables outside the local postal area. > Notice, by the way, that private addresses in a NATted domain > are both provider independent and (from the point of view > of the rest of the Internet) non-aggregated :-). If only they were useful :) > Based on these points, I think we should concentrate on > defining a set of unique, provider-independent == non-aggregable > addresses to fulfill the needs of those who had wanted > to use site-local addresses. We would also specify that > the default-free zone MUST NOT contain routes for such > addresses. Indeed. If there's no likely candidate for global routability by the next IETF, I'll be voting for that. 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 Tue Apr 8 17:32: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 h390Wvmh027028; Tue, 8 Apr 2003 17:32:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h390WvHT027027; Tue, 8 Apr 2003 17:32:57 -0700 (PDT) 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 h390Wrmh027020 for ; Tue, 8 Apr 2003 17:32:53 -0700 (PDT) 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 h390X1cU005936 for ; Tue, 8 Apr 2003 17:33:01 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id SAA21283 for ; Tue, 8 Apr 2003 18:32:52 -0600 (MDT) 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, 9 Apr 2003 00:32:52 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, 9 Apr 2003 00:32: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; Wed, 9 Apr 2003 00:32:51 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 00:32:51 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 08 Apr 2003 17:32:49 -0700 Reply-To: From: "Tony Hain" To: Subject: Sites will pick random numbers Date: Tue, 8 Apr 2003 17:32:43 -0700 Message-Id: <0e6101c2fe2f$88e98ac0$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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In case anyone disbelieves the point that sites will pick random numbers when they can't get them permanently allocated. From today's mail: > AS xxxx currently leaks 80.0.0.0/8 and 2.0.0.0/8 (IANA unassigned). ^^^^ AS # masked -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 8 17:45: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 h390jPmh027294; Tue, 8 Apr 2003 17:45:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h390jP82027293; Tue, 8 Apr 2003 17:45:25 -0700 (PDT) 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 h390jLmh027286 for ; Tue, 8 Apr 2003 17:45:21 -0700 (PDT) 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 h390jTvV029959 for ; Tue, 8 Apr 2003 17:45:29 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id SAA17268 for ; Tue, 8 Apr 2003 18:45:23 -0600 (MDT) 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, 9 Apr 2003 00:45:22 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, 9 Apr 2003 00:45: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; Wed, 9 Apr 2003 00:45:22 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; Wed, 9 Apr 2003 00:45:21 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 <01KUIR8ZUFSA9AVGCO@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 10:41:40 +1000 Received: from kapow.its.monash.edu.au (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 30D172000B; Wed, 09 Apr 2003 10:41:40 +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 AD57020007; Wed, 09 Apr 2003 10:41:39 +1000 (EST) Date: Wed, 09 Apr 2003 10:41:39 +1000 From: Greg Daley Subject: Re: Goals vs. process To: Charlie Perkins Cc: "Nick 'Sharkey' Moore" , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E936C43.9080401@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: <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> <5.1.0.14.2.20030407055056.036f9188@mail.windriver.com> <3E91CCAD.AF49740F@iprg.nokia.com> <3E92199F.2070702@eng.monash.edu.au> <3E92F974.C0782F86@iprg.nokia.com> <3E936292.3060007@iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Charlie, Charlie Perkins wrote: > G'day Nick, > > Nick 'Sharkey' Moore wrote: > >> :-) Good point. I guess the exception is geographical routing >> stuff, where routes to Melbourne and Sydney aggregate to a >> route to Australia if you're far enough away. >> > It's an interesting point. I guess one could route according to > any locators that have a usable map. For geographical, > the map is pretty natural. For routing according to usual signaling > pathways, locality in the map conveniently corresponds to > ease of signaling, which makes protocols work well. Maybe > geographical routing would work better if the routers were known > to have some some sort of signal pathways across adjacent counties. Counties or countries? for small distances, moving the 50-100km between one region and another may not be a big issue. Advertised routes may be able to take care of this for you. This may make sense if the minimum distance to a destination for one of N paths takes you a certain number of zones/hops/km. The metrics could be related to the topology (rather than existing routing topologies). I'm not sure that it would be as cheap to route this way though. > It's also interesting to note that for geographically dependent > but provider independent addressing, portability is lost. > In other words, it doesn't matter who the provider is as long > as you don't move and they live nearby somehow. This may be an issue in Silicon Valley, especially in those 'startup-suites' which pop up ;) If people are looking for large blocks of land from which to get an big permanent aggregatable prefix, I'm sure that we could sell them some land in outback Australia (Just mind the RTT, sand and snakes though). 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 Tue Apr 8 21:23:06 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 h394N6mh028539; Tue, 8 Apr 2003 21:23:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h394N68g028538; Tue, 8 Apr 2003 21:23:06 -0700 (PDT) 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 h394N2mh028531 for ; Tue, 8 Apr 2003 21:23:02 -0700 (PDT) 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 h394NAvV010615 for ; Tue, 8 Apr 2003 21:23:10 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id VAA21830 for ; Tue, 8 Apr 2003 21:23:05 -0700 (PDT) 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, 9 Apr 2003 04:23:04 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, 9 Apr 2003 04:23:04 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, 9 Apr 2003 04:23:04 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 04:23:03 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id AAC4D146C1; Wed, 9 Apr 2003 14:22:41 +1000 (EST) Date: Wed, 9 Apr 2003 14:22:41 +1000 From: "Nick 'Sharkey' Moore" To: Charlie Perkins Cc: ipng@sunroof.eng.sun.com Subject: Re: Goals vs. process Message-Id: <20030409042241.GB791@zoic.org> Mail-Followup-To: Charlie Perkins , ipng@sunroof.eng.sun.com References: <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> <5.1.0.14.2.20030407055056.036f9188@mail.windriver.com> <3E91CCAD.AF49740F@iprg.nokia.com> <3E92199F.2070702@eng.monash.edu.au> <3E92F974.C0782F86@iprg.nokia.com> <3E936292.3060007@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E936292.3060007@iprg.nokia.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Apr 08, 2003 at 05:00:18PM -0700, Charlie Perkins wrote: > > It's an interesting point. I guess one could route according to > any locators that have a usable map. For geographical, > the map is pretty natural. For routing according to usual signaling > pathways, locality in the map conveniently corresponds to > ease of signaling, which makes protocols work well. Maybe > geographical routing would work better if the routers were known > to have some some sort of signal pathways across adjacent counties. Yeah, it doesn't work perfectly unless the network is "meshy". On the other hand, it'd be interesting to see how aggregable those routes would be if the (lat,long)->prefix map was done well. > It's also interesting to note that for geographically dependent > but provider independent addressing, portability is lost. Yeah, "provider independent" vs. "locational independent", to look at it another way. But that'll get us involved in the identity vs locality debate again :-) -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 8 21:31: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 h394VQmh028731; Tue, 8 Apr 2003 21:31:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h394VQ5E028730; Tue, 8 Apr 2003 21:31:26 -0700 (PDT) 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 h394VNmh028723 for ; Tue, 8 Apr 2003 21:31:23 -0700 (PDT) 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 h394VVvV012034 for ; Tue, 8 Apr 2003 21:31:31 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id VAA24556 for ; Tue, 8 Apr 2003 21:31:25 -0700 (PDT) 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, 9 Apr 2003 04:31: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; Wed, 9 Apr 2003 04:31: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, 9 Apr 2003 04:31:22 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 04:31:22 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h394VDJ24855; Wed, 9 Apr 2003 07:31:14 +0300 Date: Wed, 9 Apr 2003 07:31:13 +0300 (EEST) From: Pekka Savola To: Tony Hain cc: ipng@sunroof.eng.sun.com Subject: Re: Sites will pick random numbers In-Reply-To: <0e6101c2fe2f$88e98ac0$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 Tue, 8 Apr 2003, Tony Hain wrote: > In case anyone disbelieves the point that sites will pick random numbers > when they can't get them permanently allocated. From today's mail: > > > AS xxxx currently leaks 80.0.0.0/8 and 2.0.0.0/8 (IANA unassigned). > ^^^^ AS # masked Doesn't this kinda prove the point that site locals aren't needed? :-) -- 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 Apr 8 23:21:35 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 h396LZmh029763; Tue, 8 Apr 2003 23:21:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h396LYpo029762; Tue, 8 Apr 2003 23:21:34 -0700 (PDT) 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 h396LVmh029755 for ; Tue, 8 Apr 2003 23:21:31 -0700 (PDT) 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 h396LdcU012983 for ; Tue, 8 Apr 2003 23:21:39 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id AAA28833 for ; Wed, 9 Apr 2003 00:21:33 -0600 (MDT) 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, 9 Apr 2003 06:21: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; Wed, 9 Apr 2003 06:21: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; Wed, 9 Apr 2003 06:21:33 Z Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 06:21:32 Z Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h396JhIY020067; Wed, 9 Apr 2003 08:19:43 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 9 Apr 2003 08:21:30 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 9 Apr 2003 08:21:30 +0200 Date: Wed, 9 Apr 2003 08:21:25 +0200 Subject: Re: Yet another FEC0::/10 proposal Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipng@sunroof.eng.sun.com To: "Nick 'Sharkey' Moore" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20030408220832.GD27763@zoic.org> Message-Id: <7DCB2018-6A53-11D7-88A6-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 09 Apr 2003 06:21:30.0159 (UTC) FILETIME=[423FD3F0:01C2FE60] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On onsdag, apr 9, 2003, at 00:08 Europe/Stockholm, Nick 'Sharkey' Moore wrote: > On Tue, Apr 08, 2003 at 07:58:54AM +0200, Patrik F?ltstr?m wrote: >> >> If we have three hosts, A, B and C, and A communicate with B, and B >> with C. Then A know the peer address of B, and B know the one of C, >> but, A doesn't know the one C has. Because of this, A doesn't know >> within what scope C is, and because of this algorithms like the one >> above doesn't work. An application can not make a choice based on >> scoping. > > Um. So this is a protocol where B is passing C's address to A, so > that A can talk directly to C? Yes. > Sounds ... interesting ... but > maybe this situation can also be fixed with scoping rules, if we > require all addresses to be of the same scope. > > A -------- (B_A B_C) ------- C > \__________________________/ > > (B_A is B's source address for talking with A. B_C is C's source > address for talking with C. I figured I'd better separate them > just in case. S(X) just means "the scope of X". Sorry for dragging > my own notations into the light of day ...) > > Eg: with the scoping rules I proposed earlier, S(A) MUST= S(B_A) > already, > and S(B_C) MUST= S(C) already. So if your application ensures that > S(B_A) = S(B_C), then S(A) = S(C), and there's no problem. Yes, B might detect that the scope is different, but what should B do? B doesn't know what some other address of A (in a different scope) is. B can only say "No", which might be hard if A and B already have a communication going, and then want to add C. > BTW, did you have a specific application/protocol in mind? I'm > guessing something p2pish with a central despatch server ... FTP and SIP. Especially SIP (ftp is not used in that mode much the last 20 years...). paf -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 8 23:31:18 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 h396VImh000170; Tue, 8 Apr 2003 23:31:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h396VIEG000169; Tue, 8 Apr 2003 23:31:18 -0700 (PDT) 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 h396VDmh000159 for ; Tue, 8 Apr 2003 23:31:13 -0700 (PDT) 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 h396VKvV000971 for ; Tue, 8 Apr 2003 23:31:20 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id AAA16242 for ; Wed, 9 Apr 2003 00:31:14 -0600 (MDT) 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, 9 Apr 2003 06:31:09 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, 9 Apr 2003 06:31:09 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, 9 Apr 2003 06:31:09 Z Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 06:31:09 Z Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h396UAWI006309 for ; Tue, 8 Apr 2003 23:30:10 -0700 (MST) Received: from motorola.com (mvp-10-238-2-9.corp.mot.com [10.238.2.9]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h396V43m020550 for ; Wed, 9 Apr 2003 01:31:06 -0500 Message-Id: <3E93BE27.FEEB4CDE@motorola.com> Date: Wed, 09 Apr 2003 16:31:03 +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: Re: A different FEC0::/10 proposal References: <3E8D3F6D.3C780065@motorola.com> <3E8D8941.C0CF8359@hursley.ibm.com> <3E90E508.362F6EEC@motorola.com> <431280000.1049704844@localhost.besserwisser.org> <3E923D4B.395A8BD6@motorola.com> <751000000.1049782231@localhost.besserwisser.org> <5.1.0.14.2.20030408073028.04270e70@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Resend to list (sorry Margaret): Margaret Wasserman wrote: > > There are some choices other than modifying existing applications to know > about address scope, such as: > > Returning only global addresses in the default APIs. Applications that > know how to handle locally scoped address could ask for them explicitly. I think this misses my point. There are 2 types of addresses: - addresses that are explicitly filtered. - addresses that are silently filtered. In the current v4 architecture, RFC1918 addresses are explicitly filtered. The documentation says that they are not global. Other v4 addresses are not in fact global. They might be blocked by filters on the local site or by filters on remote sites. They will be blocked if they hit the outside of a NAT (evil things that they are). The same logic applies for v6, except we hope for fewer NATs. Because of these considerations, any application that comes into contact with a multi-address end node (src or dst) needs to be aware of the functional effects of filtering - some source-destination pairs may work while others may fail. This is without reference to site local addresses. How do SLs fit? In almost every private address deployment scenario I've seen, if an SL address (in the correct functional scope) it is at least as reliable as a global address (except for site merges with bad SL prefixes, but I think we're all agreed that we need to define mechanisms to ensure good NRPI/SL prefixes). Therefore, the application doesn't suffer from using them unless it intends to do address forwarding. Longest-Prefix-Match source selection will ensure SL destinations get SL sources, and global destinations get global sources. If you don't have a global source, you probably aren't supposed to be able to make an external connection. In the address forwarding case, SLs make a big difference. If the site uses SLs for it's internal network, then applications have a very easy way of knowing which prefixes are 'most likely' to be filtered, and which are not. If a site instead filters some 'global' prefixes, it's trial and error. Ultimately, it's trial and error anyway, but at least this way you get hints which trials are most likely to succeed. Does anyone have a compelling argument why applications that do not forward addresses outside the site (and apps which do ought to know who they are, or at least the person that configures them should) would find it a bad idea to use non-routeable priavte addresses for in-site communication? Would it be a good thing to redefine FEC0::/10 'site-locals' as a non-routeable private addresses? This seems to be how most people who want them intend to use them. Note that I am explicitly not suggesting they must be registered, but instead make use of the various auto-allocation drafts to ensure acceptable uniqueness. > There are also alternatives to split DNS for getting local addresses > from the DNS, such as: > > A special local DNS domain (such as .local) or a different DNS record > to retrieve local addresses. That's certainly an option, and one we have implemented. -- 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 Wed Apr 9 04:55:59 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 h39Btxmh001267; Wed, 9 Apr 2003 04:55:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39BtxGj001266; Wed, 9 Apr 2003 04:55:59 -0700 (PDT) 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 h39Bttmh001259 for ; Wed, 9 Apr 2003 04:55:55 -0700 (PDT) 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 h39Bu3vV015042 for ; Wed, 9 Apr 2003 04:56:03 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id FAA20851 for ; Wed, 9 Apr 2003 05:55:57 -0600 (MDT) 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, 9 Apr 2003 11:55: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; Wed, 9 Apr 2003 11:55: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, 9 Apr 2003 11:55:55 Z Received: from eikenes.alvestrand.no ([217.13.28.204] [217.13.28.204]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 11:55:54 Z Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id E5A25621FA; Wed, 9 Apr 2003 13:55:53 +0200 (CEST) Date: Wed, 09 Apr 2003 13:55:53 +0200 From: Harald Tveit Alvestrand To: Michel Py , "Charles E. Perkins" Cc: ipng@sunroof.eng.sun.com Subject: Re: Globally Unique Private Addresses and Scoped Architecture Message-Id: <814670000.1049889353@askvoll.hjemme.alvestrand.no> In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F754@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F504F754@server2000.arneill-py.sa cramento.ca.us> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --On tirsdag, april 08, 2003 11:32:05 -0700 Michel Py wrote: > Example that works (WRT to being un-routable on the public Internet that > is): RFC1918. Although we occasionally see these on the public Internet, > it's due to misconfiguration. No customer is going to see their upstream > and offer them money to leak or route RFC1918 addresses, because it > achieves nothing (because RFC1918 addresses are ambiguous). No demand, > no routing. Since what we are talking about here is to remove ambiguity, > we must provide a replacement for what ambiguity provides in terms of > enforcing the non-public-routability. when IPv4 customers come to their ISP and offer them money in order to route RFC 1918 addresses to places the customer is not directly connected to, we usually call the result a provider provisioned VPN. Demand seems widespread. So if we roll out globally unique non-routable addresses, we should not be at all surprised to see that ISPs will actually route them if offered enough money; it's simpler (and therefore cheaper) for them than configuring a VPN. (of course this only works in v4 if the two ends have coordinated their RFC 1918 deplyment plans. There are a lot of cases when they do.) Harald -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 9 07:35: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 h39EZXmh001976; Wed, 9 Apr 2003 07:35:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39EZXfe001975; Wed, 9 Apr 2003 07:35:33 -0700 (PDT) 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 h39EZTmh001968 for ; Wed, 9 Apr 2003 07:35:29 -0700 (PDT) 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 h39EZbvV010398 for ; Wed, 9 Apr 2003 07:35:37 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id IAA27569 for ; Wed, 9 Apr 2003 08:35:31 -0600 (MDT) 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, 9 Apr 2003 14:35: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, 9 Apr 2003 14:35: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; Wed, 9 Apr 2003 14:35:30 Z Received: from d06lmsgate.uk.ibm.com (d06lmsgate.uk.ibm.com [195.212.29.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 14:35:29 Z Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.uk.ibm.com [9.166.84.148]) by d06lmsgate.uk.ibm.com (8.12.9/8.12.8) with ESMTP id h39EZQPs122932 for ; Wed, 9 Apr 2003 15:35:27 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d06relay02.portsmouth.uk.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h39EZNv0142498 for ; Wed, 9 Apr 2003 15:35:24 +0100 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA22724 from ; Wed, 9 Apr 2003 16:35:14 +0200 Message-Id: <3E942FCE.F1298511@hursley.ibm.com> Date: Wed, 09 Apr 2003 16:35:58 +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: Goals vs. process References: <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> <5.1.0.14.2.20030407055056.036f9188@mail.windriver.com> <3E91CCAD.AF49740F@iprg.nokia.com> <3E92199F.2070702@eng.monash.edu.au> <3E92F974.C0782F86@iprg.nokia.com> <20030408230047.GA587@zoic.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nick 'Sharkey' Moore wrote: > > G'day Charlie, > > On Tue, Apr 08, 2003 at 09:31:48AM -0700, Charles E. Perkins wrote: > > > > Here's why PI may be the same as non-aggregable. > > > > Supposing we define the "provider" as the "lowest point > > in the hierarchy outside one's domain", which is (practically > > speaking) about the same thing as the "point of attachment" > > to "the Internet". A provider-independent address would then > > be an address which is independent of (i.e., not related to) > > its point of attachment to the Internet. > > :-) Good point. I guess the exception is geographical routing > stuff, where routes to Melbourne and Sydney aggregate to a > route to Australia if you're far enough away. If the relevant ISPs in Oz don't share the same trans-Pacific route, they don't aggregate at all. 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 Apr 9 07:42:10 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 h39Eg9mh002276; Wed, 9 Apr 2003 07:42:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39Eg9Hm002275; Wed, 9 Apr 2003 07:42:09 -0700 (PDT) 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 h39Eg6mh002268 for ; Wed, 9 Apr 2003 07:42:06 -0700 (PDT) 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 h39EgEcU004771 for ; Wed, 9 Apr 2003 07:42:14 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id IAA02347 for ; Wed, 9 Apr 2003 08:42:08 -0600 (MDT) 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, 9 Apr 2003 14:42:04 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, 9 Apr 2003 14:42:04 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, 9 Apr 2003 14:42:04 Z Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 14:42:03 Z Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.uk.ibm.com [9.166.84.147]) by d06lmsgate-3.uk.ibm.com (8.12.9/8.12.8) with ESMTP id h39EfURc142764; Wed, 9 Apr 2003 15:41:31 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d06relay01.portsmouth.uk.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h39EfTlk247384; Wed, 9 Apr 2003 15:41:30 +0100 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58310 from ; Wed, 9 Apr 2003 16:41:27 +0200 Message-Id: <3E943144.62389568@hursley.ibm.com> Date: Wed, 09 Apr 2003 16:42:12 +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: Is /32 enough? (was Re: Patrick Faltstrom...) References: <200304052043.PAA16343@ss10.danlan.com> <417230000.1049703524@localhost.besserwisser.org> <20030407093146.GS23732@login.ecs.soton.ac.uk> <758240000.1049782597@localhost.besserwisser.org> <20030408064836.GB19150@login.ecs.soton.ac.uk> <885020000.1049794189@localhost.besserwisser.org> <20030408101852.GC26495@login.ecs.soton.ac.uk> <20030408104946.GA27074@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 Tue, Apr 08, 2003 at 11:18:52AM +0100, Tim Chown wrote: > > > > So there are 8 /32's available per allocation, kind of. In other words > > an ISP can grow to a /28, which is 2^20 /48's, which is 1M /48's, but > > (Actually I think that's a /29, or 500K prefixes max...) > Regardless, I wouldn't be shocked by a DFZ where a given ISP had multiple /29s if it grew really big. I do agree that ISPs need to have a sense that they can get as many of the 35 trillion /48s as they need. 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 Apr 9 07:47: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 h39Elvmh002584; Wed, 9 Apr 2003 07:47:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39EluoQ002583; Wed, 9 Apr 2003 07:47:56 -0700 (PDT) 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 h39Elrmh002573 for ; Wed, 9 Apr 2003 07:47:53 -0700 (PDT) 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 h39Em1cU006181 for ; Wed, 9 Apr 2003 07:48:01 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA21005 for ; Wed, 9 Apr 2003 08:47:55 -0600 (MDT) 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, 9 Apr 2003 14:47: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; Wed, 9 Apr 2003 14:47: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; Wed, 9 Apr 2003 14:47:55 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, 9 Apr 2003 14:47:54 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h39EkBCi029844 for ; Wed, 9 Apr 2003 16:47:48 +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 h39EjOvl197806 for ; Wed, 9 Apr 2003 16:46:06 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42154 from ; Wed, 9 Apr 2003 16:45:21 +0200 Message-Id: <3E94322E.FE581EB3@hursley.ibm.com> Date: Wed, 09 Apr 2003 16:46:06 +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: Sites will pick random numbers 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, 8 Apr 2003, Tony Hain wrote: > > In case anyone disbelieves the point that sites will pick random numbers > > when they can't get them permanently allocated. From today's mail: > > > > > AS xxxx currently leaks 80.0.0.0/8 and 2.0.0.0/8 (IANA unassigned). > > ^^^^ AS # masked > > Doesn't this kinda prove the point that site locals aren't needed? :-) Well, so does the fact that several specifics within 2002::/16 are in the IPv6 DFZ. Neither of these are exactly good things. 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 Apr 9 08:01: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 h39F1bmh003216; Wed, 9 Apr 2003 08:01:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39F1aAW003215; Wed, 9 Apr 2003 08:01:36 -0700 (PDT) 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 h39F1Xmh003208 for ; Wed, 9 Apr 2003 08:01:33 -0700 (PDT) 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 h39F1fvV016592 for ; Wed, 9 Apr 2003 08:01:41 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA08692 for ; Wed, 9 Apr 2003 09:01:32 -0600 (MDT) 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, 9 Apr 2003 15:01: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; Wed, 9 Apr 2003 15:01:25 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, 9 Apr 2003 15:01:25 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 15:01:25 Z Content-class: urn:content-classes:message Subject: RE: Globally Unique Private Addresses and Scoped Architecture Date: Wed, 9 Apr 2003 08:01:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F756@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Globally Unique Private Addresses and Scoped Architecture Thread-Index: AcL+jvxMzc8lF3qDSVOeWyD8u0NG2wAGPm0g From: "Michel Py" To: "Harald Tveit Alvestrand" , "Charles E. Perkins" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h39F1Xmh003209 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Harald, >> Michel Py wrote: >> Example that works (WRT to being un-routable on the public >> Internet that is): RFC1918. Although we occasionally see >> these on the public Internet, it's due to misconfiguration. >> No customer is going to see their upstream and offer them >> money to leak or route RFC1918 addresses, because it >> achieves nothing (because RFC1918 addresses are ambiguous). >> No demand, no routing. Since what we are talking about here >> is to remove ambiguity, we must provide a replacement for >> what ambiguity provides in terms of enforcing the non >> -public-routability. > Harald Tveit Alvestrand wrote: > when IPv4 customers come to their ISP and offer them money > in order to route RFC 1918 addresses to places the customer > is not directly connected to, we usually call the result a > provider provisioned VPN. > Demand seems widespread. > So if we roll out globally unique non-routable addresses, > we should not be at all surprised to see that ISPs will > actually route them if offered enough money; it's simpler > (and therefore cheaper) for them than configuring a VPN. Agree. What would be a surprise is if they would not try. > (of course this only works in v4 if the two ends have > coordinated their RFC 1918 deplyment plans. There are > a lot of cases when they do.) Which is why we need to reduce the odds of what you described two paragraphs ago happening in v6 as much as we possibly can. 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 Apr 9 08:54: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 h39Fsemh003529; Wed, 9 Apr 2003 08:54:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39Fse2i003528; Wed, 9 Apr 2003 08:54:40 -0700 (PDT) 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 h39Fsamh003521 for ; Wed, 9 Apr 2003 08:54:37 -0700 (PDT) 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 h39FsicU022323 for ; Wed, 9 Apr 2003 08:54:45 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA01323 for ; Wed, 9 Apr 2003 09:54:39 -0600 (MDT) 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, 9 Apr 2003 15:54:31 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, 9 Apr 2003 15:54: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; Wed, 9 Apr 2003 15:54:31 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, 9 Apr 2003 15:54: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 IAA11398; Wed, 9 Apr 2003 08:54:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h39FsSB19261; Wed, 9 Apr 2003 08:54:28 -0700 X-mProtect: <200304091554> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrEARkS; Wed, 09 Apr 2003 08:54:26 PDT Message-Id: <3E944232.32A1DCE7@iprg.nokia.com> Date: Wed, 09 Apr 2003 08:54:26 -0700 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: Michel Py CC: Harald Tveit Alvestrand , ipng@sunroof.eng.sun.com Subject: Re: Globally Unique Private Addresses and Scoped Architecture References: <963621801C6D3E4A9CF454A1972AE8F504F756@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: > > So if we roll out globally unique non-routable addresses, > > we should not be at all surprised to see that ISPs will > > actually route them if offered enough money; it's simpler > > (and therefore cheaper) for them than configuring a VPN. > > Agree. What would be a surprise is if they would not try. O.K. The agreement seems to be that some providers would try to route provider-independent addresses, if offered enough money. Is that correct? >> (of course this only works in v4 if the two ends have >> coordinated their RFC 1918 deplyment plans. There are >> a lot of cases when they do.) > > Which is why we need to reduce the odds of what you described two > paragraphs ago happening in v6 as much as we possibly can. Do you mean, that we should discourage providers from routing provider-independent addresses? Do you still believe this if such addresses are forbidden from inclusion in the default-free zone? It seems to me that we "should" be able to enforce this directly, if it's specified as an important part of IPv6 scalability. Mistakes might happen, but they could be corrected within hours, and typically that amount of deviation from "goodness" wouldn't upset the overall scalability of the aggregated route advertisements. It just has to be that most of the DFZ community does effectively exclude and nullify advertisement of provider- independent (i.e., non-aggregable) addresses. 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 Apr 9 14:19:46 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 h39LJkmh005106; Wed, 9 Apr 2003 14:19:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39LJjQx005105; Wed, 9 Apr 2003 14:19:45 -0700 (PDT) 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 h39LJgmh005098 for ; Wed, 9 Apr 2003 14:19:42 -0700 (PDT) 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 h39LJovV008330 for ; Wed, 9 Apr 2003 14:19:50 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id PAA04053 for ; Wed, 9 Apr 2003 15:19:44 -0600 (MDT) 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, 9 Apr 2003 21:19: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; Wed, 9 Apr 2003 21:16: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; Wed, 9 Apr 2003 21:19:43 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 21:19:43 Z Content-class: urn:content-classes:message Subject: RE: Globally Unique Private Addresses and Scoped Architecture Date: Wed, 9 Apr 2003 14:19:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F757@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Globally Unique Private Addresses and Scoped Architecture Thread-Index: AcL+sFHFfh08fJcgRy2HDijUfT18sQAJgJsQ From: "Michel Py" To: "Charles E. Perkins" Cc: "Harald Tveit Alvestrand" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h39LJgmh005099 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, > Charles E. Perkins wrote: > O.K. The agreement seems to be that some providers > would try to route provider-independent addresses, > if offered enough money. Is that correct? Yes. > Do you mean, that we should discourage providers > from routing provider-independent addresses? Yes, see below for details. More than discourage is needed. > Do you still believe this if such addresses are > forbidden from inclusion in the default-free zone? Yes, see below too. There is demand for two kinds of globally unique addresses: globally-unique-private and "scalable PI". Unfortunately "scalable PI" is an oxymoron, which is why we need to reduce the risk of globally-unique-private becoming globally-unique-not-private with means PI and routing table bloat. The demand for PI is strong (yesterday at the ARIN meeting micro-allocations were discussed); solutions are being developed that would provide what could look like scalable PI and smell like scalable PI but these are not there yet. > It seems to me that we "should" be able to enforce > his directly, if it's specified as an important part > of IPv6 scalability. Mistakes might happen, but they > could be corrected within hours, > and typically that amount of deviation from "goodness" > wouldn't upset the overall scalability of the aggregated > route advertisements. I'm not worried about someone doing a honest mistake and making a filter SNAFU. Today, if someone announces 192.168.1.0/24 to the DFZ, who cares? nobody and the reason is because it's obviously a mistake. What I am worried is it becoming standard practice. > It just has to be that most of the DFZ community does > effectively exclude and nullify advertisement of provider- > independent (i.e., non-aggregable) addresses. Network administrators will not buy this. Half of the reason people want private addresses is because they "own" the address and therefore don't have to renumber if they switch ISPs, and the other half is that these addresses are not publicly routable. The non-routability on the public Internet is guaranteed by ambiguity as of today. It is futile do discuss the rationale why people want private addresses. Unless you have a good plan to educate masses (an RFC does not strike me as one) people will continue to use them. The real question is whether they will use the ones we provide or hijack a prefix of their own choosing. Since we can't really guarantee that globally-unique-private will stay private, we need to provide a solution that has acceptable odds in terms of non-routability. In other words: The need for global PI will prevail over the need for globally-unique-private for the simple reason that administrators have a backup plan for globally-unique-private if they pervert the mechanism we develop: hijack a prefix. The reason network administrators will not believe that operators will nullify PI advertisement is because these very same administrators are the ones that will be asking these very same operators to do the exact opposite in exchange for cash. 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 Apr 9 15:11: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 h39MBWmh005829; Wed, 9 Apr 2003 15:11:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39MBWf1005828; Wed, 9 Apr 2003 15:11:32 -0700 (PDT) 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 h39MBTmh005821 for ; Wed, 9 Apr 2003 15:11:29 -0700 (PDT) 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 h39MBbvV023724 for ; Wed, 9 Apr 2003 15:11:37 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA05279 for ; Wed, 9 Apr 2003 16:11:31 -0600 (MDT) 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, 9 Apr 2003 22:11:31 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, 9 Apr 2003 22:11: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; Wed, 9 Apr 2003 22:11:30 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; Wed, 9 Apr 2003 22:11: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 PAA28528; Wed, 9 Apr 2003 15:11:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h39MBTw23232; Wed, 9 Apr 2003 15:11:29 -0700 X-mProtect: <200304092211> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.159, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNNViYS; Wed, 09 Apr 2003 15:11:27 PDT Message-Id: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Apr 2003 15:11:04 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden & Margaret Wasserman Subject: Consensus on Site-Local Addressing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, Well, that was fun! :-) All told, there were over 200 responses to the consensus call on IPv6 site-local addressing, approximately 3-to-1 in favor of deprecating IPv6 site-local unicast addressing. The final count (including the room and the mailing list) was: 155 YES, 56 NO (211 Total). There were also a significant number of the people on both sides of this issue that voiced (in their original responses, or in subsequent messages) a strong belief that we should investigate alternative mechanisms for local addressing and local access control. The chairs have read all of the messages on the list, and based on your considerable input, we have determined that the IPv6 WG does have rough consensus to deprecate the usage of IPv6 site-local unicast addressing AND to investigate alternative mechanisms for local addressing and local access control. In particular, the IPv6 WG will work to accomplish the following things in parallel: (1) Publish an informational document that explains the issues encountered with site-local addressing and our reasons for deprecating IPv6 site-local unicast addresses. This document will officially deprecate site-local addressing. (2) Remove site-local unicast addressing from the IPv6 scoped addressing architecture I-D, and publish the parts of the document on which we do have consensus (i.e., link local addresses, multicast, etc.). This will include a note that the IPv6 working group is investigating other forms of local IPv6 addressing and that the usage of any new forms of local addresses will be documented elsewhere. (3) Update the IPv6 addressing architecture to indicate that the usage of the FECO::/10 prefix for site-local addressing is deprecated. To maintain backward compatibility with existing implementations the prefix should be reserved and should not be allocated for other purposes. (4) Define and publish the requirements for a local addressing mechanism to provide: - Addresses for disconnected networks. - Addresses for intermittently connected networks. - Addresses that support merging of sites. - Stable local addresses for changing ISPs without disrupting local communication. Once we have consensus on the requirements, the IPv6 WG will work on solutions for local addressing that meet those requirements. (5) Define and publish the requirements for a local access control mechanism, then work on a solution that meets those requirements. Each of these new work items will need to be added to the IPv6 WG charter and will go through the normal IETF document processes. For (4) and (5) it is important to make the rest of the IETF community aware that the IPv6 WG is undertaking these tasks, so we will consider methods to invite wider review and discussion of these problems. IPv6 site-local addressing has been a contentious issue in the IPv6 WG for some time, and we are both glad to see the WG reach consensus on this issue. This will allow us to complete and publish the IPv6 scoped addressing architecture document, an important part of the IPv6 specification. We hope that people on all sides of this issue will respect the rough consensus of the WG, and will work with us to achieve the goals outlined above. Thanks to everyone who expressed an opinion during this discussion. Bob Hinden & Margaret Wasserman IPv6 WG Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 9 15:14: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 h39MEVmh005946; Wed, 9 Apr 2003 15:14:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39MEVfV005945; Wed, 9 Apr 2003 15:14:31 -0700 (PDT) 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 h39MERmh005935 for ; Wed, 9 Apr 2003 15:14:27 -0700 (PDT) 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 h39MEZcU020537 for ; Wed, 9 Apr 2003 15:14:35 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA07568 for ; Wed, 9 Apr 2003 15:14:30 -0700 (PDT) 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, 9 Apr 2003 22:14:29 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, 9 Apr 2003 22:14: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, 9 Apr 2003 22:14:29 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 22:14:29 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id A24AE146BF; Thu, 10 Apr 2003 08:14:26 +1000 (EST) Date: Thu, 10 Apr 2003 08:14:26 +1000 From: "Nick 'Sharkey' Moore" To: Patrik F?ltstr?m Cc: ipng@sunroof.eng.sun.com Subject: Re: Yet another FEC0::/10 proposal Message-Id: <20030409221426.GF1746@zoic.org> Mail-Followup-To: Patrik F?ltstr?m , ipng@sunroof.eng.sun.com References: <20030408220832.GD27763@zoic.org> <7DCB2018-6A53-11D7-88A6-000A959CF516@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7DCB2018-6A53-11D7-88A6-000A959CF516@cisco.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Apr 09, 2003 at 08:21:25AM +0200, Patrik F?ltstr?m wrote: > > > > A -------- (B_A B_C) ------- C > > \__________________________/ > > > >Eg: with the scoping rules I proposed earlier, S(A) MUST= S(B_A) > >already, > >and S(B_C) MUST= S(C) already. So if your application ensures that > >S(B_A) = S(B_C), then S(A) = S(C), and there's no problem. > > Yes, B might detect that the scope is different, but what should B do? Well, if B only corresponds on addresses in one scope, that problem goes away. Presumably, if you _really_ want B to see two scopes, B needs to keep two client lists and never the twain shall meet. I think, in short, that this can be easily solved with 1) strict scoping rules at L3 and 2) sane setups in the application. > FTP and SIP. Especially SIP (ftp is not used in that mode much the last > 20 years...). I'm not sure whether to be glad or not that FTP is not the only protocol doing this sort of thing ... -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 9 15:22: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 h39MMcmh006484; Wed, 9 Apr 2003 15:22:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39MMcmQ006483; Wed, 9 Apr 2003 15:22:38 -0700 (PDT) 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 h39MMYmh006476 for ; Wed, 9 Apr 2003 15:22:34 -0700 (PDT) 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 h39MMgcU023367 for ; Wed, 9 Apr 2003 15:22:43 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA29554 for ; Wed, 9 Apr 2003 16:22:37 -0600 (MDT) 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, 9 Apr 2003 22:22:37 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, 9 Apr 2003 22:22: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; Wed, 9 Apr 2003 22:22:36 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 22:22:36 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id DD830146BF; Thu, 10 Apr 2003 08:22:34 +1000 (EST) Date: Thu, 10 Apr 2003 08:22:34 +1000 From: "Nick 'Sharkey' Moore" To: ipng@sunroof.eng.sun.com Cc: Brian E Carpenter Subject: Re: Goals vs. process Message-Id: <20030409222234.GB7329@zoic.org> Mail-Followup-To: ipng@sunroof.eng.sun.com, Brian E Carpenter References: <5.1.0.14.2.20030405112707.030dfbc0@mail.windriver.com> <5.1.0.14.2.20030407055056.036f9188@mail.windriver.com> <3E91CCAD.AF49740F@iprg.nokia.com> <3E92199F.2070702@eng.monash.edu.au> <3E92F974.C0782F86@iprg.nokia.com> <20030408230047.GA587@zoic.org> <3E942FCE.F1298511@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E942FCE.F1298511@hursley.ibm.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Apr 09, 2003 at 04:35:58PM +0200, Brian E Carpenter wrote: > Nick 'Sharkey' Moore wrote: > > > > :-) Good point. I guess the exception is geographical routing > > stuff, where routes to Melbourne and Sydney aggregate to a > > route to Australia if you're far enough away. > > If the relevant ISPs in Oz don't share the same trans-Pacific > route, they don't aggregate at all. Well, they might for a router on the east coast, which might just look at the address and go "Oh, the antipodes. Send it to California." The Californian router then has to look at it and decide is it for Melbourne or for Sydney or for Auckland. I realize that this kind of 'geographical scope' isn't very useful for a lot of things, and I'm certainly not advocating the replacement of the current scheme with it. I think it's got some charms though. Right, back to replacing SLAs ... -----sharks -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 9 15:33: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 h39MXomh006774; Wed, 9 Apr 2003 15:33:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39MXoQ4006773; Wed, 9 Apr 2003 15:33:50 -0700 (PDT) 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 h39MXkmh006766 for ; Wed, 9 Apr 2003 15:33:46 -0700 (PDT) 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 h39MXscU027110 for ; Wed, 9 Apr 2003 15:33:55 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA20300 for ; Wed, 9 Apr 2003 16:33:49 -0600 (MDT) 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, 9 Apr 2003 22:33: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; Wed, 9 Apr 2003 22:33:48 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, 9 Apr 2003 22:33:48 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 22:33:47 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id SAA09330; Wed, 9 Apr 2003 18:33:43 -0400 (EDT) Date: Wed, 9 Apr 2003 18:33:43 -0400 (EDT) From: Dan Lanciani Message-Id: <200304092233.SAA09330@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: Globally Unique Private Addresses and Scoped Architecture Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Michel Py" wrote: |Unfortunately "scalable PI" |is an oxymoron, which is why we need to reduce the risk of |globally-unique-private becoming globally-unique-not-private with means |PI and routing table bloat. IMHO, it is impossible to reduce the risk as stated. That is, we might be able to prevent globally-unique-globally-visible-in-the-routing-table, but that isn't quite the same thing. Once we have any globally unique ownable address space we can make it not-private with auto-tunnels analogous to those used for 6to4. All that is required is agreement on a lookup mechanism, and I believe that the desire for PI space is strong enough to produce such an agreement in the market regardless of what the IETF may do. Now, I happen to think that ownable address space would be a good thing, but it would seriously alter the economics of pure provider-controlled allocations. Again IMHO, the only reason site-locals survived as long as they did was that their ambiguity made them appear as less of a threat in this respect. Dan Lanciani ddl@danlan.*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 Apr 9 16:11:12 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 h39NBCmh007220; Wed, 9 Apr 2003 16:11:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39NBC1T007219; Wed, 9 Apr 2003 16:11:12 -0700 (PDT) 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 h39NB8mh007212 for ; Wed, 9 Apr 2003 16:11:08 -0700 (PDT) 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 h39NBHcU008133 for ; Wed, 9 Apr 2003 16:11:17 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA24503 for ; Wed, 9 Apr 2003 17:11:11 -0600 (MDT) 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, 9 Apr 2003 23:11: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; Wed, 9 Apr 2003 23:11: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; Wed, 9 Apr 2003 23:11:10 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; Wed, 9 Apr 2003 23:11:10 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 h39NB3GO023756; Wed, 9 Apr 2003 16:11:05 -0700 (PDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id AAA16330; Thu, 10 Apr 2003 00:11:02 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Bob Hinden & Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Addressing From: Ole Troan Date: Thu, 10 Apr 2003 00:11:02 +0100 In-Reply-To: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> (Bob Hinden & Margaret Wasserman's message of "Wed, 09 Apr 2003 15:11:04 -0700") Message-Id: <7t5smsrl115.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.20030409150734.02f0ad58@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [...] what do you propose to do with existing RFCs/drafts which refers to/uses site-local addresses? RFC2894 comes to mind. /ot > In particular, the IPv6 WG will work to accomplish the following > things in parallel: > > (1) Publish an informational document that explains the issues > encountered with site-local addressing and our reasons > for deprecating IPv6 site-local unicast addresses. This > document will officially deprecate site-local addressing. > > (2) Remove site-local unicast addressing from the IPv6 > scoped addressing architecture I-D, and publish the > parts of the document on which we do have consensus > (i.e., link local addresses, multicast, etc.). This > will include a note that the IPv6 working group is > investigating other forms of local IPv6 addressing and > that the usage of any new forms of local addresses will be > documented elsewhere. > > (3) Update the IPv6 addressing architecture to indicate that the > usage of the FECO::/10 prefix for site-local addressing is > deprecated. To maintain backward compatibility with existing > implementations the prefix should be reserved and should not > be allocated for other purposes. > > (4) Define and publish the requirements for a local addressing > mechanism to provide: > - Addresses for disconnected networks. > - Addresses for intermittently connected networks. > - Addresses that support merging of sites. > - Stable local addresses for changing ISPs without > disrupting local communication. > Once we have consensus on the requirements, the IPv6 > WG will work on solutions for local addressing that > meet those requirements. > > (5) Define and publish the requirements for a local access > control mechanism, then work on a solution that meets > those requirements. > > Each of these new work items will need to be added to the IPv6 WG > charter and will go through the normal IETF document processes. For > (4) and (5) it is important to make the rest of the IETF community > aware that the IPv6 WG is undertaking these tasks, so we will consider > methods to invite wider review and discussion of these problems. > > IPv6 site-local addressing has been a contentious issue in the IPv6 WG > for some time, and we are both glad to see the WG reach consensus on > this issue. This will allow us to complete and publish the IPv6 > scoped addressing architecture document, an important part of the IPv6 > specification. > > We hope that people on all sides of this issue will respect the rough > consensus of the WG, and will work with us to achieve the goals > outlined above. > > Thanks to everyone who expressed an opinion during this discussion. > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 9 16:22:30 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 h39NMUmh007525; Wed, 9 Apr 2003 16:22:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39NMU65007524; Wed, 9 Apr 2003 16:22:30 -0700 (PDT) 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 h39NMQmh007517 for ; Wed, 9 Apr 2003 16:22:26 -0700 (PDT) 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 h39NMZcU011448 for ; Wed, 9 Apr 2003 16:22:35 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA09393 for ; Wed, 9 Apr 2003 16:22:29 -0700 (PDT) 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, 9 Apr 2003 23:22: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; Wed, 9 Apr 2003 23:18: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, 9 Apr 2003 23:22:28 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; Wed, 9 Apr 2003 23:22:28 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 AAA02204 for ; Thu, 10 Apr 2003 00:22: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 AAA03886 for ; Thu, 10 Apr 2003 00:22:25 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h39NMP110520 for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 00:22:25 +0100 Date: Thu, 10 Apr 2003 00:22:25 +0100 From: Tim Chown To: "ipng@sunroof.eng.sun.com" Subject: Re: Is /32 enough? (was Re: Patrick Faltstrom...) Message-Id: <20030409232225.GF10290@login.ecs.soton.ac.uk> Mail-Followup-To: "ipng@sunroof.eng.sun.com" References: <200304052043.PAA16343@ss10.danlan.com> <417230000.1049703524@localhost.besserwisser.org> <20030407093146.GS23732@login.ecs.soton.ac.uk> <758240000.1049782597@localhost.besserwisser.org> <20030408064836.GB19150@login.ecs.soton.ac.uk> <885020000.1049794189@localhost.besserwisser.org> <20030408101852.GC26495@login.ecs.soton.ac.uk> <20030408104946.GA27074@login.ecs.soton.ac.uk> <3E943144.62389568@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E943144.62389568@hursley.ibm.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Apr 09, 2003 at 04:42:12PM +0200, Brian E Carpenter wrote: > > Regardless, I wouldn't be shocked by a DFZ where a given ISP had multiple > /29s if it grew really big. I do agree that ISPs need to have a sense > that they can get as many of the 35 trillion /48s as they need. OK, so long as the ISP's know that and don't start rolling out with dynamic prefixes... this would only increase clamour for 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 Wed Apr 9 16:22: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 h39NMhmh007535; Wed, 9 Apr 2003 16:22:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39NMh3d007534; Wed, 9 Apr 2003 16:22:43 -0700 (PDT) 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 h39NMbmh007527 for ; Wed, 9 Apr 2003 16:22:37 -0700 (PDT) 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 h39NMjcU011543 for ; Wed, 9 Apr 2003 16:22:45 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA06859 for ; Wed, 9 Apr 2003 17:22:40 -0600 (MDT) 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, 9 Apr 2003 23:22: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, 9 Apr 2003 23:19: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, 9 Apr 2003 23:22:37 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; Wed, 9 Apr 2003 23:22:37 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id AC199146BF; Thu, 10 Apr 2003 09:22:35 +1000 (EST) Date: Thu, 10 Apr 2003 09:22:35 +1000 From: "Nick 'Sharkey' Moore" To: IPng Cc: Margaret Wasserman Subject: Re: A different FEC0::/10 proposal Message-Id: <20030409232235.GC7329@zoic.org> Mail-Followup-To: IPng , Margaret Wasserman References: <3E8D3F6D.3C780065@motorola.com> <3E8D8941.C0CF8359@hursley.ibm.com> <3E90E508.362F6EEC@motorola.com> <431280000.1049704844@localhost.besserwisser.org> <3E923D4B.395A8BD6@motorola.com> <751000000.1049782231@localhost.besserwisser.org> <5.1.0.14.2.20030408073028.04270e70@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030408073028.04270e70@mail.windriver.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Apr 08, 2003 at 07:36:13AM -0400, Margaret Wasserman wrote: > > There are some choices other than modifying existing applications to know > about address scope, such as: > Returning only global addresses in the default APIs. Applications that > know how to handle locally scoped address could ask for them explicitly. Hmmm ... I'm not that keen on this one, since it may mess stuff up for nodes on sometimes-connected networks. > There are also alternatives to split DNS for getting local addresses > from the DNS, such as: > A special local DNS domain (such as .local) or a different DNS record > to retrieve local addresses. Yeah, I was thinking along these lines myself ... if you enforce scoping rules such that for a given packet S(source) MUST= S(dest) a lot of the address selection problems go away, I think. -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 9 16:31: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 h39NVTmh008127; Wed, 9 Apr 2003 16:31:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39NVTow008126; Wed, 9 Apr 2003 16:31:29 -0700 (PDT) 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 h39NVPmh008119 for ; Wed, 9 Apr 2003 16:31:25 -0700 (PDT) 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 h39NVXcU014832 for ; Wed, 9 Apr 2003 16:31:33 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA03961 for ; Wed, 9 Apr 2003 17:31:28 -0600 (MDT) 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, 9 Apr 2003 23:31: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, 9 Apr 2003 23:31: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, 9 Apr 2003 23:31:27 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, 9 Apr 2003 23:31:27 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 QAA02036; Wed, 9 Apr 2003 16:31:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h39NVQo07082; Wed, 9 Apr 2003 16:31:26 -0700 X-mProtect: <200304092331> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.159, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBAuLu7; Wed, 09 Apr 2003 16:31:23 PDT Message-Id: <4.3.2.7.2.20030409162826.02f0ad58@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Apr 2003 16:31:22 -0700 To: Ole Troan From: Bob Hinden Subject: Re: Consensus on Site-Local Addressing Cc: ipng@sunroof.eng.sun.com In-Reply-To: <7t5smsrl115.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> <4.3.2.7.2.20030409150734.02f0ad58@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 Ole, >what do you propose to do with existing RFCs/drafts which refers >to/uses site-local addresses? RFC2894 comes to mind. In the short term nothing. There are existing implementations that use site-local. Once (4) is further along we will likely have a better idea of how to update these documents. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 9 16:38: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 h39NcQmh008534; Wed, 9 Apr 2003 16:38:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39NcQBD008533; Wed, 9 Apr 2003 16:38:26 -0700 (PDT) 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 h39NcNmh008526 for ; Wed, 9 Apr 2003 16:38:23 -0700 (PDT) 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 h39NcVvV020061 for ; Wed, 9 Apr 2003 16:38:31 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA21867 for ; Wed, 9 Apr 2003 16:38:26 -0700 (PDT) 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, 9 Apr 2003 23:38: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, 9 Apr 2003 23:38: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; Wed, 9 Apr 2003 23:38:25 Z Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 9 Apr 2003 23:38:25 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 h39NcLB1026177; Wed, 9 Apr 2003 19:38:21 -0400 (EDT) Date: Wed, 9 Apr 2003 19:38:21 -0400 (EDT) From: Ralph Droms To: Bob Hinden cc: Ole Troan , Subject: Re: Consensus on Site-Local Addressing In-Reply-To: <4.3.2.7.2.20030409162826.02f0ad58@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 Bob - not to be difficult...by "implementations that use" do you mean "devices that implement" or "deployments that use" site-locals? - Ralph On Wed, 9 Apr 2003, Bob Hinden wrote: > Ole, > > >what do you propose to do with existing RFCs/drafts which refers > >to/uses site-local addresses? RFC2894 comes to mind. > > In the short term nothing. There are existing implementations that use > site-local. Once (4) is further along we will likely have a better idea of > how to update these documents. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 9 16:54: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 h39Nsnmh008952; Wed, 9 Apr 2003 16:54:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h39NsnSB008951; Wed, 9 Apr 2003 16:54:49 -0700 (PDT) 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 h39Nskmh008944 for ; Wed, 9 Apr 2003 16:54:46 -0700 (PDT) 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 h39NsscU022137 for ; Wed, 9 Apr 2003 16:54:54 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id RAA21824 for ; Wed, 9 Apr 2003 17:54:48 -0600 (MDT) 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, 9 Apr 2003 23:54: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, 9 Apr 2003 23:54: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; Wed, 9 Apr 2003 23:54:48 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, 9 Apr 2003 23:54:48 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 QAA02882; Wed, 9 Apr 2003 16:54:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h39NskX09694; Wed, 9 Apr 2003 16:54:46 -0700 X-mProtect: <200304092354> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.159, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2Hwa3t; Wed, 09 Apr 2003 16:54:44 PDT Message-Id: <4.3.2.7.2.20030409164501.02935410@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Apr 2003 16:50:47 -0700 To: Ralph Droms From: Bob Hinden Subject: Re: Consensus on Site-Local Addressing Cc: In-Reply-To: References: <4.3.2.7.2.20030409162826.02f0ad58@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 Ralph, There are devices that implement site-locals and I would assume there is some usage as well. Bob At 04:38 PM 4/9/2003, Ralph Droms wrote: >Bob - not to be difficult...by "implementations that use" do you mean >"devices that implement" or "deployments that use" site-locals? > >- Ralph > >On Wed, 9 Apr 2003, Bob Hinden wrote: > > > Ole, > > > > >what do you propose to do with existing RFCs/drafts which refers > > >to/uses site-local addresses? RFC2894 comes to mind. > > > > In the short term nothing. There are existing implementations that use > > site-local. Once (4) is further along we will likely have a better idea of > > how to update these documents. > > > > Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 9 17:06: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 h3A060mh009373; Wed, 9 Apr 2003 17:06:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A060NC009372; Wed, 9 Apr 2003 17:06:00 -0700 (PDT) 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 h3A05umh009362 for ; Wed, 9 Apr 2003 17:05:57 -0700 (PDT) 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 h3A065cU025128 for ; Wed, 9 Apr 2003 17:06:05 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id SAA19995 for ; Wed, 9 Apr 2003 18:05:59 -0600 (MDT) 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, 10 Apr 2003 00:05:17 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, 10 Apr 2003 00:05:17 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, 10 Apr 2003 00:05:16 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; Thu, 10 Apr 2003 00:05:16 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 RAA03354 for ; Wed, 9 Apr 2003 17:05:15 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3A05EG26587; Wed, 9 Apr 2003 17:05:14 -0700 X-mProtect: <200304100005> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJz5fEf; Wed, 09 Apr 2003 17:05:12 PDT Message-Id: <3E94B596.40706@iprg.nokia.com> Date: Wed, 09 Apr 2003 17:06:46 -0700 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: Bob Hinden & Margaret Wasserman CC: ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Addressing References: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, Bob Hinden & Margaret Wasserman wrote: > (4) Define and publish the requirements for a local addressing > mechanism to provide: > - Addresses for disconnected networks. > - Addresses for intermittently connected networks. > - Addresses that support merging of sites. > - Stable local addresses for changing ISPs without > disrupting local communication. > Once we have consensus on the requirements, the IPv6 > WG will work on solutions for local addressing that > meet those requirements. A fundamental question here is whether the disconnected/intermittently connected networks will require subnetting internally. When subnetting is not required, link-local addressing (i.e., FE80::/10) may be enough. 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 Apr 9 17:41: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 h3A0flmh009862; Wed, 9 Apr 2003 17:41:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A0flFo009861; Wed, 9 Apr 2003 17:41:47 -0700 (PDT) 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 h3A0fhmh009854 for ; Wed, 9 Apr 2003 17:41:43 -0700 (PDT) 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 h3A0fpcU003621 for ; Wed, 9 Apr 2003 17:41:51 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id RAA20130 for ; Wed, 9 Apr 2003 17:41:46 -0700 (PDT) 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, 10 Apr 2003 00:41:46 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, 10 Apr 2003 00:41: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; Thu, 10 Apr 2003 00:41:45 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 00:41:44 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 09 Apr 2003 17:41:42 -0700 Reply-To: From: "Tony Hain" To: "'Thomas Narten'" , "'Erik Nordmark'" Cc: Subject: FW: Consensus on Site-Local Addressing Date: Wed, 9 Apr 2003 17:41:32 -0700 Message-Id: <0f4201c2fef9$ef22eaf0$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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3A0fhmh009855 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas & Erik, Please consider this the second step in the appeal process, as I have already discussed these issues with the chairs on more than one occasion. 'we reject kings, presidents and voting...' The consensus measurement on the mail list was much more indicative of the real lack of it (60/40%), than what was effectively ballot stuffing by WG visitors without a complete context. There was a very short presentation in the apps open area, intended to raise concerns and incite involvement, were those in the apps area were agitated, then invited to the IPv6 WG session in SF to discuss the potential issues. The subsequent short discussion in the IPv6 WG showed there were issues to work through, and at least one question voiced about understanding the requirements. Rather than deal with the issues raised, the chairs decided to call an ambiguous question of yes/no for deprecation. While the chairs do in 2) recognize their interpretation of the consensus that the WG will investigate other forms of local addressing, there is no mention of ambiguity and the rest of the wording of 1) & 2) can be interpreted as local scope addressing is deprecated. The concern is that we will end up with a document lacking local scope addressing, and claims that we had consensus to remove local scope from the architecture. Many of those who bothered to state why they were expressing a yes opinion claimed ambiguity was the reason, while others were only interested in removing special handling for local scope addresses. Those are technically different issues, so they need different questions. What we have is an indication that many are unhappy with the status quo, but a lack of recognition that the call ended up combining yes opinions for removing ambiguity with yes opinions for removing local scope addresses from the architecture. From subsequent discussions with the chairs, it is clear that was not their intent, but never the less that is the result of the lack of clarity in this consensus call. '... we believe in rough consensus & running code' & from the Tao : 'running code wins' On several related mail threads there were many comments about running code, and at least Brian Zill & Brian Haberman said they collectively had host, application, and router implementations of the current SL running. Point 3) even acknowledges there are existing implementations. This consensus call intends to invalidate the running code, and all we have to replace it is a promise in 4) that if the group can ever agree that operational requirements of the site network manager are worth solving, we might start to work on solutions, subject to appropriate charter updates. This whole discussion is based on the argument that some developers couldn't create running code for an arguably bogus scenario where topology locators are blindly passed outside their scope of relevance. Bias was given to the opinions of those with a lack of running code, at the expense of, and with the specific intent of invalidating the code that exists. There were also claims in the meeting and mail threads that we have analyzed site local as currently defined, and it doesn't meet the requirements. At the same time, there is a recognition by many of the same people that we need to develop a complete set of requirements. It should be obvious that the analysis is flawed if the complete set of requirements are not understood first. To that end, and in the spirit of making progress, draft-hain-ipv6-sitelocal-00.txt was processed by the I-D editor on 4/8, and is offered as an attempt to document the requirements for address space with a local scope of relevance. It is clearly incomplete, and largely based on my previous email on the subject. While I contest the claim that the Yes/No opinions expressed measured consensus for a consistent interpretation of what 'deprecate site local addresses' means, I do believe that a set of work items for the group were identified. It is also clear that we can add new work to a group at any time, without the need to remove existing items first. I agree with the chairs that items 4) & 5) are valid outcomes of the subsequent discussion, though one thing that their interpretation of the result does not make clear is the meaning of 'accomplish the following things in parallel:'. In talking to the chairs it appears the intent is to start the work at the same time, but we need to avoid invalid transition states, so parallel needs to mean that all 5 are to be forwarded to the IESG at one time. In particular, without solutions to the requirements in hand, any documents for 1) & 3) that intend to deprecate the only local use address space will simply create chaos, and might need to be rescinded if the complete set of requirements shows a need with no other technical approach. In short, I do not believe the consensus call measured the opinions that were consistent the chairs interpretation of the question, so the claimed results are invalid. I do believe that the effort identified work items 4) & 5), with the potential that 1) & 3) might follow if there are no outstanding requirements for ambiguous address space. I question the wisdom of 2), but will reserve judgment until the complete text identifying further work is spelled out. In any case, I hope this appeal can be dealt with at this level, and that the overall effort results in an expedited charter update. It is imperative that new approaches exist prior to removal of the current, and there is a very real danger that the current destructive energy will dissipate in the face of the hard work of creating replacements. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Bob > Hinden & Margaret Wasserman > Sent: Wednesday, April 09, 2003 3:11 PM > To: ipng@sunroof.eng.sun.com > Subject: Consensus on Site-Local Addressing > > > Hi All, > > Well, that was fun! :-) > > All told, there were over 200 responses to the consensus call on IPv6 > site-local addressing, approximately 3-to-1 in favor of > deprecating IPv6 > site-local unicast addressing. The final count (including > the room and the > mailing list) was: 155 YES, 56 NO (211 Total). > > There were also a significant number of the people on both > sides of this > issue that voiced (in their original responses, or in > subsequent messages) > a strong belief that we should investigate alternative > mechanisms for local > addressing and local access control. > > The chairs have read all of the messages on the list, and > based on your > considerable input, we have determined that the IPv6 WG does > have rough > consensus to deprecate the usage of IPv6 site-local unicast > addressing AND > to investigate alternative mechanisms for local addressing > and local access > control. > > In particular, the IPv6 WG will work to accomplish the > following things in > parallel: > > (1) Publish an informational document that explains the issues > encountered with site-local addressing and our reasons > for deprecating IPv6 site-local unicast addresses. This > document will officially deprecate site-local addressing. > > (2) Remove site-local unicast addressing from the IPv6 > scoped addressing architecture I-D, and publish the > parts of the document on which we do have consensus > (i.e., link local addresses, multicast, etc.). This > will include a note that the IPv6 working group is > investigating other forms of local IPv6 addressing and > that the usage of any new forms of local addresses will be > documented elsewhere. > > (3) Update the IPv6 addressing architecture to indicate that the > usage of the FECO::/10 prefix for site-local addressing is > deprecated. To maintain backward compatibility with existing > implementations the prefix should be reserved and should not > be allocated for other purposes. > > (4) Define and publish the requirements for a local addressing > mechanism to provide: > - Addresses for disconnected networks. > - Addresses for intermittently connected networks. > - Addresses that support merging of sites. > - Stable local addresses for changing ISPs without > disrupting local communication. > Once we have consensus on the requirements, the IPv6 > WG will work on solutions for local addressing that > meet those requirements. > > (5) Define and publish the requirements for a local access > control mechanism, then work on a solution that meets > those requirements. > > Each of these new work items will need to be added to the > IPv6 WG charter > and will go through the normal IETF document processes. For > (4) and (5) it > is important to make the rest of the IETF community aware > that the IPv6 WG > is undertaking these tasks, so we will consider methods to > invite wider > review and discussion of these problems. > > IPv6 site-local addressing has been a contentious issue in > the IPv6 WG for > some time, and we are both glad to see the WG reach consensus on this > issue. This will allow us to complete and publish the IPv6 scoped > addressing architecture document, an important part of the > IPv6 specification. > > We hope that people on all sides of this issue will respect the rough > consensus of the WG, and will work with us to achieve the > goals outlined above. > > Thanks to everyone who expressed an opinion during this discussion. > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 9 17:42: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 h3A0gbmh009882; Wed, 9 Apr 2003 17:42:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A0gbet009881; Wed, 9 Apr 2003 17:42:37 -0700 (PDT) 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 h3A0gXmh009874 for ; Wed, 9 Apr 2003 17:42:33 -0700 (PDT) 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 h3A0gfcU003756 for ; Wed, 9 Apr 2003 17:42:41 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA28728 for ; Wed, 9 Apr 2003 18:42:35 -0600 (MDT) 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, 10 Apr 2003 00:42: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; Thu, 10 Apr 2003 00:42: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, 10 Apr 2003 00:42:27 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 00:42:27 Z Content-class: urn:content-classes:message Subject: RE: Globally Unique Private Addresses and Scoped Architecture Date: Wed, 9 Apr 2003 17:42:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F759@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: Globally Unique Private Addresses and Scoped Architecture Thread-Index: AcL+6OmAIJ6h7SfhQiujNxxA9G229wACVQKQ From: "Michel Py" To: "Dan Lanciani" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3A0gXmh009875 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, | Michel Py wrote: | Unfortunately "scalable PI" is an oxymoron, which is why we need | to reduce the risk of globally-unique-private becoming globally- | unique-not-private with means PI and routing table bloat. > Dan Lanciani wrote: > IMHO, it is impossible to reduce the risk as stated. That is, > we might be able to prevent globally-unique-globally-visible- > in-the-routing-table, but that isn't quite the same thing. IMHO, what you wrote above is the risk that is impossible to reduce in the current situation. > Once we have any globally unique ownable address space we can > make it not-private with auto-tunnels analogous to those > used for 6to4. That would not bother me. > All that is required is agreement on a lookup mechanism, What you are talking about is a dual-space system. It's not simple but fortunately it already exists. > and I believe that the desire for PI space is strong enough to > produce such an agreement in the market regardless of what the > IETF may do. You might be right. > Now, I happen to think that ownable address space would be a > good thing, but it would seriously alter the economics of pure > provider-controlled allocations. Ah this is really not a surprise coming from you. A way to make sure that ISPs won't bill by the IP address. But be careful, they might make you pay extra just because you own an address instead :-) 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 Apr 9 17:44: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 h3A0ifmh009963; Wed, 9 Apr 2003 17:44:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A0ifIV009960; Wed, 9 Apr 2003 17:44:41 -0700 (PDT) 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 h3A0iamh009950 for ; Wed, 9 Apr 2003 17:44:36 -0700 (PDT) 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 h3A0iicU004169 for ; Wed, 9 Apr 2003 17:44:44 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id SAA17388 for ; Wed, 9 Apr 2003 18:44:38 -0600 (MDT) 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, 10 Apr 2003 00:44: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; Thu, 10 Apr 2003 00:41: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; Thu, 10 Apr 2003 00:44:37 Z Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 00:44:37 Z Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h3A0ilTi004848 for ; Wed, 9 Apr 2003 17:44:47 -0700 (MST) Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA09801 for ; Wed, 9 Apr 2003 17:44:36 -0700 (MST)] Received: from motorola.com (mvp-10-238-2-53.corp.mot.com [10.238.2.53]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h3A0jYw25867 for ; Wed, 9 Apr 2003 19:45:35 -0500 Message-Id: <3E94BE6F.3B7DE568@motorola.com> Date: Thu, 10 Apr 2003 10:44: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: Re: Consensus on Site-Local Addressing References: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> <4.3.2.7.2.20030409162826.02f0ad58@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden wrote: > > Ole, > > >what do you propose to do with existing RFCs/drafts which refers > >to/uses site-local addresses? RFC2894 comes to mind. > > In the short term nothing. There are existing implementations that use > site-local. There's also the question of what you mean by 'implement site local'. As I see it, there are 5 aspects of 'site local' as defined in the architecture: (1) Scopes and scope ids. (2) The FEC0::/10 prefix. (3) Ambiguity. (4) Non-routeability of SL addresses beyond 'site' (more implicit than explicit). (5) The name 'site-local'. Most people seemed happy to lose (1). There are concerns about (3), but we have several proposals to compensate. Most "don't deprectate" people wanted something that met (4). (2) and (5) are details. What did come out clearly (to me) is that there is a demand for non-routeable provider independent (NRPI) address space, and site locals were seen as providing that. My summary of the NRPI requirements is: - NRPIs must be optional. - Non-routeability must be enforced - Routers by default black hole NRPI destinations. - Networks using NRPI must implement some form of NRPI border that drops NRPI destinations AND sources and prevents NRPI from being added to the global routing tables. - NPRI prefixes must operationally be as unique as practical. - NRPI prefixes may be registered - It must be possible to get good-enough unique NRPI prefixes without a registration process. And my contentious requirement: - Unless otherwise configured, hosts / applications should favour NRPI-NRPI over global-global communication, and should disfavour NRPI-global communication. This fourth requirement is a consequence of: > - Addresses for intermittently connected networks. > - Stable local addresses for changing ISPs without > disrupting local communication. Looks a lot like the moderate SL proposal with mechanisms to prevent ambiguity. -- 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 Wed Apr 9 19:23: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 h3A2NAmh010903; Wed, 9 Apr 2003 19:23:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A2NAS9010902; Wed, 9 Apr 2003 19:23:10 -0700 (PDT) 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 h3A2N6mh010895 for ; Wed, 9 Apr 2003 19:23:06 -0700 (PDT) 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 h3A2NEvV026291 for ; Wed, 9 Apr 2003 19:23:14 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id UAA16825 for ; Wed, 9 Apr 2003 20:23:07 -0600 (MDT) 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, 10 Apr 2003 02:23: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, 10 Apr 2003 02:23: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; Thu, 10 Apr 2003 02:23:06 Z Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 02:23:06 Z Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h3A2N5mX012727 for ; Wed, 9 Apr 2003 19:23:05 -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 TAA07535 for ; Wed, 9 Apr 2003 19:23:03 -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 h3A2N2VI028974 for ; Thu, 10 Apr 2003 12:23:02 +1000 (EST) Message-Id: <3E94D585.B0BEED2F@motorola.com> Date: Thu, 10 Apr 2003 12:23:01 +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: Re: Consensus on Site-Local Addressing References: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> <4.3.2.7.2.20030409162826.02f0ad58@mailhost.iprg.nokia.com> <3E94BE6F.3B7DE568@motorola.com> <3E94CD29.9040006@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greg Daley wrote: > I'm just thinking that Ambiguity is more > important to get rid of than scoping. Greg, I suppose what I'm saying is that the idea of multiple ambiguous overlapping 'sites' identified by some additional scoping mechanism (the 'full' model) was generally seen as bad. If your identifiers (NRPI or otherwise) are unique enough, you don't need additional scope information to disambiguate them. Is that clearer, or am I getting messed up in terminology again? -- 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 Wed Apr 9 20:23: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 h3A3NHmh012111; Wed, 9 Apr 2003 20:23:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A3NHO3012110; Wed, 9 Apr 2003 20:23:17 -0700 (PDT) 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 h3A3NDmh012101 for ; Wed, 9 Apr 2003 20:23:13 -0700 (PDT) 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 h3A3NLcU007214 for ; Wed, 9 Apr 2003 20:23:22 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id VAA04828 for ; Wed, 9 Apr 2003 21:23:15 -0600 (MDT) 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, 10 Apr 2003 03:23: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, 10 Apr 2003 03:23: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; Thu, 10 Apr 2003 03:23:10 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 03:23:10 Z Content-class: urn:content-classes:message Subject: RE: Consensus on Site-Local Addressing Date: Wed, 9 Apr 2003 20:23:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F75F@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: Consensus on Site-Local Addressing Thread-Index: AcL/CVj+QdlJoFvTR3mqNZ7yEVbZNwABrEoQ From: "Michel Py" To: , "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3A3NEmh012104 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew, >> Greg Daley wrote: >> I'm just thinking that Ambiguity is more >> important to get rid of than scoping. > Andrew White wrote: > I suppose what I'm saying is that the idea of multiple ambiguous > overlapping 'sites' identified by some additional scoping > mechanism (the 'full' model) was generally seen as bad. Correct. > If your identifiers (NRPI or otherwise) are unique enough, you > don't need additional scope information to disambiguate them. No, but you need additional scope (or some other kind of architectural limitation) as a guarantee/odds lowering that these NRPI would not be routed on the global routing table. 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 Apr 9 21:01:10 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 h3A41Amh012429; Wed, 9 Apr 2003 21:01:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A41A3h012428; Wed, 9 Apr 2003 21:01:10 -0700 (PDT) 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 h3A416mh012421 for ; Wed, 9 Apr 2003 21:01:06 -0700 (PDT) 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 h3A41EcU013579 for ; Wed, 9 Apr 2003 21:01:15 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id WAA21467 for ; Wed, 9 Apr 2003 22:01:09 -0600 (MDT) 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, 10 Apr 2003 04:01: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; Thu, 10 Apr 2003 04:01:09 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, 10 Apr 2003 04:01:08 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 04:01:08 Z Content-class: urn:content-classes:message Subject: RE: Consensus on Site-Local Addressing Date: Wed, 9 Apr 2003 21:01:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F50456F7@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Consensus on Site-Local Addressing Thread-Index: AcL+9ZsfkCE4R+qiT/WQ1WZhPdKfCQAIA9Mw From: "Michel Py" To: "Fred L. Templin" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3A417mh012422 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, > A fundamental question here is whether the disconnected/ > intermittently connected networks will require subnetting > internally. When subnetting is not required, link-local > addressing (i.e., FE80::/10) may be enough. There are many cases where these sites would indeed require local subnetting. 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 Apr 9 21:16: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 h3A4GLmh012659; Wed, 9 Apr 2003 21:16:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A4GKBB012658; Wed, 9 Apr 2003 21:16:20 -0700 (PDT) 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 h3A4GHmh012651 for ; Wed, 9 Apr 2003 21:16:17 -0700 (PDT) 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 h3A4GPcU016002 for ; Wed, 9 Apr 2003 21:16:25 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id WAA20305 for ; Wed, 9 Apr 2003 22:16:18 -0600 (MDT) 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, 10 Apr 2003 04:16: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; Thu, 10 Apr 2003 04:16: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; Thu, 10 Apr 2003 04:16:17 Z Received: from ALPHA1.ITS.MONASH.EDU.AU (ALPHA1.ITS.MONASH.EDU.AU [130.194.1.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 04:16:17 Z Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KUKD10K7FA95W8S9@vaxc.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 14:15:57 +1000 Received: from splat.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 6138D130005 for ; Thu, 10 Apr 2003 14:15:57 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id 45988130004 for ; Thu, 10 Apr 2003 14:15:57 +1000 (EST) Date: Thu, 10 Apr 2003 14:15:57 +1000 From: Greg Daley Subject: Re: Consensus on Site-Local Addressing To: IPng Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E94EFFD.1020508@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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Andrew, I was actually thinking that choosing between routable and non-routable addresses would be the main application for scoping rules, is all. I'm not really interested in finding out which site is which, just that my address choice is the right one for the job at hand. Greg Andrew White wrote: > Greg Daley wrote: > > >>I'm just thinking that Ambiguity is more >>important to get rid of than scoping. > > > Greg, > > I suppose what I'm saying is that the idea of multiple ambiguous overlapping > 'sites' identified by some additional scoping mechanism (the 'full' model) > was generally seen as bad. If your identifiers (NRPI or otherwise) are > unique enough, you don't need additional scope information to disambiguate > them. > > Is that clearer, or am I getting messed up in terminology again? > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 9 21:41:58 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 h3A4fwmh013116; Wed, 9 Apr 2003 21:41:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A4fvDe013115; Wed, 9 Apr 2003 21:41:57 -0700 (PDT) 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 h3A4fsmh013108 for ; Wed, 9 Apr 2003 21:41:54 -0700 (PDT) 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 h3A4g2cU019919 for ; Wed, 9 Apr 2003 21:42:02 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id WAA06794 for ; Wed, 9 Apr 2003 22:41:55 -0600 (MDT) 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, 10 Apr 2003 04:41: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; Thu, 10 Apr 2003 04:37: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; Thu, 10 Apr 2003 04:41:22 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 04:41:22 Z Content-class: urn:content-classes:message Subject: RE: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Date: Wed, 9 Apr 2003 21:40:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F762@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve Thread-Index: AcL9LQFl7a2/13R0Q4Gh3qIzlS+T2wB7Yl6A From: "Michel Py" To: "Ronald van der Pol" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3A4fsmh013109 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ronald, > Ronald van der Pol wrote: > What _exactly_ should the "ideal" network provide as a service? > Two extremes are probably: > > - Applications deal with several (locator) addresses. > Input to the network layer are two (locator) addresses (src and dst). > The network delivers packets between exactly one pair of (locator) > addresses (multiple path may exist between these addresses). > The upper layers pick the "best" source and destination (locator) > addresses. > The upper layers react when a path breaks. > > - Applications deal with one identifier. > Input to the network layer are two identifiers (src and dst). > The network picks the "best" path out of several (probably by > choosing the "best" (locator) addresses). > The network reacts when a path breaks. > The upper layers use some kind of stable identifier instead of a > (locator) address. > > Where do we put the complexity? These are not mutually exclusive. The first one would likely be used in a soho-like multihomed site and the second one in a large organization setup. 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 Apr 9 23:11: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 h3A6Btmh013576; Wed, 9 Apr 2003 23:11:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A6BtqX013575; Wed, 9 Apr 2003 23:11:55 -0700 (PDT) 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 h3A6Bpmh013568 for ; Wed, 9 Apr 2003 23:11:51 -0700 (PDT) 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 h3A6BxvV001698 for ; Wed, 9 Apr 2003 23:11:59 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id AAA08174 for ; Thu, 10 Apr 2003 00:11:54 -0600 (MDT) 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, 10 Apr 2003 06:11: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; Thu, 10 Apr 2003 06:11: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; Thu, 10 Apr 2003 06:11:52 Z Received: from klapautius.it.su.se ([217.215.166.49] [217.215.166.49]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 06:11:52 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 h3A58Xo03450; Thu, 10 Apr 2003 07:08:37 +0200 Message-Id: <3E94FC4F.4070309@it.su.se> Date: Thu, 10 Apr 2003 07:08:31 +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: alh-ietf@tndh.net CC: "'Thomas Narten'" , "'Erik Nordmark'" , ipng@sunroof.eng.sun.com Subject: Re: FW: Consensus on Site-Local Addressing References: <0f4201c2fef9$ef22eaf0$ee1a4104@eagleswings> In-Reply-To: <0f4201c2fef9$ef22eaf0$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: >Thomas & Erik, > >Please consider this the second step in the appeal process, as I have >already discussed these issues with the chairs on more than one >occasion. > >'we reject kings, presidents and voting...' >The consensus measurement on the mail list was much more indicative of >the real lack of it (60/40%), than what was effectively ballot stuffing > > > Please note that the consensus call on the mailinglist explicitly called for those that expressed their opinion during the show of hands at the meeting _not_ to vote. The figures you quote doesn't take this into account. But even so the numbers you quote clearly does not constitute rough consensus for *keeping* site-locals, or as Kurt Zeilenga put it "contention is out of scope". 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 Wed Apr 9 23:51: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 h3A6ptmh013976; Wed, 9 Apr 2003 23:51:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A6ptM1013975; Wed, 9 Apr 2003 23:51:55 -0700 (PDT) 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 h3A6pqmh013968 for ; Wed, 9 Apr 2003 23:51:52 -0700 (PDT) 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 h3A6q0vV008002 for ; Wed, 9 Apr 2003 23:52:00 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id AAA07335 for ; Thu, 10 Apr 2003 00:51:54 -0600 (MDT) 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, 10 Apr 2003 06:51: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, 10 Apr 2003 06:51: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; Thu, 10 Apr 2003 06:51:53 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; Thu, 10 Apr 2003 06:51:53 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id XAA15940; Wed, 9 Apr 2003 23:51:23 -0700 (PDT) Message-Id: <5.1.0.14.2.20030410024536.03940328@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Apr 2003 02:46:24 -0400 To: "Fred L. Templin" From: Margaret Wasserman Subject: Re: Consensus on Site-Local Addressing Cc: Bob Hinden & Margaret Wasserman , ipng@sunroof.eng.sun.com In-Reply-To: <3E94B596.40706@iprg.nokia.com> References: <4.3.2.7.2.20030409150734.02f0ad58@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 Fred, At 05:06 PM 4/9/2003 -0700, Fred L. Templin wrote: >A fundamental question here is whether the disconnected/intermittently >connected networks will require subnetting internally. When subnetting >is not required, link-local addressing (i.e., FE80::/10) may be enough. This is a good question for the requirements definition, and an indication of why we think that we need to better understand the requirements before specifying a solution. 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 Apr 10 00:49: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 h3A7nVmh014317; Thu, 10 Apr 2003 00:49:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A7nVKb014316; Thu, 10 Apr 2003 00:49:31 -0700 (PDT) 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 h3A7nRmh014309 for ; Thu, 10 Apr 2003 00:49:27 -0700 (PDT) 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 h3A7nZcU022751 for ; Thu, 10 Apr 2003 00:49:35 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id BAA26132 for ; Thu, 10 Apr 2003 01:49:29 -0600 (MDT) 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, 10 Apr 2003 07:49: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; Thu, 10 Apr 2003 07:45: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; Thu, 10 Apr 2003 07:49:26 Z Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 07:49:25 Z Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3A7lC8S009025; Thu, 10 Apr 2003 09:47:35 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 10 Apr 2003 09:49:23 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 10 Apr 2003 09:49:22 +0200 Date: Thu, 10 Apr 2003 09:49:16 +0200 Subject: Re: Yet another FEC0::/10 proposal Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipng@sunroof.eng.sun.com To: "Nick 'Sharkey' Moore" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20030409221426.GF1746@zoic.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 10 Apr 2003 07:49:23.0152 (UTC) FILETIME=[B39C7500:01C2FF35] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On torsdag, apr 10, 2003, at 00:14 Europe/Stockholm, Nick 'Sharkey' Moore wrote: > Well, if B only corresponds on addresses in one scope, that problem > goes away. Presumably, if you _really_ want B to see two scopes, > B needs to keep two client lists and never the twain shall meet. > > I think, in short, that this can be easily solved with > 1) strict scoping rules at L3 and 2) sane setups in the application. As SIP is global voice over IP which ultimately means that A, B and C can be any node on the Internet, this imply only global scope can be used for applications, and limited scope can only be used in very very special and controlled environments (which I would classify is _not_ "Internet" but instead "some other thing which happens to use IP as the protocol"). This is _exactly_ why I ask myself what Site Local is really solving, as it is not usable for applications, and why I therefore think Site Local must be deprecated, as the problems (non-apps) people think Site Local is solving MUST be solved by using different mechanisms. paf -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 01:19: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 h3A8Jtmh014759; Thu, 10 Apr 2003 01:19:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A8JtWb014758; Thu, 10 Apr 2003 01:19:55 -0700 (PDT) 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 h3A8Jpmh014751 for ; Thu, 10 Apr 2003 01:19:51 -0700 (PDT) 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 h3A8K0cU028049 for ; Thu, 10 Apr 2003 01:20:00 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id BAA16519 for ; Thu, 10 Apr 2003 01:19:54 -0700 (PDT) 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, 10 Apr 2003 08:19: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; Thu, 10 Apr 2003 08:19: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; Thu, 10 Apr 2003 08:19:53 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; Thu, 10 Apr 2003 08:19:52 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id F1795146BF; Thu, 10 Apr 2003 18:19:50 +1000 (EST) Date: Thu, 10 Apr 2003 18:19:50 +1000 From: "Nick 'Sharkey' Moore" To: Patrik F?ltstr?m Cc: ipng@sunroof.eng.sun.com Subject: Re: Yet another FEC0::/10 proposal Message-Id: <20030410081950.GB8470@zoic.org> Mail-Followup-To: Patrik F?ltstr?m , ipng@sunroof.eng.sun.com References: <20030409221426.GF1746@zoic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 10, 2003 at 09:49:16AM +0200, Patrik F?ltstr?m wrote: > > As SIP is global voice over IP which ultimately means that A, B and C > can be any node on the Internet, this imply only global scope can be > used for applications, [...] > This is _exactly_ why I ask myself what Site Local is really solving, > as it is not usable for applications, [...] I'm not sure we can say "Not useful for SIP" == "Not useful for applications". -----Nick ... who knows nothing whatsoever about SIP, mind you ... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 01:29: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 h3A8Tjmh014993; Thu, 10 Apr 2003 01:29:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A8Tj3l014992; Thu, 10 Apr 2003 01:29:45 -0700 (PDT) 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 h3A8Tfmh014985 for ; Thu, 10 Apr 2003 01:29:41 -0700 (PDT) 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 h3A8TnvV023819 for ; Thu, 10 Apr 2003 01:29:49 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id BAA21215 for ; Thu, 10 Apr 2003 01:29:44 -0700 (PDT) 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, 10 Apr 2003 08:29: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, 10 Apr 2003 08:26: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, 10 Apr 2003 08:29:43 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 08:29:42 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 78F05146BF; Thu, 10 Apr 2003 18:29:40 +1000 (EST) Date: Thu, 10 Apr 2003 18:29:40 +1000 From: "Nick 'Sharkey' Moore" To: ipng@sunroof.eng.sun.com Cc: Tony Hain Subject: Re: FW: Consensus on Site-Local Addressing Message-Id: <20030410082940.GC8470@zoic.org> Mail-Followup-To: ipng@sunroof.eng.sun.com, Tony Hain References: <0f4201c2fef9$ef22eaf0$ee1a4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f4201c2fef9$ef22eaf0$ee1a4104@eagleswings> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Apr 09, 2003 at 05:41:32PM -0700, Tony Hain wrote: > > While I contest the claim that the Yes/No opinions expressed measured > consensus for a consistent interpretation of what 'deprecate site local > addresses' means, I do believe that a set of work items for the group > were identified. I reckon that's not such a bad conclusion really: I would have preferred "choose replacement X; deprecate SLA in favour of X", but I'm happy enough with "Deprecate SLA; choose replacement X" so long as the latter actually gets supported. I think there's been some really constructive work towards various candidate Xs in the many side-threads too. -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 02:42:02 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 h3A9g1mh015422; Thu, 10 Apr 2003 02:42:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A9g1iO015421; Thu, 10 Apr 2003 02:42:01 -0700 (PDT) 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 h3A9fwmh015414 for ; Thu, 10 Apr 2003 02:41:58 -0700 (PDT) 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 h3A9g6vV004140 for ; Thu, 10 Apr 2003 02:42:06 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA07403 for ; Thu, 10 Apr 2003 03:42:00 -0600 (MDT) 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, 10 Apr 2003 09:41: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; Thu, 10 Apr 2003 09:41: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, 10 Apr 2003 09:41:08 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 09:41:07 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3A9eh525663; Thu, 10 Apr 2003 16:40:44 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3A9eQQ11985; Thu, 10 Apr 2003 16:40:27 +0700 (ICT) From: Robert Elz To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= cc: ipng@sunroof.eng.sun.com Subject: Re: Yet another FEC0::/10 proposal In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Apr 2003 16:40:26 +0700 Message-Id: <11983.1049967626@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Apr 2003 09:49:16 +0200 From: Message-ID: I haven't been following the ipv6 wg list (the ipng list) for about 6 months now (just lack of time), so I'm not really aware what started this silly discussion. But this has to be the worst piece of rational argument I have ever come across in any forum, just about anywhere, by someone who should know better... | As SIP is global voice over IP which ultimately means that A, B and C | can be any node on the Internet, this imply only global scope can be | used for applications, Huh??? I see a red car, therefore only red can be used for cars. To disprove "only global scope can be used for applications" all one needs is to find an application which can use other than global scope. Well, take ssh, web browsers, NFS, telnet, SMTP, .... Examples of applications which work just fine over SL addresses. Now, if someone was stupid enough to be claiming that all applications will work using SL addressing, your counter-example would be enough to disprove that. I suppose it is possible someone who wasn't thinking might have made such a claim that I haven't seen, though I doubt it, as it is patently obvious that SL addressing can't be used anytime the communications are to go outside a site. But in any case that isn't what you're saying ... | and limited scope can only be used in very very | special and controlled environments (which I would classify is _not_ | "Internet" but instead "some other thing which happens to use IP as the | protocol"). by definition, they only work inside a site. I don't think that's very special (every node can be, if it wants a site, every collection of a few nodes on a LAN certainly can be). Controlled - yes, of course, SL addresses don't want to escape a site. | This is _exactly_ why I ask myself what Site Local is really solving, | as it is not usable for applications, That is obviously false, I use SL addressing for applications every day. | and why I therefore think Site | Local must be deprecated, as the problems (non-apps) people think Site | Local is solving MUST be solved by using different mechanisms. Go ahead and propose some different mechanism that works nearly as well, as universally, and with as few problems, as SL addressing. Some of the problems you need to solve, before we simply assume that there *must be* some other solution that someone else is required to find, and abandon SL addressing are ... How do I keep my connection to my NFS server when all my global addresses change? How do I avoid having to reconfigure my browser to know a new proxy server in the same circumstance? (etc). These are situations where SL addresses work just fine - if I assign SL addresses to my NFS server, and web cache, then I can use those addresses, and know they'll remain stable, isolated from all events other than those I decide to instigate myself (ie: if I decide to renumber my internal network, split subnets etc, then if I'm not careful, some of those addresses might alter) - nothing imposed by the outside world can make that happen. Please note, one non-answer to this is to redefine site local addresses so they're global, but not routed. That solves none of the problems (the addresses still can't be used in your SIP example for instance) but imposes some extra address assignment bureaucracy on everyone. We already have the one (chain of ISPs) that can't be avoided for topological addressing, we don't need another one (this was why we never had any global non-routable addresses in the design in the past). Personally, if a system to make this work can be found, I'd love it - globally unique non-routable addresses solve all the problems that non-unique SL addresses do, and perhaps a few more (though now we have those extra 38 bits available for SL SLAs there really isn't almost anything that SL as we have it now cannot do). Also note that even geographic address assignment plans (like Tony Hain's very clever proposal) don't avoid this bureaucracy - they allow some sites to avoid it, but require it for others - something is needed to adjudicate between multiple sites that are all in the same geographic area (apartments in an apartment block for example). I doubt that there is some other solution, but if you can find a way to make addresses stable, without making them non-routable (which makes them equivalent to SL as we now have it) then please, tell us all what that solution is. Until you can do that, please stop telling everyone that it must exist, and that someone else is required to find it. On the other hand, there clearly are applications that never want to use SL addresses. There are others for which SL addressing is workable, but for which the benefits are negligible, and so using them isn't worth the effort. And there are others for which using SL addresses, when appropriate, can be a big win. So, what seems to be needed is a way for the application to indicate which of those groups it is is - and really that just means, whether it wants to use SL addresses, if they'll work, or not. That seems reasonable to me. Abandoning SL addresses because there are a class of applications for which they don't work is absurd. The other issue is multi-site nodes. That's something that could be dropped. There were arguments in the early days about where site boundaries should be drawn - through links, through nodes, or only through DMZ's. Allowing links in multiple sites is impractical, as then packets would need to carry site IDs, and that makes a mess. Allowing nodes to be in multiple sites is possible (that's what we have) though it adds some complications. Forcing there to be a no-site link between nodes in different sites (and only one site for any node) makes SL addresses look just like globals, for almost all purposes - but means that exchange points have a harder time operating as a site - really they want to be a local site for the exchange itself, so it can use stable addressing on all of its local links, but every ISP owned router in the exchange also wants to be part of that ISP's site). This is the argument that swayed the decision in favour of multi-site nodes. Given that applications (and everything except routing protocols) need to deal with scoped addressing because of LL addresses (I'm assuming there's no-one here insane enough to be planning to deprecate those) and that multiple instances of routing protocols isn't something new anyway (and other methods can also be used, and I believe have been), there are really very few drawbacks to allowing multi-site nodes, so I see no reason to change that aspect of the spec - but it is one that could perhaps be changed (the loss isn't very great). Aside from that, Site Local addressing MUST remain as it is, until someone solves the routing problems which prevent non-topological routable addresses from working (even the geographic addressing schemes, as they're proposed to be used for routable addressing, require the topology be set up to match the geography - at least coarsely). Anyone proposing to remove the one locally routable, stable, addressing form that we have, has to be able to propose a replacement, otherwise we simply have to retain what we have now, which works. That is, people used it, and yes, it works! kre ps: I'm a co-author of a paper that is to be submitted (somewhere, I don't personally really care much where it is going) which describes exactly how we use SL addresses, how easily they're made to work, and gives at least some idea on how the API can be managed to allow all of this, though I'm not yet sure we have that quite right yet - there's still work being done. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 02:44: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 h3A9ihmh015496; Thu, 10 Apr 2003 02:44:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A9ihxs015495; Thu, 10 Apr 2003 02:44:43 -0700 (PDT) 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 h3A9iemh015488 for ; Thu, 10 Apr 2003 02:44:40 -0700 (PDT) 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 h3A9imvV004503 for ; Thu, 10 Apr 2003 02:44:48 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id DAA07214 for ; Thu, 10 Apr 2003 03:44:39 -0600 (MDT) 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, 10 Apr 2003 09:44:39 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, 10 Apr 2003 09:41: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, 10 Apr 2003 09:44:38 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 09:44:37 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3A9iV525916; Thu, 10 Apr 2003 16:44:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3A9i6Q11999; Thu, 10 Apr 2003 16:44:10 +0700 (ICT) From: Robert Elz To: Bob Hinden , Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Addressing In-Reply-To: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Apr 2003 16:44:06 +0700 Message-Id: <11997.1049967846@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 09 Apr 2003 15:11:04 -0700 From: Bob Hinden & Margaret Wasserman Message-ID: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> | All told, there were over 200 responses to the consensus call on IPv6 | site-local addressing, approximately 3-to-1 in favor of deprecating IPv6 | site-local unicast addressing. The final count (including the room and the | mailing list) was: 155 YES, 56 NO (211 Total). As I just said in another message, I haven't been following what has been going on here for some time, so I wasn't aware you were voting (which is something the IETF doesn't normally do). You can add me to the "no" list. But 155 to 57 (or anything else like that) isn't consensus, or rough consensus, for anything. It is lack of consensus. That's clear. What's more, on another issue, 8-9 months again, where there was a similar ratio in favour of a change, the chairs ruled that there was no consensus, and so the change wouldn't be made. Of course, that was an issue where those opposed included one chair, and one AD, and almost no-one else, so clearly there there could not be consensus for a change could there? Without consensus for a change, the docs should stay as they are, just as was done last time. | There were also a significant number of the people on both sides of this | issue that voiced (in their original responses, or in subsequent messages) | a strong belief that we should investigate alternative mechanisms for local | addressing and local access control. This is just fine, the WG can certainly do that. But the right thing to do is to leave SL addressing in the spec now, until there is something better to replace it. Why would anyone want to take something that works just fine, within its scope of usefulness, and discard it, and then go looking for a mechanism to achieve all the same functions as the first offers. What do we do if after all that searching, we just return to where we are now? | The chairs have read all of the messages on the list, and based on your | considerable input, we have determined that the IPv6 WG does have rough | consensus to deprecate the usage of IPv6 site-local unicast addressing AND | to investigate alternative mechanisms for local addressing and local access | control. You can expect an appeal against the decision that there is rough consensus here. What there is, is a debate. You can treat this message as an official request to the WG chairs that they reconsider the stated position. That's the first step ... | In particular, the IPv6 WG will work to accomplish the following things in | parallel: | | (1) Publish an informational document that explains the issues | encountered with site-local addressing and our reasons | for deprecating IPv6 site-local unicast addresses. This | document will officially deprecate site-local addressing. | (2) Remove site-local unicast addressing from the IPv6 | scoped addressing architecture I-D, and publish the | parts of the document on which we do have consensus | (i.e., link local addresses, multicast, etc.). This | will include a note that the IPv6 working group is | investigating other forms of local IPv6 addressing and | that the usage of any new forms of local addresses will be | documented elsewhere. | (3) Update the IPv6 addressing architecture to indicate that the | usage of the FECO::/10 prefix for site-local addressing is | deprecated. To maintain backward compatibility with existing | implementations the prefix should be reserved and should not | be allocated for other purposes. Those three should be deferred until after some other solution has been found. After all, that solution may result in none of the above being required. | (4) Define and publish the requirements for a local addressing | mechanism to provide: | - Addresses for disconnected networks. | - Addresses for intermittently connected networks. | - Addresses that support merging of sites. | - Stable local addresses for changing ISPs without | disrupting local communication. | Once we have consensus on the requirements, the IPv6 | WG will work on solutions for local addressing that | meet those requirements. | | (5) Define and publish the requirements for a local access | control mechanism, then work on a solution that meets | those requirements. This is just fine, let the WG do just that. If something results which achieves all of what SL addressing accomplishes, with less imagined problems, then it will make sense to deprecate SL addressing, and you should find it fairly easy to obtain some kind of consensus to do that. If no-one is able to find a better solution, then we'll at least have one method for stable addressing which works (and even supports site merging if the sites planned ahead and didn't just use 0 in the upper 38 bits, but put some random number there, which is trivial to do). | We hope that people on all sides of this issue will respect the rough | consensus of the WG, Sorry, I cannot believe there is any even rough consensus here. Majority votes is not the way the IETF is supposed to operate. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 10 02:56:46 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 h3A9ujmh016000; Thu, 10 Apr 2003 02:56:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3A9ujGP015999; Thu, 10 Apr 2003 02:56:45 -0700 (PDT) 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 h3A9ugmh015992 for ; Thu, 10 Apr 2003 02:56:42 -0700 (PDT) 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 h3A9uovV006454 for ; Thu, 10 Apr 2003 02:56:50 -0700 (PDT) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id CAA01848 for ; Thu, 10 Apr 2003 02:56:45 -0700 (PDT) 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, 10 Apr 2003 09:56:44 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP; Thu, 10 Apr 2003 09:56:44 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Thu, 10 Apr 2003 09:56:43 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay12.sun.com with ESMTP; Thu, 10 Apr 2003 09:56:42 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3A9uR527035; Thu, 10 Apr 2003 16:56:28 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3A9u7Q12023; Thu, 10 Apr 2003 16:56:09 +0700 (ICT) From: Robert Elz To: Leif Johansson cc: alh-ietf@tndh.net, "'Thomas Narten'" , "'Erik Nordmark'" , ipng@sunroof.eng.sun.com Subject: Re: FW: Consensus on Site-Local Addressing In-Reply-To: <3E94FC4F.4070309@it.su.se> References: <3E94FC4F.4070309@it.su.se> <0f4201c2fef9$ef22eaf0$ee1a4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Apr 2003 16:56:07 +0700 Message-Id: <12021.1049968567@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Apr 2003 07:08:31 +0200 From: Leif Johansson Message-ID: <3E94FC4F.4070309@it.su.se> | Please note that the consensus call on the mailinglist explicitly called | for those that expressed their opinion during the show of hands at | the meeting _not_ to vote. That was a plain silly decision, if that's how it was done. No-one knows just who raised their hands in a WG meeting (I assume) - I doubt that there was even a very accurate count done. I wasn't at that meeting, but I've been at many others where similar things have been done - it is almost impossible to count raised hands, and I've never seen anyone attempt to make a list of who held up hands on each side of a debate. If one really wanted a vote (which I don't think is the correct answer anyway, for anything) the right way to do it on the list would be to ask everyone with an opinion to express it on the list. Then there would be a simple record, and everyone could add up the numbers and verify them. | But even so the numbers you quote | clearly does not constitute rough consensus for *keeping* site-locals, It has been previously ruled (and correctly I believe, though it was on a proposal I was making for a change) that a consensus is needed to change the architecture, not to retain it. in the absence of a consensus things should stay as they are. That's what seems to have happened here (even assuming the published numbers, that's not rough consensus). kre ps: Thomas, Eirk, I support Tony's appeal, I'll be making a similar one, assuming the chairs reject the request I have just made that they undo this bogus decision. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 03:15:46 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 h3AAFkmh016223; Thu, 10 Apr 2003 03:15:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AAFkak016222; Thu, 10 Apr 2003 03:15:46 -0700 (PDT) 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 h3AAFgmh016215 for ; Thu, 10 Apr 2003 03:15:42 -0700 (PDT) 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 h3AAFocU015992 for ; Thu, 10 Apr 2003 03:15:50 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id EAA19086 for ; Thu, 10 Apr 2003 04:15:43 -0600 (MDT) 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, 10 Apr 2003 10:15:41 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP; Thu, 10 Apr 2003 10:15:41 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP; Thu, 10 Apr 2003 10:15:41 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay2.sun.com with ESMTP; Thu, 10 Apr 2003 10:14:43 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3AADo528197; Thu, 10 Apr 2003 17:14:21 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3AADkQ12051; Thu, 10 Apr 2003 17:13:46 +0700 (ICT) From: Robert Elz To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: site-locals: a way out In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Apr 2003 17:13:46 +0700 Message-Id: <12049.1049969626@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 8 Apr 2003 23:10:35 +0200 (CEST) From: Erik Nordmark Message-ID: I have never considered the supposed security benefits of SL addressing to be anything worthy of even mention. If anything they seem to be a red herring that is so easy to shoot down, (to hook?) that it makes the case for SL addresses look weaker than it is. | The only issue is that I don't know how likely ISPs are to configure site | boundaries if they are not going to use site-locals themselves. If site locals aren't being used, then every router should be a site boundary. Site locals should only ever be forwarded by a router when site local addressing is in use on multiple interfaces, and they're all in the same site (having them default to all be in the same site when SL is configured makes sense - it is the usual case, so it makes life easier for most users - but if SL isn't being used, forwarding packets containing SL addresses makes no sense at all). That is, links without SL addressing should be regarded as being in a site of their own, unique from all other sites. I never even considered this as being in doubt, is this something that isn't clear in the specs? If so, that should certainly get fixed. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 10 03:30:02 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 h3AAU2mh016544; Thu, 10 Apr 2003 03:30:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AAU10Z016543; Thu, 10 Apr 2003 03:30:01 -0700 (PDT) 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 h3AATwmh016533 for ; Thu, 10 Apr 2003 03:29:58 -0700 (PDT) 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 h3AAU5cU018274 for ; Thu, 10 Apr 2003 03:30:05 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA27821 for ; Thu, 10 Apr 2003 03:30:00 -0700 (PDT) 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, 10 Apr 2003 10:29: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, 10 Apr 2003 10:29: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, 10 Apr 2003 10:29:59 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 10:29:57 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3AATo529240; Thu, 10 Apr 2003 17:29:50 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3AATUQ12080; Thu, 10 Apr 2003 17:29:31 +0700 (ICT) From: Robert Elz To: Tim Chown cc: "ipng@sunroof.eng.sun.com" Subject: Re: Is /32 enough? (was Re: Patrick Faltstrom...) In-Reply-To: <20030409232225.GF10290@login.ecs.soton.ac.uk> References: <20030409232225.GF10290@login.ecs.soton.ac.uk> <200304052043.PAA16343@ss10.danlan.com> <417230000.1049703524@localhost.besserwisser.org> <20030407093146.GS23732@login.ecs.soton.ac.uk> <758240000.1049782597@localhost.besserwisser.org> <20030408064836.GB19150@login.ecs.soton.ac.uk> <885020000.1049794189@localhost.besserwisser.org> <20030408101852.GC26495@login.ecs.soton.ac.uk> <20030408104946.GA27074@login.ecs.soton.ac.uk> <3E943144.62389568@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Apr 2003 17:29:30 +0700 Message-Id: <12078.1049970570@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Apr 2003 00:22:25 +0100 From: Tim Chown Message-ID: <20030409232225.GF10290@login.ecs.soton.ac.uk> | On Wed, Apr 09, 2003 at 04:42:12PM +0200, Brian E Carpenter wrote: | > | > Regardless, I wouldn't be shocked by a DFZ where a given ISP had multiple | > /29s if it grew really big. I do agree that ISPs need to have a sense | > that they can get as many of the 35 trillion /48s as they need. | | OK, so long as the ISP's know that and don't start rolling out with | dynamic prefixes... this would only increase clamour for site locals :( It is irrelevant. One of the big advantages of intermittent connections is that they can trivially be switched to any provider. It is highly reasonable for a site to use an ISP which specialises in business users, but use them only during their off peak periods (at night), and also use an ISP that specialises in home users, and use them during their off peak periods (during the day). Even if that doesn't result in lowered rates, it almost certainly results in better throughput, using the ISPs links when they're not as busy as they are when they're most used. But this results in 2 /48's - even if those two are stable, they're not consistently workable, and hosts need to know which one they can safely use right now. That could be done using some form of scoped addressing - but SL addresses are a better solution for that (since they're obvious), or it can be done by only advertising the address which actually works generally at the minute, which is what is likely to happen. So, now all the addresses in the site switch around at least twice a day - and there are probably periods during which neither works (neither is advertised) so some other addresses are needed. Nothing that comes from an ISP is, or ever will be, suitable for use for stable addresses - not even if the ISPs were selected as a distribution mechanism for PI addressing, there are too many issues to deal with. On the other hand, some address block, selected by the IETF, and labelled as available for stable addressing purposes (just like 1918 addresses) allows a site to have confidence that the addressing it is using for its internal communications will remain stable, and safe to use. What that prefix is doesn't really matter, it could be f000::/5 or E000:/4 or C000:/3 ... it could even be FEC0::/10. Then, when we have a block of addresses that work only locally within a site we can give them a nice easy to remember name to use to talk about them - maybe we call them "site local". kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 10 03:39: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 h3AAdsmh016821; Thu, 10 Apr 2003 03:39:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AAdrI8016820; Thu, 10 Apr 2003 03:39:53 -0700 (PDT) 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 h3AAdomh016811 for ; Thu, 10 Apr 2003 03:39:50 -0700 (PDT) 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 h3AAdvvV012889 for ; Thu, 10 Apr 2003 03:39:57 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA24441 for ; Thu, 10 Apr 2003 04:39:51 -0600 (MDT) 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, 10 Apr 2003 10:39: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; Thu, 10 Apr 2003 10:36: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; Thu, 10 Apr 2003 10:39:46 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 10:39:45 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3AAdb529824; Thu, 10 Apr 2003 17:39:38 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3AAd5Q12099; Thu, 10 Apr 2003 17:39:10 +0700 (ICT) From: Robert Elz To: Harald Tveit Alvestrand cc: Michel Py , "Charles E. Perkins" , ipng@sunroof.eng.sun.com Subject: Re: Globally Unique Private Addresses and Scoped Architecture In-Reply-To: <814670000.1049889353@askvoll.hjemme.alvestrand.no> References: <814670000.1049889353@askvoll.hjemme.alvestrand.no> <963621801C6D3E4A9CF454A1972AE8F504F754@server2000.arneill-py.sa cramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Apr 2003 17:39:05 +0700 Message-Id: <12097.1049971145@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 09 Apr 2003 13:55:53 +0200 From: Harald Tveit Alvestrand Message-ID: <814670000.1049889353@askvoll.hjemme.alvestrand.no> | when IPv4 customers come to their ISP and offer them money in order to | route RFC 1918 addresses to places the customer is not directly connected | to, we usually call the result a provider provisioned VPN. | | Demand seems widespread. Yes, this is fine, there's nothing wrong with this, and no reason not to support it. | So if we roll out globally unique non-routable addresses, we should not be | at all surprised to see that ISPs will actually route them if offered | enough money; it's simpler (and therefore cheaper) for them than | configuring a VPN. They don't need to be globally unique for this, just unique within the relevant domain (area). | (of course this only works in v4 if the two ends have coordinated their RFC | 1918 deplyment plans. There are a lot of cases when they do.) Yes, of course. And with SL addresses, with 2^38 different numbers to choose from (instead of the 256 + 16 + 1 in 1918 - plus subnets of those "classful" numbers) all it takes is sane guidance to make this trivial in all but the rarest/unlikiest circumstances, without even requiring co-ordination. If the ISPs can make this work for the customers, why would anyone want to stop them? That is, I have seen here in the past hour or so while I have been glancing at some of the past couple of days ipng list traffic, that people seem to be specifying "non-routable" as a goal. That's absurd, why would anyone explicitly want a non-routable address, even assuming that such a thing could be constructed? The goal is, or should be, that routability is not a requirement. That is, that we need some address space for which it can't be guaranteed that routing will work. As much as anyone chooses to make it work, for money, or for other reasons, that's just fine. But in the design of the address space, other attributes, like address stability, are more important, and we don't compromise those, at all, to assist with making the addresses routable. For what it is worth, this is exactly what FEC0::/10 gives us now. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 10 05:11:04 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 h3ACB4mh017336; Thu, 10 Apr 2003 05:11:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ACB4rg017335; Thu, 10 Apr 2003 05:11:04 -0700 (PDT) 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 h3ACB0mh017328 for ; Thu, 10 Apr 2003 05:11:00 -0700 (PDT) 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 h3ACB7vV024684 for ; Thu, 10 Apr 2003 05:11:07 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id FAA07957 for ; Thu, 10 Apr 2003 05:11:02 -0700 (PDT) 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, 10 Apr 2003 12:11:01 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP; Thu, 10 Apr 2003 12:11:01 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP; Thu, 10 Apr 2003 12:11:01 Z Received: from newdev.harvard.edu ([140.247.60.212] [140.247.60.212]) by relay1.sun.com with ESMTP; Thu, 10 Apr 2003 12:11:00 Z Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.7/8.12.2) with ESMTP id h3ACAw7X021057; Thu, 10 Apr 2003 08:10:58 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.7/8.12.2/Submit) id h3ACAvJc021056; Thu, 10 Apr 2003 08:10:57 -0400 (EDT) Date: Thu, 10 Apr 2003 08:10:57 -0400 (EDT) From: Scott Bradner Message-Id: <200304101210.h3ACAvJc021056@newdev.harvard.edu> To: alh-ietf@tndh.net, leifj@it.su.se Subject: Re: FW: Consensus on Site-Local Addressing Cc: erik.nordmark@Sun.COM, ipng@sunroof.eng.sun.com, narten@us.ibm.com In-Reply-To: <3E94FC4F.4070309@it.su.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But even so the numbers you quote > clearly does not constitute rough consensus for *keeping* site-locals, I would think that the issue is 'is there consensus to remove something that is currently in the spec' - i.e., the removal of an established feature needs strong support, the default is to keep it. (note that the above observation is not a comment on the specific question, it is comment on proper process in the IETF) Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 05:58: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 h3ACwhmh017773; Thu, 10 Apr 2003 05:58:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ACwgrn017772; Thu, 10 Apr 2003 05:58:42 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h3ACwcmh017765 for ; Thu, 10 Apr 2003 05:58:39 -0700 (PDT) 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 h3ACwbS29697; Thu, 10 Apr 2003 14:58:37 +0200 (MEST) Date: Thu, 10 Apr 2003 14:58:29 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: site-locals: a way out To: Robert Elz Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <12049.1049969626@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have never considered the supposed security benefits of SL > addressing to be anything worthy of even mention. If anything > they seem to be a red herring that is so easy to shoot down, > (to hook?) that it makes the case for SL addresses look weaker > than it is. While I personally agree with you, lots of folks have expressed this as a benefit of site-locals that we don't want to loose by removing site-locals. > That is, links without SL addressing should be regarded as being in > a site of their own, unique from all other sites. > > I never even considered this as being in doubt, is this something that > isn't clear in the specs? If so, that should certainly get fixed. I sure haven't read that explicitly in any spec, and I haven't even gotten that impression from reading between the lines. addr-arch says about *link*-locals: Routers must not forward any packets with link-local source or destination addresses to other links. And about site-locals: Routers must not forward any packets with site-local source or destination addresses outside of the site. If the intent is indeed as you assume, then IMHO the statement about site-locals above should be augmented to say: Routers must by default assume that each link consitutes a different site that is, require explicit configuration to make multiple links be part of the same site. As a result of this, routers by default must not forward any packets with site-local source or destination addresses to other links. But I have no idea whether this intent has WG consensus - I merely do not think the spec says what you think it should say. 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 Apr 10 06:03: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 h3AD3umh017839; Thu, 10 Apr 2003 06:03:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AD3uEh017838; Thu, 10 Apr 2003 06:03:56 -0700 (PDT) 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 h3AD3qmh017831 for ; Thu, 10 Apr 2003 06:03:52 -0700 (PDT) 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 h3AD40cU009513 for ; Thu, 10 Apr 2003 06:04:00 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA23033 for ; Thu, 10 Apr 2003 06:03:54 -0700 (PDT) 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, 10 Apr 2003 13:03: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; Thu, 10 Apr 2003 13:03:54 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, 10 Apr 2003 13:03:53 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, 10 Apr 2003 13:03:53 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA19217; Thu, 10 Apr 2003 06:03:07 -0700 (PDT) Message-Id: <5.1.0.14.2.20030410085108.0394ae30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Apr 2003 08:57:39 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: Consensus on Site-Local Addressing Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: <11997.1049967846@munnari.OZ.AU> References: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> <4.3.2.7.2.20030409150734.02f0ad58@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 Robert, >Without consensus for a change, the docs should stay as they are, >just as was done last time. What do you think it means for the documents to 'stay as they are'? Right now, we have three Internet-Drafts that define different options for the usage of site-local addressing. One is a WG I-D, the scoped addressing architecture, and two are individual. We established in Yokohama (Summer 2002) that there was no consensus to send the WG I-D, in its current form, to the IESG because of unresolved issues with site-local addressing. In Atlanta (fall 2002), we established that the WG did not have consensus to pursue the "full" usage model for site-locals currently documented in the WG I-D. In San Francisco (Spring 2003), it was quite clear that there is no WG consensus to pursue any of the other usage models for site-local ("moderate", "exclusive" or "limited"). So, I _think_ that leaving documents 'as they are' means leaving the prefix in the addressing architecture and allowing all of the I-Ds that specify any usage of it to expire as there is no consensus to advance any of them. Is that what you are proposing? Margaret > | There were also a significant number of the people on both sides of this > | issue that voiced (in their original responses, or in subsequent > messages) > | a strong belief that we should investigate alternative mechanisms for > local > | addressing and local access control. > >This is just fine, the WG can certainly do that. But the right thing >to do is to leave SL addressing in the spec now, until there is something >better to replace it. > >Why would anyone want to take something that works just fine, within its >scope of usefulness, and discard it, and then go looking for a mechanism >to achieve all the same functions as the first offers. What do we do >if after all that searching, we just return to where we are now? > > | The chairs have read all of the messages on the list, and based on your > | considerable input, we have determined that the IPv6 WG does have rough > | consensus to deprecate the usage of IPv6 site-local unicast > addressing AND > | to investigate alternative mechanisms for local addressing and local > access > | control. > >You can expect an appeal against the decision that there is rough >consensus here. What there is, is a debate. You can treat this >message as an official request to the WG chairs that they reconsider >the stated position. That's the first step ... > > | In particular, the IPv6 WG will work to accomplish the following > things in > | parallel: > | > | (1) Publish an informational document that explains the issues > | encountered with site-local addressing and our reasons > | for deprecating IPv6 site-local unicast addresses. This > | document will officially deprecate site-local addressing. > > | (2) Remove site-local unicast addressing from the IPv6 > | scoped addressing architecture I-D, and publish the > | parts of the document on which we do have consensus > | (i.e., link local addresses, multicast, etc.). This > | will include a note that the IPv6 working group is > | investigating other forms of local IPv6 addressing and > | that the usage of any new forms of local addresses will be > | documented elsewhere. > > | (3) Update the IPv6 addressing architecture to indicate that the > | usage of the FECO::/10 prefix for site-local addressing is > | deprecated. To maintain backward compatibility with existing > | implementations the prefix should be reserved and should not > | be allocated for other purposes. > >Those three should be deferred until after some other solution has >been found. After all, that solution may result in none of the above >being required. > > | (4) Define and publish the requirements for a local addressing > | mechanism to provide: > | - Addresses for disconnected networks. > | - Addresses for intermittently connected networks. > | - Addresses that support merging of sites. > | - Stable local addresses for changing ISPs without > | disrupting local communication. > | Once we have consensus on the requirements, the IPv6 > | WG will work on solutions for local addressing that > | meet those requirements. > | > | (5) Define and publish the requirements for a local access > | control mechanism, then work on a solution that meets > | those requirements. > >This is just fine, let the WG do just that. If something results which >achieves all of what SL addressing accomplishes, with less imagined >problems, then it will make sense to deprecate SL addressing, and you >should find it fairly easy to obtain some kind of consensus to do that. > >If no-one is able to find a better solution, then we'll at least have >one method for stable addressing which works (and even supports site >merging if the sites planned ahead and didn't just use 0 in the upper >38 bits, but put some random number there, which is trivial to do). > > | We hope that people on all sides of this issue will respect the rough > | consensus of the WG, > >Sorry, I cannot believe there is any even rough consensus here. >Majority votes is not the way the IETF is supposed to operate. > >kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 10 06:09: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 h3AD9Jmh018029; Thu, 10 Apr 2003 06:09:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AD9JT8018028; Thu, 10 Apr 2003 06:09:19 -0700 (PDT) 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 h3AD9Gmh018021 for ; Thu, 10 Apr 2003 06:09:16 -0700 (PDT) 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 h3AD9NvV003026 for ; Thu, 10 Apr 2003 06:09:23 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id GAA25605 for ; Thu, 10 Apr 2003 06:09:17 -0700 (PDT) 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, 10 Apr 2003 13:09: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; Thu, 10 Apr 2003 13:09: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; Thu, 10 Apr 2003 13:09:17 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; Thu, 10 Apr 2003 13:09:16 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3AD8vu9049758 for ; Thu, 10 Apr 2003 15:09:13 +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 h3AD8onk268828 for ; Thu, 10 Apr 2003 15:08:50 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42182 from ; Thu, 10 Apr 2003 15:08:49 +0200 Message-Id: <3E956D0D.95367286@hursley.ibm.com> Date: Thu, 10 Apr 2003 15:09:33 +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: Consensus on Site-Local Addressing References: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> <11997.1049967846@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd like to reply to kre that IMHO the chairs are perfectly entitled to declare a consensus on the basis of this straw poll. If you'd been following the debate, you would realise that there is in fact a large measure of agreement between the Nos and Yeses about the end goal (a workable solution for stable addressing for fully or intermittently disconnected sites). There's a smaller measure of disagreement about how the WG should proceed to find this solution. I don't think many of the people engaged in the debate want the final result to be today's SL definition. And given the way we use the word "deprecate" in standards, deprecating and reserving FEC0::/10 won't break anything that runs today, if we get Last Call consensus on doing so. All we have now is a declared consensus on a direction of work, and given the months of debate that led to this straw poll, I think we should respect the result. So I specifically request the chairs *not* to reconsider their stated position. Please maintain current course and speed. Brian Robert Elz wrote: > > Date: Wed, 09 Apr 2003 15:11:04 -0700 > From: Bob Hinden & Margaret Wasserman > Message-ID: <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> > > | All told, there were over 200 responses to the consensus call on IPv6 > | site-local addressing, approximately 3-to-1 in favor of deprecating IPv6 > | site-local unicast addressing. The final count (including the room and the > | mailing list) was: 155 YES, 56 NO (211 Total). > > As I just said in another message, I haven't been following what has been > going on here for some time, so I wasn't aware you were voting (which is > something the IETF doesn't normally do). > > You can add me to the "no" list. > > But 155 to 57 (or anything else like that) isn't consensus, or rough > consensus, for anything. It is lack of consensus. That's clear. > > What's more, on another issue, 8-9 months again, where there was a > similar ratio in favour of a change, the chairs ruled that there was > no consensus, and so the change wouldn't be made. Of course, that > was an issue where those opposed included one chair, and one AD, > and almost no-one else, so clearly there there could not be consensus > for a change could there? > > Without consensus for a change, the docs should stay as they are, > just as was done last time. > > | There were also a significant number of the people on both sides of this > | issue that voiced (in their original responses, or in subsequent messages) > | a strong belief that we should investigate alternative mechanisms for local > | addressing and local access control. > > This is just fine, the WG can certainly do that. But the right thing > to do is to leave SL addressing in the spec now, until there is something > better to replace it. > > Why would anyone want to take something that works just fine, within its > scope of usefulness, and discard it, and then go looking for a mechanism > to achieve all the same functions as the first offers. What do we do > if after all that searching, we just return to where we are now? > > | The chairs have read all of the messages on the list, and based on your > | considerable input, we have determined that the IPv6 WG does have rough > | consensus to deprecate the usage of IPv6 site-local unicast addressing AND > | to investigate alternative mechanisms for local addressing and local access > | control. > > You can expect an appeal against the decision that there is rough > consensus here. What there is, is a debate. You can treat this > message as an official request to the WG chairs that they reconsider > the stated position. That's the first step ... > > | In particular, the IPv6 WG will work to accomplish the following things in > | parallel: > | > | (1) Publish an informational document that explains the issues > | encountered with site-local addressing and our reasons > | for deprecating IPv6 site-local unicast addresses. This > | document will officially deprecate site-local addressing. > > | (2) Remove site-local unicast addressing from the IPv6 > | scoped addressing architecture I-D, and publish the > | parts of the document on which we do have consensus > | (i.e., link local addresses, multicast, etc.). This > | will include a note that the IPv6 working group is > | investigating other forms of local IPv6 addressing and > | that the usage of any new forms of local addresses will be > | documented elsewhere. > > | (3) Update the IPv6 addressing architecture to indicate that the > | usage of the FECO::/10 prefix for site-local addressing is > | deprecated. To maintain backward compatibility with existing > | implementations the prefix should be reserved and should not > | be allocated for other purposes. > > Those three should be deferred until after some other solution has > been found. After all, that solution may result in none of the above > being required. > > | (4) Define and publish the requirements for a local addressing > | mechanism to provide: > | - Addresses for disconnected networks. > | - Addresses for intermittently connected networks. > | - Addresses that support merging of sites. > | - Stable local addresses for changing ISPs without > | disrupting local communication. > | Once we have consensus on the requirements, the IPv6 > | WG will work on solutions for local addressing that > | meet those requirements. > | > | (5) Define and publish the requirements for a local access > | control mechanism, then work on a solution that meets > | those requirements. > > This is just fine, let the WG do just that. If something results which > achieves all of what SL addressing accomplishes, with less imagined > problems, then it will make sense to deprecate SL addressing, and you > should find it fairly easy to obtain some kind of consensus to do that. > > If no-one is able to find a better solution, then we'll at least have > one method for stable addressing which works (and even supports site > merging if the sites planned ahead and didn't just use 0 in the upper > 38 bits, but put some random number there, which is trivial to do). > > | We hope that people on all sides of this issue will respect the rough > | consensus of the WG, > > Sorry, I cannot believe there is any even rough consensus here. > Majority votes is not the way the IETF is supposed to operate. > > kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 10 06:15: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 h3ADFhmh018430; Thu, 10 Apr 2003 06:15:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ADFhqJ018429; Thu, 10 Apr 2003 06:15:43 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h3ADFcmh018416 for ; Thu, 10 Apr 2003 06:15:39 -0700 (PDT) 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 h3ADFhS00592; Thu, 10 Apr 2003 15:15:43 +0200 (MEST) Date: Thu, 10 Apr 2003 15:15:35 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Globally Unique Private Addresses and Scoped Architecture To: Dan Lanciani Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200304092233.SAA09330@ss10.danlan.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > IMHO, it is impossible to reduce the risk as stated. That is, we might be > able to prevent but > that isn't quite the same thing. Once we have any globally unique ownable > address space we can make it not-private with auto-tunnels analogous to those > used for 6to4. All that is required is agreement on a lookup mechanism, and > I believe that the desire for PI space is strong enough to produce such an > agreement in the market regardless of what the IETF may do. Now, I happen to Dan, In my head this "lookup mechanism for auto-tunneling" is merely a different way of stating that we need to separate identifiers and locators and have a lookup mechanism to map from an identifier to a (set of) locator(s). If that's what you mean I agree with it, and I think the IETF can gather enough ideas to be able to engineer a reasonable solution to this problem. One question I have is whether we today know enough to know what the structure should be of the identifier or whether the desired structure of the identifier depends on what type of lookup system we design. I'm concerned about defining the globally-unique-globally-visible-in-the-routing-table format until we at least know that we can build a scalable and robust lookup function for it. 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 Apr 10 06:17: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 h3ADHQmh018513; Thu, 10 Apr 2003 06:17:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ADHPN4018512; Thu, 10 Apr 2003 06:17:25 -0700 (PDT) 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 h3ADHMmh018502 for ; Thu, 10 Apr 2003 06:17:22 -0700 (PDT) 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 h3ADHTvV004727 for ; Thu, 10 Apr 2003 06:17:29 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id GAA29488 for ; Thu, 10 Apr 2003 06:17:23 -0700 (PDT) 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, 10 Apr 2003 13:17: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; Thu, 10 Apr 2003 13:17: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; Thu, 10 Apr 2003 13:17:22 Z Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 13:17:21 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3ADEgDI058764; Thu, 10 Apr 2003 15:17:12 +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 h3ADEWnk290548; Thu, 10 Apr 2003 15:14:36 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA29576 from ; Thu, 10 Apr 2003 15:14:29 +0200 Message-Id: <3E956E61.B0F9AF3D@hursley.ibm.com> Date: Thu, 10 Apr 2003 15:15:13 +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: "'Thomas Narten'" , "'Erik Nordmark'" Cc: ipng@sunroof.eng.sun.com Subject: Re: FW: Consensus on Site-Local Addressing References: <0f4201c2fef9$ef22eaf0$ee1a4104@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk See my comments on the list in response to Robert Elz for why I think this appeal is misguided. I think we should just get on with the work at this point. Anything else is a distraction and ultimately harmful to IPv6. Brian Tony Hain wrote: > > Thomas & Erik, > > Please consider this the second step in the appeal process, as I have > already discussed these issues with the chairs on more than one > occasion. > > 'we reject kings, presidents and voting...' > The consensus measurement on the mail list was much more indicative of > the real lack of it (60/40%), than what was effectively ballot stuffing > by WG visitors without a complete context. There was a very short > presentation in the apps open area, intended to raise concerns and > incite involvement, were those in the apps area were agitated, then > invited to the IPv6 WG session in SF to discuss the potential issues. > The subsequent short discussion in the IPv6 WG showed there were issues > to work through, and at least one question voiced about understanding > the requirements. Rather than deal with the issues raised, the chairs > decided to call an ambiguous question of yes/no for deprecation. > > While the chairs do in 2) recognize their interpretation of the > consensus that the WG will investigate other forms of local addressing, > there is no mention of ambiguity and the rest of the wording of 1) & 2) > can be interpreted as local scope addressing is deprecated. The concern > is that we will end up with a document lacking local scope addressing, > and claims that we had consensus to remove local scope from the > architecture. Many of those who bothered to state why they were > expressing a yes opinion claimed ambiguity was the reason, while others > were only interested in removing special handling for local scope > addresses. Those are technically different issues, so they need > different questions. What we have is an indication that many are unhappy > with the status quo, but a lack of recognition that the call ended up > combining yes opinions for removing ambiguity with yes opinions for > removing local scope addresses from the architecture. From subsequent > discussions with the chairs, it is clear that was not their intent, but > never the less that is the result of the lack of clarity in this > consensus call. > > '... we believe in rough consensus & running code' & from the Tao : > 'running code wins' > On several related mail threads there were many comments about running > code, and at least Brian Zill & Brian Haberman said they collectively > had host, application, and router implementations of the current SL > running. Point 3) even acknowledges there are existing implementations. > This consensus call intends to invalidate the running code, and all we > have to replace it is a promise in 4) that if the group can ever agree > that operational requirements of the site network manager are worth > solving, we might start to work on solutions, subject to appropriate > charter updates. This whole discussion is based on the argument that > some developers couldn't create running code for an arguably bogus > scenario where topology locators are blindly passed outside their scope > of relevance. Bias was given to the opinions of those with a lack of > running code, at the expense of, and with the specific intent of > invalidating the code that exists. > > There were also claims in the meeting and mail threads that we have > analyzed site local as currently defined, and it doesn't meet the > requirements. At the same time, there is a recognition by many of the > same people that we need to develop a complete set of requirements. It > should be obvious that the analysis is flawed if the complete set of > requirements are not understood first. To that end, and in the spirit of > making progress, draft-hain-ipv6-sitelocal-00.txt was processed by the > I-D editor on 4/8, and is offered as an attempt to document the > requirements for address space with a local scope of relevance. It is > clearly incomplete, and largely based on my previous email on the > subject. > > While I contest the claim that the Yes/No opinions expressed measured > consensus for a consistent interpretation of what 'deprecate site local > addresses' means, I do believe that a set of work items for the group > were identified. It is also clear that we can add new work to a group at > any time, without the need to remove existing items first. I agree with > the chairs that items 4) & 5) are valid outcomes of the subsequent > discussion, though one thing that their interpretation of the result > does not make clear is the meaning of 'accomplish the following things > in parallel:'. In talking to the chairs it appears the intent is to > start the work at the same time, but we need to avoid invalid transition > states, so parallel needs to mean that all 5 are to be forwarded to the > IESG at one time. In particular, without solutions to the requirements > in hand, any documents for 1) & 3) that intend to deprecate the only > local use address space will simply create chaos, and might need to be > rescinded if the complete set of requirements shows a need with no other > technical approach. > > In short, I do not believe the consensus call measured the opinions that > were consistent the chairs interpretation of the question, so the > claimed results are invalid. I do believe that the effort identified > work items 4) & 5), with the potential that 1) & 3) might follow if > there are no outstanding requirements for ambiguous address space. I > question the wisdom of 2), but will reserve judgment until the complete > text identifying further work is spelled out. In any case, I hope this > appeal can be dealt with at this level, and that the overall effort > results in an expedited charter update. It is imperative that new > approaches exist prior to removal of the current, and there is a very > real danger that the current destructive energy will dissipate in the > face of the hard work of creating replacements. > > Tony > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Bob > > Hinden & Margaret Wasserman > > Sent: Wednesday, April 09, 2003 3:11 PM > > To: ipng@sunroof.eng.sun.com > > Subject: Consensus on Site-Local Addressing > > > > > > Hi All, > > > > Well, that was fun! :-) > > > > All told, there were over 200 responses to the consensus call on IPv6 > > site-local addressing, approximately 3-to-1 in favor of > > deprecating IPv6 > > site-local unicast addressing. The final count (including > > the room and the > > mailing list) was: 155 YES, 56 NO (211 Total). > > > > There were also a significant number of the people on both > > sides of this > > issue that voiced (in their original responses, or in > > subsequent messages) > > a strong belief that we should investigate alternative > > mechanisms for local > > addressing and local access control. > > > > The chairs have read all of the messages on the list, and > > based on your > > considerable input, we have determined that the IPv6 WG does > > have rough > > consensus to deprecate the usage of IPv6 site-local unicast > > addressing AND > > to investigate alternative mechanisms for local addressing > > and local access > > control. > > > > In particular, the IPv6 WG will work to accomplish the > > following things in > > parallel: > > > > (1) Publish an informational document that explains the issues > > encountered with site-local addressing and our reasons > > for deprecating IPv6 site-local unicast addresses. This > > document will officially deprecate site-local addressing. > > > > (2) Remove site-local unicast addressing from the IPv6 > > scoped addressing architecture I-D, and publish the > > parts of the document on which we do have consensus > > (i.e., link local addresses, multicast, etc.). This > > will include a note that the IPv6 working group is > > investigating other forms of local IPv6 addressing and > > that the usage of any new forms of local addresses will be > > documented elsewhere. > > > > (3) Update the IPv6 addressing architecture to indicate that the > > usage of the FECO::/10 prefix for site-local addressing is > > deprecated. To maintain backward compatibility with existing > > implementations the prefix should be reserved and should not > > be allocated for other purposes. > > > > (4) Define and publish the requirements for a local addressing > > mechanism to provide: > > - Addresses for disconnected networks. > > - Addresses for intermittently connected networks. > > - Addresses that support merging of sites. > > - Stable local addresses for changing ISPs without > > disrupting local communication. > > Once we have consensus on the requirements, the IPv6 > > WG will work on solutions for local addressing that > > meet those requirements. > > > > (5) Define and publish the requirements for a local access > > control mechanism, then work on a solution that meets > > those requirements. > > > > Each of these new work items will need to be added to the > > IPv6 WG charter > > and will go through the normal IETF document processes. For > > (4) and (5) it > > is important to make the rest of the IETF community aware > > that the IPv6 WG > > is undertaking these tasks, so we will consider methods to > > invite wider > > review and discussion of these problems. > > > > IPv6 site-local addressing has been a contentious issue in > > the IPv6 WG for > > some time, and we are both glad to see the WG reach consensus on this > > issue. This will allow us to complete and publish the IPv6 scoped > > addressing architecture document, an important part of the > > IPv6 specification. > > > > We hope that people on all sides of this issue will respect the rough > > consensus of the WG, and will work with us to achieve the > > goals outlined above. > > > > Thanks to everyone who expressed an opinion during this discussion. > > > > Bob Hinden & Margaret Wasserman > > IPv6 WG Chairs > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 06:31: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 h3ADVtmh019224; Thu, 10 Apr 2003 06:31:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ADVt3f019223; Thu, 10 Apr 2003 06:31:55 -0700 (PDT) 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 h3ADVqmh019216 for ; Thu, 10 Apr 2003 06:31:52 -0700 (PDT) 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 h3ADVxvV007496 for ; Thu, 10 Apr 2003 06:31:59 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id HAA08245 for ; Thu, 10 Apr 2003 07:31:52 -0600 (MDT) 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, 10 Apr 2003 13:31:49 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, 10 Apr 2003 13:31: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; Thu, 10 Apr 2003 13:31:49 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; Thu, 10 Apr 2003 13:31:48 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3ADVkDI049646 for ; Thu, 10 Apr 2003 15:31:46 +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 h3ADUUom245462 for ; Thu, 10 Apr 2003 15:30:30 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA21524 from ; Thu, 10 Apr 2003 15:30:28 +0200 Message-Id: <3E957221.254CD6D5@hursley.ibm.com> Date: Thu, 10 Apr 2003 15:31:13 +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: IPv6 Subject: C000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Let's be constructive and ignore distractions like appeals. Let's also assume that item (4) ["requirements for a local addressing mechanism"] in the chairs' work list is relatively straightfoward and obvious. Assume that we consider stable, probably unique, unrouteable prefixes important enough to get their own 3-bit prefix, and for the sake of argument let's pick C000::/3. Further assume that we want to generate /48s. Then the problem to solve is generating probably unique 45 bit numbers easily and essentially free of charge. That's clearly possible in several ways, so let's not debate details. Therefore, assume we have a way of generating such prefixes under C000::/3. What are they going to do to the scoped architecture? Will applications need to treat them any differently from 2000::/3? 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 Apr 10 06:59:14 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 h3ADxEmh019674; Thu, 10 Apr 2003 06:59:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ADxDe1019673; Thu, 10 Apr 2003 06:59:13 -0700 (PDT) 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 h3ADxAmh019666 for ; Thu, 10 Apr 2003 06:59:10 -0700 (PDT) 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 h3ADxHcU023438 for ; Thu, 10 Apr 2003 06:59:17 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id HAA23598 for ; Thu, 10 Apr 2003 07:59:12 -0600 (MDT) 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, 10 Apr 2003 13:59:11 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, 10 Apr 2003 13:59: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, 10 Apr 2003 13:59:11 Z Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 13:59:10 Z Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h3ADxAo21359; Thu, 10 Apr 2003 06:59:10 -0700 Received: from innovationslab.net ([63.109.132.2]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h3AEEhQe005723 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 10 Apr 2003 07:14:46 -0700 Message-Id: <3E9578A9.1080003@innovationslab.net> Date: Thu, 10 Apr 2003 09:59:05 -0400 From: Brian Haberman 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: Brian E Carpenter CC: IPv6 Subject: Re: C000 References: <3E957221.254CD6D5@hursley.ibm.com> In-Reply-To: <3E957221.254CD6D5@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: > Let's be constructive and ignore distractions like appeals. > Let's also assume that item (4) ["requirements for a local > addressing mechanism"] in the chairs' work list is relatively > straightfoward and obvious. > > Assume that we consider stable, probably unique, > unrouteable prefixes important enough to get their own 3-bit > prefix, and for the sake of argument let's pick C000::/3. > > Further assume that we want to generate /48s. > > Then the problem to solve is generating probably unique 45 bit > numbers easily and essentially free of charge. That's clearly possible > in several ways, so let's not debate details. > > Therefore, assume we have a way of generating such prefixes under C000::/3. Assumption made. :) > > What are they going to do to the scoped architecture? I believe the scoped addr arch will have to contain rules that specify how the prefixes are delineated. That is, if the prefixes don't match, they are in different sites. The process doing this comparison will then have to determine what action is needed for the mis-match (e.g. routing protocols will not advertise the both prefixes out the same interface). > Will applications need to treat them any differently from 2000::/3? I think so. In the 3rd-party referral case, an app will have to do the check mentioned above before sending a referral. 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 Thu Apr 10 07:15: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 h3AEFNmh020019; Thu, 10 Apr 2003 07:15:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AEFNXG020018; Thu, 10 Apr 2003 07:15:23 -0700 (PDT) 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 h3AEFKmh020011 for ; Thu, 10 Apr 2003 07:15:20 -0700 (PDT) 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 h3AEFRvV015778 for ; Thu, 10 Apr 2003 07:15:27 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA03341 for ; Thu, 10 Apr 2003 08:15:21 -0600 (MDT) 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, 10 Apr 2003 14:15: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, 10 Apr 2003 14:11:48 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, 10 Apr 2003 14:15:21 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, 10 Apr 2003 14:15:20 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA20757; Thu, 10 Apr 2003 07:14:43 -0700 (PDT) Message-Id: <5.1.0.14.2.20030410100611.03949e28@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Apr 2003 10:13:11 -0400 To: Brian Haberman From: Margaret Wasserman Subject: Re: C000 Cc: Brian E Carpenter , IPv6 In-Reply-To: <3E9578A9.1080003@innovationslab.net> References: <3E957221.254CD6D5@hursley.ibm.com> <3E957221.254CD6D5@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>What are they going to do to the scoped architecture? > >I believe the scoped addr arch will have to contain rules >that specify how the prefixes are delineated. That is, if >the prefixes don't match, they are in different sites. The >process doing this comparison will then have to determine what >action is needed for the mis-match (e.g. routing protocols will >not advertise the both prefixes out the same interface). Why? If local addresses are not ambiguous, there is no reason why "sites" can't overlap (i.e. one interface could be in two different "sites"). BTW, I think we may want to reconsider the use of the term "site" -- I'm not sure what term to use instead, though. >>Will applications need to treat them any differently from 2000::/3? > >I think so. In the 3rd-party referral case, an app will have to do >the check mentioned above before sending a referral. Or, we need to make sure that apps don't get local addresses unless they explicitly ask for them. This could be achieved by a combination of Mark Andrew's proposal for putting local addresses in the DNS, and some API changes to only return the largest scoped address(es) available, unless an app explicitly asks for addresses with lesser scope. 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 Apr 10 07:27: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 h3AERbmh020280; Thu, 10 Apr 2003 07:27:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AERbfo020279; Thu, 10 Apr 2003 07:27:37 -0700 (PDT) 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 h3AERYmh020272 for ; Thu, 10 Apr 2003 07:27:34 -0700 (PDT) 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 h3AERfcU029769 for ; Thu, 10 Apr 2003 07:27:41 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id HAA09181 for ; Thu, 10 Apr 2003 07:27:36 -0700 (PDT) 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, 10 Apr 2003 14:27: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, 10 Apr 2003 14:27: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, 10 Apr 2003 14:27:35 Z Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 14:27:35 Z Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h3AERYo21462; Thu, 10 Apr 2003 07:27:34 -0700 Received: from innovationslab.net ([63.109.132.2]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h3AEhAQe005834 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 10 Apr 2003 07:43:11 -0700 Message-Id: <3E957F54.4050102@innovationslab.net> Date: Thu, 10 Apr 2003 10:27:32 -0400 From: Brian Haberman 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: Margaret Wasserman CC: Brian E Carpenter , IPv6 Subject: Re: C000 References: <3E957221.254CD6D5@hursley.ibm.com> <3E957221.254CD6D5@hursley.ibm.com> <5.1.0.14.2.20030410100611.03949e28@mail.windriver.com> In-Reply-To: <5.1.0.14.2.20030410100611.03949e28@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > > >>> What are they going to do to the scoped architecture? >> >> >> I believe the scoped addr arch will have to contain rules >> that specify how the prefixes are delineated. That is, if >> the prefixes don't match, they are in different sites. The >> process doing this comparison will then have to determine what >> action is needed for the mis-match (e.g. routing protocols will >> not advertise the both prefixes out the same interface). > > > Why? If local addresses are not ambiguous, there is no reason > why "sites" can't overlap (i.e. one interface could be in two > different "sites"). I didn't consider overlapping sites in my response. Of course, if they are not ambiguous they could be globally routed... > BTW, I think we may want to reconsider the > use of the term "site" -- I'm not sure what term to use > instead, though. Don't know what term would be appropriate. > >>> Will applications need to treat them any differently from 2000::/3? >> >> >> I think so. In the 3rd-party referral case, an app will have to do >> the check mentioned above before sending a referral. > > > Or, we need to make sure that apps don't get local addresses > unless they explicitly ask for them. This could be achieved by > a combination of Mark Andrew's proposal for putting local > addresses in the DNS, and some API changes to only return the > largest scoped address(es) available, unless an app explicitly > asks for addresses with lesser scope. If we allow overlapping sites and the addresses are near-unique, the apps may not even care. I seem to be guessing since there isn't any context around these addresses to describe their properties. 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 Apr 10 08:12:12 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 h3AFCBmh020703; Thu, 10 Apr 2003 08:12:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AFCBZI020702; Thu, 10 Apr 2003 08:12:11 -0700 (PDT) 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 h3AFC8mh020695 for ; Thu, 10 Apr 2003 08:12:08 -0700 (PDT) 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 h3AFCFcU009522 for ; Thu, 10 Apr 2003 08:12:15 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id JAA14272 for ; Thu, 10 Apr 2003 09:12:03 -0600 (MDT) 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, 10 Apr 2003 15:11: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; Thu, 10 Apr 2003 15:11: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, 10 Apr 2003 15:11:52 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; Thu, 10 Apr 2003 15:11:50 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3AFBbUm071114; Thu, 10 Apr 2003 17:11:38 +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 h3AFBYom238196; Thu, 10 Apr 2003 17:11:35 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42652 from ; Thu, 10 Apr 2003 17:11:30 +0200 Message-Id: <3E9589CE.6F4B1F6@hursley.ibm.com> Date: Thu, 10 Apr 2003 17:12:14 +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: Brian Haberman Cc: Margaret Wasserman , IPv6 Subject: Re: C000 References: <3E957221.254CD6D5@hursley.ibm.com> <3E957221.254CD6D5@hursley.ibm.com> <5.1.0.14.2.20030410100611.03949e28@mail.windriver.com> <3E957F54.4050102@innovationslab.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk below... Brian Haberman wrote: > > Margaret Wasserman wrote: > > > > > >>> What are they going to do to the scoped architecture? > >> > >> > >> I believe the scoped addr arch will have to contain rules > >> that specify how the prefixes are delineated. That is, if > >> the prefixes don't match, they are in different sites. The > >> process doing this comparison will then have to determine what > >> action is needed for the mis-match (e.g. routing protocols will > >> not advertise the both prefixes out the same interface). > > > > > > Why? If local addresses are not ambiguous, there is no reason > > why "sites" can't overlap (i.e. one interface could be in two > > different "sites"). > > I didn't consider overlapping sites in my response. Of course, > if they are not ambiguous they could be globally routed... > > > BTW, I think we may want to reconsider the > > use of the term "site" -- I'm not sure what term to use > > instead, though. > > Don't know what term would be appropriate. > > > > >>> Will applications need to treat them any differently from 2000::/3? > >> > >> > >> I think so. In the 3rd-party referral case, an app will have to do > >> the check mentioned above before sending a referral. > > > > > > Or, we need to make sure that apps don't get local addresses > > unless they explicitly ask for them. This could be achieved by > > a combination of Mark Andrew's proposal for putting local > > addresses in the DNS, and some API changes to only return the > > largest scoped address(es) available, unless an app explicitly > > asks for addresses with lesser scope. > > If we allow overlapping sites and the addresses are near-unique, > the apps may not even care. > > I seem to be guessing since there isn't any context around these > addresses to describe their properties. Indeed, we need to define their properties to meet the requirements, when we've agreed on them. My point was really to check whether we still have scoping issues and the answer seems to be yes. However, I think during the recent debates it was pointed out that many sites will choose to treat some of their normal (PA) address space as private, simply by not routing it externally. So the referral issue will arise there too. 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 Apr 10 08:19:10 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 h3AFJ9mh020972; Thu, 10 Apr 2003 08:19:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AFJ95N020971; Thu, 10 Apr 2003 08:19:09 -0700 (PDT) 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 h3AFJ5mh020960 for ; Thu, 10 Apr 2003 08:19:06 -0700 (PDT) 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 h3AFJDcU011485 for ; Thu, 10 Apr 2003 08:19:13 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA14530 for ; Thu, 10 Apr 2003 09:19:07 -0600 (MDT) 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, 10 Apr 2003 15:19: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; Thu, 10 Apr 2003 15:15: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; Thu, 10 Apr 2003 15:19:06 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, 10 Apr 2003 15:19:05 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA25398; Thu, 10 Apr 2003 08:18:27 -0700 (PDT) Message-Id: <5.1.0.14.2.20030410110944.046ca878@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Apr 2003 11:16:56 -0400 To: Brian Haberman From: Margaret Wasserman Subject: Re: C000 Cc: Brian E Carpenter , IPv6 In-Reply-To: <3E957F54.4050102@innovationslab.net> References: <5.1.0.14.2.20030410100611.03949e28@mail.windriver.com> <3E957221.254CD6D5@hursley.ibm.com> <3E957221.254CD6D5@hursley.ibm.com> <5.1.0.14.2.20030410100611.03949e28@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 At 10:27 AM 4/10/2003 -0400, Brian Haberman wrote: >If we allow overlapping sites and the addresses are near-unique, >the apps may not even care. > >I seem to be guessing since there isn't any context around these >addresses to describe their properties. Me, too. That's why I think we should start by trying to figure out what our requirements are for local addressing -- or at least what the problems statement is... Then, we can try to figure out what type of addressing and/or other mechanisms can be used to meet those needs with the fewest limitations, the least complexity and the lowest impact on other parts of the protocols stack. I'm not sure where to start, though... From my perspective, the primary need is for addresses to use on disconnected networks. However, other people have stated other requirements for local addressing -- addressing for intermittently connected networks, allowing local connections to survive global prefix renumbering, local access control, handling site merges, etc. People have also offered constraints -- shouldn't require changes to existing applications, etc. I think that these things may need more details added before we can understand if any (combination of) mechanism(s) can meet the requirements and stay within the constraints. In some cases, we may find that there are conflicting requirements and constraints, and we will need to make trade-offs. 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 Apr 10 08:24: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 h3AFOjmh021161; Thu, 10 Apr 2003 08:24:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AFOjYU021160; Thu, 10 Apr 2003 08:24:45 -0700 (PDT) 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 h3AFOfmh021148 for ; Thu, 10 Apr 2003 08:24:41 -0700 (PDT) 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 h3AFOmvV001212 for ; Thu, 10 Apr 2003 08:24:48 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA15072 for ; Thu, 10 Apr 2003 09:24:43 -0600 (MDT) 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, 10 Apr 2003 15:23: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; Thu, 10 Apr 2003 15:23: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; Thu, 10 Apr 2003 15:23:54 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; Thu, 10 Apr 2003 15:23: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 IAA14904; Thu, 10 Apr 2003 08:23:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3AFNq003522; Thu, 10 Apr 2003 08:23:52 -0700 X-mProtect: <200304101523> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdE6I5jM; Thu, 10 Apr 2003 08:23:50 PDT Message-Id: <3E958CAD.5050407@iprg.nokia.com> Date: Thu, 10 Apr 2003 08:24:29 -0700 From: Charlie Perkins Organization: Nokia 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: Robert Elz CC: ipng@sunroof.eng.sun.com Subject: Re: Globally Unique Private Addresses and Scoped Architecture References: <814670000.1049889353@askvoll.hjemme.alvestrand.no> <963621801C6D3E4A9CF454A1972AE8F504F754@server2000.arneill-py.sa cramento.ca.us> <12097.1049971145@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Robert, Robert Elz wrote: > > | So if we roll out globally unique non-routable addresses, we should not be > | at all surprised to see that ISPs will actually route them if offered > | enough money; it's simpler (and therefore cheaper) for them than > | configuring a VPN. > >They don't need to be globally unique for this, just unique within the >relevant domain (area). > But global uniqueness means we don't need scoping in the (unicast) address architecture. It means that scoping can be done as part of route table management instead. I thought that was the point of the exercise (or at least one important point). > ........... that people seem to >be specifying "non-routable" as a goal. That's absurd, why would anyone >explicitly want a non-routable address, even assuming that such a thing >could be constructed? > I think we need addresses that are not allowed to be "globally routable", but are still unique. I certainly agree that these addresses should still be routable according to the needs of the local administration. To be precise, though, we do want non-routable addresses too; they're the link-local addresses. 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 Thu Apr 10 08:38:48 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 h3AFcmmh021733; Thu, 10 Apr 2003 08:38:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AFclw9021732; Thu, 10 Apr 2003 08:38:47 -0700 (PDT) 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 h3AFcimh021725 for ; Thu, 10 Apr 2003 08:38:44 -0700 (PDT) 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 h3AFcpvV005318 for ; Thu, 10 Apr 2003 08:38:51 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA26947 for ; Thu, 10 Apr 2003 09:38:22 -0600 (MDT) 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, 10 Apr 2003 15:36: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; Thu, 10 Apr 2003 15:36: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; Thu, 10 Apr 2003 15:36:29 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; Thu, 10 Apr 2003 15:36:29 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA04850; Thu, 10 Apr 2003 08:35:50 -0700 (PDT) Message-Id: <5.1.0.14.2.20030410111815.046d8de0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Apr 2003 11:33:06 -0400 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: C000 Cc: Brian Haberman , IPv6 In-Reply-To: <3E9589CE.6F4B1F6@hursley.ibm.com> References: <3E957221.254CD6D5@hursley.ibm.com> <3E957221.254CD6D5@hursley.ibm.com> <5.1.0.14.2.20030410100611.03949e28@mail.windriver.com> <3E957F54.4050102@innovationslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, At 05:12 PM 4/10/2003 +0200, Brian E Carpenter wrote: >Indeed, we need to define their properties to meet the requirements, >when we've agreed on them. My point was really to check whether we >still have scoping issues and the answer seems to be yes. However, >I think during the recent debates it was pointed out that many >sites will choose to treat some of their normal (PA) address space >as private, simply by not routing it externally. So the referral >issue will arise there too. Yes, applications do have to deal with addresses that are unreachable. Even if we group the "local" addresses into a single prefix, applications will still need to handle it when global address/port combinations are filtered/firewalled. I'm not sure that it is possible, but I hope that we can come up with a local addressing scheme that does not require hosts to include any special handling for local addresses (at any layer of the protocol stack). I think that this may be possible using globally unique local addresses, specifying some DNS enhancements (like Mark Andrew's proposal, perhaps) that make it possible for applications/stacks to control when they might receive local addresses, and relying on the longest match rule in the address selection rules to generally match local addresses with local address and globals with globals. But, I really need to understand the goals better before I can be sure. I'm fairly certain that something more complex will be needed in the intermittently-connected case, but I'm hoping that we can come up with optional mechanisms for those type of networks that won't be required for all implementations. I also understand that there is some interesting work going on in this area in the nemo WG, but I haven't check that out yet. 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 Apr 10 09:01: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 h3AG1Kmh022162; Thu, 10 Apr 2003 09:01:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AG1KKd022161; Thu, 10 Apr 2003 09:01:20 -0700 (PDT) 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 h3AG1Hmh022150 for ; Thu, 10 Apr 2003 09:01:17 -0700 (PDT) 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 h3AG1OvV012415 for ; Thu, 10 Apr 2003 09:01:24 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA22038 for ; Thu, 10 Apr 2003 10:01:18 -0600 (MDT) 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, 10 Apr 2003 16:01:18 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP; Thu, 10 Apr 2003 16:01:18 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP; Thu, 10 Apr 2003 16:01:17 Z Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by relay2.sun.com with ESMTP; Thu, 10 Apr 2003 16:01:17 Z Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3AG1Ggl075188; Thu, 10 Apr 2003 12:01:16 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3AFxvtu235200; Thu, 10 Apr 2003 09:59:58 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.5/8.12.5) with ESMTP id h3AFuQem032144; Thu, 10 Apr 2003 11:56:26 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h3AFuM0r032139; Thu, 10 Apr 2003 11:56:26 -0400 Message-Id: <200304101556.h3AFuM0r032139@rotala.raleigh.ibm.com> To: alh-ietf@tndh.net cc: "'Erik Nordmark'" , ipng@sunroof.eng.sun.com Subject: Re: FW: Consensus on Site-Local Addressing In-Reply-To: Message from alh-ietf@tndh.net of "Wed, 09 Apr 2003 17:41:32 PDT." <0f4201c2fef9$ef22eaf0$ee1a4104@eagleswings> Date: Thu, 10 Apr 2003 11:56:22 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, > Please consider this the second step in the appeal process, as I have > already discussed these issues with the chairs on more than one > occasion. Discussing general issues with the chairs is not the same as finding disagreement with a specific action that the chairs have taken. I suspect you have done the former, but not the latter. If you feel that the chairs have erred, and that they have taken an action that isn't supported by the processes as outlined in RFC 2026 (and RFC 2418), an appeal might be warranted. To file an appeal, the process is outlined in RFC 2026. Start with the chairs, use RFC 2026/2418 as a guide for what are appropriate grounds for an appeal, and be clear about what action (or inaction) you specifically have issue with and want reconsidered. Suggesting what remedy you believe is appropriate would also be useful. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 10 10:03: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 h3AH3Omh022804; Thu, 10 Apr 2003 10:03:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AH3OHb022803; Thu, 10 Apr 2003 10:03:24 -0700 (PDT) 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 h3AH3Kmh022796 for ; Thu, 10 Apr 2003 10:03:20 -0700 (PDT) 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 h3AH3ScU012100 for ; Thu, 10 Apr 2003 10:03:28 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA02559 for ; Thu, 10 Apr 2003 11:03:22 -0600 (MDT) 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, 10 Apr 2003 17:03: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, 10 Apr 2003 16:59: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, 10 Apr 2003 17:03:20 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 17:03:20 Z Content-class: urn:content-classes:message Subject: RE: Globally Unique Private Addresses and Scoped Architecture Date: Thu, 10 Apr 2003 10:01:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F5045705@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: Globally Unique Private Addresses and Scoped Architecture Thread-Index: AcL/dg587eTqwaWjQEeln+o4QBBXtAADHWGw From: "Michel Py" To: "Charlie Perkins" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3AH3Lmh022797 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, > Charlie Perkins wrote: > But global uniqueness means we don't need scoping in the > (unicast) address architecture. It means that scoping can > be done as part of route table management instead. Can you give some precisions about this? > I think we need addresses that are not allowed to be > "globally routable", but are still unique. I certainly > agree that these addresses should still be routable > according to the needs of the local administration. Yes. > To be precise, though, we do want non-routable addresses > too; they're the link-local addresses. Yes. 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 Apr 10 10:04:48 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 h3AH4lmh022826; Thu, 10 Apr 2003 10:04:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AH4luR022825; Thu, 10 Apr 2003 10:04:47 -0700 (PDT) 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 h3AH4imh022818 for ; Thu, 10 Apr 2003 10:04:44 -0700 (PDT) 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 h3AH4pcU012810 for ; Thu, 10 Apr 2003 10:04:51 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA03718 for ; Thu, 10 Apr 2003 10:04:45 -0700 (PDT) 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, 10 Apr 2003 17:04: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, 10 Apr 2003 17:04: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, 10 Apr 2003 17:04: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, 10 Apr 2003 17:04:44 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 10 Apr 2003 10:04:41 -0700 Reply-To: From: "Tony Hain" To: "'Thomas Narten'" Cc: "'Erik Nordmark'" , Subject: RE: FW: Consensus on Site-Local Addressing Date: Thu, 10 Apr 2003 10:04:41 -0700 Message-Id: <0f9101c2ff83$46f11ac0$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: <200304101556.h3AFuM0r032139@rotala.raleigh.ibm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > Tony, > > > Please consider this the second step in the appeal process, > as I have > > already discussed these issues with the chairs on more than one > > occasion. > > Discussing general issues with the chairs is not the same as > finding disagreement with a specific action that the chairs > have taken. I suspect you have done the former, but not the > latter. If you feel that the chairs have erred, and that they > have taken an action that isn't supported by the processes as > outlined in RFC 2026 (and RFC 2418), an appeal might be > warranted. To file an appeal, the process is outlined in RFC > 2026. Start with the chairs, use RFC 2026/2418 as a guide for > what are appropriate grounds for an appeal, and be clear > about what action (or inaction) you specifically have issue > with and want reconsidered. Suggesting what remedy you > believe is appropriate would also be useful. Well I did specifically discuss a disagreement with the action of the chairs in calling the ambiguous question, but I will accept this deferral and redirect the current appeal comment to the chairs. 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 Apr 10 10:14:40 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 h3AHEemh023269; Thu, 10 Apr 2003 10:14:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AHEd1k023268; Thu, 10 Apr 2003 10:14:39 -0700 (PDT) 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 h3AHEamh023261 for ; Thu, 10 Apr 2003 10:14:36 -0700 (PDT) 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 h3AHEhcU016558 for ; Thu, 10 Apr 2003 10:14:43 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA27660 for ; Thu, 10 Apr 2003 10:14:38 -0700 (PDT) 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, 10 Apr 2003 17:14: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, 10 Apr 2003 17:14: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, 10 Apr 2003 17:14:37 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; Thu, 10 Apr 2003 17:14:37 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 KAA19407; Thu, 10 Apr 2003 10:13:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3AHDdo22106; Thu, 10 Apr 2003 10:13:39 -0700 X-mProtect: <200304101713> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdy93TOQ; Thu, 10 Apr 2003 10:13:37 PDT Message-Id: <3E95A642.EAD2374C@iprg.nokia.com> Date: Thu, 10 Apr 2003 10:13:38 -0700 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: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: Globally Unique Private Addresses and Scoped Architecture References: <963621801C6D3E4A9CF454A1972AE8F5045705@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 Hello Michel, Michel Py wrote: > > Charlie Perkins wrote: > > But global uniqueness means we don't need scoping in the > > (unicast) address architecture. It means that scoping can > > be done as part of route table management instead. > > Can you give some precisions about this? To be precise, needs precise definitions. Shall I be so bold? Let's say that a "scope" corresponds to a "domain of effectiveness". Now we have two undefined terms instead of just one. Ignoring that for the moment... (and, so much for precise definitions!) Applied to a globally unique address (note: not necessarily globally routable) it means the networks where the address may be used to support communications. For addresses that aren't globally routable, I reckon this would mean those networks where non-global arrangements have been made for routability. That means that the "scope" of the address is defined by the (non-global) routing arrangements that have been made for that address. I hope this is helpful. It's probably crucial to get some definitions that are agreeable, and that help to decompose what could currently be viewed as a mass of related but separable wishlist items. 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 Thu Apr 10 10:34:12 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 h3AHYCmh023742; Thu, 10 Apr 2003 10:34:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AHYC67023741; Thu, 10 Apr 2003 10:34:12 -0700 (PDT) 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 h3AHY8mh023730 for ; Thu, 10 Apr 2003 10:34:08 -0700 (PDT) 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 h3AHYFcU023343 for ; Thu, 10 Apr 2003 10:34:15 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA22066 for ; Thu, 10 Apr 2003 11:34:10 -0600 (MDT) 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, 10 Apr 2003 17:31: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; Thu, 10 Apr 2003 17:31:54 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, 10 Apr 2003 17:31:54 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 17:31:53 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 10 Apr 2003 10:31:48 -0700 Reply-To: From: "Tony Hain" To: "'Bob Hinden'" , "'Margaret Wasserman'" Cc: Subject: FW: Consensus on Site-Local Addressing Date: Thu, 10 Apr 2003 10:31:47 -0700 Message-Id: <0f9301c2ff87$128fd880$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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3AHY8mh023731 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob & Margaret, As I noted to Thomas a few moments ago, I have already raised concerns about the initial action of calling the ambiguous question. I believe his response indicates I also need to raise a concern with you about this specific action of declaring consensus. As the content of the note below indicates, there can be no consensus because the question was not clear. At best, this activity shows a desire to change the status quo, but it does not and can not indicate anything else. The consensus declaration must be voided. As I note below, steps 4) & 5) indicate work that the group believes we should take on. *If* the result of that work leaves us with no further use for the current definition for an ambiguous address space, then in that context I believe steps 1) & 3) are appropriate. Until then they are not, and are very likely to create chaos, particularly if done before 4) delivers complete alternatives. You must void the declaration of consensus, and should recognize that the original question was not clear. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tony Hain > Sent: Wednesday, April 09, 2003 5:42 PM > To: 'Thomas Narten'; 'Erik Nordmark' > Cc: ipng@sunroof.eng.sun.com > Subject: FW: Consensus on Site-Local Addressing > > > Thomas & Erik, > > Please consider this the second step in the appeal process, > as I have already discussed these issues with the chairs on > more than one occasion. > > 'we reject kings, presidents and voting...' > The consensus measurement on the mail list was much more > indicative of the real lack of it (60/40%), than what was > effectively ballot stuffing by WG visitors without a complete > context. There was a very short presentation in the apps open > area, intended to raise concerns and incite involvement, were > those in the apps area were agitated, then invited to the > IPv6 WG session in SF to discuss the potential issues. The > subsequent short discussion in the IPv6 WG showed there were > issues to work through, and at least one question voiced > about understanding the requirements. Rather than deal with > the issues raised, the chairs decided to call an ambiguous > question of yes/no for deprecation. > > While the chairs do in 2) recognize their interpretation of > the consensus that the WG will investigate other forms of > local addressing, there is no mention of ambiguity and the > rest of the wording of 1) & 2) can be interpreted as local > scope addressing is deprecated. The concern is that we will > end up with a document lacking local scope addressing, and > claims that we had consensus to remove local scope from the > architecture. Many of those who bothered to state why they > were expressing a yes opinion claimed ambiguity was the > reason, while others were only interested in removing special > handling for local scope addresses. Those are technically > different issues, so they need different questions. What we > have is an indication that many are unhappy with the status > quo, but a lack of recognition that the call ended up > combining yes opinions for removing ambiguity with yes > opinions for removing local scope addresses from the > architecture. From subsequent discussions with the chairs, it > is clear that was not their intent, but never the less that > is the result of the lack of clarity in this consensus call. > > '... we believe in rough consensus & running code' & from the > Tao : 'running code wins' On several related mail threads > there were many comments about running code, and at least > Brian Zill & Brian Haberman said they collectively had host, > application, and router implementations of the current SL > running. Point 3) even acknowledges there are existing > implementations. This consensus call intends to invalidate > the running code, and all we have to replace it is a promise > in 4) that if the group can ever agree that operational > requirements of the site network manager are worth solving, > we might start to work on solutions, subject to appropriate > charter updates. This whole discussion is based on the > argument that some developers couldn't create running code > for an arguably bogus scenario where topology locators are > blindly passed outside their scope of relevance. Bias was > given to the opinions of those with a lack of running code, > at the expense of, and with the specific intent of > invalidating the code that exists. > > There were also claims in the meeting and mail threads that > we have analyzed site local as currently defined, and it > doesn't meet the requirements. At the same time, there is a > recognition by many of the same people that we need to > develop a complete set of requirements. It should be obvious > that the analysis is flawed if the complete set of > requirements are not understood first. To that end, and in > the spirit of making progress, > draft-hain-ipv6-sitelocal-00.txt was processed by the I-D > editor on 4/8, and is offered as an attempt to document the > requirements for address space with a local scope of > relevance. It is clearly incomplete, and largely based on my > previous email on the subject. > > While I contest the claim that the Yes/No opinions expressed > measured consensus for a consistent interpretation of what > 'deprecate site local addresses' means, I do believe that a > set of work items for the group were identified. It is also > clear that we can add new work to a group at any time, > without the need to remove existing items first. I agree with > the chairs that items 4) & 5) are valid outcomes of the > subsequent discussion, though one thing that their > interpretation of the result does not make clear is the > meaning of 'accomplish the following things in parallel:'. In > talking to the chairs it appears the intent is to start the > work at the same time, but we need to avoid invalid > transition states, so parallel needs to mean that all 5 are > to be forwarded to the IESG at one time. In particular, > without solutions to the requirements in hand, any documents > for 1) & 3) that intend to deprecate the only local use > address space will simply create chaos, and might need to be > rescinded if the complete set of requirements shows a need > with no other technical approach. > > In short, I do not believe the consensus call measured the > opinions that were consistent the chairs interpretation of > the question, so the claimed results are invalid. I do > believe that the effort identified work items 4) & 5), with > the potential that 1) & 3) might follow if there are no > outstanding requirements for ambiguous address space. I > question the wisdom of 2), but will reserve judgment until > the complete text identifying further work is spelled out. In > any case, I hope this appeal can be dealt with at this level, > and that the overall effort results in an expedited charter > update. It is imperative that new approaches exist prior to > removal of the current, and there is a very real danger that > the current destructive energy will dissipate in the face of > the hard work of creating replacements. > > Tony > > > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Bob > > Hinden & Margaret Wasserman > > Sent: Wednesday, April 09, 2003 3:11 PM > > To: ipng@sunroof.eng.sun.com > > Subject: Consensus on Site-Local Addressing > > > > > > Hi All, > > > > Well, that was fun! :-) > > > > All told, there were over 200 responses to the consensus > call on IPv6 > > site-local addressing, approximately 3-to-1 in favor of > > deprecating IPv6 > > site-local unicast addressing. The final count (including > > the room and the > > mailing list) was: 155 YES, 56 NO (211 Total). > > > > There were also a significant number of the people on both > > sides of this > > issue that voiced (in their original responses, or in > > subsequent messages) > > a strong belief that we should investigate alternative > > mechanisms for local > > addressing and local access control. > > > > The chairs have read all of the messages on the list, and > > based on your > > considerable input, we have determined that the IPv6 WG does > > have rough > > consensus to deprecate the usage of IPv6 site-local unicast > > addressing AND > > to investigate alternative mechanisms for local addressing > > and local access > > control. > > > > In particular, the IPv6 WG will work to accomplish the > > following things in > > parallel: > > > > (1) Publish an informational document that explains the issues > > encountered with site-local addressing and our reasons > > for deprecating IPv6 site-local unicast addresses. This > > document will officially deprecate site-local addressing. > > > > (2) Remove site-local unicast addressing from the IPv6 > > scoped addressing architecture I-D, and publish the > > parts of the document on which we do have consensus > > (i.e., link local addresses, multicast, etc.). This > > will include a note that the IPv6 working group is > > investigating other forms of local IPv6 addressing and > > that the usage of any new forms of local addresses will be > > documented elsewhere. > > > > (3) Update the IPv6 addressing architecture to indicate that the > > usage of the FECO::/10 prefix for site-local addressing is > > deprecated. To maintain backward compatibility with existing > > implementations the prefix should be reserved and should not > > be allocated for other purposes. > > > > (4) Define and publish the requirements for a local addressing > > mechanism to provide: > > - Addresses for disconnected networks. > > - Addresses for intermittently connected networks. > > - Addresses that support merging of sites. > > - Stable local addresses for changing ISPs without > > disrupting local communication. > > Once we have consensus on the requirements, the IPv6 > > WG will work on solutions for local addressing that > > meet those requirements. > > > > (5) Define and publish the requirements for a local access > > control mechanism, then work on a solution that meets > > those requirements. > > > > Each of these new work items will need to be added to the > > IPv6 WG charter > > and will go through the normal IETF document processes. For > > (4) and (5) it > > is important to make the rest of the IETF community aware > > that the IPv6 WG > > is undertaking these tasks, so we will consider methods to > > invite wider > > review and discussion of these problems. > > > > IPv6 site-local addressing has been a contentious issue in > > the IPv6 WG for > > some time, and we are both glad to see the WG reach > consensus on this > > issue. This will allow us to complete and publish the IPv6 scoped > > addressing architecture document, an important part of the > > IPv6 specification. > > > > We hope that people on all sides of this issue will respect > the rough > > consensus of the WG, and will work with us to achieve the > > goals outlined above. > > > > Thanks to everyone who expressed an opinion during this discussion. > > > > Bob Hinden & Margaret Wasserman > > IPv6 WG Chairs > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Apr 10 10:55:22 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 h3AHtMmh023954; Thu, 10 Apr 2003 10:55:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AHtMEt023953; Thu, 10 Apr 2003 10:55:22 -0700 (PDT) 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 h3AHtImh023946 for ; Thu, 10 Apr 2003 10:55:18 -0700 (PDT) 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 h3AHtQvV020437 for ; Thu, 10 Apr 2003 10:55:26 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA05955 for ; Thu, 10 Apr 2003 10:55:20 -0700 (PDT) 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, 10 Apr 2003 17:44: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; Thu, 10 Apr 2003 17:44: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, 10 Apr 2003 17:44:49 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; Thu, 10 Apr 2003 17:44:49 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 KAA20691; Thu, 10 Apr 2003 10:44:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3AHimG00430; Thu, 10 Apr 2003 10:44:48 -0700 X-mProtect: <200304101744> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdk8eogX; Thu, 10 Apr 2003 10:44:46 PDT Message-Id: <3E95ADEF.2080002@iprg.nokia.com> Date: Thu, 10 Apr 2003 10:46:23 -0700 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: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Addressing References: <963621801C6D3E4A9CF454A1972AE8F50456F7@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, Michel Py wrote: > Fred, > > >>A fundamental question here is whether the disconnected/ >>intermittently connected networks will require subnetting >>internally. When subnetting is not required, link-local >>addressing (i.e., FE80::/10) may be enough. > > > There are many cases where these sites would indeed require local > subnetting. Is your statement based on proven fact or best current practices and/or conventional wisdom which may/may not be based on proven fact? I am not trying to be critical/sarcastic; just pointing out that we may need to examine long-held beliefs as we find a way forward. Regards, 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 Thu Apr 10 11:04: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 h3AI40mh024125; Thu, 10 Apr 2003 11:04:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AI40k4024123; Thu, 10 Apr 2003 11:04:00 -0700 (PDT) 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 h3AI3umh024111 for ; Thu, 10 Apr 2003 11:03:56 -0700 (PDT) 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 h3AI43vV023008 for ; Thu, 10 Apr 2003 11:04:03 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA27569 for ; Thu, 10 Apr 2003 11:03:58 -0700 (PDT) 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, 10 Apr 2003 17:48: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; Thu, 10 Apr 2003 17:48: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, 10 Apr 2003 17:48:57 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 17:48:57 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 10 Apr 2003 10:48:55 -0700 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , "'Brian E Carpenter'" Cc: "'Brian Haberman'" , "'IPv6'" Subject: RE: C000 Date: Thu, 10 Apr 2003 10:48:54 -0700 Message-Id: <0f9401c2ff89$747bad60$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.20030410111815.046d8de0@mail.windriver.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > ... > Yes, applications do have to deal with addresses that are > unreachable. Even if we group the "local" addresses into a > single prefix, applications will still need to handle it when > global address/port combinations are filtered/firewalled. > > I'm not sure that it is possible, but I hope that we can come > up with a local addressing scheme that does not require hosts > to include any special handling for local addresses (at any > layer of the protocol stack). This pair of paragraphs sums up the fundamental problem. For many there is an analytical recognition that applications do have to have special handling for limited scope addresses, but at the same time there is wishful thinking that we can flatten the network back into a single routing scope. > > I think that this may be possible using globally unique > local addresses, specifying some DNS enhancements (like > Mark Andrew's proposal, perhaps) that make it possible > for applications/stacks to control when they might receive > local addresses, and relying on the longest match rule in the > address selection rules to generally match local addresses > with local address and globals with globals. But, I really > need to understand the goals better before I can be sure. The inconsistency of accepting DNS enhancements for one type of limited scope address but not another is really sad. What is even worse is the recognition that we don't have a wide understanding of the goals & requirements, while claiming we have consensus that the only tool in hand does not solve the problems. 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 Apr 10 11:11: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 h3AIBJmh024537; Thu, 10 Apr 2003 11:11:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AIBJO3024534; Thu, 10 Apr 2003 11:11:19 -0700 (PDT) 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 h3AIBEmh024517 for ; Thu, 10 Apr 2003 11:11:14 -0700 (PDT) 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 h3AIBMcU005713 for ; Thu, 10 Apr 2003 11:11:22 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA04998 for ; Thu, 10 Apr 2003 11:11:16 -0700 (PDT) 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, 10 Apr 2003 18:04: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; Thu, 10 Apr 2003 18:04: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; Thu, 10 Apr 2003 18:04:24 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 18:04:24 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 10 Apr 2003 11:04:21 -0700 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , "'Brian Haberman'" Cc: "'Brian E Carpenter'" , "'IPv6'" Subject: RE: C000 Date: Thu, 10 Apr 2003 11:04:20 -0700 Message-Id: <0f9501c2ff8b$9ca5be00$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.20030410110944.046ca878@mail.windriver.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > ... > That's why I think we should start by trying to figure out > what our requirements are for local addressing -- or at least > what the problems statement is... > > Then, we can try to figure out what type of addressing and/or > other mechanisms can be used to meet those needs with the > fewest limitations, the least complexity and the lowest > impact on other parts of the protocols stack. > > I'm not sure where to start, though... I offer draft-hain-ipv6-sitelocal-00.txt as a starting point. > ... > I think that these things may need more details added > before we can understand if any (combination of) mechanism(s) > can meet the requirements and stay within the constraints. In > some cases, we may find that there are conflicting > requirements and constraints, and we will need to make trade-offs. The cynical might consider this a 3-year effort that will simply redesign the current SL, since the current SL was the result of a trade-off between the demand for site controlled address space, and the routing communities conflicting demand that any address space not provider aligned have an enforceable means of keeping it out of the global routing tables. 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 Apr 10 11:16: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 h3AIGimh024860; Thu, 10 Apr 2003 11:16:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AIGiOI024859; Thu, 10 Apr 2003 11:16:44 -0700 (PDT) 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 h3AIGemh024847 for ; Thu, 10 Apr 2003 11:16:40 -0700 (PDT) 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 h3AIGlvV028540 for ; Thu, 10 Apr 2003 11:16:47 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA13055 for ; Thu, 10 Apr 2003 12:16:42 -0600 (MDT) 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, 10 Apr 2003 18:16: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, 10 Apr 2003 18:16: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, 10 Apr 2003 18:16:41 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 18:16:41 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 10 Apr 2003 11:16:40 -0700 Reply-To: From: "Tony Hain" To: "'Brian E Carpenter'" , "'Thomas Narten'" , "'Erik Nordmark'" Cc: Subject: RE: FW: Consensus on Site-Local Addressing Date: Thu, 10 Apr 2003 11:16:38 -0700 Message-Id: <0f9b01c2ff8d$54879b00$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: <3E956E61.B0F9AF3D@hursley.ibm.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3AIGemh024850 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > ... > See my comments on the list in response to Robert Elz for > why I think this appeal is misguided. I think we should just > get on with the work at this point. Anything else is a > distraction and ultimately harmful to IPv6. While I agree we should get on with the work, confusing the network managers of the world is the act that will be harmful to IPv6. We have been claiming for some time now that the specs are stable and people should be planning their deployments. An arbitrary act by the IPv6 WG to declare site controlled address space as 'not to be used' is significantly more damaging because it invalidates the plans of those who bothered to start. This will only lead to bad press about IPv6 not being ready for prime-time since the WG is not providing a viable alternative. We do not need to call another question, because the discussion has identified work to be done in the chair's items 4) & 5). If that work provides appropriate alternatives, and there is no further need for the current SL, then it is appropriate to deprecate it. Until then, actions that remove a tool from a network managers hand without an acceptable replacement, will only serve to delay IPv6 deployments. We agree on the goal, but the specific course of action by the chairs was inappropriate in this case. 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 Apr 10 11:27: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 h3AIRXmh025289; Thu, 10 Apr 2003 11:27:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AIRWTR025288; Thu, 10 Apr 2003 11:27:32 -0700 (PDT) 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 h3AIRTmh025281 for ; Thu, 10 Apr 2003 11:27:29 -0700 (PDT) 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 h3AIRavV002208 for ; Thu, 10 Apr 2003 11:27:36 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA10378 for ; Thu, 10 Apr 2003 12:27:30 -0600 (MDT) 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, 10 Apr 2003 18:27: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; Thu, 10 Apr 2003 18:27: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; Thu, 10 Apr 2003 18:27:30 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; Thu, 10 Apr 2003 18:27:29 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 LAA22830; Thu, 10 Apr 2003 11:27:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3AIRMJ01774; Thu, 10 Apr 2003 11:27:22 -0700 X-mProtect: <200304101827> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdX6s2yM; Thu, 10 Apr 2003 11:27:20 PDT Message-Id: <3E95B788.DB9921CE@iprg.nokia.com> Date: Thu, 10 Apr 2003 11:27:20 -0700 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: alh-ietf@tndh.net CC: "'IPv6'" Subject: Re: C000 References: <0f9401c2ff89$747bad60$ee1a4104@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Tony, Tony Hain wrote: > This pair of paragraphs sums up the fundamental problem. For many there > is an analytical recognition that applications do have to have special > handling for limited scope addresses, I thought this was under dispute. I myself do not find the arguments for special handling very persuasive, for exactly the reason that Margaret stated: >> ... applications do have to deal with addresses that are >> unreachable. Even if we group the "local" addresses into a >> single prefix, applications will still need to handle it when >> global address/port combinations are filtered/firewalled. To me this means that if an application encounters an address that is unreachable for _any_ reason (not just incompatible scoping) it has to cope, and maybe in just about the same ways. For the second part, > but at the same time there is > wishful thinking that we can flatten the network back into a single > routing scope. What do you think about the proposal to define a block of addresses for use as globally-unique but not globally routable addresses? That's _not_ a single routing "scope". It would be nice if we could get some quick action on something along those lines that would (a) allow site-locals to be deprecated according to the wishes of many people and yet (b) allow the use of provider-independent addresses according to the wishes of many people. Maybe if a lot of people found this to be a solution of their most important wishes we could move forward more quickly. 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 Thu Apr 10 11:30: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 h3AIUcmh025408; Thu, 10 Apr 2003 11:30:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AIUcUt025407; Thu, 10 Apr 2003 11:30:38 -0700 (PDT) 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 h3AIUYmh025400 for ; Thu, 10 Apr 2003 11:30:34 -0700 (PDT) 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 h3AIUfvV003291 for ; Thu, 10 Apr 2003 11:30:41 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA18121 for ; Thu, 10 Apr 2003 11:30:36 -0700 (PDT) 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, 10 Apr 2003 18:30: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; Thu, 10 Apr 2003 18:30: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, 10 Apr 2003 18:30:35 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 18:30:35 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 10 Apr 2003 11:29:50 -0700 Reply-To: From: "Tony Hain" To: "'Fred L. Templin'" , "'Michel Py'" Cc: Subject: RE: Consensus on Site-Local Addressing Date: Thu, 10 Apr 2003 11:29:51 -0700 Message-Id: <0f9c01c2ff8f$2d1ac310$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: <3E95ADEF.2080002@iprg.nokia.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3AIUYmh025401 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred L. Templin wrote: > ... > > There are many cases where these sites would indeed require local > > subnetting. > > Is your statement based on proven fact or best current > practices and/or conventional wisdom which may/may not be > based on proven fact? See draft-hain-ipv6-sitelocal-00.txt, the research ship example as one real case where a multi-subnet network intermittently attaches to different providers. Other vehicle types (airplanes in particular) already have multiple subnets, and will attach to different providers over time. > I am not trying to be > critical/sarcastic; just pointing out that we may need to > examine long-held beliefs as we find a way forward. Yes we need to examine beliefs, like the concept that applications can blindly pass topology locators around, or that multi-faced DNS doesn't exist because the IETF refuses to deal with it. The reality of the network is that there are addresses that are only useful in a particular routing scope, and it is inappropriate for applications or infrastructure to pass those outside the scope of relevance. 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 Apr 10 11:50:49 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 h3AIonmh026067; Thu, 10 Apr 2003 11:50:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AIongO026066; Thu, 10 Apr 2003 11:50:49 -0700 (PDT) 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 h3AIojmh026059 for ; Thu, 10 Apr 2003 11:50:45 -0700 (PDT) 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 h3AIorvV009807 for ; Thu, 10 Apr 2003 11:50:53 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA02457 for ; Thu, 10 Apr 2003 12:50:47 -0600 (MDT) 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, 10 Apr 2003 18:50:47 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, 10 Apr 2003 18:50: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; Thu, 10 Apr 2003 18:50: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; Thu, 10 Apr 2003 18:50: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 TAA20880 for ; Thu, 10 Apr 2003 19:50:45 +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 TAA18686 for ; Thu, 10 Apr 2003 19:50:45 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3AIojq29947 for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 19:50:45 +0100 Date: Thu, 10 Apr 2003 19:50:45 +0100 From: Tim Chown To: IPv6 Subject: Re: C000 Message-Id: <20030410185045.GE29653@login.ecs.soton.ac.uk> Mail-Followup-To: IPv6 References: <3E957221.254CD6D5@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E957221.254CD6D5@hursley.ibm.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 10, 2003 at 03:31:13PM +0200, Brian E Carpenter wrote: > Let's be constructive and ignore distractions like appeals. > Let's also assume that item (4) ["requirements for a local > addressing mechanism"] in the chairs' work list is relatively > straightfoward and obvious. > > Assume that we consider stable, probably unique, > unrouteable prefixes important enough to get their own 3-bit > prefix, and for the sake of argument let's pick C000::/3. > > Further assume that we want to generate /48s. Well, in some cases a block of /48's is desirable - the nice property of fec0::/10 is that you can have a local-scope hiearchy of sites with aggregatable site prefixes (rather than routers in such a topology needing to maintain routes to all non-aggregated /48's). 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 Thu Apr 10 11:59: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 h3AIx3mh026423; Thu, 10 Apr 2003 11:59:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AIx329026422; Thu, 10 Apr 2003 11:59:03 -0700 (PDT) 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 h3AIwxmh026415 for ; Thu, 10 Apr 2003 11:59:00 -0700 (PDT) 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 h3AIx7cU022940 for ; Thu, 10 Apr 2003 11:59:07 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA06868 for ; Thu, 10 Apr 2003 12:59:01 -0600 (MDT) 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, 10 Apr 2003 18:58: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; Thu, 10 Apr 2003 18:58:33 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, 10 Apr 2003 18:58:33 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 18:58:33 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 10 Apr 2003 11:58:32 -0700 Reply-To: From: "Tony Hain" To: "'Charles E. Perkins'" Cc: "'IPv6'" Subject: RE: C000 Date: Thu, 10 Apr 2003 11:58:32 -0700 Message-Id: <0fa301c2ff93$2e9b99e0$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: <3E95B788.DB9921CE@iprg.nokia.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3AIx0mh026416 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charles E. Perkins wrote: > > This pair of paragraphs sums up the fundamental problem. For many > > there is an analytical recognition that applications do > have to have > > special handling for limited scope addresses, > > I thought this was under dispute. I myself do not find the > arguments for special handling very persuasive, for exactly > the reason that Margaret stated: > > >> ... applications do have to deal with addresses that are > >> unreachable. Even if we group the "local" addresses into a > >> single prefix, applications will still need to handle it when > >> global address/port combinations are filtered/firewalled. > > To me this means that if an application encounters an address > that is unreachable for _any_ reason (not just incompatible > scoping) it has to cope, and maybe in just about the same ways. Some applications might cope in the same way, but others MUST NOT. It is inappropriate for a file mount of proprietary content to suddenly traverse the Internet when the internal network partitions. If the file mount were allowed to arbitrarily connect using the global scope addresses, this is exactly what would happen. > > > > For the second part, > > > but at the same time there is > > wishful thinking that we can flatten the network back into a single > > routing scope. > > What do you think about the proposal to define a block of > addresses for use as globally-unique but not globally > routable addresses? That's _not_ a single routing "scope". This describes the reality of networks that partition their PA space. The only arguments against uniqueness are coming from those who want to ensure that the space is not routable. > > It would be nice if we could get some quick action on > something along those lines that would (a) allow site-locals > to be deprecated according to the wishes of many people and > yet (b) allow the use of provider-independent addresses > according to the wishes of many people. Maybe if a lot of > people found this to be a solution of their most important > wishes we could move forward more quickly. If there were only those two opinions, we might move quickly. Unfortunately, the consensus call mixed the opinions of those that want a resolution disallowing local scopes (route filtering) with those that want to remove the ambiguity aspect of the current SL. Then we need to account for the opinion of the routing community that wants a way to ensure that PI addresses do not crush the routing table (actually many simply do not want PI to exist). To that end, I have been working on a PI allocation that scales to some degree, but may require minor adjustments to current business models. This raises yet another community of opinion, where business models are sacred. There are undoubtedly other opinions that need to be factored in. We are not going to find a single approach that meets all competing requirements quickly. We may find a set of approaches, but in any case that will take time. If we want to make progress, we need to task those motivated to get rid of the current SL with finding alternatives first. Doing otherwise is irresponsible and will only stall IPv6 deployments. I have no doubt that simply having this debate will cause many to reconsider their rollout plans. 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 Apr 10 12:01: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 h3AJ1tmh026536; Thu, 10 Apr 2003 12:01:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AJ1seX026535; Thu, 10 Apr 2003 12:01:54 -0700 (PDT) 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 h3AJ1pmh026523 for ; Thu, 10 Apr 2003 12:01:51 -0700 (PDT) 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 h3AJ1wvV013540 for ; Thu, 10 Apr 2003 12:01:58 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA05943 for ; Thu, 10 Apr 2003 12:01:53 -0700 (PDT) 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, 10 Apr 2003 19:01:52 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, 10 Apr 2003 19:01: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; Thu, 10 Apr 2003 19:01:52 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; Thu, 10 Apr 2003 19:01:51 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 UAA20960 for ; Thu, 10 Apr 2003 20:01:50 +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 UAA19094 for ; Thu, 10 Apr 2003 20:01:50 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3AJ1o329989 for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 20:01:50 +0100 Date: Thu, 10 Apr 2003 20:01:50 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: FW: Consensus on Site-Local Addressing Message-Id: <20030410190150.GF29653@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <3E956E61.B0F9AF3D@hursley.ibm.com> <0f9b01c2ff8d$54879b00$ee1a4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f9b01c2ff8d$54879b00$ee1a4104@eagleswings> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 10, 2003 at 11:16:38AM -0700, Tony Hain wrote: > > While I agree we should get on with the work, confusing the network > managers of the world is the act that will be harmful to IPv6. We have > been claiming for some time now that the specs are stable and people > should be planning their deployments. So who has actually deployed site-local addressing/routing on their sites? 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 Thu Apr 10 12:09: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 h3AJ9tmh027060; Thu, 10 Apr 2003 12:09:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AJ9tfo027059; Thu, 10 Apr 2003 12:09:55 -0700 (PDT) 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 h3AJ9omh027043 for ; Thu, 10 Apr 2003 12:09:50 -0700 (PDT) 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 h3AJ9wcU026833 for ; Thu, 10 Apr 2003 12:09:58 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id NAA00394 for ; Thu, 10 Apr 2003 13:09:46 -0600 (MDT) 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, 10 Apr 2003 19:09: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, 10 Apr 2003 19:09: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, 10 Apr 2003 19:09:45 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, 10 Apr 2003 19:09:45 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 h3AJ9BB0015540; Thu, 10 Apr 2003 15:09:11 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-192.cisco.com [161.44.149.192]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA29649; Thu, 10 Apr 2003 15:09:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20030410150744.00b93d60@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Apr 2003 15:09:12 -0400 To: Tim Chown From: Ralph Droms Subject: Re: FW: Consensus on Site-Local Addressing Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20030410190150.GF29653@login.ecs.soton.ac.uk> References: <0f9b01c2ff8d$54879b00$ee1a4104@eagleswings> <3E956E61.B0F9AF3D@hursley.ibm.com> <0f9b01c2ff8d$54879b00$ee1a4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:01 PM 4/10/2003 +0100, Tim Chown wrote: >On Thu, Apr 10, 2003 at 11:16:38AM -0700, Tony Hain wrote: >> >> While I agree we should get on with the work, confusing the network >> managers of the world is the act that will be harmful to IPv6. We have >> been claiming for some time now that the specs are stable and people >> should be planning their deployments. > >So who has actually deployed site-local addressing/routing on their sites? > >Tim And what were the operational experiences? What worked, what broke, etc. It would be good to get some input based on experience as a counterweight to speculation... - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 12:21: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 h3AJLZmh027571; Thu, 10 Apr 2003 12:21:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AJLZ8x027570; Thu, 10 Apr 2003 12:21:35 -0700 (PDT) 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 h3AJLVmh027563 for ; Thu, 10 Apr 2003 12:21:31 -0700 (PDT) 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 h3AJLcvV020528 for ; Thu, 10 Apr 2003 12:21:38 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA17631 for ; Thu, 10 Apr 2003 12:21:33 -0700 (PDT) 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, 10 Apr 2003 19:21:32 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, 10 Apr 2003 19:21:32 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, 10 Apr 2003 19:21:31 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; Thu, 10 Apr 2003 19:21: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 UAA21167 for ; Thu, 10 Apr 2003 20:21:30 +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 UAA19662 for ; Thu, 10 Apr 2003 20:21:29 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3AJLTV30121 for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 20:21:29 +0100 Date: Thu, 10 Apr 2003 20:21:29 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Site locals: Whither Steve Deering? Message-Id: <20030410192129.GG29653@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <963621801C6D3E4A9CF454A1972AE8F5045705@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5045705@server2000.arneill-py.sacramento.ca.us> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK, so Steve isn't with us to give his comment. But I was curious to see what he might have said in the past. The Google is Your Friend. First, it is interesting that in 2003 people think that deleting site-locals will send the wrong message about IPv6 readiness. Just look what Steve himself said in March 1998... "Well, it does appear that we do not have consensus on deleting site-local addresses from IPv6. Also, someone mentioned to me another reason for retaining site-locals: deleting them at this point would just strengthen a preception in some quarters that IPv6 is still undergoing significant changes, and therefore is not ready to be taken seriously. While I personally think that deletion of inessential features is a much more benign type of change than addition of new features, and that as a living, evolving technology, it is wrong to expect IP ever to be "done", it is nonetheless important for us to be sensitive to the concerns people have about its stability. So for that reason and the other reasons people have identified, I propose that we keep site-local addresses for now, and continue to work on ironing out the details of their use." (http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/IPng/1998-04/0085.html) That was 1998. We've since had 5 years to "iron out details of their use" but haven't done so yet, although Brian and some others have some scoped implementations. Also in March 1998, in response to Christian's suggestion of the evilness of scoped addresses, Steve wrote: "Site-local addresses made more sense in some of the earlier stages of SIP and SIPP development, based on ideas that no longer apply in IPv6. I would be quite happy to delete site-local unicast addresses entirely from IPv6 if we had consensus on that (though the notion of site boundaries would still appear in the scope field of multicast address) -- it would simplify the implementations and the specs, and eliminate much of the confusion and design choices of the sort we have been discussing. However, I don't recall consensus ever being reached about net 10 in the IPv4 world. Does anyone in the IPv6 community want to speak up in favor of site-local addesses? (Note: if we eliminated site-local addresses, we could always add them back in in the future if absolutely necessary, using the net 10 approach, i.e., simply designating one global prefix for private use.) (I realize that I probably sound rather inconsistent here, on the one hand arguing for flexibility in how site-local address may be used, and on the other hand being content to see them eliminated altogether. But I don't think I am contradicting myself: I prefer the minimum number of mechanisms that achieve the maximum "power"/capability/generality. *If* we are going to keep site-local addresses, I think we should not unnecessarily constrain their possible use.)" (http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/IPng/1998-04/0033.html) So (again five years ago) Steve was happy to write out site-locals if we have consensus to do so, on the basis that we can always add them back later if the alternatives don't work out. Also note we would keep site local multicast scope - something which itself could be used for some service discovery mechanisms. Of course I wouldn't presume that Steve's views would be the same now, but I found it interesting to read what he write, even five years ago, particularly the second quote. 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 Thu Apr 10 12:23: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 h3AJNCmh027609; Thu, 10 Apr 2003 12:23:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AJNCwY027608; Thu, 10 Apr 2003 12:23:12 -0700 (PDT) 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 h3AJN8mh027598 for ; Thu, 10 Apr 2003 12:23:08 -0700 (PDT) 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 h3AJNFcU005141 for ; Thu, 10 Apr 2003 12:23:15 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA29844 for ; Thu, 10 Apr 2003 13:23:10 -0600 (MDT) 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, 10 Apr 2003 19:23: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; Thu, 10 Apr 2003 19:23: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; Thu, 10 Apr 2003 19:23:09 Z Received: from fuchsia.home ([203.146.155.23] [203.146.155.23]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 19:23:06 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3AJKuS8006451; Fri, 11 Apr 2003 02:20:57 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3AJInp16694; Fri, 11 Apr 2003 02:18:51 +0700 (ICT) From: Robert Elz To: Margaret Wasserman cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Addressing In-Reply-To: <5.1.0.14.2.20030410085108.0394ae30@mail.windriver.com> References: <5.1.0.14.2.20030410085108.0394ae30@mail.windriver.com> <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Apr 2003 02:18:49 +0700 Message-Id: <16692.1050002329@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Apr 2003 08:57:39 -0400 From: Margaret Wasserman Message-ID: <5.1.0.14.2.20030410085108.0394ae30@mail.windriver.com> | What do you think it means for the documents to 'stay as they are'? Site locals remain in the addressing architecture, as defined. | So, I _think_ that leaving documents 'as they are' means leaving | the prefix in the addressing architecture and allowing all of the | I-Ds that specify any usage of it to expire as there is no consensus | to advance any of them. Is that what you are proposing? That's just fine. I don't need something to tell me the one true blessed way to use the things, I can (and do) manage to use the things all by myself. Others do the same, I expect. The ways they use them, and the way I do, are most likely not the same. Who cares? I just need implementations that implement what the address architecture says should be done, not forwarding FEC0::/10 packets from one site to another, which means, with the ability to specify what is one site, and what is another. Personally, I don't have much need (or any real need, other than for experimentation) for multi-site nodes, so just "link in the site" and "link not in the site" would be enough for me (but I also see no compelling need to deprive others of multi-site nodes if they want them). But if SL addresses are removed from the architecture, implementors will quite likely start yanking the code that handles all of this, requiring filters to block packets (which is possible) which are unlikely to then send the ICMP "out of scope" type (which I hope by now has been returned to the specs - Steve Deering did say that it just got accidentally omitted, it is needed for LL's as well). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 10 12:24:46 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 h3AJOkmh027708; Thu, 10 Apr 2003 12:24:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AJOjfK027706; Thu, 10 Apr 2003 12:24:45 -0700 (PDT) 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 h3AJOfmh027696 for ; Thu, 10 Apr 2003 12:24:41 -0700 (PDT) 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 h3AJOncU005680 for ; Thu, 10 Apr 2003 12:24:49 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA00790 for ; Thu, 10 Apr 2003 13:24:43 -0600 (MDT) 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, 10 Apr 2003 19:24: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; Thu, 10 Apr 2003 19:24: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, 10 Apr 2003 19:24:42 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 19:24:41 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 10 Apr 2003 12:24:40 -0700 Reply-To: From: "Tony Hain" To: "'Tim Chown'" , Subject: RE: FW: Consensus on Site-Local Addressing Date: Thu, 10 Apr 2003 12:24:40 -0700 Message-Id: <0fb001c2ff96$d5406660$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: <20030410190150.GF29653@login.ecs.soton.ac.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3AJOgmh027697 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown wrote: > ... > So who has actually deployed site-local addressing/routing on > their sites? It is not my place to announce deployments, but at least Microsoft & kre have said on this list they have deployed and use SL. My point was targeted at those who are planning deployments. I have talked to customers who consider a stable address block, independent of their provider(s) to be a top priority. Yanking the defined non-PA space will only cause them to pick random numbers, or turn the documentation space into a different instance of ambiguous space. 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 Apr 10 12:28: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 h3AJSomh028114; Thu, 10 Apr 2003 12:28:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AJSoYK028113; Thu, 10 Apr 2003 12:28:50 -0700 (PDT) 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 h3AJSjmh028100 for ; Thu, 10 Apr 2003 12:28:45 -0700 (PDT) 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 h3AJSqcU007111 for ; Thu, 10 Apr 2003 12:28:52 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA24635 for ; Thu, 10 Apr 2003 13:28:47 -0600 (MDT) 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, 10 Apr 2003 19:28: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; Thu, 10 Apr 2003 19:28: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, 10 Apr 2003 19:28:46 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; Thu, 10 Apr 2003 19:28:46 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 MAA25677; Thu, 10 Apr 2003 12:28:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3AJShB00818; Thu, 10 Apr 2003 12:28:43 -0700 X-mProtect: <200304101928> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAy781q; Thu, 10 Apr 2003 12:28:42 PDT Message-Id: <3E95C5EA.FD6923D1@iprg.nokia.com> Date: Thu, 10 Apr 2003 12:28:42 -0700 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: alh-ietf@tndh.net CC: "'IPv6'" Subject: Re: C000 References: <0fa301c2ff93$2e9b99e0$ee1a4104@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Tony, Tony Hain wrote: > Some applications might cope in the same way, but others MUST NOT. I'm still not convinced by your example ... > It is > inappropriate for a file mount of proprietary content to suddenly > traverse the Internet when the internal network partitions. Agreed! > If the file > mount were allowed to arbitrarily connect using the global scope > addresses, this is exactly what would happen. The addresses are supposed to NOT be globally routable. Thus, the Internet traversal would only happen if the local network administration made other arrangements for the packets to be routed to some other domain. Tunneling comes to mind, but we don't have to be that specific for this discussion. So it seems to me that the danger would only exist IF the network administration took specific steps to enable it. Administrations that left the provider-independent addresses routable only within their domain should still see that the traffic is dropped instead of exiting their domain. > > For the second part, > > > > > but at the same time there is > > > wishful thinking that we can flatten the network back into a single > > > routing scope. > > > > What do you think about the proposal to define a block of > > addresses for use as globally-unique but not globally > > routable addresses? That's _not_ a single routing "scope". > > This describes the reality of networks that partition their PA space. > The only arguments against uniqueness are coming from those who want to > ensure that the space is not routable. If I read this correctly, it means we're in good agreement here. And, others claim (correctly in my opinion) that it is possible to ensure that the space is not externally routable even if it contains unambiguous addresses. > > It would be nice if we could get some quick action on > > something along those lines that would (a) allow site-locals > > to be deprecated according to the wishes of many people and > > yet (b) allow the use of provider-independent addresses > > according to the wishes of many people. Maybe if a lot of > > people found this to be a solution of their most important > > wishes we could move forward more quickly. > > If there were only those two opinions, we might move quickly. I am suggesting that there may be a large population that hold these opinions, and if the members of that large population are willing to forego their other needs for a little while, we might move forward more quickly now. The other needs would then become priority items to be met as soon as the proponents figure out how. > ............. Then we need to > account for the opinion of the routing community that wants a way to > ensure that PI addresses do not crush the routing table (actually many > simply do not want PI to exist). Anyone who does not want to route PI addresses should have the authority of RFC 36fb (fb == foobar) to back them up! > To that end, I have been working on a > PI allocation that scales to some degree, but may require minor > adjustments to current business models. This raises yet another > community of opinion, where business models are sacred. There are > undoubtedly other opinions that need to be factored in. So why can't this be done within the context of an allocated space of provider-independent but NOT-globally-routable addresses, by the same specification that deprecates site-local? > We are not going to find a single approach that meets all competing > requirements quickly. We may find a set of approaches, but in any case > that will take time. Not all. Check! Doing all competing requirements may actually be impossible, unless the requirements are softened somehow. > If we want to make progress, we need to task those > motivated to get rid of the current SL with finding alternatives first. > Doing otherwise is irresponsible and will only stall IPv6 deployments. I > have no doubt that simply having this debate will cause many to > reconsider their rollout plans. Unless you can say why the proposed routing doesn't solve the address scoping problem, I still think there is a viable strategy lurking nearby. Agreed it only does two of the more important things that need to be done. 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 Thu Apr 10 12:29: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 h3AJT7mh028178; Thu, 10 Apr 2003 12:29:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AJT7mk028177; Thu, 10 Apr 2003 12:29:07 -0700 (PDT) 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 h3AJStmh028133 for ; Thu, 10 Apr 2003 12:28:56 -0700 (PDT) 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 h3AJT2cU007198 for ; Thu, 10 Apr 2003 12:29:02 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA22917 for ; Thu, 10 Apr 2003 13:28:57 -0600 (MDT) 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, 10 Apr 2003 19:28: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, 10 Apr 2003 19:25:23 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, 10 Apr 2003 19:28:55 Z Received: from fuchsia.home ([203.146.155.23] [203.146.155.23]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 19:28:52 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3AJSbS8006563; Fri, 11 Apr 2003 02:28:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3AJQTp16790; Fri, 11 Apr 2003 02:26:33 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Addressing In-Reply-To: <3E956D0D.95367286@hursley.ibm.com> References: <3E956D0D.95367286@hursley.ibm.com> <4.3.2.7.2.20030409150734.02f0ad58@mailhost.iprg.nokia.com> <11997.1049967846@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Apr 2003 02:26:29 +0700 Message-Id: <16788.1050002789@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Apr 2003 15:09:33 +0200 From: Brian E Carpenter Message-ID: <3E956D0D.95367286@hursley.ibm.com> | And given the way we use the word "deprecate" | in standards, deprecating and reserving FEC0::/10 won't break | anything that runs today, if we get Last Call consensus on doing so. Only if you assume that implementors keep implementing what is currently defined, and if you're assuming that, why "deprecate" anything, what would that mean. | All we have now is a declared consensus on a direction of work, | and given the months of debate that led to this straw poll, I | think we should respect the result. For the direction of work, I have no problem, as I said. But there's no need to go ripping anything out of the docs that are currently published RFCs until there is something ready to replace it. There's no need for that - unless there's some background assumption that nothing will ever be produced to replace it, but SL addresses still have to go anyway. That is, SL addresses as we have them might not be perfect, but the overall spec is much better with them than with nothing at all to replace them. kre ps: there really is no need to quote my entire message in your reply, that is an evil habit to get into. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 12:39:22 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 h3AJdMmh029370; Thu, 10 Apr 2003 12:39:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AJdLFb029369; Thu, 10 Apr 2003 12:39:21 -0700 (PDT) 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 h3AJdImh029362 for ; Thu, 10 Apr 2003 12:39:18 -0700 (PDT) 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 h3AJdPvV027185 for ; Thu, 10 Apr 2003 12:39:25 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id NAA13597 for ; Thu, 10 Apr 2003 13:39:18 -0600 (MDT) 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, 10 Apr 2003 19:39: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, 10 Apr 2003 19:35: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, 10 Apr 2003 19:39:16 Z Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 19:39:16 Z Received: from nomad.ctd.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id OAA05628 for ; Thu, 10 Apr 2003 14:39:13 -0500 (CDT) Message-Id: <5.1.1.5.2.20030410143502.00a2f8d0@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 10 Apr 2003 14:39:14 -0500 To: "'IPv6'" From: Richard Carlson Subject: Re: C000 In-Reply-To: <3E95B788.DB9921CE@iprg.nokia.com> References: <0f9401c2ff89$747bad60$ee1a4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Charrlie; At 11:27 AM 4/10/03 -0700, Charles E. Perkins wrote: >Hello Tony, > >Tony Hain wrote: > > > This pair of paragraphs sums up the fundamental problem. For many there > > is an analytical recognition that applications do have to have special > > handling for limited scope addresses, > >I thought this was under dispute. I myself do not find the >arguments for special handling very persuasive, for exactly >the reason that Margaret stated: > > >> ... applications do have to deal with addresses that are > >> unreachable. Even if we group the "local" addresses into a > >> single prefix, applications will still need to handle it when > >> global address/port combinations are filtered/firewalled. > >To me this means that if an application encounters an address >that is unreachable for _any_ reason (not just incompatible >scoping) it has to cope, and maybe in just about the same ways. I agree with this statement. Why would applications that have unreachable peer handling care what the reason is? Regards; Rich >For the second part, > > > but at the same time there is > > wishful thinking that we can flatten the network back into a single > > routing scope. > >What do you think about the proposal to define a block of >addresses for use as globally-unique but not globally routable >addresses? That's _not_ a single routing "scope". > >It would be nice if we could get some quick action on something >along those lines that would (a) allow site-locals to be deprecated >according to the wishes of many people and yet (b) allow the use >of provider-independent addresses according to the wishes of many >people. Maybe if a lot of people found this to be a solution of >their most important wishes we could move forward more quickly. > >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 >-------------------------------------------------------------------- ------------------------------------ Richard A. Carlson e-mail: RACarlson@anl.gov Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 12:48:53 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 h3AJmrmh029739; Thu, 10 Apr 2003 12:48:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AJmrp7029737; Thu, 10 Apr 2003 12:48:53 -0700 (PDT) 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 h3AJmnmh029730 for ; Thu, 10 Apr 2003 12:48:49 -0700 (PDT) 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 h3AJmuvV000142 for ; Thu, 10 Apr 2003 12:48:56 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA06496 for ; Thu, 10 Apr 2003 13:48:51 -0600 (MDT) 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, 10 Apr 2003 19:48: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; Thu, 10 Apr 2003 19:48: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; Thu, 10 Apr 2003 19:48:49 Z Received: from fuchsia.home ([203.146.155.24] [203.146.155.24]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 19:48:46 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3AJl5S8006755; Fri, 11 Apr 2003 02:47:05 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3AJijp16996; Fri, 11 Apr 2003 02:44:45 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: IPv6 Subject: Re: C000 In-Reply-To: <3E957221.254CD6D5@hursley.ibm.com> References: <3E957221.254CD6D5@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Apr 2003 02:44:45 +0700 Message-Id: <16994.1050003885@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Apr 2003 15:31:13 +0200 From: Brian E Carpenter Message-ID: <3E957221.254CD6D5@hursley.ibm.com> | Let's also assume that item (4) ["requirements for a local | addressing mechanism"] in the chairs' work list is relatively | straightfoward and obvious. I wouldn't. | Assume that we consider stable, probably unique, | unrouteable prefixes important enough to get their own 3-bit | prefix, and for the sake of argument let's pick C000::/3. Actually, we don't need a 3 bit prefix for these - the number allocation in the rest of the prefix can be quite dense, there are no H ratios to consider here, so a very large number of sites will fit. So, say, a 10 bit prefix (just to pick a number) would most likely work just fine. For the sake of argument, let's pick FEC0::/10 | Further assume that we want to generate /48s. Of course, nothing else is rational (though, just like globals, there needs to be a provision for pairs, or even bigger blocks, for those very few truly huge sites for which a /48 is not enough - but while we need to remember not to break that, we can probably ignore it for most purposes). | Then the problem to solve is generating probably unique 45 bit | numbers easily and essentially free of charge. That's clearly possible | in several ways, so let's not debate details. Well, actually, it was the details of this that led to site locals as we have them now. You may remember that I was one of those who thought that this should be achievable fairly easily - but the WG back in the early days did not agree, no-one wanted to create another ICANN type organisation, which is more or less what would be required (just with people selling numbers instead of names - just like domain names, there has to be some kind of renewal payment, or dead allocations never get cleaned up, and even with 45 bits of address space, if nothing is ever reclaimed, they won't last very long). So, let's do exactly that and, if not quite debating details, at least produce some concrete proposals, and see how well they're supported, | What are they going to do to the scoped architecture? Will applications | need to treat them any differently from 2000::/3? For the few applications that care any more than "if I send a packet, does it arrive" (which work just fine with SL as it exists now), then yes. Apps would need to make sure that they only send addresses to other nodes which are likely to work there, so they'd need to filter out the useless ones (somehow working out which those are - if it is a defined prefix, that's fairly easy) and only sending ones that can be expected to work. This is pretty much exactly what needs to be done using current SL's. The one difference is that (one hopes) that a C000::/3 would be certainly useless if sent outside its zone of reachability (a packet sent to it will go as far as default routes take it, then die). On the other hand, a packet sent to a (current) FEC0::/10 just might go to some node in the other site because of the ambiguity (which is a problem that really is bringing the internet to its knees with 1918 addresses, isn't it!) Of course, if sites don't just use FEC0::/48 but instead really use FEC0::/10 and 38 random bits, the chances of the same random bits just happening to be in use at some other location where a referral happens to have been sent are vanishingly small. But even if it does happen, and FEC0::/48 will probably be fairly common, the chances of a packet being delivered to some other node are pretty low, given that most addresses have an EUI-64 (or a random number) in the low 64 bits, so the chances of duplication in different sites is pretty tiny. Once again, I wouldn't mind some kind of number allocation authority to fill in the 38 bits with something more likely to be unique than a random number (or the 45 bits if a /3 replaced the /10) - but before we think about discarding what we have now, let's get the details of that authority (or mechanism) worked out and defined, and agreed to. If attempts to do that fail, then we still have SL's as we have now, which is certainly a big advantage over nothingness. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 10 13:07: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 h3AK7lmh000220; Thu, 10 Apr 2003 13:07:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AK7lqA000219; Thu, 10 Apr 2003 13:07:47 -0700 (PDT) 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 h3AK7hmh000211 for ; Thu, 10 Apr 2003 13:07:43 -0700 (PDT) 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 h3AK7ovV005175 for ; Thu, 10 Apr 2003 13:07:50 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA23774 for ; Thu, 10 Apr 2003 14:07:44 -0600 (MDT) 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, 10 Apr 2003 20:05:37 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, 10 Apr 2003 20:05: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; Thu, 10 Apr 2003 20:05:37 Z Received: from fuchsia.home ([203.146.155.24] [203.146.155.24]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 20:05:34 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3AK4qS8006960; Fri, 11 Apr 2003 03:04:53 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3AK28p17530; Fri, 11 Apr 2003 03:02:12 +0700 (ICT) From: Robert Elz To: Ralph Droms cc: Tim Chown , ipng@sunroof.eng.sun.com Subject: Re: FW: Consensus on Site-Local Addressing In-Reply-To: <4.3.2.7.2.20030410150744.00b93d60@funnel.cisco.com> References: <4.3.2.7.2.20030410150744.00b93d60@funnel.cisco.com> <0f9b01c2ff8d$54879b00$ee1a4104@eagleswings> <3E956E61.B0F9AF3D@hursley.ibm.com> <0f9b01c2ff8d$54879b00$ee1a4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Apr 2003 03:02:08 +0700 Message-Id: <17528.1050004928@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Apr 2003 15:09:12 -0400 From: Ralph Droms Message-ID: <4.3.2.7.2.20030410150744.00b93d60@funnel.cisco.com> | At 08:01 PM 4/10/2003 +0100, Tim Chown wrote: | >So who has actually deployed site-local addressing/routing on their sites? I have. | And what were the operational experiences? What worked, what broke, etc. A few implementation bugs (NetBSD (KAME) doesn't (didn't) send an ICMP when packets attempted to leave the site, they were dropped silently) but aside from that, nothing broke that I use - everything worked / works. I am not trying to run a site containing nodes that are also in other sites though, I don't have a topology that requires that. I am however not using SLs in the way that many people imagine them, there are no SL addresses in the DNS (well, none aside from a few for explicit testing with names line foo-sl where there are only SL addresses). | It would be good to get some input based on experience as a counterweight | to speculation... Yes. It would. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 10 13:14: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 h3AKE7mh000559; Thu, 10 Apr 2003 13:14:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AKE7Y7000558; Thu, 10 Apr 2003 13:14:07 -0700 (PDT) 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 h3AKE2mh000545 for ; Thu, 10 Apr 2003 13:14:02 -0700 (PDT) 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 h3AKE9vV007705 for ; Thu, 10 Apr 2003 13:14:09 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA24083 for ; Thu, 10 Apr 2003 14:14:03 -0600 (MDT) 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, 10 Apr 2003 20:14:03 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, 10 Apr 2003 20:14:02 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, 10 Apr 2003 20:14:02 Z Received: from fuchsia.home ([203.146.155.24] [203.146.155.24]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 20:13:59 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3AKDhS8007053; Fri, 11 Apr 2003 03:13:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3AKAip17634; Fri, 11 Apr 2003 03:10:44 +0700 (ICT) From: Robert Elz To: "Charles E. Perkins" cc: alh-ietf@tndh.net, "'IPv6'" Subject: Re: C000 In-Reply-To: <3E95B788.DB9921CE@iprg.nokia.com> References: <3E95B788.DB9921CE@iprg.nokia.com> <0f9401c2ff89$747bad60$ee1a4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Apr 2003 03:10:44 +0700 Message-Id: <17632.1050005444@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Apr 2003 11:27:20 -0700 From: "Charles E. Perkins" Message-ID: <3E95B788.DB9921CE@iprg.nokia.com> | | Hello Tony, | To me this means that if an application encounters an address | that is unreachable for _any_ reason (not just incompatible | scoping) it has to cope, and maybe in just about the same ways. Yes, I agree with that much. The difference is where an application needs to send an address to its peer, and has two available - which does it pick. If they're both global, then both are equally likely to work, so random selection (or selection using any other available criteria) is as good as it gets. On the other hand, when they're of different scopes, then the app wants to take care not to send an address that is not appropriate for the destination, so random selection most certainly isn't the solution. | What do you think about the proposal to define a block of | addresses for use as globally-unique but not globally routable | addresses? That's _not_ a single routing "scope". No, but it is essentially identical to what we currently have. There are almost no real practical differences. Why change? | It would be nice if we could get some quick action on something | along those lines that would (a) allow site-locals to be deprecated | according to the wishes of many people and yet (b) allow the use | of provider-independent addresses according to the wishes of many | people. Maybe if a lot of people found this to be a solution of | their most important wishes we could move forward more quickly. Yes, if that could be done, it would be fine. The problem is, that the last time this was attempted, (a) was the result of the search for (b). What makes you sure that the result would be different this time? Or different in a way other than "no consensus was achieved for any particular non routable addressing scheme so we won't have one" which at the minute is the most likely outcome of ant attempt to find something new (given that many people have been, wrongly I believe, scared away from site locals as we have them, and so might not support them even as a compromise solution). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 10 13:28: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 h3AKSsmh002904; Thu, 10 Apr 2003 13:28:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AKSsPv002903; Thu, 10 Apr 2003 13:28:54 -0700 (PDT) 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 h3AKSomh002889 for ; Thu, 10 Apr 2003 13:28:50 -0700 (PDT) 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 h3AKSvcU027934 for ; Thu, 10 Apr 2003 13:28:57 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA10694 for ; Thu, 10 Apr 2003 13:28:52 -0700 (PDT) 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, 10 Apr 2003 20:28: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; Thu, 10 Apr 2003 20:28: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; Thu, 10 Apr 2003 20:28:51 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 20:28:51 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 10 Apr 2003 13:28:50 -0700 Reply-To: From: "Tony Hain" To: "'Charles E. Perkins'" Cc: "'IPv6'" Subject: RE: C000 Date: Thu, 10 Apr 2003 13:28:46 -0700 Message-Id: <0fb601c2ff9f$c9a6f400$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: <3E95C5EA.FD6923D1@iprg.nokia.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3AKSomh002894 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charles E. Perkins wrote: > ... > > If the > file mount > > were allowed to arbitrarily connect using the global scope > addresses, > > this is exactly what would happen. > > The addresses are supposed to NOT be globally routable. > Thus, the Internet traversal would only happen if the > local network administration made other arrangements > for the packets to be routed to some other domain. > Tunneling comes to mind, but we don't have to be that > specific for this discussion. > > So it seems to me that the danger would only exist IF the > network administration took specific steps to enable it. > Administrations that left the provider-independent addresses > routable only within their domain should still see that the > traffic is dropped instead of exiting their domain. You missed the point. For this to work as you describe, the application had to do something to recognize the different scopes of the addresses available to it. If it does nothing and expects all addresses to have a single scope, it will recover into a state that the network manager wants to preclude. > > If I read this correctly, it means we're in good agreement > here. And, others claim (correctly in my opinion) that it is > possible to ensure that the space is not externally routable > even if it contains unambiguous addresses. If a single entity is in control of routing announcements, the confidence level of it being correct is higher, though most would recognize that errors happen. When sites interconnect, or service providers have explicit instructions for custom handling of prefixes, there is an opportunity for error outside the origin sites control. Ambiguity raises the confidence level that filtering will happen even in the case of errors, because the well-known prefix will be filtered at multiple levels. > > > > > It would be nice if we could get some quick action on something > > > along those lines that would (a) allow site-locals to be > deprecated > > > according to the wishes of many people and yet (b) allow > the use of > > > provider-independent addresses according to the wishes of many > > > people. Maybe if a lot of people found this to be a solution of > > > their most important wishes we could move forward more quickly. > > > > If there were only those two opinions, we might move quickly. > > I am suggesting that there may be a large population that > hold these opinions, and if the members of that large > population are willing to forego their other needs for a > little while, we might move forward more quickly now. The > other needs would then become priority items to be met as > soon as the proponents figure out how. Wrong order, and from what I can tell many hold the opinion that we should remove ambiguity simply on the promise that we might find an alternative. We are much more likely to find alternatives if those who want ambiguity to go away are motivated. If ambiguity goes away, it will be much harder to get the group to agree that the other needs are in fact priorities. > > > ............. Then we need to > > account for the opinion of the routing community that wants > a way to > > ensure that PI addresses do not crush the routing table > (actually many > > simply do not want PI to exist). > > Anyone who does not want to route PI addresses should have > the authority of RFC 36fb (fb == foobar) to back them up! Cash speaks much louder than an RFC, particularly if the competitor is willing to ignore the RFC to get it. > > > To that end, I have been working on a PI > > allocation that scales to some degree, but may require minor > > adjustments to current business models. This raises yet another > > community of opinion, where business models are sacred. There are > > undoubtedly other opinions that need to be factored in. > > So why can't this be done within the context of an allocated > space of provider-independent but NOT-globally-routable > addresses, by the same specification that deprecates site-local? If it meets all the needs, I have no problem. That is not what the chair's plan of action is though. Item 1) specifically calls for deprecation, then item 4) identifies requirements for a replacement, followed by possible future work items on solutions if the group comes to consensus on requirements and the charter is appropriately updated. The point is there are many opinions on what is right here, and until they result in a viable alternative that all agree to, the current plan must remain in place. > > > We are not going to find a single approach that meets all competing > > requirements quickly. We may find a set of approaches, but in any > > case that will take time. > > Not all. Check! Doing all competing requirements may actually > be impossible, unless the requirements are softened somehow. The current activity shows that even when requirements are softened (like uniqueness was last time around), people will try to firm them back up later. > > > If we want to make progress, we need to task those > > motivated to get rid of the current SL with finding alternatives > > first. Doing otherwise is irresponsible and will only stall IPv6 > > deployments. I have no doubt that simply having this debate > will cause > > many to reconsider their rollout plans. > > Unless you can say why the proposed routing doesn't solve the > address scoping problem, I still think there is a viable > strategy lurking nearby. Agreed it only does two of the more > important things that need to be done. What is important depends on which community you are standing in, and what issues have been recent irritants. Also, what looks like an obvious solution from some perspectives, is an absolute non-starter from others. We must not fall in the trap of proclaiming 'there must be a simple solution' and deprecating the only tool we have. We must find a solution that all can accept first. 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 Apr 10 13:34: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 h3AKYBmh003451; Thu, 10 Apr 2003 13:34:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AKQ1IG002515; Thu, 10 Apr 2003 13:26:01 -0700 (PDT) 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 h3AKPfmh002454 for ; Thu, 10 Apr 2003 13:25:42 -0700 (PDT) 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 h3AKPmvV012898 for ; Thu, 10 Apr 2003 13:25:48 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA24883 for ; Thu, 10 Apr 2003 13:25:42 -0700 (PDT) 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, 10 Apr 2003 20:25: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; Thu, 10 Apr 2003 20:25: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; Thu, 10 Apr 2003 20:25:11 Z Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 20:25:11 Z Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 10 Apr 2003 22:25:02 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3AKN9Xo026248; Thu, 10 Apr 2003 22:23:13 +0200 (MET DST) Received: from xfe-ams-312.cisco.com ([144.254.228.205]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 10 Apr 2003 22:24:57 +0200 Received: from cisco.com ([144.254.74.55]) by xfe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 10 Apr 2003 22:24:56 +0200 Date: Thu, 10 Apr 2003 22:24:48 +0200 Subject: Re: Yet another FEC0::/10 proposal Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipng@sunroof.eng.sun.com To: Robert Elz From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <11983.1049967626@munnari.OZ.AU> Message-Id: <7A23836E-6B92-11D7-88A6-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 10 Apr 2003 20:24:56.0787 (UTC) FILETIME=[40903230:01C2FF9F] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On torsdag, apr 10, 2003, at 11:40 Europe/Stockholm, Robert Elz wrote: > by definition, they only work inside a site. I don't think that's > very special (every node can be, if it wants a site, every collection > of a few nodes on a LAN certainly can be). Controlled - yes, of > course, > SL addresses don't want to escape a site. Ok, my brain run away, you are right in what you say Robert. What I have problems with is the ambiguity between for example site local and global address for the same host together with scoping (for one of them). Yes, I agree there are issues with for example your NFS connection when you get new global addresses (I think your site can keep your addresses when it is disconnected, but you might end up having problems when it connects to something again). But, I don't think that is a problem which should be solved with ambiguity and more addresses. I see two paths out of this: (a) Fix SIP, NFS, TCP, whatever so the protocols can handle a renumbering "event" when it happens. If we use addresses both for routing and identification, and the identifier because of this changes because of routing topology changes, then the protocols must be able to handle such an event. (b) Differentiate routing from identifier (much easier for me to point at as I have _absolutely_no_clue_ what that means for IP addresses, routing etc. I know it is something very very nice in general to not overload the use of some identifier from work in apps area for some years now. To conclude, I used a bad example, sorry. I wanted to show how hard it might be for a SIP-like application to know what address to use. That's it. paf -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 14:11:46 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 h3ALBkmh004529; Thu, 10 Apr 2003 14:11:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ALBkO3004528; Thu, 10 Apr 2003 14:11:46 -0700 (PDT) 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 h3ALBgmh004521 for ; Thu, 10 Apr 2003 14:11:42 -0700 (PDT) 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 h3ALBovV028664 for ; Thu, 10 Apr 2003 14:11:50 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA04567 for ; Thu, 10 Apr 2003 15:11:44 -0600 (MDT) 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, 10 Apr 2003 21:11: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, 10 Apr 2003 21:11: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, 10 Apr 2003 21:11:44 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 21:11:43 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id RAA14722; Thu, 10 Apr 2003 17:11:40 -0400 (EDT) Date: Thu, 10 Apr 2003 17:11:40 -0400 (EDT) From: Dan Lanciani Message-Id: <200304102111.RAA14722@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Globally Unique Private Addresses and Scoped Architecture Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie Perkins wrote: |But global uniqueness means we don't need scoping in the (unicast) |address architecture. It means that scoping can be done as part of |route table management instead. I think you have to be at least a little careful here about that pesky source address selection issue. If I tell machine A to connect to machine B using machine B's globally unique local address, I want to be sure that machine A uses its local address as the source even if it has a global and even if global/local communication is otherwise allowed. Without this constraint the connection will not have the stability of the locals. The intuitively obvious mechanisms of source address selection may make this work correctly without explicit scope; however, if scope-like notions *are* introduced (in particular, the common suggestion to always prefer a global if it is available) the system will break. In other words, I think you have to either completely eliminate scope considerations (no fair putting in a few simple tweaks to "fix" mobile IP or such) or else you are stuck with supporting a complete and fully specified scoping mechanism. Dan Lanciani ddl@danlan.*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 Apr 10 14:35: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 h3ALZomh005032; Thu, 10 Apr 2003 14:35:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ALZosr005031; Thu, 10 Apr 2003 14:35:50 -0700 (PDT) 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 h3ALZlmh005024 for ; Thu, 10 Apr 2003 14:35:47 -0700 (PDT) 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 h3ALZsvV005446 for ; Thu, 10 Apr 2003 14:35:54 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA13626 for ; Thu, 10 Apr 2003 15:35:48 -0600 (MDT) 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, 10 Apr 2003 21:35: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; Thu, 10 Apr 2003 21: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, 10 Apr 2003 21:35:48 Z Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 21:35:47 Z Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 72210137F12; Thu, 10 Apr 2003 14:35:46 -0700 (PDT) Date: Thu, 10 Apr 2003 14:35:46 -0700 Subject: Re: C000 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Brian E Carpenter , IPv6 To: Robert Elz From: David Conrad In-Reply-To: <16994.1050003885@munnari.OZ.AU> Message-Id: <63DA971C-6B9C-11D7-8A4A-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Perhaps I'm misunderstanding... On Thursday, April 10, 2003, at 12:44 PM, Robert Elz wrote: > just like domain names, there has to be some > kind of renewal payment, or dead allocations never get cleaned up, and > even with 45 bits of address space, if nothing is ever reclaimed, they > won't last very long). 2^45 / ( 60 * 60 * 24 * 365.25) = 1,114,925 If you are allocating (on average) a /45 per second, 24x7x365, it will take over 1 million years to consume 45 bits of address space without reclamation. > Of course, if sites don't just use FEC0::/48 but instead really use > FEC0::/10 and 38 random bits 2^38 / ( 60 * 60 * 24 * 365.25 ) = 8,710 If you are allocating (on average) a /38 per second, 24x7x365, it will take over 8 thousand years to consume 38 bits of address space without reclamation. A simple auto-responder operated by some global authority (or split among (say) 4 or 5 regional authorities) that automatically responds to a request every second would probably take a competent perl (or other language) programmer a day or two to throw together. What am I missing? 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 Thu Apr 10 15:10: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 h3AMAlmh005832; Thu, 10 Apr 2003 15:10:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AMAlmi005831; Thu, 10 Apr 2003 15:10:47 -0700 (PDT) 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 h3AMAhmh005821 for ; Thu, 10 Apr 2003 15:10:43 -0700 (PDT) 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 h3AMApvV015840 for ; Thu, 10 Apr 2003 15:10:51 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA11195 for ; Thu, 10 Apr 2003 16:10:45 -0600 (MDT) 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, 10 Apr 2003 22:10:45 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, 10 Apr 2003 22:07: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, 10 Apr 2003 22:10:44 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 22:10:43 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id SAA15067; Thu, 10 Apr 2003 18:10:39 -0400 (EDT) Date: Thu, 10 Apr 2003 18:10:39 -0400 (EDT) From: Dan Lanciani Message-Id: <200304102210.SAA15067@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: Globally Unique Private Addresses and Scoped Architecture Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: |> IMHO, it is impossible to reduce the risk as stated. That is, we might be |> able to prevent but ^ deleted important context |> that isn't quite the same thing. Once we have any globally unique ownable |> address space we can make it not-private with auto-tunnels analogous to those |> used for 6to4. All that is required is agreement on a lookup mechanism, and |> I believe that the desire for PI space is strong enough to produce such an |> agreement in the market regardless of what the IETF may do. Now, I happen to | |Dan, | |In my head this "lookup mechanism for auto-tunneling" is merely a |different way of stating that we need to separate identifiers and locators |and have a lookup mechanism to map from an identifier to a (set of) locator(s). No. I've suggested separate identifier/locator schemes in the past (as you know) but they have generally been shot down on the grounds that we don't understand the issues well enough yadda yadda yadda. Here the globally unique ownable space is part of the total space and is no more a separate identifier than is any 6to4 address. Like 6to4 addresses such ownable globals require special considerations to reach, but they are just as capable of conducting a conversation with a "real" global as is any 6to4 address. I suspect that ingress filtering will be used to prevent optimization of the PI->PA route (without filtering you could omit the tunnel) but that won't be much of a deterrent. |If that's what you mean I agree with it, and I think the IETF can gather |enough ideas to be able to engineer a reasonable solution to this problem. It's doubtful that the IETF will "engineer" an identifier/locator solution any time soon for exactly the reasons that they have not already done so. I've given up on such solutions. Fortunately, auto-tunnels and a lookup mechanism are so trivial that they can be glued together with no help from the IETF. |One question I have is whether we today know enough to know what |the structure should be of the identifier or whether the desired structure |of the identifier depends on what type of lookup system we design. This is the kind of unanswerable meta question that has always put identifier/ locator solutions on permanent hold. We will never know "enough" to know that we have made the right choice, so we make no choice. Besides, it's clear that at this point even if we agreed on a separate identifier/locator model it is too late to retrofit it to the existing spec. Let's accept that and move on. |I'm concerned about defining the |globally-unique-globally-visible-in-the-routing-table format |until we at least know that we can build a scalable and robust lookup |function for it. Nobody said anything about such a format. We are talking about a globally unique address space that is *not* visible in the public routing table. This was proposed as a way to replace the functionality lost with site-locals, remember? Once it exists we can turn it into PI space without putting any burden on the core routing tables, but that is just a bonus. Let's not use that bonus as an excuse to defer solving the problem that GUSL/whatever was supposed to solve. Dan Lanciani ddl@danlan.*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 Apr 10 15:13: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 h3AMDQmh005892; Thu, 10 Apr 2003 15:13:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AMDQ0J005891; Thu, 10 Apr 2003 15:13:26 -0700 (PDT) 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 h3AMDMmh005884 for ; Thu, 10 Apr 2003 15:13:22 -0700 (PDT) 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 h3AMDUcU002770 for ; Thu, 10 Apr 2003 15:13:30 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA02961 for ; Thu, 10 Apr 2003 16:13:24 -0600 (MDT) 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, 10 Apr 2003 22:13: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; Thu, 10 Apr 2003 22:13: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, 10 Apr 2003 22:13:22 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; Thu, 10 Apr 2003 22:13:22 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 XAA22404 for ; Thu, 10 Apr 2003 23:13:21 +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 XAA23838 for ; Thu, 10 Apr 2003 23:13:20 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3AMDKO31763 for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 23:13:20 +0100 Date: Thu, 10 Apr 2003 23:13:20 +0100 From: Tim Chown To: IPv6 Subject: Re: C000 Message-Id: <20030410221320.GQ30412@login.ecs.soton.ac.uk> Mail-Followup-To: IPv6 References: <16994.1050003885@munnari.OZ.AU> <63DA971C-6B9C-11D7-8A4A-000393DB42B2@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63DA971C-6B9C-11D7-8A4A-000393DB42B2@nominum.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 10, 2003 at 02:35:46PM -0700, David Conrad wrote: > > What am I missing? So my disconnected network gets a prefix from your autoresponder how? :) 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 Thu Apr 10 15:25: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 h3AMP3mh006508; Thu, 10 Apr 2003 15:25:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AMP2tv006507; Thu, 10 Apr 2003 15:25:02 -0700 (PDT) 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 h3AMOxmh006497 for ; Thu, 10 Apr 2003 15:24:59 -0700 (PDT) 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 h3AMP6cU006712 for ; Thu, 10 Apr 2003 15:25:06 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA00840 for ; Thu, 10 Apr 2003 16:25:00 -0600 (MDT) 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, 10 Apr 2003 22:24:03 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, 10 Apr 2003 22:24: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, 10 Apr 2003 22:24:03 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; Thu, 10 Apr 2003 22:24:03 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 9FC0E146C1; Fri, 11 Apr 2003 08:24:01 +1000 (EST) Date: Fri, 11 Apr 2003 08:24:01 +1000 From: "Nick 'Sharkey' Moore" To: ipng@sunroof.eng.sun.com Cc: Robert Elz Subject: Re: Globally Unique Private Addresses and Scoped Architecture Message-Id: <20030410222401.GC10578@zoic.org> Mail-Followup-To: ipng@sunroof.eng.sun.com, Robert Elz References: <814670000.1049889353@askvoll.hjemme.alvestrand.no> <963621801C6D3E4A9CF454A1972AE8F504F754@server2000.arneill-py.sacramento.ca.us> <12097.1049971145@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12097.1049971145@munnari.OZ.AU> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk G'day kre ... herewith some wild speculation about what people actually mean when they say ... On Thu, Apr 10, 2003 at 05:39:05PM +0700, Robert Elz wrote: > > | at all surprised to see that ISPs will actually route them if offered > | enough money; it's simpler (and therefore cheaper) for them than > | configuring a VPN. > > They don't need to be globally unique for this, just unique within the > relevant domain (area). I think most of the push for uniqueness is the site-merger situation ... tricky if both sites happen to have chosen FEC0:DEAD:BEEF:/48. Easy if they've picked those bits at random though, so that's not a big issue. > If the ISPs can make this work for the customers, why would anyone want > to stop them? :-) That's the kind of thing I keep saying too :-) > That is, I have seen here in the past hour or so while I have been glancing > at some of the past couple of days ipng list traffic, that people seem to > be specifying "non-routable" as a goal. Not as a 'goal', just as a recognized limitation. And what people really mean is 'non-route-aggregable', to differentiate from more majestic efforts trying to get globally routable provider independent addressing. > For what it is worth, this is exactly what FEC0::/10 gives us now. Yeah, I think people have issues with some of the more complex bits of scoping though. I'd propose to replace the tricky bits with a strict scope(source) == scope(destination) for all packets, which seems to clear up issues like 'convexity' quite nicely :-) -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 15:26: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 h3AMQimh006555; Thu, 10 Apr 2003 15:26:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AMQira006554; Thu, 10 Apr 2003 15:26:44 -0700 (PDT) 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 h3AMQfmh006547 for ; Thu, 10 Apr 2003 15:26:41 -0700 (PDT) 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 h3AMQmvV020881 for ; Thu, 10 Apr 2003 15:26:48 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA20937 for ; Thu, 10 Apr 2003 16:26:43 -0600 (MDT) 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, 10 Apr 2003 22:26:42 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, 10 Apr 2003 22:26: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, 10 Apr 2003 22:26:42 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 22:26:41 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id SAA15204; Thu, 10 Apr 2003 18:26:38 -0400 (EDT) Date: Thu, 10 Apr 2003 18:26:38 -0400 (EDT) From: Dan Lanciani Message-Id: <200304102226.SAA15204@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Globally Unique Private Addresses and Scoped Architecture Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: |That is, I have seen here in the past hour or so while I have been glancing |at some of the past couple of days ipng list traffic, that people seem to |be specifying "non-routable" as a goal. That's absurd, why would anyone |explicitly want a non-routable address, even assuming that such a thing |could be constructed? There seem to be some folks who are strongly opposed to allowing users to own PI space that can be routed. Knowing this, some of us who want to have *some* kind of local address space have resigned ourselves to the fact that such space must be crippled in order not to be vetoed by the former group. However, it seems that some of the folks in the first group are also arguing against the ambiguity of site-locals even though ambiguity is the only obvious way to sufficiently cripple the address space and prevent routability. As I've tried to point out in the past few messages, any globally unique ownable address space can be turned into PI space with auto-tunnels in the manner of 6to4, all without putting any burden on the core routing tables. That's for the best, IMHO, but it presents something of a quandary for folks who want neither ambiguous site-locals nor ownable PI space... Dan Lanciani ddl@danlan.*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 Apr 10 15:31: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 h3AMVdmh006781; Thu, 10 Apr 2003 15:31:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AMVcx5006780; Thu, 10 Apr 2003 15:31:38 -0700 (PDT) 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 h3AMVZmh006773 for ; Thu, 10 Apr 2003 15:31:35 -0700 (PDT) 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 h3AMVgvV022364 for ; Thu, 10 Apr 2003 15:31:42 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA23432 for ; Thu, 10 Apr 2003 16:31:37 -0600 (MDT) 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, 10 Apr 2003 22:31: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; Thu, 10 Apr 2003 22:31: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; Thu, 10 Apr 2003 22:31:36 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 22:31:36 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id SAA15242; Thu, 10 Apr 2003 18:31:33 -0400 (EDT) Date: Thu, 10 Apr 2003 18:31:33 -0400 (EDT) From: Dan Lanciani Message-Id: <200304102231.SAA15242@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Addressing Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: |For the direction of work, I have no problem, as I said. But there's |no need to go ripping anything out of the docs that are currently |published RFCs until there is something ready to replace it. | |There's no need for that - unless there's some background assumption |that nothing will ever be produced to replace it, but SL addresses still |have to go anyway. I think it is pretty clear that that is exactly the assumption made by some "YES" voters. Some have stated it explicitly on the grounds that the problems solved by site-locals are not sufficiently important to require solutions in the first place. Others have taken a more subtle approach by claiming that site-locals never actually solved the problems. Dan Lanciani ddl@danlan.*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 Apr 10 15:35: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 h3AMZimh007058; Thu, 10 Apr 2003 15:35:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AMZiMt007057; Thu, 10 Apr 2003 15:35:44 -0700 (PDT) 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 h3AMZemh007047 for ; Thu, 10 Apr 2003 15:35:40 -0700 (PDT) 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 h3AMZhcU010577 for ; Thu, 10 Apr 2003 15:35:43 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id QAA26425 for ; Thu, 10 Apr 2003 16:35:26 -0600 (MDT) 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, 10 Apr 2003 22:35: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; Thu, 10 Apr 2003 22:31: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; Thu, 10 Apr 2003 22:35:24 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 22:35:24 Z Content-class: urn:content-classes:message Subject: RE: FW: Consensus on Site-Local Addressing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Apr 2003 15:35:23 -0700 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F76B@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: FW: Consensus on Site-Local Addressing Thread-Index: AcL/l9xQB4GFaQenSXut5iwiRCmzrgAGSFAw From: "Michel Py" To: "Tony Hain" , "Tim Chown" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3AMZemh007048 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Tony Hain wrote: > Yanking the defined non-PA space will only cause them to pick > random numbers, or turn the documentation space into a different > instance of ambiguous space. Or use 2002:RFC:1918, best pick after FEC0::/10 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 Apr 10 15:39: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 h3AMdJmh007318; Thu, 10 Apr 2003 15:39:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AMdJKi007317; Thu, 10 Apr 2003 15:39:19 -0700 (PDT) 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 h3AMdFmh007307 for ; Thu, 10 Apr 2003 15:39:15 -0700 (PDT) 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 h3AMdLcU012236 for ; Thu, 10 Apr 2003 15:39:22 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA07931 for ; Thu, 10 Apr 2003 16:39:16 -0600 (MDT) 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, 10 Apr 2003 22:39: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; Thu, 10 Apr 2003 22:39:15 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, 10 Apr 2003 22:39:14 Z Received: from fuchsia.home ([203.146.155.23] [203.146.155.23]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 22:39:11 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3AMciS8020582; Fri, 11 Apr 2003 05:38:47 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3AMXop20522; Fri, 11 Apr 2003 05:33:52 +0700 (ICT) From: Robert Elz To: David Conrad cc: Brian E Carpenter , IPv6 Subject: Re: C000 In-Reply-To: <63DA971C-6B9C-11D7-8A4A-000393DB42B2@nominum.com> References: <63DA971C-6B9C-11D7-8A4A-000393DB42B2@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Apr 2003 05:33:50 +0700 Message-Id: <20520.1050014030@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Apr 2003 14:35:46 -0700 From: David Conrad Message-ID: <63DA971C-6B9C-11D7-8A4A-000393DB42B2@nominum.com> | What am I missing? Aside from Tim's response, there's also the issue of why I'm only going to be asking for one a second. I think I'd try more like a thousand a second. If a thousand other people do the same, then the 2^45 space is gone in a year. Why would we do that? Well, after the year, the address space is going to be exhausted, but I'm going to have a nice supply that I can agree to part with some of, for just a small consideration... Now if you make the application refuse to service more than one request a second, to prevent this, then it is going to be pretty difficult for anyone else to ever get a number, because these million requests a second are still arriving, in addition to the few hundred (or so) from "legitimate" users. To prevent this, you need to start doing lots of analysis of the requests, using some non-trivial technology to make sure that you're only allocating addresses to those who deserve them. At this point, the whole thing gets non-trivial. Of course, if there's a non-trivial charge for the numbers, then many of those problems go away - but who gets to keep all that money? How do I get to be someone who gets to allocate an integer in response to a request, and charge $1 for the privilege (and how big a chunk of that 2^45 (or 2^38) can I have just for me, for free... - if not for free, then how do I get to be the organisation that allocates the chunks, for much larger sums, and much less work). All of this really was considered 8 years or so ago (no, I really don't remember when it was) - schemes to allocate numbers look easy, but to make them effective, and reasonable, and able to avoid abuses they're not nearly as simple as they look like they should be. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 10 15:54: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 h3AMsUmh007952; Thu, 10 Apr 2003 15:54:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AMsU7r007951; Thu, 10 Apr 2003 15:54:30 -0700 (PDT) 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 h3AMsRmh007944 for ; Thu, 10 Apr 2003 15:54:27 -0700 (PDT) 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 h3AMsYcU016821 for ; Thu, 10 Apr 2003 15:54:34 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA22025 for ; Thu, 10 Apr 2003 16:54:28 -0600 (MDT) 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, 10 Apr 2003 22:54: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; Thu, 10 Apr 2003 22:54: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; Thu, 10 Apr 2003 22:54:28 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 22:54:27 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 10 Apr 2003 15:54:24 -0700 Reply-To: From: "Tony Hain" To: "'Michel Py'" , "'Tim Chown'" , Subject: RE: FW: Consensus on Site-Local Addressing Date: Thu, 10 Apr 2003 15:54:25 -0700 Message-Id: <0fc801c2ffb4$22d27810$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: <963621801C6D3E4A9CF454A1972AE8F504F76B@server2000.arneill-py.sacramento.ca.us> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3AMsRmh007945 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: > ... > Or use 2002:RFC:1918, best pick after FEC0::/10 Depends on the implementation. Some recognize that space as invalid since the 2002 points to the tunnel interface, but 1918 is not valid on that interface. It would be much easier to use 2001:0DB8::/32 as site controlled space since implementations wouldn't know the difference between it and other 2001 space. Of course since everyone would be using the same /32, it would be just as ambiguous as the FEC0::/10 space people are trying to get rid of. The 2001:0DB8::/32 space is actually worse for the purpose since it only allows 16 bits for local /48 coordination rather than 38. 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 Apr 10 16:07: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 h3AN7Kmh008321; Thu, 10 Apr 2003 16:07:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3AN7Kdw008320; Thu, 10 Apr 2003 16:07:20 -0700 (PDT) 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 h3AN7Gmh008310 for ; Thu, 10 Apr 2003 16:07:16 -0700 (PDT) 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 h3AN7NvV003654 for ; Thu, 10 Apr 2003 16:07:23 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA05213 for ; Thu, 10 Apr 2003 16:07:18 -0700 (PDT) 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, 10 Apr 2003 23: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; Thu, 10 Apr 2003 23:07:17 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, 10 Apr 2003 23:07:17 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 23:07:17 Z Content-class: urn:content-classes:message Subject: RE: FW: Consensus on Site-Local Addressing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Apr 2003 16:07:16 -0700 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F76C@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: FW: Consensus on Site-Local Addressing Thread-Index: AcL/tCKjT/96RXnyRLWGTXt+Jx7XBQAAB3Cw From: "Michel Py" To: "Tony Hain" , "Tim Chown" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3AN7Gmh008311 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, >> Michel Py wrote: >> Or use 2002:RFC:1918, best pick after FEC0::/10 > Tony Hain wrote: > Depends on the implementation. Some recognize that space as > invalid since the 2002 points to the tunnel interface, As pointed out a few days ago in a discussion with Brian Zill it is not a good idea to automatically enable the pseudo-interface on hosts as it breaks things. > but 1918 is not valid on that interface. This is a feature, not a bug. > It would be much easier to use 2001:0DB8::/32 as site controlled > space since implementations wouldn't know the difference between > it and other 2001 space. Of course since everyone would be using > the same /32, it would be just as ambiguous as the FEC0::/10 > space people are trying to get rid of. The 2001:0DB8::/32 space > is actually worse for the purpose since it only allows 16 bits > for local /48 coordination rather than 38. That's why 2002:0A00::/24 is better, collision chances are one out of 16M which I can leave with opposed to 1 out of 64k. 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 Apr 10 16:11: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 h3ANBQmh008652; Thu, 10 Apr 2003 16:11:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ANBQN6008651; Thu, 10 Apr 2003 16:11:26 -0700 (PDT) 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 h3ANBKmh008628 for ; Thu, 10 Apr 2003 16:11:20 -0700 (PDT) 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 h3ANBQvV004983 for ; Thu, 10 Apr 2003 16:11:27 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id RAA11170 for ; Thu, 10 Apr 2003 17:11:19 -0600 (MDT) 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, 10 Apr 2003 23:11: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; Thu, 10 Apr 2003 23:11: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, 10 Apr 2003 23:11:17 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 10 Apr 2003 23:11:17 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 10 Apr 2003 16:11:12 -0700 Reply-To: From: "Tony Hain" To: "'Robert Elz'" , "'David Conrad'" Cc: "'Brian E Carpenter'" , "'IPv6'" Subject: RE: C000 Date: Thu, 10 Apr 2003 16:11:11 -0700 Message-Id: <0fcb01c2ffb6$7c95fb90$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: <20520.1050014030@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > ... > All of this really was considered 8 years or so ago (no, I > really don't remember when it was) - schemes to allocate > numbers look easy, but to make them effective, and > reasonable, and able to avoid abuses they're not nearly as > simple as they look like they should be. Preallocation of a range in an evenly distributed manner would get past the abuse issues, or at least localize them to the granularity of the distribution grid. 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 Apr 10 16:27:22 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 h3ANRLmh009406; Thu, 10 Apr 2003 16:27:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ANRLSM009405; Thu, 10 Apr 2003 16:27:21 -0700 (PDT) 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 h3ANRImh009398 for ; Thu, 10 Apr 2003 16:27:18 -0700 (PDT) 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 h3ANRPcU027141 for ; Thu, 10 Apr 2003 16:27:25 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA14300 for ; Thu, 10 Apr 2003 16:27:20 -0700 (PDT) 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, 10 Apr 2003 23:27: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; Thu, 10 Apr 2003 23:27: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; Thu, 10 Apr 2003 23:27:19 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; Thu, 10 Apr 2003 23:27:18 Z Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KULH837V069AVPV1@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 09:26:59 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2D3D212C003; Fri, 11 Apr 2003 09:26:59 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 184E712C002; Fri, 11 Apr 2003 09:26:59 +1000 (EST) Date: Fri, 11 Apr 2003 09:26:58 +1000 From: Greg Daley Subject: Re: Yet another FEC0::/10 proposal To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: "Nick 'Sharkey' Moore" , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E95FDC2.30609@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 Patrik, Patrik Fa"ltstro"m wrote: [Nick's post cut] > > > As SIP is global voice over IP which ultimately means that A, B and C > can be any node on the Internet, this imply only global scope can be > used for applications, and limited scope can only be used in very very > special and controlled environments (which I would classify is _not_ > "Internet" but instead "some other thing which happens to use IP as the > protocol"). > [rest cut] While I'm sure that SIP is primarily focussed on the Internet, most VoIP systems run site-internally today (albeit with H.323). These systems may not even be on public internets (I would consider running a VPN not reachable from my corporate network's address range for voice communications). In these cases, a locally scoped address space may be a valid choice, since global routability isn't a goal. 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 Apr 10 16:44:12 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 h3ANiCmh009936; Thu, 10 Apr 2003 16:44:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ANiC1O009935; Thu, 10 Apr 2003 16:44:12 -0700 (PDT) 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 h3ANi8mh009928 for ; Thu, 10 Apr 2003 16:44:08 -0700 (PDT) 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 h3ANiFvV014307 for ; Thu, 10 Apr 2003 16:44:15 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id RAA21041 for ; Thu, 10 Apr 2003 17:44:08 -0600 (MDT) 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, 10 Apr 2003 23:41: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; Thu, 10 Apr 2003 23:41: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; Thu, 10 Apr 2003 23:41:51 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; Thu, 10 Apr 2003 23:41:51 Z Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id C35CA137F12; Thu, 10 Apr 2003 16:39:19 -0700 (PDT) Date: Thu, 10 Apr 2003 16:39:18 -0700 Subject: Re: C000 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Brian E Carpenter , IPv6 To: Robert Elz From: David Conrad In-Reply-To: <20520.1050014030@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, April 10, 2003, at 03:33 PM, Robert Elz wrote: > Aside from Tim's response, Which, given the smiley, I assume was in jest. If it wasn't, I've got a few billions of hours worth of AOL "1035 hours free" CDs I'd be happy to send his way. > there's also the issue of why I'm only > going to be asking for one a second. I didn't assume that. I said the auto-responder would respond to one per second (or 10 or 100 or 1000, 2^45 is a _lot_). > I think I'd try more like > a thousand a second. If a thousand other people do the same, then > the 2^45 space is gone in a year. *Yawn* So, the automated system keeps track of the requesting address and drops multiple requests from the same source. This is just silly. Yes, we can all come up with DoS attacks that can disable a service like this. We can also come up with remedies against many of those attacks. Arms races are fun. What is the point? We're talking about allocating a globally unique prefix for each non-connected sites to remove what some consider a wart/unnecessary and/or ill-defined complexity that will result in duplicate addresses. You want to connect, you're going to have to get a prefix from your ISP and renumber anyway. The advantages to allocating a globally unique prefix are well known. The disadvantage is that someone/something has to insure global uniqueness. Given 2^45, it would be mind-numbingly easy to determine whether or not an automated system was being abused _LONG_ before any even close to significant portion of the prefixes were consumed. The allocating organization(s) then come up with solutions to the abuse and wait for the next abuse mechanism to appear. I do not see why this requires a perfect theoretical solution when a pragmatic engineering solution will be good enough and is so bloody easy. This entire discussion has been really depressing. People seem to be arguing theoretical positions instead of trying to come up with engineering solutions to what is, fundamentally, a non-problem. Non-connected sites are going to have to renumber if they want to connect (at least according to the current routing paradigm). Given that, we might as well make it easier for non-connected sites that want to talk to each other. Who knows, maybe somebody will come up with a way to flat route 2^48 in the million years between now and when the first /3 is consumed. Sheesh. 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 Thu Apr 10 17:02: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 h3B02Wmh010342; Thu, 10 Apr 2003 17:02:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B02VNr010341; Thu, 10 Apr 2003 17:02:31 -0700 (PDT) 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 h3B02Rmh010328 for ; Thu, 10 Apr 2003 17:02:27 -0700 (PDT) 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 h3B02YcU007564 for ; Thu, 10 Apr 2003 17:02:35 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA13102 for ; Thu, 10 Apr 2003 18:02:29 -0600 (MDT) 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, 11 Apr 2003 00: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; Fri, 11 Apr 2003 00:02: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; Fri, 11 Apr 2003 00:02:22 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 00:02:21 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 10 Apr 2003 17:00:12 -0700 Reply-To: From: "Tony Hain" To: "'David Conrad'" , "'Robert Elz'" Cc: "'Brian E Carpenter'" , "'IPv6'" Subject: RE: C000 Date: Thu, 10 Apr 2003 17:00:12 -0700 Message-Id: <0fd101c2ffbd$5369ce20$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 David Conrad wrote: > You want to connect, you're going to > have to get > a prefix from your ISP and renumber anyway. This statement keeps being made as if there is magic in connected status. The reality is that in IPv6, renumbering is simply adding a prefix. There is no requirement that any other prefixes go away. In particular, a stable site controlled prefix will not go away no matter where it came from. > ... > Non-connected sites are going to have to renumber if they want to > connect (at least according to the current routing paradigm). Or simply pay *enough* to get their prefix of choice routed. 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 Apr 10 18:03:02 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 h3B132mh011024; Thu, 10 Apr 2003 18:03:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B132jd011023; Thu, 10 Apr 2003 18:03:02 -0700 (PDT) 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 h3B12wmh011016 for ; Thu, 10 Apr 2003 18:02:58 -0700 (PDT) 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 h3B135vV004435 for ; Thu, 10 Apr 2003 18:03:06 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id TAA05251 for ; Thu, 10 Apr 2003 19:02:59 -0600 (MDT) 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, 11 Apr 2003 00:59: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, 11 Apr 2003 00:55:54 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, 11 Apr 2003 00:59:27 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; Fri, 11 Apr 2003 00:59:27 Z Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 3263E137F12; Thu, 10 Apr 2003 17:56:52 -0700 (PDT) Date: Thu, 10 Apr 2003 17:56:51 -0700 Subject: Re: C000 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'Robert Elz'" , "'Brian E Carpenter'" , "'IPv6'" To: From: David Conrad In-Reply-To: <0fd101c2ffbd$5369ce20$ee1a4104@eagleswings> Message-Id: <7B52DDA8-6BB8-11D7-8A4A-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, On Thursday, April 10, 2003, at 05:00 PM, Tony Hain wrote: > The reality is that in IPv6, renumbering is simply adding a > prefix. There is no requirement that any other prefixes go away. Pragmatically speaking, I believe this requirement will be made by ISPs when you move from one provider to another. Even if it isn't, you will (perhaps eventually) have to garbage collect all the non-useful prefixes from router configs, firewall rules, network management packages, etc. > In > particular, a stable site controlled prefix will not go away no matter > where it came from. Yes, and barring NAT, you still need to number the site with the provider's prefix you obtained to gain connectivity. Given this, I don't see any particular value in using a prefix guaranteed to be ambiguous over a globally unique prefix (assuming the globally unique prefix can be obtained trivially). >> Non-connected sites are going to have to renumber if they want to >> connect (at least according to the current routing paradigm). > Or simply pay *enough* to get their prefix of choice routed. Only if they have globally unique prefixes (which I thought you were arguing against). And besides, pay whom? Potentially each and every ISP in front of each and every site they want to reach? If this were easy, why aren't we doing it with IPv4 now? 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 Thu Apr 10 18:08:48 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 h3B18mmh011149; Thu, 10 Apr 2003 18:08:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B18mna011148; Thu, 10 Apr 2003 18:08:48 -0700 (PDT) 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 h3B18imh011141 for ; Thu, 10 Apr 2003 18:08:44 -0700 (PDT) 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 h3B18pvV006035 for ; Thu, 10 Apr 2003 18:08:52 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id SAA24740 for ; Thu, 10 Apr 2003 18:08:46 -0700 (PDT) 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, 11 Apr 2003 01:08:43 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, 11 Apr 2003 01:08: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, 11 Apr 2003 01:08:43 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; Fri, 11 Apr 2003 01:08: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 SAA10271; Thu, 10 Apr 2003 18:08:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3B18eT28838; Thu, 10 Apr 2003 18:08:40 -0700 X-mProtect: <200304110108> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQuzQkG; Thu, 10 Apr 2003 18:08:38 PDT Message-Id: <3E9615BD.4090802@iprg.nokia.com> Date: Thu, 10 Apr 2003 18:09:17 -0700 From: Charlie Perkins Organization: Nokia 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: alh-ietf@tndh.net CC: "'IPv6'" Subject: Re: C000 References: <0fb601c2ff9f$c9a6f400$ee1a4104@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Tony, Tony Hain wrote: >>Administrations that left the provider-independent addresses >>routable only within their domain should still see that the >>traffic is dropped instead of exiting their domain. >> >> > >You missed the point. For this to work as you describe, the application >had to do something to recognize the different scopes of the addresses >available to it. If it does nothing and expects all addresses to have a >single scope, it will recover into a state that the network manager >wants to preclude. > I _did_ mean that the application should not distinguish the scope by considering the address. I guess you mean to suggest that the application should distinguish its inferred level of security for the data transfer based on whether the destination is site-local or not. This suggestion, though, can only work one time. If an application needs to make _two_ distinctions (for, say, two different reasons, or two different levels of security), site-local cannot help. Doesn't this mean that the addressing is effectively imbued with some other characteristic(s) (like security level in this case)? I thought that associating the address structure with application- defined semantics was "bad". I'm remembering the "porn bit". >If a single entity is in control of routing announcements, the >confidence level of it being correct is higher, though most would >recognize that errors happen. When sites interconnect, or service >providers have explicit instructions for custom handling of prefixes, >there is an opportunity for error outside the origin sites control. > Do you mean, that some other site would advertise a PI prefix that actually belonged to the origin site? It seems to me that this wouldn't wreak too much damage as long as the core routers didn't have to accept the prefix. >Ambiguity raises the confidence level that filtering will happen even in >the case of errors, because the well-known prefix will be filtered at >multiple levels. > It seems to be a tricky business to predict which of several possible protocol or administrative errors would be more likely, but in this case it seems to me that there isn't much difference. If I had an "ambiguous" prefix, and a friend to route it for me, I might ought to warn my friend that it was ambiguous. But even if I was lax, I'd still expect my friend to honor an agreement that we might make. Thus, the "ambiguous" case has "more" error potential, it seems to me. Suggesting that ambiguity is a stronger deterrent than mandating exclusion from the core routers is pretty speculative, isn't it? >>I am suggesting that there may be a large population that >>hold these opinions, and if the members of that large >>population are willing to forego their other needs for a >>little while, we might move forward more quickly now. The >>other needs would then become priority items to be met as >>soon as the proponents figure out how. >> >> > >Wrong order, and from what I can tell many hold the opinion that we >should remove ambiguity simply on the promise that we might find an >alternative. We are much more likely to find alternatives if those who >want ambiguity to go away are motivated. If ambiguity goes away, it will >be much harder to get the group to agree that the other needs are in >fact priorities. > I'd rather suggest that we build on smaller successes instead of keeping around bugs for people to fix. The danger might be that the buggy stuff would get more and more ingrained to the point of permanence. Ambiguous addresses seem "buggy" even by your description of their value. >>Anyone who does not want to route PI addresses should have >>the authority of RFC 36fb (fb == foobar) to back them up! >> >> > >Cash speaks much louder than an RFC, particularly if the competitor is >willing to ignore the RFC to get it. > But that's fine with me too. I only suggest that the non-aggregable prefix should not get into the core routing tables. If someone wants to route it by other means, why not? Even if one of the core routers advertises such a prefix, all the others "should' ignore it or flag it as an error. I don't see this as a terrible problem... >>So why can't this be done within the context of an allocated >>space of provider-independent but NOT-globally-routable >>addresses, by the same specification that deprecates site-local? >> >> > >If it meets all the needs, I have no problem. That is not what the >chair's plan of action is though. > Good plans can take improvements into account, and if there were some acceptable consensus I bet it would carry weight. > Item 1) specifically calls for >deprecation, then item 4) identifies requirements for a replacement, >followed by possible future work items on solutions if the group comes >to consensus on requirements and the charter is appropriately updated. >The point is there are many opinions on what is right here, and until >they result in a viable alternative that all agree to, the current plan >must remain in place. > A plan that gets (a lot?) more than the existing amount of consensus could be called "better", in a way. I think the non-globally-routable GUPI plan has some chance at that. > >We must not fall in the trap of proclaiming 'there must be a simple >solution' and deprecating the only tool we have. We must find a solution >that all can accept first. > > Well, that's not what I'm suggesting. I'm only suggesting that there might be a better plan (non-globally-routable GUPI) that is acceptable to _more_ people (not everybody). It's simple, because it's incomplete. 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 Thu Apr 10 18:11:04 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 h3B1B4mh011295; Thu, 10 Apr 2003 18:11:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B1B4XC011294; Thu, 10 Apr 2003 18:11:04 -0700 (PDT) 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 h3B1B0mh011281 for ; Thu, 10 Apr 2003 18:11:00 -0700 (PDT) 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 h3B1B7cU024776 for ; Thu, 10 Apr 2003 18:11:07 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id TAA18735 for ; Thu, 10 Apr 2003 19:10:48 -0600 (MDT) 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, 11 Apr 2003 01:09:04 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, 11 Apr 2003 01:09: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; Fri, 11 Apr 2003 01:09:03 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 01:09:03 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 14816146C0; Fri, 11 Apr 2003 11:08:59 +1000 (EST) Date: Fri, 11 Apr 2003 11:08:59 +1000 From: "Nick 'Sharkey' Moore" To: IPv6 Cc: Brian E Carpenter Subject: Re: C000 Message-Id: <20030411010858.GB14736@zoic.org> Mail-Followup-To: IPv6 , Brian E Carpenter References: <3E957221.254CD6D5@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E957221.254CD6D5@hursley.ibm.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 10, 2003 at 03:31:13PM +0200, Brian E Carpenter wrote: > > Assume that we consider stable, probably unique, > unrouteable prefixes important enough to get their own 3-bit > prefix, and for the sake of argument let's pick C000::/3. I dunno, I'm not sure that that's called for. I'd agree that we'd probably like to generate /48s, but I think that 2^38 of them is probably enough. Remember, the uniqueness constraint is really just there to ease site mergers. > [...] Therefore, assume we have a way of generating such > prefixes under C000::/3. I'd rather see: 1) something useful using FEC0:/10 very soon, eg: non-aggregable non-globally-routed. provider-independent addresses (GUPIs) 2) some further work on route-aggregable PI addressing, which could more usefully be assigned a block like C000:/3. -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 18:14:53 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 h3B1Eqmh011683; Thu, 10 Apr 2003 18:14:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B1Ep9L011673; Thu, 10 Apr 2003 18:14:51 -0700 (PDT) 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 h3B1Elmh011657 for ; Thu, 10 Apr 2003 18:14:47 -0700 (PDT) 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 h3B1EscU025967 for ; Thu, 10 Apr 2003 18:14:54 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id TAA20755 for ; Thu, 10 Apr 2003 19:14:47 -0600 (MDT) 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, 11 Apr 2003 01:14: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; Fri, 11 Apr 2003 01:14: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; Fri, 11 Apr 2003 01:14:45 Z Received: from ALPHA8.ITS.MONASH.EDU.AU (ALPHA8.ITS.MONASH.EDU.AU [130.194.1.8]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 01:14:44 Z Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KULKPHZY4W9BXZ28@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 11:06:32 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id D92EF12C008; Fri, 11 Apr 2003 11:06:31 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id BFAE412C007; Fri, 11 Apr 2003 11:06:31 +1000 (EST) Date: Fri, 11 Apr 2003 11:06:31 +1000 From: Greg Daley Subject: Re: C000 To: Tim Chown Cc: IPv6 Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E961517.9040703@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: <16994.1050003885@munnari.OZ.AU> <63DA971C-6B9C-11D7-8A4A-000393DB42B2@nominum.com> <20030410221320.GQ30412@login.ecs.soton.ac.uk> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tim, Tim Chown wrote: > On Thu, Apr 10, 2003 at 02:35:46PM -0700, David Conrad wrote: > >>What am I missing? > > > So my disconnected network gets a prefix from your autoresponder how? :) I'm sure they could put a fax number on the website ;) 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 Thu Apr 10 18:22: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 h3B1Mvmh012349; Thu, 10 Apr 2003 18:22:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B1Mv4A012348; Thu, 10 Apr 2003 18:22:57 -0700 (PDT) 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 h3B1Mrmh012341 for ; Thu, 10 Apr 2003 18:22:53 -0700 (PDT) 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 h3B1N1vV010202 for ; Thu, 10 Apr 2003 18:23:01 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id TAA20986 for ; Thu, 10 Apr 2003 19:22:55 -0600 (MDT) 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, 11 Apr 2003 01:22: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, 11 Apr 2003 01:22:54 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, 11 Apr 2003 01:22:54 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 01:22:54 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id F1ADE146C0; Fri, 11 Apr 2003 11:22:52 +1000 (EST) Date: Fri, 11 Apr 2003 11:22:52 +1000 From: "Nick 'Sharkey' Moore" To: ipng@sunroof.eng.sun.com Cc: Charlie Perkins Subject: Re: C000 Message-Id: <20030411012252.GC14736@zoic.org> Mail-Followup-To: ipng@sunroof.eng.sun.com, Charlie Perkins References: <0fb601c2ff9f$c9a6f400$ee1a4104@eagleswings> <3E9615BD.4090802@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E9615BD.4090802@iprg.nokia.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 10, 2003 at 06:09:17PM -0700, Charlie Perkins wrote: > > Doesn't this mean that the addressing is effectively imbued with > some other characteristic(s) (like security level in this case)? > I thought that associating the address structure with application- > defined semantics was "bad". I'm remembering the "porn bit". I'd agree, in so far as deciding what a scope 'means' from the scope is a flawed approach ... maybe _this_ GUPI is my sooper- secure VPN, but _that_ GUPI is my experimental broadcast radio interface ... I think it would be good for nodes to be able to recognize the difference between scopes though, and avoid sending packets which cross scopes. That would clear up a lot of the issues re: convexity, etc. > But that's fine with me too. I only suggest that the non-aggregable prefix > should not get into the core routing tables. If someone wants to route it > by other means, why not? Eg: tunnels, presumably. Yeah, I don't see a problem with that, if the Illuminati want a globally-routable PI network running over VPN tunnels, they can have one ... and organize their own route aggregation. > Well, that's not what I'm suggesting. I'm only suggesting that there might > be a better plan (non-globally-routable GUPI) that is acceptable to > _more_ people (not everybody). It's simple, because it's incomplete. Hmmm ... maybe we should complete it, and see if it's still simple! -----Nick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 10 18:24: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 h3B1Obmh012408; Thu, 10 Apr 2003 18:24:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B1Ob9W012407; Thu, 10 Apr 2003 18:24:37 -0700 (PDT) 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 h3B1OXmh012397 for ; Thu, 10 Apr 2003 18:24:33 -0700 (PDT) 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 h3B1OecU002843 for ; Thu, 10 Apr 2003 18:24:40 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id TAA23783 for ; Thu, 10 Apr 2003 19:24:34 -0600 (MDT) 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, 11 Apr 2003 01:24:34 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP; Fri, 11 Apr 2003 01:24:33 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP; Fri, 11 Apr 2003 01:24:33 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay1.sun.com with ESMTP; Fri, 11 Apr 2003 01:24:33 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.33]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA08200; Thu, 10 Apr 2003 18:23:37 -0700 (PDT) Message-Id: <5.1.0.14.2.20030410211315.040e7b58@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Apr 2003 21:21:27 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: FW: Consensus on Site-Local Addressing Cc: Leif Johansson , alh-ietf@tndh.net, "'Thomas Narten'" , "'Erik Nordmark'" , ipng@sunroof.eng.sun.com In-Reply-To: <12021.1049968567@munnari.OZ.AU> References: <3E94FC4F.4070309@it.su.se> <3E94FC4F.4070309@it.su.se> <0f4201c2fef9$ef22eaf0$ee1a4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, >If one really wanted a vote (which I don't think is the correct answer >anyway, for anything) the right way to do it on the list would be to >ask everyone with an opinion to express it on the list. Then there >would be a simple record, and everyone could add up the numbers and >verify them. Actually, RFC 2418, section 3.3 explicitly says: "In the case where a consensus which has been reached during a face- to-face meeting is being verified on a mailing list the people who were in the meeting and expressed agreement must be taken into account." 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 Apr 10 18:26:28 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 h3B1QRmh012519; Thu, 10 Apr 2003 18:26:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B1QRYf012518; Thu, 10 Apr 2003 18:26:27 -0700 (PDT) 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 h3B1QNmh012506 for ; Thu, 10 Apr 2003 18:26:23 -0700 (PDT) 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 h3B1QUvV011088 for ; Thu, 10 Apr 2003 18:26:30 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id TAA14368 for ; Thu, 10 Apr 2003 19:26:25 -0600 (MDT) 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, 11 Apr 2003 01:26:25 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, 11 Apr 2003 01:26:24 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, 11 Apr 2003 01:26:24 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 01:26:24 Z Content-class: urn:content-classes:message Subject: RE: Consensus on Site-Local Addressing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Apr 2003 18:26:23 -0700 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F76E@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: Consensus on Site-Local Addressing Thread-Index: AcL/iOKufi7YukvYRvWfFfvMjBRwiwALaVZg From: "Michel Py" To: "Fred L. Templin" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3B1QOmh012509 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, >>> Fred L. Templin wrote: >>> A fundamental question here is whether the disconnected/ >>> intermittently connected networks will require subnetting >>> internally. When subnetting is not required, link-local >>> addressing (i.e., FE80::/10) may be enough. >> Michel Py wrote: >> There are many cases where these sites would indeed require >> local subnetting. > Is your statement based on proven fact or best current > practices and/or On current practices (I would not go as far as calling them best) and on customer demands/RFPs. There are situations like Tony's ship and more generally large habited mobile objects, and situations such as utility companies that have extremely large numbers of discrete (read: no human glued to the keyboard) devices for monitoring and control of the business (electricity, water, sewer system, etc). These sites can be extremely large and are either intermittently connected or partially connected (meaning only a small part of the site) to the public Internet. > I am not trying to be critical/sarcastic; just pointing out that > we may need to examine long-held beliefs as we find a way forward. It is clear that _some_ of the motives behind these demands are based on not-that-long-held beliefs, namely two of them: 1. Renumbering is a pain in the kazoo. 2. Private addresses are more secure. Before analyzing how true these beliefs are, let me tell you that discussing this in here is irrelevant. I am not the one writing the RFPs and I am not going to waste time and potentially lose customers by explaining them that they are stupid. I'll do what I can, but in the end the customers pay and get what they want because I want them to be happy and give me more of their business. If they want routers to be painted pink I will paint them myself and if they want RFC1918 addresses even if they actually own a portable class A they will get them too. You can lead the horse to the water, but can't make it drink. Still with me? 1. Renumbering is a pain in the kazoo. I hear American organizations telling me that they would prefer hiring Saddam Hussein as CEO instead of renumbering their production private network. This is based on multiple way-behind-deadline way-over-budget catastrophes some of which (especially the kind that included a flag day) had to be rolled back at extreme costs. In my experience, IPv6 has not changed anything WRT this. In the cost of renumbering a large network, the part that is about actually renumbering devices (read: change the address on all the devices) represents 5% or 10% of the bottom line. Even if the IPv6 part of this was perfect (and it's not) this still leaves us with 90% or 95% of a pain in the kazoo which by all practical means is still called a pain. Renumbering is a major pain, not a belief. 2. Private addresses are more secure. Note that I did not say "private addresses are secure". Some of the networks I have to deal with have anywhere from two to six layers of firewalls between the edge and the inside of the network (which is not the core). There are multiple access-lists and stateful inspection all over the place. Although it is true that private addresses can be routed over a tunnel, this is also is a know phenomenon and protocols suitable for tunneling are blocked or monitored. This is one of the things that is part of the defense in depth: Make the life of the hacker complicated. Attacks are a lot easier to detect in the inside than at the edge. It is a well-know phenomenon (often used by security companies sales droids) that if you plug an intrusion detection device at the edge of the public network it will immediately scream that a dozen IPs are trying to hack you. This is network noise; we know it and there are some types of alarm that everyone deactivates the reason being there are so many of them that nobody has time to investigate. However, in the inside of the network, any blip reported by the IDS is investigated, the reason being that there are almost none. Specifically, any traffic to port 80 from a regulation valve is highly suspicious. Regulation valves do not surf the web on their own. So yes, private addresses are a plus for security because they make suspicious patterns easier to identify and any attempt to tunnel them out not only requires skill but will fail and will also trigger alarms all over the place. Keep in mind: the market does not get what it wants, but it does get what it has money to pay for and this includes private addresses whether the IETF likes it or not. 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 Apr 10 18:37:14 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 h3B1bDmh013174; Thu, 10 Apr 2003 18:37:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B1bDq3013173; Thu, 10 Apr 2003 18:37:13 -0700 (PDT) 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 h3B1bAmh013163 for ; Thu, 10 Apr 2003 18:37:10 -0700 (PDT) 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 h3B1bHcU006324 for ; Thu, 10 Apr 2003 18:37:17 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id TAA22608 for ; Thu, 10 Apr 2003 19:37:11 -0600 (MDT) 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, 11 Apr 2003 01:37: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; Fri, 11 Apr 2003 01:37:10 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, 11 Apr 2003 01:37: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; Fri, 11 Apr 2003 01:37:09 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 CAA23980 for ; Fri, 11 Apr 2003 02:37:04 +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 CAA27908 for ; Fri, 11 Apr 2003 02:37:04 +0100 (BST) Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3B1b4I18091 for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 02:37:04 +0100 Date: Fri, 11 Apr 2003 02:37:04 +0100 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: C000 Message-Id: <20030411013704.GQ2303@ecs.soton.ac.uk> References: <0fd101c2ffbd$5369ce20$ee1a4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0fd101c2ffbd$5369ce20$ee1a4104@eagleswings> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I might have missed something here, but... Wy dont we go with something like C000::/3 and then allocate prefixes within that to the various different uniqueness mechanims such as geo, MAC, time, requested, manual, random etc? I think it's quite clear that people had very different requirements from SLs, perhaps their main strength was simply as a big chunk of free to use address space. It would be nice if this quality could be preserved whilst removing the ambiguity and consequent scope issues. C000::/3 addresses could be treated as global (imho) so existing implementations wouldn't need changing. With ISP support it's possible that some schemes really could become globally routable and thus offer some degree of provider independance. I think something like this would be simple to implement today and hopefully would address a lot of the concerns people had with SLs. 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 Thu Apr 10 18:43:30 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 h3B1hUmh013514; Thu, 10 Apr 2003 18:43:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B1hTFe013513; Thu, 10 Apr 2003 18:43:29 -0700 (PDT) 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 h3B1hQmh013503 for ; Thu, 10 Apr 2003 18:43:26 -0700 (PDT) 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 h3B1hXvV015662 for ; Thu, 10 Apr 2003 18:43:33 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id TAA29767 for ; Thu, 10 Apr 2003 19:43:27 -0600 (MDT) 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, 11 Apr 2003 01:43: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; Fri, 11 Apr 2003 01:43: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, 11 Apr 2003 01:43:26 Z Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 01:43:26 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3B1hGmi013452; Thu, 10 Apr 2003 18:43:17 -0700 (PDT) Received: from cisco.com (sjc-vpn3-695.cisco.com [10.21.66.183]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA01223; Thu, 10 Apr 2003 18:43:15 -0700 (PDT) Message-Id: <3E961DB1.7080509@cisco.com> Date: Thu, 10 Apr 2003 18:43:13 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'Margaret Wasserman'" , "'Brian Haberman'" , "'Brian E Carpenter'" , "'IPv6'" Subject: A review of draft-hain-ipv6-sitelocal-00.txt (was Re: C000) References: <0f9501c2ff8b$9ca5be00$ee1a4104@eagleswings> In-Reply-To: <0f9501c2ff8b$9ca5be00$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: > >>... >>That's why I think we should start by trying to figure out >>what our requirements are for local addressing -- or at least >>what the problems statement is... >> >>Then, we can try to figure out what type of addressing and/or >>other mechanisms can be used to meet those needs with the >>fewest limitations, the least complexity and the lowest >>impact on other parts of the protocols stack. >> >>I'm not sure where to start, though... > > > I offer draft-hain-ipv6-sitelocal-00.txt as a starting point. Ok, let's take a look at this document. > Most of the arguments against the use of site-local addresses amount > to wanting applications to work even in the presence of intentional > filtering imposed by the network manager. The argument to remove > site-local addresses from the architecture is equivalent to; we > should prevent you from doing harm to yourself by insisting that > scissors were never invented, that way we don't have to keep telling > you not to run with them. Filtering will exist in networks, so there > will be domains of applicability, or scopes. Applications that > insist on passing topology information outside its domain of > applicability will fail to operate correctly. I believe that you have misunderstood other peoples' arguments. Nobody denies that filtering will occur. However, people have raised concerns about how an API should interpret a site-local as opposed to a globally scoped address. There is also a response time issue, as well as the security of ICMP to consider at the same time. How long do you get to complete a phone call? > The site-local address format uniquely identifies interfaces within > a single administrative domain of applicability. Site-local > addresses are designed to provide stable addresses for use inside a > site. Let us delve deeper than this. Why is it that stable addresses are so necessary? Could it be because renumbering is painful? Could that be one source of our ills? Jumping around a bit... > Private space is used to avoid exposing to competitors what internal > networks they are deploying and which office is coordinating that > effort. One needn't have private address space to avoid this problem. You don't need private address space to conceal topology. > Network managers also don't have to expose business plans to > a registrar for evaluation for networks that are not attached to the > global Internet. I think this is a real problem, because registrars still do not understand the amount of address space they have. Simply charge a linearly increasing fee and be done with it. > Some have stated that if they are required to > register for public space for every internal use network, they are > more likely to pick random numbers than tip off the competition. Because of the other problems. And indeed they may be better off doing so, even so. Which brings us to: > Another significant use of private address space is test networks. > Frequently these are large, elaborate networks with a mix of public > and private address space. Use of random unallocated space runs the > risk of collision with legitimate addresses on remote networks. Yes, but it's a very low risk. Far lower than IPv4. But you also miss a point. The reason people use private address space today is simply because of the hassle of getting it allocated. Fix the registries and this largely goes away. Finally, from your security considerations section: > Access control is one aspect of what SL provides. It is a clear > address space that service providers can put in bogon filters, and > enterprise managers can filter without having to go into detail > about which specific devices on a subnet are allowed in or not. It > does not comprise a full service security solution, and should not > be sold as such. It is simply a way to clearly articulate the > difference between public and private endpoints. While I understand why you would think this, it was a huge mistake for the providers to believe this with RFC 1918 addresses. Every time someone advertises a bogus route to a real network I kick myself because people thought RFC 1918 would solve that problem. It won't. Filtering of site-locals is nothing more or less than filtering any other address range. We now know through fast and hard experience that such permissive mechanisms are BAD for the Internet. Let's not make this same mistake again. > The cynical might consider this a 3-year effort that will simply > redesign the current SL, since the current SL was the result of a > trade-off between the demand for site controlled address space, and the > routing communities conflicting demand that any address space not > provider aligned have an enforceable means of keeping it out of the > global routing tables. The cynical would say that 8+8 was given short shrift. 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 Thu Apr 10 20:01:30 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 h3B31Tmh014080; Thu, 10 Apr 2003 20:01:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B31Tcf014079; Thu, 10 Apr 2003 20:01:29 -0700 (PDT) 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 h3B31Qmh014072 for ; Thu, 10 Apr 2003 20:01:26 -0700 (PDT) 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 h3B31XcU021943 for ; Thu, 10 Apr 2003 20:01:33 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id UAA24560 for ; Thu, 10 Apr 2003 20:01:28 -0700 (PDT) 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, 11 Apr 2003 03:01:27 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, 11 Apr 2003 03:01:27 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, 11 Apr 2003 03:01:27 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 03:01:26 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id XAA16602; Thu, 10 Apr 2003 23:01:23 -0400 (EDT) Date: Thu, 10 Apr 2003 23:01:23 -0400 (EDT) From: Dan Lanciani Message-Id: <200304110301.XAA16602@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: C000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Nick 'Sharkey' Moore" wrote: |> But that's fine with me too. I only suggest that the non-aggregable prefix |> should not get into the core routing tables. If someone wants to route it |> by other means, why not? | |Eg: tunnels, presumably. Yeah, I don't see a problem with that, |if the Illuminati want a globally-routable PI network running |over VPN tunnels, they can have one ... and organize their own |route aggregation. Don't think in terms of VPN tunnels; these simulate links and create a virtual model of the net with equivalent problems. Think in terms of auto-tunnels like those used for 6to4. Instead of looking inside the v6 destination address to find the v4 tunnel destination you look up (and cache) the v6 tunnel destination of the machine that knows how to deliver your packet. The nice thing about such a network is that it doesn't depend on route aggregation in the first place. Because the routing knowledge (i.e., which tunnel destination do I need) is distributed across all the sites, the scaling issues that afflict full-knowledge central-routing models do not exist. As has always been the case, everyone can have routable PI space at the cost of an approximate doubling in header bloat. (We could have done better than that by embracing source routing directly, but it isn't clear that it matters much now.) The great thing about making unique "local" address space available to end users is that the market will get to decide whether routable PI space is worth that doubling. Dan Lanciani ddl@danlan.*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 Apr 10 21:32:14 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 h3B4WDmh014573; Thu, 10 Apr 2003 21:32:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B4WDwZ014572; Thu, 10 Apr 2003 21:32:13 -0700 (PDT) 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 h3B4W9mh014559 for ; Thu, 10 Apr 2003 21:32:09 -0700 (PDT) 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 h3B4WGvV014675 for ; Thu, 10 Apr 2003 21:32:16 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id WAA28722 for ; Thu, 10 Apr 2003 22:32:10 -0600 (MDT) 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, 11 Apr 2003 04:32:08 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, 11 Apr 2003 04:32: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; Fri, 11 Apr 2003 04:32:08 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, 11 Apr 2003 04:32:07 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 VAA17455; Thu, 10 Apr 2003 21:32:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3B4W4a15587; Thu, 10 Apr 2003 21:32:04 -0700 X-mProtect: <200304110432> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNJqT7P; Thu, 10 Apr 2003 21:32:02 PDT Message-Id: <3E96456A.5000407@iprg.nokia.com> Date: Thu, 10 Apr 2003 21:32:42 -0700 From: Charlie Perkins Organization: Nokia 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: Robert Elz CC: alh-ietf@tndh.net, "'IPv6'" Subject: Re: C000 References: <3E95B788.DB9921CE@iprg.nokia.com> <0f9401c2ff89$747bad60$ee1a4104@eagleswings> <17632.1050005444@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Robert, Robert Elz wrote: > | What do you think about the proposal to define a block of > | addresses for use as globally-unique but not globally routable > | addresses? That's _not_ a single routing "scope". > >No, but it is essentially identical to what we currently have. There >are almost no real practical differences. Why change? > I would think that a solution that doesn't have scope built into the addressing architecture, and that has few practical operational differences from site-local, would be a good choice. The reason for change would be to eliminate ambiguous addresses. > | It would be nice if we could get some quick action on something > | along those lines that would (a) allow site-locals to be deprecated > | according to the wishes of many people and yet (b) allow the use > | of provider-independent addresses according to the wishes of many > | people. Maybe if a lot of people found this to be a solution of > | their most important wishes we could move forward more quickly. > >Yes, if that could be done, it would be fine. The problem is, that the >last time this was attempted, (a) was the result of the search for (b). >What makes you sure that the result would be different this time? > I'm not sure! But I would like to see a way to have the kind of provider independence that site-local provides, and this is a way to do it that is "compatible" with the vote to eliminate site-locals. Making more people happy and giviing more people what they need/want is a better outcome than just eliminating site-locals. >Or different in a way other than "no consensus was achieved for any >particular non routable addressing scheme so we won't have one" > Well, at least they're routable away from the core, unique, and useful right away. Why do you say that "globally unique, provider independent, non-globally-routable" is not a particular choide for an addressing scheme? Do you mean that it's not specific enough? Additional specification would come later as needed. My proposal is to specify some useful address range at the same time that site-locals are deprecated. I don't even care if it's FEC0/10 but there are surely arguments pro and con and maybe somewhere else is less controversial. 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 Fri Apr 11 01:39: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 h3B8dhmh017764; Fri, 11 Apr 2003 01:39:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B8dh91017763; Fri, 11 Apr 2003 01:39:43 -0700 (PDT) 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 h3B8demh017756 for ; Fri, 11 Apr 2003 01:39:40 -0700 (PDT) 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 h3B8dlcU023880 for ; Fri, 11 Apr 2003 01:39:47 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id BAA19729 for ; Fri, 11 Apr 2003 01:39:41 -0700 (PDT) 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, 11 Apr 2003 08:39:38 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, 11 Apr 2003 08:39: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; Fri, 11 Apr 2003 08:39:38 Z Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 08:39:37 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3B8ckju027840; Fri, 11 Apr 2003 10:38:47 +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 h3B8cjnP252716; Fri, 11 Apr 2003 10:38:46 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34390 from ; Fri, 11 Apr 2003 10:38:37 +0200 Message-Id: <3E967F3A.22803DBC@hursley.ibm.com> Date: Fri, 11 Apr 2003 10:39:22 +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: IPv6 Subject: Re: C000 References: <16994.1050003885@munnari.OZ.AU> <63DA971C-6B9C-11D7-8A4A-000393DB42B2@nominum.com> <20030410221320.GQ30412@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 Thu, Apr 10, 2003 at 02:35:46PM -0700, David Conrad wrote: > > > > What am I missing? > > So my disconnected network gets a prefix from your autoresponder how? :) That's why there are other algorithms to consider (GPS readout or a date-and-time based hash or an IEEE address hash, for example). The point is, it's soluble one way or another. 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 Apr 11 01:40:53 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 h3B8eqmh017781; Fri, 11 Apr 2003 01:40:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3B8eqsG017780; Fri, 11 Apr 2003 01:40:52 -0700 (PDT) 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 h3B8emmh017773 for ; Fri, 11 Apr 2003 01:40:48 -0700 (PDT) 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 h3B8eucU024036 for ; Fri, 11 Apr 2003 01:40:56 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id BAA02257 for ; Fri, 11 Apr 2003 01:40:50 -0700 (PDT) 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, 11 Apr 2003 08:40: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; Fri, 11 Apr 2003 08:40: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; Fri, 11 Apr 2003 08:40:46 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; Fri, 11 Apr 2003 08:40:45 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3B8eEu9020304; Fri, 11 Apr 2003 10:40:14 +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 h3B8eBPQ255100; Fri, 11 Apr 2003 10:40:11 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA25408 from ; Fri, 11 Apr 2003 10:40:06 +0200 Message-Id: <3E967F92.C485B1B9@hursley.ibm.com> Date: Fri, 11 Apr 2003 10:40:50 +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: Robert Elz Cc: David Conrad , IPv6 Subject: Re: C000 References: <63DA971C-6B9C-11D7-8A4A-000393DB42B2@nominum.com> <20520.1050014030@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > > Date: Thu, 10 Apr 2003 14:35:46 -0700 > From: David Conrad > Message-ID: <63DA971C-6B9C-11D7-8A4A-000393DB42B2@nominum.com> > > | What am I missing? > > Aside from Tim's response, there's also the issue of why I'm only > going to be asking for one a second. I think I'd try more like > a thousand a second. If a thousand other people do the same, then > the 2^45 space is gone in a year. Of course the allocator would throttle the rate, but indeed there are various DoS attacks to be considered. 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 Apr 11 03:08: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 h3BA8Nmh019395; Fri, 11 Apr 2003 03:08:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BA8NQD019394; Fri, 11 Apr 2003 03:08:23 -0700 (PDT) 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 h3BA8Imh019387 for ; Fri, 11 Apr 2003 03:08:18 -0700 (PDT) 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 h3BA8PvV009348 for ; Fri, 11 Apr 2003 03:08:25 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA10677 for ; Fri, 11 Apr 2003 03:08:19 -0700 (PDT) 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, 11 Apr 2003 10:08: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; Fri, 11 Apr 2003 10:08: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; Fri, 11 Apr 2003 10:08:18 Z Received: from fuchsia.home ([203.146.155.26] [203.146.155.26]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 10:08:15 Z Received: from delta.home (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id h3BA82ok013901; Fri, 11 Apr 2003 17:08:05 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.home (8.11.6/8.11.6) with ESMTP id h3BA6lb25234; Fri, 11 Apr 2003 17:06:58 +0700 (ICT) From: Robert Elz To: alh-ietf@tndh.net cc: ipng@sunroof.eng.sun.com Subject: Re: C000 In-Reply-To: <0fcb01c2ffb6$7c95fb90$ee1a4104@eagleswings> References: <0fcb01c2ffb6$7c95fb90$ee1a4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Apr 2003 17:06:47 +0700 Message-Id: <25232.1050055607@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Apr 2003 16:11:11 -0700 From: "Tony Hain" Message-ID: <0fcb01c2ffb6$7c95fb90$ee1a4104@eagleswings> | Preallocation of a range in an evenly distributed manner would get past | the abuse issues, or at least localize them to the granularity of the | distribution grid. Only if you have some way to verify that the source of a request is with the designated grid unit. To make any verification like that non trivial to subvert, it is going to cost something to perform, so the idea of free numbers goes away - then the billing also needs to be paid for, and the organisation doing all this work is going to want to be compensated for it (profit...) kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 11 03:20: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 h3BAKOmh020035; Fri, 11 Apr 2003 03:20:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BAKNcl020034; Fri, 11 Apr 2003 03:20:23 -0700 (PDT) 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 h3BAKJmh020024 for ; Fri, 11 Apr 2003 03:20:19 -0700 (PDT) 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 h3BAKPvV011876 for ; Fri, 11 Apr 2003 03:20:25 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA16018 for ; Fri, 11 Apr 2003 03:20:20 -0700 (PDT) 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, 11 Apr 2003 10:20: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; Fri, 11 Apr 2003 10:20: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; Fri, 11 Apr 2003 10:20:19 Z Received: from fuchsia.home ([203.146.155.26] [203.146.155.26]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 10:20:16 Z Received: from delta.home (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id h3BAJqok014022; Fri, 11 Apr 2003 17:19:52 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.home (8.11.6/8.11.6) with ESMTP id h3BAIOb25401; Fri, 11 Apr 2003 17:18:36 +0700 (ICT) From: Robert Elz To: David Conrad cc: Brian E Carpenter , IPv6 Subject: Re: C000 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Apr 2003 17:18:24 +0700 Message-Id: <25399.1050056304@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Apr 2003 16:39:18 -0700 From: David Conrad Message-ID: | *Yawn* So, the automated system keeps track of the requesting address | and drops multiple requests from the same source. And now no-one is able to offer a broker service, with a nice web, or e-mail (or telephone, for Tim's people who aren't connected) interface, because you will only allow the source address to request one address. Of course, if all this is being done using IPv6, which we assume it one day will, then I have 2^64 available source addresses in one subnet available to me, which is enough to get all 2^45 site numbers if you just check the address for uniqueness. So, you're going to have to try and find some larger aggregation to use, and get that right. | This is just silly. Yes, we can all come up with DoS attacks that can | disable a service like this. We can also come up with remedies against | many of those attacks. Arms races are fun. And costly. | What is the point? We're talking about allocating a globally unique | prefix for each non-connected sites to remove what some consider a | wart/unnecessary and/or ill-defined complexity that will result in | duplicate addresses. Yes, and as I said before, and proposed in different ways several times, that's what I would have liked too. I still would. The point here is that previous attempts to do this all failed. So, I'd like some very strong evidence that this time it will succeed, before being willing to throw out all of what we now have, because I have no confidence at all that it is going to succeed this time. | You want to connect, you're going to have to get | a prefix from your ISP and renumber anyway. Of course you'll need a new prefix, but as Tony said, not "renumber" But that's irrelevant here. | This entire discussion has been really depressing. People seem to be | arguing theoretical positions instead of trying to come up with | engineering solutions to what is, fundamentally, a non-problem. I agree with this. I have practical experience, and site local addresses as we have them work. We don't need any of this discussion. If we want to find a way to allocate stable PI addresses, and we can make that work, then let's just do that. Once we have it, it is quite possible that there will be no remaining need for site-local addresses, and then no-one is going to object to deleting them. Until then, they should stay just as they are now. kre kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 11 03:53:22 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 h3BArMmh020893; Fri, 11 Apr 2003 03:53:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BArLCW020892; Fri, 11 Apr 2003 03:53:21 -0700 (PDT) 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 h3BArHmh020885 for ; Fri, 11 Apr 2003 03:53:17 -0700 (PDT) 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 h3BArNcU014127 for ; Fri, 11 Apr 2003 03:53:24 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id EAA16449 for ; Fri, 11 Apr 2003 04:53:18 -0600 (MDT) 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, 11 Apr 2003 10:53: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; Fri, 11 Apr 2003 10:53:17 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, 11 Apr 2003 10:53:17 Z Received: from fuchsia.home ([203.146.155.28] [203.146.155.28]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 10:53:14 Z Received: from delta.home (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id h3BAq7ok014496; Fri, 11 Apr 2003 17:52:13 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.home (8.11.6/8.11.6) with ESMTP id h3BAoIb25893; Fri, 11 Apr 2003 17:50:21 +0700 (ICT) From: Robert Elz To: Eliot Lear cc: alh-ietf@tndh.net, "'Margaret Wasserman'" , "'Brian Haberman'" , "'Brian E Carpenter'" , "'IPv6'" Subject: Re: A review of draft-hain-ipv6-sitelocal-00.txt (was Re: C000) In-Reply-To: <3E961DB1.7080509@cisco.com> References: <3E961DB1.7080509@cisco.com> <0f9501c2ff8b$9ca5be00$ee1a4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Apr 2003 17:50:18 +0700 Message-Id: <25891.1050058218@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Apr 2003 18:43:13 -0700 From: Eliot Lear Message-ID: <3E961DB1.7080509@cisco.com> | Let us delve deeper than this. Why is it that stable addresses are so | necessary? Could it be because renumbering is painful? Could that be | one source of our ills? No. The more painful renumbering is (and hence the less often we're likely to actually do it - even if that means being locked into an ISP) the less we need some other kind of stable addresses, because in practice the ISP provided addresses are stable. The easier we make renumbering, which I agree is something that we should be working on (and something I am actually getting some work done on), the more we want/need some other stable addressing scheme. The root cause is that addresses are also identifiers, and things break when the identifiers alter. So, we one of two problems solved before we can give up on some easily obtainable stable address space - either we need PI (routable) addressing, or we need separation of identity from location. So far, after all of these years, we have failed to find anything that works for either of those. When you have a solution to one of them, that will be a big advance by itself - then we can look again and see if we still have a need for any other kind of addressing. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 11 03:55:48 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 h3BAtmmh020962; Fri, 11 Apr 2003 03:55:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BAtmh5020961; Fri, 11 Apr 2003 03:55:48 -0700 (PDT) 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 h3BAthmh020951 for ; Fri, 11 Apr 2003 03:55:43 -0700 (PDT) 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 h3BAtovV016570 for ; Fri, 11 Apr 2003 03:55:50 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA20645 for ; Fri, 11 Apr 2003 03:55:44 -0700 (PDT) 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, 11 Apr 2003 10:55:44 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, 11 Apr 2003 10:55: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; Fri, 11 Apr 2003 10:55:44 Z Received: from fuchsia.home ([203.146.155.28] [203.146.155.28]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 10:55:41 Z Received: from delta.home (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id h3BAsrok014526; Fri, 11 Apr 2003 17:54:53 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.home (8.11.6/8.11.6) with ESMTP id h3BAr5b25941; Fri, 11 Apr 2003 17:53:10 +0700 (ICT) From: Robert Elz To: Charlie Perkins cc: alh-ietf@tndh.net, "'IPv6'" Subject: Re: C000 In-Reply-To: <3E96456A.5000407@iprg.nokia.com> References: <3E96456A.5000407@iprg.nokia.com> <3E95B788.DB9921CE@iprg.nokia.com> <0f9401c2ff89$747bad60$ee1a4104@eagleswings> <17632.1050005444@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Apr 2003 17:53:05 +0700 Message-Id: <25939.1050058385@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Apr 2003 21:32:42 -0700 From: Charlie Perkins Message-ID: <3E96456A.5000407@iprg.nokia.com> | I would think that a solution that doesn't have scope built into the | addressing architecture, and that has few practical operational | differences from site-local, would be a good choice. Unless we delete link-local, that isn't going to happen, is it? | I'm not sure! But I would like to see a way to have the kind of | provider independence that site-local provides, and this is a way | to do it that is "compatible" with the vote to eliminate site-locals. | Making more people happy and giviing more people what they | need/want is a better outcome than just eliminating site-locals. That's fine - but let's find the new solution first, please. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 11 04:46: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 h3BBkBmh021453; Fri, 11 Apr 2003 04:46:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BBkAK6021452; Fri, 11 Apr 2003 04:46:10 -0700 (PDT) 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 h3BBk7mh021445 for ; Fri, 11 Apr 2003 04:46:07 -0700 (PDT) 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 h3BBkDvV022537 for ; Fri, 11 Apr 2003 04:46:13 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA06660 for ; Fri, 11 Apr 2003 04:46:07 -0700 (PDT) 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, 11 Apr 2003 11:46:02 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, 11 Apr 2003 11:42: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; Fri, 11 Apr 2003 11:46:01 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 11:46:01 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3BBjRv20370; Fri, 11 Apr 2003 14:45:27 +0300 Date: Fri, 11 Apr 2003 14:45:27 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: Eliot Lear , , "'Margaret Wasserman'" , "'Brian Haberman'" , "'Brian E Carpenter'" , "'IPv6'" Subject: pain of renumbering [Re: A review of draft-hain-ipv6-sitelocal-00.txt (was Re: C000)] In-Reply-To: <25891.1050058218@munnari.OZ.AU> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 11 Apr 2003, Robert Elz wrote: > Date: Thu, 10 Apr 2003 18:43:13 -0700 > From: Eliot Lear > Message-ID: <3E961DB1.7080509@cisco.com> > > | Let us delve deeper than this. Why is it that stable addresses are so > | necessary? Could it be because renumbering is painful? Could that be > | one source of our ills? > > No. The more painful renumbering is (and hence the less often we're > likely to actually do it - even if that means being locked into an ISP) > the less we need some other kind of stable addresses, because in practice > the ISP provided addresses are stable. > > The easier we make renumbering, which I agree is something that we should > be working on (and something I am actually getting some work done on), > the more we want/need some other stable addressing scheme. > > The root cause is that addresses are also identifiers, and things break > when the identifiers alter. [...] Indeed, but that depends a *lot* on what you expect of "renumbering". IMO, we should focus on making renumbering as easy as possible *primarily* with no regard to connection survivability. Even if connections broke, that alone coul dbe a huge win. Of course, a full solution would be bonus, but not realistic to aim for. To begin with, writing an informational document on operational procedures how to make renumbering easier could be a start to scoping the problems. -- 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 Apr 11 06:56: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 h3BDucmh022939; Fri, 11 Apr 2003 06:56:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BDuch7022938; Fri, 11 Apr 2003 06:56:38 -0700 (PDT) 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 h3BDuXmh022931 for ; Fri, 11 Apr 2003 06:56:33 -0700 (PDT) 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 h3BDuevV012427 for ; Fri, 11 Apr 2003 06:56:40 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id GAA07479 for ; Fri, 11 Apr 2003 06:56:34 -0700 (PDT) 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, 11 Apr 2003 13:56:31 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, 11 Apr 2003 13:56: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; Fri, 11 Apr 2003 13:56:30 Z Received: from fuchsia.home ([203.146.155.26] [203.146.155.26]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 13:56:25 Z Received: from delta.home (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id h3BDs1ok016566; Fri, 11 Apr 2003 20:54:04 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.home (8.11.6/8.11.6) with ESMTP id h3BDerb28954; Fri, 11 Apr 2003 20:40:53 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: Eliot Lear , alh-ietf@tndh.net, "'Margaret Wasserman'" , "'Brian Haberman'" , "'Brian E Carpenter'" , "'IPv6'" Subject: Re: pain of renumbering [Re: A review of draft-hain-ipv6-sitelocal-00.txt (was Re: C000)] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Apr 2003 20:40:53 +0700 Message-Id: <28952.1050068453@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 11 Apr 2003 14:45:27 +0300 (EEST) From: Pekka Savola Message-ID: | IMO, we should focus on making renumbering as easy as possible *primarily* | with no regard to connection survivability. I agree, for connections which are using the addresses that are altered. Finding a way to keep them running is some long term project for someone else... But, I want to keep connections that don't have to be affected by the renumbering - and that means having those use some addresses that aren't going to be affected. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 11 07:20:46 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 h3BEKkmh023283; Fri, 11 Apr 2003 07:20:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BEKkJB023282; Fri, 11 Apr 2003 07:20:46 -0700 (PDT) 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 h3BEKgmh023275 for ; Fri, 11 Apr 2003 07:20:42 -0700 (PDT) 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 h3BEKnvV017029 for ; Fri, 11 Apr 2003 07:20:49 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id IAA00155 for ; Fri, 11 Apr 2003 08:20:43 -0600 (MDT) 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, 11 Apr 2003 14:20:43 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP; Fri, 11 Apr 2003 14:20:43 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP; Fri, 11 Apr 2003 14:20:43 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay1.sun.com with ESMTP; Fri, 11 Apr 2003 14:20:42 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA12458; Fri, 11 Apr 2003 07:20:01 -0700 (PDT) Message-Id: <5.1.0.14.2.20030411094553.040e3040@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 11 Apr 2003 10:16:09 -0400 To: Tony Hain From: Margaret Wasserman Subject: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Cc: Bob Hinden , Thomas Narten , Erik Nordmark , ipng@sunroof.eng.sun.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, Based on your messages below, we understand that you are attempting to start an appeal regarding the IPv6 WG's decision to deprecate IPv6 site-local unicast addressing. However, it is not entirely clear to us what action (or inaction) you are appealing and on what grounds. We understand that you disagree with the WGs decision to deprecate IPv6 site-local unicast addressing without first defining an alternative local addressing mechanism, but that is not, in itself, grounds for an appeal. In order for us to consider this appeal, you should follow the appeals process outlined in section 6.5.4 of RFC 2026. Your appeal should include a "detailed and specific description of the facts of the dispute". In particular, you should make it clear exactly what action (or inaction) you are appealing. You must also indicate what grounds you have for appealing that action (or inaction). There are two possible grounds for appeal of a WG action, listed in RFC 2026, section 6.5.1: (a) [your] own views have not been adequately considered by the Working Group, or (b) the Working Group has made an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy. It might also be possible to raise a process appeal if you believe that the chairs violated the process for session management described in section 3.3 of RFC 2418. Please explicitly state what you are appealing and explain your grounds for appeal. You should also supply any information necessary to explain and support your position. Once we have this information, we will carefully consider your appeal and provide a written reply. We understand that your appeal is motivated by your desire to do the right thing for IPv6, and we will make every attempt to deal with it fairly and promptly. Bob Hinden & Margaret Wasserman IPv6 WG Chairs >Reply-To: >From: "Tony Hain" >To: "'Bob Hinden'" , > "'Margaret Wasserman'" >Cc: >Subject: FW: Consensus on Site-Local Addressing >Date: Thu, 10 Apr 2003 10:31:47 -0700 >X-Mailer: Microsoft Outlook, Build 10.0.4510 >Importance: Normal >X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com >id h3AHY8mh023731 >Sender: owner-ipng@sunroof.eng.sun.com > >Bob & Margaret, > >As I noted to Thomas a few moments ago, I have already raised concerns >about the initial action of calling the ambiguous question. I believe >his response indicates I also need to raise a concern with you about >this specific action of declaring consensus. As the content of the note >below indicates, there can be no consensus because the question was not >clear. At best, this activity shows a desire to change the status quo, >but it does not and can not indicate anything else. The consensus >declaration must be voided. > >As I note below, steps 4) & 5) indicate work that the group believes we >should take on. *If* the result of that work leaves us with no further >use for the current definition for an ambiguous address space, then in >that context I believe steps 1) & 3) are appropriate. Until then they >are not, and are very likely to create chaos, particularly if done >before 4) delivers complete alternatives. > >You must void the declaration of consensus, and should recognize that >the original question was not clear. > >Tony > > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tony Hain > > Sent: Wednesday, April 09, 2003 5:42 PM > > To: 'Thomas Narten'; 'Erik Nordmark' > > Cc: ipng@sunroof.eng.sun.com > > Subject: FW: Consensus on Site-Local Addressing > > > > > > Thomas & Erik, > > > > Please consider this the second step in the appeal process, > > as I have already discussed these issues with the chairs on > > more than one occasion. > > > > 'we reject kings, presidents and voting...' > > The consensus measurement on the mail list was much more > > indicative of the real lack of it (60/40%), than what was > > effectively ballot stuffing by WG visitors without a complete > > context. There was a very short presentation in the apps open > > area, intended to raise concerns and incite involvement, were > > those in the apps area were agitated, then invited to the > > IPv6 WG session in SF to discuss the potential issues. The > > subsequent short discussion in the IPv6 WG showed there were > > issues to work through, and at least one question voiced > > about understanding the requirements. Rather than deal with > > the issues raised, the chairs decided to call an ambiguous > > question of yes/no for deprecation. > > > > While the chairs do in 2) recognize their interpretation of > > the consensus that the WG will investigate other forms of > > local addressing, there is no mention of ambiguity and the > > rest of the wording of 1) & 2) can be interpreted as local > > scope addressing is deprecated. The concern is that we will > > end up with a document lacking local scope addressing, and > > claims that we had consensus to remove local scope from the > > architecture. Many of those who bothered to state why they > > were expressing a yes opinion claimed ambiguity was the > > reason, while others were only interested in removing special > > handling for local scope addresses. Those are technically > > different issues, so they need different questions. What we > > have is an indication that many are unhappy with the status > > quo, but a lack of recognition that the call ended up > > combining yes opinions for removing ambiguity with yes > > opinions for removing local scope addresses from the > > architecture. From subsequent discussions with the chairs, it > > is clear that was not their intent, but never the less that > > is the result of the lack of clarity in this consensus call. > > > > '... we believe in rough consensus & running code' & from the > > Tao : 'running code wins' On several related mail threads > > there were many comments about running code, and at least > > Brian Zill & Brian Haberman said they collectively had host, > > application, and router implementations of the current SL > > running. Point 3) even acknowledges there are existing > > implementations. This consensus call intends to invalidate > > the running code, and all we have to replace it is a promise > > in 4) that if the group can ever agree that operational > > requirements of the site network manager are worth solving, > > we might start to work on solutions, subject to appropriate > > charter updates. This whole discussion is based on the > > argument that some developers couldn't create running code > > for an arguably bogus scenario where topology locators are > > blindly passed outside their scope of relevance. Bias was > > given to the opinions of those with a lack of running code, > > at the expense of, and with the specific intent of > > invalidating the code that exists. > > > > There were also claims in the meeting and mail threads that > > we have analyzed site local as currently defined, and it > > doesn't meet the requirements. At the same time, there is a > > recognition by many of the same people that we need to > > develop a complete set of requirements. It should be obvious > > that the analysis is flawed if the complete set of > > requirements are not understood first. To that end, and in > > the spirit of making progress, > > draft-hain-ipv6-sitelocal-00.txt was processed by the I-D > > editor on 4/8, and is offered as an attempt to document the > > requirements for address space with a local scope of > > relevance. It is clearly incomplete, and largely based on my > > previous email on the subject. > > > > While I contest the claim that the Yes/No opinions expressed > > measured consensus for a consistent interpretation of what > > 'deprecate site local addresses' means, I do believe that a > > set of work items for the group were identified. It is also > > clear that we can add new work to a group at any time, > > without the need to remove existing items first. I agree with > > the chairs that items 4) & 5) are valid outcomes of the > > subsequent discussion, though one thing that their > > interpretation of the result does not make clear is the > > meaning of 'accomplish the following things in parallel:'. In > > talking to the chairs it appears the intent is to start the > > work at the same time, but we need to avoid invalid > > transition states, so parallel needs to mean that all 5 are > > to be forwarded to the IESG at one time. In particular, > > without solutions to the requirements in hand, any documents > > for 1) & 3) that intend to deprecate the only local use > > address space will simply create chaos, and might need to be > > rescinded if the complete set of requirements shows a need > > with no other technical approach. > > > > In short, I do not believe the consensus call measured the > > opinions that were consistent the chairs interpretation of > > the question, so the claimed results are invalid. I do > > believe that the effort identified work items 4) & 5), with > > the potential that 1) & 3) might follow if there are no > > outstanding requirements for ambiguous address space. I > > question the wisdom of 2), but will reserve judgment until > > the complete text identifying further work is spelled out. In > > any case, I hope this appeal can be dealt with at this level, > > and that the overall effort results in an expedited charter > > update. It is imperative that new approaches exist prior to > > removal of the current, and there is a very real danger that > > the current destructive energy will dissipate in the face of > > the hard work of creating replacements. > > > > 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 Fri Apr 11 07:32: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 h3BEWamh023465; Fri, 11 Apr 2003 07:32:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BEWaXL023464; Fri, 11 Apr 2003 07:32:36 -0700 (PDT) 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 h3BEWWmh023454 for ; Fri, 11 Apr 2003 07:32:32 -0700 (PDT) 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 h3BEWdcU021881 for ; Fri, 11 Apr 2003 07:32:39 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id HAA28598 for ; Fri, 11 Apr 2003 07:32:32 -0700 (PDT) From: jarno.rajahalme@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; Fri, 11 Apr 2003 14: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; Fri, 11 Apr 2003 14:32: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; Fri, 11 Apr 2003 14:32: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; Fri, 11 Apr 2003 14:32:21 Z Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3BEWIQ20141 for ; Fri, 11 Apr 2003 17:32:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 11 Apr 2003 17:32:18 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 11 Apr 2003 17:32:18 +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: C000 Date: Fri, 11 Apr 2003 17:32:18 +0300 Message-Id: <009CA59D1752DD448E07F8EB2F9117570216EB89@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: C000 Thread-Index: AcL/ZmmNzlurW0tLSMuS24W7V6SkHQA0AL7Q To: , X-OriginalArrivalTime: 11 Apr 2003 14:32:18.0662 (UTC) FILETIME=[27C04860:01C30037] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3BEWXmh023455 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > Assume that we consider stable, probably unique, > unrouteable prefixes important enough to get their own 3-bit Unique prefixes can be made routable by injecting them into the routing tables. Maybe current users of private address spaces actually *want* ambiguous prefixes, since that makes them unroutable (harder to set up VPNs where you should not, etc.)?? 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 Fri Apr 11 07:42: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 h3BEg9mh023840; Fri, 11 Apr 2003 07:42:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BEg9vd023839; Fri, 11 Apr 2003 07:42:09 -0700 (PDT) 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 h3BEg5mh023832 for ; Fri, 11 Apr 2003 07:42:06 -0700 (PDT) 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 h3BEgCvV021117 for ; Fri, 11 Apr 2003 07:42:12 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id IAA07000 for ; Fri, 11 Apr 2003 08:42:05 -0600 (MDT) 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, 11 Apr 2003 14:42:04 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP; Fri, 11 Apr 2003 14:38:29 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Fri, 11 Apr 2003 14:42:04 Z Received: from TheWorld.com ([199.172.62.106] [199.172.62.106]) by relay11.sun.com with ESMTP; Fri, 11 Apr 2003 14:42:02 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id h3BEfblV002954; Fri, 11 Apr 2003 10:41:38 -0400 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id KAA9115775; Fri, 11 Apr 2003 10:41:19 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Fri, 11 Apr 2003 10:41:19 -0400 From: Quality Quorum To: Margaret Wasserman cc: Tony Hain , Bob Hinden , Thomas Narten , Erik Nordmark , Subject: Re: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) In-Reply-To: <5.1.0.14.2.20030411094553.040e3040@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 Fri, 11 Apr 2003, Margaret Wasserman wrote: > Based on your messages below, we understand that you are attempting > to start an appeal regarding the IPv6 WG's decision to deprecate IPv6 > site-local unicast addressing. Huh? You saw a consensus in this flurry of e-mail, unbelievable. Just to be counted, my vote is 'no', all previous fights between IETF and the market forces were easily won by the market forces. It is going to happen again. There is some undoubtful reason in the proposal - if you allow for PI NAT6 will be unstoppable. The problem with the proposal is that it unstoppable regardless of decision by WG/IESG/IETF. 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 Apr 11 07:55: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 h3BEtqmh024716; Fri, 11 Apr 2003 07:55:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BEtpaD024715; Fri, 11 Apr 2003 07:55:51 -0700 (PDT) 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 h3BEtmmh024705 for ; Fri, 11 Apr 2003 07:55:48 -0700 (PDT) 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 h3BEtscU027038 for ; Fri, 11 Apr 2003 07:55:54 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id IAA13484 for ; Fri, 11 Apr 2003 08:55:48 -0600 (MDT) 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, 11 Apr 2003 14:55: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, 11 Apr 2003 14:55:48 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, 11 Apr 2003 14:55:47 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; Fri, 11 Apr 2003 14:55:47 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 HAA09302; Fri, 11 Apr 2003 07:55:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3BEtjq29811; Fri, 11 Apr 2003 07:55:45 -0700 X-mProtect: <200304111455> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEKBAtH; Fri, 11 Apr 2003 07:55:43 PDT Message-Id: <3E96D796.2040508@iprg.nokia.com> Date: Fri, 11 Apr 2003 07:56:22 -0700 From: Charlie Perkins Organization: Nokia 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: Robert Elz CC: "'IPv6'" Subject: Re: C000 References: <3E96456A.5000407@iprg.nokia.com> <3E95B788.DB9921CE@iprg.nokia.com> <0f9401c2ff89$747bad60$ee1a4104@eagleswings> <17632.1050005444@munnari.OZ.AU> <25939.1050058385@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Robert, Robert Elz wrote: > | I would think that a solution that doesn't have scope built into the > | addressing architecture, and that has few practical operational > | differences from site-local, would be a good choice. > >Unless we delete link-local, that isn't going to happen, is it? > Got me there. But it's the exception that proves the rule, because applications using link-local are in fact special-built to do so. > | I'm not sure! But I would like to see a way to have the kind of > | provider independence that site-local provides, and this is a way > | to do it that is "compatible" with the vote to eliminate site-locals. > | Making more people happy and giviing more people what they > | need/want is a better outcome than just eliminating site-locals. > >That's fine - but let's find the new solution first, please. > > > O.K. How about a staged solution? The first autoresponder gives out a new address to _any_ requester, but only one per minute total no matter how many requesters. Then we work from there to solve more and more of the problems that you have raised in other messages. As I remember, almost no IETF solution is perfect on first deployment (even site-locals, as it turns out). The broker service is easily arranged even by autoresponder. And if it's simple enough I reckon an autorresponder ought to be hosted on IANA's website. IANA "could" delegate out subranges to other sites for robustness. 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 Fri Apr 11 08:06: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 h3BF6Ymh025218; Fri, 11 Apr 2003 08:06:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BF6Yrq025217; Fri, 11 Apr 2003 08:06:34 -0700 (PDT) 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 h3BF6Vmh025210 for ; Fri, 11 Apr 2003 08:06:31 -0700 (PDT) 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 h3BF6bvV027035 for ; Fri, 11 Apr 2003 08:06:37 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA24742 for ; Fri, 11 Apr 2003 08:06:31 -0700 (PDT) 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, 11 Apr 2003 15:06:29 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, 11 Apr 2003 15: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, 11 Apr 2003 15:06:29 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; Fri, 11 Apr 2003 15:06:29 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA04872; Fri, 11 Apr 2003 08:05:36 -0700 (PDT) Message-Id: <5.1.0.14.2.20030411105604.040e3040@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 11 Apr 2003 11:03:26 -0400 To: From: Margaret Wasserman Subject: RE: Consensus on Site-Local Addressing Cc: "'Fred L. Templin'" , "'Michel Py'" , In-Reply-To: <0f9c01c2ff8f$2d1ac310$ee1a4104@eagleswings> References: <3E95ADEF.2080002@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 >See draft-hain-ipv6-sitelocal-00.txt, the research ship example as one >real case where a multi-subnet network intermittently attaches to >different providers. Other vehicle types (airplanes in particular) >already have multiple subnets, and will attach to different providers >over time. This is exactly the type of problem that the nemo working group is chartered to address, so people interested in working on this problem should start following the nemo group. I don't believe that they are far enough along yet to have determined whether any special type of addressing is needed to solve this problem. It also seems possible that the results of the nemo work will apply to intermittently connected SOHO networks, but I don't think that is their main thrust. I haven't actually been following nemo, but I probably should... 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 Fri Apr 11 08:31:53 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 h3BFVrmh025626; Fri, 11 Apr 2003 08:31:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BFVrGg025625; Fri, 11 Apr 2003 08:31:53 -0700 (PDT) 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 h3BFVnmh025618 for ; Fri, 11 Apr 2003 08:31:49 -0700 (PDT) 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 h3BFVucU006332 for ; Fri, 11 Apr 2003 08:31:56 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA21692 for ; Fri, 11 Apr 2003 09:31:50 -0600 (MDT) 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, 11 Apr 2003 15:31: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; Fri, 11 Apr 2003 15: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; Fri, 11 Apr 2003 15:31:09 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; Fri, 11 Apr 2003 15:31:08 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3BFUlgE007636; Fri, 11 Apr 2003 08:30:47 -0700 (PDT) Received: from cisco.com (sjc-vpn2-926.cisco.com [10.21.115.158]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA06412; Fri, 11 Apr 2003 08:30:46 -0700 (PDT) Message-Id: <3E96DFA4.20807@cisco.com> Date: Fri, 11 Apr 2003 08:30:44 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Elz CC: alh-ietf@tndh.net, "'Margaret Wasserman'" , "'Brian Haberman'" , "'Brian E Carpenter'" , "'IPv6'" Subject: Re: A review of draft-hain-ipv6-sitelocal-00.txt (was Re: C000) References: <3E961DB1.7080509@cisco.com> <0f9501c2ff8b$9ca5be00$ee1a4104@eagleswings> <25891.1050058218@munnari.OZ.AU> In-Reply-To: <25891.1050058218@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob, Have you looked at HIP? 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 Apr 11 08:45: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 h3BFjOmh026148; Fri, 11 Apr 2003 08:45:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BFjOmc026147; Fri, 11 Apr 2003 08:45:24 -0700 (PDT) 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 h3BFjKmh026140 for ; Fri, 11 Apr 2003 08:45:20 -0700 (PDT) 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 h3BFjQcU010384 for ; Fri, 11 Apr 2003 08:45:27 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA14400 for ; Fri, 11 Apr 2003 09:45:21 -0600 (MDT) 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, 11 Apr 2003 15:45: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; Fri, 11 Apr 2003 15:45: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; Fri, 11 Apr 2003 15:45:17 Z Received: from fuchsia.home ([203.146.155.30] [203.146.155.30]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 15:45:12 Z Received: from delta.home (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id h3BFj2ok017785 for ; Fri, 11 Apr 2003 22:45:03 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.home (8.11.6/8.11.6) with ESMTP id h3BFbbb01506; Fri, 11 Apr 2003 22:37:37 +0700 (ICT) From: Robert Elz To: Charlie Perkins cc: "'IPv6'" Subject: Re: C000 In-Reply-To: <3E96D796.2040508@iprg.nokia.com> References: <3E96D796.2040508@iprg.nokia.com> <3E96456A.5000407@iprg.nokia.com> <3E95B788.DB9921CE@iprg.nokia.com> <0f9401c2ff89$747bad60$ee1a4104@eagleswings> <17632.1050005444@munnari.OZ.AU> <25939.1050058385@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Apr 2003 22:37:37 +0700 Message-Id: <1504.1050075457@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 11 Apr 2003 07:56:22 -0700 From: Charlie Perkins Message-ID: <3E96D796.2040508@iprg.nokia.com> | But it's the exception that proves the rule, because | applications using link-local are in fact special-built to do so. No, they're not. The applications that use them most commonly in normal use are, but part of the objective for LL addresses was to be able to deal with an isolated LAN - no routers - and on that LAN you want all of the applications to function. What's more, a host connected to that LAN isn't necessarily not also connected to other LANS. That means that all applications need to be able to handle scoped addresses, just so they can function in this kind of environment. That includes where you want to use your multi-interface host (802.3 and 802.11 perhaps - they're pretty common these days) to figure out what is going wrong on the LAN and why the router is not advertising any prefixes. That might mean using telnet, snmp, http, ssh, tftp, ... (almost anything). | O.K. How about a staged solution? The first autoresponder gives out a | new address to _any_ requester, but only one per minute total no matter | how many requesters. Fine. Make it work, and we'll see how well it functions. And you're doing that, also consider how you convince people to actually use it, rather than just inventing their own number and using that. What's the benefit that the average site is going to get, or what down-side is there to just inventing a number for a site which only intends to use it internally (disconnected, filtered, whatever). Remember, even back in the early days, when all it took was an e-mail to get a class B number (I don't go back far enough to when this worked for A's!) lots of people still just picked a number out of the air and used it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 11 08:46: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 h3BFkQmh026192; Fri, 11 Apr 2003 08:46:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BFkQko026191; Fri, 11 Apr 2003 08:46:26 -0700 (PDT) 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 h3BFkMmh026184 for ; Fri, 11 Apr 2003 08:46:22 -0700 (PDT) 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 h3BFkSvV006351 for ; Fri, 11 Apr 2003 08:46:29 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA15222 for ; Fri, 11 Apr 2003 09:46:23 -0600 (MDT) 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, 11 Apr 2003 15:46: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; Fri, 11 Apr 2003 15:42: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, 11 Apr 2003 15:46:21 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 15:46:19 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h3BFjfvm068807; Fri, 11 Apr 2003 08:45:41 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h3BFjfkY068806; Fri, 11 Apr 2003 08:45:41 -0700 (PDT) Date: Fri, 11 Apr 2003 08:45:41 -0700 From: Shannon -jj Behrens To: Mike Saywell Cc: ipng@sunroof.eng.sun.com Subject: Re: C000 Message-Id: <20030411154541.GA68746@alicia.nttmcl.com> References: <0fd101c2ffbd$5369ce20$ee1a4104@eagleswings> <20030411013704.GQ2303@ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030411013704.GQ2303@ecs.soton.ac.uk> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Apr 11, 2003 at 02:37:04AM +0100, Mike Saywell wrote: > I might have missed something here, but... Just a few days ago, I was volunteering to create the service for free (in the name of fame), and Michael Py reminded me of the above draft which talks about your next paragraph. By the way, my service was going to be based on a simple turing test instead of rate limiting (these are just small details), such as the simple tests required before you can create a new slashdot account. > Wy dont we go with something like C000::/3 and then allocate prefixes > within that to the various different uniqueness mechanims such as geo, > MAC, time, requested, manual, random etc? > > I think it's quite clear that people had very different requirements from > SLs, perhaps their main strength was simply as a big chunk of free to > use address space. It would be nice if this quality could be preserved > whilst removing the ambiguity and consequent scope issues. > > C000::/3 addresses could be treated as global (imho) so existing > implementations wouldn't need changing. With ISP support it's possible > that some schemes really could become globally routable and thus offer > some degree of provider independance. > > I think something like this would be simple to implement today and hopefully > would address a lot of the concerns people had with SLs. I agree. 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 Fri Apr 11 09:12: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 h3BGCumh027017; Fri, 11 Apr 2003 09:12:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BGCukw027016; Fri, 11 Apr 2003 09:12:56 -0700 (PDT) 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 h3BGCrmh027009 for ; Fri, 11 Apr 2003 09:12:53 -0700 (PDT) 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 h3BGCxvV013250 for ; Fri, 11 Apr 2003 09:12:59 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA05815 for ; Fri, 11 Apr 2003 09:12:54 -0700 (PDT) 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, 11 Apr 2003 16:12:53 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, 11 Apr 2003 16:12:52 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, 11 Apr 2003 16:12:52 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; Fri, 11 Apr 2003 16:12: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 JAA12490; Fri, 11 Apr 2003 09:12:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3BGCoG27055; Fri, 11 Apr 2003 09:12:50 -0700 X-mProtect: <200304111612> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBGjhi9; Fri, 11 Apr 2003 09:12:48 PDT Message-Id: <3E96E981.38BB72C3@iprg.nokia.com> Date: Fri, 11 Apr 2003 09:12:49 -0700 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: Robert Elz CC: "'IPv6'" Subject: Re: C000 References: <3E96D796.2040508@iprg.nokia.com> <3E96456A.5000407@iprg.nokia.com> <3E95B788.DB9921CE@iprg.nokia.com> <0f9401c2ff89$747bad60$ee1a4104@eagleswings> <17632.1050005444@munnari.OZ.AU> <25939.1050058385@munnari.OZ.AU> <1504.1050075457@munnari.OZ. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Robert, I'll respond mainly just to clarify what I said, but maybe the discussion is not generating much that is new. If so, I hope you don't mind if I let you have the last word. Robert Elz wrote: > | But it's the exception that proves the rule, because > | applications using link-local are in fact special-built to do so. > > No, they're not. The applications that use them most commonly in normal > use are, but part of the objective for LL addresses was to be able to > deal with an isolated LAN - no routers - and on that LAN you want all of > the applications to function. I completely agree with this, and I meant to say something different, but I think you already said it better. > | O.K. How about a staged solution? The first autoresponder gives out a > | new address to _any_ requester, but only one per minute total no matter > | how many requesters. > > Fine. Make it work, and we'll see how well it functions. You're on. But I can't do much on it before next week. > And you're doing that, also consider how you convince people to actually > use it, rather than just inventing their own number and using that. Obviously, this is impossible to do in any absolute sense. But, it could be that "most" people will "do the right thing". And you are right that everything needs clear documentation. > What's the benefit that the average site is going to get, or what > down-side is there to just inventing a number for a site which only > intends to use it internally (disconnected, filtered, whatever). Only future-proofing and the possibility for tunneled access to the outside world. > Remember, even back in the early days, when all it took was an e-mail > to get a class B number (I don't go back far enough to when this worked > for A's!) lots of people still just picked a number out of the air and > used it. In fact, people still do this for disconnected sites. 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 Fri Apr 11 09:25:18 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 h3BGPHmh027431; Fri, 11 Apr 2003 09:25:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BGPHrN027429; Fri, 11 Apr 2003 09:25:17 -0700 (PDT) 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 h3BGPEmh027422 for ; Fri, 11 Apr 2003 09:25:14 -0700 (PDT) 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 h3BGPKvV016608 for ; Fri, 11 Apr 2003 09:25:20 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA09526 for ; Fri, 11 Apr 2003 10:25:14 -0600 (MDT) 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, 11 Apr 2003 16:25: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; Fri, 11 Apr 2003 16:25: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; Fri, 11 Apr 2003 16:25:14 Z Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 16:25:13 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 h3BGP8gE024456; Fri, 11 Apr 2003 09:25:09 -0700 (PDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA24413; Fri, 11 Apr 2003 17:25:00 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Charlie Perkins Cc: "'IPv6'" Subject: Re: C000 From: Ole Troan Date: Fri, 11 Apr 2003 17:25:00 +0100 In-Reply-To: <3E96D796.2040508@iprg.nokia.com> (Charlie Perkins's message of "Fri, 11 Apr 2003 07:56:22 -0700") Message-Id: <7t5istlm277.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <3E96456A.5000407@iprg.nokia.com> <3E95B788.DB9921CE@iprg.nokia.com> <0f9401c2ff89$747bad60$ee1a4104@eagleswings> <17632.1050005444@munnari.OZ.AU> <25939.1050058385@munnari.OZ.AU> <3E96D796.2040508@iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, >> | I would think that a solution that doesn't have scope built into the >> | addressing architecture, and that has few practical operational >> | differences from site-local, would be a good choice. >> >>Unless we delete link-local, that isn't going to happen, is it? >> > Got me there. But it's the exception that proves the rule, because > applications using link-local are in fact special-built to do so. are they? so the solving the "dentist's office" problem is no longer on the agenda. that's news to me. every application must work with link-local addresses. /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 Fri Apr 11 09:45:40 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 h3BGjemh027836; Fri, 11 Apr 2003 09:45:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BGjetE027835; Fri, 11 Apr 2003 09:45:40 -0700 (PDT) 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 h3BGjamh027828 for ; Fri, 11 Apr 2003 09:45:36 -0700 (PDT) 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 h3BGjhcU029429 for ; Fri, 11 Apr 2003 09:45:43 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA03707 for ; Fri, 11 Apr 2003 10:45:36 -0600 (MDT) 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, 11 Apr 2003 16:45: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; Fri, 11 Apr 2003 16:45: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; Fri, 11 Apr 2003 16:45:18 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 16:45:18 Z Content-class: urn:content-classes:message Subject: RE: C000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 11 Apr 2003 09:45:15 -0700 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F771@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: C000 Thread-Index: AcMASHmkG3TbcGHjRNep8juhxjl4bwAACvNQ From: "Michel Py" To: "Ole Troan" , "Charlie Perkins" Cc: "IPv6" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3BGjbmh027829 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, >> Charlie Perkins wrote: >> Got me there. But it's the exception that proves the rule, >> because applications using link-local are in fact special-built >> to do so. > Ole Troan > are they? so the solving the "dentist's office" problem is no > longer on the agenda. that's news to me. > every application must work with link-local addresses. I was about to make the same comment than Ole. What about two PCs connected with a cross-over cable? No router no hub no switch no nothing. No global address, no site-local address. I expect these two PCs to be able to participate in a peer-to-peer network, what else than link-locals would be used then? 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 Apr 11 09:49: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 h3BGnXmh027948; Fri, 11 Apr 2003 09:49:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BGnXF1027947; Fri, 11 Apr 2003 09:49:33 -0700 (PDT) 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 h3BGnTmh027937 for ; Fri, 11 Apr 2003 09:49:29 -0700 (PDT) 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 h3BGnZcU000772 for ; Fri, 11 Apr 2003 09:49:35 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA24056 for ; Fri, 11 Apr 2003 09:49:30 -0700 (PDT) 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, 11 Apr 2003 16:49:30 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, 11 Apr 2003 16:45: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; Fri, 11 Apr 2003 16:49:29 Z Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 16:49:29 Z Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3BGnLOm189460; Fri, 11 Apr 2003 12:49:21 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3BGnJMV045872; Fri, 11 Apr 2003 12:49:19 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.5/8.12.5) with ESMTP id h3BGjaem006750; Fri, 11 Apr 2003 12:45:36 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h3BGja7r006745; Fri, 11 Apr 2003 12:45:36 -0400 Message-Id: <200304111645.h3BGja7r006745@rotala.raleigh.ibm.com> To: Eliot Lear cc: "'IPv6'" Subject: Re: A review of draft-hain-ipv6-sitelocal-00.txt (was Re: C000) In-Reply-To: Message from lear@cisco.com of "Thu, 10 Apr 2003 18:43:13 PDT." <3E961DB1.7080509@cisco.com> Date: Fri, 11 Apr 2003 12:45:35 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eliot Lear writes: > > Network managers also don't have to expose business plans to > > a registrar for evaluation for networks that are not attached to the > > global Internet. > I think this is a real problem, because registrars still do not > understand the amount of address space they have. Simply charge a > linearly increasing fee and be done with it. This issue does not exist for IPv6. The RIR policies for allocating IPv6 address space say one can give each end site a /48 (or /64). There is no need to count hosts or in any other way justify how many hosts one has. This a *big* change from IPv4. See, for example, http://www.arin.net/policy/ipv6.html 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 Fri Apr 11 10:08:06 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 h3BH85mh028588; Fri, 11 Apr 2003 10:08:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BH85Vv028587; Fri, 11 Apr 2003 10:08:05 -0700 (PDT) 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 h3BH81mh028580 for ; Fri, 11 Apr 2003 10:08:01 -0700 (PDT) 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 h3BH88vV029969 for ; Fri, 11 Apr 2003 10:08:08 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA10315 for ; Fri, 11 Apr 2003 10:08:02 -0700 (PDT) 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, 11 Apr 2003 17:07: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; Fri, 11 Apr 2003 17:07: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; Fri, 11 Apr 2003 17:07:49 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 17:07:48 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 11 Apr 2003 10:07:43 -0700 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , "'Tony Hain'" Cc: "'Bob Hinden'" , "'Thomas Narten'" , "'Erik Nordmark'" , Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Fri, 11 Apr 2003 10:07:44 -0700 Message-Id: <106f01c3004c$deceb8b0$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: <5.1.0.14.2.20030411094553.040e3040@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3BH82mh028581 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > Hi Tony, > > Based on your messages below, we understand that you are > attempting to start an appeal regarding the IPv6 WG's > decision to deprecate IPv6 site-local unicast addressing. > However, it is not entirely clear to us what action (or > inaction) you are appealing and on what grounds. What is not clear about? >> As the content of the note below indicates, there can >> be no consensus because the question was not clear. >>> Many of those who bothered to state why they were >>> expressing a yes opinion claimed ambiguity was the >>> reason, while others were only interested in removing >>> special handling for local scope addresses. Those are >>> technically different issues, so they need different >>> questions. >>> In short, I do not believe the consensus call measured >>> the opinions that were consistent the chairs >>> interpretation of the question, so the claimed results >>> are invalid. > We > understand that you disagree with the WGs decision to > deprecate IPv6 site-local unicast addressing without first > defining an alternative local addressing mechanism, but that > is not, in itself, grounds for an appeal. I can't disagree because the WG did not reach a decision, the chairs declared one. There were different interpretations of what people were voting YES for, therefore there was no decision. The chairs combined YES get rid of scoping, with YES get rid of ambiguity responses to arrive at a count. That does not constitute a WG decision. > > In order for us to consider this appeal, you should follow > the appeals process outlined in section 6.5.4 of RFC 2026. > Your appeal should include a "detailed and specific > description of the facts of the dispute". In particular, you > should make it clear exactly what action (or inaction) you > are appealing. >> You must void the declaration of consensus, and should >> recognize that the original question was not clear. The question asked was: Should we deprecate IPv6 site-local unicast addressing? The answers indicated that some interpreted that as deprecation of address scoping, while others interpreted it as remove the ambiguity associated with the current definition of the FEC0::/10 prefix. Those are technically different issues and require separate questions, yet the chairs combined the disparate YES votes for each perspective into their own interpretation of what the original question meant. This is not WG consensus. > > You must also indicate what grounds you have for appealing > that action (or inaction). There are two possible grounds > for appeal of a WG action, listed in RFC 2026, section 6.5.1: > > (a) [your] own views have not been adequately considered > by the Working Group, or > (b) the Working Group has made an incorrect technical choice > which places the quality and/or integrity of the Working > Group's product(s) in significant jeopardy. The working group was mislead by an ambiguous question from the chairs, and has not reached a consensus on anything other than more work needs to be done. Some of the YES votes were for removal of scopes from the architecture, and others were for removing ambiguous addresses as SL is currently defined. Those are technically different concepts requiring different questions. The declaration of consensus by the chairs indicates an incorrect technical choice which places the integrity of the WG product in significant jeopardy. > > It might also be possible to raise a process appeal if you > believe that the chairs violated the process for session > management described in section 3.3 of RFC 2418. Well since you brought it up, the agenda listed Limited Usage, and Moderate Usage as the topics of discussion. Then (someone that was there should verify this, but I have been told that) your presentation listed: Full Moderate Exclusive Limited No SLs and you started the presentation by saying that the first one and the last one were not under consideration. Later you call an ambiguous question attempting to accomplish the last one. Is that proper session management? If people are led to believe a topic will not be discussed, they are less likely to come prepared to discuss it, or stick around to make sure their views are heard during a discussion. I can only question, maybe others that were there will appeal based on mismanagement. > > Please explicitly state what you are appealing and explain > your grounds for appeal. You should also supply any > information necessary to explain and support your position. > Once we have this information, we will carefully consider > your appeal and provide a written reply. I believe I did this in the original note to Thomas & Erik, which was included in the subsequent note of appeal to the chairs. I am appealing the declaration of consensus based on an ambiguous question, where some responses indicate remove addresses with local scope while others indicate remove ambiguity of the address range. > > We understand that your appeal is motivated by your desire to > do the right thing for IPv6, and we will make every attempt > to deal with it fairly and promptly. >From my reading, this response does not indicate a desire for promptness. Tony > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > >Reply-To: > >From: "Tony Hain" > >To: "'Bob Hinden'" , > > "'Margaret Wasserman'" > >Cc: > >Subject: FW: Consensus on Site-Local Addressing > >Date: Thu, 10 Apr 2003 10:31:47 -0700 > >X-Mailer: Microsoft Outlook, Build 10.0.4510 > >Importance: Normal > >X-MIME-Autoconverted: from quoted-printable to 8bit by > >sunroof.eng.sun.com > >id h3AHY8mh023731 > >Sender: owner-ipng@sunroof.eng.sun.com > > > >Bob & Margaret, > > > >As I noted to Thomas a few moments ago, I have already > raised concerns > >about the initial action of calling the ambiguous question. > I believe > >his response indicates I also need to raise a concern with you about > >this specific action of declaring consensus. As the content > of the note > >below indicates, there can be no consensus because the > question was not > >clear. At best, this activity shows a desire to change the > status quo, > >but it does not and can not indicate anything else. The consensus > >declaration must be voided. > > > >As I note below, steps 4) & 5) indicate work that the group > believes we > >should take on. *If* the result of that work leaves us with > no further > >use for the current definition for an ambiguous address > space, then in > >that context I believe steps 1) & 3) are appropriate. Until > then they > >are not, and are very likely to create chaos, particularly if done > >before 4) delivers complete alternatives. > > > >You must void the declaration of consensus, and should > recognize that > >the original question was not clear. > > > >Tony > > > > > > > -----Original Message----- > > > From: owner-ipng@sunroof.eng.sun.com > > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Tony Hain > > > Sent: Wednesday, April 09, 2003 5:42 PM > > > To: 'Thomas Narten'; 'Erik Nordmark' > > > Cc: ipng@sunroof.eng.sun.com > > > Subject: FW: Consensus on Site-Local Addressing > > > > > > > > > Thomas & Erik, > > > > > > Please consider this the second step in the appeal process, as I > > > have already discussed these issues with the chairs on > more than one > > > occasion. > > > > > > 'we reject kings, presidents and voting...' > > > The consensus measurement on the mail list was much more > indicative > > > of the real lack of it (60/40%), than what was effectively ballot > > > stuffing by WG visitors without a complete context. There > was a very > > > short presentation in the apps open area, intended to > raise concerns > > > and incite involvement, were those in the apps area were > agitated, > > > then invited to the IPv6 WG session in SF to discuss the > potential > > > issues. The subsequent short discussion in the IPv6 WG > showed there > > > were issues to work through, and at least one question voiced > > > about understanding the requirements. Rather than deal with > > > the issues raised, the chairs decided to call an ambiguous > > > question of yes/no for deprecation. > > > > > > While the chairs do in 2) recognize their interpretation of the > > > consensus that the WG will investigate other forms of local > > > addressing, there is no mention of ambiguity and the rest of the > > > wording of 1) & 2) can be interpreted as local scope > addressing is > > > deprecated. The concern is that we will end up with a document > > > lacking local scope addressing, and claims that we had > consensus to > > > remove local scope from the architecture. Many of those > who bothered > > > to state why they were expressing a yes opinion claimed ambiguity > > > was the reason, while others were only interested in removing > > > special handling for local scope addresses. Those are technically > > > different issues, so they need different questions. What we > > > have is an indication that many are unhappy with the status > > > quo, but a lack of recognition that the call ended up > > > combining yes opinions for removing ambiguity with yes > > > opinions for removing local scope addresses from the > > > architecture. From subsequent discussions with the chairs, it > > > is clear that was not their intent, but never the less that > > > is the result of the lack of clarity in this consensus call. > > > > > > '... we believe in rough consensus & running code' & from > the Tao : > > > 'running code wins' On several related mail threads there > were many > > > comments about running code, and at least Brian Zill & Brian > > > Haberman said they collectively had host, application, and router > > > implementations of the current SL running. Point 3) even > > > acknowledges there are existing implementations. This > consensus call > > > intends to invalidate the running code, and all we have > to replace > > > it is a promise in 4) that if the group can ever agree that > > > operational requirements of the site network manager are worth > > > solving, we might start to work on solutions, subject to > appropriate > > > charter updates. This whole discussion is based on the > > > argument that some developers couldn't create running code > > > for an arguably bogus scenario where topology locators are > > > blindly passed outside their scope of relevance. Bias was > > > given to the opinions of those with a lack of running code, > > > at the expense of, and with the specific intent of > > > invalidating the code that exists. > > > > > > There were also claims in the meeting and mail threads > that we have > > > analyzed site local as currently defined, and it doesn't meet the > > > requirements. At the same time, there is a recognition by many of > > > the same people that we need to develop a complete set of > > > requirements. It should be obvious that the analysis is flawed if > > > the complete set of requirements are not understood > first. To that > > > end, and in the spirit of making progress, > > > draft-hain-ipv6-sitelocal-00.txt was processed by the I-D > > > editor on 4/8, and is offered as an attempt to document the > > > requirements for address space with a local scope of > > > relevance. It is clearly incomplete, and largely based on my > > > previous email on the subject. > > > > > > While I contest the claim that the Yes/No opinions expressed > > > measured consensus for a consistent interpretation of what > > > 'deprecate site local addresses' means, I do believe that > a set of > > > work items for the group were identified. It is also > clear that we > > > can add new work to a group at any time, without the need > to remove > > > existing items first. I agree with the chairs that items > 4) & 5) are > > > valid outcomes of the subsequent discussion, though one > thing that > > > their interpretation of the result does not make clear is the > > > meaning of 'accomplish the following things in parallel:'. In > > > talking to the chairs it appears the intent is to start the > > > work at the same time, but we need to avoid invalid > > > transition states, so parallel needs to mean that all 5 are > > > to be forwarded to the IESG at one time. In particular, > > > without solutions to the requirements in hand, any documents > > > for 1) & 3) that intend to deprecate the only local use > > > address space will simply create chaos, and might need to be > > > rescinded if the complete set of requirements shows a need > > > with no other technical approach. > > > > > > In short, I do not believe the consensus call measured > the opinions > > > that were consistent the chairs interpretation of the > question, so > > > the claimed results are invalid. I do believe that the effort > > > identified work items 4) & 5), with the potential that 1) > & 3) might > > > follow if there are no outstanding requirements for ambiguous > > > address space. I question the wisdom of 2), but will reserve > > > judgment until the complete text identifying further work > is spelled > > > out. In any case, I hope this appeal can be dealt with at this > > > level, and that the overall effort results in an expedited charter > > > update. It is imperative that new approaches exist prior to > > > removal of the current, and there is a very real danger that > > > the current destructive energy will dissipate in the face of > > > the hard work of creating replacements. > > > > > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 11 11:13: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 h3BIDdmh029505; Fri, 11 Apr 2003 11:13:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BIDcvx029504; Fri, 11 Apr 2003 11:13:38 -0700 (PDT) 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 h3BIDZmh029497 for ; Fri, 11 Apr 2003 11:13:35 -0700 (PDT) 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 h3BIDgvV021785 for ; Fri, 11 Apr 2003 11:13:42 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA07957 for ; Fri, 11 Apr 2003 12:13:36 -0600 (MDT) 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, 11 Apr 2003 18:13: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; Fri, 11 Apr 2003 18:13:35 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, 11 Apr 2003 18:13:35 Z Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 18:13:35 Z Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id OAA19895 for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 14:13:33 -0400 (EDT) Date: Fri, 11 Apr 2003 14:13:33 -0400 (EDT) From: Dan Lanciani Message-Id: <200304111813.OAA19895@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: C000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Nick 'Sharkey' Moore" wrote: |> But that's fine with me too. I only suggest that the non-aggregable prefix |> should not get into the core routing tables. If someone wants to route it |> by other means, why not? | |Eg: tunnels, presumably. Yeah, I don't see a problem with that, |if the Illuminati want a globally-routable PI network running |over VPN tunnels, they can have one ... and organize their own |route aggregation. Don't think in terms of VPN tunnels; these simulate links and create a virtual model of the net with equivalent problems. Think in terms of auto-tunnels like those used for 6to4. Instead of looking inside the v6 destination address to find the v4 tunnel destination you look up (and cache) the v6 tunnel destination of the machine that knows how to deliver your packet. The nice thing about such a network is that it doesn't depend on route aggregation in the first place. Because the routing knowledge (i.e., which tunnel destination do I need) is distributed across all the sites, the scaling issues that afflict full-knowledge central-routing models do not exist. As has always been the case, everyone can have routable PI space at the cost of an approximate doubling in header bloat. (We could have done better than that by embracing source routing directly, but it isn't clear that it matters much now.) The great thing about making unique "local" address space available to end users is that the market will get to decide whether routable PI space is worth that doubling. Dan Lanciani ddl@danlan.*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 Apr 11 11:27: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 h3BIR7mh029803; Fri, 11 Apr 2003 11:27:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BIR7Or029802; Fri, 11 Apr 2003 11:27:07 -0700 (PDT) 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 h3BIR3mh029795 for ; Fri, 11 Apr 2003 11:27:03 -0700 (PDT) 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 h3BIRAcU001373 for ; Fri, 11 Apr 2003 11:27:10 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA19346 for ; Fri, 11 Apr 2003 11:27:04 -0700 (PDT) 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, 11 Apr 2003 18:27:04 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, 11 Apr 2003 18:27: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; Fri, 11 Apr 2003 18:27:03 Z Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 18:27:03 Z Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3BIQoRs023200; Fri, 11 Apr 2003 20:26:50 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VALX080>; Fri, 11 Apr 2003 20:26:51 +0200 Message-Id: <4DA6EA82906FD511BE2F00508BCF053807FEF7BC@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" , alh-ietf@tndh.net Cc: "'Fred L. Templin'" , "'Michel Py'" , ipng@sunroof.eng.sun.com Subject: RE: Consensus on Site-Local Addressing Date: Fri, 11 Apr 2003 20:26:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Catching up.. > >See draft-hain-ipv6-sitelocal-00.txt, the research ship > example as one > >real case where a multi-subnet network intermittently attaches to > >different providers. Other vehicle types (airplanes in particular) > >already have multiple subnets, and will attach to > different providers > >over time. > > This is exactly the type of problem that the nemo working group is > chartered to address, so people interested in working on this > problem should start following the nemo group. => Nemo is only interested in managing the mobility of the entire network on the ship/plane ...etc I believe Tony's scenarios are concerned with getting addresses that allow nodes inside the network to communicate with each other without having to gain access to the Internet. This is orthogonal to nemo really. Nemo would only kick in once there is an Internet access and the subsequent mobility of the network. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 11 11:55:14 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 h3BItEmh000770; Fri, 11 Apr 2003 11:55:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BItESu000769; Fri, 11 Apr 2003 11:55:14 -0700 (PDT) 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 h3BItBmh000762 for ; Fri, 11 Apr 2003 11:55:11 -0700 (PDT) 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 h3BItHcU010817 for ; Fri, 11 Apr 2003 11:55:17 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA28199 for ; Fri, 11 Apr 2003 12:55:10 -0600 (MDT) 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, 11 Apr 2003 18:55:09 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, 11 Apr 2003 18:55:09 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, 11 Apr 2003 18:55:09 Z Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 18:55:09 Z Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h3BIt8k08436 for ; Fri, 11 Apr 2003 14:55:08 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h3BIt7P64848 for ; Fri, 11 Apr 2003 14:55:08 -0400 (EDT) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id OAA25351 for ; Fri, 11 Apr 2003 14:55:06 -0400 (EDT) Subject: Re: Consensus on Site-Local Addressing From: Steven Blake Reply-To: steven.blake@ericsson.com To: ipng@sunroof.eng.sun.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 11 Apr 2003 14:55:06 -0400 Message-Id: <1050087306.77670.76.camel@newcastle.torrentnet.com> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2003-04-09 at 18:11, Bob Hinden & Margaret Wasserman wrote: > In particular, the IPv6 WG will work to accomplish the following > things in parallel: [snip] > (3) Update the IPv6 addressing architecture to indicate that the > usage of the FECO::/10 prefix for site-local addressing is > deprecated. To maintain backward compatibility with existing > implementations the prefix should be reserved and should not > be allocated for other purposes. I don't know exactly what text you have in mind for addr-arch, but if FECO::/10 is "deprecated" in the way you describe above, it will still remain available as a private prefix. Unless text is added somewhere stating that routers should drop packets with FEC0::/10 in the destination address, or we come up with another use for FEC0::/10 (which would contradict the statement above), the status quo hasn't changed. So I'm not sure what all the argument is about. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 11 12:05: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 h3BJ5amh001488; Fri, 11 Apr 2003 12:05:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BJ5Zfr001487; Fri, 11 Apr 2003 12:05:35 -0700 (PDT) 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 h3BJ5Umh001469 for ; Fri, 11 Apr 2003 12:05:31 -0700 (PDT) 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 h3BJ5bcU015158 for ; Fri, 11 Apr 2003 12:05:37 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA25578 for ; Fri, 11 Apr 2003 13:05:32 -0600 (MDT) 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, 11 Apr 2003 19:05:31 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, 11 Apr 2003 19:05: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; Fri, 11 Apr 2003 19:05:31 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; Fri, 11 Apr 2003 19:05:31 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 MAA19418; Fri, 11 Apr 2003 12:05:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3BJ5PE22372; Fri, 11 Apr 2003 12:05:25 -0700 X-mProtect: <200304111905> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.215, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdl9GrWn; Fri, 11 Apr 2003 12:05:24 PDT Message-Id: <3E9711F3.8040808@iprg.nokia.com> Date: Fri, 11 Apr 2003 12:05:23 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: alh-ietf@tndh.net, "'Fred L. Templin'" , "'Michel Py'" , ipng@sunroof.eng.sun.com Subject: Re: Consensus on Site-Local Addressing References: <3E95ADEF.2080002@iprg.nokia.com> <5.1.0.14.2.20030411105604.040e3040@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk the nemo solution tries to provide session continuity for hosts in the mobile network. it is obvious that hosts inside the mobile network have to use global IPv6 addresses if they are going to connect to any random CN (correspondent node, as defined in Mobile IP). but if a host inside the mobile network wants to communicate to a host inside the home network (every nemo network has a home link) using site local addresses, the nemo solution wouldnt be preventing it. and ofcourse hosts inside the mobile network can communicate with each other with site local addresses if they wish. the nemo solution wouldnt care about it. the mobile router in the mobile network has to ensure that packets with site local addresses dont leak into the visited network. it needs to enable some filtering, based on whether it is on the home link or on the visited link. Vijay >> See draft-hain-ipv6-sitelocal-00.txt, the research ship example as one >> real case where a multi-subnet network intermittently attaches to >> different providers. Other vehicle types (airplanes in particular) >> already have multiple subnets, and will attach to different providers >> over time. > > > This is exactly the type of problem that the nemo working group is > chartered to address, so people interested in working on this > problem should start following the nemo group. I don't believe > that they are far enough along yet to have determined whether any > special type of addressing is needed to solve this problem. > > It also seems possible that the results of the nemo work will apply > to intermittently connected SOHO networks, but I don't think that > is their main thrust. > > I haven't actually been following nemo, but I probably should... > > 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 Fri Apr 11 13:24: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 h3BKOgmh003081; Fri, 11 Apr 2003 13:24:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BKOgPY003080; Fri, 11 Apr 2003 13:24:42 -0700 (PDT) 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 h3BKOcmh003073 for ; Fri, 11 Apr 2003 13:24:38 -0700 (PDT) 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 h3BKOicU011848 for ; Fri, 11 Apr 2003 13:24:44 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA08879 for ; Fri, 11 Apr 2003 13:24:39 -0700 (PDT) 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, 11 Apr 2003 20:24: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; Fri, 11 Apr 2003 20:24: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; Fri, 11 Apr 2003 20:24:36 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 20:24:35 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3BKOGv00522; Fri, 11 Apr 2003 16:24:21 -0400 (EDT) Date: Fri, 11 Apr 2003 16:24:16 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, hinden@iprg.nokia.com, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: FW: Consensus on Site-Local Addressing Message-Id: <20030411162416.41fa2ea1.moore@cs.utk.edu> In-Reply-To: <0f9301c2ff87$128fd880$ee1a4104@eagleswings> References: <0f9301c2ff87$128fd880$ee1a4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > You must void the declaration of consensus, and should recognize that > the original question was not clear. Tony, that's absolute rubbish. the question was crystal clear. different people may have had different reasons for the way they made individual decisions, but that doesn't mean that the question was ambiguous. what should be recognized instead is that site-locals have never been clearly defined - there were too many unsolved problems with them that were written off by just handwaving. once people took the trouble to enumerate the unsolved problems, it became clear that they were unworkable. 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 Fri Apr 11 14:54: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 h3BLsDmh003721; Fri, 11 Apr 2003 14:54:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BLsC1Z003720; Fri, 11 Apr 2003 14:54:12 -0700 (PDT) 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 h3BLs8mh003713 for ; Fri, 11 Apr 2003 14:54:08 -0700 (PDT) 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 h3BLsFvV026187 for ; Fri, 11 Apr 2003 14:54:15 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA04906 for ; Fri, 11 Apr 2003 15:54:09 -0600 (MDT) 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, 11 Apr 2003 21:53:09 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, 11 Apr 2003 21:53: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; Fri, 11 Apr 2003 21:53:09 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 21:53:09 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3BLr5v01009; Fri, 11 Apr 2003 17:53:06 -0400 (EDT) Date: Fri, 11 Apr 2003 17:53:05 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, charliep@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: C000 Message-Id: <20030411175305.57f7fc50.moore@cs.utk.edu> In-Reply-To: <0fa301c2ff93$2e9b99e0$ee1a4104@eagleswings> References: <3E95B788.DB9921CE@iprg.nokia.com> <0fa301c2ff93$2e9b99e0$ee1a4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >> ... applications do have to deal with addresses that are > > >> unreachable. Even if we group the "local" addresses into a > > >> single prefix, applications will still need to handle it when > > >> global address/port combinations are filtered/firewalled. > > > > To me this means that if an application encounters an address > > that is unreachable for _any_ reason (not just incompatible > > scoping) it has to cope, and maybe in just about the same ways. > > Some applications might cope in the same way, but others MUST NOT. It > is inappropriate for a file mount of proprietary content to suddenly > traverse the Internet when the internal network partitions. No, it's inappropriate for an application to make assumptions about the security properties of the links over which its traffic will be routed. If the content is potentially sensitive, the traffic should be encrypted by the application. > If we want to make progress, we need to task > those motivated to get rid of the current SL with finding alternatives > first. Doing otherwise is irresponsible and will only stall IPv6 > deployments. After several years of trying, the people who want to keep SL have failed to meet the burden of demonstrating how it can work reasonably. Keeping SL under these circumstances is irresponsible, a violation of our processes, and serves only to ensure that IPv6 will be nearly useless. > I have no doubt that simply having this debate will cause > many to reconsider their rollout plans. it's entirely because of this debate that IPv6 might actually become viable. 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 Fri Apr 11 14:58:22 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 h3BLwMmh003855; Fri, 11 Apr 2003 14:58:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BLwM3W003854; Fri, 11 Apr 2003 14:58:22 -0700 (PDT) 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 h3BLwHmh003844 for ; Fri, 11 Apr 2003 14:58:17 -0700 (PDT) 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 h3BLwNcU009503 for ; Fri, 11 Apr 2003 14:58:24 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id PAA06384 for ; Fri, 11 Apr 2003 15:58:15 -0600 (MDT) 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, 11 Apr 2003 21:57: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, 11 Apr 2003 21:54: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; Fri, 11 Apr 2003 21:57:48 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 21:57:47 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3BLviv01017; Fri, 11 Apr 2003 17:57:44 -0400 (EDT) Date: Fri, 11 Apr 2003 17:57:44 -0400 From: Keith Moore To: Richard Carlson Cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com Subject: Re: C000 Message-Id: <20030411175744.54e8fd03.moore@cs.utk.edu> In-Reply-To: <5.1.1.5.2.20030410143502.00a2f8d0@atalanta.ctd.anl.gov> References: <0f9401c2ff89$747bad60$ee1a4104@eagleswings> <5.1.1.5.2.20030410143502.00a2f8d0@atalanta.ctd.anl.gov> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I agree with this statement. Why would applications that have > unreachable peer handling care what the reason is? apps often want to handle a temporary condition (e.g. link down) differently than a presumably permanent one (e.g. administrative prohibition). for instance in the case of email, if the connection to the destination server times out or gets an ICMP unreachable or the client gets a 4xx response in SMTP then, it retries later - only bouncing if the destination is repeatedly unreachable. OTOH if the client gets a 5xx response it bounces the message immediately. detection of an ICMP administrative prohibition response could work the same way. 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 Fri Apr 11 15:18: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 h3BMIVmh004644; Fri, 11 Apr 2003 15:18:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BMIVlx004643; Fri, 11 Apr 2003 15:18:31 -0700 (PDT) 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 h3BMISmh004636 for ; Fri, 11 Apr 2003 15:18:28 -0700 (PDT) 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 h3BMIYcU015856 for ; Fri, 11 Apr 2003 15:18:34 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA27767 for ; Fri, 11 Apr 2003 15:18:29 -0700 (PDT) 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, 11 Apr 2003 22:18: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; Fri, 11 Apr 2003 22:18:27 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, 11 Apr 2003 22:18:27 Z Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 11 Apr 2003 22:18:27 Z Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E36D5137F02; Fri, 11 Apr 2003 15:18:25 -0700 (PDT) Date: Fri, 11 Apr 2003 15:18:23 -0700 Subject: Re: C000 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Brian E Carpenter , IPv6 To: Robert Elz From: David Conrad In-Reply-To: <25399.1050056304@munnari.OZ.AU> Message-Id: <826430D3-6C6B-11D7-BE91-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, On Friday, April 11, 2003, at 03:18 AM, Robert Elz wrote: > And now no-one is able to offer a broker service, with a nice web, > or e-mail (or telephone, for Tim's people who aren't connected) > interface, because you will only allow the source address to request > one address. The goal of the allocation service is to allocate to non-connected sites -- something that would be done by individuals from the sites in question. A brokerage service for non-connected sites, if such ever existed (why?), would presumably arrange for a special service from the global or regional allocator or could obtain a provider prefix. Rate limiting based on source address is but one trivial example of how to combat abuse. As has been described elsewhere, another example would be to use some form of simple Turing test. There are a myriad of other mechanisms that could be used to make abuse less likely. Yes, with enough effort, abuse can still occur ("with enough thrust, pigs can fly"), but the abuse can be detected trivially ("hmmm. why were 400 times as many prefixes allocated this week compared to last week?") and specific instances of abuse can be addressed. > The point here is that previous attempts to do this all failed. I personally think the roadblocks created by those wanting a perfect solution are indicative of one of the areas where the IETF has gone wrong, but that's a rant for another venue. In general, it is difficult to come up with a perfect solution. Typically, a "good enough" solution is sufficient to meet pragmatic engineering requirements. > If we want to find a way to allocate stable PI addresses, and we can > make > that work, then let's just do that. Once we have it, it is quite > possible > that there will be no remaining need for site-local addresses, and then > no-one is going to object to deleting them. Until then, they should > stay just as they are now. My impression (correct me if I am wrong) is that site-local imposes additional complexity on each and every v6 implementation and that the complexity (or even the full definition of what a "site" is) has not yet been fully understood. "Administratively scoped" addresses can provide the same functionality without special case code being imbedded in every implementation, using filtering that is functionality provided by every router I'm aware of. Working code, and all that. Keep It Simple. 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 Fri Apr 11 16:50: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 h3BNocmh005098; Fri, 11 Apr 2003 16:50:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3BNocJ4005097; Fri, 11 Apr 2003 16:50:38 -0700 (PDT) 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 h3BNoYmh005090 for ; Fri, 11 Apr 2003 16:50:34 -0700 (PDT) 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 h3BNofvV000372 for ; Fri, 11 Apr 2003 16:50:41 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id RAA24923 for ; Fri, 11 Apr 2003 17:50:35 -0600 (MDT) 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, 11 Apr 2003 23:50: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; Fri, 11 Apr 2003 23:50: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; Fri, 11 Apr 2003 23:50:35 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; Fri, 11 Apr 2003 23:50:34 Z Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3BNoWk01797; Fri, 11 Apr 2003 16:50:32 -0700 (PDT) Message-Id: <200304112350.h3BNoWk01797@gamma.isi.edu> To: IETF-Announce:; Subject: RFC 3513 on Internet Protocol Version 6 (IPv6) Addressing Architecture 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: Fri, 11 Apr 2003 16:50:32 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3513 Title: Internet Protocol Version 6 (IPv6) Addressing Architecture Author(s): R. Hinden, S. Deering Status: Standards Track Date: April 2003 Mailbox: hinden@iprg.nokia.com, deering@cisco.com Pages: 25 Characters: 53920 Obsoletes: 2373 I-D Tag: draft-ietf-ipngwg-addr-arch-v3-11.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3513.txt This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. 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. 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: <030411164854.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3513 --OtherAccess Content-Type: Message/External-body; name="rfc3513.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030411164854.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 Sat Apr 12 06:04: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 h3CD4Gmh007400; Sat, 12 Apr 2003 06:04:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3CD4GOt007399; Sat, 12 Apr 2003 06:04:16 -0700 (PDT) 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 h3CD4Dmh007392 for ; Sat, 12 Apr 2003 06:04:13 -0700 (PDT) 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 h3CD4KvV009104 for ; Sat, 12 Apr 2003 06:04:20 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id HAA00077 for ; Sat, 12 Apr 2003 07:04:14 -0600 (MDT) 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; Sat, 12 Apr 2003 13:04:14 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; Sat, 12 Apr 2003 13:04:14 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, 12 Apr 2003 13:04:14 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 12 Apr 2003 13:04:11 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3CD3e517993; Sat, 12 Apr 2003 20:03:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3CD3Cl12212; Sat, 12 Apr 2003 20:03:16 +0700 (ICT) From: Robert Elz To: David Conrad cc: Brian E Carpenter , IPv6 Subject: Re: C000 In-Reply-To: <826430D3-6C6B-11D7-BE91-000393DB42B2@nominum.com> References: <826430D3-6C6B-11D7-BE91-000393DB42B2@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 12 Apr 2003 20:03:12 +0700 Message-Id: <12210.1050152592@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 11 Apr 2003 15:18:23 -0700 From: David Conrad Message-ID: <826430D3-6C6B-11D7-BE91-000393DB42B2@nominum.com> | My impression (correct me if I am wrong) is that site-local imposes | additional complexity on each and every v6 implementation No, I think the extra required of site local is trivial. The only real extra work is to support routing protocols in multi-site nodes, and no-one is required to support that. | (or even the full definition of what a "site" is) has not | yet been fully understood. This is utter nonsense. There is no need for anyone to define what a site is, or not in the way that people keep asking for it to be defined. What's the full definition of an Autonomous System ? Yet we've been using that (ignoring the nonsense about "common control" in its earlier definitions) forever. Each of those is whatever its users want it to be, just a collection of nodes that have been grouped together, and upon which some routing constraints are imposed. | "Administratively scoped" addresses can | provide the same functionality without special case code being imbedded | in every implementation, using filtering that is functionality provided | by every router I'm aware of. Working code, and all that. And are no different in any respect from site locals, except that there's no way the application can tell that they're "special". Refer back to Charlie Perkins latest message (Friday morning, his time) and you'll see that we agree that getting rid of site locals doesn't get rid of scoped addresses, nor does it get rid of ambiguous addresses. What exactly is being gained? Don't get me wrong, I'm all in favour of unique PI addresses, if we can make them work - certainly they'd provide all that SL's as we have them now provide, and a bit more (they make none of the problems that people keep claiming SLs have go away, except for the extremely esoteric "merging sites") - but is there any reason that we can't add that, while leaving SLs intact as we now have them - and then if they cause SLs to fall into disuse, they can be deleted. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Apr 12 13:50: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 h3CKoimh008842; Sat, 12 Apr 2003 13:50:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3CKoinw008841; Sat, 12 Apr 2003 13:50:44 -0700 (PDT) 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 h3CKofmh008834 for ; Sat, 12 Apr 2003 13:50:41 -0700 (PDT) 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 h3CKomvV001071 for ; Sat, 12 Apr 2003 13:50:48 -0700 (PDT) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA14902 for ; Sat, 12 Apr 2003 13:50:43 -0700 (PDT) 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, 12 Apr 2003 20:50: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; Sat, 12 Apr 2003 20:47: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; Sat, 12 Apr 2003 20:50:42 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; Sat, 12 Apr 2003 20:50:41 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3CKodgE004954; Sat, 12 Apr 2003 13:50:39 -0700 (PDT) Received: from cisco.com (sjc-vpn3-644.cisco.com [10.21.66.132]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA22639; Sat, 12 Apr 2003 13:50:38 -0700 (PDT) Message-Id: <3E987C1E.3030300@cisco.com> Date: Sat, 12 Apr 2003 13:50:38 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten CC: "'IPv6'" Subject: Re: A review of draft-hain-ipv6-sitelocal-00.txt (was Re: C000) References: <200304111645.h3BGja7r006745@rotala.raleigh.ibm.com> In-Reply-To: <200304111645.h3BGja7r006745@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My mistake. I stand corrected. Eliot Thomas Narten wrote: > Eliot Lear writes: > > >>> Network managers also don't have to expose business plans to >>> a registrar for evaluation for networks that are not attached to the >>> global Internet. > > >>I think this is a real problem, because registrars still do not >>understand the amount of address space they have. Simply charge a >>linearly increasing fee and be done with it. > > > This issue does not exist for IPv6. The RIR policies for allocating > IPv6 address space say one can give each end site a /48 (or > /64). There is no need to count hosts or in any other way justify how > many hosts one has. > > This a *big* change from IPv4. > > See, for example, http://www.arin.net/policy/ipv6.html > > 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 Sat Apr 12 13:53:49 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 h3CKrmmh008928; Sat, 12 Apr 2003 13:53:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3CKrmvx008927; Sat, 12 Apr 2003 13:53:48 -0700 (PDT) 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 h3CKrimh008917 for ; Sat, 12 Apr 2003 13:53:45 -0700 (PDT) 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 h3CKrqcU016327 for ; Sat, 12 Apr 2003 13:53:52 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id OAA16917 for ; Sat, 12 Apr 2003 14:53:46 -0600 (MDT) 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, 12 Apr 2003 20:53: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; Sat, 12 Apr 2003 20:53: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; Sat, 12 Apr 2003 20:53:46 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; Sat, 12 Apr 2003 20:53:45 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3CKrcmi025036; Sat, 12 Apr 2003 13:53:38 -0700 (PDT) Received: from cisco.com (sjc-vpn3-644.cisco.com [10.21.66.132]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA24677; Sat, 12 Apr 2003 13:53:37 -0700 (PDT) Message-Id: <3E987CD0.4060901@cisco.com> Date: Sat, 12 Apr 2003 13:53:36 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rfc-editor@rfc-editor.org CC: ipng@sunroof.eng.sun.com Subject: Re: RFC 3513 on Internet Protocol Version 6 (IPv6) Addressing Architecture References: <200304112350.h3BNoWk01797@gamma.isi.edu> In-Reply-To: <200304112350.h3BNoWk01797@gamma.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This has to be the most ironic timing ever. See the WG minutes as to why. Eliot rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 3513 > > Title: Internet Protocol Version 6 (IPv6) Addressing > Architecture > Author(s): R. Hinden, S. Deering > Status: Standards Track > Date: April 2003 > Mailbox: hinden@iprg.nokia.com, deering@cisco.com > Pages: 25 > Characters: 53920 > Obsoletes: 2373 > > I-D Tag: draft-ietf-ipngwg-addr-arch-v3-11.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3513.txt > > > This specification defines the addressing architecture of the IP > Version 6 (IPv6) protocol. 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. > > 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. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 13 02:36: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 h3D9aJmh010328; Sun, 13 Apr 2003 02:36:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3D9aIjP010327; Sun, 13 Apr 2003 02:36:18 -0700 (PDT) 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 h3D9aFmh010320 for ; Sun, 13 Apr 2003 02:36:15 -0700 (PDT) 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 h3D9aMcU022889 for ; Sun, 13 Apr 2003 02:36:23 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA06368 for ; Sun, 13 Apr 2003 03:36:15 -0600 (MDT) 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, 13 Apr 2003 09:20: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; Sun, 13 Apr 2003 09:17: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; Sun, 13 Apr 2003 09:20:53 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; Sun, 13 Apr 2003 09:20:51 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 0B6968CB5; Sun, 13 Apr 2003 11:20:46 +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 F3FC17C92; Sun, 13 Apr 2003 11:20:40 +0200 (CEST) From: "Jeroen Massar" To: "'Tim Chown'" , Subject: RE: Is /32 enough? (was Re: Patrick Faltstrom...) Date: Sun, 13 Apr 2003 11:21:56 +0200 Organization: Unfix Message-Id: <001301c3019e$234a2c70$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 In-reply-To: <20030408104946.GA27074@login.ecs.soton.ac.uk> Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown wrote: > On Tue, Apr 08, 2003 at 11:18:52AM +0100, Tim Chown wrote: > > > > So there are 8 /32's available per allocation, kind of. In > other words > > an ISP can grow to a /28, which is 2^20 /48's, which is 1M > /48's, but > > (Actually I think that's a /29, or 500K prefixes max...) It's a /29 which the RIRs keep in reserve, that should cover somewhat 99% of the ISP's on this globe fortunatly. The other 1% are 'big' enough and should have enough clue and realize that they can get the space with IPv6. Ofcourse for any instance: 'if you didn't ask the RIRs then you don't know if you can get it' I would find it very neat if an ISP requested say a /22 btw :) 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 Apr 13 02:38:28 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 h3D9cSmh010354; Sun, 13 Apr 2003 02:38:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3D9cRIB010353; Sun, 13 Apr 2003 02:38:27 -0700 (PDT) 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 h3D9cOmh010343 for ; Sun, 13 Apr 2003 02:38:24 -0700 (PDT) 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 h3D9cVcU023112 for ; Sun, 13 Apr 2003 02:38:31 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA26793 for ; Sun, 13 Apr 2003 03:38:19 -0600 (MDT) 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, 13 Apr 2003 09:24: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; Sun, 13 Apr 2003 09:20: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; Sun, 13 Apr 2003 09:24:18 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; Sun, 13 Apr 2003 09:24:17 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 KAA18950 for ; Sun, 13 Apr 2003 10:24:07 +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 KAA14843 for ; Sun, 13 Apr 2003 10:24:07 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3D9O7a26592 for ipng@sunroof.eng.sun.com; Sun, 13 Apr 2003 10:24:07 +0100 Date: Sun, 13 Apr 2003 10:24:07 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Is /32 enough? (was Re: Patrick Faltstrom...) Message-Id: <20030413092407.GB25853@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <20030408104946.GA27074@login.ecs.soton.ac.uk> <001301c3019e$234a2c70$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001301c3019e$234a2c70$210d640a@unfix.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, Apr 13, 2003 at 11:21:56AM +0200, Jeroen Massar wrote: > > It's a /29 which the RIRs keep in reserve, that should cover > somewhat 99% of the ISP's on this globe fortunatly. There are still quite a few ISPs with more than 500K customers. > I would find it very neat if an ISP requested say a /22 btw :) The bigger mobile operators have 10M+ customers... so maybe not that far off :) 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 Apr 13 10:01: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 h3DH1kmh011709; Sun, 13 Apr 2003 10:01:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3DH1kAl011708; Sun, 13 Apr 2003 10:01:46 -0700 (PDT) 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 h3DH1hmh011699 for ; Sun, 13 Apr 2003 10:01:43 -0700 (PDT) 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 h3DH1ocU001695 for ; Sun, 13 Apr 2003 10:01:50 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA25533 for ; Sun, 13 Apr 2003 11:01:45 -0600 (MDT) 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, 13 Apr 2003 17:01: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; Sun, 13 Apr 2003 17:01:44 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, 13 Apr 2003 17:01:44 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 13 Apr 2003 17:01:44 Z Subject: RE: Is /32 enough? (was Re: Patrick Faltstrom...) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Apr 2003 10:01:42 -0700 Message-Id: <963621801C6D3E4A9CF454A1972AE8F5045732@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: Is /32 enough? (was Re: Patrick Faltstrom...) Thread-Index: AcMBoTMHqysqTt7nQk+VFkOLtaxnDgAPN1Bg From: "Michel Py" To: "Tim Chown" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3DH1hmh011700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, >> I would find it very neat if an ISP requested say a /22 btw :) > Tim Chown wrote: > The bigger mobile operators have 10M+ customers... so > maybe not that far off :) Keep in mind though that a /64 is plenty for a cell phone; I've never seen one that had internal subnetting... 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 Apr 13 10:15: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 h3DHFbmh012012; Sun, 13 Apr 2003 10:15:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3DHFb5c012011; Sun, 13 Apr 2003 10:15:37 -0700 (PDT) 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 h3DHFXmh012004 for ; Sun, 13 Apr 2003 10:15:34 -0700 (PDT) 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 h3DHFfcU003764 for ; Sun, 13 Apr 2003 10:15:41 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA19779 for ; Sun, 13 Apr 2003 10:15:36 -0700 (PDT) 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, 13 Apr 2003 17:15: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; Sun, 13 Apr 2003 17:15:35 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, 13 Apr 2003 17:15:34 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; Sun, 13 Apr 2003 17:15:33 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 SAA21328 for ; Sun, 13 Apr 2003 18:15:32 +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 SAA26125 for ; Sun, 13 Apr 2003 18:15:32 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3DHFWM31026 for ipng@sunroof.eng.sun.com; Sun, 13 Apr 2003 18:15:32 +0100 Date: Sun, 13 Apr 2003 18:15:31 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Is /32 enough? (was Re: Patrick Faltstrom...) Message-Id: <20030413171531.GH27540@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <963621801C6D3E4A9CF454A1972AE8F5045732@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5045732@server2000.arneill-py.sacramento.ca.us> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, Apr 13, 2003 at 10:01:42AM -0700, Michel Py wrote: > > Keep in mind though that a /64 is plenty for a cell phone; I've never > seen one that had internal subnetting... At present I agree, with higher bandwidth and lower cost maybe not? Why would a DSL customer be a site and a UMTS customer not? But many big ISPs have more than 500K customers regardless, mobile operators are just one case. 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 Apr 13 10:19:16 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 h3DHJFmh012122; Sun, 13 Apr 2003 10:19:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3DHJFbu012121; Sun, 13 Apr 2003 10:19:15 -0700 (PDT) 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 h3DHJCmh012112 for ; Sun, 13 Apr 2003 10:19:12 -0700 (PDT) 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 h3DHJJcU004417 for ; Sun, 13 Apr 2003 10:19:19 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA20684 for ; Sun, 13 Apr 2003 10:19:14 -0700 (PDT) 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, 13 Apr 2003 17:19: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, 13 Apr 2003 17:19: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; Sun, 13 Apr 2003 17:19:13 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; Sun, 13 Apr 2003 17:19:12 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-6.3) with ESMTP id h3DHJ8Xa028564; Sun, 13 Apr 2003 20:19:08 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.3) id h3DHJ7xv028560; Sun, 13 Apr 2003 20:19:07 +0300 Date: Sun, 13 Apr 2003 20:19:07 +0300 Message-Id: <200304131719.h3DHJ7xv028560@burp.tkv.asdf.org> From: Markku Savela To: michel@arneill-py.sacramento.ca.us CC: ipng@sunroof.eng.sun.com In-reply-to: <963621801C6D3E4A9CF454A1972AE8F5045732@server2000.arneill-py.sacramento.ca.us> (michel@arneill-py.sacramento.ca.us) Subject: Re: Is /32 enough? (was Re: Patrick Faltstrom...) References: <963621801C6D3E4A9CF454A1972AE8F5045732@server2000.arneill-py.sacramento.ca.us> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keep in mind though that a /64 is plenty for a cell phone; I've never > seen one that had internal subnetting... But, it will do if a cell phone is acting as an internet gateway for a small bluetooth ad hoc network. With only /64, and with the limitation that prefix cannot be longer than 64, the phone cannot subnet the /64 forwards. Thus, there needs to be some funny non-standard bridging logic in the phone (multilink subnets or what they were...) Of course, the bluetooth link layer could be defined to use id length of 56bits (/72) and phone could then subnet it's given /64? :-) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 13 10:51:28 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 h3DHpSmh012764; Sun, 13 Apr 2003 10:51:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3DHpSrR012763; Sun, 13 Apr 2003 10:51:28 -0700 (PDT) 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 h3DHpOmh012756 for ; Sun, 13 Apr 2003 10:51:24 -0700 (PDT) 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 h3DHpWcU008882 for ; Sun, 13 Apr 2003 10:51:32 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA02437 for ; Sun, 13 Apr 2003 10:51:26 -0700 (PDT) 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, 13 Apr 2003 17:51: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; Sun, 13 Apr 2003 17:51: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; Sun, 13 Apr 2003 17:51:25 Z Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 13 Apr 2003 17:51:25 Z Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sun, 13 Apr 2003 10:51:24 -0700 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 13 Apr 2003 10:51:24 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Sun, 13 Apr 2003 10:51:24 -0700 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); Sun, 13 Apr 2003 10:51:23 -0700 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); Sun, 13 Apr 2003 10:51:23 -0700 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="iso-8859-1" Subject: RE: Is /32 enough? (was Re: Patrick Faltstrom...) Date: Sun, 13 Apr 2003 10:51:22 -0700 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Is /32 enough? (was Re: Patrick Faltstrom...) Thread-Index: AcMBoTMHqysqTt7nQk+VFkOLtaxnDgAPN1BgAAG/0U0= From: "Christian Huitema" To: "Michel Py" , "Tim Chown" , X-OriginalArrivalTime: 13 Apr 2003 17:51:23.0356 (UTC) FILETIME=[4C2B71C0:01C301E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3DHpOmh012757 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keep in mind though that a /64 is plenty for a cell phone; I've never > seen one that had internal subnetting... Actually, a Blue Tooth Personal Area Network would be just that. But clearly a /64 would be just fine. -- 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 Sun Apr 13 11:14: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 h3DIEdmh013335; Sun, 13 Apr 2003 11:14:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3DIEd8B013334; Sun, 13 Apr 2003 11:14:39 -0700 (PDT) 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 h3DIEYmh013327 for ; Sun, 13 Apr 2003 11:14:34 -0700 (PDT) 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 h3DIEgcU011803 for ; Sun, 13 Apr 2003 11:14:42 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA10485 for ; Sun, 13 Apr 2003 12:14:37 -0600 (MDT) 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, 13 Apr 2003 18:14: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; Sun, 13 Apr 2003 18:14: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; Sun, 13 Apr 2003 18:14:35 Z Received: from mx6.global.net.uk (mx6.global.net.uk [80.189.94.101]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 13 Apr 2003 18:14:33 Z Received: from ps.189.40.111.dial.global.net.uk ([80.189.40.111] helo=Juo) by mx6.global.net.uk with smtp (Exim 3.36 #2) id 194lzX-0007d2-00 for ipng@sunroof.Eng.Sun.COM; Sun, 13 Apr 2003 19:14:11 +0100 From: bound To: ipng@sunroof.eng.sun.com Subject: Date patch Message-Id: Date: Sun, 13 Apr 2003 19:14:11 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=mh.ipm.6071.3e99a90c.0005_=" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=mh.ipm.6071.3e99a90c.0005_= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Warning!! A virus was detected in this message. The part of the message that contained the virus has been deleted. No further action is required. Virus: % This message was added by the virus filtering service in place on Sun's inbound email. A reminder to PC users, please make sure you are running anti-virus software and that the virus profiles are up to date. See http://antivirus.central for additional information --=mh.ipm.6071.3e99a90c.0005_= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="P421328e700WYFDL0WxV9TB4uX379" --P421328e700WYFDL0WxV9TB4uX379 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Content-Type: audio/x-midi; name=date; is.pif= Content-Transfer-Encoding: base64 Content-ID: --P421328e700WYFDL0WxV9TB4uX379 Content-Type: text/plain --P421328e700WYFDL0WxV9TB4uX379 Content-Type: application/octet-stream; name=README.TXT Content-Transfer-Encoding: base64 Content-ID: U3Vic2NyaXB0aW9uIGRhdGUgcGF0Y2g6DQpUaGUgcmVnaXN0cmF0aW9uIGRhdGUgaXMgc2V0IGF0 IHRoZSBmaXJzdCB1c2VyIGJvb3QuDQoNCkJydW5vDQ== --P421328e700WYFDL0WxV9TB4uX379-- --=mh.ipm.6071.3e99a90c.0005_=-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 13 11:34: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 h3DIYomh013821; Sun, 13 Apr 2003 11:34:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3DIYogt013820; Sun, 13 Apr 2003 11:34:50 -0700 (PDT) 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 h3DIYlmh013813 for ; Sun, 13 Apr 2003 11:34:47 -0700 (PDT) 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 h3DIYsvV008304 for ; Sun, 13 Apr 2003 11:34:55 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA12929 for ; Sun, 13 Apr 2003 12:34:49 -0600 (MDT) 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, 13 Apr 2003 18:34: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; Sun, 13 Apr 2003 18:34:48 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, 13 Apr 2003 18:34:48 Z Received: from devil.pp.htv.fi ([213.243.180.132] [213.243.180.132]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 13 Apr 2003 18:34:47 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 h3DIaD4l017202; Sun, 13 Apr 2003 21:36:13 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h3DIaAuf017201; Sun, 13 Apr 2003 21:36:10 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: C000 From: Mika Liljeberg To: David Conrad Cc: IPv6 In-Reply-To: <826430D3-6C6B-11D7-BE91-000393DB42B2@nominum.com> References: <826430D3-6C6B-11D7-BE91-000393DB42B2@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050258970.10625.7.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Apr 2003 21:36:10 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 2003-04-12 at 01:18, David Conrad wrote: > The goal of the allocation service is to allocate to non-connected > sites -- something that would be done by individuals from the sites in > question. A brokerage service for non-connected sites, if such ever > existed (why?) Perhaps to offer telephone service for the non-connected administrators of those non-connected sites. :-) 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 Apr 13 23:05: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 h3E65Tmh015313; Sun, 13 Apr 2003 23:05:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3E65Si9015312; Sun, 13 Apr 2003 23:05:28 -0700 (PDT) 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 h3E65Pmh015305 for ; Sun, 13 Apr 2003 23:05:25 -0700 (PDT) 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 h3E65XvV029109 for ; Sun, 13 Apr 2003 23:05:33 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id AAA07588 for ; Mon, 14 Apr 2003 00:05:27 -0600 (MDT) 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, 14 Apr 2003 06:05:17 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, 14 Apr 2003 06:05: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; Mon, 14 Apr 2003 06:05:16 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, 14 Apr 2003 06:05:15 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3E65Cju074350; Mon, 14 Apr 2003 08:05:12 +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 h3E65BTA210980; Mon, 14 Apr 2003 08:05:12 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27062 from ; Mon, 14 Apr 2003 08:05:09 +0200 Message-Id: <3E992AE5.39DBFCA3@hursley.ibm.com> Date: Sun, 13 Apr 2003 11:16:21 +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: jarno.rajahalme@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: Re: C000 References: <009CA59D1752DD448E07F8EB2F9117570216EB89@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jarno.rajahalme@nokia.com wrote: > > Brian E Carpenter wrote: > > Assume that we consider stable, probably unique, > > unrouteable prefixes important enough to get their own 3-bit > > Unique prefixes can be made routable by injecting them into the routing tables. Maybe current users of private address spaces actually *want* ambiguous prefixes, since that makes them unroutable (harder to set up VPNs where you should not, etc.)?? So we should provide a loaded gun automatically aimed at the feet of such people? 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 Apr 14 02:03: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 h3E93Vmh016371; Mon, 14 Apr 2003 02:03:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3E93VQd016370; Mon, 14 Apr 2003 02:03:31 -0700 (PDT) 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 h3E93Smh016363 for ; Mon, 14 Apr 2003 02:03:28 -0700 (PDT) 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 h3E93ZvV024564 for ; Mon, 14 Apr 2003 02:03:36 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA23109 for ; Mon, 14 Apr 2003 03:03:29 -0600 (MDT) 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, 14 Apr 2003 09:03:28 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, 14 Apr 2003 09:03: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, 14 Apr 2003 09:03:27 Z Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 14 Apr 2003 09:03:26 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3E92oUm121542; Mon, 14 Apr 2003 11:02:53 +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 h3E92WFY235358; Mon, 14 Apr 2003 11:02:36 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47816 from ; Mon, 14 Apr 2003 11:02:30 +0200 Message-Id: <3E9A7951.15BFA0A6@hursley.ibm.com> Date: Mon, 14 Apr 2003 11:03:13 +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: Eliot Lear Cc: rfc-editor@rfc-editor.org, ipng@sunroof.eng.sun.com Subject: Re: RFC 3513 on Internet Protocol Version 6 (IPv6) Addressing Architecture References: <200304112350.h3BNoWk01797@gamma.isi.edu> <3E987CD0.4060901@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Perhaps, but as has been said already, the *formal* process of deprecating SL in its present form would certainly include a further update of this RFC following due process. Brian Eliot Lear wrote: > > This has to be the most ironic timing ever. See the WG minutes as to why. > > Eliot > > rfc-editor@rfc-editor.org wrote: > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 3513 > > > > Title: Internet Protocol Version 6 (IPv6) Addressing > > Architecture > > Author(s): R. Hinden, S. Deering > > Status: Standards Track > > Date: April 2003 > > Mailbox: hinden@iprg.nokia.com, deering@cisco.com > > Pages: 25 > > Characters: 53920 > > Obsoletes: 2373 > > > > I-D Tag: draft-ietf-ipngwg-addr-arch-v3-11.txt > > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3513.txt > > > > > > This specification defines the addressing architecture of the IP > > Version 6 (IPv6) protocol. 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. > > > > 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 > > > > ... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 14 03:56:59 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 h3EAuxmh017099; Mon, 14 Apr 2003 03:56:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3EAux2x017098; Mon, 14 Apr 2003 03:56:59 -0700 (PDT) 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 h3EAutmh017091 for ; Mon, 14 Apr 2003 03:56:55 -0700 (PDT) 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 h3EAv2vV011189 for ; Mon, 14 Apr 2003 03:57:02 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA04434 for ; Mon, 14 Apr 2003 04:56:53 -0600 (MDT) 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, 14 Apr 2003 10:53: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; Mon, 14 Apr 2003 10:53: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, 14 Apr 2003 10:53:45 Z Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 14 Apr 2003 10:53:40 Z Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3EAr4ft167790; Mon, 14 Apr 2003 06:53:04 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-233-121.mts.ibm.com [9.65.233.121]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3EAr38t059394; Mon, 14 Apr 2003 04:53:03 -0600 Received: from cichlid.raleigh.ibm.com (narten@localhost) by cichlid.raleigh.ibm.com (8.11.6/8.9.3) with ESMTP id h3EApB129272; Mon, 14 Apr 2003 06:51:12 -0400 Message-Id: <200304141051.h3EApB129272@cichlid.raleigh.ibm.com> To: Brian E Carpenter cc: Tim Chown , "ipng@sunroof.eng.sun.com" Subject: Re: Is /32 enough? (was Re: Patrick Faltstrom...) In-Reply-To: Message from brian@hursley.ibm.com of "Wed, 09 Apr 2003 16:42:12 +0200." <3E943144.62389568@hursley.ibm.com> Date: Mon, 14 Apr 2003 06:51:11 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > Regardless, I wouldn't be shocked by a DFZ where a given ISP had > multiple /29s if it grew really big. I do agree that ISPs need to > have a sense that they can get as many of the 35 trillion /48s as > they need. Or a single /28, or something even shorter. See, for isntance, "RIPE 261 Document: IPv6 Address Space Management". Implementation of this algorithm eliminates even the current /29 limitation. http://www.ripe.net/ripe/docs/ipv6-sparse.html 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 Mon Apr 14 05: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 h3EC9Jmh017730; Mon, 14 Apr 2003 05:09:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3EC9JhG017729; Mon, 14 Apr 2003 05:09:19 -0700 (PDT) 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 h3EC9Fmh017722 for ; Mon, 14 Apr 2003 05:09:15 -0700 (PDT) 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 h3EC9MvV021640 for ; Mon, 14 Apr 2003 05:09:22 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id GAA12629 for ; Mon, 14 Apr 2003 06:09:16 -0600 (MDT) 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, 14 Apr 2003 12:09: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, 14 Apr 2003 12:09:15 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, 14 Apr 2003 12:09:15 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, 14 Apr 2003 12:09:15 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.18]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA11758; Mon, 14 Apr 2003 05:08:33 -0700 (PDT) Message-Id: <5.1.0.14.2.20030414080547.04012660@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 14 Apr 2003 08:07:02 -0400 To: Eliot Lear From: Margaret Wasserman Subject: Re: RFC 3513 on Internet Protocol Version 6 (IPv6) Addressing Architecture Cc: rfc-editor@rfc-editor.org, ipng@sunroof.eng.sun.com In-Reply-To: <3E987CD0.4060901@cisco.com> References: <200304112350.h3BNoWk01797@gamma.isi.edu> <200304112350.h3BNoWk01797@gamma.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 01:53 PM 4/12/2003 -0700, Eliot Lear wrote: >This has to be the most ironic timing ever. See the WG minutes as to why. Perhaps. But, it is still great to see this come out as an RFC, since it makes so many important improvements over the previous RFC (removal of the TLA/SLA boundaries, etc.). Thanks, Bob! 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 Apr 14 05:21: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 h3ECLamh018032; Mon, 14 Apr 2003 05:21:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ECLavN018031; Mon, 14 Apr 2003 05:21:36 -0700 (PDT) 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 h3ECLWmh018024 for ; Mon, 14 Apr 2003 05:21:32 -0700 (PDT) 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 h3ECLdvV023307 for ; Mon, 14 Apr 2003 05:21:39 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA23585 for ; Mon, 14 Apr 2003 05:21:31 -0700 (PDT) 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, 14 Apr 2003 12:21: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; Mon, 14 Apr 2003 12:21: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; Mon, 14 Apr 2003 12:21:27 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, 14 Apr 2003 12:21:27 Z Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01888; Mon, 14 Apr 2003 08:18:44 -0400 (EDT) Message-Id: <200304141218.IAA01888@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-07.txt Date: Mon, 14 Apr 2003 08:18:44 -0400 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-07.txt Pages : 9 Date : 2003-4-11 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-07.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-07.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-07.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-4-11134040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-flow-label-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-flow-label-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-11134040.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 Apr 14 05:47: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 h3ECl2mh018634; Mon, 14 Apr 2003 05:47:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ECl2kR018633; Mon, 14 Apr 2003 05:47:02 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h3ECkwmh018626 for ; Mon, 14 Apr 2003 05:46:58 -0700 (PDT) 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 h3ECl2L21372; Mon, 14 Apr 2003 14:47:02 +0200 (MEST) Date: Mon, 14 Apr 2003 14:46:54 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: C000 To: Margaret Wasserman Cc: Brian E Carpenter , Brian Haberman , IPv6 In-Reply-To: "Your message with ID" <5.1.0.14.2.20030410111815.046d8de0@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 > I'm fairly certain that something more complex will be > needed in the intermittently-connected case, but I'm > hoping that we can come up with optional mechanisms for > those type of networks that won't be required for all > implementations. I also understand that there is some > interesting work going on in this area in the nemo WG, > but I haven't check that out yet. Margaret, Just to be clear: I think the reference to Nemo makes sense in a specific case of intermittently-connected networks - the case of an organization having some pieces of their network intermittently connected. In that case the general approach of tunneling back to the organization's main network, and the specific instantiation of this called Nemo, makes sure the addresses in the intermittently connected part remain as stable as the organization's addressing as a whole. But this doesn't necessarily address the case of e.g. a lonely household which is intermittently connected and where the ISP chooses to return a different prefix each time the household connects. Note that I don't think there is any technical issues that need to be solved by the IETF to enable the ISP to hand out the same prefix each time the household connects. See the "tussel in cyperspace" paper for the issues around trying to mandate business level issus using protocols. 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 Apr 14 05:47: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 h3EClVmh018651; Mon, 14 Apr 2003 05:47:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3EClVvX018650; Mon, 14 Apr 2003 05:47:31 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h3EClQmh018643 for ; Mon, 14 Apr 2003 05:47:27 -0700 (PDT) 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 h3EClUL21556; Mon, 14 Apr 2003 14:47:30 +0200 (MEST) Date: Mon, 14 Apr 2003 14:47:22 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Consensus on Site-Local Addressing To: alh-ietf@tndh.net Cc: "'Fred L. Templin'" , "'Michel Py'" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <0f9c01c2ff8f$2d1ac310$ee1a4104@eagleswings> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > See draft-hain-ipv6-sitelocal-00.txt, the research ship example as one > real case where a multi-subnet network intermittently attaches to > different providers. Other vehicle types (airplanes in particular) > already have multiple subnets, and will attach to different providers > over time. Tony, I stated some disagreement with the research ship example being a case where site-locals would help on April 4th. Email included below since I didn't find a http archive for the list which provides URLs for each email. I didn't see a response from you. Erik >----- Begin Included Message -----< Date: Fri, 4 Apr 2003 13:38:28 +0200 (CEST) From: "Erik Nordmark" Subject: RE: site-locals To: alh-ietf@tndh.net Cc: "'Erik Nordmark'" , john.loughney@nokia.com, lear@cisco.com, ipng@sunroof.eng.sun.com > It is not a red herring. Input sent to me for the requirements doc: But this case is exactly the same as what I categorized as #1 in my list - isolating communication local to the site from site renumbering. The only added twist is that site renumber occurs when the site attaches and detaches from the Internet. > Research ships at sea intermittently connect via INMARSAT, or when in > port, the shipboard network is connected to shore via Ethernet. Looking at your resarch ship case a bit more in detail it occurs to me that even using site-locals plus globals while connected doesn't necessarily protect the local communication. The introduction of the global prefix/addresses when the ship is connected might very well trigger different address selection behaviors in the stack or in the applications. Thus it seems like the robustness provided by site-locals only apply to communication established (and addresses selected) before the global prefix is introduced. Later communication is subject to any bugs or poor interaction in the address selection domain - something that is bound to have some corner cases due to its complexity. (Note that this is a property that applies to #1 in my list that I've previously not realized.) While the effect of this probably is less than the effect of renumbering the ships network each time it attaches to the Internet, it still doesn't isolate the ships internal network from being attached to the Internet when site-locals are used as you propose. So if I were to design this ship I'd use neiether renumbering at attachment time nor site-locals. Instead I'd have the research ship get a stable prefixe (a few /64's might suffice) from the organization that runs it which are globally unique and can be used whether the ship is connected or disconnected. This completely isolates the addressing of the ship internals from whether it is connected or disconnected; the only difference is the when disconnected off-ship destinations are unreachable. When it gets connected tunnel(s) need to be established back to the research organization in order for routing to work. Such tunnels could be cobbled up today with some existing tunnel establishment mechanism, and the Nemo WG is working on an IETF standard for such tunnel establishment. So if you want internal stability you have to pay by having less efficient routing - going bidirectionally over the tunnel to "home" - no free lunch. If you believe in Mobile IPv6 route optimization you might also believe that the Nemo work can be extended to provide route optimization to/from correspondent nodes in the Internet at large (by reusing the MIPv6 approach). I personally think the utility of this remains to be proven, but if it is it would help with the routing inefficiencies caused by routing. So once again, this is not a case where I think site-locals help. Erik >----- End Included Message -----< -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 14 06:21: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 h3EDLWmh019062; Mon, 14 Apr 2003 06:21:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3EDLWIN019061; Mon, 14 Apr 2003 06:21:32 -0700 (PDT) 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 h3EDLTmh019054 for ; Mon, 14 Apr 2003 06:21:29 -0700 (PDT) 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 h3EDLacU027606 for ; Mon, 14 Apr 2003 06:21:36 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA06691 for ; Mon, 14 Apr 2003 06:21:25 -0700 (PDT) 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, 14 Apr 2003 13:17: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, 14 Apr 2003 13:14: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; Mon, 14 Apr 2003 13:17:43 Z Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 14 Apr 2003 13:17:41 Z Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3EDEquT075288; Mon, 14 Apr 2003 09:14:52 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3EDEpqc284106; Mon, 14 Apr 2003 07:14:51 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.5/8.12.5) with ESMTP id h3EDAVem021956; Mon, 14 Apr 2003 09:10:31 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h3EDAVbE021951; Mon, 14 Apr 2003 09:10:31 -0400 Message-Id: <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> To: Robert Elz cc: IPv6 Subject: Re: C000 In-Reply-To: Message from kre@munnari.OZ.AU of "Sat, 12 Apr 2003 20:03:12 +0700." <12210.1050152592@munnari.OZ.AU> Date: Mon, 14 Apr 2003 09:10:31 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > Date: Fri, 11 Apr 2003 15:18:23 -0700 > From: David Conrad > Message-ID: <826430D3-6C6B-11D7-BE91-000393DB42B2@nominum.com> > | My impression (correct me if I am wrong) is that site-local imposes > | additional complexity on each and every v6 implementation > No, I think the extra required of site local is trivial. The only real > extra work is to support routing protocols in multi-site nodes, and no-one > is required to support that. This strikes me as a comment from someone who has not been following this topic in detail. There are _many_ in the community who disagree with the above statement. Including folk that do applications for a living and are concerned about the implications on individual applications. Consider, for example, how it only takes "trivial" changes to ensure that an implementation/application that is running in a multi-sited environment (e.g, a home user with SLs configured locally who also has an IPsec tunnel back to their work enviornment, which also uses SLs). Robert Elz writes: > Date: Thu, 10 Apr 2003 09:49:16 +0200 > From: > Message-ID: > I haven't been following the ipv6 wg list (the ipng list) for about 6 > months now (just lack of time), so I'm not really aware what started > this silly discussion. Please spend some time going through the extensive archive on this topic. You might find that the topic is more complex than your above comment indicates. 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 Mon Apr 14 06:29:53 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 h3EDTqmh019295; Mon, 14 Apr 2003 06:29:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3EDTqFH019294; Mon, 14 Apr 2003 06:29:52 -0700 (PDT) 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 h3EDTlmh019275 for ; Mon, 14 Apr 2003 06:29:48 -0700 (PDT) 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 h3EDTscU029232 for ; Mon, 14 Apr 2003 06:29:55 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id GAA25003 for ; Mon, 14 Apr 2003 06:29:49 -0700 (PDT) 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, 14 Apr 2003 13:29: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; Mon, 14 Apr 2003 13:29:48 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, 14 Apr 2003 13:29:48 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, 14 Apr 2003 13:29:47 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3EDEKmi017672; Mon, 14 Apr 2003 06:14:20 -0700 (PDT) Received: from cisco.com (sjc-vpn1-393.cisco.com [10.21.97.137]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA17496; Mon, 14 Apr 2003 06:14:19 -0700 (PDT) Message-Id: <3E9986A8.7080605@cisco.com> Date: Sun, 13 Apr 2003 08:47:52 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Elz CC: David Conrad , Brian E Carpenter , IPv6 Subject: Re: C000 References: <826430D3-6C6B-11D7-BE91-000393DB42B2@nominum.com> <12210.1050152592@munnari.OZ.AU> In-Reply-To: <12210.1050152592@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > Date: Fri, 11 Apr 2003 15:18:23 -0700 > From: David Conrad > Message-ID: <826430D3-6C6B-11D7-BE91-000393DB42B2@nominum.com> > > | My impression (correct me if I am wrong) is that site-local imposes > | additional complexity on each and every v6 implementation > > No, I think the extra required of site local is trivial. The only real > extra work is to support routing protocols in multi-site nodes, and no-one > is required to support that. So long as you go with the rule that you select a source address based on the destination's scope, that all works. If you don't do that we have other problems, such as unacceptably long application time-outs. Christian's rules actually seem pretty sensible in this regard. > > | (or even the full definition of what a "site" is) has not > | yet been fully understood. > > There is no need for anyone to define what > a site is, or not in the way that people keep asking for it to be defined. > What's the full definition of an Autonomous System ? Yet we've been > using that (ignoring the nonsense about "common control" in its earlier > definitions) forever. Each of those is whatever its users want it to > be, just a collection of nodes that have been grouped together, and upon > which some routing constraints are imposed. And in fact, if the ultimate decision is to keep SLs, this is an important point. Sites end at administratively defined boundaries. It's almost like asking where one should put a firewall. The answer is, of course, where one is needed. > > | "Administratively scoped" addresses can > | provide the same functionality without special case code being imbedded > | in every implementation, using filtering that is functionality provided > | by every router I'm aware of. Working code, and all that. > > And are no different in any respect from site locals, except that there's > no way the application can tell that they're "special". > > Refer back to Charlie Perkins latest message (Friday morning, his time) > and you'll see that we agree that getting rid of site locals doesn't > get rid of scoped addresses, nor does it get rid of ambiguous addresses. > What exactly is being gained? > > Don't get me wrong, I'm all in favour of unique PI addresses, if we can > make them work - certainly they'd provide all that SL's as we have them > now provide, and a bit more (they make none of the problems that people > keep claiming SLs have go away, except for the extremely esoteric > "merging sites") - but is there any reason that we can't add that, while > leaving SLs intact as we now have them - and then if they cause SLs to > fall into disuse, they can be deleted. What benefit, then, does IP version 6 provide you? 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 Apr 14 10:28: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 h3EHSpmh022310; Mon, 14 Apr 2003 10:28:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3EHSpq9022308; Mon, 14 Apr 2003 10:28:51 -0700 (PDT) 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 h3EHSlmh022299 for ; Mon, 14 Apr 2003 10:28:47 -0700 (PDT) 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 h3EHSscU000690 for ; Mon, 14 Apr 2003 10:28:54 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA27117 for ; Mon, 14 Apr 2003 11:28:47 -0600 (MDT) 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, 14 Apr 2003 17:25: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; Mon, 14 Apr 2003 17:21: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; Mon, 14 Apr 2003 17:25:06 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, 14 Apr 2003 17:25:05 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 KAA03087; Mon, 14 Apr 2003 10:25:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3EHOwB22517; Mon, 14 Apr 2003 10:24:58 -0700 X-mProtect: <200304141724> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.159, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpddydMYx; Mon, 14 Apr 2003 10:24:56 PDT Message-Id: <4.3.2.7.2.20030414102239.02edcb40@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Apr 2003 10:24:47 -0700 To: Margaret Wasserman From: Bob Hinden Subject: Re: RFC 3513 on Internet Protocol Version 6 (IPv6) Addressing Architecture Cc: Eliot Lear , ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030414080547.04012660@mail.windriver.com> References: <3E987CD0.4060901@cisco.com> <200304112350.h3BNoWk01797@gamma.isi.edu> <200304112350.h3BNoWk01797@gamma.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, It is quite ironic to me as well given current discussions, but it was very good to see it published. Bob At 05:07 AM 4/14/2003, Margaret Wasserman wrote: >At 01:53 PM 4/12/2003 -0700, Eliot Lear wrote: >>This has to be the most ironic timing ever. See the WG minutes as to why. > >Perhaps. But, it is still great to see this come out as an RFC, >since it makes so many important improvements over the previous >RFC (removal of the TLA/SLA boundaries, etc.). > >Thanks, Bob! > >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 Apr 14 11:44: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 h3EIiOmh024002; Mon, 14 Apr 2003 11:44:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3EIiOkV024001; Mon, 14 Apr 2003 11:44:24 -0700 (PDT) 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 h3EIiKmh023994 for ; Mon, 14 Apr 2003 11:44:20 -0700 (PDT) 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 h3EIiRcU026700 for ; Mon, 14 Apr 2003 11:44:27 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA14126 for ; Mon, 14 Apr 2003 12:44:21 -0600 (MDT) 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, 14 Apr 2003 18:44: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; Mon, 14 Apr 2003 18:44: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; Mon, 14 Apr 2003 18:44:20 Z Received: from caluxsmtp.attcanada.com ([209.82.17.130] [209.82.17.130]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 14 Apr 2003 18:44:20 Z Received: from CALVS002.att-intra.com ([10.1.1.46]) by caluxsmtp.attcanada.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id com for ; Mon, 14 Apr 2003 12:47:04 -0600 Received: FROM CALEX006.att-intra.com BY CALVS002.att-intra.com ; Mon Apr 14 12:44:13 2003 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: RFC 3513 on Internet Protocol Version 6 (IPv6) Addressing Architecture Date: Mon, 14 Apr 2003 12:44:11 -0600 Message-Id: <3D7C088D6CCFD31190A5009027D30E910DCF9A71@torex004.att-intra.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 3513 on Internet Protocol Version 6 (IPv6) Addressing Architecture Thread-Index: AcMCtO/yStfV2xRsR6W/0M6d0XOcIgAAJYnA From: "Rasheeduddin, Tariq" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3EIiKmh023995 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anyone know if there any standard or RFC available to define the size of prefix length which will be acceptable by upstream in the absense of TLA/NLA boundaries? For example, if I have a /32 from ARIN directly then other service provider or my upstream should accept it? Tariq From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Margaret Wasserman Sent: Monday, April 14, 2003 8:07 AM To: Eliot Lear Cc: rfc-editor@rfc-editor.org; ipng@sunroof.eng.sun.com Subject: Re: RFC 3513 on Internet Protocol Version 6 (IPv6) Addressing Architecture At 01:53 PM 4/12/2003 -0700, Eliot Lear wrote: >This has to be the most ironic timing ever. See the WG minutes as to why. Perhaps. But, it is still great to see this come out as an RFC, since it makes so many important improvements over the previous RFC (removal of the TLA/SLA boundaries, etc.). Thanks, Bob! 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 Tue Apr 15 02:16: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 h3F9GRmh027296; Tue, 15 Apr 2003 02:16:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3F9GR80027295; Tue, 15 Apr 2003 02:16:27 -0700 (PDT) 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 h3F9GOmh027288 for ; Tue, 15 Apr 2003 02:16:24 -0700 (PDT) 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 h3F9GVvV006907 for ; Tue, 15 Apr 2003 02:16:31 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id CAA05026 for ; Tue, 15 Apr 2003 02:16:25 -0700 (PDT) From: Robert.Peschi@alcatel.be 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, 15 Apr 2003 09:15:11 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, 15 Apr 2003 09:15: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; Tue, 15 Apr 2003 09:15:11 Z Received: from relay1.alcatel.be ([195.207.101.240] [195.207.101.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 09:15:10 Z Received: from bemail01.net.alcatel.be (bemail01.net.alcatel.be [138.203.145.85]) by relay1.alcatel.be (8.12.9/8.12.4) with ESMTP id h3F9DNET013571 for ; Tue, 15 Apr 2003 11:13:24 +0200 (MEST) Sensitivity: Subject: Any reason for configuring several LL@ on a given interface ? To: ipng@sunroof.eng.sun.com Date: Tue, 15 Apr 2003 11:13:22 +0200 Message-Id: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/15/2003 11:13:23 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Just for my clarification. Is there any reasonable usage of configuring *several* Link Local Addresses on a given IPv6 interface ? Thanks, Robert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 15 02:23: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 h3F9N2mh027409; Tue, 15 Apr 2003 02:23:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3F9N22u027408; Tue, 15 Apr 2003 02:23:02 -0700 (PDT) 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 h3F9Mxmh027401 for ; Tue, 15 Apr 2003 02:22:59 -0700 (PDT) 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 h3F9N6vV008258 for ; Tue, 15 Apr 2003 02:23:06 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA02415 for ; Tue, 15 Apr 2003 03:23:00 -0600 (MDT) 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, 15 Apr 2003 09:22: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; Tue, 15 Apr 2003 09:22: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; Tue, 15 Apr 2003 09:22:34 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 09:22:29 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3F9Kj500118; Tue, 15 Apr 2003 16:20:46 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3F9KNW05982; Tue, 15 Apr 2003 16:20:25 +0700 (ICT) From: Robert Elz To: Eliot Lear cc: David Conrad , Brian E Carpenter , IPv6 Subject: Re: C000 In-Reply-To: <3E9986A8.7080605@cisco.com> References: <3E9986A8.7080605@cisco.com> <826430D3-6C6B-11D7-BE91-000393DB42B2@nominum.com> <12210.1050152592@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Apr 2003 16:20:23 +0700 Message-Id: <5980.1050398423@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 13 Apr 2003 08:47:52 -0700 From: Eliot Lear Message-ID: <3E9986A8.7080605@cisco.com> | So long as you go with the rule that you select a source address based | on the destination's scope, that all works. Yes, as much as possible, that's what I do. | And in fact, if the ultimate decision is to keep SLs, this is an | important point. Sites end at administratively defined boundaries. | It's almost like asking where one should put a firewall. The answer is, | of course, where one is needed. Exactly. | What benefit, then, does IP version 6 provide you? Me personally, almost nothing. Or rather, only the intangible benefit of having the internet continue to exist into the future, and be able to sanely support future applications - all of which depends upon available addresses for everyone. But I have no idea what this question has to do with anything. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 15 02:29:42 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 h3F9Tgmh027769; Tue, 15 Apr 2003 02:29:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3F9TgYQ027768; Tue, 15 Apr 2003 02:29:42 -0700 (PDT) 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 h3F9Tbmh027750 for ; Tue, 15 Apr 2003 02:29:37 -0700 (PDT) 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 h3F9TicU020469 for ; Tue, 15 Apr 2003 02:29:44 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA25390 for ; Tue, 15 Apr 2003 03:29:38 -0600 (MDT) 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, 15 Apr 2003 09:28:08 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, 15 Apr 2003 09:28: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; Tue, 15 Apr 2003 09:28:07 Z Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 09:28:07 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.9/8.12.8) with SMTP id h3F9Rrqw021480; Tue, 15 Apr 2003 11:27:53 +0200 (MEST) Received: (from ignatios@newton.cs.uni-bonn.de) by newton.cs.uni-bonn.de (mini_sendmail/1.3.2 21nov2002 nb1 15Feb2003); Tue, 15 Apr 2003 11:26:53 CEST (sender ignatios@newton.cs.uni-bonn.de) Date: Tue, 15 Apr 2003 11:26:53 +0200 From: Ignatios Souvatzis To: Robert.Peschi@alcatel.be Cc: ipng@sunroof.eng.sun.com Subject: Re: Any reason for configuring several LL@ on a given interface ? Message-Id: <20030415092652.GB25074@newton.cs.uni-bonn.de> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="TYecfFk8j8mZq+dy" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --TYecfFk8j8mZq+dy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 15, 2003 at 11:13:22AM +0200, Robert.Peschi@alcatel.be wrote: > Hi, > Just for my clarification. >=20 > Is there any reasonable usage of configuring *several* > Link Local Addresses on a given IPv6 interface ? Some virtual server of some kind? -is --TYecfFk8j8mZq+dy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPpvQWjCn4om+4LhpAQEXWwf/eBSO/41FLY8CPWHojEM24YHkT2HO5BUf XpczV13XS1ewCb5bUoFlTtW1J1eJbMkoXHhaHxb5Dqc9tVt72v860oJKhcJp+Ijz aMxZKSv2ZY8ij3DZNxg7y2y8juuDrR4fxCtR0q/xGU1TRC+vCaBqiMu90GgVHMMD br1l1bPD02Phu8NO1EEZjLuX9ljUDVdwRGz6PMCFy819gL/G49Ewz2lW3WbTwMjJ l5hQOnlslPb8IEIz6gy7bmLBmQsOo7CrSlGjQxN/oJyHrxRhlyimzD4q7qp93K18 p7MEoBajFpcwl4exHHT1Lg5GlQkGf7dPgOdNsjGwxrhzf+sOJrNffg== =JcMT -----END PGP SIGNATURE----- --TYecfFk8j8mZq+dy-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 15 02:32: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 h3F9Wcmh027933; Tue, 15 Apr 2003 02:32:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3F9WcB0027932; Tue, 15 Apr 2003 02:32:38 -0700 (PDT) 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 h3F9WZmh027925 for ; Tue, 15 Apr 2003 02:32:35 -0700 (PDT) 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 h3F9WgcU021524 for ; Tue, 15 Apr 2003 02:32:42 -0700 (PDT) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id CAA15689 for ; Tue, 15 Apr 2003 02:32:35 -0700 (PDT) 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, 15 Apr 2003 09:30: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; Tue, 15 Apr 2003 09:26: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; Tue, 15 Apr 2003 09:30:04 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 09:30:03 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3F9Tm500383; Tue, 15 Apr 2003 16:29:48 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3F9TiW06000; Tue, 15 Apr 2003 16:29:45 +0700 (ICT) From: Robert Elz To: Thomas Narten cc: IPv6 Subject: Re: C000 In-Reply-To: <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> References: <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Apr 2003 16:29:44 +0700 Message-Id: <5998.1050398984@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 14 Apr 2003 09:10:31 -0400 From: Thomas Narten Message-ID: <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> | This strikes me as a comment from someone who has not been following | this topic in detail. Which I have already said is true. | There are _many_ in the community who disagree with the above statement. I'm sure there are. But many people disagreeing does not make a consensus for a change. | Including folk that do applications for a | living and are concerned about the implications on individual | applications. Consider, for example, how it only takes "trivial" | changes to ensure that an implementation/application that is running | in a multi-sited environment (e.g, a home user with SLs configured | locally who also has an IPsec tunnel back to their work enviornment, | which also uses SLs). If you have read my (relatively few) messages over the past week or so, you'll see that I agree that multi-site nodes are an extra complication. We could abolish those if people are willing to give up the few cases where they're actually useful. Doing that would be far less intrusive than abolishing site local completely. But I still don't see what getting rid of SL really accomplishes there. Those same apps need to deal with using LL addresses when nothing else is available, and they need to be able to operate on nodes that have attachments to multiple links where only LL addresses exist. It seems to me that the problems there are just the same as the problems with SLs that you imply. So, are you proposing to do away with LLs, leaving only global addresses, to make the application code writers job easier? If not, then they're going to have to cope anyway, aren't they? Lastly however, my model of SL usage (which I admit hasn't been widely distributed yet, though if you read all my messages, going back a long time, on this topic, you'd probably guess easily enough) has only those apps that actually want to use SL addresses ever actually seeing the things. An app (or its author) that doesn't want to have to deal with SL addresses, will never see them (isolated sites that have only SL addresses excepted, but in that environment, SL's are effectively global and nothing really matters). | Please spend some time going through the extensive archive on this | topic. I am going to do that. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 15 03:46: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 h3FAkhmh028843; Tue, 15 Apr 2003 03:46:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FAkh8F028842; Tue, 15 Apr 2003 03:46:43 -0700 (PDT) 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 h3FAkemh028835 for ; Tue, 15 Apr 2003 03:46:40 -0700 (PDT) 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 h3FAkmvV022089 for ; Tue, 15 Apr 2003 03:46:48 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA21319 for ; Tue, 15 Apr 2003 03:46:42 -0700 (PDT) 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, 15 Apr 2003 10:46:42 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, 15 Apr 2003 10:46: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; Tue, 15 Apr 2003 10:46: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; Tue, 15 Apr 2003 10:46:42 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.14]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id DAA08287; Tue, 15 Apr 2003 03:45:56 -0700 (PDT) Message-Id: <5.1.0.14.2.20030415063621.014d5058@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Apr 2003 06:44:21 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: C000 Cc: Thomas Narten , IPv6 In-Reply-To: <5998.1050398984@munnari.OZ.AU> References: <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.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:29 PM 4/15/2003 +0700, Robert Elz wrote: Hi Robert, >If you have read my (relatively few) messages over the past week or so, >you'll see that I agree that multi-site nodes are an extra complication. >We could abolish those if people are willing to give up the few cases >where they're actually useful. Doing that would be far less intrusive >than abolishing site local completely. The IPv6 WG has considered a few different models for accomplishing this (the only documented ones are the "moderate" and "limited" models that Bob Hinden and I document, respectively). We haven't found any model that realizes most of the benefits of site-local addresses that doesn't cause serious complications for DNS, applications and/or routing. >But I still don't see what getting rid of SL really accomplishes there. > >Those same apps need to deal with using LL addresses when nothing else >is available, and they need to be able to operate on nodes that have >attachments to multiple links where only LL addresses exist. There is little/no belief that LLs will be included in the DNS, and they aren't routed (so we skip any complications for DNS or routing protocols). Some apps just may not work properly in on a multi-link node in a link-local-only environment... but there are many apps that it would not really make sense to run in this sort of environment. >So, are you proposing to do away with LLs, leaving only global addresses, >to make the application code writers job easier? If not, then they're >going to have to cope anyway, aren't they? Applications should be able to treat all addresses that they ever see as global addresses. As you state, this works if you constrain the use of site-locals to a single disconnected site and/or the use of link-locals to a single disconnected link. This was my "limited" proposal. >Lastly however, my model of SL usage (which I admit hasn't been widely >distributed yet, though if you read all my messages, going back a long >time, on this topic, you'd probably guess easily enough) has only those >apps that actually want to use SL addresses ever actually seeing the >things. An app (or its author) that doesn't want to have to deal with >SL addresses, will never see them (isolated sites that have only SL >addresses excepted, but in that environment, SL's are effectively global >and nothing really matters). If you want the IPv6 WG to consider your model, please document it. 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 Tue Apr 15 04:48:53 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 h3FBmqmh029199; Tue, 15 Apr 2003 04:48:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FBmq2e029198; Tue, 15 Apr 2003 04:48:52 -0700 (PDT) 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 h3FBmnmh029191 for ; Tue, 15 Apr 2003 04:48:49 -0700 (PDT) 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 h3FBmvcU012179 for ; Tue, 15 Apr 2003 04:48:57 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA14331 for ; Tue, 15 Apr 2003 04:48:51 -0700 (PDT) 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, 15 Apr 2003 11:48:49 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, 15 Apr 2003 11:48:48 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, 15 Apr 2003 11:48:48 Z Received: from batch10.uni-muenster.de (batch10.uni-muenster.de [128.176.188.65]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 11:48:47 Z Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch10.uni-muenster.de (Postfix) with ESMTP id C6AD024AA; Tue, 15 Apr 2003 13:48:46 +0200 (MES) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id D9673312D9; Tue, 15 Apr 2003 13:48:25 +0200 (CEST) Received: from LEMY.UNI-MUENSTER.DE (LEMY.UNI-MUENSTER.DE [128.176.184.238]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 49E31312BA; Tue, 15 Apr 2003 13:48:25 +0200 (CEST) From: Christian Schild Reply-To: schild@uni-muenster.de Organization: Westfaelische Wilhelms-Universitaet To: "Michel Py" , "Tony Hain" , "Tim Chown" , Subject: Re: FW: Consensus on Site-Local Addressing Date: Tue, 15 Apr 2003 13:48:25 +0200 User-Agent: KMail/1.5 References: <963621801C6D3E4A9CF454A1972AE8F504F76B@server2000.arneill-py.sacramento.ca.us> In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F76B@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304151348.25744.ipng@uni-muenster.de> X-Virus-Scanned: by AMaViS 0.3.12pre7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Am Freitag, 11. April 2003 00:35 schrieb Michel Py: > > Tony Hain wrote: > > Yanking the defined non-PA space will only cause them to pick > > random numbers, or turn the documentation space into a different > > instance of ambiguous space. > > Or use 2002:RFC:1918, best pick after FEC0::/10 Well I think actually this is even worse. Especially if people start to expect the same things from this 'private' address space as from SL. SLs at least had a scope. With 2002:RFC1918 an application or a router has no idea that it should treat this address in a special way, it is just 'global aggregatable' (prefix 001). Imagine a few of the scenarios we draw, e.g. a disconnected network is going online? Using 2002:RFC1918 is much more dangerous than ambiguous SL's flying around. Christian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 15 06:02: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 h3FD2Jmh029696; Tue, 15 Apr 2003 06:02:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FD2J0a029695; Tue, 15 Apr 2003 06:02:19 -0700 (PDT) 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 h3FD2Gmh029688 for ; Tue, 15 Apr 2003 06:02:16 -0700 (PDT) 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 h3FD2OcU023384 for ; Tue, 15 Apr 2003 06:02:24 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id HAA29716 for ; Tue, 15 Apr 2003 07:02:18 -0600 (MDT) 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, 15 Apr 2003 13:02: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; Tue, 15 Apr 2003 12:58: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, 15 Apr 2003 13:02:15 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 13:02:11 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3FD1w506765; Tue, 15 Apr 2003 20:01:59 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3FD1iW07130; Tue, 15 Apr 2003 20:01:45 +0700 (ICT) From: Robert Elz To: Margaret Wasserman cc: Thomas Narten , IPv6 Subject: Re: C000 In-Reply-To: <5.1.0.14.2.20030415063621.014d5058@mail.windriver.com> References: <5.1.0.14.2.20030415063621.014d5058@mail.windriver.com> <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Apr 2003 20:01:44 +0700 Message-Id: <7128.1050411704@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 15 Apr 2003 06:44:21 -0400 From: Margaret Wasserman Message-ID: <5.1.0.14.2.20030415063621.014d5058@mail.windriver.com> | There is little/no belief that LLs will be included in the DNS, I would hope that will be true of SL's as well (in both cases, with the exception of the case where there is only one link/site, where putting LL's/SL's in the (locally-rooted, as there is nothing else) DNS might make sense (depending upon what other name resolution mechanisms are available). But any kind of local use only addresses in the global DNS (whether they be 1918's, LL's, SL's, or some new non-routed PI addressing) makes no sense. | and they aren't routed (so we skip any complications for DNS or routing | protocols). Yes, once again, routing in mult-site nodes is the one extra complexity for SLs. | Some apps just may not work properly in on a multi-link | node in a link-local-only environment... but there are many apps | that it would not really make sense to run in this sort of environment. Why is it reasonable, or even acceptable, to say this about LLs, when the same statement could be made, just as well, about SLs, but there it is, for some reason, unacceptable? | Applications should be able to treat all addresses that they ever see | as global addresses. That's fine, if they don't care what works. For many apps, the difference is immaterial, and that's exactly what they would do. For others though, more care is needed - if an app has two addresses available, and needs to send one as a referral, it had better pick the one that is going to work. I appreciate that app writers would prefer if they were both global addresses, so they can say "I have no way to tell which will work, so all I can do is pick at random, and it is someone else's fault if it doesn't work", whereas with SL addresses (or even a /3 or something prefix for PI global addresses) that is no longer true, and one address will be more likely to work (just from its appearance) than another - so the app writer no longer has an excuse for not doing the extra work. And yes, it is extra work, no question about it. But getting rid of SLs doesn't make that go away, as LLs still exist. | As you state, this works if you constrain the | use of site-locals to a single disconnected site and/or the use of | link-locals to a single disconnected link. I have no intention whatever of adopting any such constraint. That's just the environment when allowing SLs (or LLs) to be treated identically to globals works (including sticking them in the DNS, or anywhere else). | If you want the IPv6 WG to consider your model, please document it. That will happen. But I don't see any reason why there needs to be one approved or blessed model necessarily. Just leave SLs in the architecture (with the properties they currently have), and they will get used. If different people come up with different strategies, that's just fine. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 15 08:23: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 h3FFNXmh000326; Tue, 15 Apr 2003 08:23:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FFNXr3000325; Tue, 15 Apr 2003 08:23:33 -0700 (PDT) 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 h3FFNTmh000318 for ; Tue, 15 Apr 2003 08:23:29 -0700 (PDT) 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 h3FFNbvV008929 for ; Tue, 15 Apr 2003 08:23:37 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA01753 for ; Tue, 15 Apr 2003 09:23:31 -0600 (MDT) 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, 15 Apr 2003 15:23: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; Tue, 15 Apr 2003 15:23: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; Tue, 15 Apr 2003 15:23:30 Z Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 15:23:29 Z Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h3FFNSdp027210 for ; Tue, 15 Apr 2003 17:23:28 +0200 Received: from sceerd01.erd.siemens.at (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h3FFNRZv029298 for ; Tue, 15 Apr 2003 17:23:27 +0200 (MET DST) Received: from siemens.com (atpc7puc.erd.siemens.at [158.226.168.106]) by sceerd01.erd.siemens.at (8.9.3/8.8.5) with ESMTP id RAA05696 for ; Tue, 15 Apr 2003 17:23:26 +0200 Message-Id: <3E9C23FA.8080501@siemens.com> Date: Tue, 15 Apr 2003 17:23:38 +0200 From: Peter Grubmair User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF mailing list post IPv6 Subject: RFC2401 and RFC2473 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have question concerning the neccessity to support IPv6 over IPv6 tunneling (RFC2473) RFC2473 does not state that it it mandatory for an IPv6 host to support it, but RFC2401 (IPSec architecture framework) states it is mandatory to support RFC2401 in IPv6, and lateron it tells me that both tramsport mode and tunnel mode have to be supported by a host. Does this mean that RFC2473 is mandatory in IPv6 ? Thanks in advance, Peter Grubmair PS: If you feel that this question is not appropiate for this mailing-list, please give information about the one which is better suited. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 15 08:33: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 h3FFXvmh000671; Tue, 15 Apr 2003 08:33:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FFXutF000670; Tue, 15 Apr 2003 08:33:56 -0700 (PDT) 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 h3FFXrmh000661 for ; Tue, 15 Apr 2003 08:33:53 -0700 (PDT) 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 h3FFY1cU029011 for ; Tue, 15 Apr 2003 08:34:01 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA02781 for ; Tue, 15 Apr 2003 09:33:59 -0600 (MDT) 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, 15 Apr 2003 15:33: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, 15 Apr 2003 15:30: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; Tue, 15 Apr 2003 15:33:58 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; Tue, 15 Apr 2003 15:33:58 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id h3FFXrxa002804 for ; Tue, 15 Apr 2003 11:33:53 -0400 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id LAA9742437 for ; Tue, 15 Apr 2003 11:33:55 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Tue, 15 Apr 2003 11:33:55 -0400 From: Quality Quorum To: ipng@sunroof.eng.sun.com Subject: Re: Any reason for configuring several LL@ on a given interface ? In-Reply-To: <20030415092652.GB25074@newton.cs.uni-bonn.de> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 15 Apr 2003, Ignatios Souvatzis wrote: > On Tue, Apr 15, 2003 at 11:13:22AM +0200, Robert.Peschi@alcatel.be wrote: > > Hi, > > Just for my clarification. > > > > Is there any reasonable usage of configuring *several* > > Link Local Addresses on a given IPv6 interface ? > > Some virtual server of some kind? what about routers? Can we expect router having multiple attachments to the same link ? > > -is > 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 Apr 15 09:09:35 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 h3FG9Zmh001230; Tue, 15 Apr 2003 09:09:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FG9YW1001229; Tue, 15 Apr 2003 09:09:34 -0700 (PDT) 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 h3FG9Vmh001222 for ; Tue, 15 Apr 2003 09:09:31 -0700 (PDT) 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 h3FG9dcU009333 for ; Tue, 15 Apr 2003 09:09:39 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id KAA03042 for ; Tue, 15 Apr 2003 10:09:30 -0600 (MDT) 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, 15 Apr 2003 16:07:15 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, 15 Apr 2003 16:03: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, 15 Apr 2003 16:07:14 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, 15 Apr 2003 16:07:14 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 JAA21862; Tue, 15 Apr 2003 09:07:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3FG76t06912; Tue, 15 Apr 2003 09:07:06 -0700 X-mProtect: <200304151607> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGpwbO6; Tue, 15 Apr 2003 09:07:04 PDT Message-Id: <3E9C2EA6.9070409@iprg.nokia.com> Date: Tue, 15 Apr 2003 09:09:10 -0700 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: Margaret Wasserman CC: Robert Elz , Thomas Narten , IPv6 Subject: Re: C000 References: <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> <5.1.0.14.2.20030415063621.014d5058@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > At 04:29 PM 4/15/2003 +0700, Robert Elz wrote: >> But I still don't see what getting rid of SL really accomplishes there. >> >> Those same apps need to deal with using LL addresses when nothing else >> is available, and they need to be able to operate on nodes that have >> attachments to multiple links where only LL addresses exist. I think Robert has a point here; no one is talking about doing away with LL's, so apps will still need to deal with them. Perhaps the non-routable aspect of LL's makes things less complicated than for SL's, however? > There is little/no belief that LLs will be included in the DNS, and > they aren't routed (so we skip any complications for DNS or routing > protocols). Some apps just may not work properly in on a multi-link > node in a link-local-only environment... but there are many apps > that it would not really make sense to run in this sort of environment. As to Margaret's point on multi-link nodes in a link-local-only environment, if the multi-link nodes are populated with host routes that associate LL destinations with links (or, if LL destinations can be associated with links through on-demand route discovery) then apps should work fine. Ongoing work in the MANET wg has considered this case; perhaps this is also falls within the realm of the multi-link subnet specification? 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 Tue Apr 15 09:11:48 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 h3FGBmmh001268; Tue, 15 Apr 2003 09:11:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FGBmAd001267; Tue, 15 Apr 2003 09:11:48 -0700 (PDT) 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 h3FGBimh001260 for ; Tue, 15 Apr 2003 09:11:45 -0700 (PDT) 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 h3FGBrcU010204 for ; Tue, 15 Apr 2003 09:11:53 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA20866 for ; Tue, 15 Apr 2003 09:11:47 -0700 (PDT) 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, 15 Apr 2003 16:11: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; Tue, 15 Apr 2003 16:11:46 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, 15 Apr 2003 16:11:46 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 16:11:45 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3FGBe406110; Tue, 15 Apr 2003 19:11:40 +0300 Date: Tue, 15 Apr 2003 19:11:39 +0300 (EEST) From: Pekka Savola To: Quality Quorum cc: ipng@sunroof.eng.sun.com Subject: Re: Any reason for configuring several LL@ on a given interface ? 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, 15 Apr 2003, Quality Quorum wrote: > On Tue, 15 Apr 2003, Ignatios Souvatzis wrote: > > > On Tue, Apr 15, 2003 at 11:13:22AM +0200, Robert.Peschi@alcatel.be wrote: > > > Hi, > > > Just for my clarification. > > > > > > Is there any reasonable usage of configuring *several* > > > Link Local Addresses on a given IPv6 interface ? > > > > Some virtual server of some kind? > > what about routers? Can we expect router having multiple attachments to > the same link ? As a bridge between Secure Neighbor Discovery and Neighbor Discovery, I'd say yes. -- 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 Apr 15 09:15:06 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 h3FGF6mh001456; Tue, 15 Apr 2003 09:15:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FGF5Wh001455; Tue, 15 Apr 2003 09:15:05 -0700 (PDT) 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 h3FGF2mh001445 for ; Tue, 15 Apr 2003 09:15:02 -0700 (PDT) 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 h3FGFAcU011236 for ; Tue, 15 Apr 2003 09:15:10 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA13679 for ; Tue, 15 Apr 2003 10:15:02 -0600 (MDT) 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, 15 Apr 2003 16:15: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; Tue, 15 Apr 2003 16:11: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, 15 Apr 2003 16:14:59 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 16:14:59 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3FGEfn06123; Tue, 15 Apr 2003 19:14:41 +0300 Date: Tue, 15 Apr 2003 19:14:41 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: Margaret Wasserman , Thomas Narten , IPv6 Subject: Re: C000 In-Reply-To: <7128.1050411704@munnari.OZ.AU> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 15 Apr 2003, Robert Elz wrote: > | If you want the IPv6 WG to consider your model, please document it. > > That will happen. But I don't see any reason why there needs to be > one approved or blessed model necessarily. Just leave SLs in > the architecture (with the properties they currently have), and > they will get used. If different people come up with different > strategies, that's just fine. "Just leaving SLs in the architecture" requires a *significant* effort in about all the aspects of routing protocols, apps, etc. Who's going to do that work? Is it worth the while of all the people involved? I'd say NO. That's why IMO the decision was to "deprecate" site locals. Not eliminate them. Indeed, I personally use quite a few features that are in "deprecated" status. But if I happen to shoot myself in the foot by accident, I can't blame anyone else: it has been made crystal clear what the status of SL's should be. -- 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 Apr 15 09:24:10 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 h3FGO9mh002060; Tue, 15 Apr 2003 09:24:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FGO9Vu002059; Tue, 15 Apr 2003 09:24:09 -0700 (PDT) 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 h3FGO6mh002052 for ; Tue, 15 Apr 2003 09:24:06 -0700 (PDT) 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 h3FGOEcU014451 for ; Tue, 15 Apr 2003 09:24:14 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA10935 for ; Tue, 15 Apr 2003 10:24:07 -0600 (MDT) 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, 15 Apr 2003 16:24:03 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, 15 Apr 2003 16:24:02 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, 15 Apr 2003 16:23:54 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 16:23:54 Z Content-class: urn:content-classes:message Subject: RE: C000 Date: Tue, 15 Apr 2003 09:23:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-Id: <963621801C6D3E4A9CF454A1972AE8F5045736@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: C000 thread-index: AcMDPc0RyOrtnvVaToK87GNZyZ8RqQALVdYw From: "Michel Py" To: "Margaret Wasserman" Cc: "IPv6" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3FGO6mh002053 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is little/no belief that LLs will be included in the DNS, This is news to me. How would a small unconnected group of computers work (the "dentist office" as Ole would put 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 Tue Apr 15 09:29: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 h3FGTQmh002260; Tue, 15 Apr 2003 09:29:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FGTQn3002258; Tue, 15 Apr 2003 09:29:26 -0700 (PDT) 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 h3FGTMmh002248 for ; Tue, 15 Apr 2003 09:29:23 -0700 (PDT) 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 h3FGTVvV029410 for ; Tue, 15 Apr 2003 09:29:31 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA03122 for ; Tue, 15 Apr 2003 09:29:25 -0700 (PDT) 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, 15 Apr 2003 16:29: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; Tue, 15 Apr 2003 16:29:25 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, 15 Apr 2003 16:29:24 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; Tue, 15 Apr 2003 16:29:24 Z Received: from IDLEWYLDE.windriver.com ([128.224.4.102]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA15983; Tue, 15 Apr 2003 09:28:49 -0700 (PDT) Message-Id: <5.1.0.14.2.20030415122448.03293650@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Apr 2003 12:27:21 -0400 To: "Michel Py" From: Margaret Wasserman Subject: RE: C000 Cc: "IPv6" In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5045736@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 At 09:23 AM 4/15/2003 -0700, Michel Py wrote: > > There is little/no belief that LLs will be included in the DNS, > >This is news to me. How would a small unconnected group of computers >work (the "dentist office" as Ole would put it)? In general, I expect that the "dentist office" will be connected to the Internet, and that the dentist will receive his IP address prefixes and DNS service from his provider. There may be other cases where people run small disconnected networks (just to talk to their printer, or for their appliance to talk to each other), but I suspect that those networks will use local discovery and name resolutions protocols, rather than DNS. DNS is a bit too complicated to set up for this type of scenario, IMO. 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 Tue Apr 15 09:34:49 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 h3FGYnmh002486; Tue, 15 Apr 2003 09:34:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FGYn8q002485; Tue, 15 Apr 2003 09:34:49 -0700 (PDT) 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 h3FGYjmh002478 for ; Tue, 15 Apr 2003 09:34:45 -0700 (PDT) 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 h3FGYrvV001719 for ; Tue, 15 Apr 2003 09:34:53 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA12113 for ; Tue, 15 Apr 2003 09:34:48 -0700 (PDT) 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, 15 Apr 2003 16:34:47 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, 15 Apr 2003 16:34: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, 15 Apr 2003 16:34:47 Z Received: from devil.pp.htv.fi ([213.243.180.132] [213.243.180.132]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 16:34:46 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 h3FGZm4l029740; Tue, 15 Apr 2003 19:35:48 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h3FGZkpv029739; Tue, 15 Apr 2003 19:35:46 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: C000 From: Mika Liljeberg To: Robert Elz Cc: Thomas Narten , IPv6 In-Reply-To: <5998.1050398984@munnari.OZ.AU> References: <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> <5998.1050398984@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050424546.22241.73.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Apr 2003 19:35:46 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2003-04-15 at 12:29, Robert Elz wrote: > If you have read my (relatively few) messages over the past week or so, > you'll see that I agree that multi-site nodes are an extra complication. > We could abolish those if people are willing to give up the few cases > where they're actually useful. Doing that would be far less intrusive > than abolishing site local completely. Those "few cases" of multi-site nodes will include a few hundred million 3GPP terminals in a not so distant future. Wireless multi-access terminals will be quite common, because people will want to combine wide coverage with fast short range access (not to mention VPN). Non-global reachability is practically a given. Whether those terminals will use local-scope addressing is another matter, but quite likely some of them will. 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 Apr 15 09:40: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 h3FGetmh002772; Tue, 15 Apr 2003 09:40:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FGetZ7002771; Tue, 15 Apr 2003 09:40:55 -0700 (PDT) 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 h3FGepmh002764 for ; Tue, 15 Apr 2003 09:40:51 -0700 (PDT) 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 h3FGexcU020574 for ; Tue, 15 Apr 2003 09:40:59 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA16679 for ; Tue, 15 Apr 2003 09:40:54 -0700 (PDT) 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, 15 Apr 2003 16:40:53 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, 15 Apr 2003 16:40: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, 15 Apr 2003 16:40:53 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 16:40:53 Z Content-class: urn:content-classes:message Subject: RE: C000 Date: Tue, 15 Apr 2003 09:40:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F787@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: C000 thread-index: AcMDbCzAGHHgxohrRCuTOFttz2+vfgAAIg2g From: "Michel Py" To: "Margaret Wasserman" Cc: "IPv6" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3FGeqmh002765 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> Margaret Wasserman wrote: >>> There is little/no belief that LLs will be included in >>> the DNS >> Michel Py wrote: >> This is news to me. How would a small unconnected group of >> computers work (the "dentist office" as Ole would put it)? > In general, I expect that the "dentist office" will be > connected to the Internet Not my dentist and no need for it today. The dentist office uses proprietary software to take care of the business, no Internet required. The dentist typically does not want office assistants to surf pr0n while he's drilling in my mouth. > There may be other cases where people run small disconnected > networks (just to talk to their printer, or for their appliance > to talk to each other), but I suspect that those networks will > use local discovery and name resolutions protocols, rather than > DNS. DNS is a bit too complicated to set up for this type of > scenario, IMO. Explain me how to make Microsoft Active Directory without DNS? This represents the VAST majority of "dentist office" server software installed today; pretty typical, 4 workstations and a "server" which is not much more than a workstation with mirrored IDE disks and a tape drive. 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 Apr 15 09:41: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 h3FGfTmh002827; Tue, 15 Apr 2003 09:41:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FGfSji002826; Tue, 15 Apr 2003 09:41:28 -0700 (PDT) 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 h3FGfLmh002805 for ; Tue, 15 Apr 2003 09:41:21 -0700 (PDT) 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 h3FGfTvV004150 for ; Tue, 15 Apr 2003 09:41:29 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA17032 for ; Tue, 15 Apr 2003 09:41:23 -0700 (PDT) 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, 15 Apr 2003 16:41: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, 15 Apr 2003 16:41: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, 15 Apr 2003 16:41:20 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 16:41:20 Z Content-class: urn:content-classes:message Subject: RE: FW: Consensus on Site-Local Addressing MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 15 Apr 2003 09:41:19 -0700 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F786@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: FW: Consensus on Site-Local Addressing thread-index: AcMDRPsIqDPxJfuOTJCewlXarvp7jgAJxDaw From: "Michel Py" To: , "Tony Hain" , "Tim Chown" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3FGfLmh002806 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, >>> Tony Hain wrote: >>> Yanking the defined non-PA space will only cause them to >>> pick random numbers, or turn the documentation space into >>> a different instance of ambiguous space. >> Michel Py wrote: >> Or use 2002:RFC:1918, best pick after FEC0::/10 > Christian Schild wrote: > Well I think actually this is even worse. Especially if people > start to expect the same things from this 'private' address > space as from SL. Why wouldn't they? After all, it's based on the same RFC1918 addresses. > SLs at least had a scope. With 2002:RFC1918 an application or > a router has no idea that it should treat this address in a > special way, it is just 'global aggregatable' (prefix 001). > Imagine a few of the scenarios we draw, e.g. a disconnected > network is going online? Using 2002:RFC1918 is much more > dangerous than ambiguous SL's flying around. I don't disagree. But do you have a replacement solution and if you don't what can you do to prevent people from using 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 Tue Apr 15 09:49: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 h3FGnKmh003327; Tue, 15 Apr 2003 09:49:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FGnKmg003326; Tue, 15 Apr 2003 09:49:20 -0700 (PDT) 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 h3FGnGmh003319 for ; Tue, 15 Apr 2003 09:49:16 -0700 (PDT) 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 h3FGnOcU023889 for ; Tue, 15 Apr 2003 09:49:24 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA22730 for ; Tue, 15 Apr 2003 09:49:19 -0700 (PDT) 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, 15 Apr 2003 16:49: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, 15 Apr 2003 16:45:32 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, 15 Apr 2003 16:49:18 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 16:49:18 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3FGn8l06364; Tue, 15 Apr 2003 19:49:08 +0300 Date: Tue, 15 Apr 2003 19:49:07 +0300 (EEST) From: Pekka Savola To: Michel Py cc: Margaret Wasserman , IPv6 Subject: RE: C000 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F787@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, 15 Apr 2003, Michel Py wrote: > >>> Margaret Wasserman wrote: There is little/no belief that LLs will be > >>> included in the DNS > > >> Michel Py wrote: > >> This is news to me. How would a small unconnected group of > >> computers work (the "dentist office" as Ole would put it)? > > > In general, I expect that the "dentist office" will be > > connected to the Internet > > Not my dentist and no need for it today. The dentist office uses > proprietary software to take care of the business, no Internet required. > The dentist typically does not want office assistants to surf pr0n while > he's drilling in my mouth. Invent a prefix. -- 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 Apr 15 09:51: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 h3FGpHmh003478; Tue, 15 Apr 2003 09:51:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FGpGh5003477; Tue, 15 Apr 2003 09:51:16 -0700 (PDT) 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 h3FGpCmh003460 for ; Tue, 15 Apr 2003 09:51:12 -0700 (PDT) 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 h3FGpKcU024748 for ; Tue, 15 Apr 2003 09:51:20 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA03505 for ; Tue, 15 Apr 2003 10:51:15 -0600 (MDT) 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, 15 Apr 2003 16:50: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; Tue, 15 Apr 2003 16:50: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, 15 Apr 2003 16:50:57 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 16:50:56 Z Content-class: urn:content-classes:message Subject: RE: C000 Date: Tue, 15 Apr 2003 09:50:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-Id: <963621801C6D3E4A9CF454A1972AE8F5045739@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: C000 thread-index: AcMDbvEkRpgwlM8dT6qWZyYXYrK1owAAAsRw From: "Michel Py" To: "Pekka Savola" Cc: "IPv6" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3FGpCmh003462 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Pekka Savola wrote: > Invent a prefix. You mean, hijack a prefix. No thank you. Been there, done that, been killed by it. There have been enough opinions voiced against doing this. Hijacking is not an option. 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 Apr 15 10:13: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 h3FHDlmh004119; Tue, 15 Apr 2003 10:13:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FHDlrY004118; Tue, 15 Apr 2003 10:13:47 -0700 (PDT) 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 h3FHDhmh004111 for ; Tue, 15 Apr 2003 10:13:43 -0700 (PDT) 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 h3FHDpcU002552 for ; Tue, 15 Apr 2003 10:13:51 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA14244 for ; Tue, 15 Apr 2003 11:13:46 -0600 (MDT) 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, 15 Apr 2003 17:13: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, 15 Apr 2003 17:13:44 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, 15 Apr 2003 17:13:38 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; Tue, 15 Apr 2003 17:13:38 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id h3FHDbgE015118 for ; Tue, 15 Apr 2003 13:13:37 -0400 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id NAA9743594 for ; Tue, 15 Apr 2003 13:13:37 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Tue, 15 Apr 2003 13:13:37 -0400 From: Quality Quorum To: ipng@sunroof.eng.sun.com Subject: Re: Any reason for configuring several LL@ on a given interface ? 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, 15 Apr 2003, Pekka Savola wrote: > > what about routers? Can we expect router having multiple attachments to > > the same link ? > > As a bridge between Secure Neighbor Discovery and Neighbor Discovery, I'd > say yes. What is the reasonable assumption about the number of attachments? Is it 2 (one for discovery and one for secure discovery)? Is it 1000? > 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 Apr 15 10:42: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 h3FHgDmh004508; Tue, 15 Apr 2003 10:42:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FHgDWS004506; Tue, 15 Apr 2003 10:42:13 -0700 (PDT) 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 h3FHg9mh004497 for ; Tue, 15 Apr 2003 10:42:09 -0700 (PDT) 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 h3FHgHcU013658 for ; Tue, 15 Apr 2003 10:42:17 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA07509 for ; Tue, 15 Apr 2003 11:42:12 -0600 (MDT) 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, 15 Apr 2003 17:42: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; Tue, 15 Apr 2003 17:42: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, 15 Apr 2003 17:42:11 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 17:42:10 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h3FHg7vm075332; Tue, 15 Apr 2003 10:42:07 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h3FHg724075331; Tue, 15 Apr 2003 10:42:07 -0700 (PDT) Date: Tue, 15 Apr 2003 10:42:07 -0700 From: Shannon -jj Behrens To: Quality Quorum Cc: ipng@sunroof.eng.sun.com Subject: Re: Any reason for configuring several LL@ on a given interface ? Message-Id: <20030415174207.GA74647@alicia.nttmcl.com> References: <20030415092652.GB25074@newton.cs.uni-bonn.de> 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, Apr 15, 2003 at 11:33:55AM -0400, Quality Quorum wrote: > On Tue, 15 Apr 2003, Ignatios Souvatzis wrote: > > On Tue, Apr 15, 2003 at 11:13:22AM +0200, Robert.Peschi@alcatel.be wrote: > > > Hi, > > > Just for my clarification. > > > > > > Is there any reasonable usage of configuring *several* > > > Link Local Addresses on a given IPv6 interface ? > > > > Some virtual server of some kind? > > what about routers? Can we expect router having multiple attachments to > the same link ? Multiple attachments would = multiple interfaces, correct? The question was about having multiple addresses on one interface. Perhaps I'm missing something. 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 Tue Apr 15 11:20: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 h3FIJxmh004960; Tue, 15 Apr 2003 11:19:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FIJx8h004959; Tue, 15 Apr 2003 11:19:59 -0700 (PDT) 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 h3FIJumh004952 for ; Tue, 15 Apr 2003 11:19:56 -0700 (PDT) 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 h3FIK4vV009584 for ; Tue, 15 Apr 2003 11:20:04 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA25932 for ; Tue, 15 Apr 2003 12:19:58 -0600 (MDT) 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, 15 Apr 2003 18:19: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; Tue, 15 Apr 2003 18:19: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, 15 Apr 2003 18:19:57 Z Received: from TheWorld.com ([199.172.62.104] [199.172.62.104]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 18:19:57 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id h3FIJlYj021120; Tue, 15 Apr 2003 14:19:47 -0400 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id OAA9026794; Tue, 15 Apr 2003 14:19:46 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Tue, 15 Apr 2003 14:19:46 -0400 From: Quality Quorum To: Shannon -jj Behrens cc: ipng@sunroof.eng.sun.com Subject: Re: Any reason for configuring several LL@ on a given interface ? In-Reply-To: <20030415174207.GA74647@alicia.nttmcl.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, 15 Apr 2003, Shannon -jj Behrens wrote: > Multiple attachments would = multiple interfaces, correct? The question was > about having multiple addresses on one interface. Perhaps I'm missing > something. Say, I have a router which is attached to link aaaa:bbbb:cccc:dddd with two interfaces, e.g aaaa:bbbb:cccc:dddd:0000:1111:2222:3333 and aaaa:bbbb:cccc:dddd:4444:5555:6666:7777 I do not think that it makes much sense, however, I am wondering how common this configuration could be ? > > Best Regards, > -jj > 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 Apr 15 11:24: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 h3FIOZmh005068; Tue, 15 Apr 2003 11:24:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FIOZhp005067; Tue, 15 Apr 2003 11:24:35 -0700 (PDT) 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 h3FIOWmh005060 for ; Tue, 15 Apr 2003 11:24:32 -0700 (PDT) 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 h3FIOecU028425 for ; Tue, 15 Apr 2003 11:24:40 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA23332 for ; Tue, 15 Apr 2003 12:24:33 -0600 (MDT) 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, 15 Apr 2003 18: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 for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 18:20: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, 15 Apr 2003 18:24:30 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 18:24:29 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3FIOMc07034; Tue, 15 Apr 2003 21:24:22 +0300 Date: Tue, 15 Apr 2003 21:24:22 +0300 (EEST) From: Pekka Savola To: Michel Py cc: IPv6 Subject: hijacking prefixes for disconnected [RE: C000] In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5045739@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, 15 Apr 2003, Michel Py wrote: > > Pekka Savola wrote: > > Invent a prefix. > > You mean, hijack a prefix. Yes. > No thank you. Been there, done that, been > killed by it. There have been enough opinions voiced against doing this. > Hijacking is not an option. What we'd need, rather than opinions, is documentation and analysis what has actually happened and why. There seem to be three main issues here: 1) set-up - "which prefix should I pick?" - "where must it be configured?" 2) dealing with the introduction of Internet connectivity - sooner or later, the will be *some* network connectivity, even if intermittent. Otherwise, there are zero problems with prefix hijacking. - "getting basic things to work" 3) reconfiguring all the instances where invented prefix was used - "finding out all the cases where it has been configured and changing them" 4) a non-problem: forcing the Internet to accept your hijacked prefix. This is specifically not an issue, as the assumption is that this is not acceptable. Note: in today's world, it seems to me that almost all of these cases are really those of intermittent connectivity. Can even a small "dentist's office" really manage without a model/ISDN dialup, for reading email, or some other minor other business. A particular problem seems to happen in the case where one consultant sets up a network with hijacked prefix and another comes, much later when everything has been forgotten, to change/fix something. HOWEVER, remember that we're talking about "dentist's office" case: a single link which has zero connectivity. No external parties all over the Internet; only a node or two on the local link. -- 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 Apr 15 11:38:18 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 h3FIcImh005587; Tue, 15 Apr 2003 11:38:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FIcIis005586; Tue, 15 Apr 2003 11:38:18 -0700 (PDT) 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 h3FIcEmh005579 for ; Tue, 15 Apr 2003 11:38:14 -0700 (PDT) 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 h3FIcMvV016521 for ; Tue, 15 Apr 2003 11:38:22 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA05849 for ; Tue, 15 Apr 2003 12:38:17 -0600 (MDT) 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, 15 Apr 2003 18:38: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; Tue, 15 Apr 2003 18:38: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; Tue, 15 Apr 2003 18:38:16 Z Received: from fuchsia.home ([203.146.155.26] [203.146.155.26]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 18:38:14 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3FIbWGf011236; Wed, 16 Apr 2003 01:37:33 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3FIarD09212; Wed, 16 Apr 2003 01:36:55 +0700 (ICT) From: Robert Elz To: "Fred L. Templin" cc: Margaret Wasserman , Thomas Narten , IPv6 Subject: Re: C000 In-Reply-To: <3E9C2EA6.9070409@iprg.nokia.com> References: <3E9C2EA6.9070409@iprg.nokia.com> <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> <5.1.0.14.2.20030415063621.014d5058@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Apr 2003 01:36:53 +0700 Message-Id: <9210.1050431813@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 15 Apr 2003 09:09:10 -0700 From: "Fred L. Templin" Message-ID: <3E9C2EA6.9070409@iprg.nokia.com> | Perhaps the non-routable | aspect of LL's makes things less complicated than for SL's, however? Routing is only complicated for SL's at multi-site nodes. Anywhere else, SL routing is identical to global routing - it is just another prefix passed around (and filtered from being passed around at the site boundaries). There's nothing special in that. Multi-site nodes certainly make routing harder. I don't write routing implementations, so I'm not going to attempt to say if it is so much harder that we'd really be better off without them in the architecture. But that's really the only aspect of SL's that routing should be influencing. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 15 11:53: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 h3FIrMmh005966; Tue, 15 Apr 2003 11:53:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FIrM6e005965; Tue, 15 Apr 2003 11:53:22 -0700 (PDT) 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 h3FIrJmh005958 for ; Tue, 15 Apr 2003 11:53:19 -0700 (PDT) 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 h3FIrRvV021029 for ; Tue, 15 Apr 2003 11:53:27 -0700 (PDT) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA05923 for ; Tue, 15 Apr 2003 11:53:22 -0700 (PDT) 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, 15 Apr 2003 18:51: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, 15 Apr 2003 18:51: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; Tue, 15 Apr 2003 18:51:46 Z Received: from fuchsia.home ([203.146.155.26] [203.146.155.26]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 18:51:44 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3FIpHGf018471; Wed, 16 Apr 2003 01:51:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3FIobD09427; Wed, 16 Apr 2003 01:50:38 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: IPv6 Subject: Re: C000 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Apr 2003 01:50:37 +0700 Message-Id: <9425.1050432637@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 15 Apr 2003 19:14:41 +0300 (EEST) From: Pekka Savola Message-ID: | "Just leaving SLs in the architecture" requires a *significant* effort in | about all the aspects of routing protocols, apps, etc. | | Who's going to do that work? Is it worth the while of all the people | involved? | | I'd say NO. Then just don't implement it. We don't need to deprecate it for you to not implement it. If no-one really cares about SLs, then your users won't mind, and everyone will be happy. When we get to advance IPv6 to Internet Standard status, if no-one is using (including obviously if many implementations haven't bothered implementing) SL addresses, then the "significant implementation and successful operational experience" won't have been achieved, and the SL part will have to be removed from the spec in order for it to advance. (I suspect that SL has enough implementations to get to DS without problems). This is all as it should be. On the other hand, if the users really do want the functionality offered by site locals, then if the IETF deprecates them, when the users come to you complaining that your implementation is lacking them, you're just going to say "there's nothing like that in the current IETF standards, so there's nothing I can do about it" and the users will have no real options. On the other hand if the users want the thing, and it is still in the spec, and you just haven't bothered to implement it, because you regard it as unnecessary, too difficult, broken, ... then when the users come to you and ask why, you get to try and convince them you're right. If you do, fine. If not, your implementation gets a reputation as deficient, and fewer users use it. Again, that's all as it should be. So, just have the courage of your convictions. If you think it is useless, unnecessary, or broken, just don't implement it. There's no need to need the rest of the IETF to agree to you (or seem to agree with you) before taking that action. | That's why IMO the decision was to "deprecate" site locals. Not eliminate | them. Indeed, I personally use quite a few features that are in | "deprecated" status. For some things that's entirely reasonable. For example, RIP (v1 anyway) is deprecated, but lots of people still use it. There are two cases where that works - first where the deprecated thing has been in wide use, but has been replaced by something better - (RIP, SNMPv1 ...) - there the implementations all exist, for users who know what they're doing (or don't) there's no real difficulty using the thing. The other case is where only peer nodes under some degree of common control need to do anything at all to use something that's been deprecated. But for something which has not yet been out there long enough, or been implemented all that much, and which requires fairly general implementation to be useful at all, deprecation is equivalent to outlawing. It just gets forgotten - often without any real experience to show that it wouldn't have worked, just fear of too much work on the part of some implementors. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 15 11:55: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 h3FItWmh006015; Tue, 15 Apr 2003 11:55:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FItWbT006014; Tue, 15 Apr 2003 11:55:32 -0700 (PDT) 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 h3FItTmh006007 for ; Tue, 15 Apr 2003 11:55:29 -0700 (PDT) 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 h3FItbcU008885 for ; Tue, 15 Apr 2003 11:55:37 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA15830 for ; Tue, 15 Apr 2003 12:55:31 -0600 (MDT) 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, 15 Apr 2003 18:55: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; Tue, 15 Apr 2003 18:55: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; Tue, 15 Apr 2003 18:55:30 Z Received: from fuchsia.home ([203.146.155.26] [203.146.155.26]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 18:55:28 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3FIt5Gf028520; Wed, 16 Apr 2003 01:55:05 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3FIsED09485; Wed, 16 Apr 2003 01:54:14 +0700 (ICT) From: Robert Elz To: Margaret Wasserman cc: "Michel Py" , "IPv6" Subject: Re: C000 In-Reply-To: <5.1.0.14.2.20030415122448.03293650@mail.windriver.com> References: <5.1.0.14.2.20030415122448.03293650@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Apr 2003 01:54:14 +0700 Message-Id: <9483.1050432854@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 15 Apr 2003 12:27:21 -0400 From: Margaret Wasserman Message-ID: <5.1.0.14.2.20030415122448.03293650@mail.windriver.com> | DNS is a bit too complicated to set up for this type of scenario, IMO. Current implementations are, but they need not be. With dynamic update now starting to be more widely used, there's no reason that a DNS server can't just be turned on and forgotten, with hosts registering themselves in it. After all, if cheap hub/adsl type devices can come complete with DHCP servers, NAT, ... there's no reason that similar devices can't come complete with DNS servers as well. This means that there's no need for different kinds of name resolution in clients depending upon how they happen to be connected in this particular instance. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 15 11:56: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 h3FIuumh006080; Tue, 15 Apr 2003 11:56:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FIuuk0006079; Tue, 15 Apr 2003 11:56:56 -0700 (PDT) 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 h3FIurmh006069 for ; Tue, 15 Apr 2003 11:56:53 -0700 (PDT) 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 h3FIv1vV022065 for ; Tue, 15 Apr 2003 11:57:01 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA15623 for ; Tue, 15 Apr 2003 12:56:55 -0600 (MDT) 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, 15 Apr 2003 18:56: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; Tue, 15 Apr 2003 18:53:08 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, 15 Apr 2003 18:56:54 Z Received: from fuchsia.home ([203.146.155.26] [203.146.155.26]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 18:56:52 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3FIuYGf002898; Wed, 16 Apr 2003 01:56:34 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3FItlD09521; Wed, 16 Apr 2003 01:55:53 +0700 (ICT) From: Robert Elz To: Mika Liljeberg cc: IPv6 Subject: Re: C000 In-Reply-To: <1050424546.22241.73.camel@devil> References: <1050424546.22241.73.camel@devil> <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> <5998.1050398984@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Apr 2003 01:55:47 +0700 Message-Id: <9519.1050432947@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 15 Apr 2003 19:35:46 +0300 From: Mika Liljeberg Message-ID: <1050424546.22241.73.camel@devil> | Those "few cases" of multi-site nodes will include a few hundred million | 3GPP terminals in a not so distant future. You're considering objects I don't know much about, so could you explain why they need to be multi-site? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 15 12:18: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 h3FJIHmh007040; Tue, 15 Apr 2003 12:18:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FJIHBv007039; Tue, 15 Apr 2003 12:18:17 -0700 (PDT) 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 h3FJIDmh007032 for ; Tue, 15 Apr 2003 12:18:13 -0700 (PDT) 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 h3FJILvV029993 for ; Tue, 15 Apr 2003 12:18:21 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA03318 for ; Tue, 15 Apr 2003 13:18:15 -0600 (MDT) 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, 15 Apr 2003 19:18:06 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, 15 Apr 2003 19:18: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, 15 Apr 2003 19:18:06 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 19:18:06 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3FJHtj07342; Tue, 15 Apr 2003 22:17:56 +0300 Date: Tue, 15 Apr 2003 22:17:55 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: IPv6 Subject: IETF spec complexity and site locals [Re: C000] In-Reply-To: <9425.1050432637@munnari.OZ.AU> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 16 Apr 2003, Robert Elz wrote: > Date: Tue, 15 Apr 2003 19:14:41 +0300 (EEST) > From: Pekka Savola > Message-ID: > > | "Just leaving SLs in the architecture" requires a *significant* effort in > | about all the aspects of routing protocols, apps, etc. > | > | Who's going to do that work? Is it worth the while of all the people > | involved? > | > | I'd say NO. > > Then just don't implement it. We don't need to deprecate it for you to > not implement it. > > If no-one really cares about SLs, then your users won't mind, and everyone > will be happy. When we get to advance IPv6 to Internet Standard status, > if no-one is using (including obviously if many implementations haven't > bothered implementing) SL addresses, then the "significant implementation > and successful operational experience" won't have been achieved, and the > SL part will have to be removed from the spec in order for it to advance. > (I suspect that SL has enough implementations to get to DS without problems). > > This is all as it should be. > > On the other hand, if the users really do want the functionality offered > by site locals, then if the IETF deprecates them, when the users come to you > complaining that your implementation is lacking them, you're just going to > say "there's nothing like that in the current IETF standards, so there's > nothing I can do about it" and the users will have no real options. I'm not sure if I agree with your point here btw. The documents which contained SL's still exists: the knowledge to implement them has not been lost. Indeed, deprecating them is the real test for the users and implementers: if they are really needed, the support stays. Otherwise it's removed. And if someone really needs the implementation to have the support, they must convince the vendor they're useful. > On the other hand if the users want the thing, and it is still in the spec, > and you just haven't bothered to implement it, because you regard it as > unnecessary, too difficult, broken, ... then when the users come to you and > ask why, you get to try and convince them you're right. If you do, fine. > If not, your implementation gets a reputation as deficient, and fewer users > use it. > > Again, that's all as it should be. > > So, just have the courage of your convictions. If you think it is useless, > unnecessary, or broken, just don't implement it. There's no need to > need the rest of the IETF to agree to you (or seem to agree with you) before > taking that action. You miss my point completely. I'm worried about the specification complexity. Implementation complexity is important of course, but was not the point here. Why waste the cycles of the vast majority of the IETF folks by specifying the details of SL's everywhere? Of course, you could just handwave them away everywhere ("use with site-local addresses is out of scope"), but that would not seem to be responsible behaviour at all. We need to ensure no significant amount of *IETF* work is wasted on making site-locals "work". The easiest way to do that seems to be "deprecating" them. -- 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 Apr 15 13:03: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 h3FK3Wmh007425; Tue, 15 Apr 2003 13:03:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FK3W5L007424; Tue, 15 Apr 2003 13:03:32 -0700 (PDT) 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 h3FK3Smh007417 for ; Tue, 15 Apr 2003 13:03:28 -0700 (PDT) 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 h3FK3avV013079 for ; Tue, 15 Apr 2003 13:03:36 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA28469 for ; Tue, 15 Apr 2003 14:03:31 -0600 (MDT) 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, 15 Apr 2003 20:03: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; Tue, 15 Apr 2003 20:03: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, 15 Apr 2003 20:03:30 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, 15 Apr 2003 20:03:28 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 UAA19179; Tue, 15 Apr 2003 20:55:54 +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 UAA10242; Tue, 15 Apr 2003 20:55:54 +0100 (BST) Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3FJtsn03561; Tue, 15 Apr 2003 20:55:54 +0100 Date: Tue, 15 Apr 2003 20:55:54 +0100 From: Mike Saywell To: Pekka Savola Cc: Robert Elz , IPv6 Subject: Re: IETF spec complexity and site locals [Re: C000] Message-Id: <20030415195554.GX2303@ecs.soton.ac.uk> References: <9425.1050432637@munnari.OZ.AU> 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, Apr 15, 2003 at 10:17:55PM +0300, Pekka Savola wrote: > I'm worried about the specification complexity. Implementation complexity > is important of course, but was not the point here. > > Why waste the cycles of the vast majority of the IETF folks by specifying > the details of SL's everywhere? Of course, you could just handwave them > away everywhere ("use with site-local addresses is out of scope"), but > that would not seem to be responsible behaviour at all. > > We need to ensure no significant amount of *IETF* work is wasted on making > site-locals "work". The easiest way to do that seems to be "deprecating" > them. > It seems to me that most of the people who want to keep site-locals only require the address space and not any special handling of scope. Whilst the people that want to get rid of them are mainly concerned about the problems scoping implies. So can we not simply deprecate the scoping side of things but leave the allocation intact? Perhaps renaming it as being reserved for experimental and disconnected networks only... Yes there are issues when sites merge etc, but they *can* use global addresses, if they've chosen not too then they're making life much harder for themselves and they deserve the pain ;) Ad-hoc networks and other minority cases such as community networks may not have the luxury of obtaining the necessary global address space, so they need some prefix to communicate, but nothing more. 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 Apr 15 13:05: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 h3FK51mh007448; Tue, 15 Apr 2003 13:05:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FK51Nh007447; Tue, 15 Apr 2003 13:05:01 -0700 (PDT) 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 h3FK4vmh007437 for ; Tue, 15 Apr 2003 13:04:57 -0700 (PDT) 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 h3FK55vV013369 for ; Tue, 15 Apr 2003 13:05:05 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA28235 for ; Tue, 15 Apr 2003 14:04:58 -0600 (MDT) 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, 15 Apr 2003 20:04:49 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, 15 Apr 2003 20:04: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; Tue, 15 Apr 2003 20:04:49 Z Received: from fuchsia.home ([203.146.155.28] [203.146.155.28]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 20:04:47 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3FK4JGf004291; Wed, 16 Apr 2003 03:04:22 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3FK2wD10874; Wed, 16 Apr 2003 03:02:58 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: IPv6 Subject: Re: hijacking prefixes for disconnected [RE: C000] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Apr 2003 03:02:58 +0700 Message-Id: <10872.1050436978@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 15 Apr 2003 21:24:22 +0300 (EEST) From: Pekka Savola Message-ID: | 3) reconfiguring all the instances where invented prefix was used | - "finding out all the cases where it has been configured and | changing them" But this is what doesn't happen - and it is exactly what sites want to avoid - they want addressing that doesn't alter, at least for internal uses. So, even assuming it is trivially easy, they won't change them. | Note: in today's world, it seems to me that almost all of these cases are | really those of intermittent connectivity. Of changing connectivity, whether intermittent, or not. Right now (as of this instant I mean) my connections rarely last much more than an hour or so (then restart fairly quickly). Every time I connect I get a different address. You can be dead sure that that address has no bearing at all on the addressing I am using on my internal net. We might like to pretend that we can stop providers from doing that, but we cannot. | HOWEVER, remember that we're talking about "dentist's office" case: a | single link which has zero connectivity. No external parties all over the | Internet; only a node or two on the local link. No. That's one scenario. Another is a link which is normally connected, but where the router just happens to be down (maybe the router is a linux system and the thing has crashed...). There, there's nothing to hand out prefixes to other nodes, so all they're going to get are LL addresses. There's too much "I know how the net should be used, anyone who dreams of using it differently than I think should be done is brain dead" type stuff going on here. Learn to accept that people will use things in all kinds of ways that none of us can imagine right now. In another message pekkas@netcore.fi said: | You miss my point completely. | I'm worried about the specification complexity. Implementation complexity | is important of course, but was not the point here. Specification complexity of SL is almost zero. It has been that way for ages. And implementations were using it regardless. What's more the degree of specification was just about perfect for this. The aim and basic rules were there, and that was it. Enough to work out what needed to be accomplished. With that, implementors can go and try different ways of actually using the things, documenting the results along the way for the benefit of others. | We need to ensure no significant amount of *IETF* work is wasted on making | site-locals "work". The easiest way to do that seems to be "deprecating" | them. There's been far more IETF work spent (it seems to me) in the past few months on the attempt to deprecate site locals than was ever spent on their specification, or on making them work. This hardly seems to have been *easy*. All that was needed was to do nothing, and see what happens. That's still all that is needed. kre ps: with this, enough from me for a day (or more perhaps). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 15 13:56: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 h3FKuZmh008340; Tue, 15 Apr 2003 13:56:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FKuZba008339; Tue, 15 Apr 2003 13:56:35 -0700 (PDT) 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 h3FKuWmh008332 for ; Tue, 15 Apr 2003 13:56:32 -0700 (PDT) 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 h3FKuevV028452 for ; Tue, 15 Apr 2003 13:56:40 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA21694 for ; Tue, 15 Apr 2003 14:56:33 -0600 (MDT) 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, 15 Apr 2003 20:56:30 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, 15 Apr 2003 20:52: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, 15 Apr 2003 20:56:30 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; Tue, 15 Apr 2003 20:56:30 Z Received: from IDLEWYLDE.windriver.com ([128.224.4.102]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA24667; Tue, 15 Apr 2003 13:55:04 -0700 (PDT) Message-Id: <5.1.0.14.2.20030415164902.0467f6f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Apr 2003 16:51:52 -0400 To: Mike Saywell From: Margaret Wasserman Subject: Re: IETF spec complexity and site locals [Re: C000] Cc: Pekka Savola , Robert Elz , IPv6 In-Reply-To: <20030415195554.GX2303@ecs.soton.ac.uk> References: <9425.1050432637@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:55 PM 4/15/2003 +0100, Mike Saywell wrote: >It seems to me that most of the people who want to keep site-locals >only require the address space and not any special handling of scope. >Whilst the people that want to get rid of them are mainly concerned >about the problems scoping implies. > >So can we not simply deprecate the scoping side of things but leave the >allocation intact? Perhaps renaming it as being reserved for experimental >and disconnected networks only... > >Yes there are issues when sites merge etc, but they *can* use global >addresses, if they've chosen not too then they're making life much >harder for themselves and they deserve the pain ;) > >Ad-hoc networks and other minority cases such as community networks may >not have the luxury of obtaining the necessary global address space, >so they need some prefix to communicate, but nothing more. It would be hard for me to disagree with you, because this is exactly what I proposed in my "limited" model... However, people have convinced me that there are already implementations that include special handling for the FECO::/10 prefix, based on the assumption that it is "scoped" (as defined in the scoped addressing architecture). What you really want for disconnected sites is a local prefix that will be treated exactly like a global prefix (since it is global to the attached network), so there may be a conflict between implementations that treat site-local specially and the needs of a disconnected network. 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 Tue Apr 15 13:56: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 h3FKuqmh008350; Tue, 15 Apr 2003 13:56:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FKuq89008349; Tue, 15 Apr 2003 13:56:52 -0700 (PDT) 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 h3FKukmh008342 for ; Tue, 15 Apr 2003 13:56:46 -0700 (PDT) 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 h3FKusvV028527 for ; Tue, 15 Apr 2003 13:56:54 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA20310 for ; Tue, 15 Apr 2003 13:56:47 -0700 (PDT) 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, 15 Apr 2003 20:56: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, 15 Apr 2003 20:56: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, 15 Apr 2003 20:56:44 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; Tue, 15 Apr 2003 20:56:44 Z Received: from IDLEWYLDE.windriver.com ([128.224.4.102]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA24655; Tue, 15 Apr 2003 13:55:01 -0700 (PDT) Message-Id: <5.1.0.14.2.20030415164645.042e9268@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Apr 2003 16:48:59 -0400 To: Mike Saywell From: Margaret Wasserman Subject: Re: IETF spec complexity and site locals [Re: C000] Cc: Pekka Savola , Robert Elz , IPv6 In-Reply-To: <20030415195554.GX2303@ecs.soton.ac.uk> References: <9425.1050432637@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:55 PM 4/15/2003 +0100, Mike Saywell wrote: >It seems to me that most of the people who want to keep site-locals >only require the address space and not any special handling of scope. >Whilst the people that want to get rid of them are mainly concerned >about the problems scoping implies. > >So can we not simply deprecate the scoping side of things but leave the >allocation intact? Perhaps renaming it as being reserved for experimental >and disconnected networks only... I would be concerned about doing this because some implementation already have special handling for the "scoped" nature of site-locals. For disconnected networks, you ideally want to use prefixes that will be treated exactly like globals (they are global to the attached network), so you wouldn't want to use a prefix for which there may already be special handling due to its scoped nature, would you? >Ad-hoc networks and other minority cases such as community networks may >not have the luxury of obtaining the necessary global address space, >so they need some prefix to communicate, but nothing more. I agree. >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 15 15:30:42 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 h3FMUgmh009720; Tue, 15 Apr 2003 15:30:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FMUgI5009719; Tue, 15 Apr 2003 15:30:42 -0700 (PDT) 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 h3FMUdmh009712 for ; Tue, 15 Apr 2003 15:30:39 -0700 (PDT) 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 h3FMUlcU017687 for ; Tue, 15 Apr 2003 15:30:47 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA11554 for ; Tue, 15 Apr 2003 15:30:41 -0700 (PDT) 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, 15 Apr 2003 22:29: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; Tue, 15 Apr 2003 22:29: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; Tue, 15 Apr 2003 22:29:19 Z Received: from devil.pp.htv.fi ([213.243.180.132] [213.243.180.132]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 22:29:18 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 h3FMUk4l031272; Wed, 16 Apr 2003 01:30:46 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h3FMUif9031271; Wed, 16 Apr 2003 01:30:45 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: C000 From: Mika Liljeberg To: Robert Elz Cc: IPv6 In-Reply-To: <9519.1050432947@munnari.OZ.AU> References: <1050424546.22241.73.camel@devil> <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> <5998.1050398984@munnari.OZ.AU> <9519.1050432947@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050445842.22244.576.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Apr 2003 01:30:44 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2003-04-15 at 21:55, Robert Elz wrote: > | Those "few cases" of multi-site nodes will include a few hundred million > | 3GPP terminals in a not so distant future. > > You're considering objects I don't know much about, so could you explain > why they need to be multi-site? Well, the why of it is a good question, and I'm probably not the best person to answer it, but I'll give it a go anyway. The roots of this thinking are deep in the telecoms world. Basically, 3GPP views packet data as a bearer service that carries packets between two access points. For simplicity, you could think of the bearer service as a tunnel between the mobile terminal and some remote gateway, which provides access to a service or to a network. Naturally, operators and service providers want to charge differently for different services, so a clear separation is required. The terminal gets an IP address from the gateway as part of the tunnel setup procedure (called PDP context activation). This means that, as soon as the terminal activates more than one packet data service, it automatically becomes multi-site (assuming the gateways for the services belong to different sites). The mobile might also have access to circuit switched data services. Add to that VPN or a short range radio like Bluetooth or 802.11 and you have yet more opportunities to become multi-site. Mobile devices are simply primed for this, so I wouldn't assume multi-site nodes will be rare. 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 Apr 15 16:01:06 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 h3FN16mh010756; Tue, 15 Apr 2003 16:01:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3FN16L9010755; Tue, 15 Apr 2003 16:01:06 -0700 (PDT) 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 h3FN12mh010748 for ; Tue, 15 Apr 2003 16:01:03 -0700 (PDT) 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 h3FN1BvV011326 for ; Tue, 15 Apr 2003 16:01:11 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA27150 for ; Tue, 15 Apr 2003 16:01:05 -0700 (PDT) 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, 15 Apr 2003 23:00: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; Tue, 15 Apr 2003 23:00:48 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, 15 Apr 2003 23:00:47 Z Received: from oak1a.cats.ohiou.edu ([132.235.8.44] [132.235.8.44]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 15 Apr 2003 23:00:47 Z Received: from hkruse.csm.ohiou.edu (hkruse.csm.ohiou.edu [132.235.75.144]) (authenticated bits=0) by oak1a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id h3FLHgWV1041082 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 15 Apr 2003 17:17:43 -0400 (EDT) Date: Tue, 15 Apr 2003 17:18:14 -0400 From: Hans Kruse To: IPv6 Subject: Re: IETF spec complexity and site locals [Re: C000] Message-Id: <1905071177.1050427094@hkruse.csm.ohiou.edu> In-Reply-To: <20030415195554.GX2303@ecs.soton.ac.uk> References: <20030415195554.GX2303@ecs.soton.ac.uk> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yup, that would seem to make sense. Hijacked prefixes create problems for the _rest of the network_ when the admin of the disconnected site does the wrong thing (connect without proper/complete renumbering, filtering, etc). So, we need a recognizable prefix for non-provider based addresses so the rest of the net can protect itself. If the address space is identified, then scoped link locals could go to experimental (forgive me if that is procedurally not possible) or be deprecated, and the WG can start work on solving some of the issues raised (globally unique PI space, intermittent connections, etc). --On Tuesday, April 15, 2003 20:55 +0100 Mike Saywell wrote: > It seems to me that most of the people who want to keep site-locals > only require the address space and not any special handling of scope. > Whilst the people that want to get rid of them are mainly concerned > about the problems scoping implies. > > So can we not simply deprecate the scoping side of things but leave the > allocation intact? Perhaps renaming it as being reserved for experimental > and disconnected networks only... > > Yes there are issues when sites merge etc, but they *can* use global > addresses, if they've chosen not too then they're making life much > harder for themselves and they deserve the pain ;) > > Ad-hoc networks and other minority cases such as community networks may > not have the luxury of obtaining the necessary global address space, > so they need some prefix to communicate, but nothing more. Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 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 Apr 15 23:11: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 h3G6BMmh013463; Tue, 15 Apr 2003 23:11:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3G6BMjY013462; Tue, 15 Apr 2003 23:11:22 -0700 (PDT) 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 h3G6BJmh013455 for ; Tue, 15 Apr 2003 23:11:19 -0700 (PDT) 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 h3G6BRcU003768 for ; Tue, 15 Apr 2003 23:11:27 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id AAA23358 for ; Wed, 16 Apr 2003 00:11:20 -0600 (MDT) 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, 16 Apr 2003 06:11: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; Wed, 16 Apr 2003 06:11: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; Wed, 16 Apr 2003 06:11:18 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, 16 Apr 2003 06:11:18 Z Received: (cpmta 26207 invoked from network); 15 Apr 2003 23:11:16 -0700 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.135) with SMTP; 15 Apr 2003 23:11:16 -0700 X-Sent: 16 Apr 2003 06:11:16 GMT Message-Id: <00bb01c303de$f7f88bf0$7a051eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: "IPv6" Subject: Site Locals - a silly suggestion Date: Wed, 16 Apr 2003 09:11:04 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B8_01C303F8.1BA49710" 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_00B8_01C303F8.1BA49710 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable This may seem strange, but why are we killing ourselves to add site = locals to IPv6? (No need to in-line an answer it is rhetorical - read = on) Mostly because people want to keep the RFC 1918 addresses in their = networks for whatever reasons that they feel that they are needed (real = or imagined). As the addresses ::10:x:x:x (and the rest of the RFC 1918 addresses) = will have to keep their existing "local only: special status, lets just = make this official (i.e. not add another IPv6 /10 space) and write it = into the specification. This way we don't add work and we don't kill what is installed in so = many companies already. These are the companies (or people) that will = insist on using an 4 to 6 "NAT" on their router based on a Global IPv6 = address that will be provided by their ISP and their own (existing or = new) RFC 1918 addresses inside their private network. After all we still need to account for the RFC 1918 addresses in what = ever we propose as the standard, and this way we meet what Mike Saywell = said in "Re: IETF spec complexity and site locals [Re: C000]" > It seems to me that most of the people who want to keep site-locals > only require the address space and not any special handling of scope. > Whilst the people that want to get rid of them are mainly concerned > about the problems scoping implies. ------=_NextPart_000_00B8_01C303F8.1BA49710 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
This may seem strange, but why are we = killing=20 ourselves to add site locals to IPv6? (No need to in-line an answer it = is=20 rhetorical - read on)
 
Mostly because people want to keep the = RFC 1918=20 addresses in their networks for whatever reasons that they feel that = they are=20 needed (real or imagined).
 
As the addresses ::10:x:x:x (and the = rest of the=20 RFC 1918 addresses) will have to keep their existing "local only: = special=20 status, lets just make this official (i.e. not add another IPv6 /10 = space) and=20 write it into the specification.
 
This way we don't add work and we don't = kill what=20 is installed in so many companies already. These are the companies  = (or=20 people) that will insist on using an 4 to 6 "NAT" on their router based = on a=20 Global IPv6 address that will be provided by their ISP and their own = (existing=20 or new) RFC 1918 addresses inside their private network.
 
After all we still need to account for = the RFC 1918=20 addresses in what ever we propose as the standard, and this way we meet = what=20 Mike Saywell said in "Re: IETF spec complexity and site locals [Re:=20 C000]"
 
 
> It seems to me that most of the = people who=20 want to keep site-locals
> only require the address space and not = any=20 special handling of scope.
> Whilst the people that want to get = rid of=20 them are mainly concerned
> about the problems scoping=20 implies.
------=_NextPart_000_00B8_01C303F8.1BA49710-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 15 23:30: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 h3G6Uumh013808; Tue, 15 Apr 2003 23:30:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3G6Utlv013807; Tue, 15 Apr 2003 23:30:55 -0700 (PDT) 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 h3G6Uqmh013800 for ; Tue, 15 Apr 2003 23:30:52 -0700 (PDT) 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 h3G6V1cU007485 for ; Tue, 15 Apr 2003 23:31:01 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id AAA00460 for ; Wed, 16 Apr 2003 00:30:52 -0600 (MDT) 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, 16 Apr 2003 06:30:49 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, 16 Apr 2003 06:30: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; Wed, 16 Apr 2003 06:30:49 Z Received: from hemant.gsslco.co.in (hemant.gsslco.co.in [202.54.16.83]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 06:30:48 Z Received: from agni.bombay.gsslco.co.in (agni.bombay..gsslco.co.in [10.1.100.6]) by hemant.gsslco.co.in (8.11.6/8.11.6) with ESMTP id h3G6eu702130 for ; Wed, 16 Apr 2003 12:10:57 +0530 Received: (from root@localhost) by agni.bombay.gsslco.co.in (8.11.2/8.11.2) id h3G6XJ214048 for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 12:03:19 +0530 Received: from gauri ([10.1.1.115]) by agni.bombay.gsslco.co.in (8.11.2/8.11.2) with SMTP id h3G6XIk14021 for ; Wed, 16 Apr 2003 12:03:18 +0530 Message-Id: <002e01c303e2$b28c3090$7301010a@bombay.gsslco.co.in> From: "Partha, K V B" To: Subject: The 69/8 problem Date: Wed, 16 Apr 2003 12:07:48 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C30410.CC3D40A0" 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 X-scanner: scanned by Inflex 1.0.12.3 - (http://pldaniels.com/inflex/) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C30410.CC3D40A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like to state an observation. Filtering policies in networks = connected to the Internet to prevent DoS attacks might lead to a = potential Denial of Service in the future. One example of this is the = 69.0.0.0/8 address space which was once denied access by many networks = to prevent DoS attacks (please refer to = http://puck.nether.net/~jared/papers/69-paper.html). The implications on Internet2, as we introduce through IPv6 new and = larger reserved address spaces could be fatal and may have to be = considered before widespread deployment of IPng. --- Partha. ------=_NextPart_000_002B_01C30410.CC3D40A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I would like to state an observation. Filtering policies in = networks=20 connected to the Internet to prevent DoS attacks might lead to a = potential=20 Denial of Service in the future. One example of this is the 69.0.0.0/8 = address=20 space which was once denied access by many networks to prevent DoS = attacks=20 (please refer to http://puck.n= ether.net/~jared/papers/69-paper.html).

The implications on Internet2, as we introduce = through IPv6=20 new and larger reserved address spaces could be fatal and may have to be = considered before widespread deployment of=20 IPng.

---
Partha.
------=_NextPart_000_002B_01C30410.CC3D40A0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 16 01:00: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 h3G80amh014432; Wed, 16 Apr 2003 01:00:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3G80aID014431; Wed, 16 Apr 2003 01:00:36 -0700 (PDT) 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 h3G80Wmh014424 for ; Wed, 16 Apr 2003 01:00:32 -0700 (PDT) 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 h3G80evV001106 for ; Wed, 16 Apr 2003 01:00:40 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id CAA02804 for ; Wed, 16 Apr 2003 02:00:06 -0600 (MDT) From: Robert.Peschi@alcatel.be 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, 16 Apr 2003 08:00: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, 16 Apr 2003 08:00: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, 16 Apr 2003 08:00:04 Z Received: from relay1.alcatel.be ([195.207.101.240] [195.207.101.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 08:00:03 Z Received: from bemail01.net.alcatel.be (bemail01.net.alcatel.be [138.203.145.85]) by relay1.alcatel.be (8.12.9/8.12.4) with ESMTP id h3G7xlET008969; Wed, 16 Apr 2003 09:59:52 +0200 (MEST) Sensitivity: Subject: Re: Any reason for configuring several LL@ on a given interface ? To: jj@nttmcl.com, pekkas@netcore.fi Cc: ipng@sunroof.eng.sun.com Date: Wed, 16 Apr 2003 09:59:46 +0200 Message-Id: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/16/2003 09:59:52 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 15 Apr 2003, Shannon -jj Behrens wrote: > Multiple attachments would = multiple interfaces, correct? The question was > about having multiple addresses on one interface. Perhaps I'm missing > something. Actually, I have no doubt about the relevance for several global addresses per IPv6 interface (e.g. for site renumbering with address finite lifetime). What I was wondering is the relevance for having several FE80:: on the same IPv6 interface (say on a POS fibre). On Tue, 15 Apr 2003, Pekka Savola wrote: > > what about routers? Can we expect router having multiple attachments to > > the same link ? > > As a bridge between Secure Neighbor Discovery and Neighbor Discovery, I'd > say yes. I'm not so familiar with Secure Neighbor Discovery. Would you mean here that having several *LL@* on an interface is usefull/needed for secure ND ? Any pointer maybe ? Thanks, Kind regards Robert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 16 02:55: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 h3G9tTmh015504; Wed, 16 Apr 2003 02:55:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3G9tTiZ015503; Wed, 16 Apr 2003 02:55:29 -0700 (PDT) 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 h3G9tOmh015496 for ; Wed, 16 Apr 2003 02:55:25 -0700 (PDT) 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 h3G9tXvV019717 for ; Wed, 16 Apr 2003 02:55:33 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id CAA09710 for ; Wed, 16 Apr 2003 02:55:28 -0700 (PDT) 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, 16 Apr 2003 09:55:27 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, 16 Apr 2003 09:51: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; Wed, 16 Apr 2003 09:55:27 Z Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 09:55:27 Z Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 16 Apr 2003 11:55:18 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3G9rRih000445; Wed, 16 Apr 2003 11:53:27 +0200 (MET DST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA25442; Wed, 16 Apr 2003 10:55:15 +0100 (BST) Date: Wed, 16 Apr 2003 10:55:15 +0100 From: Derek Fawcus To: Pekka Savola Cc: Quality Quorum , ipng@sunroof.eng.sun.com Subject: Re: Any reason for configuring several LL@ on a given interface ? Message-Id: <20030416105515.A16173@edinburgh.cisco.com> Mail-Followup-To: Pekka Savola , Quality Quorum , ipng@sunroof.eng.sun.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from pekkas@netcore.fi on Tue, Apr 15, 2003 at 07:11:39PM +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Apr 15, 2003 at 07:11:39PM +0300, Pekka Savola wrote: > On Tue, 15 Apr 2003, Quality Quorum wrote: > > On Tue, 15 Apr 2003, Ignatios Souvatzis wrote: > > > > > On Tue, Apr 15, 2003 at 11:13:22AM +0200, Robert.Peschi@alcatel.be wrote: > > > > Hi, > > > > Just for my clarification. > > > > > > > > Is there any reasonable usage of configuring *several* > > > > Link Local Addresses on a given IPv6 interface ? > > > > > > Some virtual server of some kind? > > > > what about routers? Can we expect router having multiple attachments to > > the same link ? > > As a bridge between Secure Neighbor Discovery and Neighbor Discovery, I'd > say yes. So how's that going to work (maybe I should catch up on my send reading)? Given that redirects require routers to have one LL address on a link in order to work. A router with multiple LL addresses on a given link would have to look like multiple 'logical' routers. DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 16 03:15: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 h3GAFdmh015780; Wed, 16 Apr 2003 03:15:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3GAFcsM015779; Wed, 16 Apr 2003 03:15:38 -0700 (PDT) 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 h3GAFYmh015772 for ; Wed, 16 Apr 2003 03:15:34 -0700 (PDT) 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 h3GAFgvV023557 for ; Wed, 16 Apr 2003 03:15:42 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id EAA23019 for ; Wed, 16 Apr 2003 04:15:32 -0600 (MDT) 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, 16 Apr 2003 10:15: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; Wed, 16 Apr 2003 10:15: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; Wed, 16 Apr 2003 10:15:30 Z Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 10:15:10 Z Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 16 Apr 2003 12:14:53 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3GAD4L7004485; Wed, 16 Apr 2003 12:13:05 +0200 (MET DST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA26324; Wed, 16 Apr 2003 11:14:53 +0100 (BST) Date: Wed, 16 Apr 2003 11:14:53 +0100 From: Derek Fawcus To: Mike Saywell Cc: IPv6 Subject: Re: IETF spec complexity and site locals [Re: C000] Message-Id: <20030416111453.B16173@edinburgh.cisco.com> Mail-Followup-To: Mike Saywell , IPv6 References: <9425.1050432637@munnari.OZ.AU> <20030415195554.GX2303@ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20030415195554.GX2303@ecs.soton.ac.uk>; from ms@ecs.soton.ac.uk on Tue, Apr 15, 2003 at 08:55:54PM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Apr 15, 2003 at 08:55:54PM +0100, Mike Saywell wrote: > > It seems to me that most of the people who want to keep site-locals > only require the address space and not any special handling of scope. > Whilst the people that want to get rid of them are mainly concerned > about the problems scoping implies. > > So can we not simply deprecate the scoping side of things but leave the > allocation intact? Perhaps renaming it as being reserved for experimental > and disconnected networks only... > > Yes there are issues when sites merge etc, but they *can* use global > addresses, if they've chosen not too then they're making life much > harder for themselves and they deserve the pain ;) > > Ad-hoc networks and other minority cases such as community networks may > not have the luxury of obtaining the necessary global address space, > so they need some prefix to communicate, but nothing more. I didn't bother patticipating in the consensus call (forgot), but if I had it would have been to vote no. I've previously given my thoughts on this (during the previous round of "let's fill SL"), which were that as a user I wanted them, but as an implementor I could do without them. As a user my only need for them is to have a bunch of address space tha I could allocate from without having to coordinate with any RIR, and I'de like that to be a significant chunk of address space. As an implementor, the only real pain caused by SL (in forwarding) is that it effectivly requires multiple FIBs (or a scoped FIB), which can cause wonderful issues depending upon the router architecture. There are also issues at the routing level. The scope check when forwarding is a non issue, as it has to be done for LL anyway. So if we had a bunch of address space (say FE40::/10) reserved in the architecture that was for private allocation (without the scope / multi site features) I be happy to deprecate (for almost any definition of deprecate) SL addresses. I'd say that this new address block be treated like global unicast by all systems/apps, but that if one wanted to use it, then it was at one's own risk - you have to handle any issues that arise. This would still mean that the addresses are ambiguous, but then that's the user's problem for chosing to use them. If this ambiguity doesn't cause any issues for their application, then fair enougth. I would not limit the use of these addresses to any particular scenario. I would allow them to be used when one also (potentially) had proper assigned global unicasts. This would (for example) allow one to use these addresses for say transit and internal connectivity within a community wireless network, with end nodes potentially having bits of global unicast space handed on to them if/when they wanted to reach the wider internet. I'd not require any filtering requirements on the addresses, but in operational terms anyone using them would probably want to do some filtering. Likewise ISPs would probably want to drop packets using such addresses. We could also then simply the default address selection rules to be longest match (assuming SL deprecated). (How about reserving FE00::/8 for various 'ambigous' addresses?) DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 16 03:43:58 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 h3GAhvmh016263; Wed, 16 Apr 2003 03:43:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3GAhvIN016262; Wed, 16 Apr 2003 03:43:57 -0700 (PDT) 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 h3GAhsmh016255 for ; Wed, 16 Apr 2003 03:43:54 -0700 (PDT) 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 h3GAi1vV029319 for ; Wed, 16 Apr 2003 03:44:01 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id EAA13535 for ; Wed, 16 Apr 2003 04:43:56 -0600 (MDT) 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, 16 Apr 2003 10:43: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; Wed, 16 Apr 2003 10:43:48 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, 16 Apr 2003 10:43:48 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 10:43:47 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3GAhZj13370; Wed, 16 Apr 2003 13:43:35 +0300 Date: Wed, 16 Apr 2003 13:43:34 +0300 (EEST) From: Pekka Savola To: Derek Fawcus cc: Quality Quorum , Subject: Re: Any reason for configuring several LL@ on a given interface ? In-Reply-To: <20030416105515.A16173@edinburgh.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 Wed, 16 Apr 2003, Derek Fawcus wrote: > On Tue, Apr 15, 2003 at 07:11:39PM +0300, Pekka Savola wrote: > > As a bridge between Secure Neighbor Discovery and Neighbor Discovery, I'd > > say yes. > > So how's that going to work (maybe I should catch up on my send reading)? Not necessarily, but that's one option. If ND and SEND nodes are to communicate, that seems like the only way. The SEND protocol is still in the works, but one draft is out. > Given that redirects require routers to have one LL address on a link in > order to work. Not necessarily -- just as long as different sets of hosts consistently use a specific LL address you should be fine, I think. E.g., for SEND nodes, use LL_1; for ND nodes, use LL. > A router with multiple LL addresses on a given link would > have to look like multiple 'logical' routers. In a way, I think -- but that doesn't change the fact that the router does have to support them. Of course, the implementation might do that using sub-interfaces or the like -- don't know if it'd work. -- 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 Apr 16 03:45:04 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 h3GAj3mh016306; Wed, 16 Apr 2003 03:45:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3GAj3Gl016305; Wed, 16 Apr 2003 03:45:03 -0700 (PDT) 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 h3GAiwmh016291 for ; Wed, 16 Apr 2003 03:44:58 -0700 (PDT) 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 h3GAj6cU027015 for ; Wed, 16 Apr 2003 03:45:06 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id EAA14080 for ; Wed, 16 Apr 2003 04:45:01 -0600 (MDT) 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, 16 Apr 2003 10:44:58 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, 16 Apr 2003 10:44: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; Wed, 16 Apr 2003 10:44:57 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 10:44:57 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3GAilt13378; Wed, 16 Apr 2003 13:44:51 +0300 Date: Wed, 16 Apr 2003 13:44:47 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: IPv6 Subject: Re: IETF spec complexity and site locals [Re: C000] 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 I've put these two threads back separately because they deal with separate issues -- and it's easier for the rest to keep up. On Wed, 16 Apr 2003, Robert Elz wrote: > In another message pekkas@netcore.fi said: > | You miss my point completely. > | I'm worried about the specification complexity. Implementation complexity > | is important of course, but was not the point here. > > Specification complexity of SL is almost zero. At the *moment*, yes. > It has been that way for > ages. Because it has never been properly specified. > And implementations were using it regardless. What's more the > degree of specification was just about perfect for this. The aim and > basic rules were there, and that was it. Enough to work out what needed > to be accomplished. For basic stuff like the scope and address selection -- I'd maybe agree. But routing protocols, for example? Definitely not. > With that, implementors can go and try different ways of actually using > the things, documenting the results along the way for the benefit of others. I haven't seen much documentation yet -- the only thing has been Brian Haberman's experiences of prototype implementation with routing protocols. > | We need to ensure no significant amount of *IETF* work is wasted on making > | site-locals "work". The easiest way to do that seems to be "deprecating" > | them. > > There's been far more IETF work spent (it seems to me) in the past few > months on the attempt to deprecate site locals than was ever spent on their > specification, or on making them work. This hardly seems to have been *easy*. "ever spent" -- maybe yes. And that's the whole problem: a nice concept which doesn't seem to fly except in some certain scenarios. Currently, it's out there. When specs are written, at the moment, SL's must be taken into consideration in their fullest form. Any other action would seem irresponsible. "To be spent to be specify them properly" -- definitely not, as seen above. > All that was needed was to do nothing, and see what happens. > > That's still all that is needed. I totally disagree here. Let's see. From here, we might have an analogue: * we know Internet can be an nasty place from the security point of view -- however, there are likely some intranets which are actually pretty nice. Is it OK to just say "Security considerations are outside of the scope of this memo." and leave it at that in all specs, whether related to Internet, intranets or whatever else? -- 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 Apr 16 03:48: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 h3GAmGmh016458; Wed, 16 Apr 2003 03:48:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3GAmG0Q016457; Wed, 16 Apr 2003 03:48:16 -0700 (PDT) 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 h3GAmBmh016432 for ; Wed, 16 Apr 2003 03:48:11 -0700 (PDT) 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 h3GAmIvV000204 for ; Wed, 16 Apr 2003 03:48:18 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA26940 for ; Wed, 16 Apr 2003 03:48:12 -0700 (PDT) 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, 16 Apr 2003 10:47: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; Wed, 16 Apr 2003 10:47:46 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, 16 Apr 2003 10:47: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, 16 Apr 2003 10:47:44 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3GAlan13409; Wed, 16 Apr 2003 13:47:36 +0300 Date: Wed, 16 Apr 2003 13:47:36 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: IPv6 Subject: Re: hijacking prefixes for disconnected [RE: C000] In-Reply-To: <10872.1050436978@munnari.OZ.AU> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, all, Please note that the discussion was about "disconnected" case -- and for that only. Ensuring stable internal connectivity etc. is a different beast altogether. What I tried to do is to scope issues in the case that site *is* actually disconnected -- and a special single-subnet case of that in particular. Hijacking prefixes for stable internal connectivity while being connected to the Internet would be undoubtely a very bad practice :-). That said, I'll try to answer the few points here and move discussion on other topics to other threads (to make it easier to other people to keep up). On Wed, 16 Apr 2003, Robert Elz wrote: > | 3) reconfiguring all the instances where invented prefix was used > | - "finding out all the cases where it has been configured and > | changing them" > > But this is what doesn't happen - and it is exactly what sites want to > avoid - they want addressing that doesn't alter, at least for internal > uses. So, even assuming it is trivially easy, they won't change them. Assume that the system is is quite simple, and changes could be done by knowledgeable person in less than 10 minutes. Assume that the system would get a stable global prefix from the ISP. Why would it want to keep its invented prefix? Keeping it would actually hurt them too as it would be used in the source address selection and about a half of their packets would get return routed to /dev/null or some other site. They'd certainly want to renumber. > | Note: in today's world, it seems to me that almost all of these cases are > | really those of intermittent connectivity. > > Of changing connectivity, whether intermittent, or not. Right now > (as of this instant I mean) my connections rarely last much more than > an hour or so (then restart fairly quickly). Every time I connect I > get a different address. You can be dead sure that that address has > no bearing at all on the addressing I am using on my internal net. This is outside of the scope of the original topic -- see a separate thread for thoughts on why ISP's change prefixes/addresses. > | HOWEVER, remember that we're talking about "dentist's office" case: a > | single link which has zero connectivity. No external parties all over the > | Internet; only a node or two on the local link. > > No. That's one scenario. That was the specific scenario here (I think). I didn't claim to analyze all the SL scenarios. > Another is a link which is normally connected, > but where the router just happens to be down (maybe the router is a linux > system and the thing has crashed...). There, there's nothing to hand out > prefixes to other nodes, so all they're going to get are LL addresses. In this particular case, I wouldn't be worried about this at all, but that's just me. > There's too much "I know how the net should be used, anyone who dreams of > using it differently than I think should be done is brain dead" type stuff > going on here. Learn to accept that people will use things in all kinds > of ways that none of us can imagine right now. I agree that we can't force a model on people -- but then again, we *can* try to look at which models people have, and try to design solutions for that. Looking at the problem of *disconnected* dentist's office (as far as I understood it) would be on such approach. > In another message pekkas@netcore.fi said: > | You miss my point completely. > | I'm worried about the specification complexity. Implementation complexity > | is important of course, but was not the point here. Answered in different thread. -- 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 Apr 16 03:50: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 h3GAoGmh016595; Wed, 16 Apr 2003 03:50:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3GAoG80016594; Wed, 16 Apr 2003 03:50:16 -0700 (PDT) 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 h3GAoCmh016584 for ; Wed, 16 Apr 2003 03:50:12 -0700 (PDT) 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 h3GAoHvV000625 for ; Wed, 16 Apr 2003 03:50:17 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA16307 for ; Wed, 16 Apr 2003 04:50:11 -0600 (MDT) 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, 16 Apr 2003 10:50: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, 16 Apr 2003 10:46:23 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, 16 Apr 2003 10:50:11 Z Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 10:50:10 Z Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 16 Apr 2003 12:50:00 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h3GAmF9F010740; Wed, 16 Apr 2003 12:48:15 +0200 (MET DST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA27964; Wed, 16 Apr 2003 11:50:03 +0100 (BST) Date: Wed, 16 Apr 2003 11:50:03 +0100 From: Derek Fawcus To: Pekka Savola Cc: Quality Quorum , ipng@sunroof.eng.sun.com Subject: Re: Any reason for configuring several LL@ on a given interface ? Message-Id: <20030416115003.C16173@edinburgh.cisco.com> Mail-Followup-To: Pekka Savola , Quality Quorum , ipng@sunroof.eng.sun.com References: <20030416105515.A16173@edinburgh.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from pekkas@netcore.fi on Wed, Apr 16, 2003 at 01:43:34PM +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Apr 16, 2003 at 01:43:34PM +0300, Pekka Savola wrote: > On Wed, 16 Apr 2003, Derek Fawcus wrote: > > Given that redirects require routers to have one LL address on a link in > > order to work. > > Not necessarily -- just as long as different sets of hosts consistently > use a specific LL address you should be fine, I think. > > E.g., for SEND nodes, use LL_1; for ND nodes, use LL. Consider one router redirecting a host to a better on link router. It would seem that you're placing a requirement that all routers maintain knowledge of all nodes on a link that are SEND capable? OK - time to read the current send draft, before I speculate further. DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 16 04:18:14 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 h3GBIEmh017476; Wed, 16 Apr 2003 04:18:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3GBIEv3017475; Wed, 16 Apr 2003 04:18:14 -0700 (PDT) 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 h3GBIAmh017466 for ; Wed, 16 Apr 2003 04:18:10 -0700 (PDT) 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 h3GBIIvV005483 for ; Wed, 16 Apr 2003 04:18:18 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA08151 for ; Wed, 16 Apr 2003 05:18:12 -0600 (MDT) 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, 16 Apr 2003 11:18: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; Wed, 16 Apr 2003 11:14: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; Wed, 16 Apr 2003 11:18:10 Z Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 11:18:09 Z Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3GBFBft167770; Wed, 16 Apr 2003 07:15:11 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-251-64.mts.ibm.com [9.65.251.64]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3GBFBuB079562; Wed, 16 Apr 2003 05:15:11 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h3GBDOi10807; Wed, 16 Apr 2003 07:13:24 -0400 Message-Id: <200304161113.h3GBDOi10807@cichlid.adsl.duke.edu> To: Robert Elz cc: IPv6 Subject: Re: C000 In-Reply-To: Message from kre@munnari.OZ.AU of "Sat, 12 Apr 2003 20:03:12 +0700." <12210.1050152592@munnari.OZ.AU> Date: Wed, 16 Apr 2003 07:13:24 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > Date: Fri, 11 Apr 2003 15:18:23 -0700 > From: David Conrad > Message-ID: <826430D3-6C6B-11D7-BE91-000393DB42B2@nominum.com> > | My impression (correct me if I am wrong) is that site-local imposes > | additional complexity on each and every v6 implementation > No, I think the extra required of site local is trivial. The only real > extra work is to support routing protocols in multi-site nodes, and no-one > is required to support that. I think it is naive to believe that implementing SLs can truly be optional and only impacts those that chose to implement/use them. If they get widely used, implementations will be forced to deal with the consequences, including those that specifically didn't want to do anything special with SLs. >From a previous posting: Thomas Narten writes: > Having said that, one of the great difficulties I have with SLs is > that I don't see a viable "compromise" or "middle ground". Every > proposal I have looked at either uses SLs in very restricted settings > (e.g, disconnected sites), or ends up having to implement the full > blown "multi-sited node" (even though try to claim otherwise). I find > scenarios that argue for a middle ground to be an unworkable illusion. > Consider a bottom line. If we say SL addresses are a reasonable thing > for (say) home networks doing autoconfig, and so on, the reality will > be that SOHO routers will find ways of creating zeroconf environments > that enable SL by default. They will then be used in practice in huge > numbers of home networks. Corporations will likewise be tempted to use > them, since they seem to provide "permanent" addresses, and > "stability" across renumbering. So, we have situation not unlike being > half-pregnant. In practice, SLs will become widely used in many > organizations. > But, once you have wide usage in terms of independent networks > numbered using SLs, you have the inevitable problem of what happens if > a node is in two sites at the same time. I don't buy the argument that > this won't happen much and that the market can fill the gap if there > is a need (and the IETF thus won't need to do this). If widespread > useage of SL in networks becomes the reality, devices will be forced > to work in those enviornments. One simple example: at home, I have my > home network with a DSL link to the internet and also a VPN connection > to my corporate intranet. This is a *very* common operating > configuration. (Does anyone believe this won't be a common > environment?) If both the home and corporate network use SL addressing > (as they will in practice), things just won't work right unless nodes > implement the multi-sited node architecture. > Thus, I continue to come to the conclusion that we can't have it both > ways. We either deprecate SLs, or we do the full blown multi-sited > node. Doing anything in between will not work well enough in practice > (i.e., is equivalent to us putting our heads in the sand) and will > lead to interoperability problems, failed communications, and a less > robust Internet. Exactly the opposite of what I believe IPv6 is all > about. 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 Apr 16 04:26: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 h3GBQcmh017834; Wed, 16 Apr 2003 04:26:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3GBQbGr017833; Wed, 16 Apr 2003 04:26:37 -0700 (PDT) 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 h3GBQYmh017826 for ; Wed, 16 Apr 2003 04:26:34 -0700 (PDT) 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 h3GBQgvV006870 for ; Wed, 16 Apr 2003 04:26:42 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA16422 for ; Wed, 16 Apr 2003 05:26:36 -0600 (MDT) 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, 16 Apr 2003 11:26: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, 16 Apr 2003 11:26: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, 16 Apr 2003 11:26:36 Z Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 11:26:35 Z Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3GBNuft112740; Wed, 16 Apr 2003 07:23:56 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-251-64.mts.ibm.com [9.65.251.64]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3GBNtuB076284; Wed, 16 Apr 2003 05:23:55 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h3GBM8w11244; Wed, 16 Apr 2003 07:22:09 -0400 Message-Id: <200304161122.h3GBM8w11244@cichlid.adsl.duke.edu> To: Robert Elz cc: IPv6 Subject: Re: C000 In-Reply-To: Message from kre@munnari.OZ.AU of "Tue, 15 Apr 2003 16:29:44 +0700." <5998.1050398984@munnari.OZ.AU> Date: Wed, 16 Apr 2003 07:22:08 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But I still don't see what getting rid of SL really accomplishes there. > Those same apps need to deal with using LL addresses when nothing else > is available, and they need to be able to operate on nodes that have > attachments to multiple links where only LL addresses exist. > It seems to me that the problems there are just the same as the problems > with SLs that you imply. In theory, the problems are similar, in practice, I think not. I.e., the difficulties can be contained for LLs much more easily than with SLs. Differences include: - LLs are useful for boostrapping; that is what people seem to say they will be used for. Folk aren't arguing that LLs be used to keep connections stable across renumbering, or for numbering their internal links in a PI manner. - LLs will almost certainly not be in the DNS, whereas SLs will (how else can applications find them and use them?) - Using LLs as a last resort is generally fine; implementations can almost pretend they don't exists unless there are no other addresses (e.g., via address selection rules). But one of the goals people have for SLs is that their usage is preferred over globals (when possible). - Single link environments aren't going to be the norm, thus global addresses will be needed to reach off-link destinations. In those environments, LLs only need to be used in limited settings. I don't see the desirably or need for a node being in multiple "sites", if it only has LL addresses. But this is certainly what will happen if SLs are used. It is the need to implement full multi-sitedness that brings the full complexity into the picture. So far, the notion that one can get the benefts of SL without also implying a need to implement the full multi-sited node mode has been unconvincing. > So, are you proposing to do away with LLs, leaving only global addresses, > to make the application code writers job easier? If not, then they're > going to have to cope anyway, aren't they? Nodes/applications can treat LLs as if they were global addresses in most cases without it causing a lot of problems. They don't need to special case for them (except for applications that use LLs as part of the protocol -- but that is a minimal set). Treating SLs as if they were global will lead to things not working correctly in practice (e.g, the multi-sited node example). > Lastly however, my model of SL usage (which I admit hasn't been widely > distributed yet, though if you read all my messages, going back a long > time, on this topic, you'd probably guess easily enough) has only those > apps that actually want to use SL addresses ever actually seeing the > things. Your model is different than the model others have and are pushing when they say "keep SLs". There are some who argue that an important benefit of SLs is that they can keep connections stable across renumbering events. That is largely at odds with the idea that only apps that care about SLs will use them and or have to know about them. Or, what if you connect to a site that has SLs in the DNS (because that is what the site has chosen to do)? Maybe the application never wanted to deal with this case, bit it has no been forced to. 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 Apr 16 05:00: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 h3GC0Qmh018872; Wed, 16 Apr 2003 05:00:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3GC0Q47018871; Wed, 16 Apr 2003 05:00:26 -0700 (PDT) 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 h3GC0Nmh018864 for ; Wed, 16 Apr 2003 05:00:23 -0700 (PDT) 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 h3GC0UcU009715 for ; Wed, 16 Apr 2003 05:00:31 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA24009 for ; Wed, 16 Apr 2003 06:00:25 -0600 (MDT) 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, 16 Apr 2003 12:00: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, 16 Apr 2003 11:56: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, 16 Apr 2003 12:00:24 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; Wed, 16 Apr 2003 12:00:24 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.11]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA08907; Wed, 16 Apr 2003 04:59:50 -0700 (PDT) Message-Id: <5.1.0.14.2.20030416075554.0430ffa0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 16 Apr 2003 07:58:21 -0400 To: "EricLKlein" From: Margaret Wasserman Subject: Re: Site Locals - a silly suggestion Cc: "IPv6" In-Reply-To: <00bb01c303de$f7f88bf0$7a051eac@ttitelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Eric, At 09:11 AM 4/16/2003 +0300, EricLKlein wrote: >As the addresses ::10:x:x:x (and the rest of the RFC 1918 addresses) will >have to keep their existing "local only: special status, lets just make >this official (i.e. not add another IPv6 /10 space) and write it into the >specification. > >This way we don't add work and we don't kill what is installed in so many >companies already. These are the companies (or people) that will insist >on using an 4 to 6 "NAT" on their router based on a Global IPv6 address >that will be provided by their ISP and their own (existing or new) RFC >1918 addresses inside their private network. This is an interesting suggestion. It fits well with the suggestion that others have made that people who have stable PI address space in IPv4 could use the IPv6 addresses that map to their IPv4 addresses. This might be one way of, quite literally, making sure that IPv6 doesn't take away anything that people can already do in IPv4. 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 Apr 16 06:24:10 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 h3GDOAmh019373; Wed, 16 Apr 2003 06:24:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3GDOAYK019372; Wed, 16 Apr 2003 06:24:10 -0700 (PDT) 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 h3GDO7mh019365 for ; Wed, 16 Apr 2003 06:24:07 -0700 (PDT) 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 h3GDOEvV025882 for ; Wed, 16 Apr 2003 06:24:14 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id HAA00633 for ; Wed, 16 Apr 2003 07:24:08 -0600 (MDT) 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, 16 Apr 2003 13:24:07 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, 16 Apr 2003 13:20: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; Wed, 16 Apr 2003 13:24:06 Z Received: from TheWorld.com ([199.172.62.104] [199.172.62.104]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 13:24:06 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id h3GDO6AU023061 for ; Wed, 16 Apr 2003 09:24:06 -0400 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id JAA53121 for ; Wed, 16 Apr 2003 09:24:05 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Wed, 16 Apr 2003 09:24:05 -0400 From: Quality Quorum To: ipng@sunroof.eng.sun.com Subject: Re: Site Locals - a silly suggestion In-Reply-To: <5.1.0.14.2.20030416075554.0430ffa0@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 Wed, 16 Apr 2003, Margaret Wasserman wrote: > > Hi Eric, > > At 09:11 AM 4/16/2003 +0300, EricLKlein wrote: > >As the addresses ::10:x:x:x (and the rest of the RFC 1918 addresses) will > >have to keep their existing "local only: special status, lets just make > >this official (i.e. not add another IPv6 /10 space) and write it into the > >specification. > > > >This way we don't add work and we don't kill what is installed in so many > >companies already. These are the companies (or people) that will insist > >on using an 4 to 6 "NAT" on their router based on a Global IPv6 address > >that will be provided by their ISP and their own (existing or new) RFC > >1918 addresses inside their private network. > > This is an interesting suggestion. It fits well with the suggestion > that others have made that people who have stable PI address space > in IPv4 could use the IPv6 addresses that map to their IPv4 addresses. > > This might be one way of, quite literally, making sure that IPv6 > doesn't take away anything that people can already do in IPv4. IMHO, it is not going to work, because there is no IID field here and hence a lot of stuff would simply be broken. > > Margaret > 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 Apr 16 07:32: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 h3GEWXmh020100; Wed, 16 Apr 2003 07:32:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3GEWWVQ020099; Wed, 16 Apr 2003 07:32:32 -0700 (PDT) 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 h3GEWTmh020092 for ; Wed, 16 Apr 2003 07:32:29 -0700 (PDT) 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 h3GEWbvV008322 for ; Wed, 16 Apr 2003 07:32:37 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id HAA00073 for ; Wed, 16 Apr 2003 07:32:31 -0700 (PDT) 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, 16 Apr 2003 14:32:31 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, 16 Apr 2003 14:32: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; Wed, 16 Apr 2003 14:32:30 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 14:32:30 Z Content-class: urn:content-classes:message Subject: RE: Site Locals - a silly suggestion MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 16 Apr 2003 07:32:28 -0700 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F78A@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: Site Locals - a silly suggestion thread-index: AcMEHKd3CG5bOF3PRGOiLFwPNDh6fgAB7YVQ From: "Michel Py" To: "Quality Quorum" , , "EricLKlein" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3GEWTmh020093 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> At 09:11 AM 4/16/2003 +0300, EricLKlein wrote: >> As the addresses ::10:x:x:x (and the rest of the RFC 1918 addresses) > Aleksey > IMHO, it is not going to work, because there is no IID field > here and hence a lot of stuff would simply be broken. Correct. Besides, hasn't this stuff been taken out of RFC 3513? Nice try Eric, but no cigar this time. Keep trying though. 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 Apr 16 08:44: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 h3GFihmh020960; Wed, 16 Apr 2003 08:44:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3GFihO4020959; Wed, 16 Apr 2003 08:44:43 -0700 (PDT) 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 h3GFidmh020952 for ; Wed, 16 Apr 2003 08:44:40 -0700 (PDT) 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 h3GFilvV025695 for ; Wed, 16 Apr 2003 08:44:47 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA19649 for ; Wed, 16 Apr 2003 08:44:42 -0700 (PDT) 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, 16 Apr 2003 15:44:39 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, 16 Apr 2003 15:40: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, 16 Apr 2003 15:44:39 Z Received: from c001.snv.cp.net ([209.228.32.115] [209.228.32.115]) by relay11.sun.com for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 15:44:39 Z Received: (cpmta 1668 invoked from network); 16 Apr 2003 08:44:15 -0700 Received: from 139.92.208.223 (HELO w2knerick) by smtp.register-admin.com (209.228.32.115) with SMTP; 16 Apr 2003 08:44:15 -0700 X-Sent: 16 Apr 2003 15:44:15 GMT Message-Id: <001d01c3042f$03a1b850$dfd05c8b@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <963621801C6D3E4A9CF454A1972AE8F504F78A@server2000.arneill-py.sacramento.ca.us> Subject: Re: Site Locals - a silly suggestion Date: Wed, 16 Apr 2003 18:42:45 +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 ----- Original Message ----- From: "Michel Py" To: "Quality Quorum" ; ; "EricLKlein" Sent: Wednesday, April 16, 2003 5:32 PM Subject: RE: Site Locals - a silly suggestion >> At 09:11 AM 4/16/2003 +0300, EricLKlein wrote: >> As the addresses ::10:x:x:x (and the rest of the RFC 1918 addresses) > Aleksey > IMHO, it is not going to work, because there is no IID field > here and hence a lot of stuff would simply be broken. > Correct. Besides, hasn't this stuff been taken out of RFC 3513? Seems I missed this one, how will the old RFC 1918 addresses be dealt with in the new ::x:x:x:x world of IPv6? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 16 15:30: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 h3GMUbmh023567; Wed, 16 Apr 2003 15:30:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3GMUb2L023566; Wed, 16 Apr 2003 15:30:37 -0700 (PDT) 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 h3GMUXmh023559 for ; Wed, 16 Apr 2003 15:30:34 -0700 (PDT) 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 h3GMUecU011303 for ; Wed, 16 Apr 2003 15:30:40 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA22367 for ; Wed, 16 Apr 2003 16:30:35 -0600 (MDT) 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, 16 Apr 2003 22:30: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; Wed, 16 Apr 2003 22:26: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; Wed, 16 Apr 2003 22:30:32 Z Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 16 Apr 2003 22:30:31 Z Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by atlrel9.hp.com (Postfix) with ESMTP id 440261C01456; Wed, 16 Apr 2003 18:30:31 -0400 (EDT) Received: from rose.hp.com (ros54018fli.rose.hp.com [15.29.17.171]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id PAA12362; Wed, 16 Apr 2003 15:30:22 -0700 (PDT) Message-Id: <3E9DD97E.4E1450B3@rose.hp.com> Date: Wed, 16 Apr 2003 15:30:22 -0700 From: John Flick X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert.Peschi@alcatel.be Cc: ipng@sunroof.eng.sun.com Subject: Re: Any reason for configuring several LL@ on a given interface ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert.Peschi@alcatel.be wrote: > > On Tue, 15 Apr 2003, Shannon -jj Behrens wrote: > > > Multiple attachments would = multiple interfaces, correct? The question > was > > about having multiple addresses on one interface. Perhaps I'm missing > > something. > > Actually, I have no doubt about the relevance for several global addresses > per IPv6 interface (e.g. for site renumbering with address finite > lifetime). > > What I was wondering is the relevance for having several > FE80:: > on the same IPv6 interface (say on a POS fibre). See draft-ietf-vrrp-ipv6-spec-03.txt for one example of where an IPv6 interface may have multiple LL addresses. 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 Apr 16 20:54: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 h3H3s8mh025223; Wed, 16 Apr 2003 20:54:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3H3s8EX025222; Wed, 16 Apr 2003 20:54:08 -0700 (PDT) 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 h3H3s4mh025215 for ; Wed, 16 Apr 2003 20:54:04 -0700 (PDT) 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 h3H3sBcU001767 for ; Wed, 16 Apr 2003 20:54:11 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA19912 for ; Wed, 16 Apr 2003 21:54:06 -0600 (MDT) 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, 17 Apr 2003 03:54: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; Thu, 17 Apr 2003 03: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, 17 Apr 2003 03:54:01 Z Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 17 Apr 2003 03:54:00 Z Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h3H3s0l1023904 for ; Wed, 16 Apr 2003 20:54:00 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id UAA26953 for ; Wed, 16 Apr 2003 20:53:25 -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 h3H3rsVI027073 for ; Thu, 17 Apr 2003 13:53:56 +1000 (EST) Message-Id: <3E9E2552.914CD268@motorola.com> Date: Thu, 17 Apr 2003 13:53:54 +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: IPv6 Subject: Re: C000 References: <200304161122.h3GBM8w11244@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > > Your model is different than the model others have and are pushing > when they say "keep SLs". There are some who argue that an important > benefit of SLs is that they can keep connections stable across > renumbering events. That is largely at odds with the idea that only > apps that care about SLs will use them and or have to know about > them. I don't see it this way. IMO, desirable default behaviour is to use site locals iff they exist (see RFC3484, section 6, rules 2, 8, 9). In fact, use the smallest relevant scope (based on whatever destination ID (eg hostname) you are using). Given this, work your way up the destination list until something works. This works for "most" applications regardless of scopes, filters, or site locals. So, name -> address resolvers or similar systems will need to know about address scopes so they can implement source address selection. Most applications can remain blissfully ignorant and simply try addresses in the order given until one works or they all fail, without considering scope. The applications that will have problems are those that intend to forward addresses (not just names) in a manner that might cross scope boundaries. Such applications need much more complex address selection rules, since they need to choose addresses that will work across the entire mesh, not just point-to-point. For such applications, the difference between a site local address and a "global" address is that the site local promises that it is scoped. The global may have global scope, or may be filtered. Recovery code is needed in either case - SLs have the advantage that they can be discarded a-priori, since using an SL to a machine with only a global can be reasonably expected to break. -- 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 Thu Apr 17 02:19:02 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 h3H9J2mh027630; Thu, 17 Apr 2003 02:19:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3H9J1U1027629; Thu, 17 Apr 2003 02:19:01 -0700 (PDT) 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 h3H9Iwmh027622 for ; Thu, 17 Apr 2003 02:18:58 -0700 (PDT) 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 h3H9J6vV000071 for ; Thu, 17 Apr 2003 02:19:06 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id CAA23732 for ; Thu, 17 Apr 2003 02:19:00 -0700 (PDT) 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, 17 Apr 2003 09:19: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; Thu, 17 Apr 2003 09:18: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, 17 Apr 2003 09:18:59 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 17 Apr 2003 09:18:58 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3H9Ia324662; Thu, 17 Apr 2003 16:18:36 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3H9IIL18746; Thu, 17 Apr 2003 16:18:23 +0700 (ICT) From: Robert Elz To: Mika Liljeberg cc: IPv6 Subject: Re: C000 In-Reply-To: <1050445842.22244.576.camel@devil> References: <1050445842.22244.576.camel@devil> <1050424546.22241.73.camel@devil> <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> <5998.1050398984@munnari.OZ.AU> <9519.1050432947@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Apr 2003 16:18:18 +0700 Message-Id: <18744.1050571098@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 16 Apr 2003 01:30:44 +0300 From: Mika Liljeberg Message-ID: <1050445842.22244.576.camel@devil> | The terminal gets an IP address from the gateway | as part of the tunnel setup procedure (called PDP context activation). | This means that, as soon as the terminal activates more than one packet | data service, it automatically becomes multi-site (assuming the gateways | for the services belong to different sites). Huh? I'm still mis-understanding something. Why would I want my terminal (phone) to be a member of either (any) of the sites that are relevant to the gateways? | The mobile might also have access to circuit switched data services. Add | to that VPN or a short range radio like Bluetooth or 802.11 and you have Sure, if I have a bunch of local attached devices, I'm likely to want all of them, and the handset, to be in the same site. But I'm still not sure why I'd want them to be in a site connected to any service provider. I suspect that you're assuming that all links have to be in some site or other - they don't - siteless links are entirely possible (and in the IPv6 world as it exists right now, are probably the most common around). Sites (as in the usage of the term in site local addressing) are an administrative concept - multi-site nodes only really make sense when a node is controlled by multiple administrations (and some similar cases where a link wants to be in a site, where the attached nodes are controlled by multiple administrations, because links can't be in multiple sites). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 17 02:30: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 h3H9UJmh027966; Thu, 17 Apr 2003 02:30:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3H9UI9T027965; Thu, 17 Apr 2003 02:30:18 -0700 (PDT) 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 h3H9UFmh027958 for ; Thu, 17 Apr 2003 02:30:15 -0700 (PDT) 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 h3H9UNcU000099 for ; Thu, 17 Apr 2003 02:30:23 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id CAA29037 for ; Thu, 17 Apr 2003 02:30:17 -0700 (PDT) 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, 17 Apr 2003 09:30: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; Thu, 17 Apr 2003 09:30:16 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, 17 Apr 2003 09:30:16 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; Thu, 17 Apr 2003 09:30:16 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 KAA12284; Thu, 17 Apr 2003 10:22: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 KAA11502; Thu, 17 Apr 2003 10:22:43 +0100 (BST) Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3H9Mhq05071; Thu, 17 Apr 2003 10:22:43 +0100 Date: Thu, 17 Apr 2003 10:22:43 +0100 From: Mike Saywell To: Margaret Wasserman Cc: Pekka Savola , Robert Elz , IPv6 Subject: Re: IETF spec complexity and site locals [Re: C000] Message-Id: <20030417092243.GE2303@ecs.soton.ac.uk> References: <9425.1050432637@munnari.OZ.AU> <5.1.0.14.2.20030415164902.0467f6f0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030415164902.0467f6f0@mail.windriver.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Apr 15, 2003 at 04:51:52PM -0400, Margaret Wasserman wrote: > >Ad-hoc networks and other minority cases such as community networks may > >not have the luxury of obtaining the necessary global address space, > >so they need some prefix to communicate, but nothing more. > > It would be hard for me to disagree with you, because this is exactly > what I proposed in my "limited" model... > > However, people have convinced me that there are already implementations > that include special handling for the FECO::/10 prefix, based on the > assumption that it is "scoped" (as defined in the scoped addressing > architecture). Hmm, hence the C000::/3 proposal I suppose. Well I'd vote "YES" for either, I think it's the best middle-ground we're likely to find... 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 Thu Apr 17 02:38: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 h3H9cBmh028380; Thu, 17 Apr 2003 02:38:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3H9cB2Q028379; Thu, 17 Apr 2003 02:38:11 -0700 (PDT) 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 h3H9c8mh028372 for ; Thu, 17 Apr 2003 02:38:08 -0700 (PDT) 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 h3H9cFvV004267 for ; Thu, 17 Apr 2003 02:38:15 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA18950 for ; Thu, 17 Apr 2003 03:38:09 -0600 (MDT) 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, 17 Apr 2003 09:38: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; Thu, 17 Apr 2003 09:38: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; Thu, 17 Apr 2003 09:38:08 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 17 Apr 2003 09:38:06 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3H9br303460; Thu, 17 Apr 2003 16:37:56 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3H9bXL18783; Thu, 17 Apr 2003 16:37:42 +0700 (ICT) From: Robert Elz To: Robert.Peschi@alcatel.be cc: ipng@sunroof.eng.sun.com Subject: Re: Any reason for configuring several LL@ on a given interface ? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Apr 2003 16:37:33 +0700 Message-Id: <18781.1050572253@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 16 Apr 2003 09:59:46 +0200 From: Robert.Peschi@alcatel.be Message-ID: | What I was wondering is the relevance for having several | FE80:: | on the same IPv6 interface (say on a POS fibre). I do that sometimes, but I can't claim it is for much of a good reason. Keeping the FE80::EUI-64 makes things "normal", but having FE80::1 makes things "easy", so I sometimes just have both, the EUI form is what the system will use (when it originates packets, for RS, etc). The ::1 form is what I use (as target addr) when I ping, or similar, when I am using literal addresses for some reason. I've also done it on tunnels to linux boxes - they like to use fe80::i.p.v.4 as the LL on the tunnel, whereas NetBSD/KAME uses FE80::EUI-64 (taken from some relevant interface). There I often use fe80::1 (as above) and also add fe80::i.p.v.4 so my NetBSD end will have an address that a linux user might assume that it is going to have. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 17 02:42: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 h3H9grmh028619; Thu, 17 Apr 2003 02:42:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3H9gr8x028617; Thu, 17 Apr 2003 02:42:53 -0700 (PDT) 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 h3H9gnmh028601 for ; Thu, 17 Apr 2003 02:42:49 -0700 (PDT) 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 h3H9gvcU002240 for ; Thu, 17 Apr 2003 02:42:57 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id CAA15968 for ; Thu, 17 Apr 2003 02:42:51 -0700 (PDT) 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, 17 Apr 2003 09:42:49 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, 17 Apr 2003 09:42: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; Thu, 17 Apr 2003 09:42:48 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 17 Apr 2003 09:42:42 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3H9fp305293; Thu, 17 Apr 2003 16:41:51 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3H9fcL18798; Thu, 17 Apr 2003 16:41:38 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: IPv6 Subject: Re: IETF spec complexity and site locals [Re: C000] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Apr 2003 16:41:38 +0700 Message-Id: <18796.1050572498@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 16 Apr 2003 13:44:47 +0300 (EEST) From: Pekka Savola Message-ID: | Let's see. From here, we might have an analogue: | | * we know Internet can be an nasty place from the security point of view | -- however, there are likely some intranets which are actually pretty | nice. Hmm - interesting example. I'd veen considering writing a draft deprecating the AH and ESP headers. All the arguments I've seen (with trivial rearrangements) for deprecating site local addresses apply. They're not much used, there are problems with key distribution that aren't yet specified, issues of authenticity, ... And in practice TLS (SSL) accomplishes all that's really needed, and it is widely deployed. So, should we go ahead with that? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 17 02:49:46 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 h3H9nkmh029069; Thu, 17 Apr 2003 02:49:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3H9nktO029068; Thu, 17 Apr 2003 02:49:46 -0700 (PDT) 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 h3H9ngmh029058 for ; Thu, 17 Apr 2003 02:49:42 -0700 (PDT) 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 h3H9nocU003698 for ; Thu, 17 Apr 2003 02:49:50 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA24502 for ; Thu, 17 Apr 2003 03:49:44 -0600 (MDT) 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, 17 Apr 2003 09:49: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; Thu, 17 Apr 2003 09:45: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; Thu, 17 Apr 2003 09:49:41 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 17 Apr 2003 09:49:40 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3H9nX308007; Thu, 17 Apr 2003 16:49:33 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3H9nCL18812; Thu, 17 Apr 2003 16:49:12 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: IPv6 Subject: Re: hijacking prefixes for disconnected [RE: C000] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Apr 2003 16:49:12 +0700 Message-Id: <18810.1050572952@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 16 Apr 2003 13:47:36 +0300 (EEST) From: Pekka Savola Message-ID: | Please note that the discussion was about "disconnected" case -- and for | that only. Ensuring stable internal connectivity etc. is a different | beast altogether. What I tried to do is to scope issues in the case that | site *is* actually disconnected -- and a special single-subnet case of | that in particular. The problem is that when you divide up the problems into neat little compartments, and try to solve each one separately, the mess that results when you try and combine it all back together again is far worse than anything we have today. | Assume that the system is is quite simple, and changes could be done by | knowledgeable person in less than 10 minutes. Sure (I know others will never assume that would ever be possible, but I am willing to assume that eventually we can make renumbering quite painless). | Assume that the system would get a stable global prefix from the ISP. I'm not sure I'd assume that. In fact, I think it would be unlikely. | Why would it want to keep its invented prefix? Why would it want to change? | Keeping it would actually | hurt them too as it would be used in the source address selection and | about a half of their packets would get return routed to /dev/null or some | other site. They'd certainly want to renumber. You're making assumptions about what you'd want, and applying them to others. If my invented address is 8123:4567::whatever then source address selection isn't going to be a problem, anything to a 2000::/3 address will pick whatever 2000::/3 address my ISP has supplied me just now. Anything to my 8123:4567::/32 address space will use that address as source. All looks like it will work fine to me - and painlessly avoid having my internal connections break. Of course, so does fec0::/10 in just the same way, with the advantage that what is going on with that address is known by everyone. | That was the specific scenario here (I think). I didn't claim to analyze | all the SL scenarios. You're in favour of deprecating the things without analysing all scenarios? | I agree that we can't force a model on people -- but then again, we *can* | try to look at which models people have, and try to design solutions for | that. Sure. And while doing so, let's look for a unified model which suits all the purposes if we can, it keeps everything simpler. That's how site locals came about of course. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 17 03:05: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 h3HA5Omh029549; Thu, 17 Apr 2003 03:05:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3HA5Ot9029548; Thu, 17 Apr 2003 03:05:24 -0700 (PDT) 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 h3HA5Lmh029541 for ; Thu, 17 Apr 2003 03:05:21 -0700 (PDT) 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 h3HA5RcU006503 for ; Thu, 17 Apr 2003 03:05:28 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id EAA02135 for ; Thu, 17 Apr 2003 04:05:19 -0600 (MDT) 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, 17 Apr 2003 10:05:08 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, 17 Apr 2003 10:05: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, 17 Apr 2003 10:05:08 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 17 Apr 2003 10:04:09 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3HA3x309531; Thu, 17 Apr 2003 17:04:00 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3HA3iL18836; Thu, 17 Apr 2003 17:03:47 +0700 (ICT) From: Robert Elz To: Thomas Narten cc: IPv6 Subject: Re: C000 In-Reply-To: <200304161113.h3GBDOi10807@cichlid.adsl.duke.edu> References: <200304161113.h3GBDOi10807@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Apr 2003 17:03:44 +0700 Message-Id: <18834.1050573824@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 16 Apr 2003 07:13:24 -0400 From: Thomas Narten Message-ID: <200304161113.h3GBDOi10807@cichlid.adsl.duke.edu> | I think it is naive to believe that implementing SLs can truly be | optional and only impacts those that chose to implement/use them. If | they get widely used, implementations will be forced to deal with the | consequences, including those that specifically didn't want to do | anything special with SLs. Of course. There's no surprise there. But that's if they get widely used. If they're not used much at all, then implementations will largely be able to ignore them, right? So, your argument seems to be that you want to deprecate site locals because you're afraid they'll get used. That's novel. | > So, we have situation not unlike being | > half-pregnant. In practice, SLs will become widely used in many | > organizations. I would hope that's what will happen, yes. | > But, once you have wide usage in terms of independent networks | > numbered using SLs, you have the inevitable problem of what happens if | > a node is in two sites at the same time. Why? If that was simply made impossible, then the node would have to choose which site it wanted to be in. Some might curse the restriction, but people would adapt (and/or implementations would adapt - just as some RIPv1 implementations managed to handle multiple subnet masks on a network they were routing, something which is apparently impossible to achieve using RIPv1). | One simple example: at home, I have my | > home network with a DSL link to the internet and also a VPN connection | > to my corporate intranet. This is a *very* common operating | > configuration. (Does anyone believe this won't be a common | > environment?) If both the home and corporate network use SL addressing | > (as they will in practice), things just won't work right unless nodes | > implement the multi-sited node architecture. Huh? The multi-site architecture that's currently proposed can't deal with that - only a node can be in multiple sites, not a link. To do what you're describing, your home lan would want to be in two sites, and site locals just can't deal with that. For me, I'd just be a part of my corporate lan's site (I'm not in the slightest bit interested in being part of some random ISP's site, even if they'd allow me). Being "part of the site" just means integrating addressing. That will already be being done for the corporation's global addressing (I'll have a piece of that for my home use) - I'd expect to just get the equivalent piece of their site local addressing. This works just fine for me (and I guess you) - at home I'm never going to want an entire /48 (as in, consume the whole thing), so however I get my addressing I'm only going to be using a small part. The actual numbers I use for my subnet numbers are irrelevant. But even if that isn't possible, and the corporation won't give me any addresses at all (global or site-local) I can still be part of the same site just by picking a different value for the upper 38 "used to be 0" bits in the site-local address, and not configuring boundaries. As long as the values are different, as many nets as want can be connected together that way. You don't have to configure boundaries - so you don't have to have different sites. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 17 03:41:42 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 h3HAfgmh029994; Thu, 17 Apr 2003 03:41:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3HAffP3029993; Thu, 17 Apr 2003 03:41:41 -0700 (PDT) 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 h3HAfcmh029986 for ; Thu, 17 Apr 2003 03:41:38 -0700 (PDT) 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 h3HAfjvV013875 for ; Thu, 17 Apr 2003 03:41:45 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA05223 for ; Thu, 17 Apr 2003 03:41:40 -0700 (PDT) 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, 17 Apr 2003 10:41:39 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, 17 Apr 2003 10:41: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; Thu, 17 Apr 2003 10:41:39 Z Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 17 Apr 2003 10:41:37 Z Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h3HAf5311771; Thu, 17 Apr 2003 17:41:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3HAepL18881; Thu, 17 Apr 2003 17:40:59 +0700 (ICT) From: Robert Elz To: Thomas Narten cc: IPv6 Subject: Re: C000 In-Reply-To: <200304161122.h3GBM8w11244@cichlid.adsl.duke.edu> References: <200304161122.h3GBM8w11244@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Apr 2003 17:40:51 +0700 Message-Id: <18879.1050576051@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 16 Apr 2003 07:22:08 -0400 From: Thomas Narten Message-ID: <200304161122.h3GBM8w11244@cichlid.adsl.duke.edu> | In theory, the problems are similar, in practice, I think not. I.e., | the difficulties can be contained for LLs much more easily than with | SLs. | | Differences include: | | - LLs are useful for boostrapping; that is what people seem to say | they will be used for. That is one of their important uses. | Folk aren't arguing that LLs be used to keep connections stable | across renumbering, Aren't they? I thought that was exactly why BGP+ uses LL addresses over a tunnel for its peer-peer connectivity? I also see no reason that connections that are on a link shouldn't use LL addresses, even in preference to SL. Certainly if SL addresses go away that's what I'll be doing, there will be no other option, it will just offer much reduced functionality. Or course, the other option (I suppose) will be NATv6 and stable internal addressing (the same as is done now for v4). | or for numbering their internal links in a PI manner. Of course they are - but this is easy, as we get a prefix, and how we sub-divide it is irrelevant to the provider. That is, we already get PI stable internal numbering, so we don't have to deal with any of this. If you can make stable PI global addressing work, that will be fine, and better than SL addresses. Go for it. Just leave SL alone as it is until you're finished. It won't actually solve almost any of the hard problems that SL's (and LL's) create - unless your PI global addressing is also globally routable of course - that is, there will still be addresses that don't work, and will never work. Routing would get easier, but just abandoning multi-site nodes would achieve that (routing wins because LLs aren't routed, forwarding still needs to handle scoped addresses). | - LLs will almost certainly not be in the DNS, whereas SLs will (how | else can applications find them and use them?) SLs should certainly not be in the DNS (non-connected sites excepted). And there are ways. There's certainly no particular reason for putting a SL in the DNS that doesn't apply equally to LL addresses. It may be that LL will be less common (as long as SL remain) as there won't be as much need to ever know an LL address, but if SL goes away (before being replaced by something better of course), then LL will be the only stable addresses that remain, and I'd both expect, and actually use, the things in just the way I'm advocating that SL's be used (which in my case isn't in the DNS, but for others, might be). | - Using LLs as a last resort is generally fine; implementations can | almost pretend they don't exists unless there are no other addresses | (e.g., via address selection rules). But one of the goals people | have for SLs is that their usage is preferred over globals (when | possible). Yes. There are advantages to using LL's (in preference even to SL's) when they're applicable as well. I see no reason that shouldn't be done. | - Single link environments aren't going to be the norm, thus global | addresses will be needed to reach off-link destinations. In those | environments, LLs only need to be used in limited settings. I don't | see the desirably or need for a node being in multiple "sites", if | it only has LL addresses. What you've just said, once you translate it into the correct terminology is that you don't see a need for nodes to be connected to multiple links. Nonsense. And LL addresses still will be used, on nodes connected to multiple links (which is the LL equivalent of a node connected to multiple sites in the SL case). And applications need to deal with that. | It is the need to implement full multi-sitedness that brings the full | complexity into the picture. yes, it does. But that's already needed for multiple links, and LLs, and I don't think you can just wish those away. Nor do I take any notice of proclamations that "they're not meant to be used that way" - if they can be, they will be. | So far, the notion that one can get the | benefts of SL without also implying a need to implement the full | multi-sited node mode has been unconvincing. Your concept of what is a multi-site node seems to be deficient, based upon your analysis in the other message I just replied to. The true need for multi-site nodes is really very rare. While I have played with such things, just for fun, I have not yet seen a true operating environment where they're needed (but I also don't hang about exchange points, which was the motivation for including them). | Nodes/applications can treat LLs as if they were global addresses in | most cases without it causing a lot of problems. They don't need to | special case for them (except for applications that use LLs as part of | the protocol -- but that is a minimal set). Treating SLs as if they | were global will lead to things not working correctly in practice | (e.g, the multi-sited node example). This is utter nonsense. LL's are scoped addresses, with even more restricted scopes, than SL's. If you're willing to "just treat an LL as if it was a global" then you can most certainly do exactly the same to a SL address. That will cause far fewer problems. | Your model is different than the model others have and are pushing | when they say "keep SLs". Yes. | There are some who argue that an important | benefit of SLs is that they can keep connections stable across | renumbering events. That includes me. | That is largely at odds with the idea that only | apps that care about SLs will use them and or have to know about | them. Nonsense. Only apps that both use long time connections (ones that would expect to last at least as long as address overlap during a renumbering - which some people have said should be months, but even an hour is enough) and which can't easily recover from broken connections, care about address stability. That is, my web browser doesn't (other than perhaps if it keeps its proxy config using address to avoid DNS lookups for it every query, a topic on which I know nothing) - as web connections don't last for hours (more likel seconds, perhaps minutes). SMTP connections just the same - and if the connection does break, the SMTP client/server will simply retry (using the new addresses next time). On the other hand, I want my ssh sessions, my NFS mounts, etc, to remain viable for years. Those I don't want touched by address alterations (or not ones over which I have no direct control). Or, to put this another way, only ssh and NFS (and a few more like them) really need to deal with SL addresses, everything else can just use globals. | Or, what if you connect to a site that has SLs in the DNS (because | that is what the site has chosen to do)? Maybe the application never | wanted to deal with this case, bit it has no been forced to. And what if you want to connect to a site that has LLs in the DNS (because that is what the site has chosen to do)? Or in the IPv4 world, what if you connect to a site that has 1918 addresses in the DNS (because that is what the site has chosen to do)? Maybe the application never wanted to deal with this case, but it has no been forced to. So what? Things don't work if people put bad addresses in the DNS. Have you really never come across something that has 127.0.0.1 in the DNS and wondered why you couldn't connect to it? Try a connection to localhost.cs.mu.oz.au see what happens? I'd guess that localhost.xxx for lots of other xxx's would do just the same. It isn't SLs that cause this problem. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 17 11:39:49 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 h3HIdnmh002306; Thu, 17 Apr 2003 11:39:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3HIdnBV002305; Thu, 17 Apr 2003 11:39:49 -0700 (PDT) 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 h3HIdjmh002298 for ; Thu, 17 Apr 2003 11:39:45 -0700 (PDT) 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 h3HIdqvV028484 for ; Thu, 17 Apr 2003 11:39:52 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id MAA08629 for ; Thu, 17 Apr 2003 12:39:45 -0600 (MDT) 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, 17 Apr 2003 18:39: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, 17 Apr 2003 18:39: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, 17 Apr 2003 18:39:44 Z Received: from devil.pp.htv.fi ([213.243.180.132] [213.243.180.132]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 17 Apr 2003 18:39:43 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-2) with ESMTP id h3HIfC7o014454; Thu, 17 Apr 2003 21:41:13 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-2) id h3HIfBO5014453; Thu, 17 Apr 2003 21:41:11 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: C000 From: Mika Liljeberg To: Robert Elz Cc: IPv6 In-Reply-To: <18744.1050571098@munnari.OZ.AU> References: <1050445842.22244.576.camel@devil> <1050424546.22241.73.camel@devil> <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> <5998.1050398984@munnari.OZ.AU> <9519.1050432947@munnari.OZ.AU> <18744.1050571098@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050604871.2893.199.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Apr 2003 21:41:11 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2003-04-17 at 12:18, Robert Elz wrote: > Date: 16 Apr 2003 01:30:44 +0300 > From: Mika Liljeberg > Message-ID: <1050445842.22244.576.camel@devil> > > | The terminal gets an IP address from the gateway > | as part of the tunnel setup procedure (called PDP context activation). > | This means that, as soon as the terminal activates more than one packet > | data service, it automatically becomes multi-site (assuming the gateways > | for the services belong to different sites). > > Huh? I'm still mis-understanding something. Why would I want my terminal > (phone) to be a member of either (any) of the sites that are relevant to the > gateways? Well, as a subscriber you only get to choose whether you want to use particular services, such as "WAP", "Multimedia Messaging" or "Internet". Each of these "PDP contexts" is effectively a tunnel leading to a (potentially) different network. The terminal gets an IP address from each network. Some of these networks may use private addressing. I.e., a single host is either connected to multiple networks or connected to the same network in multiple points of the topology (or even both). I'm merely trying to explain how packet data services are organized in the 3GPP architecture. I'm not trying to defend the architecture itself (as I said, I'm probably not the right person for that). If you'd like to know more about the architecture, I refer you to www.3gpp.org. > | The mobile might also have access to circuit switched data services. Add > | to that VPN or a short range radio like Bluetooth or 802.11 and you have > > Sure, if I have a bunch of local attached devices, I'm likely to want all > of them, and the handset, to be in the same site. But I'm still not sure > why I'd want them to be in a site connected to any service provider. I wasn't talking about local attached devices. I'll give you an example. You can have constant wide-area wireless Internet connectivity via GPRS. Your operator charges by amount of transferred data, so you would also like to use 802.11 WLAN to connect to Internet whenever you're in a WLAN hotspot (to save money and to get better bandwidth). So, you have one (or more) addresses via your GPRS (3GPP) access, and an intermittent one via WLAN (changing depending on your point of attachment). > I suspect that you're assuming that all links have to be in some site or > other - they don't - siteless links are entirely possible (and in the IPv6 > world as it exists right now, are probably the most common around). You could argue that all siteless links of the same scope form a site amongst themselves. That's how it works out in the implementation, anyway. There's no special site zone id reserved for "siteless". 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 Apr 17 14:29: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 h3HLSxmh004009; Thu, 17 Apr 2003 14:28:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3HLSxjs004008; Thu, 17 Apr 2003 14:28:59 -0700 (PDT) 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 h3HLSumh004001 for ; Thu, 17 Apr 2003 14:28:56 -0700 (PDT) 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 h3HLT3vV015690 for ; Thu, 17 Apr 2003 14:29:03 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id OAA13556 for ; Thu, 17 Apr 2003 14:28:58 -0700 (PDT) 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, 17 Apr 2003 21:28: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; Thu, 17 Apr 2003 21:28:56 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, 17 Apr 2003 21:28:54 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, 17 Apr 2003 21:28:54 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 h3HLSqRP027694 for ; Thu, 17 Apr 2003 17:28:52 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-48.cisco.com [161.44.150.48]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA04999 for ; Thu, 17 Apr 2003 17:28:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20030417172210.06394ef0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 17 Apr 2003 17:28:48 -0400 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: WG last calls of potential interest to ipv6 WG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There are two WG last calls in progress in the dhc WG that might be of interest to members of the ipv6 WG: draft-ietf-dhc-dhcpv6-interop-01 - documentation of issues with the DHCPv6 specification discovered through interoperability testing at TAHI and Connectathon; these changes will be made to the DHCPv6 specification before publication as an RFC (see http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01999.html) draft-ietf-dhc-dhcpv6-stateless-00 - a guide to implementation of stateless DHCPv6; a host uses stateless DHCPv6 if it sees the 'O' bit set in an RA (see http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01997.html) Please respond to the dhc WG mailing list, dhcwg@ietf.org, if you have any comments on these drafts... - Ralph Droms -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 18 09:06: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 h3IG6omh006641; Fri, 18 Apr 2003 09:06:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IG6nv6006640; Fri, 18 Apr 2003 09:06:49 -0700 (PDT) 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 h3IG6emh006605 for ; Fri, 18 Apr 2003 09:06:40 -0700 (PDT) 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 h3IG6mvV026868 for ; Fri, 18 Apr 2003 09:06:48 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA07657 for ; Fri, 18 Apr 2003 10:06:42 -0600 (MDT) 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, 18 Apr 2003 16:06:42 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, 18 Apr 2003 16:06:42 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, 18 Apr 2003 16:06:37 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 16:06:36 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 18 Apr 2003 09:06:06 -0700 Reply-To: From: "Tony Hain" To: "'Keith Moore'" Cc: , , Subject: RE: FW: Consensus on Site-Local Addressing Date: Fri, 18 Apr 2003 09:05:57 -0700 Message-Id: <000b01c305c4$6a415020$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030411162416.41fa2ea1.moore@cs.utk.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > You must void the declaration of consensus, and should > recognize that > > the original question was not clear. > > Tony, > > that's absolute rubbish. the question was crystal clear. > different people may have had different reasons for the way > they made individual decisions, but that doesn't mean that > the question was ambiguous. It does when the individual reasons were for vastly different architectural concepts. In particular when one of the more popular reasons is about removing local scope from consideration. Declaring local scope to be deprecated has just as much affect on reality as declaring the earth to be flat, or that there will be an end to rain in Seattle. The filtering that local network managers do and will continue to do creates addresses with local scope. All the votes for removing local scope must be considered void. > > what should be recognized instead is that site-locals have > never been clearly defined - there were too many unsolved > problems with them that were written off by just handwaving. > once people took the trouble to enumerate the unsolved > problems, it became clear that they were unworkable. The real hand waving going on here are the BS claims that all problems will go away if we only get rid of the current SL definition. Particularly when it is recognized by many of the same people that we don't have a complete list of the requirements for a replacement. From what I can see, the current SL is the only approach that can meet a requirement for a site to have completely stable self-controled address space, and the routing community requirement that any non-PA mechanism have an absolutely enforceable mechanism to prevent that space from showing up in the global routing system. 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 Fri Apr 18 09:06: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 h3IG6smh006644; Fri, 18 Apr 2003 09:06:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IG6swL006643; Fri, 18 Apr 2003 09:06:54 -0700 (PDT) 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 h3IG6fmh006612 for ; Fri, 18 Apr 2003 09:06:41 -0700 (PDT) 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 h3IG6nvV026882 for ; Fri, 18 Apr 2003 09:06:50 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA07714 for ; Fri, 18 Apr 2003 10:06:44 -0600 (MDT) 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, 18 Apr 2003 16:06: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, 18 Apr 2003 16:06:42 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, 18 Apr 2003 16:06:37 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 16:06:36 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 18 Apr 2003 09:06:00 -0700 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , "'Robert Elz'" Cc: "'Thomas Narten'" , "'IPv6'" Subject: RE: C000 Date: Fri, 18 Apr 2003 09:05:57 -0700 Message-Id: <000901c305c4$66e46980$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5.1.0.14.2.20030415063621.014d5058@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3IG6gmh006613 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > ... > Applications should be able to treat all addresses that they > ever see as global addresses. ... Continuing to ignore the reality that filtering creates addresses with a local scope of applicability only insures that applications can't make a valid choice when confronted with a real network. The presumption that the scoped addressing document can proceed without discusssing local scope addresses is invalid because that would only present a wishful view of a flat network. Any document that ignores the most common case network is absolutely useless outside the IETF, and not worth publishing. 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 Fri Apr 18 09:07: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 h3IG6xmh006649; Fri, 18 Apr 2003 09:06:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IG6xEG006647; Fri, 18 Apr 2003 09:06:59 -0700 (PDT) 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 h3IG6imh006623 for ; Fri, 18 Apr 2003 09:06:44 -0700 (PDT) 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 h3IG6qvV026889 for ; Fri, 18 Apr 2003 09:06:52 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA20960 for ; Fri, 18 Apr 2003 10:06:45 -0600 (MDT) 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, 18 Apr 2003 16:06:42 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, 18 Apr 2003 16:06:42 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, 18 Apr 2003 16:06:37 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 16:06:36 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 18 Apr 2003 09:05:59 -0700 Reply-To: From: "Tony Hain" To: "'Keith Moore'" Cc: , Subject: RE: C000 Date: Fri, 18 Apr 2003 09:05:57 -0700 Message-Id: <000701c305c4$66289390$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030411175305.57f7fc50.moore@cs.utk.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > ... > > Some applications might cope in the same way, but others > MUST NOT. It > > is inappropriate for a file mount of proprietary content to > suddenly > > traverse the Internet when the internal network partitions. > > No, it's inappropriate for an application to make assumptions > about the security properties of the links over which its > traffic will be routed. If the content is potentially > sensitive, the traffic should be encrypted by the application. So you have a magic solution to the key distribution problem? If not stop the FUD. > > > If we want to make progress, we need to task > > those motivated to get rid of the current SL with finding > alternatives > > first. Doing otherwise is irresponsible and will only stall IPv6 > > deployments. > > After several years of trying, the people who want to keep SL > have failed to meet the burden of demonstrating how it can > work reasonably. The shipping code would appear to show how it works. The fact that 'ignorant' apps have a problem when they blindly pass information outside its scope of relevance is not a problem caused by SL, nor are they resolved by attempts to remove SL. > Keeping SL under these circumstances is > irresponsible, a violation of our processes, and serves only > to ensure that IPv6 will be nearly useless. The violation of the process is an ill-considered attempt to declare an architecture that differs from the reality of the deployed network. > > > I have no doubt that simply having this debate will cause many to > > reconsider their rollout plans. > > it's entirely because of this debate that IPv6 might actually > become viable. Shipping code wouhd say otherwise. 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 Fri Apr 18 09:07: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 h3IG72mh006654; Fri, 18 Apr 2003 09:07:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IG72ut006653; Fri, 18 Apr 2003 09:07:02 -0700 (PDT) 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 h3IG6kmh006633 for ; Fri, 18 Apr 2003 09:06:46 -0700 (PDT) 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 h3IG6svV026902 for ; Fri, 18 Apr 2003 09:06:55 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA20957 for ; Fri, 18 Apr 2003 10:06:44 -0600 (MDT) 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, 18 Apr 2003 16:06:42 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, 18 Apr 2003 16:06:42 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, 18 Apr 2003 16:06:37 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 16:06:36 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 18 Apr 2003 09:05:59 -0700 Reply-To: From: "Tony Hain" To: "'IPv6'" Subject: RE: C000 Date: Fri, 18 Apr 2003 09:05:57 -0700 Message-Id: <000801c305c4$666a5780$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <18879.1050576051@munnari.OZ.AU> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3IG6lmh006634 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > ... > It isn't SLs that cause this problem. You are right, it is the mismatch of the fantisy of a single scope address space, confronted with the reality of the deployed network which creates limited scope addresses through filtering. 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 Fri Apr 18 09:07: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 h3IG70mh006651; Fri, 18 Apr 2003 09:07:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IG6xlJ006648; Fri, 18 Apr 2003 09:06:59 -0700 (PDT) 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 h3IG6hmh006619 for ; Fri, 18 Apr 2003 09:06:43 -0700 (PDT) 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 h3IG6pcU016877 for ; Fri, 18 Apr 2003 09:06:51 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA00221 for ; Fri, 18 Apr 2003 10:06:45 -0600 (MDT) 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, 18 Apr 2003 16:06: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, 18 Apr 2003 16:06: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; Fri, 18 Apr 2003 16:06:37 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 16:06:36 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 18 Apr 2003 09:06:05 -0700 Reply-To: From: "Tony Hain" To: "'Erik Nordmark'" Cc: "'Fred L. Templin'" , "'Michel Py'" , Subject: RE: Consensus on Site-Local Addressing Date: Fri, 18 Apr 2003 09:05:57 -0700 Message-Id: <000a01c305c4$69d80700$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3IG6hmh006620 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > > See draft-hain-ipv6-sitelocal-00.txt, the research ship > example as one > > real case where a multi-subnet network intermittently attaches to > > different providers. Other vehicle types (airplanes in particular) > > already have multiple subnets, and will attach to different > providers > > over time. > > Tony, > > I stated some disagreement with the research ship example > being a case where site-locals would help on April 4th. Email > included below since I didn't find a http archive for the > list which provides URLs for each email. > > I didn't see a response from you. Sorry, I missed it. > > Erik > > > >----- Begin Included Message -----< > > Date: Fri, 4 Apr 2003 13:38:28 +0200 (CEST) > From: "Erik Nordmark" > Subject: RE: site-locals > To: alh-ietf@tndh.net > Cc: "'Erik Nordmark'" , > john.loughney@nokia.com, lear@cisco.com, ipng@sunroof.eng.sun.com > > > It is not a red herring. Input sent to me for the requirements doc: > > But this case is exactly the same as what I categorized as #1 > in my list - > isolating communication local to the site from site > renumbering. The only added twist is that site renumber > occurs when the site attaches and detaches from the Internet. To different service providers, so the ideas promoted about telling ISPs they must allocate the same space to a given network don't work. > > > Research ships at sea intermittently connect via INMARSAT, > or when in > > port, the shipboard network is connected to shore via Ethernet. > > Looking at your resarch ship case a bit more in detail it > occurs to me that even using site-locals plus globals while > connected doesn't necessarily protect the local > communication. The introduction of the > global prefix/addresses when the ship is connected might very > well trigger different address selection behaviors in the > stack or in the applications. Not if they follow the addr selection rules as currently written. > Thus it seems like the > robustness provided by site-locals only apply to > communication established (and addresses selected) before the > global prefix is introduced. Later communication is subject > to any bugs or poor interaction in the address selection > domain - something that is bound to have some corner cases > due to its complexity. (Note that this is a property that > applies to #1 in my list that I've previously not realized.) Bugs aside, if the 'smallest scope' rule is applied, there is no issue with protecting the local communication. > While the effect of this probably is less than the effect of > renumbering the ships network each time it attaches to the > Internet, it still doesn't isolate the ships internal network > from being attached to the Internet when site-locals are used > as you propose. I believe it does. > > So if I were to design this ship I'd use neiether renumbering > at attachment time nor site-locals. Instead I'd have the > research ship get a stable prefixe (a few /64's might > suffice) from the organization that runs > it which are globally unique and can be used whether the ship > is connected or disconnected. This completely isolates the > addressing of the ship internals > from whether it is connected or disconnected; the only > difference is the when disconnected off-ship destinations are > unreachable. When it gets connected > tunnel(s) need to be established back to the research > organization in order for routing to work. While tunnels are probably acceptable for bulk file transfer, I doubt anyone would accept it for interactive/VoIP use when the tunnel endpoint is halfway around the world. > Such tunnels could > be cobbled up today with some existing tunnel establishment > mechanism, and the Nemo WG is working on an IETF standard for > such tunnel establishment. So if you want internal stability > you have to pay by having less efficient routing - going > bidirectionally over the tunnel to "home" - no free lunch. I agree there is no free lunch, but there is no reason to drop the internal use prefix just because a renumbering event added a routable one. The cost is the complexity to keep straight which prefix is local use vs. routable (not too hard with a well known prefix, but still possible with other tools to differentiate them). > > If you believe in Mobile IPv6 route optimization you might > also believe that the Nemo work can be extended to provide > route optimization to/from correspondent nodes in the > Internet at large (by reusing the MIPv6 approach). I > personally think the utility of this remains to be proven, > but if it is it would help with the routing inefficiencies > caused by routing. > > So once again, this is not a case where I think site-locals help. Site locals as currently defined are more efficient for this use than the alternatives. That does not mean it is the only approach, just that the simple 'must change addresses on connect' BS is completely invalid. Tony > > Erik > > > >----- End Included Message -----< > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 18 09:36: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 h3IGa1mh008092; Fri, 18 Apr 2003 09:36:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IGa1dY008091; Fri, 18 Apr 2003 09:36:01 -0700 (PDT) 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 h3IGZvmh008081 for ; Fri, 18 Apr 2003 09:35:57 -0700 (PDT) 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 h3IGa5vV006140 for ; Fri, 18 Apr 2003 09:36:05 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA04020 for ; Fri, 18 Apr 2003 10:36:00 -0600 (MDT) From: fred@cisco.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; Fri, 18 Apr 2003 16:35: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, 18 Apr 2003 16:32:05 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, 18 Apr 2003 16:35:59 Z Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 16:35:59 Z Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3IGZvmi003890 for ; Fri, 18 Apr 2003 09:35:58 -0700 (PDT) Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA04860 for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 09:35:57 -0700 (PDT) Date: Fri, 18 Apr 2003 09:35:57 -0700 (PDT) Message-Id: <200304181635.JAA04860@irp-view7.cisco.com> To: ipng@sunroof.eng.sun.com Subject: Operational Renumbering Procedure Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd be interested in your comments on http://www.ietf.org/internet-drafts/draft-baker-ipv6-renumber-procedure-00.txt. This document grew out of a brief exchange on the IETF list, and an internal exchange with some operations folks at Cisco. What I'm trying to explore in the document is why some people say "renumbering is easy" and others say "renumbering is next to impossible" - the latter often with expletives added for color. We get a whine from various and sundry saying "please make renumbering easy to do", but we aren't especially told what to make easy. It turns out that operationally, the best thing we can do to make renumbering easy is make manual configuration really hard. It is the cases of manual configuration - things that are not automated in the first place - that are hard to automate. I'll take direction on what to do with the draft. I have had one network operator (who has to renumber an IPv4 network) tell me that the procedure is of value to him a it gives him a step in defining things. So it may be of value as an informational document. But for me, the real value lies in helping the IPv6 and the operational communities talk with each other. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 18 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 h3IGbpmh008119; Fri, 18 Apr 2003 09:37:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IGbpbM008118; Fri, 18 Apr 2003 09:37:51 -0700 (PDT) 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 h3IGblmh008111 for ; Fri, 18 Apr 2003 09:37:47 -0700 (PDT) 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 h3IGbtvV006586 for ; Fri, 18 Apr 2003 09:37:55 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA03430 for ; Fri, 18 Apr 2003 10:37:49 -0600 (MDT) 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, 18 Apr 2003 16:37: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; Fri, 18 Apr 2003 16:37:48 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, 18 Apr 2003 16:37:48 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, 18 Apr 2003 16:37:48 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA29446; Fri, 18 Apr 2003 09:36:52 -0700 (PDT) Message-Id: <5.1.0.14.2.20030418123149.045125b8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Apr 2003 12:34:37 -0400 To: From: Margaret Wasserman Subject: RE: C000 Cc: "'Robert Elz'" , "'Thomas Narten'" , "'IPv6'" In-Reply-To: <000901c305c4$66e46980$261e4104@eagleswings> References: <5.1.0.14.2.20030415063621.014d5058@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 At 09:05 AM 4/18/2003 -0700, Tony Hain wrote: >Margaret Wasserman wrote: > > ... > > Applications should be able to treat all addresses that they > > ever see as global addresses. ... > >Continuing to ignore the reality that filtering creates addresses with a >local scope of applicability only insures that applications can't make a >valid choice when confronted with a real network. No... I am accepting the fact that any address (whether it appears to be global or local) may be unreachable, so applications already need to deal appropriately with unreachable global addresses. You seem to be ignoring the fact that firewalls will be used to filter address/port combinations for all addresses, so we can't guarantee that an address is global reachable, just because we know it is a global address. And, just because you know that you can reach a particular address at one port, doesn't indicate that you can reach it at another. 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 Fri Apr 18 10:17: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 h3IHHZmh009157; Fri, 18 Apr 2003 10:17:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IHHZBn009156; Fri, 18 Apr 2003 10:17:35 -0700 (PDT) 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 h3IHHWmh009149 for ; Fri, 18 Apr 2003 10:17:32 -0700 (PDT) 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 h3IHHevV018084 for ; Fri, 18 Apr 2003 10:17:40 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA14279 for ; Fri, 18 Apr 2003 11:17:34 -0600 (MDT) 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, 18 Apr 2003 17:17: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; Fri, 18 Apr 2003 17:17: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; Fri, 18 Apr 2003 17:17:24 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, 18 Apr 2003 17:17:23 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA27319 for ; Fri, 18 Apr 2003 10:16:51 -0700 (PDT) Message-Id: <5.1.0.14.2.20030418125134.044cf220@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Apr 2003 13:05:30 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Chairs Vacation Schedule Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, We wanted to let you know about our upcoming vacations. Margaret Wasserman will going on vacation with her family on Saturday, April 19th, returning to work on Monday, April 28th. Bob Hinden will also be taking a vacation next week, starting on Wednesday, April 23rd and returning on Monday, the 28th. Neither of us will be reading mail during our vacations, but we will catch up on the IPv6 mailing list as soon as possible after we return. Although it is hard to imagine an IPv6 WG emergency that would require our immediate attention, Thomas Narten has agreed to cover for us during the overlap. So please contact Thomas (narten@us.ibm.com) if any pressing IPv6 WG emergencies do manage to occur while we are both away. Thanks, Bob Hinden & Margaret Wasserman IPv6 WG Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 18 10: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 h3IHrgmh009561; Fri, 18 Apr 2003 10:53:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IHrgQT009560; Fri, 18 Apr 2003 10:53:42 -0700 (PDT) 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 h3IHrcmh009553 for ; Fri, 18 Apr 2003 10:53:38 -0700 (PDT) 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 h3IHrkvV027385 for ; Fri, 18 Apr 2003 10:53:46 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA05677 for ; Fri, 18 Apr 2003 11:53:41 -0600 (MDT) 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, 18 Apr 2003 17:53:40 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, 18 Apr 2003 17:53: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; Fri, 18 Apr 2003 17:53:40 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; Fri, 18 Apr 2003 17:53:39 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3IHragE006464; Fri, 18 Apr 2003 10:53:36 -0700 (PDT) Received: from cisco.com (sjc-vpn4-504.cisco.com [10.21.81.248]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA08681; Fri, 18 Apr 2003 10:53:34 -0700 (PDT) Message-Id: <3EA03B9E.7090008@cisco.com> Date: Fri, 18 Apr 2003 10:53:34 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'Keith Moore'" , hinden@iprg.nokia.com, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: FW: Consensus on Site-Local Addressing References: <000b01c305c4$6a415020$261e4104@eagleswings> In-Reply-To: <000b01c305c4$6a415020$261e4104@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: > It does when the individual reasons were for vastly different > architectural concepts. In particular when one of the more popular > reasons is about removing local scope from consideration. Declaring > local scope to be deprecated has just as much affect on reality as > declaring the earth to be flat, or that there will be an end to rain in > Seattle. The filtering that local network managers do and will continue > to do creates addresses with local scope. All the votes for removing > local scope must be considered void. This statement is false on its face. Much of the filtering network managers do has nothing whatsoever to do with IP addresses and has to do with interfaces and ports. Certainly any network manager that filters on source address is asking for a snoot full of trouble. Network managers that filter on destination address do so with an interface in mind. And in general even if they filter on destination address they ALSO filter on part. Like it or not, that's the real world. 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 Apr 18 10:55:30 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 h3IHtTmh009578; Fri, 18 Apr 2003 10:55:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IHtTaQ009577; Fri, 18 Apr 2003 10:55:29 -0700 (PDT) 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 h3IHtOmh009570 for ; Fri, 18 Apr 2003 10:55:24 -0700 (PDT) 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 h3IHtWcU018434 for ; Fri, 18 Apr 2003 10:55:32 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA12867 for ; Fri, 18 Apr 2003 11:55:27 -0600 (MDT) 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, 18 Apr 2003 17:55: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; Fri, 18 Apr 2003 17:55: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; Fri, 18 Apr 2003 17:55:13 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 17:55:12 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3IHt0v23333; Fri, 18 Apr 2003 13:55:02 -0400 (EDT) Date: Fri, 18 Apr 2003 13:55:00 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, hinden@iprg.nokia.com, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: FW: Consensus on Site-Local Addressing Message-Id: <20030418135500.55d5dd19.moore@cs.utk.edu> In-Reply-To: <000b01c305c4$6a415020$261e4104@eagleswings> References: <20030411162416.41fa2ea1.moore@cs.utk.edu> <000b01c305c4$6a415020$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > All the votes for removing local scope must be considered void. In other words, whatever you think means more than what the clear consensus of the group thinks. > > what should be recognized instead is that site-locals have > > never been clearly defined - there were too many unsolved > > problems with them that were written off by just handwaving. > > once people took the trouble to enumerate the unsolved > > problems, it became clear that they were unworkable. > > The real hand waving going on here are the BS claims that all problems > will go away if we only get rid of the current SL definition. we already know what that world is like from experience with IPv4. It doesn't solve all problems, but introduction of scoped addresses causes far more problems than it solves. 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 Fri Apr 18 11:13: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 h3IID8mh010232; Fri, 18 Apr 2003 11:13:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IID8sP010231; Fri, 18 Apr 2003 11:13:08 -0700 (PDT) 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 h3IID4mh010224 for ; Fri, 18 Apr 2003 11:13:04 -0700 (PDT) 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 h3IIDBcU023730 for ; Fri, 18 Apr 2003 11:13:12 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA16944 for ; Fri, 18 Apr 2003 12:13:06 -0600 (MDT) 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, 18 Apr 2003 18:10: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; Fri, 18 Apr 2003 18:10: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; Fri, 18 Apr 2003 18:10:15 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 18:10:15 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3IIA8v23354; Fri, 18 Apr 2003 14:10:08 -0400 (EDT) Date: Fri, 18 Apr 2003 14:10:08 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, charliep@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: C000 Message-Id: <20030418141008.04d70063.moore@cs.utk.edu> In-Reply-To: <000701c305c4$66289390$261e4104@eagleswings> References: <20030411175305.57f7fc50.moore@cs.utk.edu> <000701c305c4$66289390$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > No, it's inappropriate for an application to make assumptions > > about the security properties of the links over which its > > traffic will be routed. If the content is potentially > > sensitive, the traffic should be encrypted by the application. > > So you have a magic solution to the key distribution problem? If not > stop the FUD. even unsecured Diffie-Hellman would be more secure than trusting a network of any significant size to be physically secure and expecting apps to be aware of that aspect of the topology. and if you look for a single solution to key distribution, of course you'll never find one. different applications and different sites have widely different needs. but for the vast majority of cases off the shelf solutions are available that are both more flexible and more reliable than what you are proposing. > > After several years of trying, the people who want to keep SL > > have failed to meet the burden of demonstrating how it can > > work reasonably. > > The shipping code would appear to show how it works. where in the world did you get the idea that the fact that something is shipping means that it works well? or for that matter, the idea that "if our apps work, then the network must be okay" from Microsoft? > The fact that > 'ignorant' apps have a problem when they blindly pass information > outside its scope of relevance is not a problem caused by SL, nor are > they resolved by attempts to remove SL. SL creates a myriad of problems. Trying to claim that they're someone else's problems is disingeneous. The people who have to deal with the problems you're trying to foist on them are now telling you where to stick those problems. Hint: it's not in the IPv6 architecture. > The violation of the process is an ill-considered attempt to declare > an architecture that differs from the reality of the deployed network. the only process violation that has occured was allowing IPv6 to go to Proposed with site-locals in the first place, when we knew or should have known that there were serious technical omissions with respect to scoped addresses. but finally we're getting around to fixing that. > > it's entirely because of this debate that IPv6 might actually > > become viable. > > Shipping code wouhd say otherwise. the amount of code that is shipping now is a drop in the bucket. 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 Fri Apr 18 11:38: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 h3IIcimh010691; Fri, 18 Apr 2003 11:38:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IIciHQ010690; Fri, 18 Apr 2003 11:38:44 -0700 (PDT) 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 h3IIcemh010683 for ; Fri, 18 Apr 2003 11:38:40 -0700 (PDT) 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 h3IIcmcU001370 for ; Fri, 18 Apr 2003 11:38:48 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA03141 for ; Fri, 18 Apr 2003 12:38:43 -0600 (MDT) 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, 18 Apr 2003 18:38: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, 18 Apr 2003 18:34: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; Fri, 18 Apr 2003 18:38:42 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 18:38:41 Z Subject: RE: FW: Consensus on Site-Local Addressing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 2003 11:38:40 -0700 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504575C@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: FW: Consensus on Site-Local Addressing Thread-Index: AcMF1D971Y4/KtPpRGWL4AwmOqVsbAABSvAg From: "Michel Py" To: "Eliot Lear" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3IIcfmh010684 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Eliot Lear wrote: > Much of the filtering network managers do has nothing > whatsoever to do with IP addresses and has to do with > interfaces and ports. This is not the reality I see everyday in the trenches. 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 Apr 18 13:11:30 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 h3IKBUmh011143; Fri, 18 Apr 2003 13:11:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IKBUGA011142; Fri, 18 Apr 2003 13:11:30 -0700 (PDT) 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 h3IKBRmh011135 for ; Fri, 18 Apr 2003 13:11:27 -0700 (PDT) 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 h3IKBZvV003632 for ; Fri, 18 Apr 2003 13:11:35 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA08397 for ; Fri, 18 Apr 2003 13:11:29 -0700 (PDT) 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, 18 Apr 2003 20:11: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; Fri, 18 Apr 2003 20:11: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; Fri, 18 Apr 2003 20:11:29 Z Received: from fuchsia.home ([203.146.155.24] [203.146.155.24]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 20:11:25 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3IKAlYM010459; Sat, 19 Apr 2003 03:10:49 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3IK8dj01436; Sat, 19 Apr 2003 03:08:39 +0700 (ICT) From: Robert Elz To: Mika Liljeberg cc: IPv6 Subject: Re: C000 In-Reply-To: <1050604871.2893.199.camel@devil> References: <1050604871.2893.199.camel@devil> <1050445842.22244.576.camel@devil> <1050424546.22241.73.camel@devil> <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> <5998.1050398984@munnari.OZ.AU> <9519.1050432947@munnari.OZ.AU> <18744.1050571098@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Apr 2003 03:08:39 +0700 Message-Id: <1434.1050696519@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 17 Apr 2003 21:41:11 +0300 From: Mika Liljeberg Message-ID: <1050604871.2893.199.camel@devil> | Well, as a subscriber you only get to choose whether you want to use | particular services, such as "WAP", "Multimedia Messaging" or | "Internet". Each of these "PDP contexts" is effectively a tunnel leading | to a (potentially) different network. The terminal gets an IP address | from each network. Some of these networks may use private addressing. All this is fine. But why would my node want to be in the same site as any of those? Once again, sites are administrative things, you're only in one when you want to be. (In this case, as an embedded device, I assume the handset manufacturer would be making that decision for me, and while they could decide to implement a multi-site node, and make the handset be a member of all of those sites, I can't think of any reason they'd bother, and I as a consumer certainly wouldn't feel short changed if they don't.) | I wasn't talking about local attached devices. OK, I misunderstood (this really isn't my area...) | So, you have one (or more) addresses via your GPRS (3GPP) access, and an | intermittent one via WLAN (changing depending on your point of | attachment). Sure, but they're just service providers, they have their sites for their nodes, and I have mine for my nodes, why would we want to mingle? | You could argue that all siteless links of the same scope form a site | amongst themselves. That's how it works out in the implementation, | anyway. There's no special site zone id reserved for "siteless". Hmm... I wouldn't have replied at all to your message (nothing I have said above is really very important or new) - but it seems to me that this is a very important point. I had a similar (brief) exchange off line with Erik Nordmark on this general issue (off-line because of stupid mailer issues which contrived to delete the list address from one of my messages, not intentionally). But this seems in some way to be important when considering site local, and it is something that I had never considered, and perhaps which does need to be considered. It seems that there's some expectation out there that (assuming site local addressing remains) every link is a member of some site or other. I have no idea where that comes from, nothing I have ever read suggests that to me. Site local addresses are a prefix like any other, if you don't have a site local address (on an interface) then you're not a member of any site (on that interface) is the way I interpret things. This is just like global prefixes - if you don't have a global prefix (on some interface) then you're not a member of that network (the network of all nodes with the same prefix - of whatever prefix length is being considered). Regardless of site local staying in the architecture or not, no-one is or could be compelled to use site local addressing, or to form a site. Links that aren't members of any sites I expect to be very common (whether they're the majority of links, or just common between sites doesn't matter, but common they're likely to be). It may be that this should be clarified in the architecture. Note that there doesn't need to be a special scope id for "no site", if there's no site local address (on an interface) that interface is not in any site. Normal practice, of course, will be for routers to advertise site local prefixes in RA's just as they do global prefixes, and for nodes to auto-configure site local addresses, just as they do globals, so the usual thing would be for all the nodes attached to a lan to be in a site, but with no expectation that would be enforced anyhow (I ought to be able to take my portable system to some random net, connect, get a global prefix, but ignore site local, because of not intending to ever be a part of that site). I'm not sure how much this alters anyone's perceptions of site local usage, but I am surprised to see people believing that a "site" is something that everything is required to be in - I'd certainly like to know from where that perception arises. kre necess -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 18 14:52:15 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 h3ILqFmh011686; Fri, 18 Apr 2003 14:52:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3ILqFuw011685; Fri, 18 Apr 2003 14:52:15 -0700 (PDT) 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 h3ILqBmh011678 for ; Fri, 18 Apr 2003 14:52:11 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3ILqJ4B000591 for ; Fri, 18 Apr 2003 14:52:19 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA01283 for ; Fri, 18 Apr 2003 15:52:14 -0600 (MDT) 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, 18 Apr 2003 21:52: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; Fri, 18 Apr 2003 21:52:14 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, 18 Apr 2003 21:52:13 Z Received: from devil.pp.htv.fi ([213.243.180.132] [213.243.180.132]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 21:52:12 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h3ILrnIt023438; Sat, 19 Apr 2003 00:53:49 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h3ILrmN1023437; Sat, 19 Apr 2003 00:53:48 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: C000 From: Mika Liljeberg To: Robert Elz Cc: IPv6 In-Reply-To: <1434.1050696519@munnari.OZ.AU> References: <1050604871.2893.199.camel@devil> <1050445842.22244.576.camel@devil> <1050424546.22241.73.camel@devil> <200304141310.h3EDAVbE021951@rotala.raleigh.ibm.com> <5998.1050398984@munnari.OZ.AU> <9519.1050432947@munnari.OZ.AU> <18744.1050571098@munnari.OZ.AU> <1434.1050696519@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1050702827.21809.70.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 19 Apr 2003 00:53:48 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 2003-04-18 at 23:08, Robert Elz wrote: > Site local addresses are a prefix like any other, if you don't have a site > local address (on an interface) then you're not a member of any site (on > that interface) is the way I interpret things. I think that you just have a fairly narrow definition of what the term "site" means. I was using "site" loosely to refer to an administrative domain that might naturally (although not necessarily) map to a single zone of site-local scope, if the network administrator chose to use site-local addressing. I think most people can envision a "site" without involving site-local addressing. My apologies if my inexact use of the language confuses people. > This is just like global prefixes - if you don't have a global prefix (on > some interface) then you're not a member of that network (the network of all > nodes with the same prefix - of whatever prefix length is being considered). This is true for host interfaces but not necessarily router interfaces. > Note that there doesn't need to be a special scope id for "no site", if > there's no site local address (on an interface) that interface is not in > any site. Let's be careful here. A link belongs to a site if it carries packets with site local addresses. That doesn't mean the link has to have a site-local prefix for address auto-configuration. > Normal practice, of course, will be for routers to advertise site local > prefixes in RA's just as they do global prefixes, and for nodes to > auto-configure site local addresses, just as they do globals, so the usual > thing would be for all the nodes attached to a lan to be in a site, but > with no expectation that would be enforced anyhow (I ought to be able to > take my portable system to some random net, connect, get a global prefix, > but ignore site local, because of not intending to ever be a part of that > site). Yes, fine. In the 3GPP example, you become part of a site by the concious decision to use a particular service. This implies activating the relavant PDP context and configuring the addresses that are advertised. As a user of a phone, you generally don't get to pick and choose which prefixes you accept. > I'm not sure how much this alters anyone's perceptions of site local > usage, but I am surprised to see people believing that a "site" is something > that everything is required to be in - I'd certainly like to know from > where that perception arises. I never envisioned everyone using site-local addressing, but I've been using the term "site" long before there ever was site-local addressing and I certainly don't limit the word to that context. As I said in my first message, whether any of those 3GPP services will actually use site-local addressing is another matter, but probably some of them will. 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 Fri Apr 18 15:12:59 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 h3IMCwmh012056; Fri, 18 Apr 2003 15:12:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3IMCw4w012055; Fri, 18 Apr 2003 15:12:58 -0700 (PDT) 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 h3IMCtmh012048 for ; Fri, 18 Apr 2003 15:12:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3IMD3Hh002840 for ; Fri, 18 Apr 2003 15:13:03 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id QAA03345 for ; Fri, 18 Apr 2003 16:12:56 -0600 (MDT) 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, 18 Apr 2003 22:12: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, 18 Apr 2003 22:09: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; Fri, 18 Apr 2003 22:12:55 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 22:12:55 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 18 Apr 2003 15:12:53 -0700 Reply-To: From: "Tony Hain" To: Cc: Subject: A simple question Date: Fri, 18 Apr 2003 15:12:54 -0700 Message-Id: <001a01c305f7$a902cd60$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030418135500.55d5dd19.moore@cs.utk.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > It doesn't solve all problems, but introduction of > scoped addresses causes far more problems than it solves. I would like to understand how many people that voted YES on the question of deprecating SL concur with Keith's assertion. Tony Note: I cc'd the IETF list to catch those who may have been in the room in SF, but aren't on the IPv6 list. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 18 16:54:53 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 h3INsrmh012535; Fri, 18 Apr 2003 16:54:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3INsrsU012534; Fri, 18 Apr 2003 16:54:53 -0700 (PDT) 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 h3INsnmh012524 for ; Fri, 18 Apr 2003 16:54:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3INsvHh026905 for ; Fri, 18 Apr 2003 16:54:57 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id RAA06094 for ; Fri, 18 Apr 2003 17:54:50 -0600 (MDT) 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, 18 Apr 2003 23:54:49 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, 18 Apr 2003 23:54: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; Fri, 18 Apr 2003 23:54:48 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 18 Apr 2003 23:54:47 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 18 Apr 2003 16:54:44 -0700 Reply-To: From: "Tony Hain" To: "'Dave Crocker'" Cc: , Subject: RE: A simple question Date: Fri, 18 Apr 2003 16:54:43 -0700 Message-Id: <002401c30605$e22da070$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <036939506.20030418161216@brandenburg.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Crocker wrote: > let me turn it around: Not at this time. I am looking for a simple yes/no answer to a simple question: How many people that voted YES on the question of deprecating SL concur with Keith's assertion. KM> It doesn't solve all problems, but introduction of KM> scoped addresses causes far more problems than it solves. 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 Apr 21 11:12: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 h3LICpZ5000774; Mon, 21 Apr 2003 11:12:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LICopv000771; Mon, 21 Apr 2003 11:12:50 -0700 (PDT) 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 h3LICPZ7000707 for ; Mon, 21 Apr 2003 11:12:26 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JMEawr012689 for ; Sat, 19 Apr 2003 15:14:36 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3JMEUrZ005784 for ; Sat, 19 Apr 2003 15:14:30 -0700 (PDT) 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, 19 Apr 2003 22:14: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; Sat, 19 Apr 2003 22:10:32 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, 19 Apr 2003 22:14:29 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 22:14:27 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3JME0L15116; Sat, 19 Apr 2003 17:14:00 -0500 Message-Id: <00d001c306c0$faeadf90$93b58742@ssprunk> From: "Stephen Sprunk" To: "Robert Elz" , Cc: "Dave Crocker" , , References: <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> Subject: Re: A simple question Date: Sat, 19 Apr 2003 17:13:55 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Robert Elz" > Is not true for site locals, as no-one anticpiates that a SL address is > all an enterprise will be using (unless it is not connected to the > internet, in which case questions of its flexibility of access don't arise). > > For internet access, a global address is used. Sites (and hosts) have > both. I had always planned on using only SL addresses within the enterprise, and then NATing those SLs to public addresses at the ISP. That way, none of the enterprise network is polluted with (frequently changing) global addresses -- just like common IPv4 practice today. To assign more than one address to every host means the host must have an intelligent means of deciding which address to use. I don't trust the hosts (either OS or the user) with that decision any more than I trust them with QOS. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 11:12: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 h3LICsZ5000779; Mon, 21 Apr 2003 11:12:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LICrHL000777; Mon, 21 Apr 2003 11:12:53 -0700 (PDT) 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 h3LICSZ7000729 for ; Mon, 21 Apr 2003 11:12:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3K0SAxn011031 for ; Sat, 19 Apr 2003 17:28:11 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id SAA24060 for ; Sat, 19 Apr 2003 18:28:05 -0600 (MDT) 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, 20 Apr 2003 00:28: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; Sun, 20 Apr 2003 00:28: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; Sun, 20 Apr 2003 00:28:04 Z Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 00:28:04 Z Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h3K0OdY06518; Sat, 19 Apr 2003 17:24:39 -0700 (PDT) From: Bill Manning Message-Id: <200304200024.h3K0OdY06518@boreas.isi.edu> Subject: Re: A simple question In-Reply-To: from Joe Abley at "Apr 19, 3 08:06:10 pm" To: jabley@isc.org (Joe Abley) Date: Sat, 19 Apr 2003 17:24:39 -0700 (PDT) Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org, ot@cisco.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 % >>> So, unless there's some routing revolution, you're just going to have % >>> to learn to deal with multiple addresses, and unless LL addresses go % >>> away, you're also going to have to deal with scoped addresses. % >> % >> LL use can and should be reserved for bootstrapping and diagnostics. % > % > LL is used in applications already. e.g LL addresses are commonly used % > to address BGP endpoints on exchanges. % % What exchanges do that? % % % Joe Akira Kato and I had a draft out on how this could be done and had working, inter-operable implementations (zebra, cisco) in two locations, NSPIXP3 and LAIIX. The IDR wg chose another method and so this technique is not likely to be widely endorsed as an IETF approved method. It is still supported in the code and some folks still use it. --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 Mon Apr 21 11:12: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 h3LICtZ5000782; Mon, 21 Apr 2003 11:12:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LICs6e000778; Mon, 21 Apr 2003 11:12:54 -0700 (PDT) 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 h3LICPZB000707 for ; Mon, 21 Apr 2003 11:12:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JLV8wr007909 for ; Sat, 19 Apr 2003 14:31:08 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id PAA26169 for ; Sat, 19 Apr 2003 15:31:01 -0600 (MDT) 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, 19 Apr 2003 21:30: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; Sat, 19 Apr 2003 21:26: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, 19 Apr 2003 21:30:55 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 21:30:55 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3JLUdL14331; Sat, 19 Apr 2003 16:30:40 -0500 Message-Id: <005401c306ba$ecdd5dc0$93b58742@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" , "Robert Elz" Cc: , , , References: <20030419151329.66daf0de.moore@cs.utk.edu><16890640984.20030419070719@brandenburg.com><002401c30605$e22da070$261e4104@eagleswings><9540645034.20030418171403@brandenburg.com><11870.1050777166@munnari.OZ.AU><14384.1050784134@munnari.OZ.AU> <20030419165921.782a8353.moore@cs.utk.edu> Subject: Re: A simple question Date: Sat, 19 Apr 2003 16:28:30 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Keith Moore" > > Nothing of the kind. 1918 addresses were created because there > > was demonstrated demand for stable local use only addressing. > > 1918 addresses were created because there was a need for isolated > networks to be able to get address space, and having them pick space > at random was believed to be problematic. Perhaps that's why we allocated those addresses, but that's not the most common usage anymore; IP networks not connected to the Internet have become vanishingly rare. Today, sizeable numbers -- perhaps even the majority -- of residential broadband and corporate users sit in RFC1918 space behind NATs. This is not a small mess you can wipe under the carpet and ignore. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 11:13: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 h3LID5Z5000807; Mon, 21 Apr 2003 11:13:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LID4O3000804; Mon, 21 Apr 2003 11:13:04 -0700 (PDT) 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 h3LICPZH000707 for ; Mon, 21 Apr 2003 11:12:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JLiEwr009392 for ; Sat, 19 Apr 2003 14:44:14 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3JLi8rZ000050 for ; Sat, 19 Apr 2003 14:44:09 -0700 (PDT) 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, 19 Apr 2003 21:44: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; Sat, 19 Apr 2003 21:44:08 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, 19 Apr 2003 21:44:08 Z Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 21:44:08 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 197078-0006vK-00; Sat, 19 Apr 2003 14:43:14 -0700 Date: Sat, 19 Apr 2003 17:42:56 -0400 From: Keith Moore To: "Stephen Sprunk" Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419174256.0036c5f7.moore@cs.utk.edu> In-Reply-To: <005401c306ba$ecdd5dc0$93b58742@ssprunk> References: <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14384.1050784134@munnari.OZ.AU> <20030419165921.782a8353.moore@cs.utk.edu> <005401c306ba$ecdd5dc0$93b58742@ssprunk> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > 1918 addresses were created because there was a need for isolated > > networks to be able to get address space, and having them pick space > > at random was believed to be problematic. > > Perhaps that's why we allocated those addresses, but that's not the most > common usage anymore; IP networks not connected to the Internet have become > vanishingly rare. so we should move 1918 to Historic. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 11:13: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 h3LID6Z5000809; Mon, 21 Apr 2003 11:13:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LID58E000805; Mon, 21 Apr 2003 11:13:05 -0700 (PDT) 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 h3LICPZD000707 for ; Mon, 21 Apr 2003 11:12:28 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JLhZwr009295 for ; Sat, 19 Apr 2003 14:43:35 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA21984 for ; Sat, 19 Apr 2003 15:43:29 -0600 (MDT) 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, 19 Apr 2003 21:43:29 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, 19 Apr 2003 21:43: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; Sat, 19 Apr 2003 21:43:28 Z Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 21:43:28 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19706Z-0001Tl-00; Sat, 19 Apr 2003 14:42:39 -0700 Date: Sat, 19 Apr 2003 17:42:21 -0400 From: Keith Moore To: Robert Elz Cc: moore@CS.UTK.EDU, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419174221.7111b542.moore@cs.utk.edu> In-Reply-To: <15314.1050787340@munnari.OZ.AU> References: <20030419165921.782a8353.moore@cs.utk.edu> <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14384.1050784134@munnari.OZ.AU> <15314.1050787340@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) 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 Sun, 20 Apr 2003 04:22:20 +0700 Robert Elz wrote: > Date: Sat, 19 Apr 2003 16:59:21 -0400 > From: Keith Moore > Message-ID: <20030419165921.782a8353.moore@cs.utk.edu> > > | 1918 addresses were created because there was a need for isolated > | networks to be able to get address space, and having them pick space > | at random was believed to be problematic. > > Yes, and nothing has changed. wrong. we know now that 1918 addresses created a big mess. and nothing about IPv6 use of SLs reduces that mess. > If you (and/or the WG as a whole) can come up with a replacement that is > better than site local, and meets the objectives, that's fine. Until then > don't destroy what we have now, which works now (as in, in in day to day use > now). no, you have it backwards. SLs destroy the utility of IPv6. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 11:12: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 h3LICoZ5000772; Mon, 21 Apr 2003 11:12:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LICois000769; Mon, 21 Apr 2003 11:12:50 -0700 (PDT) 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 h3LICPZ5000707 for ; Mon, 21 Apr 2003 11:12:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JLV3wr007891 for ; Sat, 19 Apr 2003 14:31:03 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA10334 for ; Sat, 19 Apr 2003 15:30:57 -0600 (MDT) 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, 19 Apr 2003 21:30: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; Sat, 19 Apr 2003 21:30:56 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, 19 Apr 2003 21:30:56 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 21:30:56 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3JLUcL14328; Sat, 19 Apr 2003 16:30:38 -0500 Message-Id: <005301c306ba$ec1775b0$93b58742@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" , "Robert Elz" Cc: , , , References: <16890640984.20030419070719@brandenburg.com><002401c30605$e22da070$261e4104@eagleswings><9540645034.20030418171403@brandenburg.com><11870.1050777166@munnari.OZ.AU> <20030419151329.66daf0de.moore@cs.utk.edu> Subject: Re: A simple question Date: Sat, 19 Apr 2003 16:13:48 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Keith Moore" > > | site local is, in fact, an addition to the IP architecture and > > | that is what is causing the controversy. > > > > No, it isn't. It is a cleaned up replacement for 1918 addresses. > > which by itself is reason enough to kill it. I detest NAT and private addresses nearly as much as you do, but the simple matter is that many, if not most, people are going to continue using these technologies with IPv6 whether the IETF standardizes it or not. Today, NAT is a solution to political and business problems, even if IPv6 fixes the technical problems NAT was originally invented to solve. The IETF cannot eliminate these political and business problems by fiat, nor can it prevent vendors from selling IPv6 NAT devices. You are fighting the good fight, but you will surely lose nonetheless. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 11:13:04 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 h3LID3Z5000803; Mon, 21 Apr 2003 11:13:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LID3sf000799; Mon, 21 Apr 2003 11:13:03 -0700 (PDT) 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 h3LICPZ9000707 for ; Mon, 21 Apr 2003 11:12:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JLSowr007599 for ; Sat, 19 Apr 2003 14:28:50 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA09764 for ; Sat, 19 Apr 2003 15:28:44 -0600 (MDT) 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, 19 Apr 2003 21:28: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; Sat, 19 Apr 2003 21:28: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; Sat, 19 Apr 2003 21:28:28 Z Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 21:28:28 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 196zru-0006T6-00; Sat, 19 Apr 2003 14:27:30 -0700 Date: Sat, 19 Apr 2003 17:27:13 -0400 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419172713.4c34e197.moore@cs.utk.edu> In-Reply-To: <14570.1050784897@munnari.OZ.AU> References: <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | Unbfortunately, I don't see where the biggest problems with 1918 > | addresses were cleaned up for site-local. > > Two aspects. First, they're clearly of local use (defined in the > architecture), hence if they do leak, at least it is obvious what is > happening. right. but the anticipated use was such that if 1918 addresses leaked, this would be treated as an indication of an error - namely that a non-isolated network was connected to the Internet - and that the correction would be to renumber the formerly isolated network. the intent of 1918 was to enable correction of the error of giving a non-isolated network non-unique address space, not to encourage that error to the point that it became common practice (as has happened). > | The problems with 1918 space were well understood at the time: > | > | A major drawback to the use of private address space is that it may > | actually reduce an enterprise's flexibility to access the Internet. > > Is not true for site locals, as no-one anticpiates that a SL address is > all an enterprise will be using (unless it is not connected to the > internet, in which case questions of its flexibility of access don't arise). on the contrary, having an enterprise use both SLs and globals creates significant new problems of its own, and results in even less flexibility than if SLs were used only by isolated networks. > Similarly: > > | Once one commits to using a private address, one is committing to > | renumber part or all of an enterprise, > > is not true of SL addresses, as one doesn't "renumber" them, one just > augments with a global address. this is a bug, not a feature. > You may notice that it isn't *just* site locals that provide the cleanup > here, it is the whole IPv6 architecture, considered as a whole. That > includes having multiple prefixes announced to nodes, multiple addresses at a node were available in IPv4, but the problems associated with doing this have never been solved, not even in IPv6. so while having multiple prefixes per node is clearly useful for renumbering, it's not at all clear that this is a "cleanup" to the IP architecture. it's more complexity that has to be dealt with. > | Another drawback to the use of private address space is that it may > | require renumbering when merging several private internets into a > | single private internet. > > This one was certainly true of the original site local ("may require"). > (Only may because it all depends on how the merge gets done, and the > actual subnet numbers). Now that site locals have been extended to use > fec0::/10 instead of fec0::/48 it is much less likely (but still not > impossible). depends on how subnets are allocated. my guess is that sites are more likely to allocate subnet bits from left to right, rather than allocating from the right and picking the leftmost subnet bits at random - so that collisions are still likely whenever sites merge. > No, this is exactly the kind of thing that was considered in the SL design. unfortunately, many important considerations were ignored in that design. 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 Mon Apr 21 12:03:14 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 h3LJ3DZ5002933; Mon, 21 Apr 2003 12:03:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJ3DqJ002932; Mon, 21 Apr 2003 12:03:13 -0700 (PDT) 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 h3LJ32Z5002907 for ; Mon, 21 Apr 2003 12:03:02 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JKmZ3K019485 for ; Sat, 19 Apr 2003 13:48:35 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3JKmTrZ020202 for ; Sat, 19 Apr 2003 13:48:29 -0700 (PDT) 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, 19 Apr 2003 20:48:29 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, 19 Apr 2003 20:48: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; Sat, 19 Apr 2003 20:48:29 Z Received: from fuchsia.home ([203.146.155.26] [203.146.155.26]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 20:48:26 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3JKljYI005790; Sun, 20 Apr 2003 03:47:45 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3JKfbs14572; Sun, 20 Apr 2003 03:41:41 +0700 (ICT) From: Robert Elz To: Valdis.Kletnieks@vt.edu cc: Dave Crocker , ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question In-Reply-To: <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> References: <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Apr 2003 03:41:37 +0700 Message-Id: <14570.1050784897@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 19 Apr 2003 15:23:23 -0400 From: Valdis.Kletnieks@vt.edu Message-ID: <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> | Unbfortunately, I don't see where the biggest problems with 1918 addresses | were cleaned up for site-local. Two aspects. First, they're clearly of local use (defined in the architecture), hence if they do leak, at least it is obvious what is happening. More importantly ... | The problems with 1918 space were well understood at the time: | | A major drawback to the use of private address space is that it may | actually reduce an enterprise's flexibility to access the Internet. Is not true for site locals, as no-one anticpiates that a SL address is all an enterprise will be using (unless it is not connected to the internet, in which case questions of its flexibility of access don't arise). For internet access, a global address is used. Sites (and hosts) have both. Similarly: | Once one commits to using a private address, one is committing to | renumber part or all of an enterprise, is not true of SL addresses, as one doesn't "renumber" them, one just augments with a global address. You may notice that it isn't *just* site locals that provide the cleanup here, it is the whole IPv6 architecture, considered as a whole. That includes having multiple prefixes announced to nodes, and the ability to seemlessly add new ones. | Another drawback to the use of private address space is that it may | require renumbering when merging several private internets into a | single private internet. This one was certainly true of the original site local ("may require"). (Only may because it all depends on how the merge gets done, and the actual subnet numbers). Now that site locals have been extended to use fec0::/10 instead of fec0::/48 it is much less likely (but still not impossible). Some kind of global assignment policy for those 38 bits would fix this, but adds the costs of managing such a scheme. | Unfortunately, people seem to want to forget about those two paragraphs. No, this is exactly the kind of thing that was considered in the SL design. | I'm afraid that unless site-local includes a 'MUST renumber' requirement | for *BOTH* cases, it's a complete and total non-starter in my book. IPv6 requires renumbering when an address that has been used is no longer appropriate (which will generally be because of changed topology, which may be local topology changes - moving a host to a different LAN, or global ones - connecting to a different provider). That is the only reason. As long as prefixes remain usable, they can keep on being used, with other prefixes added as required. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 21 12:03:18 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 h3LJ3IZ5002939; Mon, 21 Apr 2003 12:03:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJ3IId002938; Mon, 21 Apr 2003 12:03:18 -0700 (PDT) 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 h3LJ32Z7002907 for ; Mon, 21 Apr 2003 12:03:02 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JL0g3K020651 for ; Sat, 19 Apr 2003 14:00:42 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA22809 for ; Sat, 19 Apr 2003 15:00:37 -0600 (MDT) 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, 19 Apr 2003 21: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; Sat, 19 Apr 2003 21: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; Sat, 19 Apr 2003 21:00:36 Z Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 21:00:35 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 196zQx-0001CB-00; Sat, 19 Apr 2003 13:59:39 -0700 Date: Sat, 19 Apr 2003 16:59:21 -0400 From: Keith Moore To: Robert Elz Cc: moore@CS.UTK.EDU, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419165921.782a8353.moore@cs.utk.edu> In-Reply-To: <14384.1050784134@munnari.OZ.AU> References: <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14384.1050784134@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | > No, it isn't. It is a cleaned up replacement for 1918 addresses. > | which by itself is reason enough to kill it. > > Nothing of the kind. 1918 addresses were created because there was > demonstrated demand for stable local use only addressing. 1918 addresses were created because there was a need for isolated networks to be able to get address space, and having them pick space at random was believed to be problematic. > Nothing > has changed in the Internet to cause that demand to go away. what has changed is that we now have experience with RFC 1918, and we know now that it is far more of a mess than was anticipated. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 12:03:16 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 h3LJ3GZ5002936; Mon, 21 Apr 2003 12:03:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJ3G3Z002935; Mon, 21 Apr 2003 12:03:16 -0700 (PDT) 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 h3LJ32ZB002907 for ; Mon, 21 Apr 2003 12:03:03 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JLx83K026534 for ; Sat, 19 Apr 2003 14:59:08 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id OAA14948 for ; Sat, 19 Apr 2003 14:59:03 -0700 (PDT) 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, 19 Apr 2003 21:59: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; Sat, 19 Apr 2003 21:58: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; Sat, 19 Apr 2003 21:58:59 Z Received: from fuchsia.home ([203.146.155.29] [203.146.155.29]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 21:58:56 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3JLuoYI006515; Sun, 20 Apr 2003 04:56:50 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3JLnis15759; Sun, 20 Apr 2003 04:49:44 +0700 (ICT) From: Robert Elz To: Keith Moore cc: Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question In-Reply-To: <20030419172713.4c34e197.moore@cs.utk.edu> References: <20030419172713.4c34e197.moore@cs.utk.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Apr 2003 04:49:44 +0700 Message-Id: <15757.1050788984@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 19 Apr 2003 17:27:13 -0400 From: Keith Moore Message-ID: <20030419172713.4c34e197.moore@cs.utk.edu> | not to encourage that error to the point that it became common | practice (as has happened). Usage alters to meet the demands of the users. That's nothing new. | on the contrary, having an enterprise use both SLs and globals creates | significant new problems of its own, and results in even less flexibility | than if SLs were used only by isolated networks. Nothing that IPv4 doesn't have as well (if perhaps less commonly). | multiple addresses at a node were available in IPv4, but the problems | associated with doing this have never been solved, not even in IPv6. True. But it is still used regardless. There are unsolved problems should be a challenge, not something to fear. | so while having multiple prefixes per node is clearly useful for | renumbering, Yes - but more than that - as long as addresses reflect topology, multiple addresses are the only way to have multiple topological attachments, aren't they? This is seen both in a host that is connected to two LANS, and an organisation that has two ISPs. So, unless there's some routing revolution, you're just going to have to learn to deal with multiple addresses, and unless LL addresses go away, you're also going to have to deal with scoped addresses. | so that collisions are still likely whenever sites merge. I think I'd say possible, rather than likely. But of all the problems, this is the one that bothers me least - sites aren't required to merge after all (when that does get to be a requirement, it is likely that far more significant changes are made than just "let those two sites have unified site local addresses). After all, you want to abolish the things completely - if it would be acceptable to not have them (and do remember, no organisation is going to be compelled to use them) then worrying about how to unify if they do exist them can't be high on anyone's agenda can it? That is, merging site locals would only be an issue of site locals are actively being used - if they're useless, and problematic, as you're claiming, then surely people won't be using them (the "I can't get enough address space" excuse for using 1918 addresses won't exist after all). If no-one uses them, merging won't be a problem, and nor will any of the other issues you see, surely? So, if you're worried about this, then you must be assuming that they will in fact be used - which to me means, that you can see that there is actually a demand for something to solve the problems that (apparently) only SL addresses currently can do (that's obvious, as if there was some other available solution, then people would use that, rather than these problematic SL things, wouldn't they???) So... | unfortunately, many important considerations were ignored in that design. Let's see your design that handles the issues that you must agree that the users need solved, and which actually takes note of all of those other considerations. Until we have that, and agree that it is a better design, let's just agree that there really is no choice - we either keep SLs in the design (however far from absolute perfection that actually are) or the users will invent their own variations, in a thousand different ways - which I really can't believe that you consider a preferable answer. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 21 12:03: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 h3LJ3JZ5002942; Mon, 21 Apr 2003 12:03:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJ3JiA002941; Mon, 21 Apr 2003 12:03:19 -0700 (PDT) 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 h3LJ32Z9002907 for ; Mon, 21 Apr 2003 12:03:03 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JLfq3K024615 for ; Sat, 19 Apr 2003 14:41:52 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3JLflrZ029627 for ; Sat, 19 Apr 2003 14:41:47 -0700 (PDT) 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, 19 Apr 2003 21:41: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, 19 Apr 2003 21:41:46 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, 19 Apr 2003 21:41:46 Z Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 21:41:46 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19704o-0000bR-00; Sat, 19 Apr 2003 14:40:50 -0700 Date: Sat, 19 Apr 2003 17:40:32 -0400 From: Keith Moore To: "Stephen Sprunk" Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419174032.034ebf1d.moore@cs.utk.edu> In-Reply-To: <005301c306ba$ec1775b0$93b58742@ssprunk> References: <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <20030419151329.66daf0de.moore@cs.utk.edu> <005301c306ba$ec1775b0$93b58742@ssprunk> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I detest NAT and private addresses nearly as much as you do, but the simple > matter is that many, if not most, people are going to continue using these > technologies with IPv6 whether the IETF standardizes it or not. yawn. I'm tired of baseless assertions. many of the reasons for using NAT do not apply to IPv6. if you're going to use NAT, you may as well use IPv4. a big reason to move to IPv6 is to get away from the problems that are caused by NATted IPv4 networks. 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 Mon Apr 21 12:05:28 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 h3LJ5RZ5003039; Mon, 21 Apr 2003 12:05:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJ5QHp003035; Mon, 21 Apr 2003 12:05:26 -0700 (PDT) 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 h3LJ59Z5002997 for ; Mon, 21 Apr 2003 12:05:09 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3K0euxn012242 for ; Sat, 19 Apr 2003 17:40:57 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA01000 for ; Sat, 19 Apr 2003 18:40:49 -0600 (MDT) 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, 20 Apr 2003 00:40: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; Sun, 20 Apr 2003 00:40:48 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, 20 Apr 2003 00:40:48 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 00:40:43 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3K0cBL17288; Sat, 19 Apr 2003 19:38:11 -0500 Message-Id: <008e01c306d5$1f192c50$93b58742@ssprunk> From: "Stephen Sprunk" To: "Robert Elz" Cc: , References: <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> Subject: Re: A simple question Date: Sat, 19 Apr 2003 19:27:38 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Robert Elz" > | To assign more than one address to every host means the host must > | have an intelligent means of deciding which address to use. > > Yes, but the amount of intelligence actually needed is pretty minimal. > (It is actually harder to decide between multiple available global > prefixes, than to decide between global and site local - the former is > a difficult problem, the latter is almost trivial). Agreed. But the former is a problem nobody has solved after a couple decades' effort. Choosing a source address today is a problem only for dual-homed hosts, which are fairly rare; I see no compelling reason to bring this afflication to every IPv6 host until the problem is solved. > | I don't trust the hosts (either OS or the user) with that decision > | any more than I trust them with QOS. > > But you do trust them to select a suitable outgoing interface, to pick > a usable router, and to choose amongst several different possible > addresses for the destination (over which you most often have no > control). Most hosts have one interface, one source address, and one default gateway (or two that are equally valid). Recall the KISS principle. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 12:05:35 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 h3LJ5ZZ5003048; Mon, 21 Apr 2003 12:05:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJ5Y5x003047; Mon, 21 Apr 2003 12:05:34 -0700 (PDT) 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 h3LJ59Z9002997 for ; Mon, 21 Apr 2003 12:05:10 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JNQRxn005440 for ; Sat, 19 Apr 2003 16:26:27 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA15371 for ; Sat, 19 Apr 2003 17:26:21 -0600 (MDT) 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, 19 Apr 2003 23:21: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; Sat, 19 Apr 2003 23:17: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; Sat, 19 Apr 2003 23:21:38 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; Sat, 19 Apr 2003 23:21:35 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1971dS-0000dM-00; Sat, 19 Apr 2003 16:20:42 -0700 Date: Sat, 19 Apr 2003 19:20:24 -0400 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, stephen@sprunk.org, Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419192024.440d3773.moore@cs.utk.edu> In-Reply-To: <16762.1050792143@munnari.OZ.AU> References: <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | To assign more than one address to every host means the host must have > | an intelligent means of deciding which address to use. > > Yes, but the amount of intelligence actually needed is pretty minimal. > (It is actually harder to decide between multiple available global > prefixes, than to decide between global and site local - the former is > a difficult problem, the latter is almost trivial). disagree. the app can choose any global prefix and reasonably expect it to work, modulo link failures. but when choosing between a global and a site local the app needs to know whether the site local address will be valid for the hosts that need to use it, and it has no way to know this. the app may also have to choose which interface to use with the site-local prefix, and it has no good way to know this either. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 12:05: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 h3LJ5bZ5003054; Mon, 21 Apr 2003 12:05:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJ5aeY003050; Mon, 21 Apr 2003 12:05:36 -0700 (PDT) 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 h3LJ59ZB002997 for ; Mon, 21 Apr 2003 12:05:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JNGZxn004670 for ; Sat, 19 Apr 2003 16:16:35 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id RAA07206 for ; Sat, 19 Apr 2003 17:16:29 -0600 (MDT) 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, 19 Apr 2003 23:15:40 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, 19 Apr 2003 23:15: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; Sat, 19 Apr 2003 23:15:32 Z Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 23:15:32 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1971YL-0001C3-00; Sat, 19 Apr 2003 16:15:25 -0700 Date: Sat, 19 Apr 2003 19:15:07 -0400 From: Keith Moore To: Daniel Senie Cc: moore@cs.utk.edu, stephen@sprunk.org, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A simple question Message-Id: <20030419191507.75dfcc39.moore@cs.utk.edu> In-Reply-To: <5.2.1.1.2.20030419181122.0290c090@mail.amaranth.net> References: <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14384.1050784134@munnari.OZ.AU> <20030419165921.782a8353.moore@cs.utk.edu> <5.2.1.1.2.20030419181122.0290c090@mail.amaranth.net> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Site local addressing in IPv6 is a concept which has been > mentioned in RFC 1884, 2373 and 3513, the progression of Proposed > Standards. This is a string of documents dating back to 1995. For eight > years this concept was apparently considered a good thing. it is indeed unfortunate that it took several years before there was serious consideration to the impact of site-local on networks, DNS, and applications. I view this as an indication of serious failures in our process - IPv6 was approved (under pressure, it must be said) by the working group and IESG despite serious technical omissions. fortunately proposed standards are not carved in stone, and these particular omissions are easy to fix. > I'd like to know why it's taken eight years for folks to decide it's > bad. because few serious applications people were in the discussion, and there wasn't enough review by those people during Last Call. most apps people probably assumed that the changes between IPv4 and IPv6 would be transparent to them, other than having to use a different size for the address. also IPv6 took so long getting out the door that it was widely viewed as on a distant horizon - something that could be dealt with when it finally arrived (if that ever happened). > Is it that folks are just now implementing IPv6? no, but most of the early apps that were ported to IPv6 were two-party apps, often apps that were used in conjunction with either a v4-v6 translator or proxy. many problems with SLs don't show up for these apps; they show up for multi-party apps. also, even though there were v6 stacks there were probably not many early networks that made heavy use of both SLs and globals. > It is not unprecedented to change or remove a feature as a document > advances through the standards track. Such changes, however, can have > significant impact on already-implemented and deployed solutions. Such > matters should be considered carefully in that light. Perhaps removal of > features should receive substantially more scrutiny after publication on > the standards track. I don't disagree. but surely the months of discussion on this topic qualify as a substantial amount of scrutiny. and surely you'd agree that features in published documents that appear to cause problems should also receive a substantial amount of scrutiny before advancing those documents? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 12:05:30 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 h3LJ5TZ5003042; Mon, 21 Apr 2003 12:05:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJ5SHw003040; Mon, 21 Apr 2003 12:05:28 -0700 (PDT) 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 h3LJ59Z7002997 for ; Mon, 21 Apr 2003 12:05:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JMpGxn002511 for ; Sat, 19 Apr 2003 15:51:16 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA12422 for ; Sat, 19 Apr 2003 16:51:10 -0600 (MDT) 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, 19 Apr 2003 22:51:09 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, 19 Apr 2003 22:51: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; Sat, 19 Apr 2003 22:51:08 Z Received: from fuchsia.home ([203.146.155.29] [203.146.155.29]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 22:51:05 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3JMoKYI007107; Sun, 20 Apr 2003 05:50:20 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3JMgNs16764; Sun, 20 Apr 2003 05:42:26 +0700 (ICT) From: Robert Elz To: "Stephen Sprunk" cc: Valdis.Kletnieks@vt.edu, "Dave Crocker" , ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question In-Reply-To: <00d001c306c0$faeadf90$93b58742@ssprunk> References: <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Apr 2003 05:42:23 +0700 Message-Id: <16762.1050792143@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 19 Apr 2003 17:13:55 -0500 From: "Stephen Sprunk" Message-ID: <00d001c306c0$faeadf90$93b58742@ssprunk> | To assign more than one address to every host means the host must have an | intelligent means of deciding which address to use. Yes, but the amount of intelligence actually needed is pretty minimal. (It is actually harder to decide between multiple available global prefixes, than to decide between global and site local - the former is a difficult problem, the latter is almost trivial). | I don't trust the hosts (either OS or the user) with that decision | any more than I trust them with QOS. But you do trust them to select a suitable outgoing interface, to pick a usable router, and to choose amongst several different possible addresses for the destination (over which you most often have no control). This all seems rather arbitrary. Forcing NAT on hosts & users because you're afraid that the OS/app designers can't tell what's global and what is site local seems rather heavy handed. I'm sure glad I don't have to live with your policies. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 21 12:05: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 h3LJ5bZ5003058; Mon, 21 Apr 2003 12:05:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJ5ab0003051; Mon, 21 Apr 2003 12:05:36 -0700 (PDT) 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 h3LJ59ZD002997 for ; Mon, 21 Apr 2003 12:05:11 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3K0Rsxn011020 for ; Sat, 19 Apr 2003 17:27:54 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id SAA08555 for ; Sat, 19 Apr 2003 18:27:48 -0600 (MDT) 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, 20 Apr 2003 00:27: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; Sun, 20 Apr 2003 00:27:48 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, 20 Apr 2003 00:27:48 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; Sun, 20 Apr 2003 00:27:48 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1972fX-000164-00; Sat, 19 Apr 2003 17:26:55 -0700 Date: Sat, 19 Apr 2003 20:26:37 -0400 From: Keith Moore To: Ole Troan Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419202637.7828bb08.moore@cs.utk.edu> In-Reply-To: <7t5vfxa81p5.fsf@mrwint.cisco.com> References: <20030419172713.4c34e197.moore@cs.utk.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <15757.1050788984@munnari.OZ.AU> <20030419183555.2ce07295.moore@cs.utk.edu> <7t5y926844n.fsf@mrwint.cisco.com> <20030419200049.2b0dd5f2.moore@cs.utk.edu> <7t5vfxa81p5.fsf@mrwint.cisco.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I don't have a problem with LL being used for a few special-purpose things > > that can deal with it, so long as we don't expect LL to work for all or > > even most apps. > > that is a big change in the IPv6 architecture. anyone who ever thought that scoped addresses were generally applicable was deluded. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 12:20:42 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 h3LJKfZ5005169; Mon, 21 Apr 2003 12:20:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJKfut005164; Mon, 21 Apr 2003 12:20:41 -0700 (PDT) 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 h3LJKBZ9005076 for ; Mon, 21 Apr 2003 12:20:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JMV0xn000804 for ; Sat, 19 Apr 2003 15:31:00 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA13296 for ; Sat, 19 Apr 2003 16:30:54 -0600 (MDT) 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, 19 Apr 2003 22:30: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; Sat, 19 Apr 2003 22:30:54 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, 19 Apr 2003 22:30:54 Z Received: from fuchsia.home ([203.146.155.29] [203.146.155.29]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 22:30:51 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3JMUDYI006890; Sun, 20 Apr 2003 05:30:13 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3JMMbs16390; Sun, 20 Apr 2003 05:22:37 +0700 (ICT) From: Robert Elz To: Valdis.Kletnieks@vt.edu cc: Dave Crocker , ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question In-Reply-To: <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> References: <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Apr 2003 05:22:37 +0700 Message-Id: <16388.1050790957@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 19 Apr 2003 17:51:19 -0400 From: Valdis.Kletnieks@vt.edu Message-ID: <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> | So if it's expected that both global and site-local addresses are available, | why are we bothering with making things more complicated? Because we need stable addresses for local use. Something tells me you've never actually lived in an environment where your global address changes moderately frequently. If you had, you wouldn't be so quick to ignore this need. | That's exactly *why* they're broken - if you've suddenly had a global | address show up, there's now a danger of leaking a local address, so it's | not safe to use site-local anymore. What is the danger here, and why do I, the user, care? What I know is that I want me local communications to just keep on working smoothly, whatever happens to external connectivity and the addresses I get from there. | Well.. all you need to do to fix this is to make a rule that if a | global prefix becomes available, the site-local prefix is no longer | appropriate and must be withdrawn. Can't possibly work. | This *still* leaves the problem of using site-local behind a NAT, though. First, while I can imagine people existing who would be stupid enough to do that, I find it hard to figure out what their reasoning would be. But if you assume that there are people (and there most probably are) who are so sold on the "benefits" of NAT, that they're going to use NAT no matter how much you show them that there is in fact no benefit at all (which for a site with an IPv6 global /48, and site locals, is certainly true) then why would you care what address they're using behind the NAT? That is, whether it is SL, LL, or some random "global" prefix they calculated by tossing coins. I find it almost inconceivable to believe that anyone is deciding the fate of SL addressing by reference to NAT - that's simply too ludicrous (and sad) to contemplate. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 21 12:20: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 h3LJKnZ5005179; Mon, 21 Apr 2003 12:20:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJKn0p005178; Mon, 21 Apr 2003 12:20:49 -0700 (PDT) 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 h3LJKBZN005076 for ; Mon, 21 Apr 2003 12:20:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3K0X9xn011544 for ; Sat, 19 Apr 2003 17:33:09 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id SAA02243 for ; Sat, 19 Apr 2003 18:32:57 -0600 (MDT) 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, 20 Apr 2003 00:30:24 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, 20 Apr 2003 00:26: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; Sun, 20 Apr 2003 00:30:23 Z Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 00:30:19 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 h3K0EWgE020505; Sat, 19 Apr 2003 17:14:32 -0700 (PDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id BAA05646; Sun, 20 Apr 2003 01:14:31 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Keith Moore Cc: kre@munnari.OZ.AU, Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question From: Ole Troan Date: Sun, 20 Apr 2003 01:14:30 +0100 In-Reply-To: <20030419200049.2b0dd5f2.moore@cs.utk.edu> (Keith Moore's message of "Sat, 19 Apr 2003 20:00:49 -0400") Message-Id: <7t5vfxa81p5.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2.95 (usg-unix-v) References: <20030419172713.4c34e197.moore@cs.utk.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <15757.1050788984@munnari.OZ.AU> <20030419183555.2ce07295.moore@cs.utk.edu> <7t5y926844n.fsf@mrwint.cisco.com> <20030419200049.2b0dd5f2.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> > LL use can and should be reserved for bootstrapping and diagnostics. >> >> LL is used in applications already. e.g LL addresses are commonly used >> to address BGP endpoints on exchanges. > > I don't think of BGP as operating at level 7. well, BGP uses TCP as transport and most of the implementations I've seen use POSIX socket API just like any other application. the socket API needs let the application choose zone, and pick a suitable source address accordingly. > I don't have a problem with LL being used for a few special-purpose things > that can deal with it, so long as we don't expect LL to work for all or even > most apps. that is a big change in the IPv6 architecture. throwing all the cards up in the air every second year or so (anyone recorded what the frequency is for old and closed discussions reappearing on the ipng list?) gets rather trying after a while. perhaps about time to shut the IPv6 W.G down? /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 Apr 21 12:20: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 h3LJKoZ5005183; Mon, 21 Apr 2003 12:20:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJKouN005180; Mon, 21 Apr 2003 12:20:50 -0700 (PDT) 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 h3LJKBZD005076 for ; Mon, 21 Apr 2003 12:20:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JMbQxn001380 for ; Sat, 19 Apr 2003 15:37:26 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA24540 for ; Sat, 19 Apr 2003 15:37:20 -0700 (PDT) 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, 19 Apr 2003 22:37: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; Sat, 19 Apr 2003 22:33: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; Sat, 19 Apr 2003 22:37:13 Z Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 22:37:08 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1970wP-00077q-00; Sat, 19 Apr 2003 15:36:14 -0700 Date: Sat, 19 Apr 2003 18:35:55 -0400 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419183555.2ce07295.moore@cs.utk.edu> In-Reply-To: <15757.1050788984@munnari.OZ.AU> References: <20030419172713.4c34e197.moore@cs.utk.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <15757.1050788984@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | not to encourage that error to the point that it became common > | practice (as has happened). > > Usage alters to meet the demands of the users. That's nothing new. > > | on the contrary, having an enterprise use both SLs and globals creates > | significant new problems of its own, and results in even less > | flexibility than if SLs were used only by isolated networks. > > Nothing that IPv4 doesn't have as well (if perhaps less commonly). there's a reason that most v4 hosts don't have multiple addresses with varying scopes - it doesn't work well, and it creates problems for apps. putting sitelocals in v6 is trying to impose those problems on all host. > | multiple addresses at a node were available in IPv4, but the problems > | associated with doing this have never been solved, not even in IPv6. > > True. But it is still used regardless. There are unsolved problems > should be a challenge, not something to fear. by that logic we should make the architecture as 'challenging' as possible. personally I think getting the network to work well is enough of a challenge without adding needless complexity. > | so while having multiple prefixes per node is clearly useful for > | renumbering, > > Yes - but more than that - as long as addresses reflect topology, multiple > addresses are the only way to have multiple topological attachments, > aren't they? yes there are other justifications for multiple prefixes. I think that overall they are valuable enough that I'm not suggesting that we get rid of them. what we need to do is to get rid of the idea that it matters which address you use. > So, unless there's some routing revolution, you're just going to have > to learn to deal with multiple addresses, and unless LL addresses go > away, you're also going to have to deal with scoped addresses. LL use can and should be reserved for bootstrapping and diagnostics. > That is, merging site locals would only be an issue of site locals are > actively being used - if they're useless, and problematic, as you're > claiming, then surely people won't be using them (the "I can't get enough > address space" excuse for using 1918 addresses won't exist after all). SLs aren't useless - it's just that their use causes so many problems that we're better off providing that functionality in other ways. > So, if you're worried about this, then you must be assuming that they > will in fact be used - which to me means, that you can see that there is > actually a demand for something to solve the problems that (apparently) > only SL addresses currently can do (that's obvious, as if there was some > other available solution, then people would use that, rather than these > problematic SL things, wouldn't they???) no, it's the other way around - the expectation of using SLs thus far has pre-empted development of better solutions. (by your logic the network already works as well as it possibly can, if a better network were possible then it would exist, wouldn't it?) > Until we have that, and agree that it is a better design, let's just agree > that there really is no choice - we either keep SLs in the design we've already agreed to get rid of them. it's just that some people are in denial about that. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 12:20: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 h3LJKtZ5005193; Mon, 21 Apr 2003 12:20:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJKtrX005192; Mon, 21 Apr 2003 12:20:55 -0700 (PDT) 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 h3LJKBZL005076 for ; Mon, 21 Apr 2003 12:20:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JNbpxn006662 for ; Sat, 19 Apr 2003 16:37:51 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id RAA21589 for ; Sat, 19 Apr 2003 17:37:46 -0600 (MDT) 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, 19 Apr 2003 23:37: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; Sat, 19 Apr 2003 23:37: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; Sat, 19 Apr 2003 23:37:44 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; Sat, 19 Apr 2003 23:37:44 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 h3JNM0gE027832; Sat, 19 Apr 2003 16:22:01 -0700 (PDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id AAA04888; Sun, 20 Apr 2003 00:22:00 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Keith Moore Cc: Robert Elz , Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question From: Ole Troan Date: Sun, 20 Apr 2003 00:22:00 +0100 In-Reply-To: <20030419183555.2ce07295.moore@cs.utk.edu> (Keith Moore's message of "Sat, 19 Apr 2003 18:35:55 -0400") Message-Id: <7t5y926844n.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.2.95 (usg-unix-v) References: <20030419172713.4c34e197.moore@cs.utk.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <15757.1050788984@munnari.OZ.AU> <20030419183555.2ce07295.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [...] >> So, unless there's some routing revolution, you're just going to have >> to learn to deal with multiple addresses, and unless LL addresses go >> away, you're also going to have to deal with scoped addresses. > > LL use can and should be reserved for bootstrapping and diagnostics. LL is used in applications already. e.g LL addresses are commonly used to address BGP endpoints on exchanges. so unless you suggest to remove LL addresses (and MPLS VPNs) implementations will need to handle ambiguous and topologically scoped addresses, even without site-locals. /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 Apr 21 12:20:59 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 h3LJKwZ5005196; Mon, 21 Apr 2003 12:20:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJKwQG005195; Mon, 21 Apr 2003 12:20:58 -0700 (PDT) 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 h3LJKBZJ005076 for ; Mon, 21 Apr 2003 12:20:17 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3K0cexn012015 for ; Sat, 19 Apr 2003 17:38:40 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3K0cWrZ000684 for ; Sat, 19 Apr 2003 17:38:33 -0700 (PDT) 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, 20 Apr 2003 00:37:40 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, 20 Apr 2003 00:33: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; Sun, 20 Apr 2003 00:37:40 Z Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 00:37:35 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1972oi-000751-00; Sat, 19 Apr 2003 17:36:24 -0700 Date: Sat, 19 Apr 2003 20:36:06 -0400 From: Keith Moore To: "Stephen Sprunk" Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419203606.2b6cdabc.moore@cs.utk.edu> In-Reply-To: <005f01c306d2$c33cdaf0$93b58742@ssprunk> References: <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> <20030419192024.440d3773.moore@cs.utk.edu> <005f01c306d2$c33cdaf0$93b58742@ssprunk> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > (It is actually harder to decide between multiple available global > > > prefixes, than to decide between global and site local - the former is > > > a difficult problem, the latter is almost trivial). > > > > disagree. the app can choose any global prefix and reasonably expect > > it to work, modulo link failures. > > Nit: the vast majority of apps today bind to INADDR_ANY (or its IPv6 > equivalent), so it's really the OS which is choosing the source address. one of the problems introduced by scoped addresses is that this is no longer sufficient for some kinds of apps. > If the app binds a specific source address, it is invariably > user-configurable and thus not an application problem. or to put it more clearly, the only way an app can choose reasonably between multiple addresses of varying scopes is to be explicitly configured as to how to do so. otherwise, the app has no idea whether one scope or another is more suitable for its purposes. any assumptions about whether, for instance, site-locals are more secure or more stable than globals, or whether the app will need to communicate with off-site nodes, need to be explicitly configured. of course, if the app weren't being forced to choose between addresses of differing scopes then it wouldn't need to bind to specific source addresses (no more than v4 apps do), and such configuration would not be necessary. > > but when choosing between a global and a site local the app needs to > > know whether the site local address will be valid for the hosts that need > > to use it, and it has no way to know this. > > Well, since one can easily determine whether the destination address is SL > or not, picking a source address of the correct class is trivial. wrong again. it's not reasonable to assume that the source address will not be used by off site nodes. (of course, specific apps can make that assumption, but the architecture should not) > > the app may also have to choose which interface to use with the site- > > local prefix, and it has no good way to know this either. > > Ah, but it'll have a different SL address on each interface, so that's no > worse than having multiple global addresses. depends on what is driving the selection - I don't think it's reasonable to assume that all interfaces on a host are within a single site. 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 Mon Apr 21 12:20: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 h3LJKkZ5005176; Mon, 21 Apr 2003 12:20:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJKkJA005175; Mon, 21 Apr 2003 12:20:46 -0700 (PDT) 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 h3LJKBZH005076 for ; Mon, 21 Apr 2003 12:20:16 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3K0M9xn010448 for ; Sat, 19 Apr 2003 17:22:09 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3K0M3rZ027996 for ; Sat, 19 Apr 2003 17:22:03 -0700 (PDT) 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, 20 Apr 2003 00:22: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; Sun, 20 Apr 2003 00:22: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; Sun, 20 Apr 2003 00:22:02 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 00:22:02 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3K0LHL16924; Sat, 19 Apr 2003 19:21:17 -0500 Message-Id: <005f01c306d2$c33cdaf0$93b58742@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" , "Robert Elz" Cc: , , , , References: <00d001c306c0$faeadf90$93b58742@ssprunk><200304191923.h3JJNOuL018209@turing-police.cc.vt.edu><16890640984.20030419070719@brandenburg.com><002401c30605$e22da070$261e4104@eagleswings><9540645034.20030418171403@brandenburg.com><11870.1050777166@munnari.OZ.AU><14570.1050784897@munnari.OZ.AU><16762.1050792143@munnari.OZ.AU> <20030419192024.440d3773.moore@cs.utk.edu> Subject: Re: A simple question Date: Sat, 19 Apr 2003 19:19:30 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Keith Moore" > > | To assign more than one address to every host means the host > > | must have an intelligent means of deciding which address to use. > > > > Yes, but the amount of intelligence actually needed is pretty minimal. > > (It is actually harder to decide between multiple available global > > prefixes, than to decide between global and site local - the former is > > a difficult problem, the latter is almost trivial). > > disagree. the app can choose any global prefix and reasonably expect > it to work, modulo link failures. Nit: the vast majority of apps today bind to INADDR_ANY (or its IPv6 equivalent), so it's really the OS which is choosing the source address. If the app binds a specific source address, it is invariably user-configurable and thus not an application problem. > but when choosing between a global and a site local the app needs to > know whether the site local address will be valid for the hosts that need > to use it, and it has no way to know this. Well, since one can easily determine whether the destination address is SL or not, picking a source address of the correct class is trivial. > the app may also have to choose which interface to use with the site- > local prefix, and it has no good way to know this either. Ah, but it'll have a different SL address on each interface, so that's no worse than having multiple global addresses. The truly interesting case is connecting to a LL address with multiple interfaces. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 12:55: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 h3LJt9Z5011094; Mon, 21 Apr 2003 12:55:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJt8AZ011092; Mon, 21 Apr 2003 12:55:08 -0700 (PDT) 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 h3LJgp51007269 for ; Mon, 21 Apr 2003 12:54:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3K0M8lm025459 for ; Sat, 19 Apr 2003 17:22:08 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA22701 for ; Sat, 19 Apr 2003 18:21:57 -0600 (MDT) 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, 20 Apr 2003 00:21: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; Sun, 20 Apr 2003 00:17: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; Sun, 20 Apr 2003 00:21:46 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 00:21:44 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3K0LFL16921; Sat, 19 Apr 2003 19:21:15 -0500 Message-Id: <005e01c306d2$c1f3e030$93b58742@ssprunk> From: "Stephen Sprunk" To: "Robert Elz" , Cc: "Dave Crocker" , , References: <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16388.1050790957@munnari.OZ.AU> Subject: Re: A simple question Date: Sat, 19 Apr 2003 19:11:28 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Robert Elz" > | So if it's expected that both global and site-local addresses are > | available, why are we bothering with making things more complicated? > > Because we need stable addresses for local use. Any unique global address will work fine for local use, even if you're disconnected from the Net. Or do you expect your global prefix(es) to be withdrawn from hosts every time your upstream connection flaps? > Something tells me you've never actually lived in an environment where > your global address changes moderately frequently. If you had, you > wouldn't be so quick to ignore this need. But haven't you heard? With IPv6, renumbering will be so easy you'll do it for fun! The pain renumbering is one of the main motivators for NAT today, and I have yet to see any reason to believe it'll be easier in IPv6. > | Well.. all you need to do to fix this is to make a rule that if a > | global prefix becomes available, the site-local prefix is no longer > | appropriate and must be withdrawn. > > Can't possibly work. If site-locals and globals are to coexist, the obvious solution is to specify that when the destination is SL, an SL should be preferred as source, and likewise for globals. Of course, that doesn't fix the case where you have multiple globals, or multiple interfaces. We haven't figured out how to fix that with IPv4 either, except for specific cases like "backside networks". > | This *still* leaves the problem of using site-local behind a NAT, though. > > First, while I can imagine people existing who would be stupid enough to > do that, I find it hard to figure out what their reasoning would be. Avoiding renumbering, avoiding exposing internal identities, etc. It's all the same reasons you might use IPv4 NAT, with the possible exception of address shortages. I know several very large corps that use legacy class B space inside and NAT to provider-assigned CIDR space outside -- they're obviously not doing it because of address shortages, they're doing it for administrative and scoping reasons. > I find it almost inconceivable to believe that anyone is deciding the fate > of SL addressing by reference to NAT - that's simply too ludicrous > (and sad) to contemplate. Well, IPv6 NAT proponents expected to use the SL prefix as their private addressing, so eliminating SL will require another prefix for that purpose. I don't see any other direct connection, however. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 12:59: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 h3LJxpZ5011813; Mon, 21 Apr 2003 12:59:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJxoeZ011806; Mon, 21 Apr 2003 12:59:50 -0700 (PDT) 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 h3LJxDaR011629 for ; Mon, 21 Apr 2003 12:59:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JIcKL1004961 for ; Sat, 19 Apr 2003 11:38:20 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3JIcErZ028609 for ; Sat, 19 Apr 2003 11:38:14 -0700 (PDT) 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, 19 Apr 2003 18:38:13 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, 19 Apr 2003 18:34: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, 19 Apr 2003 18:38:13 Z Received: from fuchsia.home ([203.146.155.25] [203.146.155.25]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 18:38:10 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3JIb1YI003828; Sun, 20 Apr 2003 01:37:02 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3JIWls11872; Sun, 20 Apr 2003 01:32:49 +0700 (ICT) From: Robert Elz To: Dave Crocker cc: ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question In-Reply-To: <16890640984.20030419070719@brandenburg.com> References: <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Apr 2003 01:32:46 +0700 Message-Id: <11870.1050777166@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 19 Apr 2003 07:07:19 -0700 From: Dave Crocker Message-ID: <16890640984.20030419070719@brandenburg.com> | site local is, in fact, an addition to the IP architecture and that is | what is causing the controversy. No, it isn't. It is a cleaned up replacement for 1918 addresses. | when we go around making basic additions to an architecture, we should | try to be very clear on how it will be used, how it will impact the rest | of the architecture, and what the benefits and problems are likely to | be. This "addition" was made years ago. It is used now. The only thing being contemplated now is removing it without providing a replacement. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 21 13:05: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 h3LK1DZ5012131; Mon, 21 Apr 2003 13:01:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LK1Bqc012119; Mon, 21 Apr 2003 13:01:11 -0700 (PDT) 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 h3LJxDcX011629 for ; Mon, 21 Apr 2003 13:00:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JJHTL1009245 for ; Sat, 19 Apr 2003 12:17:29 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA00218 for ; Sat, 19 Apr 2003 13:17:23 -0600 (MDT) 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, 19 Apr 2003 19:17:23 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; Sat, 19 Apr 2003 19:17: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; Sat, 19 Apr 2003 19:17:23 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 19:17:22 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3JJDTv06305; Sat, 19 Apr 2003 15:13:30 -0400 (EDT) Date: Sat, 19 Apr 2003 15:13:29 -0400 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419151329.66daf0de.moore@cs.utk.edu> In-Reply-To: <11870.1050777166@munnari.OZ.AU> References: <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | site local is, in fact, an addition to the IP architecture and > | that is what is causing the controversy. > > No, it isn't. It is a cleaned up replacement for 1918 addresses. which by itself is reason enough to kill it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 21 13:06:02 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 h3LK4tdL012717; Mon, 21 Apr 2003 13:06:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJml5G009671; Mon, 21 Apr 2003 12:48:47 -0700 (PDT) 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 h3LJgmqF007252 for ; Mon, 21 Apr 2003 12:48:01 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3K4U4wC004575 for ; Sat, 19 Apr 2003 21:30:04 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3K4TqrZ011205 for ; Sat, 19 Apr 2003 21:29:57 -0700 (PDT) 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, 20 Apr 2003 04:29: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; Sun, 20 Apr 2003 04:29: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; Sun, 20 Apr 2003 04:29:49 Z Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 04:29:47 Z Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h3K4Pxw19463; Sat, 19 Apr 2003 21:25:59 -0700 (PDT) From: Bill Manning Message-Id: <200304200425.h3K4Pxw19463@boreas.isi.edu> Subject: Re: A simple question In-Reply-To: <20030420032426.GA9713@shrubbery.net> from john heasley at "Apr 19, 3 08:24:26 pm" To: heas@shrubbery.net (john heasley) Date: Sat, 19 Apr 2003 21:25:59 -0700 (PDT) Cc: bmanning@ISI.EDU, jabley@isc.org, moore@cs.utk.edu, kre@munnari.OZ.AU, Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org, ot@cisco.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 % Sat, Apr 19, 2003 at 05:24:39PM -0700, Bill Manning: % > % >>> So, unless there's some routing revolution, you're just going to have % > % >>> to learn to deal with multiple addresses, and unless LL addresses go % > % >>> away, you're also going to have to deal with scoped addresses. % > % >> % > % >> LL use can and should be reserved for bootstrapping and diagnostics. % > % > % > % > LL is used in applications already. e.g LL addresses are commonly used % > % > to address BGP endpoints on exchanges. % > % % > % What exchanges do that? % > % % > % % > % Joe % > % > % > Akira Kato and I had a draft out on how this could be done % > and had working, inter-operable implementations (zebra, cisco) % > in two locations, NSPIXP3 and LAIIX. % % but, why? why not? back in the day, the pier wg identified several apps that did not take to renumbering well. BGP was one. couple that with the oddities of small bits of address space that are needed at exchanges (and do not play well w/ the (non)compelling arguements for aggregation) and it seemed reasonable that, if massive aggregation was an inevitable feature of IPv6, that moving exchange point communications to linklocal addresses would make many things simpler. No "special-use" ranges in v6 land for exchanges. But it was not to be. Check the IDR archives for details. we now have special blocks of IPv6 space that are not supposed to be aggregated for things like exchanges. massive aggregation is expected, except for these "special prefixes". One more administrative thing to track. :( --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 Mon Apr 21 13:06:02 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 h3LK4tdN012717; Mon, 21 Apr 2003 13:06:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJvKRV011501; Mon, 21 Apr 2003 12:57:20 -0700 (PDT) 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 h3LJgp8x007269 for ; Mon, 21 Apr 2003 12:56:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JKaJwr002895 for ; Sat, 19 Apr 2003 13:36:19 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA27385 for ; Sat, 19 Apr 2003 14:36:13 -0600 (MDT) 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, 19 Apr 2003 20:36: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; Sat, 19 Apr 2003 20:36: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; Sat, 19 Apr 2003 20:36:12 Z Received: from fuchsia.home ([203.146.155.26] [203.146.155.26]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 20:36:09 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3JKYnYI005658; Sun, 20 Apr 2003 03:34:59 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3JKSss14386; Sun, 20 Apr 2003 03:28:56 +0700 (ICT) From: Robert Elz To: Keith Moore cc: dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question In-Reply-To: <20030419151329.66daf0de.moore@cs.utk.edu> References: <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Apr 2003 03:28:54 +0700 Message-Id: <14384.1050784134@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 19 Apr 2003 15:13:29 -0400 From: Keith Moore Message-ID: <20030419151329.66daf0de.moore@cs.utk.edu> | > No, it isn't. It is a cleaned up replacement for 1918 addresses. | which by itself is reason enough to kill it. Nothing of the kind. 1918 addresses were created because there was demonstrated demand for stable local use only addressing. Nothing has changed in the Internet to cause that demand to go away. We either provide a mechanism, or the users provide one of their own. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 21 13:06:02 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 h3LK4tdP012717; Mon, 21 Apr 2003 13:06:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJsB9H010859; Mon, 21 Apr 2003 12:54:11 -0700 (PDT) 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 h3LJgp1j007269 for ; Mon, 21 Apr 2003 12:53:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3KJlsCB013099 for ; Sun, 20 Apr 2003 12:47:54 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA23251 for ; Sun, 20 Apr 2003 13:47:48 -0600 (MDT) 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; Sun, 20 Apr 2003 19:47: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; Sun, 20 Apr 2003 19:47: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; Sun, 20 Apr 2003 19:47:48 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 19:47:47 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3KJlgL32049; Sun, 20 Apr 2003 14:47:42 -0500 Message-Id: <003101c30775$b55db050$93b58742@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" , "Terry Gray" Cc: , , References: <200304200024.h3K0OdY06518@boreas.isi.edu><20030420032426.GA9713@shrubbery.net><20030420101911.09a143fb.moore@cs.utk.edu> <20030420130719.580be874.moore@cs.utk.edu> Subject: Re: A simple question Date: Sun, 20 Apr 2003 14:44:21 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Keith Moore" > > Also, I'm wondering how the SL/1918 address-scoping debate > > plays in the context of firewalls. Don't firewalls provide an even > > more random form of address scoping that apps must cope with? > > Or not? > > ... > Scoped addresses muddy this picture, because experience indicates > that apps will be expected to cope with a mixture of scoped and > global addresses. Once scoped addresses are introduced, the app > has to perform functions traditionally performed by the network. If > host A cannot reach host B, it might be due to policy or a network > failure, or it might be that the address that A has for B is not valid in > the scope that A is using. So you're not arguing against scoped addresses per se, you're arguing against having both scoped and global addresses on the same host? I see the same problem occuring if a host has two global addresses which are treated differently by the firewall(s), so it's not truly a problem with SL. The only SL-specific problem is when naughty applications pass network-layer addresses across site boundaries; such applications must be "address aware" anyways, so understanding SL isn't much of an incremental burden. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 13:06: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 h3LK4tdZ012717; Mon, 21 Apr 2003 13:06:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LK1KVc012158; Mon, 21 Apr 2003 13:01:20 -0700 (PDT) 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 h3LJxDdR011629 for ; Mon, 21 Apr 2003 13:00:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JMLo3K028844 for ; Sat, 19 Apr 2003 15:21:50 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3JMLirZ007158 for ; Sat, 19 Apr 2003 15:21:45 -0700 (PDT) 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; Sat, 19 Apr 2003 22:21:44 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, 19 Apr 2003 22:21:44 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, 19 Apr 2003 22:21:43 Z Received: from fuchsia.home ([203.146.155.29] [203.146.155.29]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 22:21:41 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3JMKsYI006791; Sun, 20 Apr 2003 05:20:54 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3JMDQs16252; Sun, 20 Apr 2003 05:13:26 +0700 (ICT) From: Robert Elz To: Keith Moore cc: dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question In-Reply-To: <20030419174221.7111b542.moore@cs.utk.edu> References: <20030419174221.7111b542.moore@cs.utk.edu> <20030419165921.782a8353.moore@cs.utk.edu> <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14384.1050784134@munnari.OZ.AU> <15314.1050787340@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Apr 2003 05:13:26 +0700 Message-Id: <16250.1050790406@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 19 Apr 2003 17:42:21 -0400 From: Keith Moore Message-ID: <20030419174221.7111b542.moore@cs.utk.edu> | wrong. we know now that 1918 addresses created a big mess. No, we don't know that, because that's incorrect. 1918 addresses are just numbers, they can't have created the mess. The mess was created by the demands of the users that led to the creation of the 1918 addresses. That is, the mess would still have been there, but worse, had 1918 never existed. | and nothing about IPv6 use of SLs reduces that mess. I think it does, but even if you're right, the mess is there anyway. It isn't going away, whatever you do with SLs. This is just like not liking shit, so you're going to ban the sewer system. Great plan. | no, you have it backwards. SLs destroy the utility of IPv6. There's a quote I remember that seems apt, I'm sure someone will remember who it was said this ... "yawn. I'm tired of baseless assertions." kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 21 13:06:04 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 h3LK4tdT012717; Mon, 21 Apr 2003 13:06:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LK2B1c012317; Mon, 21 Apr 2003 13:02:11 -0700 (PDT) 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 h3LJxDed011629 for ; Mon, 21 Apr 2003 13:01:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3KK0qge000504 for ; Sun, 20 Apr 2003 13:00:52 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3KK0lrZ001403 for ; Sun, 20 Apr 2003 13:00:47 -0700 (PDT) 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; Sun, 20 Apr 2003 20:00: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; Sun, 20 Apr 2003 20:00:46 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, 20 Apr 2003 20:00:46 Z Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 20:00:45 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 197KzM-0000Kp-00; Sun, 20 Apr 2003 13:00:36 -0700 Date: Sun, 20 Apr 2003 16:00:15 -0400 From: Keith Moore To: "Stephen Sprunk" Cc: moore@cs.utk.edu, gray@washington.edu, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A simple question Message-Id: <20030420160015.71849057.moore@cs.utk.edu> In-Reply-To: <003101c30775$b55db050$93b58742@ssprunk> References: <200304200024.h3K0OdY06518@boreas.isi.edu> <20030420032426.GA9713@shrubbery.net> <20030420101911.09a143fb.moore@cs.utk.edu> <20030420130719.580be874.moore@cs.utk.edu> <003101c30775$b55db050$93b58742@ssprunk> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So you're not arguing against scoped addresses per se, you're arguing > against having both scoped and global addresses on the same host? it turns out that this doesn't solve the problem. the addresses will still leak. apps will still be expected to cope with the mixture of ambiguous and unambiguous addresses. > I see the > same problem occuring if a host has two global addresses which are treated > differently by the firewall(s), I see that as a different problem - in particular, in that case there's no need for apps to cope with ambiguous IP addresses. as a result it's much clearer that it's unreasonable to expect apps to talk to the nodes whose traffic is being filtered. > The only SL-specific problem is when naughty applications pass network-layer > addresses across site boundaries which is a perfectly healthy and reasonable thing for apps to do. (not that they can tell where those site boundaries are anyway) > ; such applications must be "address aware" > anyways, so understanding SL isn't much of an incremental burden. using an address as an opaque identifier doesn't require address awareness. 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 Mon Apr 21 13:06: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 h3LK4tdd012717; Mon, 21 Apr 2003 13:06:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJvGOF011495; Mon, 21 Apr 2003 12:57:16 -0700 (PDT) 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 h3LJgp81007269 for ; Mon, 21 Apr 2003 12:55:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JMT0lm015110 for ; Sat, 19 Apr 2003 15:29:00 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA02770 for ; Sat, 19 Apr 2003 16:28:55 -0600 (MDT) 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, 19 Apr 2003 22:28: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; Sat, 19 Apr 2003 22:28: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; Sat, 19 Apr 2003 22:28:44 Z Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 22:28:43 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1970oL-00023W-00; Sat, 19 Apr 2003 15:27:53 -0700 Date: Sat, 19 Apr 2003 18:27:35 -0400 From: Keith Moore To: Valdis.Kletnieks@vt.edu Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419182735.425cd6fd.moore@cs.utk.edu> In-Reply-To: <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> References: <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > IPv6 requires renumbering when an address that has been used is no longer > > appropriate (which will generally be because of changed topology, which > > may be local topology changes - moving a host to a different LAN, or > > global ones - connecting to a different provider). That is the only > > reason. As long as prefixes remain usable, they can keep on being used, > > with other prefixes added as required. > > Well.. all you need to do to fix this is to make a rule that if a > global prefix becomes available, the site-local prefix is no longer > appropriate and must be withdrawn. this only solves one of several problems with site-locals, and it removes one of the few supposed benefits of site-locals - that such addresses will be stable across prefix changes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 13:06: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 h3LK4tdh012717; Mon, 21 Apr 2003 13:06:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJsDAu010867; Mon, 21 Apr 2003 12:54:13 -0700 (PDT) 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 h3LJgp1n007269 for ; Mon, 21 Apr 2003 12:53:32 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3KIuICB001752 for ; Sun, 20 Apr 2003 11:56:18 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA04199 for ; Sun, 20 Apr 2003 11:56:12 -0700 (PDT) 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, 20 Apr 2003 18:56:12 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, 20 Apr 2003 18:52: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; Sun, 20 Apr 2003 18:56:12 Z Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 18:56:12 Z Received: from nomad.ctd.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA29339; Sun, 20 Apr 2003 13:56:10 -0500 (CDT) Message-Id: <5.1.1.5.2.20030420134939.00a3f840@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sun, 20 Apr 2003 13:55:56 -0500 To: Daniel Senie , ipng@sunroof.eng.sun.com From: Richard Carlson Subject: Re: A simple question Cc: ietf@ietf.org In-Reply-To: <5.2.1.1.2.20030420140541.0290fb00@mail.amaranth.net> References: <5.1.1.5.2.20030420115012.009f0260@atalanta.ctd.anl.gov> <20030419192024.440d3773.moore@cs.utk.edu> <16762.1050792143@munnari.OZ.AU> <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 02:16 PM 4/20/03 -0400, Daniel Senie wrote: >At 01:00 PM 4/20/2003, Richard Carlson wrote: >>At 07:20 PM 4/19/03 -0400, Keith Moore wrote: >>> > | To assign more than one address to every host means the host must >>> have >>> > | an intelligent means of deciding which address to use. >>> > >>> > Yes, but the amount of intelligence actually needed is pretty minimal. >>> > (It is actually harder to decide between multiple available global >>> > prefixes, than to decide between global and site local - the former is >>> > a difficult problem, the latter is almost trivial). >>> >>>disagree. the app can choose any global prefix and reasonably expect it to >>>work, >> >>I completely disagree with this assumption. Firewalls and address >>filters mean that no app can make any reasonable assumption. Some >>addresses will work and others will fail. The app is left with no clues >>as to why the connection failed. Assuming it's just a link failure and >>retrying sometime in the future things will work is a receipt for user >>frustration. >> >>>modulo link failures. but when choosing between a global and a site >>>local the app needs to know whether the site local address will be valid for >>>the hosts that need to use it, and it has no way to know this. the app may >>>also have to choose which interface to use with the site-local prefix, >>>and it has no good way to know this either. >> >>The decision process is not forced on the app/host by the existence of >>the site-local prefix. It is due to the emergence of firewalls and >>address filters. The reality is that non-global routing scopes exist >>today. The question is - how do we provide some feedback to apps that >>they are trying to cross a scope boundary that it's a permanent error >>condition (5xx in SMTP verbiage)? One proposed notification method is >>the site-local prefix. Other methods can be created, but something needs >>to be done and simply killing site-locals and ignoring the underlying >>scoping issue is a non-starter. > >You mean aside from applications understaning that an ICMP Destination >Unreachable / Administratively Prohibited response from the site firewall? An ICMP message is one way of providing this information. There may be others, I don't know by folks are free to develop them. >For that matter, IPv6 machines arguably could try their Site Local address >and be given that same feedback from the border router or firewall, and >use the response as an indication to go use their assigned global address. >It's not clear to me that the host or application need contain the >intelligence (nor is there any way to determine scoping unassisted, IMO), >however through use of ICMP responses it certainly should be possible to >determine reachability or lack thereof. It may be useful to expand the >responses routers and firewalls give to hosts within sites to help >accomplish this. > >We have the problem of scoped addresses whether the "site local" mechanism >is retained or not. Providing guidance on the responses an application is >to receive in response to scoping controls (firewalls) would be useful >regardless. If this problem is worth solving for the already-common case >of firewalls, solving it for site-local addressing does not seem to be too >much of a stretch. Exactly, the only thing an address with a site-local prefix tell me is that a filtering router or firewall is guaranteed to be in some arbitrary path. I'm mystified as to why an app would treat it any differently that an IPv6 address generated with any other prefix. Rich ------------------------------------ Richard A. Carlson e-mail: RACarlson@anl.gov Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 13:06:06 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 h3LK4tdX012717; Mon, 21 Apr 2003 13:06:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LK29L6012316; Mon, 21 Apr 2003 13:02:09 -0700 (PDT) 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 h3LJxDeb011629 for ; Mon, 21 Apr 2003 13:01:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3KH1Fge012952 for ; Sun, 20 Apr 2003 10:01:15 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA02937 for ; Sun, 20 Apr 2003 11:01:09 -0600 (MDT) 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, 20 Apr 2003 17:01: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; Sun, 20 Apr 2003 17:01: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; Sun, 20 Apr 2003 17:01:09 Z Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 17:01:09 Z Received: from nomad.ctd.anl.gov (localhost [127.0.0.1]) by atalanta.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA24085; Sun, 20 Apr 2003 12:01:08 -0500 (CDT) Message-Id: <5.1.1.5.2.20030420115012.009f0260@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sun, 20 Apr 2003 12:00:55 -0500 To: ipng@sunroof.eng.sun.com From: Richard Carlson Subject: Re: A simple question Cc: ietf@ietf.org In-Reply-To: <20030419192024.440d3773.moore@cs.utk.edu> References: <16762.1050792143@munnari.OZ.AU> <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 07:20 PM 4/19/03 -0400, Keith Moore wrote: > > | To assign more than one address to every host means the host must have > > | an intelligent means of deciding which address to use. > > > > Yes, but the amount of intelligence actually needed is pretty minimal. > > (It is actually harder to decide between multiple available global > > prefixes, than to decide between global and site local - the former is > > a difficult problem, the latter is almost trivial). > >disagree. the app can choose any global prefix and reasonably expect it to >work, I completely disagree with this assumption. Firewalls and address filters mean that no app can make any reasonable assumption. Some addresses will work and others will fail. The app is left with no clues as to why the connection failed. Assuming it's just a link failure and retrying sometime in the future things will work is a receipt for user frustration. >modulo link failures. but when choosing between a global and a site >local the app needs to know whether the site local address will be valid for >the hosts that need to use it, and it has no way to know this. the app may >also have to choose which interface to use with the site-local prefix, >and it has no good way to know this either. The decision process is not forced on the app/host by the existence of the site-local prefix. It is due to the emergence of firewalls and address filters. The reality is that non-global routing scopes exist today. The question is - how do we provide some feedback to apps that they are trying to cross a scope boundary that it's a permanent error condition (5xx in SMTP verbiage)? One proposed notification method is the site-local prefix. Other methods can be created, but something needs to be done and simply killing site-locals and ignoring the underlying scoping issue is a non-starter. Rich ------------------------------------ Richard A. Carlson e-mail: RACarlson@anl.gov Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 13:06: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 h3LK4tdR012717; Mon, 21 Apr 2003 13:06:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJvRcX011520; Mon, 21 Apr 2003 12:57:27 -0700 (PDT) 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 h3LJgp91007269 for ; Mon, 21 Apr 2003 12:56:16 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JLUEwr007811 for ; Sat, 19 Apr 2003 14:30:14 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA18869 for ; Sat, 19 Apr 2003 15:30:07 -0600 (MDT) 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, 19 Apr 2003 21:30: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; Sat, 19 Apr 2003 21:26: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; Sat, 19 Apr 2003 21:30:00 Z Received: from fuchsia.home ([203.146.155.28] [203.146.155.28]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 21:29:56 Z Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3JLT1YI006221; Sun, 20 Apr 2003 04:29:01 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3JLMKs15316; Sun, 20 Apr 2003 04:22:20 +0700 (ICT) From: Robert Elz To: Keith Moore cc: dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question In-Reply-To: <20030419165921.782a8353.moore@cs.utk.edu> References: <20030419165921.782a8353.moore@cs.utk.edu> <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14384.1050784134@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Apr 2003 04:22:20 +0700 Message-Id: <15314.1050787340@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 19 Apr 2003 16:59:21 -0400 From: Keith Moore Message-ID: <20030419165921.782a8353.moore@cs.utk.edu> | 1918 addresses were created because there was a need for isolated | networks to be able to get address space, and having them pick space | at random was believed to be problematic. Yes, and nothing has changed. If anything, the demand now is greater than it was when 1918 addresses were first created, as addresses now are much less stable - 1918 addresses also fill the role of stable addressing for internal site use. | what has changed is that we now have experience with RFC 1918, and we | know now that it is far more of a mess than was anticipated. Which explains some of the cleanups. But even ignoring that, you cannot just wish the demand away. One way or another, the users are going to meet their demands. If that means just picking space at random again, that's what they'll do (which will likely mean that they'll need to use NAT as well, which with SL they don't). If you (and/or the WG as a whole) can come up with a replacement that is better than site local, and meets the objectives, that's fine. Until then don't destroy what we have now, which works now (as in, in in day to day use now). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 21 13:06: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 h3LK4tdx012717; Mon, 21 Apr 2003 13:06:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJsMZg010901; Mon, 21 Apr 2003 12:54:22 -0700 (PDT) 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 h3LJgp1t007269 for ; Mon, 21 Apr 2003 12:53:35 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3KKNSCB017497 for ; Sun, 20 Apr 2003 13:23:29 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id OAA03740 for ; Sun, 20 Apr 2003 14:23:23 -0600 (MDT) 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, 20 Apr 2003 20:23: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; Sun, 20 Apr 2003 20:23:23 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, 20 Apr 2003 20:23:22 Z Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 20:23:22 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 197LLH-0006xA-00; Sun, 20 Apr 2003 13:23:15 -0700 Date: Sun, 20 Apr 2003 16:22:54 -0400 From: Keith Moore To: "Stephen Sprunk" Cc: moore@cs.utk.edu, RACarlson@anl.gov, dts@senie.com, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A simple question Message-Id: <20030420162254.6b74e8d0.moore@cs.utk.edu> In-Reply-To: <003d01c30776$b38af6b0$93b58742@ssprunk> References: <20030419192024.440d3773.moore@cs.utk.edu> <16762.1050792143@munnari.OZ.AU> <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> <5.2.1.1.2.20030420140541.0290fb00@mail.amaranth.net> <003d01c30776$b38af6b0$93b58742@ssprunk> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The vast majority of applications do not pick their source address, nor is > there a compelling reason for them to do so. not in IPv4. if IPv6 has site locals more applications will need to do so. > A large number of applications > don't even handle multiple destination addresses properly, so expecting this > additional intelligence for the source address is irrational. again, you're trying to extrapolate from ipv4 experience to ipv6, but such experience isn't necessarily a good indicator when ipv6 presents a more challenging environment than ipv4. then again, if dealing with multiple addresses for a host was hard in ipv4, it's not going to be easier in ipv6. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 13:06: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 h3LK4tdn012717; Mon, 21 Apr 2003 13:06:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJvKQE011502; Mon, 21 Apr 2003 12:57:20 -0700 (PDT) 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 h3LJgp89007269 for ; Mon, 21 Apr 2003 12:55:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3K02glm023803 for ; Sat, 19 Apr 2003 17:02:42 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3K02WrZ024872 for ; Sat, 19 Apr 2003 17:02:33 -0700 (PDT) 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, 20 Apr 2003 00:02: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; Sat, 19 Apr 2003 23:58: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; Sun, 20 Apr 2003 00:02:08 Z Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 00:02:06 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1972Ga-0005Pw-00; Sat, 19 Apr 2003 17:01:08 -0700 Date: Sat, 19 Apr 2003 20:00:49 -0400 From: Keith Moore To: Ole Troan Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419200049.2b0dd5f2.moore@cs.utk.edu> In-Reply-To: <7t5y926844n.fsf@mrwint.cisco.com> References: <20030419172713.4c34e197.moore@cs.utk.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <15757.1050788984@munnari.OZ.AU> <20030419183555.2ce07295.moore@cs.utk.edu> <7t5y926844n.fsf@mrwint.cisco.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > LL use can and should be reserved for bootstrapping and diagnostics. > > LL is used in applications already. e.g LL addresses are commonly used > to address BGP endpoints on exchanges. I don't think of BGP as operating at level 7. I don't have a problem with LL being used for a few special-purpose things that can deal with it, so long as we don't expect LL to work for all or even most apps. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 13:06: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 h3LK4te3012717; Mon, 21 Apr 2003 13:06:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJwAlM011593; Mon, 21 Apr 2003 12:58:10 -0700 (PDT) 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 h3LJgpB3007269 for ; Mon, 21 Apr 2003 12:57:40 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3L2E1CB008088 for ; Sun, 20 Apr 2003 19:14:01 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id UAA13121 for ; Sun, 20 Apr 2003 20:13:55 -0600 (MDT) 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, 21 Apr 2003 02:13:55 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, 21 Apr 2003 02:13: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, 21 Apr 2003 02:13:55 Z Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 21 Apr 2003 02:13:55 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 197QoP-0001vR-00; Sun, 20 Apr 2003 19:13:41 -0700 Date: Sun, 20 Apr 2003 22:13:19 -0400 From: Keith Moore To: Daniel Senie Cc: moore@cs.utk.edu, stephen@sprunk.org, RACarlson@anl.gov, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A simple question Message-Id: <20030420221319.62964599.moore@cs.utk.edu> In-Reply-To: <5.2.1.1.2.20030420201343.02a336c0@mail.amaranth.net> References: <20030419192024.440d3773.moore@cs.utk.edu> <16762.1050792143@munnari.OZ.AU> <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> <5.2.1.1.2.20030420140541.0290fb00@mail.amaranth.net> <5.2.1.1.2.20030420201343.02a336c0@mail.amaranth.net> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > b) if there's a strong need for appropriate > ICMP responses to make IPv6 function well, then an RFC stating as much > could be published. like, for instance, a need for path mtu discovery to work reliably? (since v6 routers don't fragment packets) > >The vast majority of applications do not pick their source address, nor is > >there a compelling reason for them to do so. A large number of > >applications don't even handle multiple destination addresses properly, so > >expecting this additional intelligence for the source address is > >irrational. > > At which point they might as well just select their global address unless > the destination address for a service is site local. This decision could > (should?) be in the hands of the IP stack, unless the application > specifically asks for such control. I disagree that the IP stack can supply reasonable defaults in the face of multiple scopes. The criteria for choosing a source address varies widely from one application to another. Some applications need stable addresses, others need addresses usable from all of their potential peers, others need to choose the source address that results in the best performance (where there is more than one meaning of 'best performance'). The default address selection rules are at best a guess. We should let the network do routing, so that hosts and apps aren't expected to make routing decisions. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 13:06: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 h3LK4tdb012717; Mon, 21 Apr 2003 13:06:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJv5EP011480; Mon, 21 Apr 2003 12:57:05 -0700 (PDT) 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 h3LJgp7x007269 for ; Mon, 21 Apr 2003 12:55:49 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JMlalm017230 for ; Sat, 19 Apr 2003 15:47:36 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA00040 for ; Sat, 19 Apr 2003 16:47:30 -0600 (MDT) 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, 19 Apr 2003 22:47:29 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, 19 Apr 2003 22:47: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; Sat, 19 Apr 2003 22:47:29 Z Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 22:47:27 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19716R-00025Q-00; Sat, 19 Apr 2003 15:46:35 -0700 Date: Sat, 19 Apr 2003 18:46:17 -0400 From: Keith Moore To: "Stephen Sprunk" Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419184617.1e8e5a60.moore@cs.utk.edu> In-Reply-To: <00d001c306c0$faeadf90$93b58742@ssprunk> References: <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <00d001c306c0$faeadf90$93b58742@ssprunk> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I had always planned on using only SL addresses within the enterprise, and > then NATing those SLs to public addresses at the ISP. we can't stop you from screwing up your network. just don't expect us to endorse such practices, and don't expect apps to work across your network boundary. > That way, none of the > enterprise network is polluted with (frequently changing) global > addresses -- just like common IPv4 practice today. and the network is dysfunctional, just like common IPv4 practice today. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 13:06:22 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 h3LK4tdp012717; Mon, 21 Apr 2003 13:06:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJsBuV010864; Mon, 21 Apr 2003 12:54:11 -0700 (PDT) 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 h3LJgp1p007269 for ; Mon, 21 Apr 2003 12:53:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3KJtDCB013903 for ; Sun, 20 Apr 2003 12:55:13 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id NAA28093 for ; Sun, 20 Apr 2003 13:55:07 -0600 (MDT) 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, 20 Apr 2003 19:55:07 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, 20 Apr 2003 19:55: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; Sun, 20 Apr 2003 19:55:06 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 19:55:05 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3KJsnL32258; Sun, 20 Apr 2003 14:54:49 -0500 Message-Id: <003d01c30776$b38af6b0$93b58742@ssprunk> From: "Stephen Sprunk" To: "Richard Carlson" , "Daniel Senie" Cc: , References: <20030419192024.440d3773.moore@cs.utk.edu> <16762.1050792143@munnari.OZ.AU> <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> <5.2.1.1.2.20030420140541.0290fb00@mail.amaranth.net> Subject: Re: A simple question Date: Sun, 20 Apr 2003 14:50:00 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Daniel Senie" > At 01:00 PM 4/20/2003, Richard Carlson wrote: > >The question is - how do we provide some feedback to apps that > >they are trying to cross a scope boundary that it's a permanent error > >condition (5xx in SMTP verbiage)? One proposed notification > >method is the site-local prefix. Other methods can be created, but > >something needs to be done and simply killing site-locals and > >ignoring the underlying scoping issue is a non-starter. > > You mean aside from applications understaning that an ICMP > Destination Unreachable / Administratively Prohibited response from > the site firewall? Many firewalls simply drop packets which are prohibited without sending ICMP responses, not to mention all the places that filter all ICMP indiscriminately. > For that matter, IPv6 machines arguably could try their Site Local > address and be given that same feedback from the border router or > firewall, and use the response as an indication to go use their assigned > global address. The vast majority of applications do not pick their source address, nor is there a compelling reason for them to do so. A large number of applications don't even handle multiple destination addresses properly, so expecting this additional intelligence for the source address is irrational. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 13:06:15 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 h3LK4tdj012717; Mon, 21 Apr 2003 13:06:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJv5JK011478; Mon, 21 Apr 2003 12:57:05 -0700 (PDT) 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 h3LJgp85007269 for ; Mon, 21 Apr 2003 12:55:51 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3JMjAlm016993 for ; Sat, 19 Apr 2003 15:45:10 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA16563 for ; Sat, 19 Apr 2003 16:45:04 -0600 (MDT) 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, 19 Apr 2003 22:45:03 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, 19 Apr 2003 22:41: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; Sat, 19 Apr 2003 22:45:03 Z Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 19 Apr 2003 22:45:01 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 197145-0003TF-00; Sat, 19 Apr 2003 15:44:09 -0700 Date: Sat, 19 Apr 2003 18:43:51 -0400 From: Keith Moore To: Robert Elz Cc: moore@CS.UTK.EDU, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030419184351.55785a28.moore@cs.utk.edu> In-Reply-To: <16250.1050790406@munnari.OZ.AU> References: <20030419174221.7111b542.moore@cs.utk.edu> <20030419165921.782a8353.moore@cs.utk.edu> <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14384.1050784134@munnari.OZ.AU> <15314.1050787340@munnari.OZ.AU> <16250.1050790406@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | wrong. we know now that 1918 addresses created a big mess. > > No, we don't know that, because that's incorrect. 1918 addresses > are just numbers, they can't have created the mess. The mess was created > by the demands of the users that led to the creation of the 1918 addresses. > That is, the mess would still have been there, but worse, had 1918 never > existed. not clear. as someone pointed out, the intended use case for 1918 has all but disappeared, so maybe we wouldn't have had such a mess afterall. of course we would have had to have some kind of scoped addresses by now anyway due to the address shortage in v4. that doesn't justify putting them in v6. > | and nothing about IPv6 use of SLs reduces that mess. > > I think it does, but even if you're right, the mess is there anyway. > It isn't going away, whatever you do with SLs. > > This is just like not liking shit, so you're going to ban the sewer system. well, the damage caused by SLs spreads to every aspect of the network from apps on down. so having SLs in v6 is like saying that since we are going to have shit no matter what we do, we might as well spread it everywhere rather than try to promote any kind of sanitation. 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 Mon Apr 21 13:06: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 h3LK4tdt012717; Mon, 21 Apr 2003 13:06:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LK2C2D012321; Mon, 21 Apr 2003 13:02:12 -0700 (PDT) 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 h3LJxDeh011629 for ; Mon, 21 Apr 2003 13:01:22 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3KJCNge025599 for ; Sun, 20 Apr 2003 12:12:23 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA13332 for ; Sun, 20 Apr 2003 13:12:18 -0600 (MDT) 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, 20 Apr 2003 19:11: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, 20 Apr 2003 19:11: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; Sun, 20 Apr 2003 19:11:28 Z Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 19:11:27 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 197KDg-0003JE-00; Sun, 20 Apr 2003 12:11:20 -0700 Date: Sun, 20 Apr 2003 15:10:59 -0400 From: Keith Moore To: Daniel Senie Cc: moore@cs.utk.edu, RACarlson@anl.gov, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030420151059.1f400738.moore@cs.utk.edu> In-Reply-To: <5.2.1.1.2.20030420140541.0290fb00@mail.amaranth.net> References: <20030419192024.440d3773.moore@cs.utk.edu> <16762.1050792143@munnari.OZ.AU> <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> <5.2.1.1.2.20030420140541.0290fb00@mail.amaranth.net> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > You mean aside from applications understaning that an ICMP Destination > Unreachable / Administratively Prohibited response from the site firewall? > > For that matter, IPv6 machines arguably could try their Site Local address > and be given that same feedback from the border router or firewall how does any party - the host, border router or firewall - know whether the SL address is from that site or some other site? SLs are inherently ambiguous. > , and use > the response as an indication to go use their assigned global address. if the destination has a global address, it should *always* be used in preference to the site local, at least in the absence of external configuration. > We have the problem of scoped addresses whether the "site local" mechanism > is retained or not. I disagree, or at least, I think it's misleading to use the term "scoped addresses" to cover all filtering, because this is conflating two things - use of filtering on one hand and use of ambiguous addresses on the other. It's useful to be able to refer to a host even if you can't send traffic there. 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 Mon Apr 21 13:06: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 h3LK4te1012717; Mon, 21 Apr 2003 13:06:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJsQqq010917; Mon, 21 Apr 2003 12:54:26 -0700 (PDT) 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 h3LJgp1x007269 for ; Mon, 21 Apr 2003 12:53:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3KJQuCB009957 for ; Sun, 20 Apr 2003 12:26:57 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA20869 for ; Sun, 20 Apr 2003 13:26:51 -0600 (MDT) 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, 20 Apr 2003 19:26: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; Sun, 20 Apr 2003 19:26:50 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, 20 Apr 2003 19:26:50 Z Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 19:26:50 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 197KSb-00041b-00; Sun, 20 Apr 2003 12:26:45 -0700 Date: Sun, 20 Apr 2003 15:26:24 -0400 From: Keith Moore To: Richard Carlson Cc: moore@cs.utk.edu, dts@senie.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030420152624.153c95ff.moore@cs.utk.edu> In-Reply-To: <5.1.1.5.2.20030420134939.00a3f840@atalanta.ctd.anl.gov> References: <5.1.1.5.2.20030420115012.009f0260@atalanta.ctd.anl.gov> <20030419192024.440d3773.moore@cs.utk.edu> <16762.1050792143@munnari.OZ.AU> <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> <5.1.1.5.2.20030420134939.00a3f840@atalanta.ctd.anl.gov> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) 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 have the problem of scoped addresses whether the "site local" mechanism > >is retained or not. Providing guidance on the responses an application is > >to receive in response to scoping controls (firewalls) would be useful > >regardless. If this problem is worth solving for the already-common case > >of firewalls, solving it for site-local addressing does not seem to be too > >much of a stretch. > > Exactly, the only thing an address with a site-local prefix tell me is that > a filtering router or firewall is guaranteed to be in some arbitrary > path. but you don't know which paths, so you don't know how to use that. > I'm mystified as to why an app would treat it any differently that > an IPv6 address generated with any other prefix. some people believe that SLs would be more secure than globals, even though this is an unwarranted assumption. some people believe they would be more stable than globals, but providing stable local addresses isn't a good solution to the renumbering problem - it's not as if all of the important apps affected by renumbering are local. some people believe SLs would be more efficient. some apps writers would avoid using SLs whenever possible because they're not portable (and they'll lose when SLs are all that are available), some apps writers will use them in preference to globals (and they'll lose when they're expected to communicate across site boundaries), and other apps writers will try to deal with all cases (adding a lot of complexity and still not able to avoid the app failing for apparently arbitrary reasons). any of these makes the behavior of apps less predictable. 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 Mon Apr 21 13:06:28 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 h3LK4tdv012717; Mon, 21 Apr 2003 13:06:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJvLka011507; Mon, 21 Apr 2003 12:57:21 -0700 (PDT) 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 h3LJgp93007269 for ; Mon, 21 Apr 2003 12:56:17 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3KDqXCB021345 for ; Sun, 20 Apr 2003 06:52:34 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id HAA25087 for ; Sun, 20 Apr 2003 07:52:28 -0600 (MDT) 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, 20 Apr 2003 13:52: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; Sun, 20 Apr 2003 13:48: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; Sun, 20 Apr 2003 13:52:21 Z Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 13:52:21 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3KDpbgE027959; Sun, 20 Apr 2003 06:51:37 -0700 (PDT) Received: from cisco.com (sjc-vpn2-421.cisco.com [10.21.113.165]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA22432; Sun, 20 Apr 2003 06:51:33 -0700 (PDT) Message-Id: <3EA2A5E4.3020304@cisco.com> Date: Sun, 20 Apr 2003 06:51:32 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Senie CC: Stephen Sprunk , ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A simple question References: <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14384.1050784134@munnari.OZ.AU> <20030419165921.782a8353.moore@cs.utk.edu> <5.2.1.1.2.20030419181122.0290c090@mail.amaranth.net> In-Reply-To: <5.2.1.1.2.20030419181122.0290c090@mail.amaranth.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Daniel Senie wrote: > Example of usage: I use RFC 1918 space for private networks within > server farms. There's no connection to the public network from this > private segment. Servers connect to both public and private networks. > Backups, NFS mounts, SNMP and SQL data flows over the private network. > The isolated network segment keeps traffic off the public network for > performance reasons. This has become an acceptable use of RFC 1918 addresses. On the other hand, there is no need to support this sort of use in the v6 architecture. The address space is simply too vast for people to have to economize like this. > All the world of private addressing is not NAT, regardless of how many > times people say it is. My major concern that does drive NAT is the expressed desire on the IPng list to isolate sites from having to renumber. That use of SLs requires NAT or proxy. Rob may call it crazy, but the demand is there right now. > I am saddened by the fact that Tony's simple question could not be > addressed. Site local addressing in IPv6 is a concept which has been > mentioned in RFC 1884, 2373 and 3513, the progression of Proposed > Standards. This is a string of documents dating back to 1995. For eight > years this concept was apparently considered a good thing. The > discussion on the mailing lists makes it sound like site-local > addressing is a new idea. I'd like to know why it's taken eight years > for folks to decide it's bad. Is it that folks are just now implementing > IPv6? Is it because the documents these eight years never made the > concept clear, and now it appears too hard to implement? In all those > years, has no vendor implemented site local? Are there any other > features we should reconsider as long as we're ripping the documents open? Quite simply it is something we seem to have forgotten about: learning from operational experience. Since 1995 the use of private address space has changed, as has been said. Also, I don't think people fully understood the ramifications of SLs. I certainly didn't, initially. We also learned that using EUI-64s as end identifiers has certain privacy considerations, so this is not a first. I think we do have to take some care when making changes to the addressing architecture. If the decision of the group holds, it seems to me that those of us who voted "YES" have the burden to now provide an alternative that addresses the real requirements that SLs attempt to tackle. > It is not unprecedented to change or remove a feature as a document > advances through the standards track. Such changes, however, can have > significant impact on already-implemented and deployed solutions. Such > matters should be considered carefully in that light. Perhaps removal of > features should receive substantially more scrutiny after publication on > the standards track. I agree. The vote was for deprecation. That means we need to deprecate in favor of something better. Happy holidays, 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 Apr 21 13:06:18 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 h3LK4tdl012717; Mon, 21 Apr 2003 13:06:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LJukfj011437; Mon, 21 Apr 2003 12:56:46 -0700 (PDT) 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 h3LJgp87007269 for ; Mon, 21 Apr 2003 12:55:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3K0thlm029430 for ; Sat, 19 Apr 2003 17:55:43 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA01549 for ; Sat, 19 Apr 2003 18:55:37 -0600 (MDT) 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, 20 Apr 2003 00:55: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; Sun, 20 Apr 2003 00:51: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; Sun, 20 Apr 2003 00:55:26 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 20 Apr 2003 00:55:24 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3K0sdL17597; Sat, 19 Apr 2003 19:54:39 -0500 Message-Id: <00c101c306d7$6c9698d0$93b58742@ssprunk> From: "Stephen Sprunk" To: , "Robert Elz" Cc: "Dave Crocker" , , References: <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16388.1050790957@munnari.OZ.AU> <200304192348.h3JNmxuL020301@turing-police.cc.vt.edu> Subject: Re: A simple question Date: Sat, 19 Apr 2003 19:51:54 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake > There's this big assumption on the part of the pro-site-local crew that > we "need" a stable address. I posit that this is a crock, and that > what we *need* to do is iron out the rough edges of IPv6 renumbering > so hosts don't care *what* they have, as long as they have *some* > prefix. Changing the address on a host's interface is easy -- too bad there's a lot more involved in renumbering. For one thing, we need a TCP that can support address changes during a session, and it can't rely on a deprecation period. Beyond that, we'll need widespread deployment of DDNS, which scares the heck out of most DNS admins I know, with or without PKI. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 13:33: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 h3LKXSZ5019221; Mon, 21 Apr 2003 13:33:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LKXSkq019220; Mon, 21 Apr 2003 13:33:28 -0700 (PDT) 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 h3LKXPZ5019213 for ; Mon, 21 Apr 2003 13:33:25 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3LKXOFC026120 for ; Mon, 21 Apr 2003 13:33:24 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA23411 for ; Mon, 21 Apr 2003 13:33:18 -0700 (PDT) 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, 21 Apr 2003 20:33: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, 21 Apr 2003 20:33: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; Mon, 21 Apr 2003 20:33:09 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; Mon, 21 Apr 2003 20:33:09 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 h3LKTvc15824; Mon, 21 Apr 2003 22:29:57 +0200 Message-Id: <3EA454C5.4050609@it.su.se> Date: Mon, 21 Apr 2003 22:29:57 +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: Keith Moore CC: Daniel Senie , stephen@sprunk.org, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A simple question References: <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14384.1050784134@munnari.OZ.AU> <20030419165921.782a8353.moore@cs.utk.edu> <5.2.1.1.2.20030419181122.0290c090@mail.amaranth.net> <20030419191507.75dfcc39.moore@cs.utk.edu> In-Reply-To: <20030419191507.75dfcc39.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: >because few serious applications people were in the discussion, and there >wasn't enough review by those people during Last Call. most apps people >probably assumed that the changes between IPv4 and IPv6 would be transparent >to them, other than having to use a different size for the address. > > > I believe this is essentially correct. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 14:14: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 h3LLEHZ5021142; Mon, 21 Apr 2003 14:14:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LLEHPg021141; Mon, 21 Apr 2003 14:14:17 -0700 (PDT) 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 h3LLEDZ5021131 for ; Mon, 21 Apr 2003 14:14:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3LLECFC009164 for ; Mon, 21 Apr 2003 14:14:13 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id OAA18951 for ; Mon, 21 Apr 2003 14:14:07 -0700 (PDT) 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, 21 Apr 2003 21:14: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; Mon, 21 Apr 2003 21:14: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; Mon, 21 Apr 2003 21:14:06 Z Received: from stewart.chicago.il.us (stewart.chicago.il.us [67.38.193.238]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 21 Apr 2003 21:14:06 Z Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h3LLCqac001212; Mon, 21 Apr 2003 16:12:52 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-Id: <3EA45ED4.9060508@stewart.chicago.il.us> Date: Mon, 21 Apr 2003 16:12:52 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore CC: Robert Elz , stephen@sprunk.org, Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question References: <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> <20030419192024.440d3773.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: >> | To assign more than one address to every host means the host must have >> | an intelligent means of deciding which address to use. >> >>Yes, but the amount of intelligence actually needed is pretty minimal. >>(It is actually harder to decide between multiple available global >>prefixes, than to decide between global and site local - the former is >>a difficult problem, the latter is almost trivial). > > > disagree. the app can choose any global prefix and reasonably expect it to > work, modulo link failures. but when choosing between a global and a site > local the app needs to know whether the site local address will be valid for > the hosts that need to use it, and it has no way to know this. the app may > also have to choose which interface to use with the site-local prefix, > and it has no good way to know this either. Keith: I agree 100%.. it is quite difficult to choose a site local... and a real pain to be able to tell which interface to use or if the peer host can really speak on that site local.... very very ugly... and I say this with respect to trying to make things work in the kame SCTP implementation.. As far as I am concerned we could do with-OUT site-locals.. but of course I have said this before too :> R > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 14:19: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 h3LLJbZ5021357; Mon, 21 Apr 2003 14:19:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LLJa0B021356; Mon, 21 Apr 2003 14:19:36 -0700 (PDT) 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 h3LLJXZ5021346 for ; Mon, 21 Apr 2003 14:19:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3LLJWuc004509 for ; Mon, 21 Apr 2003 14:19:32 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA21772 for ; Mon, 21 Apr 2003 14:19:27 -0700 (PDT) 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, 21 Apr 2003 21:19: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, 21 Apr 2003 21:15: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, 21 Apr 2003 21:19:26 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; Mon, 21 Apr 2003 21:19: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 OAA17865; Mon, 21 Apr 2003 14:19:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3LLJLq14648; Mon, 21 Apr 2003 14:19:21 -0700 X-mProtect: <200304212119> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMKReOG; Mon, 21 Apr 2003 14:19:20 PDT Message-Id: <3EA460F9.9000204@iprg.nokia.com> Date: Mon, 21 Apr 2003 14:22:01 -0700 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: Keith Moore CC: Daniel Senie , stephen@sprunk.org, RACarlson@anl.gov, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A simple question References: <20030419192024.440d3773.moore@cs.utk.edu> <16762.1050792143@munnari.OZ.AU> <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: >>b) if there's a strong need for appropriate >>ICMP responses to make IPv6 function well, then an RFC stating as much >>could be published. > > > like, for instance, a need for path mtu discovery to work reliably? > (since v6 routers don't fragment packets) This is veering a bit off topic, but in the plpmtud bof at IETF 56 we were shown a method for determining path mtu that does not rely on ICMPs. (ICMPs are untrustworthy and unreliable in any case, so let's stop this red herring before it goes any farther.) Thanks, 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 Mon Apr 21 14:28: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 h3LLSjZ5022128; Mon, 21 Apr 2003 14:28:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LLSjqU022127; Mon, 21 Apr 2003 14:28:45 -0700 (PDT) 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 h3LLSfZ5022117 for ; Mon, 21 Apr 2003 14:28:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3LLSeuc007660 for ; Mon, 21 Apr 2003 14:28:41 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id PAA24136 for ; Mon, 21 Apr 2003 15:28:30 -0600 (MDT) 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, 21 Apr 2003 21:27: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; Mon, 21 Apr 2003 21:23: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, 21 Apr 2003 21:27:36 Z Received: from stewart.chicago.il.us (stewart.chicago.il.us [67.38.193.238]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 21 Apr 2003 21:27:36 Z Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h3LLRAac001237; Mon, 21 Apr 2003 16:27:10 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-Id: <3EA4622E.9000900@stewart.chicago.il.us> Date: Mon, 21 Apr 2003 16:27:10 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Sprunk CC: Keith Moore , Robert Elz , Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question References: <00d001c306c0$faeadf90$93b58742@ssprunk><200304191923.h3JJNOuL018209@turing-police.cc.vt.edu><16890640984.20030419070719@brandenburg.com><002401c30605$e22da070$261e4104@eagleswings><9540645034.20030418171403@brandenburg.com><11870.1050777166@munnari.OZ.AU><14570.1050784897@munnari.OZ.AU><16762.1050792143@munnari.OZ.AU> <20030419192024.440d3773.moore@cs.utk.edu> <005f01c306d2$c33cdaf0$93b58742@ssprunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stephen Sprunk wrote: > Thus spake "Keith Moore" > >>> | To assign more than one address to every host means the host >>> | must have an intelligent means of deciding which address to use. >>> >>>Yes, but the amount of intelligence actually needed is pretty minimal. >>>(It is actually harder to decide between multiple available global >>>prefixes, than to decide between global and site local - the former is >>>a difficult problem, the latter is almost trivial). >> >>disagree. the app can choose any global prefix and reasonably expect >>it to work, modulo link failures. > > > Nit: the vast majority of apps today bind to INADDR_ANY (or its IPv6 > equivalent), so it's really the OS which is choosing the source address. If > the app binds a specific source address, it is invariably user-configurable > and thus not an application problem. > > Nit2Nit :> That may be.. but it sure does not help us poor kernel developers any :-< >>but when choosing between a global and a site local the app needs to >>know whether the site local address will be valid for the hosts that need >>to use it, and it has no way to know this. > > > Well, since one can easily determine whether the destination address is SL > or not, picking a source address of the correct class is trivial. > I don't know if that is true.. if a host has multiple sites on it and each site is multi-homed... aka -------Intf-A---+----------+----Intf-D------ | | -------Intf-B---+----------+----Intf-C------ Say Intf-A/Intf-B are on one site and Intf-C/Intf-D are on another site.. Then if the SCTP stack is told to send a INIT -> out to a SL address on Intf-A selecting the source address is somewhat ok if the routing is set up.. but what other addresses do I list in my INIT? Ideally I would like to list the address for A and B. This way my peer could take advantage of my multi-homing.. but instead I can't... since when the peer receives the INIT it would have no way of knowing the scope for the address and what interface the address went with... Other more complicated scenario's can also be imagined with the above.. multiple sites on each host.. some shared some not.. aakk... yuck... It seems to me that with all the available address space having a SL is just a waste.. If an enterprise is worried about security put up something that is real aka a firewall.. not a NAT...It does not really add anything but it does drag along an ugly abomination that was needed as a stop-gap measure for the address shortfall.. Now we have the solution we are dragging the old junk along.. how silly... This SL thing seems to me like a un-needed complication.. > >>the app may also have to choose which interface to use with the site- >>local prefix, and it has no good way to know this either. > > > Ah, but it'll have a different SL address on each interface, so that's no > worse than having multiple global addresses. The truly interesting case is > connecting to a LL address with multiple interfaces. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 21 15:46: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 h3LMkSZ5023402; Mon, 21 Apr 2003 15:46:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3LMkSZp023401; Mon, 21 Apr 2003 15:46:28 -0700 (PDT) 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 h3LMkPZ5023394 for ; Mon, 21 Apr 2003 15:46:25 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3LMkOuc029329 for ; Mon, 21 Apr 2003 15:46:24 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA07507 for ; Mon, 21 Apr 2003 16:46:17 -0600 (MDT) 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, 21 Apr 2003 22:46: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, 21 Apr 2003 22:42: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, 21 Apr 2003 22:46:16 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, 21 Apr 2003 22:46:16 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 XAA06023 for ; Mon, 21 Apr 2003 23:46:12 +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 XAA08274 for ; Mon, 21 Apr 2003 23:46:12 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3LMkCg05981 for ipng@sunroof.eng.sun.com; Mon, 21 Apr 2003 23:46:12 +0100 Date: Mon, 21 Apr 2003 23:46:12 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Availability of recorded IETF 56 sessions... Message-Id: <20030421224612.GQ2231@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 Now those who missed the IPv6 Thursday "site local" session can see what really happened :) (Beware just the audio track alone is 100MB) Tim On Mon, Apr 21, 2003 at 03:14:01PM -0700, Joel Jaeggli wrote: > I am pleased to announce the availability of the meetings recorded during > the week of IETF56. They are available at: > > http://videolab.uoregon.edu/events/ietf/ietf56.html#archive > > or > > ftp://limestone.uoregon.edu/pub/videolab/video/ietf56 > > -- > -------------------------------------------------------------------------- > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > In Dr. Johnson's famous dictionary patriotism is defined as the last > resort of the scoundrel. With all due respect to an enlightened but > inferior lexicographer I beg to submit that it is the first. > -- Ambrose Bierce, "The Devil's Dictionary" > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 00:37:12 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 h3M7bCZ5028121; Tue, 22 Apr 2003 00:37:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3M7bBke028120; Tue, 22 Apr 2003 00:37:11 -0700 (PDT) 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 h3M7b8Z5028113 for ; Tue, 22 Apr 2003 00:37:08 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3M7bFFC003964 for ; Tue, 22 Apr 2003 00:37:15 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id BAA14121 for ; Tue, 22 Apr 2003 01:37:10 -0600 (MDT) From: john.loughney@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, 22 Apr 2003 07:37:09 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, 22 Apr 2003 07:37: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; Tue, 22 Apr 2003 07:37:09 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, 22 Apr 2003 07:37:08 Z Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3M7b7718117 for ; Tue, 22 Apr 2003 10:37:07 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Apr 2003 10:37:06 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Apr 2003 10:37:05 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Apr 2003 10:37:05 +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: A simple question Date: Tue, 22 Apr 2003 10:36:55 +0300 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A simple question Thread-Index: AcMIPAuwi+fj+x7kQP2Cd4Whg5g6YAAZDACw To: Cc: , X-OriginalArrivalTime: 22 Apr 2003 07:37:05.0038 (UTC) FILETIME=[F89E32E0:01C308A1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3M7b8Z5028114 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Keith, One comment: > > Usage alters to meet the demands of the users. That's nothing new. > > > > | on the contrary, having an enterprise use both SLs and globals creates > > | significant new problems of its own, and results in even less > > | flexibility than if SLs were used only by isolated networks. > > > > Nothing that IPv4 doesn't have as well (if perhaps less commonly). > > there's a reason that most v4 hosts don't have multiple addresses with varying > scopes - it doesn't work well, and it creates problems for apps. putting > sitelocals in v6 is trying to impose those problems on all host. I'd suggest that there has not been much of demand for this kind of functionality. Most hosts have had only a single interface, so there is not a lot of reason to give a single interface multiple addresses. Already we are seeing laptops with multiple interfaces (Ethernet, WLAN, Bluetooth, etc.) - I think it is only a matter of time that applications start to take advantage of this. One use case for this kind of functionality would be a cell phone that has some sort of expensive cellular data connnection but also has WLAN / Bluetooth interfaces. In a WLAN hotspot, data could/should go over that interface as opposed to the cellular interface. However, the cellular interface might be used to provide WAN coverage ... A lot of this is OS / implementation specific stuff, but I don't understand why this should not be supported in standards. 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 Tue Apr 22 02:09: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 h3M99HZ5029705; Tue, 22 Apr 2003 02:09:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3M99HfP029704; Tue, 22 Apr 2003 02:09:17 -0700 (PDT) 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 h3M99DZ5029697 for ; Tue, 22 Apr 2003 02:09:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3M99Kuc024604 for ; Tue, 22 Apr 2003 02:09:21 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA10220 for ; Tue, 22 Apr 2003 03:09:15 -0600 (MDT) 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, 22 Apr 2003 09:08: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, 22 Apr 2003 09:08:50 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, 22 Apr 2003 09:08:50 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 22 Apr 2003 09:08:49 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3M98gL05137; Tue, 22 Apr 2003 04:08:42 -0500 Message-Id: <023c01c308ae$c6252280$93b58742@ssprunk> From: "Stephen Sprunk" To: , Cc: , References: Subject: Re: A simple question Date: Tue, 22 Apr 2003 04:08:35 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake > Already we are seeing laptops with multiple interfaces (Ethernet, > WLAN, Bluetooth, etc.) - I think it is only a matter of time that > applications start to take advantage of this. I see it as a failure of the network layer if applications need to distinguish between multiple interfaces or address scopes. While many don't see the distinction, this is the kind of stuff that desperately needs to be in the OS/stack -- if anywhere. Applications should not know about network-level details unless they have a specific reason to care, and if anything more than a small majority of applications care, there is something wrong with our model. Most applications today cannot even handle the case of multiple A records for a destination host; do we really expect _tens of thousands_ of applications to be updated with source-address-picking intelligence? > A lot of this is OS / implementation specific stuff, but I don't understand > why this should not be supported in standards. The approach to other problems, such as QOS, is to provide a common architecture and terminology, then let the individual vendors provide their own (often creative) solutions within those confines. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 03:51: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 h3MApOZ5000836; Tue, 22 Apr 2003 03:51:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3MApOFk000835; Tue, 22 Apr 2003 03:51:24 -0700 (PDT) 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 h3MApJZ5000819 for ; Tue, 22 Apr 2003 03:51:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3MApQuc008805 for ; Tue, 22 Apr 2003 03:51:26 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA26494 for ; Tue, 22 Apr 2003 04:51:21 -0600 (MDT) 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, 22 Apr 2003 10:51: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; Tue, 22 Apr 2003 10:47: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, 22 Apr 2003 10:51:19 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 22 Apr 2003 10:51:19 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3MAokv07736; Tue, 22 Apr 2003 13:50:46 +0300 Date: Tue, 22 Apr 2003 13:50:45 +0300 (EEST) From: Pekka Savola To: Bill Manning cc: john heasley , , , , , , , , Subject: Re: A simple question In-Reply-To: <200304200425.h3K4Pxw19463@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 Sat, 19 Apr 2003, Bill Manning wrote: [...] > we now have special blocks of IPv6 space that are not > supposed to be aggregated for things like exchanges. > massive aggregation is expected, except for these "special > prefixes". One more administrative thing to track. :( Please stop this. There is nothing of the kind. The prefixes are not special. They are not expected to be routable, so there are no additional administrative things to track. Addressing for exchanges killed the need to using LL's with BGP, as simple as that. -- 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 Apr 22 05:32:58 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 h3MCWwZ5001289; Tue, 22 Apr 2003 05:32:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3MCWwIW001288; Tue, 22 Apr 2003 05:32:58 -0700 (PDT) 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 h3MCWsZ5001281 for ; Tue, 22 Apr 2003 05:32:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3MCWwuc022115 for ; Tue, 22 Apr 2003 05:32:58 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3MCWqrZ016666 for ; Tue, 22 Apr 2003 05:32:53 -0700 (PDT) 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, 22 Apr 2003 12:32: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, 22 Apr 2003 12:32:50 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, 22 Apr 2003 12:32:50 Z Received: from eikenes.alvestrand.no ([217.13.28.204] [217.13.28.204]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 22 Apr 2003 12:32:49 Z Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 75CFD62571; Tue, 22 Apr 2003 14:32:46 +0200 (CEST) Date: Tue, 22 Apr 2003 14:32:46 +0200 From: Harald Tveit Alvestrand To: alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Cc: ietf@ietf.org Subject: Re: A simple question Message-Id: <438340000.1051014766@askvoll.hjemme.alvestrand.no> In-Reply-To: <001a01c305f7$a902cd60$261e4104@eagleswings> References: <001a01c305f7$a902cd60$261e4104@eagleswings> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk just to provide a "simple" answer to a simple question: NO - I do not agree with Keith's assertion as quoted. YES - I agree with what I *believe* Keith wanted to say, which is that "introduction of *site-scoped* addresses causes far more problems than it solves". I do NOT believe that introduction of link-local addresses causes far more problems than it solves. My position on SL should be well known. I'll try to avoid repeating the rest of my arguments once again in this discussion tree. Harald --On fredag, april 18, 2003 15:12:54 -0700 Tony Hain wrote: > Keith Moore wrote: >> It doesn't solve all problems, but introduction of >> scoped addresses causes far more problems than it solves. > > I would like to understand how many people that voted YES on the > question of deprecating SL concur with Keith's assertion. > > Tony > > Note: I cc'd the IETF list to catch those who may have been in the room > in SF, but aren't on the IPv6 list. > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 22 06:37:30 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 h3MDbTZ5002199; Tue, 22 Apr 2003 06:37:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3MDbTN0002198; Tue, 22 Apr 2003 06:37:29 -0700 (PDT) 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 h3MDbPZ5002191 for ; Tue, 22 Apr 2003 06:37:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3MDbWuc003162 for ; Tue, 22 Apr 2003 06:37:32 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id HAA21895 for ; Tue, 22 Apr 2003 07:37:26 -0600 (MDT) 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, 22 Apr 2003 13:37: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; Tue, 22 Apr 2003 13:37: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; Tue, 22 Apr 2003 13:37:26 Z Received: from grouse.mail.pas.earthlink.net (grouse.mail.pas.earthlink.net [207.217.120.116]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 22 Apr 2003 13:37:25 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 197xxV-0004I8-00; Tue, 22 Apr 2003 06:37:17 -0700 Date: Tue, 22 Apr 2003 09:36:49 -0400 From: Keith Moore To: Harald Tveit Alvestrand Cc: moore@cs.utk.edu, alh-ietf@tndh.net, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question Message-Id: <20030422093649.644d0eef.moore@cs.utk.edu> In-Reply-To: <438340000.1051014766@askvoll.hjemme.alvestrand.no> References: <001a01c305f7$a902cd60$261e4104@eagleswings> <438340000.1051014766@askvoll.hjemme.alvestrand.no> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > just to provide a "simple" answer to a simple question: > > NO - I do not agree with Keith's assertion as quoted. > YES - I agree with what I *believe* Keith wanted to say, which is that > "introduction of *site-scoped* addresses causes far more problems than it > solves". > > I do NOT believe that introduction of link-local addresses causes far more > problems than it solves. I see scoped addressing as a general problem, of which v6 site-locals and v4 link-locals are both examples. That said, I think v6 link-locals as "mostly harmless" provided that we use them only for things like router discovery. If we started expecting ordinary applications to be able to use them, I'd move them back to the "harmful" category - they'd have most of the problems of site-locals. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 07:10: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 h3MEAqZ5002906; Tue, 22 Apr 2003 07:10:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3MEAqR2002905; Tue, 22 Apr 2003 07:10:52 -0700 (PDT) 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 h3MEAmZ5002898 for ; Tue, 22 Apr 2003 07:10:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3MEAuuc009583 for ; Tue, 22 Apr 2003 07:10:56 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id IAA09349 for ; Tue, 22 Apr 2003 08:10:44 -0600 (MDT) 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, 22 Apr 2003 14:09: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; Tue, 22 Apr 2003 14:05: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; Tue, 22 Apr 2003 14:09:30 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; Tue, 22 Apr 2003 14:09:30 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-6.3) with ESMTP id h3ME9EXa028544; Tue, 22 Apr 2003 17:09:14 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.3) id h3ME9EWG028540; Tue, 22 Apr 2003 17:09:14 +0300 Date: Tue, 22 Apr 2003 17:09:14 +0300 Message-Id: <200304221409.h3ME9EWG028540@burp.tkv.asdf.org> From: Markku Savela To: randall@stewart.chicago.il.us CC: ipng@sunroof.eng.sun.com In-reply-to: <3EA4622E.9000900@stewart.chicago.il.us> (message from Randall Stewart on Mon, 21 Apr 2003 16:27:10 -0500) Subject: Re: A simple question References: <00d001c306c0$faeadf90$93b58742@ssprunk><200304191923.h3JJNOuL018209@turing-police.cc.vt.edu><16890640984.20030419070719@brandenburg.com><002401c30605$e22da070$261e4104@eagleswings><9540645034.20030418171403@brandenburg.com><11870.1050777166@munnari.OZ.AU><14570.1050784897@munnari.OZ.AU><16762.1050792143@munnari.OZ.AU> <20030419192024.440d3773.moore@cs.utk.edu> <005f01c306d2$c33cdaf0$93b58742@ssprunk> <3EA4622E.9000900@stewart.chicago.il.us> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I cleaned up the CC-list, as this reply is techical, not IETF issue] > From: Randall Stewart > > I don't know if that is true.. if a host has multiple sites > on it and each site is multi-homed... aka > > -------Intf-A---+----------+----Intf-D------ > | | > -------Intf-B---+----------+----Intf-C------ > > Say Intf-A/Intf-B are on one site > and > Intf-C/Intf-D are on another site.. I'm not sure I can read above correct. Do you mean (e.g. a node has 4 interfaces as follows?): ----Intf-A---+ +----Intf-D- |-- node --| ---Intf-B---+ +----Intf-C- > Then if the SCTP stack is told to send a INIT -> out to a SL > address on Intf-A selecting the source address is somewhat ok > if the routing is set up.. but what other addresses do I list > in my INIT? Any other SL addresses from Intf-A and Intf-B (and perhaps globals from any interface, but would prefer always to use only addresses of matching scopes). If destination is global, you do not include SL addresses. > Ideally I would like to list the address for A and B. This way > my peer could take advantage of my multi-homing.. but instead > I can't... since when the peer receives the INIT it would have > no way of knowing the scope for the address and what interface > the address went with... Yes, it would. The scope id for the SL's are just picked from the incoming interface. Actual values for the id's are totally local to the node, and can be generated internally. The only external configuration is to tell which interfaces belong to same site, actual id numbers need never be referenced by the configuration. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 07:34:10 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 h3MEYAZ5003292; Tue, 22 Apr 2003 07:34:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3MEYAvM003291; Tue, 22 Apr 2003 07:34:10 -0700 (PDT) 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 h3MEY6Z5003284 for ; Tue, 22 Apr 2003 07:34:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3MEYDuc014148 for ; Tue, 22 Apr 2003 07:34:14 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id IAA19978 for ; Tue, 22 Apr 2003 08:34:06 -0600 (MDT) 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, 22 Apr 2003 14:33: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; Tue, 22 Apr 2003 14:33: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; Tue, 22 Apr 2003 14:33:00 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, 22 Apr 2003 14:33:00 Z Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3MEWJdL026934; Tue, 22 Apr 2003 07:32:37 -0700 (PDT) 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.3.3-GR) with ESMTP id ADL18709; Tue, 22 Apr 2003 07:32:18 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA28755; Tue, 22 Apr 2003 07:32:18 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16037.21106.90189.154803@thomasm-u1.cisco.com> Date: Tue, 22 Apr 2003 07:32:18 -0700 (PDT) To: Markku Savela Cc: randall@stewart.chicago.il.us, ipng@sunroof.eng.sun.com Subject: Re: A simple question In-Reply-To: <200304221409.h3ME9EWG028540@burp.tkv.asdf.org> References: <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> <20030419192024.440d3773.moore@cs.utk.edu> <005f01c306d2$c33cdaf0$93b58742@ssprunk> <3EA4622E.9000900@stewart.chicago.il.us> <200304221409.h3ME9EWG028540@burp.tkv.asdf.org> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There seems to be an underlying assumption that address selection wrt site locals presumes a policy that site-locals are preferable (security, reachability...) to globals where the narrower scopes allow communication. Is there any reason to believe that this implicit policy is the only one people will cook up, and that there won't be other policies in the future? If not, what are the implications for address selection? At some level we need to deal with multiple addresses due to multihoming, but the combinatorics when you start adding other kinds of addresses, scoping, policies, and transience considerations seems, well, a heck of lot more complicated that the socket (), gethostbyname(), and connect() most apps do today. Mike Markku Savela writes: > [I cleaned up the CC-list, as this reply is techical, not IETF issue] > > > From: Randall Stewart > > > > I don't know if that is true.. if a host has multiple sites > > on it and each site is multi-homed... aka > > > > -------Intf-A---+----------+----Intf-D------ > > | | > > -------Intf-B---+----------+----Intf-C------ > > > > Say Intf-A/Intf-B are on one site > > and > > Intf-C/Intf-D are on another site.. > > I'm not sure I can read above correct. Do you mean (e.g. a node has 4 > interfaces as follows?): > > ----Intf-A---+ +----Intf-D- > |-- node --| > ---Intf-B---+ +----Intf-C- > > > Then if the SCTP stack is told to send a INIT -> out to a SL > > address on Intf-A selecting the source address is somewhat ok > > if the routing is set up.. but what other addresses do I list > > in my INIT? > > Any other SL addresses from Intf-A and Intf-B (and perhaps globals > from any interface, but would prefer always to use only addresses of > matching scopes). If destination is global, you do not include SL > addresses. > > > Ideally I would like to list the address for A and B. This way > > my peer could take advantage of my multi-homing.. but instead > > I can't... since when the peer receives the INIT it would have > > no way of knowing the scope for the address and what interface > > the address went with... > > Yes, it would. The scope id for the SL's are just picked from the > incoming interface. > > Actual values for the id's are totally local to the node, and can be > generated internally. The only external configuration is to tell which > interfaces belong to same site, actual id numbers need never be > referenced by the configuration. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 22 07:44: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 h3MEihZ5003595; Tue, 22 Apr 2003 07:44:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3MEihve003594; Tue, 22 Apr 2003 07:44:43 -0700 (PDT) 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 h3MEicZ5003578 for ; Tue, 22 Apr 2003 07:44:38 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3MEijuc016407 for ; Tue, 22 Apr 2003 07:44:46 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3MEierZ011604 for ; Tue, 22 Apr 2003 07:44:40 -0700 (PDT) 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, 22 Apr 2003 14:44: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; Tue, 22 Apr 2003 14:44:30 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, 22 Apr 2003 14:44:29 Z Received: from stewart.chicago.il.us (stewart.chicago.il.us [67.38.193.238]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 22 Apr 2003 14:44:29 Z Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h3MEiGac003017; Tue, 22 Apr 2003 09:44:16 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-Id: <3EA55540.7080900@stewart.chicago.il.us> Date: Tue, 22 Apr 2003 09:44:16 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas CC: Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: A simple question References: <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> <20030419192024.440d3773.moore@cs.utk.edu> <005f01c306d2$c33cdaf0$93b58742@ssprunk> <3EA4622E.9000900@stewart.chicago.il.us> <200304221409.h3ME9EWG028540@burp.tkv.asdf.org> <16037.21106.90189.154803@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > There seems to be an underlying assumption that > address selection wrt site locals presumes a > policy that site-locals are preferable (security, > reachability...) to globals where the narrower > scopes allow communication. > yep .. one never knows what slick things the users will want to cook up.. > Is there any reason to believe that this implicit > policy is the only one people will cook up, and > that there won't be other policies in the future? > If not, what are the implications for address > selection? > > At some level we need to deal with multiple > addresses due to multihoming, but the > combinatorics when you start adding other kinds of > addresses, scoping, policies, and transience > considerations seems, well, a heck of lot more > complicated that the socket (), gethostbyname(), > and connect() most apps do today. > Yep. and even more pain will then come forth for us poor kernel hackers :-0 You said it a lot more elogantly than I .. as usual but you are smack on... R > Mike > > Markku Savela writes: > > [I cleaned up the CC-list, as this reply is techical, not IETF issue] > > > > > From: Randall Stewart > > > > > > I don't know if that is true.. if a host has multiple sites > > > on it and each site is multi-homed... aka > > > > > > -------Intf-A---+----------+----Intf-D------ > > > | | > > > -------Intf-B---+----------+----Intf-C------ > > > > > > Say Intf-A/Intf-B are on one site > > > and > > > Intf-C/Intf-D are on another site.. > > > > I'm not sure I can read above correct. Do you mean (e.g. a node has 4 > > interfaces as follows?): > > > > ----Intf-A---+ +----Intf-D- > > |-- node --| > > ---Intf-B---+ +----Intf-C- > > > > > Then if the SCTP stack is told to send a INIT -> out to a SL > > > address on Intf-A selecting the source address is somewhat ok > > > if the routing is set up.. but what other addresses do I list > > > in my INIT? > > > > Any other SL addresses from Intf-A and Intf-B (and perhaps globals > > from any interface, but would prefer always to use only addresses of > > matching scopes). If destination is global, you do not include SL > > addresses. > > > > > Ideally I would like to list the address for A and B. This way > > > my peer could take advantage of my multi-homing.. but instead > > > I can't... since when the peer receives the INIT it would have > > > no way of knowing the scope for the address and what interface > > > the address went with... > > > > Yes, it would. The scope id for the SL's are just picked from the > > incoming interface. > > > > Actual values for the id's are totally local to the node, and can be > > generated internally. The only external configuration is to tell which > > interfaces belong to same site, actual id numbers need never be > > referenced by the configuration. > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 07:45: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 h3MEj5Z5003623; Tue, 22 Apr 2003 07:45:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3MEj4FX003622; Tue, 22 Apr 2003 07:45:04 -0700 (PDT) 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 h3MEixZ5003615 for ; Tue, 22 Apr 2003 07:44:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3MEj6FC022203 for ; Tue, 22 Apr 2003 07:45:06 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id HAA06895 for ; Tue, 22 Apr 2003 07:45:01 -0700 (PDT) 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, 22 Apr 2003 14:41: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, 22 Apr 2003 14:41: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, 22 Apr 2003 14:41:49 Z Received: from stewart.chicago.il.us (stewart.chicago.il.us [67.38.193.238]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 22 Apr 2003 14:41:49 Z Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id h3MEfdac003014; Tue, 22 Apr 2003 09:41:40 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-Id: <3EA554A3.1000500@stewart.chicago.il.us> Date: Tue, 22 Apr 2003 09:41:39 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markku Savela CC: ipng@sunroof.eng.sun.com Subject: Re: A simple question References: <00d001c306c0$faeadf90$93b58742@ssprunk><200304191923.h3JJNOuL018209@turing-police.cc.vt.edu><16890640984.20030419070719@brandenburg.com><002401c30605$e22da070$261e4104@eagleswings><9540645034.20030418171403@brandenburg.com><11870.1050777166@munnari.OZ.AU><14570.1050784897@munnari.OZ.AU><16762.1050792143@munnari.OZ.AU> <20030419192024.440d3773.moore@cs.utk.edu> <005f01c306d2$c33cdaf0$93b58742@ssprunk> <3EA4622E.9000900@stewart.chicago.il.us> <200304221409.h3ME9EWG028540@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela wrote: > [I cleaned up the CC-list, as this reply is techical, not IETF issue] > > >>From: Randall Stewart >> >>I don't know if that is true.. if a host has multiple sites >>on it and each site is multi-homed... aka >> >>-------Intf-A---+----------+----Intf-D------ >> | | >>-------Intf-B---+----------+----Intf-C------ >> >>Say Intf-A/Intf-B are on one site >>and >>Intf-C/Intf-D are on another site.. > > > I'm not sure I can read above correct. Do you mean (e.g. a node has 4 > interfaces as follows?): > > ----Intf-A---+ +----Intf-D- > |-- node --| > ---Intf-B---+ +----Intf-C- > Yep... > >>Then if the SCTP stack is told to send a INIT -> out to a SL >>address on Intf-A selecting the source address is somewhat ok >>if the routing is set up.. but what other addresses do I list >>in my INIT? > > > Any other SL addresses from Intf-A and Intf-B (and perhaps globals > from any interface, but would prefer always to use only addresses of > matching scopes). If destination is global, you do not include SL > addresses. > Yes, if you send to a SL you can include all the globals (for sure). But you really don't know what SL's to include unless you somehow have some configuration that tells you what site the interfaces belong to... This may be a scope variable or some such.. but it is a real pain.. it can be done.. but a pain... > >>Ideally I would like to list the address for A and B. This way >>my peer could take advantage of my multi-homing.. but instead >>I can't... since when the peer receives the INIT it would have >>no way of knowing the scope for the address and what interface >>the address went with... > > > Yes, it would. The scope id for the SL's are just picked from the > incoming interface. > > Actual values for the id's are totally local to the node, and can be > generated internally. The only external configuration is to tell which > interfaces belong to same site, actual id numbers need never be > referenced by the configuration. Yes.. in theory one would need to have the SL's configured in such a way that they had the same scope.. then when you figure out what interface you are routing out (via the route table) one could then find the scope_id and hunt back through the addresses... but this of course is like I said a pain and a lot of cycles for something I just don't understand the need for.. R > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 08:00: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 h3MF0hZ5004275; Tue, 22 Apr 2003 08:00:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3MF0gOP004274; Tue, 22 Apr 2003 08:00:42 -0700 (PDT) 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 h3MF0dZ5004267 for ; Tue, 22 Apr 2003 08:00:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3MF0kFC029488 for ; Tue, 22 Apr 2003 08:00:46 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3MF0erZ019838 for ; Tue, 22 Apr 2003 08:00:40 -0700 (PDT) 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, 22 Apr 2003 15:00:39 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, 22 Apr 2003 14:56: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, 22 Apr 2003 15:00:38 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; Tue, 22 Apr 2003 15:00:37 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-6.3) with ESMTP id h3MF0UXa028765; Tue, 22 Apr 2003 18:00:30 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.3) id h3MF0UNY028761; Tue, 22 Apr 2003 18:00:30 +0300 Date: Tue, 22 Apr 2003 18:00:30 +0300 Message-Id: <200304221500.h3MF0UNY028761@burp.tkv.asdf.org> From: Markku Savela To: mat@cisco.com CC: randall@stewart.chicago.il.us, ipng@sunroof.eng.sun.com In-reply-to: <16037.21106.90189.154803@thomasm-u1.cisco.com> (message from Michael Thomas on Tue, 22 Apr 2003 07:32:18 -0700 (PDT)) Subject: Re: A simple question References: <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> <20030419192024.440d3773.moore@cs.utk.edu> <005f01c306d2$c33cdaf0$93b58742@ssprunk> <3EA4622E.9000900@stewart.chicago.il.us> <200304221409.h3ME9EWG028540@burp.tkv.asdf.org> <16037.21106.90189.154803@thomasm-u1.cisco.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Michael Thomas > > At some level we need to deal with multiple > addresses due to multihoming, but the > combinatorics when you start adding other kinds of > addresses, scoping, policies, and transience > considerations seems, well, a heck of lot more > complicated that the socket (), gethostbyname(), > and connect() most apps do today. Any application using that sequence will continue working as before, even in presense of 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 Tue Apr 22 08:18: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 h3MFInZ5004708; Tue, 22 Apr 2003 08:18:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3MFInLd004707; Tue, 22 Apr 2003 08:18:49 -0700 (PDT) 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 h3MFIjZ5004700 for ; Tue, 22 Apr 2003 08:18:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3MFIruc024526 for ; Tue, 22 Apr 2003 08:18:53 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3MFIlrZ028671 for ; Tue, 22 Apr 2003 08:18:47 -0700 (PDT) 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, 22 Apr 2003 15:18: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; Tue, 22 Apr 2003 15:18:46 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, 22 Apr 2003 15:18:08 Z Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 22 Apr 2003 15:18:07 Z Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3MFE3n2019474; Tue, 22 Apr 2003 08:14:04 -0700 (PDT) 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.3.3-GR) with ESMTP id ADL21427; Tue, 22 Apr 2003 08:14:03 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA28997; Tue, 22 Apr 2003 08:14:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16037.23611.89801.711987@thomasm-u1.cisco.com> Date: Tue, 22 Apr 2003 08:14:03 -0700 (PDT) To: Markku Savela Cc: mat@cisco.com, randall@stewart.chicago.il.us, ipng@sunroof.eng.sun.com Subject: Re: A simple question In-Reply-To: <200304221500.h3MF0UNY028761@burp.tkv.asdf.org> References: <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> <20030419192024.440d3773.moore@cs.utk.edu> <005f01c306d2$c33cdaf0$93b58742@ssprunk> <3EA4622E.9000900@stewart.chicago.il.us> <200304221409.h3ME9EWG028540@burp.tkv.asdf.org> <16037.21106.90189.154803@thomasm-u1.cisco.com> <200304221500.h3MF0UNY028761@burp.tkv.asdf.org> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela writes: > > From: Michael Thomas > > > > At some level we need to deal with multiple > > addresses due to multihoming, but the > > combinatorics when you start adding other kinds of > > addresses, scoping, policies, and transience > > considerations seems, well, a heck of lot more > > complicated that the socket (), gethostbyname(), > > and connect() most apps do today. > > Any application using that sequence will continue working as before, > even in presense of SL's. Really? I think you're making some pretty large assumptions about DNS doing the right thing, for one. And a lot more assumptions about the stack finishing the job. Not to mention the unstated assumption that DNS and the stack are the right places to hide those selection details. Why should you assume any of this? 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 Apr 22 08:20:04 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 h3MFK3Z5004756; Tue, 22 Apr 2003 08:20:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3MFK3Fe004755; Tue, 22 Apr 2003 08:20:03 -0700 (PDT) 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 h3MFK0Z5004748 for ; Tue, 22 Apr 2003 08:20:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3MFK7FC004817 for ; Tue, 22 Apr 2003 08:20:07 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA04507 for ; Tue, 22 Apr 2003 09:20:02 -0600 (MDT) 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, 22 Apr 2003 15:20: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; Tue, 22 Apr 2003 15:20: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; Tue, 22 Apr 2003 15:20:00 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; Tue, 22 Apr 2003 15:19:59 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-6.3) with ESMTP id h3MFJtXa029139; Tue, 22 Apr 2003 18:19:55 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.3) id h3MFJtlj029135; Tue, 22 Apr 2003 18:19:55 +0300 Date: Tue, 22 Apr 2003 18:19:55 +0300 Message-Id: <200304221519.h3MFJtlj029135@burp.tkv.asdf.org> From: Markku Savela To: randall@stewart.chicago.il.us CC: ipng@sunroof.eng.sun.com In-reply-to: <3EA554A3.1000500@stewart.chicago.il.us> (message from Randall Stewart on Tue, 22 Apr 2003 09:41:39 -0500) Subject: Re: A simple question References: <00d001c306c0$faeadf90$93b58742@ssprunk><200304191923.h3JJNOuL018209@turing-police.cc.vt.edu><16890640984.20030419070719@brandenburg.com><002401c30605$e22da070$261e4104@eagleswings><9540645034.20030418171403@brandenburg.com><11870.1050777166@munnari.OZ.AU><14570.1050784897@munnari.OZ.AU><16762.1050792143@munnari.OZ.AU> <20030419192024.440d3773.moore@cs.utk.edu> <005f01c306d2$c33cdaf0$93b58742@ssprunk> <3EA4622E.9000900@stewart.chicago.il.us> <200304221409.h3ME9EWG028540@burp.tkv.asdf.org> <3EA554A3.1000500@stewart.chicago.il.us> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Randall Stewart > > ----Intf-A---+ +----Intf-D- > > |-- node --| > > ---Intf-B---+ +----Intf-C- > > > Yes, if you send to a SL you can include all the globals (for sure). But > you really don't know what SL's to include unless you somehow have > some configuration that tells you what site the interfaces belong to... Not really difficult. Each interface includes array of zone ids. If you are passing multiple addresses now, I presume you have something like follows: for (all interfaces) include addresses by some logic; In scoped architecture, the above would change into level = scope_level(destination address); destid = destination_interface->zone[level]; for (all interafaces) if (interface->zone[level] == destid) include address with "scope >= level"; Yes, somewhat more convoluted, maybe a small pain :-) > Yes.. in theory one would need to have the SL's configured > in such a way that they had the same scope.. then when > you figure out what interface you are routing out (via the route > table) one could then find the scope_id and hunt back through the > addresses... but this of course is like I said a pain and a lot > of cycles for something I just don't understand the need for.. All you need is the zone-id vector in interfaces. If destination is SL with 'site-id', then route search will not match routes that point to interface with interface->zone[site-level] != site-id. Yes, another additional "pain" in implementation, but I don't see this too difficult. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 10:01: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 h3MH1qhs007124; Tue, 22 Apr 2003 10:01:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3MH1qkc007123; Tue, 22 Apr 2003 10:01:52 -0700 (PDT) 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 h3MH1lhs007110 for ; Tue, 22 Apr 2003 10:01:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3MH1sFC006969 for ; Tue, 22 Apr 2003 10:01:54 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA19669 for ; Tue, 22 Apr 2003 11:01:49 -0600 (MDT) 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, 22 Apr 2003 17:01: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; Tue, 22 Apr 2003 16:57: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, 22 Apr 2003 17:01:48 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; Tue, 22 Apr 2003 17:01:46 Z Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h3MGvlA27382; Tue, 22 Apr 2003 09:57:47 -0700 (PDT) From: Bill Manning Message-Id: <200304221657.h3MGvlA27382@boreas.isi.edu> Subject: Re: A simple question In-Reply-To: from Pekka Savola at "Apr 22, 3 01:50:45 pm" To: pekkas@netcore.fi (Pekka Savola) Date: Tue, 22 Apr 2003 09:57:47 -0700 (PDT) Cc: bmanning@ISI.EDU, heas@shrubbery.net, jabley@isc.org, moore@cs.utk.edu, kre@munnari.OZ.AU, Valdis.Kletnieks@vt.edu, dcrocker@brandenburg.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 Sat, 19 Apr 2003, Bill Manning wrote: % [...] % > we now have special blocks of IPv6 space that are not % > supposed to be aggregated for things like exchanges. % > massive aggregation is expected, except for these "special % > prefixes". One more administrative thing to track. :( % % Please stop this. There is nothing of the kind. The prefixes are not % special. They are not expected to be routable, so there are no additional % administrative things to track. stop what? telling people that RIRs have created special use prefixes for things link exchanges that for every technical purpose are global unicast addresses which have to be administratively dealt with so that they are not routed? % Addressing for exchanges killed the need to using LL's with BGP, as simple % as that. When it would have been so much easier to just use LLs. Its a perfect fit for LLs. % Pekka Savola "You each name yourselves king, yet the % Netcore Oy kingdom bleeds." % Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --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 Tue Apr 22 20:13:10 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 h3N3DAhs012437; Tue, 22 Apr 2003 20:13:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3N3D9ba012436; Tue, 22 Apr 2003 20:13:09 -0700 (PDT) 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 h3N3D5hs012429 for ; Tue, 22 Apr 2003 20:13:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3N3DCuc005078 for ; Tue, 22 Apr 2003 20:13:12 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id VAA05314 for ; Tue, 22 Apr 2003 21:13:07 -0600 (MDT) 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, 23 Apr 2003 03:13:02 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, 23 Apr 2003 03:13:02 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, 23 Apr 2003 03:13:02 Z Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 03:13:01 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 198Age-0002m2-00; Tue, 22 Apr 2003 20:12:44 -0700 Date: Tue, 22 Apr 2003 23:12:09 -0400 From: Keith Moore To: John C Klensin Cc: moore@cs.utk.edu, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A simple question Message-Id: <20030422231209.438176f7.moore@cs.utk.edu> In-Reply-To: <70757023.1050910115@p3.JCK.COM> References: <20030419192024.440d3773.moore@cs.utk.edu> <16762.1050792143@munnari.OZ.AU> <00d001c306c0$faeadf90$93b58742@ssprunk> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <16762.1050792143@munnari.OZ.AU> <5.2.1.1.2.20030420140541.0290fb00@mail.amaranth.net> <5.2.1.1.2.20030420201343.02a336c0@mail.amaranth.net> <20030420221319.62964599.moore@cs.utk.edu> <70757023.1050910115@p3.JCK.COM> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk let me see if I can clarify this by restating it. 1. Apps know best what kinds of services they need. The network doesn't know this unless the app has some way of telling the network (e.g. TOS/QoS/diffserv/intserv/packet-class flavor-of-the-year). 2. The network knows best where hosts are located, and how to get packets from here to there (if possible). The network also knows whether it's permitted to send packets from here to there (perhaps limited by available routes or policy, perhaps limited by packet filtering). Most apps don't know these things and shouldn't have to know them. However it can be useful if the network has some way to tell hosts and apps that it's not possible to get packets from here to there, and the reason for that. Traditionally ICMP has fulfilled this role. Now there are apps that have to know about network topology, such as network management tools. But in general we don't want to burden hosts and apps with having to have this kind of knowledge, because there's no good way to get it from the network, and to make it work reliably would require requiring the network to feed routing and policy information to potentially all hosts. 3. Neither the kind of service being requested/provided nor information about whether traffic is permitted should be wired into an IP address - First because it forces a binding between policy and/or service and network location which is inflexible and doesn't scale well; second because it invites/begs/demands hosts and apps to know about network topology - i.e. to second-guess the network. 4. Hosts shouldn't have to pick the "right" source or destination address in order to get the network to do its job of getting the bits from here to there (for some well-defined "here" and "there"), because hosts don't have the requisite knowledge to do this, and because a requirement to pick the right destination address means that addresses don't have a consistent meaning from one source host to another. To the extent that a host has to pick the "right" interface, it needs to be possible to make the right choice from information that the host normally has at hand (like matching prefix lengths). Similarly, using address selection as a means to select a particular service quality, or a particular security level, etc. is a best a stopgap measure because once again it requires apps to know about specific address ranges and/or network topology. Note that scoped addresses make it difficult for each of the network, hosts, and apps to do their jobs - the network can't tell whether it can get the traffic to the destination because the destination address is ambiguous (so for instance, how can it tell the difference between "prohibited" and "no route to destination" and "no such host" - and while it might have unambiguous rules for how to route such addresses, that doesn't mean the traffic went to the right place); hosts can't tell which interface to use to send the traffic; and apps can't tell whether or not the address is usable to reach the desired peer (either locally or by another peer). -- Does any of the above mean that apps should never explicitly select source and/or destination addresses or interfaces? No, it means our network architecture should not expect ordinary apps to make such selections in order to sucessfully obtain services from the network. Now, because of mobile IP and privacy addresses, we're still going to have situations where apps need to give their hosts an idea of what kinds of addresses they need. E.g. Does the app need an address that continues to work as the host moves, or will the in-care-of address do? Does it prefer an address that is stably associated with the host, or is a temporary address more appropriate? But the answers to both of these questions *are* things that the app can be expected to know. Furthermore, unlike service quality or security, these things inherently require address selection. And unlike site-local, these properties are essentially opaque to other hosts in the network - thus we cannot expect/demand that other hosts use information embedded in the address and behave differently for different kinds of addresses. And of course it will always be possible to set up or encounter situations where apps that have knowledge about the network topology (or which exhaustively try all known source/destination pairs) can succeed where apps that don't go to extreme measures will fail. In some ways this is an argument about how we divide up the burden - which burdens we should place on hosts and apps and which ones we should place on the network. And the essence of the argument is: don't expect either one to make decisions about things it doesn't know about. And this further argues for not having more addresses for a host than necessary, for not using multiple addresses as a mechanism to provide different levels of access to a host, and for eschewing ambiguous addresses. Keith > > I disagree that the IP stack can supply reasonable defaults in > > the face of multiple scopes. The criteria for choosing a > > source address varies widely from one application to another. > > Some applications need stable addresses, others need addresses > > usable from all of their potential peers, others need to > > choose the source address that results in the best performance > > (where there is more than one meaning of 'best performance'). > > The default address selection rules are at best a guess. > > > > We should let the network do routing, so that hosts and apps > > aren't expected to make routing decisions. > > Keith, > > I don't understand your point here, and would like to. It seems > to me that your first paragraph ("I disagree...") suggests that > the applications need to specify the addresses/interfaces > because they know their needs and the stack can't figure it out. > And the second argues for pushing the decisions onto the > network, which has no information at all (and, if it had it, > could probably apply it only by changing addresses mid-flight -- > NAT-like or worse). That suggests to me a conclusion of "not > application, not stack, not network either" which leaves very > few options. > > If I ignore that apparent contradiction, I'm left with the > conclusion that we need some new addressing and routing > abstractions so that the applications can tell the stack (and > the stack might tell, or negotiate with, the network) what > considerations they need optimized and do so without specifying > specific addresses or inspecting components of addresses. It > seems to me that such abstractions would also eliminate one of > the arguments against site local: having an application able to > tell the stack: > > * I need a local address > > * I need an appropriate address for routing to > > * I need a completely-global address > > Are all far more reasonable than having the application itself > recognize particular addresses or prefixes and trying to figure > out which ones make sense in its context. It also _might_ > suggest that we need to reexamine ICMP in the IPv6 context to be > sure that, if the stack needs information from the network to > make satisfactory choices along these lines, it can ask them > without, e.g., trying to set up one or more TCP connections (or > sending UDP packet using an unspecified protocol) and waiting > for the responses or timeouts. > > Is that really where we need to be headed and, if so, is anyone > doing the work rather than being stuck on "local-good / > local-bad", "scope-necessary / scope-bad", types of arguments? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 01:53:02 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 h3N8r2hs013450; Wed, 23 Apr 2003 01:53:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3N8r2j7013449; Wed, 23 Apr 2003 01:53:02 -0700 (PDT) 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 h3N8qxhs013442 for ; Wed, 23 Apr 2003 01:52:59 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3N8r5FC026819 for ; Wed, 23 Apr 2003 01:53:05 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id CAA24655 for ; Wed, 23 Apr 2003 02:53:00 -0600 (MDT) 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, 23 Apr 2003 08:52:59 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, 23 Apr 2003 08:52: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; Wed, 23 Apr 2003 08:52:59 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 08:52:58 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3N8qtY18976 for ; Wed, 23 Apr 2003 11:52:55 +0300 Date: Wed, 23 Apr 2003 11:52:54 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: ISP using dynamic address/prefix Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Majordomo was too smart and blocked this message because it believed it was a administrative request due to the words used. Let's try with a slightly different subject/body. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ---------- Forwarded message ---------- Date: Wed, 16 Apr 2003 15:47:21 +0300 (EEST) From: Pekka Savola To: ipng@sunroof.eng.sun.com Cc: Robert Elz Subject: reasons for ISP changing address/prefix Hello all, A point inherited from another thread: why do the ISP's today force the users use dynamic address/prefix for intermittent connectivity? Let's try to look at the possible reasons first, and after that, look again to see if the situation is any different with IPv6 (at least for some things yes, I believe for some others no). Depending how much discussion this incites, writing a short I-D summarizing this issue should probably be a good idea. I can do it if it seems warranted. On Wed, 16 Apr 2003, Robert Elz wrote: > | Note: in today's world, it seems to me that almost all of these cases are > | really those of intermittent connectivity. > > Of changing connectivity, whether intermittent, or not. Right now > (as of this instant I mean) my connections rarely last much more than > an hour or so (then restart fairly quickly). Every time I connect I > get a different address. You can be dead sure that that address has > no bearing at all on the addressing I am using on my internal net. This is outside of the scope of the original topic but let's consider this a bit. Why would an operator change the prefix/address? A few possible reasons spring to mind: - make it more difficult for people to run servers in their "low-end" connectivity services (and wasting bandwidth and what not) - addresses are a relatively scarce resource and especially in cases where the users do not need them all the time, it's easier to explain this to RIR's in address applications and you need a smaller block - in cases where the users do not need them all the time, it's easier&simpler to just have a pool of addresses, and associate the user with one only when required - one could also cite privacy reasons but I believe that's mostly only an excuse for another reason - the user has no incentive to get a more expensive connection or a 5$/mo upgrade for static addresses if everyone gets them for free - one might have to keep a real database of user<->IP mappings (both in the backend like RADIUS and possible RIPE-whois like databases) if they were assigned statically More of them? Some of these are bogus and can be argued of course, but let's just collect a list of reasons first. Going a bit to the IPv6 side already: > We might like to pretend that we can stop providers from doing that, but we > cannot. Well, I agree with you to a degree here that we cannot _assume_ that there will not be providers that provide you with a changing prefix. But with proper work and education, if we can manage most of them to do the right thing, we just might be able to make this problem a bit smaller. Then, a little bit less extensive mechanisms to cope with this case might be acceptable. -- 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 Apr 23 02:43:58 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 h3N9hvhs013833; Wed, 23 Apr 2003 02:43:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3N9hv1U013832; Wed, 23 Apr 2003 02:43:57 -0700 (PDT) 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 h3N9hshs013825 for ; Wed, 23 Apr 2003 02:43:54 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3N9i0FC004155 for ; Wed, 23 Apr 2003 02:44:01 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA18067 for ; Wed, 23 Apr 2003 03:43:55 -0600 (MDT) 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, 23 Apr 2003 09:43: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; Wed, 23 Apr 2003 09:43:54 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, 23 Apr 2003 09:41:54 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 09:41:53 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3N9fkq19349; Wed, 23 Apr 2003 12:41:46 +0300 Date: Wed, 23 Apr 2003 12:41:46 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: IPv6 Subject: Re: hijacking prefixes for disconnected [RE: C000] In-Reply-To: <18810.1050572952@munnari.OZ.AU> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for the late answer, holidays.. On Thu, 17 Apr 2003, Robert Elz wrote: > Date: Wed, 16 Apr 2003 13:47:36 +0300 (EEST) > From: Pekka Savola > Message-ID: > > | Please note that the discussion was about "disconnected" case -- and for > | that only. Ensuring stable internal connectivity etc. is a different > | beast altogether. What I tried to do is to scope issues in the case that > | site *is* actually disconnected -- and a special single-subnet case of > | that in particular. > > The problem is that when you divide up the problems into neat little > compartments, and try to solve each one separately, the mess that > results when you try and combine it all back together again is far > worse than anything we have today. I agree that this is a potential problem -- the pieces don't fit together, or are too different in such way that they increase the complexity enermously. However, I believe it might be possible to avoid this rathole as long as we remember it does exists. > | Why would it want to keep its invented prefix? > > Why would it want to change? Because due to those assumptions, changing would be relatively easy, and more importantly, it would make the hosts function better -- because the invented prefix is not special from any others in any way -- see below. > | Keeping it would actually > | hurt them too as it would be used in the source address selection and > | about a half of their packets would get return routed to /dev/null or some > | other site. They'd certainly want to renumber. > > You're making assumptions about what you'd want, and applying them to > others. > > If my invented address is 8123:4567::whatever then source address > selection isn't going to be a problem, anything to a 2000::/3 address > will pick whatever 2000::/3 address my ISP has supplied me just now. You assume that one picks the invented prefixes from "different enough" range. Even still, this approach would seem to require more analysis. Remember that there are other rules that override the longest matching rule, e.g. prefer home/care-of addresses, and that for example "prefer matching label" would pick 8123:4567::/32 to a destination in 2001::/16 if the site would only have 6to4 addresses for IPv6 connectivity; destination address selection is likely to have similar issues. > Anything to my 8123:4567::/32 address space will use that address as > source. > > All looks like it will work fine to me - and painlessly avoid having > my internal connections break. Not really (this can be both a good and a bad thing), it seems. > Of course, so does fec0::/10 in just the same way, with the advantage > that what is going on with that address is known by everyone. fec0::/10 has also the "scope" element which is a much earlier tie-breaker in the address selection. But this has its own problems too (the rules are not sufficient to prevent all the cases). [another point moved to a separate thread] -- 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 Apr 23 02:51:48 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 h3N9plhs014042; Wed, 23 Apr 2003 02:51:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3N9plon014041; Wed, 23 Apr 2003 02:51:47 -0700 (PDT) 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 h3N9pihs014031 for ; Wed, 23 Apr 2003 02:51:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3N9pouc003101 for ; Wed, 23 Apr 2003 02:51:50 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA14167 for ; Wed, 23 Apr 2003 03:51:45 -0600 (MDT) 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, 23 Apr 2003 09:51:43 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, 23 Apr 2003 09:51: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, 23 Apr 2003 09:51:43 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 09:51:42 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3N9pbQ19420; Wed, 23 Apr 2003 12:51:37 +0300 Date: Wed, 23 Apr 2003 12:51:37 +0300 (EEST) From: Pekka Savola To: IPv6 cc: Robert Elz Subject: why I voted for deprecation [hijacking prefixes for disconnected] Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Moving one point from a separate thread, trying to keep discussions apart.. On Thu, 17 Apr 2003, Robert Elz wrote: > Date: Wed, 16 Apr 2003 13:47:36 +0300 (EEST) > From: Pekka Savola > Message-ID: > > | That was the specific scenario here (I think). I didn't claim to analyze > | all the SL scenarios. > > You're in favour of deprecating the things without analysing all scenarios? I raised my hand for deprecation because that was the best alternative of the two. The limited model was closer to my preference: no *formal* deprecation (at least yet) while preserving some uses for site-locals, and removing the future extra work on all the protocols and applications (treat site locals like globals). And restricting the vendors who may wish to ship products assuming network is going to special-case site-locals. But, actually limited is pretty close to deprecated, really. It's just the question how to define the deprecated (ie. the wording, whether the prefix is left to the specs, etc.) and what practice vendors etc. will want to adopt. Not raising the hand for "deprecation" seemed to strongly imply going towards a moderate (or even full usage scenario), which is *specifically* something I did not want, because it seems apparent that "that way lies madness". So I chose the worst of the two questionable alternatives. -- 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 Apr 23 05:45: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 h3NCjbhs014656; Wed, 23 Apr 2003 05:45:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NCjbR2014655; Wed, 23 Apr 2003 05:45:37 -0700 (PDT) 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 h3NCjXhs014648 for ; Wed, 23 Apr 2003 05:45:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NCjfuc028387 for ; Wed, 23 Apr 2003 05:45:41 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA02271 for ; Wed, 23 Apr 2003 06:45:36 -0600 (MDT) 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, 23 Apr 2003 12: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; Wed, 23 Apr 2003 12:41: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; Wed, 23 Apr 2003 12:45:35 Z Received: from SifyMail1.1 ([202.144.76.14] [202.144.76.14]) by relay11.sun.com for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 12:45:32 Z Received: (qmail 604 invoked by uid 7002); 23 Apr 2003 17:56:14 +0530 Received: from 202.144.76.10 (HELO SifyMail-1.1) (202.144.76.10) by 202.144.76.10 with SMTP; 23 Apr 2003 17:56:14 +0530 Received: (qmail 30684 invoked by uid 7002); 23 Apr 2003 17:56:14 +0530 Received: from 202.144.76.17 (HELO SIfyMail-1.0) (202.144.76.17) by 0 with SMTP; 23 Apr 2003 17:56:14 +0530 Received: (qmail 30680 invoked from 203.197.138.194 by host webmail1 by uid 99); 23 Apr 2003 17:56:14 +0530 To: ipng@sunroof.eng.sun.com Subject: IPv6 Address validation Message-Id: <1051100774.3ea68666c2a2e@webmail1.maa.sify.net> Date: Wed, 23 Apr 2003 17:56:14 +0500 (IST) From: Ravi Kumar M MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Can any one tell me how to validate IPv6 address? any one has an example code? kindly let me know thanks & regards ravi ------------------------------------------------- Sify Mail - now with Anti-virus protection powered by Trend Micro, USA. Know more at http://mail.sify.com Sify Power mail- a Premium Service from Sify Mail! know more at http://mail.sify.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 Apr 23 07:42:28 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 h3NEgShs015579; Wed, 23 Apr 2003 07:42:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NEgSAV015578; Wed, 23 Apr 2003 07:42:28 -0700 (PDT) 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 h3NEgOhs015571 for ; Wed, 23 Apr 2003 07:42:24 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NEgWFC026899 for ; Wed, 23 Apr 2003 07:42:32 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id IAA13273 for ; Wed, 23 Apr 2003 08:42:22 -0600 (MDT) 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, 23 Apr 2003 14:42: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, 23 Apr 2003 14:42: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, 23 Apr 2003 14:42:19 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 14:42:18 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Apr 2003 07:42:08 -0700 Reply-To: From: "Tony Hain" To: "'Harald Tveit Alvestrand'" , Cc: Subject: A follow up question Date: Wed, 23 Apr 2003 07:42:08 -0700 Message-Id: <032a01c309a6$84b1ece0$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <438340000.1051014766@askvoll.hjemme.alvestrand.no> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3NEgPhs015572 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you, this was the only simple answer to the simple question. For the followup question: Do you believe that the IETF created the architectural concept of addresses with a limited scope? Tony > -----Original Message----- > From: owner-ietf@ietf.org [mailto:owner-ietf@ietf.org] On > Behalf Of Harald Tveit Alvestrand > Sent: Tuesday, April 22, 2003 5:33 AM > To: alh-ietf@tndh.net; ipng@sunroof.eng.sun.com > Cc: ietf@ietf.org > Subject: Re: A simple question > > > just to provide a "simple" answer to a simple question: > > NO - I do not agree with Keith's assertion as quoted. > YES - I agree with what I *believe* Keith wanted to say, > which is that > "introduction of *site-scoped* addresses causes far more > problems than it > solves". > > I do NOT believe that introduction of link-local addresses > causes far more > problems than it solves. > > My position on SL should be well known. I'll try to avoid > repeating the > rest of my arguments once again in this discussion tree. > > Harald > > > --On fredag, april 18, 2003 15:12:54 -0700 Tony Hain > > wrote: > > > Keith Moore wrote: > >> It doesn't solve all problems, but introduction of > >> scoped addresses causes far more problems than it solves. > > > > I would like to understand how many people that voted YES on the > > question of deprecating SL concur with Keith's assertion. > > > > Tony > > > > Note: I cc'd the IETF list to catch those who may have been in the > > room in SF, but aren't on the IPv6 list. > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Apr 23 08:03: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 h3NF3Yhs015854; Wed, 23 Apr 2003 08:03:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NF3YTA015853; Wed, 23 Apr 2003 08:03:34 -0700 (PDT) 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 h3NF3Vhs015846 for ; Wed, 23 Apr 2003 08:03:31 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NF3cFC001920 for ; Wed, 23 Apr 2003 08:03:38 -0700 (PDT) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA06505 for ; Wed, 23 Apr 2003 08:03:32 -0700 (PDT) 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, 23 Apr 2003 15:03: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, 23 Apr 2003 15:03:23 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, 23 Apr 2003 15:03:23 Z Received: from hclnpd.hclt.co.in ([202.54.64.7] [202.54.64.7]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 15:03:23 Z Received: from pilex.hclt-ntl.co.in ([192.168.19.34]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HNWQ7BTA; Wed, 23 Apr 2003 20:30:47 +0530 Received: from npd.hcltech.com (RASHANMU-PC [192.168.19.69]) by pilex.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H0SF5L53; Wed, 23 Apr 2003 20:31:06 +0530 Message-Id: <3EA6AEB7.562CBF44@npd.hcltech.com> Date: Wed, 23 Apr 2003 20:48:15 +0530 From: S Ramesh Organization: HCL Technologies Limited. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ravi Kumar M CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Address validation References: <1051100774.3ea68666c2a2e@webmail1.maa.sify.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If you are using linux (bsd networking code) as platform, take a look at /usr/include/netinet/in.h file. It has macros defined for IPv6 address validation (e.g. IN6_IS_ADDR_LINKLOCAL etc.) Thanks, Ramesh. Ravi Kumar M wrote: > > Hi, > > Can any one tell me how to validate IPv6 address? any one has an example code? kindly let me know > > thanks & regards > ravi > ------------------------------------------------- > Sify Mail - now with Anti-virus protection powered by Trend Micro, USA. > Know more at http://mail.sify.com > > Sify Power mail- a Premium Service from Sify Mail! > know more at http://mail.sify.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 > -------------------------------------------------------------------- -- http://voip.hcltech.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 Apr 23 08:04: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 h3NF4ths015871; Wed, 23 Apr 2003 08:04:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NF4tUu015870; Wed, 23 Apr 2003 08:04:55 -0700 (PDT) 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 h3NF4phs015863 for ; Wed, 23 Apr 2003 08:04:51 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NF4wuc024820 for ; Wed, 23 Apr 2003 08:04:58 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA27783 for ; Wed, 23 Apr 2003 09:04:53 -0600 (MDT) 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, 23 Apr 2003 15:01: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; Wed, 23 Apr 2003 15:01:54 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, 23 Apr 2003 15:01:54 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 15:01:53 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Apr 2003 08:01:51 -0700 Reply-To: From: "Tony Hain" To: , Subject: RE: Architectural Considerations section in specs Date: Wed, 23 Apr 2003 08:01:51 -0700 Message-Id: <033901c309a9$45d0f130$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <70125434335.20030419164712@brandenburg.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3NF4phs015864 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Crocker wrote: > Folks, > > DS> I am saddened by the fact that Tony's simple question > could not be > DS> addressed. Site local addressing in IPv6 is a concept > which has been > DS> mentioned in RFC 1884, 2373 and 3513, the progression of Proposed > DS> Standards. This is a string of documents dating back to 1995. For > DS> eight years this concept was apparently considered a good thing. > > The problem appears to have been that no one bothered to draw > the necessary implications and circulate them for explicit > consideration. So folks scanned a spec, didn't see anything > that looked egregious, and only now are realizing how > extensive the impact is. What they are missing is that a defined prefix doesn't create the problem that they are complaining about. Limiting the usable scope of addresses is an operations decision. The mismatch between the operational reality of limited scope addresses and the app developer fantasy that there is a single flat routing space is the core problem here. Defining a prefix for those only made it *possible* for apps to recognize which ones might be restricted. It does not *make* apps deal with the problem of leaking addresses outside their scope of relevance (unless you take the viewpoint that end users actually expect applications to work right, and will require it once it is possible). Applications are not required to understand topology, unless and until they insist on passing around topology specific information. If any process is going to pass around topology specific information, it MUST understand the topology it is describing. There is no magic here, and defining a prefix didn't change the architecture. Operational decisions established the architecture, and it is our job to define the technologies that work within that architectural reality. We can choose to continue to declare a 'flat-earth' and insist that applications and name resolution infrastructure are free to arbitrarily pass around topology specific objects, or we can choose to recognize the reality of the deployed network and build the technologies that allow applications to operate correctly within it. 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 Apr 23 08:31:02 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 h3NFV2hs016507; Wed, 23 Apr 2003 08:31:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NFV2aT016506; Wed, 23 Apr 2003 08:31:02 -0700 (PDT) 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 h3NFUxhs016499 for ; Wed, 23 Apr 2003 08:30:59 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NFV6FC010541 for ; Wed, 23 Apr 2003 08:31:06 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3NFV1rZ023991 for ; Wed, 23 Apr 2003 08:31:01 -0700 (PDT) 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, 23 Apr 2003 15:30:59 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, 23 Apr 2003 15:30:59 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, 23 Apr 2003 15:30:59 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 15:30:58 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h3NFUivm033344; Wed, 23 Apr 2003 08:30:44 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h3NFUi6p033343; Wed, 23 Apr 2003 08:30:44 -0700 (PDT) Date: Wed, 23 Apr 2003 08:30:44 -0700 From: Shannon -jj Behrens To: S Ramesh Cc: Ravi Kumar M , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Address validation Message-Id: <20030423153044.GB33177@alicia.nttmcl.com> References: <1051100774.3ea68666c2a2e@webmail1.maa.sify.net> <3EA6AEB7.562CBF44@npd.hcltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EA6AEB7.562CBF44@npd.hcltech.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk /* * Author: Shannon -jj Behrens * Date: Fri Nov 1 12:09:17 PST 2002 * * Given a string on the command line, return 0 if the string is a valid IPv6 * address, 1 otherwise. */ #include #include #include #include #include #include #include #include #include char *argv0; /* This is argv[0] sans path. */ /* Output usage information to the user and exit. */ void usage () { fprintf (stderr, "usage: %s [-v] address\n", argv0); exit (1); } int main (int argc, char *argv[]) { int optchar, verbose = 0, is_ipv6addr; struct sockaddr addr; argv0 = argv[0] = basename (argv[0]); while ((optchar = getopt (argc, argv, "v")) != -1) switch (optchar) { case 'v': verbose = 1; break; default: usage (); } if (optind + 1 != argc) usage (); is_ipv6addr = inet_pton (AF_INET6, argv[optind], &addr); if (is_ipv6addr < 0) { fprintf (stderr, "%s: inet_pton: %s\n", argv0, strerror (errno)); return 1; } if (verbose) { if (is_ipv6addr) printf ("%s is a valid IPv6 address.\n", argv[optind]); else printf ("%s is not a valid IPv6 address.\n", argv[optind]); } return !is_ipv6addr; } -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 08:33: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 h3NFXAhs016542; Wed, 23 Apr 2003 08:33:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NFXA58016541; Wed, 23 Apr 2003 08:33:10 -0700 (PDT) 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 h3NFX7hs016531 for ; Wed, 23 Apr 2003 08:33:07 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NFXEFC011141 for ; Wed, 23 Apr 2003 08:33:14 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA14993 for ; Wed, 23 Apr 2003 09:33:08 -0600 (MDT) 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, 23 Apr 2003 15:33:08 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, 23 Apr 2003 15:33: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, 23 Apr 2003 15:33:07 Z Received: from eikenes.alvestrand.no ([217.13.28.204] [217.13.28.204]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 15:33:07 Z Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64ECB622AF; Wed, 23 Apr 2003 17:33:03 +0200 (CEST) Date: Wed, 23 Apr 2003 17:33:03 +0200 From: Harald Tveit Alvestrand To: alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Cc: ietf@ietf.org Subject: Re: A follow up question Message-Id: <553440000.1051111983@askvoll.hjemme.alvestrand.no> In-Reply-To: <032a01c309a6$84b1ece0$261e4104@eagleswings> References: <032a01c309a6$84b1ece0$261e4104@eagleswings> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --On onsdag, april 23, 2003 07:42:08 -0700 Tony Hain wrote: > Thank you, this was the only simple answer to the simple question. > > For the followup question: > Do you believe that the IETF created the architectural concept of > addresses with a limited scope? no; I believe the community-that-became-the-IETF created the Internet by *denying* that concept, which was already well known long before TCP/IP. Because of the realities of 32 bits of address in IPv4, that denial became more and more untenable as the years went by, until RFC 1597 re-acknowledged the existence of such IPv4 addresses in 1994. Harald -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 10:12:12 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 h3NHCChs017692; Wed, 23 Apr 2003 10:12:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NHCCdf017691; Wed, 23 Apr 2003 10:12:12 -0700 (PDT) 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 h3NHC8hs017684 for ; Wed, 23 Apr 2003 10:12:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NHCFuc003756 for ; Wed, 23 Apr 2003 10:12:16 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA23634 for ; Wed, 23 Apr 2003 11:12:09 -0600 (MDT) 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, 23 Apr 2003 17:12:08 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, 23 Apr 2003 17:12:07 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, 23 Apr 2003 17:12:07 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 17:12:07 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Apr 2003 10:12:06 -0700 Reply-To: From: "Tony Hain" To: "'Harald Tveit Alvestrand'" , Cc: Subject: RE: A follow up question Date: Wed, 23 Apr 2003 10:12:08 -0700 Message-Id: <035601c309bb$79032750$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <553440000.1051111983@askvoll.hjemme.alvestrand.no> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3NHC9hs017685 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Harald Tveit Alvestrand wrote: > --On onsdag, april 23, 2003 07:42:08 -0700 Tony Hain > > wrote: > > > Thank you, this was the only simple answer to the simple question. > > > > For the followup question: > > Do you believe that the IETF created the architectural concept of > > addresses with a limited scope? > > no; I believe the community-that-became-the-IETF created the > Internet by > *denying* that concept, which was already well known long > before TCP/IP. > > Because of the realities of 32 bits of address in IPv4, that > denial became > more and more untenable as the years went by, until RFC 1597 > re-acknowledged the existence of such IPv4 addresses in 1994. Though IP addresses that were only reachable from a limited part of the network existed long before 1994. These were implicit through filtering of routing announcements, or explicit through access control mechanisms. So to clarify the question, do you believe the establishment of a set of local use prefixes is the root cause of the unsolved problems that applications developers are complaining about? 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 Apr 23 12:26:15 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 h3NJQEhs018705; Wed, 23 Apr 2003 12:26:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NJQEXS018704; Wed, 23 Apr 2003 12:26:14 -0700 (PDT) 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 h3NJQAhs018697 for ; Wed, 23 Apr 2003 12:26:10 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NJQHFC003249 for ; Wed, 23 Apr 2003 12:26:17 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA03396 for ; Wed, 23 Apr 2003 12:26:12 -0700 (PDT) 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, 23 Apr 2003 19:26: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, 23 Apr 2003 19:22: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; Wed, 23 Apr 2003 19:26:11 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 19:26:11 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3NJQ7v27514; Wed, 23 Apr 2003 15:26:08 -0400 (EDT) Date: Wed, 23 Apr 2003 15:26:07 -0400 From: Keith Moore To: Spencer Dawkins Cc: moore@cs.utk.edu, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A simple question Message-Id: <20030423152607.79be279e.moore@cs.utk.edu> In-Reply-To: <20030423121730.18200.qmail@web10908.mail.yahoo.com> References: <20030422231209.438176f7.moore@cs.utk.edu> <20030423121730.18200.qmail@web10908.mail.yahoo.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would be thrilled if we spent some time thinking about ICMP in > an architectural way - however beautiful it was before ICMP > black holing, what we have now isn't consistently usable today. > We're spending time on point solutions (Matt Mathis on non-ICMP > path MTU discovery as one example), but is this the best we can > do? I don't think we're likely to be able to dispense with ICMP. Maybe we can find more ways to make it more trustworthy. Or maybe we just need to discourage people from filtering it. > > Note that scoped addresses make it difficult for each of the > > network, hosts, and apps to do their jobs - the network can't tell > > whether it can get the traffic to the destination because the > > destination address is ambiguous (so for instance, how can it tell > > the difference between "prohibited" and "no route to destination" > > and "no such host" - and while it might have unambiguous rules for > > how to route such addresses, that doesn't mean the traffic went to > > the right place); hosts can't tell which interface to use to send > > the traffic; and apps can't tell whether or not the address is > > usable to reach the desired peer (either locally or by another > > peer). > > This was my point (perhaps I wasn't clear enough) about the > difference between site-local and firewalling - if your peer > isn't reachable because of an explicit decision from a network > operator (firewall), that's one class of problem; if your peer > isn't reachable because you have an address that doesn't work, > BUT YOU COULD HAVE BEEN GIVEN ANOTHER ADDRESS THAT WOULD HAVE > WORKED (site-local), that's a different class of problem. > > The thing that bugs me is, I don't have any idea how the > application can tell that they have the second class of problem > - even ignoring ICMP Unreachable black-holing for a moment. Am I > missing something? (I don't think I'm a Genius of IPv6) What I want to say is that if the peer isn't reachable because the host or application didn't choose the right source or destination address, this is never the host or the application's problem - it's always the network's problem - because I don't see any way to allow hosts and apps to reliably make the "right choice" in the absence of routing information, and which allows addresses to be used in referrals. (and while separating endpoint identifiers from addresses might be a laudible architectural goal, we're nowhere near being able to integrate it into the current archtitecture). > > Now, because of mobile IP and privacy addresses, we're still going > > to have situations where apps need to give their hosts an idea of > > what kinds of addresses they need. E.g. Does the app need an > > address that continues to work as the host moves, or will the > > in-care-of address do? Does it prefer an address that is stably > > associated with the host, or is a temporary address more > > appropriate? But the answers to both of these questions *are* > > things that the app can be expected to know. Furthermore, unlike > > service quality or security, these things inherently require address > > selection. And unlike site-local, these properties are essentially > > opaque to other hosts in the network - thus we cannot expect/demand > > that other hosts use information embedded in the address and behave > > differently for different kinds of addresses. > > From RFC 3344, the current Mobile IP spec: > > 1.1. Protocol Requirements > > [deleted down to] > > A mobile node must be able to communicate with other nodes > that do not implement these mobility functions. No protocol > enhancements are required in hosts or routers that are not acting as > any of the new architectural entities introduced in Section 1.5. > > And I agree I'm extrapolating, but - I always thought language > like this said Mobile IP is a host IP networking thing, not a > host application thing. > > I'm not sure I'm understanding what you're saying - are you > saying that my mobile host should know it's mobile (I believe > you), or that Mozilla on a mobile host should know it's mobile > (I'm struggling here)? I'm saying that if your application knows that a particular connection is only likely to be open for a short time, and/or that it can reliably recover from broken connections, and that the source address isn't going to be used for referrals to peers on other hosts, then it might want to somehow tell its TCP/IP stack this, so the stack can use the in-care-of address as the source address rather than the home address, thereby bypassing any tunneling that might otherwise take place. Which isn't quite the same thing as letting an app know it's on a mobile host - though that would also be useful for some apps. > My understanding of Mobile IP was that the mobile host knows, > not Mozilla (or, at least, Mozilla works if it doesn't know). > > Re: security - are you thinking of applications that prefer > site-local (in IPv4, probably NATed 1918 addresses) for > "security", or is there another common use of > addresses-for-security I don't know about? I don't think address selection is an appropriate means for an application to specify security. That's what IPsec and/or TLS are for. (and yes, we need IPsec APIs) nor do I think that an application should invest greater or less trust in traffic that is sourced from or sunk to a particular address, at least not without specifically being configured to do so, and certainly not based on whether the address is site-local. 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 Apr 23 12:27: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 h3NJRhhs018737; Wed, 23 Apr 2003 12:27:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NJRhAS018736; Wed, 23 Apr 2003 12:27:43 -0700 (PDT) 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 h3NJRdhs018729 for ; Wed, 23 Apr 2003 12:27:40 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NJRlFC003693 for ; Wed, 23 Apr 2003 12:27:47 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id MAA04421 for ; Wed, 23 Apr 2003 12:27:41 -0700 (PDT) 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, 23 Apr 2003 19:27: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; Wed, 23 Apr 2003 19:27: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; Wed, 23 Apr 2003 19:25:40 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 19:25:40 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Apr 2003 12:25:36 -0700 Reply-To: From: "Tony Hain" To: "'Daniel Senie'" Cc: , Subject: RE: A follow up question Date: Wed, 23 Apr 2003 12:25:29 -0700 Message-Id: <036f01c309ce$19def160$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5.2.1.1.2.20030423133826.02ba3f70@mail.amaranth.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3NJRehs018730 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Daniel Senie wrote: > ... The IPv6 mechanism to give hosts a-priori > knowledge that the "site local" block is flawed in that it > cannot truly > provide the scoping information, since it does not address > the wider issues > associated with administrative address scoping. You assume an outcome ('flawed') without first discussing the full set of requirements. > ... > There will remain a need and desire for private address > space, be that the > assigned "site local" block (without the "special treatment" in the > stacks), RFC 1918 space, or a combination. I think it would > be useful to > decouple the issue of the special treatment of the Site Local > address block > from the religious war over whether private address space and other > mechanisms sometimes associated are beneficial or not. In > reviewing the > recent discussion, it is clear the two are being intertwined, and it > appears to be adding to the heat, and producing no light. I have no argument with discussing them separately, as long as we don't end up with the usual discussion where it is the private address space causing the problems. There is a general lack of recognition that private addresses only exposes the underlying mis-match in the perceptions of scope. > > Separately, if there is genuine interest in addressing the > scoping problem, > I suggest that be addressed separately. Reset your clocks to 1995 ... > A proper effort might encompass > mechanisms to deliver indications to applications as to the scoping > limitations causing communications to be blocked, as well as > wire protocol > issues to carry such signalling. You assume such signaling would somehow solve the problem of A using a literal referral to C that Bl is the address it is using, when C can only see Bg. How is A supposed to know that Bl has a scope limitation when it can get there without receiving any signaling? How is the infrastructure supposed to know that A intends to tell C a literal address rather than a name? If Bl & Bg had indicators of scope differentiation in the prefix, A could recognize the difference if it bothered to look. It wouldn't have to, but if it didn't it would either have to refer the name, or provide C with the entire list so it could figure out which one works. Brian's C000 thread was exploring this space. > In a broader sense, there is a need to > deal with signalling issues as well. There are network > operators, firewall > vendors and network administrators who've been taught ICMP > packets are > inherently dangerous and must be filtered. The work output of > such efforts > should span the Internet Area producing standards track documents to > specify how to properly implement mechanisms in hosts, routers and > firewalls, and the Operations Area to provide BCPs giving guidance to > network administrators and service providers on the > operational needs of > such issues. > I agree education is appropriate. Part of that is educating the application development community that the real network has addressing with limited scopes of relevance, so blindly assuming a flat routing space and passing around topology specific information will result in broken apps. 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 Apr 23 12:51:22 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 h3NJpMhs019280; Wed, 23 Apr 2003 12:51:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NJpMLF019279; Wed, 23 Apr 2003 12:51:22 -0700 (PDT) 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 h3NJpIhs019272 for ; Wed, 23 Apr 2003 12:51:18 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NJpQFC010602 for ; Wed, 23 Apr 2003 12:51:26 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3NJpKrZ005341 for ; Wed, 23 Apr 2003 12:51:20 -0700 (PDT) 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, 23 Apr 2003 19:51: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; Wed, 23 Apr 2003 19:51: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; Wed, 23 Apr 2003 19:51:19 Z Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 19:51:18 Z Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h3NJpFo28851; Wed, 23 Apr 2003 12:51:15 -0700 Received: from innovationslab.net ([63.109.132.2]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h3NKAPQe002357 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 23 Apr 2003 13:10:29 -0700 Message-Id: <3EA6EEAE.1070801@innovationslab.net> Date: Wed, 23 Apr 2003 15:51:10 -0400 From: Brian Haberman 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: Keith Moore CC: Spencer Dawkins , ipng@sunroof.eng.sun.com Subject: Re: A simple question References: <20030422231209.438176f7.moore@cs.utk.edu> <20030423121730.18200.qmail@web10908.mail.yahoo.com> <20030423152607.79be279e.moore@cs.utk.edu> In-Reply-To: <20030423152607.79be279e.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: >>>Note that scoped addresses make it difficult for each of the >>>network, hosts, and apps to do their jobs - the network can't tell >>>whether it can get the traffic to the destination because the >>>destination address is ambiguous (so for instance, how can it tell >>>the difference between "prohibited" and "no route to destination" >>>and "no such host" - and while it might have unambiguous rules for >>>how to route such addresses, that doesn't mean the traffic went to >>>the right place); hosts can't tell which interface to use to send >>>the traffic; and apps can't tell whether or not the address is >>>usable to reach the desired peer (either locally or by another >>>peer). >> >>This was my point (perhaps I wasn't clear enough) about the >>difference between site-local and firewalling - if your peer >>isn't reachable because of an explicit decision from a network >>operator (firewall), that's one class of problem; if your peer >>isn't reachable because you have an address that doesn't work, >>BUT YOU COULD HAVE BEEN GIVEN ANOTHER ADDRESS THAT WOULD HAVE >>WORKED (site-local), that's a different class of problem. >> >>The thing that bugs me is, I don't have any idea how the >>application can tell that they have the second class of problem >>- even ignoring ICMP Unreachable black-holing for a moment. Am I >>missing something? (I don't think I'm a Genius of IPv6) > > > What I want to say is that if the peer isn't reachable because the > host or application didn't choose the right source or destination > address, this is never the host or the application's problem - it's > always the network's problem - because I don't see any way to allow > hosts and apps to reliably make the "right choice" in the absence of > routing information, and which allows addresses to be used in referrals. > (and while separating endpoint identifiers from addresses might be a > laudible architectural goal, we're nowhere near being able to integrate > it into the current archtitecture). But the stack can help in this case. There is provision in the existing scoped addressing architecture to return an ICMP message that will specify that the reason the packet was dropped was due to a scoped boundary (Destination Unreachable, Code=2). The current ICMP spec says it is for when the source address exceeds the scope boundary, but the original intent was for it to be used for either address. Do admins block ICMP messages that originate from within their own networks? 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 Apr 23 13:00:10 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 h3NK09hs019467; Wed, 23 Apr 2003 13:00:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NK097g019466; Wed, 23 Apr 2003 13:00:09 -0700 (PDT) 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 h3NK06hs019459 for ; Wed, 23 Apr 2003 13:00:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NK0DFC013356 for ; Wed, 23 Apr 2003 13:00:13 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA07845 for ; Wed, 23 Apr 2003 13:59:53 -0600 (MDT) 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, 23 Apr 2003 19:57: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; Wed, 23 Apr 2003 19:57: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, 23 Apr 2003 19:57:00 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 19:57:00 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Apr 2003 12:56:58 -0700 Reply-To: From: "Tony Hain" To: "'John C Klensin'" , "'Daniel Senie'" Cc: , Subject: RE: A follow up question Date: Wed, 23 Apr 2003 12:56:47 -0700 Message-Id: <037501c309d2$7986ded0$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <272103303.1051111464@p3.JCK.COM> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3NK06hs019460 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John C Klensin wrote: > ... Maybe that to get there > means that we need to revisit, not just ICMP as Daniel suggests, > but the "no TCPng" decision... I don't know. Maybe that is the path out. > But, if we can > figure out a way to clean this up and make it work well, we > could easily end up with a stronger justification for deploying > IPv6 than anything (at least anything real) we have had to date. Depends on where you are in the world, and how much IPv4 address space you are sitting on. I am aware of organizations in the US today that can't get enough IPv4 address space fast enough by current ARIN policy to meet a viable business plan for ramp up rate. > ... I'm just committed to a network and implementation > model in which they are kept below me in the stack. > Consequently, the only thing I want to need to know about an IP > address is how to pick it up from one source, carry it around > opaquely, and ultimately pass it to something else or use it in > an opaque way in a protocol transaction. But you just said you wanted to keep it below you in the stack. You can't have it both ways... You either get to keep it below you by passing around name objects, or you are taking on the responsibility of getting it right because you are passing around topology information. > The challenge to those > of you who are for, or against, SL at the IP level is to justify > it in a context in which applications really don't need to know > anything about them, or other address scope/ reachability/ > routability issues except through the addressing-independent > abstractions that we can agree on. I don't care if it is TCP-ng, or something else between IP & the app that takes care of figuring out the topology difference, but signaling by itself won't solve the problem of literal referrals. If the app is going to insist on passing around topology information, it has to make sure that matches the topology being used. > If the applications don't > need to know, and can function in a multiple-address-per-host > environment without --in the application-- having to determine > which one to use by some type of iteration process, then you > need to justify specialized addresses only in terms of their > requires lower in the stack. If the applications do need to > know, then the complexity costs appear to be high enough to > present an insurmountable barrier. The current IPv4 network already requires this of applications, the developers simply choose to ignore reality. There is nothing different in a unique prefix for local use, other than the ability for the app (stack) that chooses to look to figure out that some pairings won't work. If the app does as it currently will and passes an out-of-scope address, the application will fail. This is not a new requirement, it is simply exposing the fact that applications have been ignoring reality for a long time now. If there are other ways to mitigate the issue, I am all for developing them. My primary issue is that there are a variety of things people want to use SL for and removing an existing mechanism without appropriate replacements for all of them first is an irresponsible act. 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 Apr 23 13:57:22 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 h3NKvLhs020080; Wed, 23 Apr 2003 13:57:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NKvLMM020079; Wed, 23 Apr 2003 13:57:21 -0700 (PDT) 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 h3NKvIhs020072 for ; Wed, 23 Apr 2003 13:57:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NKvPuc018519 for ; Wed, 23 Apr 2003 13:57:25 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA19677 for ; Wed, 23 Apr 2003 14:57:19 -0600 (MDT) 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, 23 Apr 2003 20:57: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; Wed, 23 Apr 2003 20:57: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; Wed, 23 Apr 2003 20:57:19 Z Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 20:57:18 Z Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 2C215137F0D; Wed, 23 Apr 2003 13:57:17 -0700 (PDT) Date: Wed, 23 Apr 2003 13:57:13 -0700 Subject: Re: A follow up question Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'John C Klensin'" , "'Daniel Senie'" , , To: From: David Conrad In-Reply-To: <037501c309d2$7986ded0$261e4104@eagleswings> Message-Id: <2863E712-75CE-11D7-A3E0-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, On Wednesday, April 23, 2003, at 12:56 PM, Tony Hain wrote: > I am aware of organizations in the US today that > can't get enough IPv4 address space fast enough by current ARIN policy > to meet a viable business plan for ramp up rate. As this would appear to be an indication of a failure of allocation policy, a discussion of details on an appropriate list (ppml@arin.net would probably be best) would be appreciated. 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 Apr 23 14:29:28 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 h3NLTShs020457; Wed, 23 Apr 2003 14:29:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NLTRKE020456; Wed, 23 Apr 2003 14:29:27 -0700 (PDT) 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 h3NLTNhs020449 for ; Wed, 23 Apr 2003 14:29:23 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NLTVFC014431 for ; Wed, 23 Apr 2003 14:29:31 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id OAA23501 for ; Wed, 23 Apr 2003 14:29:25 -0700 (PDT) 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, 23 Apr 2003 21:29: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; Wed, 23 Apr 2003 21:29: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; Wed, 23 Apr 2003 21:29:22 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 21:29:22 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3NLQmv27862; Wed, 23 Apr 2003 17:26:49 -0400 (EDT) Date: Wed, 23 Apr 2003 17:26:48 -0400 From: Keith Moore To: Brian Haberman Cc: moore@cs.utk.edu, spencer_dawkins@yahoo.com, ipng@sunroof.eng.sun.com Subject: Re: A simple question Message-Id: <20030423172648.09cae3d8.moore@cs.utk.edu> In-Reply-To: <3EA6EEAE.1070801@innovationslab.net> References: <20030422231209.438176f7.moore@cs.utk.edu> <20030423121730.18200.qmail@web10908.mail.yahoo.com> <20030423152607.79be279e.moore@cs.utk.edu> <3EA6EEAE.1070801@innovationslab.net> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > What I want to say is that if the peer isn't reachable because the > > host or application didn't choose the right source or destination > > address, this is never the host or the application's problem - it's > > always the network's problem - because I don't see any way to allow > > hosts and apps to reliably make the "right choice" in the absence of > > routing information, and which allows addresses to be used in > > referrals.(and while separating endpoint identifiers from addresses > > might be a laudible architectural goal, we're nowhere near being > > able to integrate it into the current archtitecture). > > But the stack can help in this case. There is provision in the > existing scoped addressing architecture to return an ICMP message that > will specify that the reason the packet was dropped was due to a > scoped boundary (Destination Unreachable, Code=2). it doesn't help. the problem is that the scoped address is inherently ambiguous, and therefore any error that results from attempting to use the scoped address occurs for ambiguous reasons. so even if the app gets an ICMP unreachable message it doesn't know whether this is because it was trying to use the scoped address in the wrong context or for some other reason. nor does the ICMP message help the app figure out the right context, or whether it has access to the right context. Ketih -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 14:59:46 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 h3NLxkhs021432; Wed, 23 Apr 2003 14:59:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NLxkig021431; Wed, 23 Apr 2003 14:59:46 -0700 (PDT) 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 h3NLxghs021424 for ; Wed, 23 Apr 2003 14:59:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NLxnuc010617 for ; Wed, 23 Apr 2003 14:59:49 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id OAA16464 for ; Wed, 23 Apr 2003 14:59:44 -0700 (PDT) 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, 23 Apr 2003 21:59:43 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, 23 Apr 2003 21:59: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; Wed, 23 Apr 2003 21:59:42 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 21:59:42 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3NLxbv28151; Wed, 23 Apr 2003 17:59:40 -0400 (EDT) Date: Wed, 23 Apr 2003 17:59:37 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Architectural Considerations section in specs Message-Id: <20030423175937.3b28f432.moore@cs.utk.edu> In-Reply-To: <033901c309a9$45d0f130$261e4104@eagleswings> References: <70125434335.20030419164712@brandenburg.com> <033901c309a9$45d0f130$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What they are missing is that a defined prefix doesn't create the > problem that they are complaining about. Limiting the usable scope of > addresses is an operations decision. Tony, this discussion is about ambiguous addresses. Your persistent attempt to conflate it with packet filtering and/or routing policy isn't shedding any light on the argument. And you're smart enough to know the difference. > Defining a prefix for those only made it *possible* for apps to > recognize which ones might be restricted. But it doesn't help apps know *how* those addresses are restricted. > It does not *make* apps deal > with the problem of leaking addresses outside their scope of relevance > (unless you take the viewpoint that end users actually expect > applications to work right, and will require it once it is possible). Experience indicates that this is exactly what happens. You cannot expect apps to not leak addresses outside of their scope because apps do need to pass addresses around and they have no way of being aware of their scope boundaries. The way to solve this problem is to make addresses unique. > Applications are not required to understand topology, unless and until > they insist on passing around topology specific information. Another attempt at disinformation on your part. The fact that the current internet architecture doesn't provide us with reliable endpoint identifiers that are independent of topology information is not a justification for asserting that applications should not pass around the best endpoint identifiers that are available to them. And very few applications use these as anything other than opaque tokens. > There is no magic here, and defining a prefix didn't change the > architecture. defining a prefix didn't change the architecture - asserting that the same prefix could be reused in multiple locations did change the architecture. > Operational decisions established the architecture, and > it is our job to define the technologies that work within that > architectural reality. indeed. this is precisely why we are deprecating site locals - because they do not work within the architectural reality. 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 Apr 23 15:07:40 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 h3NM7ehs021674; Wed, 23 Apr 2003 15:07:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NM7d5L021673; Wed, 23 Apr 2003 15:07:39 -0700 (PDT) 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 h3NM7Zhs021666 for ; Wed, 23 Apr 2003 15:07:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NM7gFC029191 for ; Wed, 23 Apr 2003 15:07:43 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id QAA04570 for ; Wed, 23 Apr 2003 16:07:36 -0600 (MDT) 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, 23 Apr 2003 22:07: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, 23 Apr 2003 22:07: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, 23 Apr 2003 22:07:35 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 22:07:35 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3NM7Vv28177; Wed, 23 Apr 2003 18:07:31 -0400 (EDT) Date: Wed, 23 Apr 2003 18:07:31 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, john-ietf@jck.com, dts@senie.com, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030423180731.4137efe7.moore@cs.utk.edu> In-Reply-To: <037501c309d2$7986ded0$261e4104@eagleswings> References: <272103303.1051111464@p3.JCK.COM> <037501c309d2$7986ded0$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If the app is > going to insist on passing around topology information, it has to make > sure that matches the topology being used. agreed. and by far the easiest way to do this is to have all points on the network use consistent names for points in the network topology. the real problem is that people have been conditioned to believe that ambiguous addresses are a security feature, when what this actually serves to do is reduce their ability to apply security in depth. > > If the applications don't > > need to know, and can function in a multiple-address-per-host > > environment without --in the application-- having to determine > > which one to use by some type of iteration process, then you > > need to justify specialized addresses only in terms of their > > requires lower in the stack. If the applications do need to > > know, then the complexity costs appear to be high enough to > > present an insurmountable barrier. > > The current IPv4 network already requires this of applications, the > developers simply choose to ignore reality. until recently 'reality' was that the vast majority of ipv4 hosts had only one network interface, and one address, and most of the rest of the hosts could act as if they only had one interface and one address. so application writers were paying attention to reality, even if they weren't handling (or able to handle) every case that might potentially arise. > My primary issue is that there > are a variety of things people want to use SL for and removing an > existing mechanism without appropriate replacements for all of them > first is an irresponsible act. we need a list of these things, so we can work on a list of replacements. 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 Apr 23 15:12: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 h3NMCrhs021844; Wed, 23 Apr 2003 15:12:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NMCrR5021843; Wed, 23 Apr 2003 15:12:53 -0700 (PDT) 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 h3NMCmhs021827 for ; Wed, 23 Apr 2003 15:12:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NMCtuc015123 for ; Wed, 23 Apr 2003 15:12:55 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id QAA06709 for ; Wed, 23 Apr 2003 16:12:47 -0600 (MDT) 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, 23 Apr 2003 22:12: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; Wed, 23 Apr 2003 22:12: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; Wed, 23 Apr 2003 22:12:46 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 22:12:46 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3NMCRv28184; Wed, 23 Apr 2003 18:12:27 -0400 (EDT) Date: Wed, 23 Apr 2003 18:12:27 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, dts@senie.com, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030423181227.62fec8c7.moore@cs.utk.edu> In-Reply-To: <036f01c309ce$19def160$261e4104@eagleswings> References: <5.2.1.1.2.20030423133826.02ba3f70@mail.amaranth.net> <036f01c309ce$19def160$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I agree education is appropriate. Part of that is educating the > application development community that the real network has addressing > with limited scopes of relevance, so blindly assuming a flat routing > space and passing around topology specific information will result in > broken apps. This is ridiculous. Tony, we understand that we don't have a completely connected network. We've understood that for years. But we're not willing to adopt your delusions that this is the same problem as having ambiguous addresses. 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 Apr 23 15:42: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 h3NMgThs022402; Wed, 23 Apr 2003 15:42:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NMgTDK022401; Wed, 23 Apr 2003 15:42:29 -0700 (PDT) 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 h3NMgQhs022394 for ; Wed, 23 Apr 2003 15:42:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NMgXFC010412 for ; Wed, 23 Apr 2003 15:42:33 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA00594 for ; Wed, 23 Apr 2003 16:42:27 -0600 (MDT) 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, 23 Apr 2003 22:42: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; Wed, 23 Apr 2003 22:42: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, 23 Apr 2003 22:42:24 Z Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [210.49.138.109]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 22:42:22 Z Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h3NMfvab045024; Thu, 24 Apr 2003 08:41:57 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h3NMfrdV067607; Thu, 24 Apr 2003 08:41:53 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200304232241.h3NMfrdV067607@drugs.dv.isc.org> To: Shannon -jj Behrens Cc: S Ramesh , Ravi Kumar M , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: IPv6 Address validation In-reply-to: Your message of "Wed, 23 Apr 2003 08:30:44 MST." <20030423153044.GB33177@alicia.nttmcl.com> Date: Thu, 24 Apr 2003 08:41:53 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is the following a legal IPv6 literal? The RFC's are unclear about whether leading zeros are allowed or not if they would make a segment more than 4 character wide. 1234:1234:1234:1234:01234:: Note I would never expect inet_ntop() to produce the above. We were discussing this when reviewing our inet_pton() implementation. Mark > /* > * Author: Shannon -jj Behrens > * Date: Fri Nov 1 12:09:17 PST 2002 > * > * Given a string on the command line, return 0 if the string is a valid IPv6 > > * address, 1 otherwise. > */ > > #include > #include > #include > #include > #include > #include > #include > #include > #include > > char *argv0; /* This is argv[0] sans path. */ > > /* Output usage information to the user and exit. */ > void > usage () > { > fprintf (stderr, "usage: %s [-v] address\n", argv0); > exit (1); > } > > int > main (int argc, char *argv[]) > { > int optchar, verbose = 0, is_ipv6addr; > struct sockaddr addr; > > argv0 = argv[0] = basename (argv[0]); > while ((optchar = getopt (argc, argv, "v")) != -1) > switch (optchar) > { > case 'v': > verbose = 1; > break; > default: > usage (); > } > if (optind + 1 != argc) > usage (); > is_ipv6addr = inet_pton (AF_INET6, argv[optind], &addr); > if (is_ipv6addr < 0) > { > fprintf (stderr, "%s: inet_pton: %s\n", argv0, strerror (errno)); > return 1; > } > if (verbose) > { > if (is_ipv6addr) > printf ("%s is a valid IPv6 address.\n", argv[optind]); > else > printf ("%s is not a valid IPv6 address.\n", argv[optind]); > } > > return !is_ipv6addr; > } > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 15:52: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 h3NMqbhs022475; Wed, 23 Apr 2003 15:52:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NMqa1L022474; Wed, 23 Apr 2003 15:52:36 -0700 (PDT) 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 h3NMpfhs022444 for ; Wed, 23 Apr 2003 15:51:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NMpmuc026879 for ; Wed, 23 Apr 2003 15:51:48 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA05917 for ; Wed, 23 Apr 2003 16:51:43 -0600 (MDT) 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, 23 Apr 2003 22:51:43 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, 23 Apr 2003 22:51: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; Wed, 23 Apr 2003 22:51:42 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 22:51:42 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Apr 2003 15:51:40 -0700 Reply-To: From: "Tony Hain" To: "'Keith Moore'" Cc: , , , Subject: RE: A follow up question Date: Wed, 23 Apr 2003 15:51:40 -0700 Message-Id: <038e01c309ea$e7927c00$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030423180731.4137efe7.moore@cs.utk.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > we need a list of these things, so we can work on a list of > replacements. I am accepting comments for: http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-00.txt 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 Apr 23 15:52:46 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 h3NMqjhs022493; Wed, 23 Apr 2003 15:52:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NMqjVP022492; Wed, 23 Apr 2003 15:52:45 -0700 (PDT) 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 h3NMqXhs022455 for ; Wed, 23 Apr 2003 15:52:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NMqHFC013696 for ; Wed, 23 Apr 2003 15:52:17 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA15285 for ; Wed, 23 Apr 2003 15:52:12 -0700 (PDT) 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, 23 Apr 2003 22:52:11 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, 23 Apr 2003 22:52: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; Wed, 23 Apr 2003 22:52:11 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 22:52:10 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3NMppL09787; Wed, 23 Apr 2003 17:51:51 -0500 Message-Id: <001d01c309ea$eeb87890$93b58742@ssprunk> From: "Stephen Sprunk" To: , "'Daniel Senie'" Cc: , References: <036f01c309ce$19def160$261e4104@eagleswings> Subject: Re: A follow up question Date: Wed, 23 Apr 2003 17:44:31 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Tony Hain" > If Bl & Bg had indicators of scope differentiation in the prefix, A could > recognize the difference if it bothered to look. It wouldn't have to, but > if it didn't it would either have to refer the name, or provide C with the > entire list so it could figure out which one works. Brian's C000 thread > was exploring this space. "Global" addresses can be scoped by administrative/security devices just as easily as non-globals, so a scope indicator in the address is merely a hint which may lead the app/stack astray. The only way to determine if a given address, global or otherwise, will work is to try using it. SL does not solve -- nor did it create -- this problem any more than RFC1597 did. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 15:52: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 h3NMqkhs022496; Wed, 23 Apr 2003 15:52:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NMqkuh022494; Wed, 23 Apr 2003 15:52:46 -0700 (PDT) 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 h3NMqYhs022467 for ; Wed, 23 Apr 2003 15:52:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NMm6FC012261 for ; Wed, 23 Apr 2003 15:48:06 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA03669 for ; Wed, 23 Apr 2003 16:48:00 -0600 (MDT) 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, 23 Apr 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; Wed, 23 Apr 2003 22:47:59 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, 23 Apr 2003 22:47:38 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 22:47:38 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Apr 2003 15:47:37 -0700 Reply-To: From: "Tony Hain" To: "'Keith Moore'" Cc: , Subject: RE: Architectural Considerations section in specs Date: Wed, 23 Apr 2003 15:47:37 -0700 Message-Id: <038d01c309ea$56859c60$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030423175937.3b28f432.moore@cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3NMqZhs022468 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > Tony, this discussion is about ambiguous addresses. Your > persistent attempt to conflate it with packet filtering > and/or routing policy isn't shedding any light on the > argument. And you're smart enough to know the difference. Yes, but you keep changing the argument. On 4/18 it was: >> introduction of scoped addresses causes far more problems than it solves. Today it is ambiguity. I was trying to separate the discussion by focusing explicitly on the scoped address issue. > > > Defining a prefix for those only made it *possible* for apps to > > recognize which ones might be restricted. > > But it doesn't help apps know *how* those addresses are restricted. No, but a limited hint is useful in many situations. Should we have better tools? By all means. That does not mean we get rid of something that has some utility before we show that it has none because there are alternatives. > > > It does not *make* apps deal > > with the problem of leaking addresses outside their scope > of relevance > > (unless you take the viewpoint that end users actually expect > > applications to work right, and will require it once it is > possible). > > Experience indicates that this is exactly what happens. You > cannot expect apps to not leak addresses outside of their > scope because apps do need to pass addresses around and they > have no way of being aware of their scope boundaries. The > way to solve this problem is to make addresses unique. I do not buy the assertion that 'apps need to pass addresses around'. It is possible for apps to choose passing around names and let the topology get sorted out by the name resolution infrastructure. As I said to JCK, you can't have it both ways. You can either choose to keep it all below the app layer by passing around names, or if the app chooses to reach down and get topology information it has bought into the responsibility to understand what it is doing. > > > Applications are not required to understand topology, > unless and until > > they insist on passing around topology specific information. > > Another attempt at disinformation on your part. The fact > that the current internet architecture doesn't provide us > with reliable endpoint identifiers that are independent of > topology information is not a justification for asserting > that applications should not pass around the best endpoint > identifiers that are available to them. And very few > applications use these as anything other than opaque tokens. You insist on the right to reach down and get lower layer information, but refuse to accept the responsibility that goes along with having it. ??? If the app chose to use a name as the endpoint identifier, it would have the conflict. > > > There is no magic here, and defining a prefix didn't change the > > architecture. > > defining a prefix didn't change the architecture - asserting > that the same prefix could be reused in multiple locations > did change the architecture. This is more an argument to define ways to disambiguate the current space than it is to remove a well-known prefix for use in local scopes. Get your arguments straight, and you will realize all this deprecate SL nonsense is a waste of time. We need to solve the fact that apps refuse to acknowledge they are ignoring topological reality, and the ambiguity argument become simply a matter of subnet routing collisions during mergers. > > > Operational decisions established the architecture, and > > it is our job to define the technologies that work within that > > architectural reality. > > indeed. this is precisely why we are deprecating site locals > - because they do not work within the architectural reality. No, the apps that insist on reaching down and getting lower layer information that they don't understand is what doesn't work. Deprecating SL makes absolutely no difference to this, because the same issues will crop up for globally unique local scope addresses. Before you say it, the 'connect to the wrong node' argument is an IPv4 artifact. With IPv6 auto-conf, or even manual conf using a discarded MAC, the probability of a SL address actually pointing to two nodes is close to zero, and even lower than that for those both being reachable from participants in the same multi-party app. Go back through all your arguments about the evil's of SL, and see how many go away if the prefix is disambiguated. Then look at the fact that A can't tell C the difference between Bl & Bg unless there is some indicator. 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 Apr 23 15:54:14 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 h3NMsDhs022548; Wed, 23 Apr 2003 15:54:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NMsD6D022547; Wed, 23 Apr 2003 15:54:13 -0700 (PDT) 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 h3NMs8hs022537 for ; Wed, 23 Apr 2003 15:54:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NMsGFC014338 for ; Wed, 23 Apr 2003 15:54:16 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA22811 for ; Wed, 23 Apr 2003 16:54:04 -0600 (MDT) 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, 23 Apr 2003 22:53: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; Wed, 23 Apr 2003 22:53: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; Wed, 23 Apr 2003 22:53:38 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 22:53:37 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Apr 2003 15:53:36 -0700 Reply-To: From: "Tony Hain" To: "'Keith Moore'" Cc: , , Subject: RE: A follow up question Date: Wed, 23 Apr 2003 15:53:36 -0700 Message-Id: <038f01c309eb$2cc8af60$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030423181227.62fec8c7.moore@cs.utk.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > I agree education is appropriate. Part of that is educating the > > application development community that the real network has > addressing > > with limited scopes of relevance, so blindly assuming a > flat routing > > space and passing around topology specific information will > result in > > broken apps. > > This is ridiculous. Tony, we understand that we don't have a > completely connected network. We've understood that for years. > But we're not willing to adopt your delusions that this is > the same problem as having ambiguous addresses. I am focusing on your 4/18 assertion: introduction of scoped addresses causes far more problems than it solves. I am not talking at all about ambiguity. 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 Apr 23 16:23:46 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 h3NNNjhs023966; Wed, 23 Apr 2003 16:23:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NNNj8r023965; Wed, 23 Apr 2003 16:23:45 -0700 (PDT) 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 h3NNNghs023958 for ; Wed, 23 Apr 2003 16:23:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NNNnuc008388 for ; Wed, 23 Apr 2003 16:23:49 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id RAA04808 for ; Wed, 23 Apr 2003 17:23:43 -0600 (MDT) 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, 23 Apr 2003 23:23:42 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, 23 Apr 2003 23:23: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; Wed, 23 Apr 2003 23:23:41 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 23:23:41 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3NNNYL10478; Wed, 23 Apr 2003 18:23:34 -0500 Message-Id: <002701c309ef$5c64ced0$93b58742@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" , Cc: , References: <70125434335.20030419164712@brandenburg.com><033901c309a9$45d0f130$261e4104@eagleswings> <20030423175937.3b28f432.moore@cs.utk.edu> Subject: Re: Architectural Considerations section in specs Date: Wed, 23 Apr 2003 18:08:27 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Keith Moore" > Tony, this discussion is about ambiguous addresses. Your persistent > attempt to conflate it with packet filtering and/or routing policy isn't > shedding any light on the argument. And you're smart enough to know > the difference. And you're conflating ambiguous addressing with scoping. > You cannot expect apps to not leak addresses outside of their scope > because apps do need to pass addresses around and they have no > way of being aware of their scope boundaries. The way to solve this > problem is to make addresses unique. Give everyone global addresses and the scoping problem remains unchanged. Even "global" addresses are scoped by administrative or security policies. Having a prefix set aside for private addresses, whether SL or RFC1918, is convenient for humans, that's all. It may make scoping easier or more common, but it's not the cause. > > There is no magic here, and defining a prefix didn't change the > > architecture. > > defining a prefix didn't change the architecture - asserting that the > same prefix could be reused in multiple locations did change the > architecture. Perhaps. There is no functional difference unless multiple instances of the same address are actually _reachable_ by a third party; the mere existence of duplicates does not change the architecture. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 16:28:48 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 h3NNSlhs024116; Wed, 23 Apr 2003 16:28:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NNSlUr024113; Wed, 23 Apr 2003 16:28:47 -0700 (PDT) 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 h3NNShhs024099 for ; Wed, 23 Apr 2003 16:28:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NNSoFC026371 for ; Wed, 23 Apr 2003 16:28:50 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id RAA06438 for ; Wed, 23 Apr 2003 17:28:43 -0600 (MDT) 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, 23 Apr 2003 23:27: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; Wed, 23 Apr 2003 23:27: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; Wed, 23 Apr 2003 23:27: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; Wed, 23 Apr 2003 23:27:33 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 QAA02856 for ; Wed, 23 Apr 2003 16:27:32 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3NNRWR07547 for ; Wed, 23 Apr 2003 16:27:32 -0700 X-mProtect: <200304232327> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdl6q0AM; Wed, 23 Apr 2003 16:27:30 PDT Message-Id: <3EA7220F.90808@iprg.nokia.com> Date: Wed, 23 Apr 2003 16:30:23 -0700 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: ipng@sunroof.eng.sun.com Subject: Path MTU discovery and IPv6-in-IPv4 tunnels References: <5.1.0.14.2.20030419065656.03397738@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the packetization layer path MTU discovery (plpmtud) bof at IETF 56, we were shown a new method for determining path mtu that does not rely on ICMPs. For more details, see the BOF agenda at: http://www.ietf.org/ietf/03mar/plpmtud.txt The plpmtud method expects link layers to pass the largest possible packets while being consistent about what packet sizes are acceptable, but this can be difficult for IPv6-in-IPv4 tunnels. (Basically, tunnels need to strike a balance between passing large packets and avoiding excessive fragmentation in the IPv4 network.) A new draft entitled: "Path MTU Support for IPv6-in-IPv4 Tunnels" is available that specifies a means for IPv6-in-IPv4 tunnels to more fully participate in path MTU discovery. The mechanisms can be applied to various IPv6-in-IPv4 tunneling schemes, including 6to4, isatap, teredo, 6over4, and RFC 2893(bis). Comments on the document are welcome: http://www.ietf.org/internet-drafts/draft-templin-tunnelmtu-00.txt 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 Wed Apr 23 16:34: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 h3NNYOhs024466; Wed, 23 Apr 2003 16:34:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NNYOPe024465; Wed, 23 Apr 2003 16:34:24 -0700 (PDT) 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 h3NNYJhs024455 for ; Wed, 23 Apr 2003 16:34:19 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NNYRuc011696 for ; Wed, 23 Apr 2003 16:34:27 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3NNYLrZ018558 for ; Wed, 23 Apr 2003 16:34:22 -0700 (PDT) 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, 23 Apr 2003 23:34: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, 23 Apr 2003 23:34: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, 23 Apr 2003 23:34:21 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 23:34:21 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3NNYDv28248; Wed, 23 Apr 2003 19:34:15 -0400 (EDT) Date: Wed, 23 Apr 2003 19:34:13 -0400 From: Keith Moore To: "Stephen Sprunk" Cc: moore@cs.utk.edu, alh-ietf@tndh.net, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Architectural Considerations section in specs Message-Id: <20030423193413.5d7c86bb.moore@cs.utk.edu> In-Reply-To: <002701c309ef$5c64ced0$93b58742@ssprunk> References: <70125434335.20030419164712@brandenburg.com> <033901c309a9$45d0f130$261e4104@eagleswings> <20030423175937.3b28f432.moore@cs.utk.edu> <002701c309ef$5c64ced0$93b58742@ssprunk> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Tony, this discussion is about ambiguous addresses. Your persistent > > attempt to conflate it with packet filtering and/or routing policy > > isn't shedding any light on the argument. And you're smart enough > > to know the difference. > > And you're conflating ambiguous addressing with scoping. nope. the property that I'm concerned about is not that an address may only be usable within a particular portion of the network, it's that the address is ambiguous. so given an address there's no way to know whether or not it is valid, or why it doesn't seem to work to let you connect with the host/peer/server you think it's associated with. > > defining a prefix didn't change the architecture - asserting that > > the same prefix could be reused in multiple locations did change the > > architecture. > > Perhaps. There is no functional difference unless multiple instances > of the same address are actually _reachable_ by a third party; the > mere existence of duplicates does not change the architecture. wrong. it's useful to have unique names for hosts (or points on the network) even if they're not directly reachable by everyone who might possess those names. 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 Apr 23 16:38:35 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 h3NNcZhs024704; Wed, 23 Apr 2003 16:38:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NNcZDF024702; Wed, 23 Apr 2003 16:38:35 -0700 (PDT) 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 h3NNcUhs024689 for ; Wed, 23 Apr 2003 16:38:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NNcbFC029637 for ; Wed, 23 Apr 2003 16:38:38 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA21858 for ; Wed, 23 Apr 2003 17:38:32 -0600 (MDT) 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, 23 Apr 2003 23:38: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; Wed, 23 Apr 2003 23:34:23 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, 23 Apr 2003 23:38:30 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 23:38:30 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3NNcQv28263; Wed, 23 Apr 2003 19:38:26 -0400 (EDT) Date: Wed, 23 Apr 2003 19:38:25 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, dts@senie.com, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030423193825.018f6b77.moore@cs.utk.edu> In-Reply-To: <038f01c309eb$2cc8af60$261e4104@eagleswings> References: <20030423181227.62fec8c7.moore@cs.utk.edu> <038f01c309eb$2cc8af60$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Tony, we understand that we don't have a > > completely connected network. We've understood that for years. > > But we're not willing to adopt your delusions that this is > > the same problem as having ambiguous addresses. > > I am focusing on your 4/18 assertion: introduction of scoped addresses > causes far more problems than it solves. > > I am not talking at all about ambiguity. ambiguity is certainly one class of problems that site locals cause. now whether you define scoped addresses as "names for locations in the network whose meanings are relative to a particular subset of the network, and which may have other meanings in other subsets of the network", or "addresses are only reachable from a particular portion of the network" is, I suppose, fairly arbitrary. I've been using the former definition. 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 Apr 23 16:39:49 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 h3NNdnhs024807; Wed, 23 Apr 2003 16:39:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NNdm5Z024806; Wed, 23 Apr 2003 16:39:48 -0700 (PDT) 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 h3NNdihs024797 for ; Wed, 23 Apr 2003 16:39:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NNdquc013228 for ; Wed, 23 Apr 2003 16:39:52 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA22429 for ; Wed, 23 Apr 2003 17:39:46 -0600 (MDT) 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, 23 Apr 2003 23:39: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; Wed, 23 Apr 2003 23:39: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, 23 Apr 2003 23:39:45 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 23:39:45 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3NNdbL10885; Wed, 23 Apr 2003 18:39:37 -0500 Message-Id: <004e01c309f1$9a92b4e0$93b58742@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" , Cc: , , , , References: <272103303.1051111464@p3.JCK.COM><037501c309d2$7986ded0$261e4104@eagleswings> <20030423180731.4137efe7.moore@cs.utk.edu> Subject: Re: A follow up question Date: Wed, 23 Apr 2003 18:29:18 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Keith Moore" > > My primary issue is that there are a variety of things people want to > > use SL for and removing an existing mechanism without appropriate > > replacements for all of them first is an irresponsible act. > > we need a list of these things, so we can work on a list of > replacements. Top of the list: a portable but unroutable prefix, say a /48, that doesn't require recurring fees to an RIR or ISP. I don't require it to be unique (since it's unroutable), but that's your call. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 16:59: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 h3NNx5hs025708; Wed, 23 Apr 2003 16:59:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3NNx5rG025707; Wed, 23 Apr 2003 16:59:05 -0700 (PDT) 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 h3NNx1hs025700 for ; Wed, 23 Apr 2003 16:59:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3NNx8FC005604 for ; Wed, 23 Apr 2003 16:59:08 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA12931 for ; Wed, 23 Apr 2003 17:59:03 -0600 (MDT) 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, 23 Apr 2003 23:59:02 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, 23 Apr 2003 23:54:54 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, 23 Apr 2003 23:59:02 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 23 Apr 2003 23:59:02 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3NNx0v28290; Wed, 23 Apr 2003 19:59:00 -0400 (EDT) Date: Wed, 23 Apr 2003 19:59:00 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Architectural Considerations section in specs Message-Id: <20030423195900.5f0945bf.moore@cs.utk.edu> In-Reply-To: <038d01c309ea$56859c60$261e4104@eagleswings> References: <20030423175937.3b28f432.moore@cs.utk.edu> <038d01c309ea$56859c60$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > Defining a prefix for those only made it *possible* for apps to > > > recognize which ones might be restricted. > > > > But it doesn't help apps know *how* those addresses are restricted. > > No, but a limited hint is useful in many situations. Should we have > better tools? By all means. That does not mean we get rid of something > that has some utility before we show that it has none because there > are alternatives. it's not as if all of the utility for scoped addresses is positive. it does make sense to get rid of things with significant negative utility, particularly when the supposed positive utility is not compelling. site-local is not useful as a limited hint that the addresses are restricted, because the scope of such restrictions is still invisible to apps, and because there is no policy for use of site-local by apps which will work reliably across different network setups. and any measures that apps might undertake to work in the presence of site-locals will work even better (more efficiently and more reliably) if globals are used. > I do not buy the assertion that 'apps need to pass addresses around'. you're simply mistaken about that. until we have reliable, universal, distinguished names for (possibly virtual) hosts that can be used as endpoints in TCP and UDP, etc., and as long as there is ever a need to unambiguously refer to a network location, we're going to need to pass addresses around. > It is possible for apps to choose passing around names and let the > topology get sorted out by the name resolution infrastructure. not in any naming system that we have today, or are likely to have deployed within ten years. > As I said to JCK, you can't have it both ways. You can either choose > to keep it all below the app layer by passing around names, or if the > app chooses to reach down and get topology information it has bought > into the responsibility to understand what it is doing. not if the app treats the addresses as opaque tokens. > You insist on the right to reach down and get lower layer information, > but refuse to accept the responsibility that goes along with having > it.??? overloading of IP addresses to be multiple things (among them endpoint identifiers, interface identifiers, network locations, host identifiers, even authentication principals) is deeply embedded in the IP architecture. you may think it's a poor compromise, and lots of people would agree with you. but nobody has demonstrated a complete solution that appears to be a better way for things to work. and given this deliberate overloading, it's disingenous for you to claim that addresses are inherently lower layer information (more correctly, they're shared between layers), and that apps that use addresses as opaque tokens somehow have some new responsibility for dealing with ambiguity that you've decided to burden them with. > > defining a prefix didn't change the architecture - asserting > > that the same prefix could be reused in multiple locations > > did change the architecture. > > This is more an argument to define ways to disambiguate the current > space than it is to remove a well-known prefix for use in local > scopes. I don't believe there is a good way to disambigate the current SL space; there simply aren't enough bits available. Nor do I believe (for reasons cited elsewhere) that it is desirable to burden hosts and apps with having to deal with more addresses than are necessary to name the network locations to which they are attached, nor to embed information about reachability within addresses, nor to expect hosts and/or apps to select the "right" set of addresses to get from point A to point B. so there are indeed other problems with site local even if you make them globally unique; it's just that lack of uniqueness is the worst problem. > > > Operational decisions established the architecture, and > > > it is our job to define the technologies that work within that > > > architectural reality. > > > > indeed. this is precisely why we are deprecating site locals > > - because they do not work within the architectural reality. > > No, the apps that insist on reaching down and getting lower layer > information that they don't understand is what doesn't work. wrong. if they tried to treat those identifiers as anything other than opaque tokens, I might agree with you. but very few apps do that, and I'm not worried about those that do. indeed, it's the expectation that apps need to start treating addresses as other than opaque tokens, for instance by having to use different addresses in different situations in order to reach the same point on the network, that I'm arguing against. 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 Apr 23 18:32: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 h3O1WQhs026294; Wed, 23 Apr 2003 18:32:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3O1WQQb026293; Wed, 23 Apr 2003 18:32:26 -0700 (PDT) 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 h3O1WLhs026286 for ; Wed, 23 Apr 2003 18:32:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3O1WTFC001649 for ; Wed, 23 Apr 2003 18:32:29 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id TAA29816 for ; Wed, 23 Apr 2003 19:32:23 -0600 (MDT) 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, 24 Apr 2003 01:32:03 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, 24 Apr 2003 01:32:02 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, 24 Apr 2003 01:32:02 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 01:32:02 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3O1Vuv28982; Wed, 23 Apr 2003 21:31:56 -0400 (EDT) Date: Wed, 23 Apr 2003 21:31:56 -0400 From: Keith Moore To: John C Klensin Cc: moore@cs.utk.edu, dts@senie.com, alh-ietf@tndh.net, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030423213156.6a157a35.moore@cs.utk.edu> In-Reply-To: <272103303.1051111464@p3.JCK.COM> References: <553440000.1051111983@askvoll.hjemme.alvestrand.no> <5.2.1.1.2.20030423133826.02ba3f70@mail.amaranth.net> <272103303.1051111464@p3.JCK.COM> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Daniel Senie writes: > > Separately, if there is genuine interest in addressing the > > scoping problem, I suggest that be addressed separately. I guess it depends on what you define as "the scoping problem". If the problem is that the network can impose apparently arbitrary restrictions on whether hosts can communicate between point A and point B (for arbitrary A and B) I don't see that as an architectural problem, nor something that should be the responsibility of applications to solve. and if you define the problem as that hosts are expected to be able to simultaneously have access to multiple scopes that must be accessed via different source addresses or different network interfaces or different tunnels, and to be able to provide connectivity to each of those for applications on that host, I still have to question whether giving each scope a separate address prefix is a constructive way to implement that. so is there a definition for "the scoping problem" that you have in mind? John Klensin writes: > Tony, I think this pretty well reflects where I've found myself > going on this, fwiw. From an applications standpoint, the > scoping issues, and what is, or is not, "topology information", > just obscure the problem. "The problem", from an applications > point of view, is that, if we are going to stop pretending that > the address space is completely flat and global --and I agree > that to do otherwise is unrealistic at this stage-- then we need > a model by which the application can specify to the stack what > it needs/ expects, and the stack can tell the application > whatever the latter really needs to know about what is > happening. I don't see why it's unrealistic to have a global address space that encompasses all hosts that are connected any network that is connected to the Internet, and to expect applications to use that global address space. I agree that we cannot expect complete or near-complete connectivity. In my mind, the reason we need feedback from the network to applications about when applications try to violate administrative prohibitions on use of the network is not so that applications can try to route the messages through other paths (though it does enable that to some limited degree) but so that applications can provide accurate indications to their users as to why they're failing. > ICMP, as now defined and used, won't help with the > problem for a reason much more pervasive than the one Daniel and > others have identified: most of our current applications have no > interaction with either ICMP or IP -- they call on TCP or UDP > functions and don't know about the internet layer. The Internet > layer doesn't have any path (by "signalling" or otherwise) to > pass information back to the apps. I don't see why TCP and/or UDP stacks can't provide such interfaces to applications, even though of course this means that there will need to be other interfaces (invisible to applications) between TCP and IP and UDP and IP to pass that information upstream. > So, I would suggest that we really do have a problem here. > Unless we have a realistic proposal for a routing fabric that is > not dependent on the addresses used, the solution-set almost > certainly includes being able to use multiple addresses per > host, with different semantics associated with those addresses. the solution set to what? I don't see what problem this is attempting to solve, but I do see lots of problems that this creates. > As the competence level of the average ISP declines (which seems > to have been a clear trend for the last several years), > multihoming (in some form) needs to increase as the only > satisfactory alternative... and it better not be only for the > rich or the huge. The idea of a single, exclusively-global, > flat address space has been history for years; we clearly aren't > going to get back there as long as different providers charge > differently for different paths (independent of any of the > enterprise localization, firewall, RIR-granted PI space, or > other issues). radical idea: we need to get away from the notion that the IP address is a path specifier and back to the notion that an IP address is a location or interface identifier or (possibly virtual) host identifier. > But, unless we are prepared to discard the model of a layered > stack architecture, or accept our applications becoming as (or > more) complex and knowledgeable about network architectures as > switches get in the PSTN, then we should be looking at stack > abstractions that permit applications to express their needs, > and get information back, without deducing network topology, > transport or mobility economics, etc. I don't think these things need to be provided in the "stack" at all - for the same reason that apps don't want to cope with them - neither the host nor the app has the information needed to make those decisions. and lacking a uniform address space, there's no basis for lower layers to make the decisions. (for some reason a potentially-changing set of IP addresses doesn't strike me as a good endpoint identifier for any layer) so we need a uniform location name space to be used by higher layers, and we need for the network to make the path selection decisions. now maybe these decisions need to be made at border routers rather than core routers (so that finer details of path selection are handled in the periphery where you get better scaling, and the core routers just forward things along pre-determined paths) but you don't want to push the routing information all the way to hosts. 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 Apr 23 18:51: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 h3O1pfhs026638; Wed, 23 Apr 2003 18:51:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3O1pfVL026637; Wed, 23 Apr 2003 18:51:41 -0700 (PDT) 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 h3O1pbhs026630 for ; Wed, 23 Apr 2003 18:51:37 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3O1pjuc015245 for ; Wed, 23 Apr 2003 18:51:45 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3O1pdrZ005529 for ; Wed, 23 Apr 2003 18:51:39 -0700 (PDT) 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, 24 Apr 2003 01:51: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, 24 Apr 2003 01:51: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, 24 Apr 2003 01:51:38 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 01:51:38 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3O1pXL13285; Wed, 23 Apr 2003 20:51:33 -0500 Message-Id: <006401c30a04$090c3dd0$93b58742@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" Cc: , , , References: <70125434335.20030419164712@brandenburg.com><033901c309a9$45d0f130$261e4104@eagleswings><20030423175937.3b28f432.moore@cs.utk.edu><002701c309ef$5c64ced0$93b58742@ssprunk> <20030423193413.5d7c86bb.moore@cs.utk.edu> Subject: Re: Architectural Considerations section in specs Date: Wed, 23 Apr 2003 20:41:42 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Keith Moore" > > And you're conflating ambiguous addressing with scoping. > > nope. the property that I'm concerned about is not that an address > may only be usable within a particular portion of the network, it's > that the address is ambiguous. As Mr. Hain pointed out, last week your argument was about scoping and apps picking addresses, not about private addresses. > so given an address there's no way to know whether or not it is valid, > or why it doesn't seem to work to let you connect with the > host/peer/server you think it's associated with. You have no way of knowing if any address is reachable from any particular location. That is not a property specific to private addresses. > > Perhaps. There is no functional difference unless multiple instances > > of the same address are actually _reachable_ by a third party; the > > mere existence of duplicates does not change the architecture. > > wrong. it's useful to have unique names for hosts (or points on the > network) even if they're not directly reachable by everyone who might > possess those names. Useful, yes; a fundamental part of the architecture, no. Removing private addresses from the IPv6 architecture is a fundamental change from IPv4: site-locals are not a new addition, just a different name. If site-locals are deprecated, the NAT/stable address/whatever crowd will just pick a different prefix to use. Worst case, they'll all pick different ones. RFC1597 didn't cause the scoped-address mess; it just provided a reasonably safe sandbox and standard semantics. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 19:12:48 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 h3O2Cmhs026976; Wed, 23 Apr 2003 19:12:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3O2Cmal026975; Wed, 23 Apr 2003 19:12:48 -0700 (PDT) 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 h3O2Cihs026968 for ; Wed, 23 Apr 2003 19:12:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3O2CpFC011171 for ; Wed, 23 Apr 2003 19:12:51 -0700 (PDT) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id TAA18273 for ; Wed, 23 Apr 2003 19:12:45 -0700 (PDT) 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, 24 Apr 2003 02:12: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; Thu, 24 Apr 2003 02:12: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; Thu, 24 Apr 2003 02:12:43 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 02:12:42 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3O2CZv29019; Wed, 23 Apr 2003 22:12:35 -0400 (EDT) Date: Wed, 23 Apr 2003 22:12:35 -0400 From: Keith Moore To: "Stephen Sprunk" Cc: moore@cs.utk.edu, alh-ietf@tndh.net, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Architectural Considerations section in specs Message-Id: <20030423221235.5e8fe4b7.moore@cs.utk.edu> In-Reply-To: <006401c30a04$090c3dd0$93b58742@ssprunk> References: <70125434335.20030419164712@brandenburg.com> <033901c309a9$45d0f130$261e4104@eagleswings> <20030423175937.3b28f432.moore@cs.utk.edu> <002701c309ef$5c64ced0$93b58742@ssprunk> <20030423193413.5d7c86bb.moore@cs.utk.edu> <006401c30a04$090c3dd0$93b58742@ssprunk> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Thus spake "Keith Moore" > > > And you're conflating ambiguous addressing with scoping. > > > > nope. the property that I'm concerned about is not that an address > > may only be usable within a particular portion of the network, it's > > that the address is ambiguous. > > As Mr. Hain pointed out, last week your argument was about scoping and > apps picking addresses, not about private addresses. indeed, there are several arguments. ambiguity is the biggest problem, but there are others. nor are they independent of one another - the problems interrlate. having ambiguous addresses makes the address selection problem more difficult, but the need to employ address selection is a problem even if all addresses are global. also, when I've been using the word "scoping" I've been talking about the scope in which an address is defined (has a well-defined meaning) rather than the scope in which an address could be used- I argue that we need globally scoped addresses even if they can only be used within a limited portion of the network. > > so given an address there's no way to know whether or not it is > > valid, or why it doesn't seem to work to let you connect with the > > host/peer/server you think it's associated with. > > You have no way of knowing if any address is reachable from any > particular location. That is not a property specific to private > addresses. they're different. if you have a globally scoped address you can try to send to it, and the network will make a best effort to get it there, modulo policy. if it doesn't know how to get the packet there, and the network "should" send an ICMP that explains the reason it can't get there. and that address will reach the same location/host from any point in the network. if you have an ambiguous address you can try to send to it, but the network can't tell where it's intended to go. to the extent that the network tries to route it somewhere, it may not end up at the location/host the sender intended, and there's no way for anyone to know that the packet is being misrouted. if an error is returned it is pretty much useless - either the host is down or the network interpreted the address in a different scope that was intended or the sending host picked the wrong interface. note that if you had a globally unique address that only works within a limited scope, it acts like any other globally scoped address. > > > Perhaps. There is no functional difference unless multiple > > > instances of the same address are actually _reachable_ by a third > > > party; the mere existence of duplicates does not change the > > > architecture. > > > > wrong. it's useful to have unique names for hosts (or points on the > > network) even if they're not directly reachable by everyone who > > might possess those names. > > Useful, yes; a fundamental part of the architecture, no. disagree. the internet protocol fundamentally depends on addresses being global - routing between arbitrarily connected IP networks cannot work without this property. furthermore there are several deep assumptions that IP addresses are uniquely assigned to hosts - for instance, IP addresses are used as TCP endpoint identifiers, and round-trip estimates are made on a per-host basis. > Removing private addresses from the IPv6 architecture is a fundamental > change from IPv4: site-locals are not a new addition, just a different > name. False. IPv4 only had private addresses for use in isolated networks, and this was a late addition, and we've learned from experience that this was a mistake. > If site-locals are deprecated, the NAT/stable address/whatever crowd > will just pick a different prefix to use. and the boogey man will come, and we'll all be attacked by terrorists flying cessna 172s. sorry, but I'm sort of fed up with living in a country that does its best to control its citizens through irrational and ungrounded fear, all the while pretending that it's good for you and ignoring the real problems that exist. I've got a pretty low tolerance for such tactics these days. yes, we have to give people good ways to solve real problems that they have. no, we don't have to legitimize every bad idea that people have put into practice merely because somebody is doing it. 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 Apr 23 19:40: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 h3O2ebhs027305; Wed, 23 Apr 2003 19:40:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3O2eaQ3027304; Wed, 23 Apr 2003 19:40:36 -0700 (PDT) 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 h3O2eXhs027297 for ; Wed, 23 Apr 2003 19:40:33 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3O2eeuc025388 for ; Wed, 23 Apr 2003 19:40:40 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id UAA08649 for ; Wed, 23 Apr 2003 20:40:35 -0600 (MDT) 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, 24 Apr 2003 02:40: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, 24 Apr 2003 02:40: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; Thu, 24 Apr 2003 02:40:23 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; Thu, 24 Apr 2003 02:40:23 Z Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 13C5B7F; Thu, 24 Apr 2003 11:39:56 +0900 (JST) To: Shannon -jj Behrens Cc: S Ramesh , Ravi Kumar M , ipng@sunroof.eng.sun.com In-reply-to: jj's message of Wed, 23 Apr 2003 08:30:44 MST. <20030423153044.GB33177@alicia.nttmcl.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: IPv6 Address validation From: itojun@iijlab.net Date: Thu, 24 Apr 2003 11:39:56 +0900 Message-Id: <20030424023956.13C5B7F@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > is_ipv6addr = inet_pton (AF_INET6, argv[optind], &addr); > if (is_ipv6addr < 0) > { > fprintf (stderr, "%s: inet_pton: %s\n", argv0, strerror (errno)); > return 1; > } the clause is buggy. inet_pton return value is defined as follows: 1: valid 0: wasn't parsable as specified address famiily -1: some other error (see errno) you need to check if is_ipv6addr is 1 or not. itojun --- The inet_pton() function converts a presentation format address (that is, printable form as held in a character string) to network format (usually a struct in_addr or some other internal binary representation, in network byte order). It returns 1 if the address was valid for the specified ad- dress family, or 0 if the address wasn't parsable in the specified ad- dress family, or -1 if some system error occurred (in which case errno will have been set). This function is presently valid for AF_INET and AF_INET6. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 21:18: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 h3O4Iahs027685; Wed, 23 Apr 2003 21:18:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3O4IaHY027684; Wed, 23 Apr 2003 21:18:36 -0700 (PDT) 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 h3O4IWhs027677 for ; Wed, 23 Apr 2003 21:18:32 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3O4IdFC000110 for ; Wed, 23 Apr 2003 21:18:39 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id WAA08193 for ; Wed, 23 Apr 2003 22:18:34 -0600 (MDT) 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, 24 Apr 2003 04:18: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; Thu, 24 Apr 2003 04:14: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; Thu, 24 Apr 2003 04:18:22 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 04:18:22 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3O4IGv29551; Thu, 24 Apr 2003 00:18:17 -0400 (EDT) Date: Thu, 24 Apr 2003 00:18:16 -0400 From: Keith Moore To: John C Klensin Cc: moore@cs.utk.edu, dts@senie.com, alh-ietf@tndh.net, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030424001816.755d0746.moore@cs.utk.edu> In-Reply-To: <299285019.1051138646@p3.JCK.COM> References: <553440000.1051111983@askvoll.hjemme.alvestrand.no> <5.2.1.1.2.20030423133826.02ba3f70@mail.amaranth.net> <272103303.1051111464@p3.JCK.COM> <20030423213156.6a157a35.moore@cs.utk.edu> <299285019.1051138646@p3.JCK.COM> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) 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 don't have a routing architecture that is > independent of the structure of IP addresses. I wish we > did. I think the fact that we don't is going to lead us > into [other] very serious problems in the long term. > But the fact remains that we don't have anything > resembling an IP-address-independent routing fabric > proposal on the table, certainly not one that is > complete enough to be plausible. > > * We are seeing more and more requirement for > multihoming of one type or another, whether you count > community wireless schemes or other small-group or > small-ISP models into the mix or not. > > One implication of the first problem is that one can't solve the > second one by giving everyone who wants to connect to more than > one provider independently-routable PI space. Now, if we don't > come up with a solution to both of those problems, it doesn't > make any difference what features are in IPv6, because IPv6 will > fail, and it will fail because the Internet --at least the > Internet as we know it-- will fail. I think we even know what > the alternative looks like, at least in general terms, with > islands of walled gardens, each with independent address spaces, > and connected by bilateral agreements being the most likely of > those alternatives. Those proposals have been around for years, > we know what they look like, and they don't provide the > edge-oriented, end-to-end, "dumb" network we all believe is the > core strength of the Internet. I don't doubt this, but it's fairly clear to me that having multiple addresses per host and expecting hosts to make decisions about which prefix to use is also highly undesirable - in the sense that it will drastically limit the set of applications that can work well. But yes, we have more of a chance of things working if they're all using a single shared address space, than we do with disjoint address spaces. I also don't see how this problem is any different between IPv4 and IPv6, except that we might eventually expect IPv6 to scale to more prefixes than IPv4. Yes, v6 hosts have the code to handle multiple prefixes and addresses, but that doesn't mean that the apps can deal reasonably with them. And in my experience even the simplest apps fail to deal reasonably with multiple prefixes. (trial-and-error, waiting tens of seconds to timeout before proceeding to the next address, is not reasonable) But we need to distinguish between what we can do in the short term and what we need to do in the long term. In the short term our choices are either to allow some form of provider-independent addressing (with all that this means for the scalability of routing) or to expect hosts and apps to deal with multiple prefixes. Which choice is better is not obvious - it depends on whether you want to optimize IPv6 for easy deployment or eventual scalability. Your answer to this question probably depends on what layer you live at. In the longer term we need to develop a way of doing a mapping from location names or endpoint names to paths through the network, one that preserves the uniqueness and structure of IPv6 addresses. > At least so far, "give every host one address and let the > network (the routers?) sort out the routing" seems to me to > reproduce the current IPv4 situation. That doesn't seem to me > to be a solution because it: > > * Assumes that everyone who has a LAN that they want to > connect to multiple providers will have routable PI > space. Or > > * Assumes that everyone who has a LAN that they want to > connect to multiple providers will be able to do so by > punching holes in CIDR blocks. To my routing-naive mind, two mechanisms seem worth investigating: - One is a mapping at the BGP layer from what I'll call path-independent prefixes to path-specific prefixes. e.g. BGP could propagate information of the form "route prefix X as if it were prefix Y". Routers wouldn't have to compute routes for prefix X, they could just compute routes for Y and then use the same entry for X as for Y in the fowarding table. This lets the number of prefixes grow to some degree without directly increasing the complexity of routing computations, as long as the set of distinct destination networks as viewed from the core did not get larger. In effect it would allow non-adjacent prefixes to be aggregated for the purpose of route table computations. Which is not to say that this comes for free, but it would let us to some degree move toward a routing structure for the core that was independent of the IP addresses used by hosts - in effect hosts and routing would use different portions of the IP space, though some amount of overlap could be tolerated. - A mobileIP-like scheme for border routers, that could issue redirects for prefixes as well as individual IP addresses. So packets for a particular destination prefix would initially go to "home network agents" that could live anywhere on the network (including a database distributed across multiple exchange points in diverse locations, all of which advertise reachability via BGP) but which (in addition to forwarding initial packets) would return redirects for entire prefixes that caused subsequent packets to be sent to the "in care of prefixes". These redirects would be intercepted and acted on by routers near the source, not (or not only) by the sending host. Yes, it would still require tunneling, or MPLS, or some other way of telling the network "route this traffic to here rather than to the destination address in the IP packet; that's for use after the packet exits our network". But there are lots of ways to do this, and perhaps they'll become more widely available over time. And for those who think these ideas are naive, keep in mind that I did say they're not near-term solutions, and that in the near term we're stuck with less sophisticated mechanisms. But we need to insist on global addressing now so that we have a way to move to better routing systems once we do solve the problems. > > I don't see why it's unrealistic to have a global address > > space that encompasses all hosts that are connected any > > network that is connected to the Internet, and to expect > > applications to use that global address space. I agree that > > we cannot expect complete or near-complete connectivity. > > But, if we have a one-address-per-host global address space -- > which I think is what you are asking for-- and don't have > near-complete connectivity, then we are either going to see > rising times to set up the typical TCP connection, and a lot of > UDP attempts fall off the edge, or we are going to need a lot > more PI space. I don't see realistic alternatives for the > reasons discussed above. Do you? And, if so, what are they? I doubt we'll see a one-size-fits-all kind of solution any time soon. Some sites will be able to make do with multiple advertised prefixes, perhaps with clever DNS tricks to try to minimize the connection failures (yeech). Other sites will be able to tolerate a single provider. Others will demand PI space and perhaps get it. Maybe they'll have to buy an ISP, or masquerade as one, to accomplish this. I've always thought the distinction between an ISP and a multi-homed, multi-sited customer was fairly arbitrary. I could imagine an arrangement where limited-time leases for use of some amount of what was effectively PI space (even if it came out of providers' allocations, it could be routed to multiple providers) was auctioned off to the highest bidders, like radio spectrum. Or maybe the problems will create a demand for more stable/clueful/expensive IP routing service. Or maybe the public Internet will just degrade to the point that it's not useful for very much. I'm not discounting that possibility, but neither do I want to dwell on it. > > In my mind, the reason we need feedback from the network to > > applications about when applications try to violate > > administrative prohibitions on use of the network is not so > > that applications can try to route the messages through other > > paths (though it does enable that to some limited degree) but > > so that applications can provide accurate indications to their > > users as to why they're failing. > > Keith, while I'm very much in favor of accurate feedback, > messages with the ultimately semantics of "you lose" have a long > and well-documented history of being unpopular with users. Granted. But there is no way that the reliability of internet applications can improve unless the network can provide such feedback to *somebody*. Now maybe it shouldn't always be the user, but the application, or the user's network administrator, or the application author/vendor. to some degree it depends on the application. But nobody can do anything about the problem without some indication that the problem exists and some way to distinguish one kind of problem from another. > I'd rather focus on getting the network to work better and more often, > while reporting accurately on failures if there is no alternative but > to fail. No question there, but if the failure is due to an administrative prohibition (which is where I thought this started), it's hard to see what it means to have the network work better and more often - unless it's to discourage use of packet filtering. :) > > I don't see why TCP and/or UDP stacks can't provide such > > interfaces to applications, even though of course this means > > that there will need to be other interfaces (invisible to > > applications) between TCP and IP and UDP and IP to pass that > > information upstream. > > They can't provide it because we don't have a model, or set of > abstractions, for providing it. If it is important, maybe we > had better get started. Has anyone made a list of important core problems that need to be worked on? 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 Apr 23 21:22:35 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 h3O4MZhs027777; Wed, 23 Apr 2003 21:22:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3O4MYZ6027776; Wed, 23 Apr 2003 21:22:34 -0700 (PDT) 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 h3O4MUhs027769 for ; Wed, 23 Apr 2003 21:22:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3O4McFC000775 for ; Wed, 23 Apr 2003 21:22:38 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3O4MWrZ019025 for ; Wed, 23 Apr 2003 21:22:33 -0700 (PDT) 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, 24 Apr 2003 04:22: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; Thu, 24 Apr 2003 04:22:32 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, 24 Apr 2003 04:22:32 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 04:22:32 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3O4MSv29559; Thu, 24 Apr 2003 00:22:28 -0400 (EDT) Date: Thu, 24 Apr 2003 00:22:28 -0400 From: Keith Moore To: John C Klensin Cc: moore@cs.utk.edu, dts@senie.com, alh-ietf@tndh.net, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030424002228.6eec7a99.moore@cs.utk.edu> In-Reply-To: <300943293.1051140305@p3.JCK.COM> References: <300943293.1051140305@p3.JCK.COM> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In the presence of an adequate abstraction model, an application > should not care whether a given host has one address or a dozen, > nor about whether such addresses were equivalent or different, > nor about whether they represent physically separate interfaces. there are lots of assumptions behind this about what an "address" is, how it gets used, when and where the address-to-host binding takes place and whether it can change, etc. that are sufficiently different than the current IP world that I can't tell what you are assuming. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 23 23:13: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 h3O6Dnhs028378; Wed, 23 Apr 2003 23:13:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3O6DnMY028377; Wed, 23 Apr 2003 23:13:49 -0700 (PDT) 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 h3O6Dkhs028370 for ; Wed, 23 Apr 2003 23:13:46 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3O6Druc029159 for ; Wed, 23 Apr 2003 23:13:53 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3O6DkrZ024306 for ; Wed, 23 Apr 2003 23:13:48 -0700 (PDT) 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, 24 Apr 2003 06:13: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; Thu, 24 Apr 2003 06:13:46 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, 24 Apr 2003 06:13:46 Z Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 06:13:45 Z Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id 2C7881C030A8; Wed, 23 Apr 2003 23:13:39 -0700 (PDT) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id LAA04958; Thu, 24 Apr 2003 11:42:50 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: , "'Shannon -jj Behrens'" Cc: "'S Ramesh'" , "'Ravi Kumar M'" , Subject: RE: IPv6 Address validation Date: Thu, 24 Apr 2003 11:42:39 +0530 Message-Id: <001c01c30a28$83083a70$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <200304232241.h3NMfrdV067607@drugs.dv.isc.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mark RFC 3513 says that, The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the hexadecimal values of the eight 16-bit pieces of the address. Examples: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 1080:0:0:0:8:800:200C:417A The only constraint here is, "x" should refer the 16 bit pieces of the address, "01234" is a valid hex number and it doesn't exeed 16 bits. I beleive a good implementation of inet_pton should ignore the leading 0s. ~Vijay -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Mark.Andrews@isc.org Sent: Thursday, April 24, 2003 4:12 AM To: Shannon -jj Behrens Cc: S Ramesh; Ravi Kumar M; ipng@sunroof.eng.sun.com Subject: Re: IPv6 Address validation Is the following a legal IPv6 literal? The RFC's are unclear about whether leading zeros are allowed or not if they would make a segment more than 4 character wide. 1234:1234:1234:1234:01234:: Note I would never expect inet_ntop() to produce the above. We were discussing this when reviewing our inet_pton() implementation. Mark > /* > * Author: Shannon -jj Behrens > * Date: Fri Nov 1 12:09:17 PST 2002 > * > * Given a string on the command line, return 0 if the string is a valid IPv6 > > * address, 1 otherwise. > */ > > #include > #include > #include > #include > #include > #include > #include > #include > #include > > char *argv0; /* This is argv[0] sans path. */ > > /* Output usage information to the user and exit. */ > void > usage () > { > fprintf (stderr, "usage: %s [-v] address\n", argv0); > exit (1); > } > > int > main (int argc, char *argv[]) > { > int optchar, verbose = 0, is_ipv6addr; > struct sockaddr addr; > > argv0 = argv[0] = basename (argv[0]); > while ((optchar = getopt (argc, argv, "v")) != -1) > switch (optchar) > { > case 'v': > verbose = 1; > break; > default: > usage (); > } > if (optind + 1 != argc) > usage (); > is_ipv6addr = inet_pton (AF_INET6, argv[optind], &addr); > if (is_ipv6addr < 0) > { > fprintf (stderr, "%s: inet_pton: %s\n", argv0, strerror (errno)); > return 1; > } > if (verbose) > { > if (is_ipv6addr) > printf ("%s is a valid IPv6 address.\n", argv[optind]); > else > printf ("%s is not a valid IPv6 address.\n", argv[optind]); > } > > return !is_ipv6addr; > } > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Apr 24 01:20: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 h3O8K5hs028854; Thu, 24 Apr 2003 01:20:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3O8K5Df028853; Thu, 24 Apr 2003 01:20:05 -0700 (PDT) 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 h3O8K1hs028846 for ; Thu, 24 Apr 2003 01:20:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3O8K8uc018963 for ; Thu, 24 Apr 2003 01:20:08 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id CAA01301 for ; Thu, 24 Apr 2003 02:20:03 -0600 (MDT) 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, 24 Apr 2003 08:20:02 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, 24 Apr 2003 08:20:02 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, 24 Apr 2003 08:20:02 Z Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 08:20:01 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.9/8.12.8) with SMTP id h3O8Jrqw028152; Thu, 24 Apr 2003 10:19:53 +0200 (MEST) Received: (from ignatios@newton.cs.uni-bonn.de) by newton.cs.uni-bonn.de (mini_sendmail/1.3.2 21nov2002 nb1 15Feb2003); Thu, 24 Apr 2003 10:18:43 CEST (sender ignatios@newton.cs.uni-bonn.de) Date: Thu, 24 Apr 2003 10:18:43 +0200 From: Ignatios Souvatzis To: ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A simple question Message-Id: <20030424081843.GA22714@newton.cs.uni-bonn.de> References: <20030422231209.438176f7.moore@cs.utk.edu> <20030423121730.18200.qmail@web10908.mail.yahoo.com> <20030423152607.79be279e.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20030423152607.79be279e.moore@cs.utk.edu> User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Apr 23, 2003 at 03:26:07PM -0400, Keith Moore wrote: > > I would be thrilled if we spent some time thinking about ICMP in > > an architectural way - however beautiful it was before ICMP > > black holing, what we have now isn't consistently usable today. > > We're spending time on point solutions (Matt Mathis on non-ICMP > > path MTU discovery as one example), but is this the best we can > > do? >=20 > I don't think we're likely to be able to dispense with ICMP. Maybe we > can find more ways to make it more trustworthy. Or maybe we just need > to discourage people from filtering it. I don't understand why this is even a point of discussion. Next you hear some people will like to globally filter TCP RST - will you rewrite TCP to work without that? Regards, -is --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPqed4TCn4om+4LhpAQFlQwgAtQ/zBELpGwtwyys49rAmQGS8GPPjdPRk /dX6xs96ff3Aj4L0c15GI+3GUxR/0WwkF6GqWCJGcGjaXH4kRxdGvK8jgrL83X3A mvRyDNsC+Vwbzwpg4U5v84OgcmBbuF4UFsEr92zWl/n9+XFP2rmZ91XYP5TtV423 jz3mBzNBbhmsgIo7xHA6DBPvDAowPpMP3wzWwPiL2XJntJyHsnoI/ev9Bhy2eccf 2adpWFFuPjJU+iISH2FYeFrG0e0SWteZFwMlxE5xQryz6bOjCHxKB9UlkaToSmQR VS6whppM0tGFoKISjwQA0WJBbTGLcL2e2r2Qa6GUJh4VyyHnZqBSIw== =cT6g -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 24 02:00:22 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 h3O90Lhs029341; Thu, 24 Apr 2003 02:00:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3O90LgJ029340; Thu, 24 Apr 2003 02:00:21 -0700 (PDT) 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 h3O90Chs029325; Thu, 24 Apr 2003 02:00:12 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3O90JFC021635; Thu, 24 Apr 2003 02:00:19 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA10667; Thu, 24 Apr 2003 03:00:13 -0600 (MDT) From: matthew.ford@bt.com Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP; Thu, 24 Apr 2003 09:00:12 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP; Thu, 24 Apr 2003 09:00:12 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP; Thu, 24 Apr 2003 09:00:12 Z Received: from cbibipnt03.HC.BT.COM ([193.113.57.20] [193.113.57.20]) by relay2.sun.com with ESMTP; Thu, 24 Apr 2003 09:00:12 Z Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Thu, 24 Apr 2003 10:00:24 +0100 Message-Id: To: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: list (sort of) fixed Date: Thu, 24 Apr 2003 10:00:06 +0100 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 out of interest, why has whatever sun have done to fix the ipng list not fixed the mobile-ip list? 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 Thu Apr 24 03:52: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 h3OAqXhs000418; Thu, 24 Apr 2003 03:52:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OAqXW9000417; Thu, 24 Apr 2003 03:52:33 -0700 (PDT) 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 h3OAqUhs000410 for ; Thu, 24 Apr 2003 03:52:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OAqZuc011711 for ; Thu, 24 Apr 2003 03:52:36 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA12731 for ; Thu, 24 Apr 2003 04:52:30 -0600 (MDT) 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, 24 Apr 2003 10:50: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, 24 Apr 2003 10:46: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; Thu, 24 Apr 2003 10:50:56 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; Thu, 24 Apr 2003 10:50:56 Z Received: (cpmta 16260 invoked from network); 24 Apr 2003 03:50:54 -0700 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.122) with SMTP; 24 Apr 2003 03:50:54 -0700 X-Sent: 24 Apr 2003 10:50:54 GMT Message-Id: <009901c30a4f$5bb5ef90$5d051eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <200304232241.h3NMfrdV067607@drugs.dv.isc.org> Subject: Re: IPv6 Address validation Date: Thu, 24 Apr 2003 13:50:42 +0300 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 ----- Original Message ----- From: > Is the following a legal IPv6 literal? The RFC's are unclear > about whether leading zeros are allowed or not if they would > make a segment more than 4 character wide. > > 1234:1234:1234:1234:01234:: It is my understanding that the address is not valid, only because you are truncating the ending zeros, not the preceding ones with the final ::. Otherwise it is valid. 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 Thu Apr 24 04:44: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 h3OBiphs000953; Thu, 24 Apr 2003 04:44:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OBipHW000952; Thu, 24 Apr 2003 04:44:51 -0700 (PDT) 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 h3OBilhs000945 for ; Thu, 24 Apr 2003 04:44:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OBiqFC015746 for ; Thu, 24 Apr 2003 04:44:52 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3OBikrZ018563 for ; Thu, 24 Apr 2003 04:44:46 -0700 (PDT) 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, 24 Apr 2003 11:44:46 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, 24 Apr 2003 11:44: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, 24 Apr 2003 11:44:45 Z Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 11:44:45 Z Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h3OBVGo25962; Thu, 24 Apr 2003 04:31:16 -0700 (PDT) From: Bill Manning Message-Id: <200304241131.h3OBVGo25962@boreas.isi.edu> Subject: Re: IPv6 Address validation In-Reply-To: <001c01c30a28$83083a70$38e62a0f@nt23056> from Vijayabhaskar A K at "Apr 24, 3 11:42:39 am" To: vijayak@india.hp.com Date: Thu, 24 Apr 2003 04:31:15 -0700 (PDT) Cc: Mark.Andrews@isc.org, jj@nttmcl.com, rashanmu@npd.hcltech.com, ravikrm@sify.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 one valid interpretation of "01234" would be 0000.0001.0010.0011.0100 which is 20 bits. % The only constraint here is, "x" should refer the 16 bit pieces % of the address, "01234" is a valid hex number and it doesn't exeed % 16 bits. % % I beleive a good implementation of inet_pton should ignore the leading % 0s. % % ~Vijay % % % -----Original Message----- % From: owner-ipng@sunroof.eng.sun.com % [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Mark.Andrews@isc.org % Sent: Thursday, April 24, 2003 4:12 AM % To: Shannon -jj Behrens % Cc: S Ramesh; Ravi Kumar M; ipng@sunroof.eng.sun.com % Subject: Re: IPv6 Address validation % % % % Is the following a legal IPv6 literal? The RFC's are unclear % about whether leading zeros are allowed or not if they would % make a segment more than 4 character wide. % % 1234:1234:1234:1234:01234:: % % Note I would never expect inet_ntop() to produce the above. % % We were discussing this when reviewing our inet_pton() % implementation. % % Mark % % > /* % > * Author: Shannon -jj Behrens % > * Date: Fri Nov 1 12:09:17 PST 2002 % > * % > * Given a string on the command line, return 0 if the string is a valid % IPv6 % > % > * address, 1 otherwise. % > */ % > % > #include % > #include % > #include % > #include % > #include % > #include % > #include % > #include % > #include % > % > char *argv0; /* This is argv[0] sans path. */ % > % > /* Output usage information to the user and exit. */ % > void % > usage () % > { % > fprintf (stderr, "usage: %s [-v] address\n", argv0); % > exit (1); % > } % > % > int % > main (int argc, char *argv[]) % > { % > int optchar, verbose = 0, is_ipv6addr; % > struct sockaddr addr; % > % > argv0 = argv[0] = basename (argv[0]); % > while ((optchar = getopt (argc, argv, "v")) != -1) % > switch (optchar) % > { % > case 'v': % > verbose = 1; % > break; % > default: % > usage (); % > } % > if (optind + 1 != argc) % > usage (); % > is_ipv6addr = inet_pton (AF_INET6, argv[optind], &addr); % > if (is_ipv6addr < 0) % > { % > fprintf (stderr, "%s: inet_pton: %s\n", argv0, strerror (errno)); % > return 1; % > } % > if (verbose) % > { % > if (is_ipv6addr) % > printf ("%s is a valid IPv6 address.\n", argv[optind]); % > else % > printf ("%s is not a valid IPv6 address.\n", argv[optind]); % > } % > % > return !is_ipv6addr; % > } % > % > -------------------------------------------------------------------- % > IETF IPng Working Group Mailing List % > IPng Home Page: http://playground.sun.com/ipng % > FTP archive: ftp://playground.sun.com/pub/ipng % > Direct all administrative requests to majordomo@sunroof.eng.sun.com % > -------------------------------------------------------------------- % -- % Mark Andrews, Internet Software Consortium % 1 Seymour St., Dundas Valley, NSW 2117, Australia % PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org % -------------------------------------------------------------------- % IETF IPng Working Group Mailing List % IPng Home 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 % -------------------------------------------------------------------- % -- --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 Apr 24 04:51: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 h3OBpahs001252; Thu, 24 Apr 2003 04:51:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OBpalM001251; Thu, 24 Apr 2003 04:51:36 -0700 (PDT) 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 h3OBpWhs001241 for ; Thu, 24 Apr 2003 04:51:32 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OBpcuc019844 for ; Thu, 24 Apr 2003 04:51:38 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id FAA21676 for ; Thu, 24 Apr 2003 05:51:32 -0600 (MDT) 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, 24 Apr 2003 11:51: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, 24 Apr 2003 11:51: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, 24 Apr 2003 11:51:32 Z Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 11:51:32 Z Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel13.hp.com (Postfix) with ESMTP id E6A7B1C00AAD; Thu, 24 Apr 2003 04:51:21 -0700 (PDT) Received: from india.hp.com (nt23053.india.hp.com [15.42.230.53]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with ESMTP id RAA02590; Thu, 24 Apr 2003 17:19:39 +0530 (IST) Message-Id: <3EA7D09C.EA88F4E8@india.hp.com> Date: Thu, 24 Apr 2003 17:25:08 +0530 From: Ramanan Reply-To: ramanan@india.hp.com Organization: HP-iso X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Cc: Mark.Andrews@isc.org, Shannon -jj Behrens , S Ramesh , Ravi Kumar M Subject: Re: IPv6 Address validation References: <200304232241.h3NMfrdV067607@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi, Mark.Andrews@isc.org wrote: > Is the following a legal IPv6 literal? The RFC's are unclear > about whether leading zeros are allowed or not if they would > make a segment more than 4 character wide. > > 1234:1234:1234:1234:01234:: defensive programming may consider this as a valid address. However, when this address is stored in buffers of limited size, it would overflow as most buffers assume 46 as the max size of an ipv6 address string. open group suggests this bufsz. > Note I would never expect inet_ntop() to produce the above. neither would I. > We were discussing this when reviewing our inet_pton() > implementation. I would prefer to code inet_pton to accept this address. because there is a possibility that some 'ill written' scripts may produce such ip addresses. scripts get preference because handwriting ipv6 addresses is a nightmare at present. Also moving on to IPv6 applications do not want to call inet_pton and but expect getaddrinfo to validate the v6 address. the expectation is that, APIs provide more options to simplify application coding. regs ramanan > Mark > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -- > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 24 07:24: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 h3OEOths002619; Thu, 24 Apr 2003 07:24:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OEOt3V002618; Thu, 24 Apr 2003 07:24:55 -0700 (PDT) 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 h3OEOqhs002611 for ; Thu, 24 Apr 2003 07:24:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OEOuFC015664 for ; Thu, 24 Apr 2003 07:24:56 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id IAA10704 for ; Thu, 24 Apr 2003 08:24:51 -0600 (MDT) 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, 24 Apr 2003 14:24: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; Thu, 24 Apr 2003 14:24: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; Thu, 24 Apr 2003 14:24:50 Z Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 14:24:50 Z Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel9.hp.com (Postfix) with ESMTP id 807A51C015CC; Thu, 24 Apr 2003 10:24:45 -0400 (EDT) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3/8.9.3 SMKit7.02) with SMTP id TAA15089; Thu, 24 Apr 2003 19:54:00 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Bill Manning'" Cc: , , , , Subject: RE: IPv6 Address validation Date: Thu, 24 Apr 2003 19:53:58 +0530 Message-Id: <001d01c30a6d$257da490$38e62a0f@nt23056> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: <200304241131.h3OBVGo25962@boreas.isi.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk since the rfc says that "x" should hold only 16 bits, the leading zeros has to be ignored -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Bill Manning Sent: Thursday, April 24, 2003 5:01 PM To: vijayak@india.hp.com Cc: Mark.Andrews@isc.org; jj@nttmcl.com; rashanmu@npd.hcltech.com; ravikrm@sify.com; ipng@sunroof.eng.sun.com Subject: Re: IPv6 Address validation one valid interpretation of "01234" would be 0000.0001.0010.0011.0100 which is 20 bits. % The only constraint here is, "x" should refer the 16 bit pieces % of the address, "01234" is a valid hex number and it doesn't exeed % 16 bits. % % I beleive a good implementation of inet_pton should ignore the leading % 0s. % % ~Vijay % % % -----Original Message----- % From: owner-ipng@sunroof.eng.sun.com % [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Mark.Andrews@isc.org % Sent: Thursday, April 24, 2003 4:12 AM % To: Shannon -jj Behrens % Cc: S Ramesh; Ravi Kumar M; ipng@sunroof.eng.sun.com % Subject: Re: IPv6 Address validation % % % % Is the following a legal IPv6 literal? The RFC's are unclear % about whether leading zeros are allowed or not if they would % make a segment more than 4 character wide. % % 1234:1234:1234:1234:01234:: % % Note I would never expect inet_ntop() to produce the above. % % We were discussing this when reviewing our inet_pton() % implementation. % % Mark % % > /* % > * Author: Shannon -jj Behrens % > * Date: Fri Nov 1 12:09:17 PST 2002 % > * % > * Given a string on the command line, return 0 if the string is a valid % IPv6 % > % > * address, 1 otherwise. % > */ % > % > #include % > #include % > #include % > #include % > #include % > #include % > #include % > #include % > #include % > % > char *argv0; /* This is argv[0] sans path. */ % > % > /* Output usage information to the user and exit. */ % > void % > usage () % > { % > fprintf (stderr, "usage: %s [-v] address\n", argv0); % > exit (1); % > } % > % > int % > main (int argc, char *argv[]) % > { % > int optchar, verbose = 0, is_ipv6addr; % > struct sockaddr addr; % > % > argv0 = argv[0] = basename (argv[0]); % > while ((optchar = getopt (argc, argv, "v")) != -1) % > switch (optchar) % > { % > case 'v': % > verbose = 1; % > break; % > default: % > usage (); % > } % > if (optind + 1 != argc) % > usage (); % > is_ipv6addr = inet_pton (AF_INET6, argv[optind], &addr); % > if (is_ipv6addr < 0) % > { % > fprintf (stderr, "%s: inet_pton: %s\n", argv0, strerror (errno)); % > return 1; % > } % > if (verbose) % > { % > if (is_ipv6addr) % > printf ("%s is a valid IPv6 address.\n", argv[optind]); % > else % > printf ("%s is not a valid IPv6 address.\n", argv[optind]); % > } % > % > return !is_ipv6addr; % > } % > % > -------------------------------------------------------------------- % > IETF IPng Working Group Mailing List % > IPng Home Page: http://playground.sun.com/ipng % > FTP archive: ftp://playground.sun.com/pub/ipng % > Direct all administrative requests to majordomo@sunroof.eng.sun.com % > -------------------------------------------------------------------- % -- % Mark Andrews, Internet Software Consortium % 1 Seymour St., Dundas Valley, NSW 2117, Australia % PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org % -------------------------------------------------------------------- % IETF IPng Working Group Mailing List % IPng Home 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 % -------------------------------------------------------------------- % -- --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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 24 07:43:14 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 h3OEhEhs002964; Thu, 24 Apr 2003 07:43:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OEhDC4002963; Thu, 24 Apr 2003 07:43:13 -0700 (PDT) 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 h3OEhAhs002956 for ; Thu, 24 Apr 2003 07:43:10 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OEhGFC019490 for ; Thu, 24 Apr 2003 07:43:16 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3OEhArZ028622 for ; Thu, 24 Apr 2003 07:43:11 -0700 (PDT) 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, 24 Apr 2003 14:43:10 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, 24 Apr 2003 14:43:09 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, 24 Apr 2003 14:43:09 Z Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 14:43:09 Z Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h3OET5c04545; Thu, 24 Apr 2003 07:29:05 -0700 (PDT) From: Bill Manning Message-Id: <200304241429.h3OET5c04545@boreas.isi.edu> Subject: Re: IPv6 Address validation In-Reply-To: <001d01c30a6d$257da490$38e62a0f@nt23056> from Vijayabhaskar A K at "Apr 24, 3 07:53:58 pm" To: vijayak@india.hp.com Date: Thu, 24 Apr 2003 07:29:05 -0700 (PDT) Cc: bmanning@isi.edu, Mark.Andrews@isc.org, jj@nttmcl.com, rashanmu@npd.hcltech.com, ravikrm@sify.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 yes, I understand. why drop the leading zeros and not the last four bits? I would assert that "01234" is illegal and one should -NOT- presume to know which are the desired bits. and yes, a good/compliant implementation of inet_pton should ignore leading zeros, if it has a way of determining that there are insignificant leading zeros. % since the rfc says that "x" should hold only 16 bits, % the leading zeros has to be ignored % % % -----Original Message----- % From: owner-ipng@sunroof.eng.sun.com % [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Bill Manning % Sent: Thursday, April 24, 2003 5:01 PM % To: vijayak@india.hp.com % Cc: Mark.Andrews@isc.org; jj@nttmcl.com; rashanmu@npd.hcltech.com; % ravikrm@sify.com; ipng@sunroof.eng.sun.com % Subject: Re: IPv6 Address validation % % % % one valid interpretation of "01234" would be % % 0000.0001.0010.0011.0100 % % which is 20 bits. % % % % The only constraint here is, "x" should refer the 16 bit pieces % % of the address, "01234" is a valid hex number and it doesn't exeed % % 16 bits. % % % % I beleive a good implementation of inet_pton should ignore the leading % % 0s. % % % % ~Vijay % % % % % % -----Original Message----- % % From: owner-ipng@sunroof.eng.sun.com % % [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Mark.Andrews@isc.org % % Sent: Thursday, April 24, 2003 4:12 AM % % To: Shannon -jj Behrens % % Cc: S Ramesh; Ravi Kumar M; ipng@sunroof.eng.sun.com % % Subject: Re: IPv6 Address validation % % % % % % % % Is the following a legal IPv6 literal? The RFC's are unclear % % about whether leading zeros are allowed or not if they would % % make a segment more than 4 character wide. % % % % 1234:1234:1234:1234:01234:: % % % % Note I would never expect inet_ntop() to produce the above. % % % % We were discussing this when reviewing our inet_pton() % % implementation. % % % % Mark % % % % > /* % % > * Author: Shannon -jj Behrens % % > * Date: Fri Nov 1 12:09:17 PST 2002 % % > * % % > * Given a string on the command line, return 0 if the string is a valid % % IPv6 % % > % % > * address, 1 otherwise. % % > */ % % > % % > #include % % > #include % % > #include % % > #include % % > #include % % > #include % % > #include % % > #include % % > #include % % > % % > char *argv0; /* This is argv[0] sans path. */ % % > % % > /* Output usage information to the user and exit. */ % % > void % % > usage () % % > { % % > fprintf (stderr, "usage: %s [-v] address\n", argv0); % % > exit (1); % % > } % % > % % > int % % > main (int argc, char *argv[]) % % > { % % > int optchar, verbose = 0, is_ipv6addr; % % > struct sockaddr addr; % % > % % > argv0 = argv[0] = basename (argv[0]); % % > while ((optchar = getopt (argc, argv, "v")) != -1) % % > switch (optchar) % % > { % % > case 'v': % % > verbose = 1; % % > break; % % > default: % % > usage (); % % > } % % > if (optind + 1 != argc) % % > usage (); % % > is_ipv6addr = inet_pton (AF_INET6, argv[optind], &addr); % % > if (is_ipv6addr < 0) % % > { % % > fprintf (stderr, "%s: inet_pton: %s\n", argv0, strerror (errno)); % % > return 1; % % > } % % > if (verbose) % % > { % % > if (is_ipv6addr) % % > printf ("%s is a valid IPv6 address.\n", argv[optind]); % % > else % % > printf ("%s is not a valid IPv6 address.\n", argv[optind]); % % > } % % > % % > return !is_ipv6addr; % % > } % % > % % > -------------------------------------------------------------------- % % > IETF IPng Working Group Mailing List % % > IPng Home Page: http://playground.sun.com/ipng % % > FTP archive: ftp://playground.sun.com/pub/ipng % % > Direct all administrative requests to majordomo@sunroof.eng.sun.com % % > -------------------------------------------------------------------- % % -- % % Mark Andrews, Internet Software Consortium % % 1 Seymour St., Dundas Valley, NSW 2117, Australia % % PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org % % -------------------------------------------------------------------- % % IETF IPng Working Group Mailing List % % IPng Home 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 % % -------------------------------------------------------------------- % % % % % -- % --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 % -------------------------------------------------------------------- % -- --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 Apr 24 09:29: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 h3OGT8hs003410; Thu, 24 Apr 2003 09:29:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OGT7GN003409; Thu, 24 Apr 2003 09:29:07 -0700 (PDT) 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 h3OGT1hs003396 for ; Thu, 24 Apr 2003 09:29:01 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OGT6FC018323 for ; Thu, 24 Apr 2003 09:29:07 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA07319 for ; Thu, 24 Apr 2003 10:29:01 -0600 (MDT) 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, 24 Apr 2003 16:29: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; Thu, 24 Apr 2003 16:29: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, 24 Apr 2003 16:29:00 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 16:28:59 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h3OGSBvm053497; Thu, 24 Apr 2003 09:28:11 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h3OGS8e1053496; Thu, 24 Apr 2003 09:28:08 -0700 (PDT) Date: Thu, 24 Apr 2003 09:28:08 -0700 From: Shannon -jj Behrens To: Tony Hain Cc: "'Keith Moore'" , john-ietf@jck.com, dts@senie.com, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030424162808.GA52759@alicia.nttmcl.com> References: <20030423180731.4137efe7.moore@cs.utk.edu> <038e01c309ea$e7927c00$261e4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <038e01c309ea$e7927c00$261e4104@eagleswings> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Apr 23, 2003 at 03:51:40PM -0700, Tony Hain wrote: > I am accepting comments for: > http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-00.txt Dear Sir, Please forgive my rough tone (in fact, I have great respect for you as an engineer), but it would be much more interesting if you wrote a document that provided solutions for all of the problems that people have claimed site-locals cause. While I hear you saying that the wg should replace all of the features that site-locals provide before removing them from the architecture, I challenge you to instead take the impetus of fully specifying site-locals. I do believe, based on other comments on the list, that such a challenge has existed for five years and has yet to be answered. Having fully specified site-locals, I do believe the wg would be much more willing to accept them into the architecture. Although I clearly am not capable of providing the full list of questions that you must answer, perhaps the following questions are helpful: o In light of the fact that not every host has a DNS name, how do you propose multi-party P2P applications should do referrals? It would be helpful if you established the normal mode of operation for such situations. o Should site-locals be put in DNS? Should multiple views of DNS be used? If so, how do you address the apparent apprehension in the DNS community toward multiple views (I don't know about this first-hand--I've only read about it from this list)? Should zone information be kept in DNS? o Do you foresee all nodes being multi-site nodes? If I'm at work and wish to use both my work network *and* my home network via a VPN connection, I expect I would want my laptop to be a multi-site node. If this is the case, do I need to use %interface_name at the end of all IP's I give to applications I use? How would DNS lookups work on a multi-site node if site-locals are stored in DNS? o If, as you say, we should provide site-locals because, "we need to meet the network manager at his comfort zone and provide a familiar tool," how do we convince the network manager not to use NAT since this is also a familiar tool in most people's comfort zone. I'm not willing to argue that site-locals necessarily lead to NAT, but many people are, so you should probably have some answer. o Do you envision support for Margaret's idea of multiple concentric rings of security (possibly using site-locals)? If a node in the outermost ring is not able to talk to a node in the innermost ring using a site-local address because of filtering, but is permitted to use a global address, how shall applications react when the site-local "hint" is actually misleading? Again, I'm sure there are many more such questions, and I think it would be helpful (and in fact requisite) that you answer such questions in an Internet Draft in order to achieve your goal of restoring site-locals to the architecture. I thank you for your time and *patience* if you have made it all the way through this message. 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 Thu Apr 24 09:58: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 h3OGwvhs003781; Thu, 24 Apr 2003 09:58:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OGwvih003780; Thu, 24 Apr 2003 09:58:57 -0700 (PDT) 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 h3OGwrhs003773 for ; Thu, 24 Apr 2003 09:58:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OGwxuc027922 for ; Thu, 24 Apr 2003 09:58:59 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id KAA01594 for ; Thu, 24 Apr 2003 10:58:53 -0600 (MDT) 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, 24 Apr 2003 16:58: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; Thu, 24 Apr 2003 16:54: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, 24 Apr 2003 16:58:52 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; Thu, 24 Apr 2003 16:58:50 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id h3OGwmns025899 for ; Thu, 24 Apr 2003 12:58:48 -0400 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id MAA1351431 for ; Thu, 24 Apr 2003 12:58:48 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Thu, 24 Apr 2003 12:58:48 -0400 From: Quality Quorum To: ipng@sunroof.eng.sun.com Subject: a trivial answer Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am putting together a draft summarizing address translation for IPv6. The draft of the draft is appended to this mail, it is tiny. Main features 1. Each node has only one address and this address is a site-local one. This local address is trnaslated to global and vice versa when packet crosses borders of its site. 2. Port information is preserved, so IPSEC and similar protocols will work without problems. It is possible to keep servers behind address translating firewalls. 3. It is possible to do tunneling without affecting MTU this way. 4. There are trivial node requirements changes. 5. It is so trivial, that there is practically no doubt that people will use no matter what IETF thinks and whether or not proposed node requirement changes will be adopted. Thanks, Aleksey ===================================================================== Network Working Group A. Romanov Internet-Draft QQI Expires: September 3, 2003 March 5, 2003 Trivial Address Aliasing Framework for IPv6 draft-aromanov-taaf-00 Status of this Memo This document is an Internet-Draft and is in full conformance with 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 will expire on September 3, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract There are a number of issues that may make address aliasing for IPv6 desirable. This memo proposes a trivial address aliasing framework, which is simple to implement, provides a low load on network elements, and (almost) stateless operations and could be used for many purposes, including low impact tunnels. 1. Overview There are number of compelling issues that may make the address aliasing a desirable option for IPv6 deployment. o A stable private address space, for example allowing a site to go from single-homing into multi-homing and then back without any changes on the inside. o A complete hiding/decoupling of the local address space and topology from the outside world both to increase security and to prevent any spillage of information about local topology changes into global space. o Light-weight tunnels for multi-homing, VPNs and other applications requiring tunnels with no MTU overhead and working ICMP from intermediate routers. o Effective use of 128-bit addresses without unnecesary growth of routing tables and without excessive prefix matching load on hosts and routers. 2. Local Address For the purpose of this memo it is a class of IPv6 addresses reserved for local use, for example a site-local address defined in [1]. While it is not required for this address to be globally unique, however, it is desirable in order to improve the error detection and to simplify debugging. At least, it seems reasonable for an organization to select a random fixed prefix common for all its local addresses. Local address does not have any geographical meaning, any datagram using local address as a source, destination or next hop option should be silently dropped by every IPv6 entity located outside the specific site. For example IPv6 routers can have a route redirecting all local addresses to a black hole, and more specific route(s) dealing with local addresses which are truly local. 3. Global Address and Local-to-Global Mapping For the purpose of this memo a global address is a global IPv6 addresses defined in [1]. We can conceptually split a global address into three parts, upper 64 bits (U), next 48 bits (M), and bottom 16 bits (L). When a firewall has to construct a global alias (G) for a local address (A) using a global /64 prefix (P), first it finds/allocates a unique 48-bit id (I) for the A and, then it constructs G as follows G-U = P, G-M = I, G-L = A-L. Local Address | 64 bits | 64 bits | +--------------------+-------------+-------------------------+ | Local Prefix | Interface-id | +--------------------+-------------+-------------------------+ Global Address | 64 bits | 48 bits | 16 bits | +--------------------+-------------+-------------------------+ | Global Prefix | Unique-Id | 16 bits of interface-id | +--------------------+-------------+-------------------------+ When a firewall has to find local address (A) matching for a global alias (G), it uses G-M to find an address (A) in its database, it verifies that G-L equals to A-L and then it replaces G with A. The flat 48-bit id space allows to map a huge local network and/or have several nested levels of address aliasing. The mapping could be either dynamic or permanent. Permanent mapping allows for completely stateless operation with redundant address translating firewalls. 4. Other Cases of Address Aliasing We can expect that aliasing will be used for other types of addresses. For example the same method could be used to map a global address to MHAP [2] address and vice versa. 5. Upper Layer Checksums Upper layer checksum calculation established by [3] should be limited to 2 LSB of both source and destination addresses. It seems that this method of checksum calculation would still provide for data integrity with minimum required changes in the endpoint protocol stack. If this is unacceptable, then the firewalls will be loaded with payload parsing and checksum calculations. 6. Node Requirements Node has to be prepared to deal with address translation issues. Particularly, lower layers of the stack have to patch the payload if it is required by upper layers. It is expected that applications will rely on peer transport address instead of addresses supplied in the protocol streams (e.g. FTP PORT command), so this patching will be a very limited. If local addresses are relatively unique then it would be easy to catch all cases where behind-the-firewall-peer supplied local address in a HTTP protocol body. 7. Ingress Operations Address translating firewall should use M-part of a destination address to find matching local address, it should replace the destination address with the found local address and then forward it through the local network, see Section 3. 8. Egress Operations If the packet is an ICMP error message originated on non-globally-visible router, a firewall has to use its own address as a source. Otherwise, the firewall should find a 48-bit unique identifier matching a source address, it has to replace the source address with a global address constructed as follows: a 64-bit global prefix, a 48-bit unique identifier, 16 bits of original interface-id, see Section 3. The firewall has to patch payload of all ICMP messages containing a copy of an invoking packet, by replacing the destination address in this copy with its global alias and by changing ICMP checksum accordingly. 9. Tunnel Operations It is possible to use the same method to alias both source and destination address, thus providing tunnels with no MTU impact and transparent ICMP support. The tunnel operations are very similar to the ones described above. The only difference is that an ingress firewall has to process ICMP error messages originated by the routers in the tunnel: it has to replace a source address with its own local address and then patch the payload replacing both the destination address and the source address in the copy of an invoking packet . 10. Example We will use following format to represent address/port of the packet: d-addr/d-port:s-addr/s-port. We will designate a local address of host X as LX, global address of the same host will be GX, a port on this host will designated as PX Simple transaction: Host A sends UDP/TCP frame to host B and receives reply. It is a responsibility of a firewall to patch the payload of ICMP reply messages; if this transaction contains FTP 'PORT' command the stack on the host B has to use GA instead of address provided in the protocol body. [A] --GB/PB:LA/PA-> [fw] --GB/PB:GA/PA-> [fw] --LB/PB:GA/PA-> [B] [A] <-LA/PA:GB/PB-- [fw] <-GA/PA:GB/PB-- [fw] <-GA/PA:LB/PB-- [B] References [1] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [2] Py, M., "Multi Homing Translation Protocol (MHTP)", draft-py-multi6-mhtp-01 (work in progress), November 2001. [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Author's Address Aleksey Romanov Quality Quorum, Inc. EMail: qqi@world.std.com Appendix A. Acknowledgments The author would like to thank Flavio Fernandes and Frank Katenholz for very constructive reviews. Also, the author is deeply thankful to M.Rose for XML specifications and tools used to write this memo. Intellectual Property Statement 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 of the 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 implementors 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. Full Copyright Statement Copyright (C) The Internet Society (2003). 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. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 24 10:07:14 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 h3OH7Dhs003912; Thu, 24 Apr 2003 10:07:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OH7DQW003911; Thu, 24 Apr 2003 10:07:13 -0700 (PDT) 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 h3OH79hs003901 for ; Thu, 24 Apr 2003 10:07:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OH7Euc000723 for ; Thu, 24 Apr 2003 10:07:15 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA09268 for ; Thu, 24 Apr 2003 10:07:09 -0700 (PDT) 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, 24 Apr 2003 17:05:46 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, 24 Apr 2003 17:05:46 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, 24 Apr 2003 17:05:46 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 17:05:46 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h3OH5Yvm054126; Thu, 24 Apr 2003 10:05:34 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h3OH5WCp054125; Thu, 24 Apr 2003 10:05:32 -0700 (PDT) Date: Thu, 24 Apr 2003 10:05:32 -0700 From: Shannon -jj Behrens To: Mark.Andrews@isc.org Cc: S Ramesh , Ravi Kumar M , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Address validation Message-Id: <20030424170532.GB52759@alicia.nttmcl.com> References: <20030423153044.GB33177@alicia.nttmcl.com> <200304232241.h3NMfrdV067607@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304232241.h3NMfrdV067607@drugs.dv.isc.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 24, 2003 at 08:41:53AM +1000, Mark.Andrews@isc.org wrote: > Is the following a legal IPv6 literal? The RFC's are unclear > about whether leading zeros are allowed or not if they would > make a segment more than 4 character wide. > > 1234:1234:1234:1234:01234:: > > Note I would never expect inet_ntop() to produce the above. > > We were discussing this when reviewing our inet_pton() > implementation. I don't have any information about this that you don't already have. However, I know that there's a general rule that you should be strict in what you produce, and forgiving in what you accept. Nonetheless, my gut reaction is to reject it since it's convenient to demand that an IPv6 address never be longer than 4*8 + 7 characters long. 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 Thu Apr 24 10:19:46 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 h3OHJkhs004358; Thu, 24 Apr 2003 10:19:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OHJjo8004357; Thu, 24 Apr 2003 10:19:45 -0700 (PDT) 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 h3OHJghs004350 for ; Thu, 24 Apr 2003 10:19:42 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OHJmuc005255 for ; Thu, 24 Apr 2003 10:19:48 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA12667 for ; Thu, 24 Apr 2003 11:19:42 -0600 (MDT) 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, 24 Apr 2003 17:19: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, 24 Apr 2003 17:19:40 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, 24 Apr 2003 17:19:40 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 17:19:40 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h3OHJOvm054330; Thu, 24 Apr 2003 10:19:24 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h3OHJOb0054329; Thu, 24 Apr 2003 10:19:24 -0700 (PDT) Date: Thu, 24 Apr 2003 10:19:24 -0700 From: Shannon -jj Behrens To: itojun@iijlab.net Cc: S Ramesh , Ravi Kumar M , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Address validation Message-Id: <20030424171924.GC52759@alicia.nttmcl.com> References: <20030423153044.GB33177@alicia.nttmcl.com> <20030424023956.13C5B7F@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030424023956.13C5B7F@coconut.itojun.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, Thank you for your comment. In fact, most of my knowledge of the C API's comes from you. Nonetheless, the code below is correct. The if statement is there *only* to check for the -1 case. The code below it goes on to deal with the 1 or 0 case. if (is_ipv6addr < 0) /* -1 case */ { fprintf (stderr, "%s: inet_pton: %s\n", argv0, strerror (errno)); return 1; } if (verbose) { if (is_ipv6addr) /* 1 case */ printf ("%s is a valid IPv6 address.\n", argv[optind]); else /* 0 case */ printf ("%s is not a valid IPv6 address.\n", argv[optind]); } I imagine you thought that I was writing the if statement in order to catch both the -1 and 0 case, but this is not so. If I have misunderstood your statements, I welcome your further correction. Best Regards, -jj On Thu, Apr 24, 2003 at 11:39:56AM +0900, itojun@iijlab.net wrote: > > is_ipv6addr = inet_pton (AF_INET6, argv[optind], &addr); > > if (is_ipv6addr < 0) > > { > > fprintf (stderr, "%s: inet_pton: %s\n", argv0, strerror (errno)); > > return 1; > > } > > the clause is buggy. inet_pton return value is defined as follows: > 1: valid > 0: wasn't parsable as specified address famiily > -1: some other error (see errno) > > you need to check if is_ipv6addr is 1 or not. > > itojun > > > --- > The inet_pton() function converts a presentation format address (that is, > printable form as held in a character string) to network format (usually > a struct in_addr or some other internal binary representation, in network > byte order). It returns 1 if the address was valid for the specified ad- > dress family, or 0 if the address wasn't parsable in the specified ad- > dress family, or -1 if some system error occurred (in which case errno > will have been set). This function is presently valid for AF_INET and > AF_INET6. -- 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 Thu Apr 24 11:10: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 h3OIAjhs005130; Thu, 24 Apr 2003 11:10:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OIAjuU005129; Thu, 24 Apr 2003 11:10:45 -0700 (PDT) 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 h3OIAfhs005122 for ; Thu, 24 Apr 2003 11:10:41 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OIAlFC023622 for ; Thu, 24 Apr 2003 11:10:47 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3OIAfrZ018933 for ; Thu, 24 Apr 2003 11:10:41 -0700 (PDT) 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, 24 Apr 2003 18:10: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, 24 Apr 2003 18:10:41 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, 24 Apr 2003 18:10:40 Z Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 18:10:40 Z Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3OIAUv11384; Thu, 24 Apr 2003 14:10:30 -0400 (EDT) Date: Thu, 24 Apr 2003 14:07:34 -0400 From: Keith Moore To: erosen@cisco.com Cc: moore@cs.utk.edu, stephen@sprunk.org, alh-ietf@tndh.net, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Architectural Considerations section in specs Message-Id: <20030424140734.55c76b77.moore@cs.utk.edu> In-Reply-To: <200304241500.h3OF0IlY028110@rtp-core-1.cisco.com> References: <20030423221235.5e8fe4b7.moore@cs.utk.edu> <200304241500.h3OF0IlY028110@rtp-core-1.cisco.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > However, because of communications policy restrictions, > neither the application layer nor the network layer can know > whether B is actually allowed to talk to C. So it seems that > these applications can only work when deployed within a policy > domain. one question here is whether there is some burden on applications to try to find a path between hosts B and C, say by address and/or interface selection, or whether the burden is entirely on the network. one of the problems with our current notion of 'policy domains' is that they are so inflexible as a security mechanism that people demand, out of necessity, that some applications be able to work across them. so no, it's not reasonable to assume that apps that do referrals are only expected to work within a single policy domain. > The fact that A gives B an address of C rather than > a name of C doesn't seem relevant at all; after all, names > just resolve to addresses; I think the name vs. address issue is > a red herring in this context. that's because you haven't had to deal with DNS unreliability, imprecision, inconsistency, and performance issues. > 2. A system with a site-local address is likely to have other > addresses as > well, and it is a bad thing for a system to have more than one > address, because the apps have no way of knowing which address is > the right one to distribute. > > I think the reply to this is that this horse escaped from the barn > about 20 years ago not in a general sense. even today, the vast majority of IPv4 hosts have a distinguished IP address that is usable from everywhere that's supposed to be able to talk to the host. > , and anyway, choice of address is a > management function. That is, the app needs to be told through > some sort of config which addresses to use when. which is a management nightmare. > It's been claimed that if non-ambiguous addresses are used, at least > the app can tell when communication is being prevented due to policy > restrictions, as it will receive ICMP messages with appropriate > diagnostic information. Unfortunately, this presumes more from the > network layer than the network layer actually provides. ICMP > messages may be generated due to transient problems, they may fail > to be generated at all (for "security reasons", or due to limitations > on the rate of ICMP generation), they may be dropped in the network, > etc. When communication fails, there is no reliable way for the > endsystems to determine why it has failed. no, but when the connection times out right after the host has received 3 or 4 "prohibited" ICMP messages in response to traffic sent on that connection, it's a pretty good clue. 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 Apr 24 12:55: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 h3OJtahs006989; Thu, 24 Apr 2003 12:55:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OJtaNI006988; Thu, 24 Apr 2003 12:55:36 -0700 (PDT) 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 h3OJtWhs006981 for ; Thu, 24 Apr 2003 12:55:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OJtcuc024842 for ; Thu, 24 Apr 2003 12:55:38 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3OJtWrZ010143 for ; Thu, 24 Apr 2003 12:55:32 -0700 (PDT) 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, 24 Apr 2003 19:55:31 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, 24 Apr 2003 19:55: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, 24 Apr 2003 19:55: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, 24 Apr 2003 19:55:30 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 24 Apr 2003 12:55:29 -0700 Reply-To: From: "Tony Hain" To: "'Shannon -jj Behrens'" Cc: "'Keith Moore'" , , , , Subject: RE: A follow up question Date: Thu, 24 Apr 2003 12:55:29 -0700 Message-Id: <042901c30a9b$757ed1c0$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030424162808.GA52759@alicia.nttmcl.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3OJtXhs006982 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Shannon -jj Behrens wrote: > Please forgive my rough tone (in fact, I have great respect > for you as an engineer), I try to avoid taking any IETF discussions personally, one way or the other. > but it would be much more > interesting if you wrote a document that provided solutions > for all of the problems that people have claimed site-locals > cause. I understand that is what some people want, but I think we need to first agree on the problems that need solving. We have many opinions on why SL creates problems, but a blatant lack of recognition of the problems that need to be solved. > While I hear you saying that the wg should replace > all of the features that site-locals provide before removing > them from the architecture, I challenge you to instead take > the impetus of fully specifying site-locals. I believe the first step to doing that is to agree on the problems that need solving, then see if there are alternative approaches. > I do believe, > based on other comments on the list, that such a challenge > has existed for five years and has yet to be answered. > Having fully specified site-locals, I do believe the wg would > be much more willing to accept them into the architecture. I thought we were going there with the scoped arch document, but lacking agreement on the problems to be solved, it became easier to spread FUD and give up on addressing the issues than to sit down and work them through. > Although I clearly am not capable of providing the full list > of questions that you must answer, perhaps the following > questions are helpful: > > o In light of the fact that not every host has a DNS name, > how do you propose multi-party P2P applications should do > referrals? It would be helpful if you established the normal > mode of operation for such situations. As I said in the note to JCK, I have been imprecise about 'name' so whatever the app uses to get a handle from the local stack is what it needs to pass around. Doing otherwise ignores the reality that the network does not look the same from all points. > > o Should site-locals be put in DNS? Should multiple views of > DNS be used? If > so, how do you address the apparent apprehension in the DNS > community toward multiple views (I don't know about this > first-hand--I've only read about it > from this list)? Should zone information be kept in DNS? Implementation details of a multi-faced DNS are best addressed by those that already ship them. Any service that provides topology specific information has to do that with an understanding of the topology being described by that information. > > o Do you foresee all nodes being multi-site nodes? Certainly not all, my light switch should not be in any site except my house. At the same time I may want it to be in multiple scopes, so I can get to it and turn on the driveway light from the car as I approach. > If I'm at > work and wish to > use both my work network *and* my home network via a VPN > connection, I expect I would want my laptop to be a > multi-site node. If this is the case, do I > need to use %interface_name at the end of all IP's I give to > applications I > use? How would DNS lookups work on a multi-site node if > site-locals are stored in DNS? The name resolver would have to track which interface / site it got answers from because any limited scope resolution is only applicable in that interface / site context. > > o If, as you say, we should provide site-locals because, "we > need to meet the network manager at his comfort zone and > provide a familiar tool," how do we > convince the network manager not to use NAT since this is > also a familiar tool in most people's comfort zone. I'm not > willing to argue that site-locals > necessarily lead to NAT, but many people are, so you should > probably have some answer. Leading people away from something comfortable requires providing something that meets the same basic need and is easier/cheaper/more comfortable. Many use NAT because they can't get STABLE addresses otherwise, and NAT is simply the cost of getting that. Providing STABLE local use prefixes simultaneously with global prefixes that may change over time is a cheaper way to meet the need for STABLE addresses. * I emphasize STABLE because that is a invariant requirement by many managers of large networks. > > o Do you envision support for Margaret's idea of multiple > concentric rings of security (possibly using site-locals)? > If a node in the outermost ring is not able to talk to a node > in the innermost ring using a site-local address because of > filtering, but is permitted to use a global address, how > shall applications react when the site-local "hint" is > actually misleading? Personally I consider those security zones as different sites. This gets into the poor definition of 'site', but we were intentionally vague there. There is no difference between an FEC0 or 2001-w/Bellovin-Zill flag prefix in how one would solve this problem. The fact that SL does not provide multiple concentric security zones is not a failure of SL, because that was not a design requirement (again we need to agree on the problems to be solved). > > Again, I'm sure there are many more such questions, and I > think it would be > helpful (and in fact requisite) that you answer such > questions in an Internet Draft in order to achieve your goal > of restoring site-locals to the > architecture. I thank you for your time and *patience* if > you have made it all the way through this message. I agree that we need answers to all these issues, and that was the intent of the scoped arch doc. Once people realize that they continue to exist for any local use prefix, we will stop the nonsense about SL is the evil that causes the problems and get back to developing the needed documents. 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 Apr 24 12:56: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 h3OJu9hs007006; Thu, 24 Apr 2003 12:56:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OJu8BH007005; Thu, 24 Apr 2003 12:56:08 -0700 (PDT) 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 h3OJu5hs006998 for ; Thu, 24 Apr 2003 12:56:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OJuBuc025047 for ; Thu, 24 Apr 2003 12:56:11 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA24979 for ; Thu, 24 Apr 2003 13:56:05 -0600 (MDT) 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, 24 Apr 2003 19:55: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, 24 Apr 2003 19:55:35 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, 24 Apr 2003 19:55:26 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 19:55:25 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 24 Apr 2003 12:55:24 -0700 Reply-To: From: "Tony Hain" To: , "'Keith Moore'" Cc: "'Stephen Sprunk'" , , Subject: RE: Architectural Considerations section in specs Date: Thu, 24 Apr 2003 12:55:25 -0700 Message-Id: <042801c30a9b$72a91c80$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200304241500.h3OF0IlY028110@rtp-core-1.cisco.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3OJu5hs006999 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eric Rosen wrote: > ... The fact that A gives B an address of C > rather than a name of C doesn't seem relevant at all; > after all, names just resolve to addresses; I think the > name vs. address issue is a red herring in this context. If A gave the entire list of choices to B, you would be right. The problem is that A will generally give B the one it chose, since it believes that one works. > > The existence of policy domains seems to restrict the > applicability of these multi-party referring applications, > especially as the app itself has no way of knowing whether > it is crossing policy domain boundaries. This is right in the general case. We have toyed with the idea of preventing mixed scope connections which would allow the app to clearly know. > > So what does this have to do with site-local addresses? > I think two > arguments have been made. > > 1. Because site-local addresses are ambiguous, if A passes > a site-local > address to B, B may not be able to use it to talk to C. > > I think the reply that has been made to this is that > the site-local > addresses have to be unambiguous within a particular > policy domain, and > it is a management function to ensure that this is the > case. Since the > apps in questions are applicable only within a policy > domain, the fact > that the addresses are ambiguous outside that domain > doesn't makes the > apps any less useful than they already are. This is right on. > > 2. A system with a site-local address is likely to have > other addresses as > well, and it is a bad thing for a system to have more > than one address, > because the apps have no way of knowing which address is > the right one to > distribute. > > I think the reply to this is that this horse escaped from > the barn about > 20 years ago, and anyway, choice of address is a > management function. > That is, the app needs to be told through some sort > of config which > addresses to use when. The intent of the sending rules is to provide the default version of that config. There are arguments that those don't work for the mobile node case, but I would argue that the mobile node has to know when it is away from home to inform its HA, so we could add a rule that MNs don't use local scope addresses when away from home. > > It's been claimed that if non-ambiguous addresses are used, > at least the app can tell when communication is being > prevented due to policy restrictions, as it will receive > ICMP messages with appropriate diagnostic information. > Unfortunately, this presumes more from the network layer > than the network layer actually provides. ICMP messages > may be generated due to transient problems, they may fail > to be generated at all (for "security reasons", or due to > limitations on the rate of ICMP generation), they may be > dropped in the network, etc. When communication fails, > there is no reliable way for the endsystems to determine why > it has failed. In addition, it doesn't solve the issue that A will pass B the address that it is using, rather than the possible set. B needs to derive its own view of how to reach C even when globally unique addresses are used. > > So I don't really think the case against site-locals has > been made here (which is not to say that there isn't a > case against them based on other considerations). > > I think the underlying problem is that our comms > architecture doesn't take the policy restrictions into > account at all, and folks tend to assume that this needs to > be accounted for at some other layer than the one they are > most interested in. This generates frustration, and creates > a high heat to > light ratio. Usually everyone blames it on NAT, so it's > nice to see the > same issue come up in an IPv6 non-NAT context. > I am not trying to place blame, but I would word it differently. While the architecture has all along allowed for differentiating policy restrictions, the app community chose to simplify their effort by ignoring that there were policy differences in the lower layers. This worked as long as the world was dominated by client/server oriented 2 party apps. In a world of multi-party apps, the policy differences of the lower layers are exposed and we need to rethink how apps deal with that reality. 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 Apr 24 12:56: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 h3OJukhs007023; Thu, 24 Apr 2003 12:56:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OJuksU007022; Thu, 24 Apr 2003 12:56:46 -0700 (PDT) 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 h3OJughs007015 for ; Thu, 24 Apr 2003 12:56:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OJumFC000857 for ; Thu, 24 Apr 2003 12:56:48 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA23491 for ; Thu, 24 Apr 2003 13:56:36 -0600 (MDT) 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, 24 Apr 2003 19:55:34 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, 24 Apr 2003 19:55: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; Thu, 24 Apr 2003 19:55:19 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 19:55:19 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 24 Apr 2003 12:55:15 -0700 Reply-To: From: "Tony Hain" To: "'John C Klensin'" Cc: "'Daniel Senie'" , , Subject: RE: A follow up question Date: Thu, 24 Apr 2003 12:55:16 -0700 Message-Id: <042701c30a9b$6d3dc840$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <299162132.1051138523@p3.JCK.COM> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3OJughs007016 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John C Klensin wrote: > I want to leave most of that discussion for some ARIN-related > list, as David Conrad suggested. I was certainly not trying to pick on ARIN, because there is wide perception that they are fairly liberal in their IPv4 policy. I agree that allocation policy discussions belong elsewhere. > But, for the record, I was > trying to dodge the question of whether address space > exhaustion, by itself, was "strong enough" or "sufficient" > reason to get IPv6 deployed and, especially, to avoid the > rathole-populating discussion about alternatives. Since I am on > record as believing that, by some reasonable measures, we have > already run out of address space and IPv6 is not yet widely > deployed, I would suggest that we have a solid example that it > has not [yet?] proven to be sufficient. Yes it is not widely deployed yet, but that does not mean lack of IPv4 space is not a sufficient reason. In several active deployment cases I am aware of, going as fast as they can, it takes 3-5 years to get to the point of delivering a stable commercial grade service. It should not be surprising that we don't see wide scale deployment yet, since the realization that we are effectively out of IPv4 space has only hit home recently. > ... > I strongly suspect that we are using words in ways that results > in miscommunication, because I think there is a third > alternative. That alternative may fall into the category you > describe as "passing around name objects", or maybe it doesn't. > >From my perspective --which is definitely the applications end > of the stack looking down-- the problem is all about data > abstraction. I'm going to try to switch terminology here in the > hope that it will help clarify things. Suppose the application > gets a well-constructed handle, and passes that handle "around" > --either to other applications or to different interfaces to the > stack/network. I don't see the application as dealing in > topology information by doing that, even if the handle > ultimately identifies information that is deeply > topology-sensitive and/or if the process that produces the > handle uses topological information, or probes the network to > develop such information. The important thing from that > perspective is that the application is dealing with the handle > as an opaque object, without trying to open it up and evaluate > its meaning or semantics (with regard to the network or > otherwise). In general I agree, but the difference of perspective is that ignoring the fact that the well constructed handle is actually derived from topology information does not make the issue go away. The only way you can get the handle you are looking for is to have something below you sort out the topological reality. I agree the current name service is not up to the task, and I believe that we need to get that fixed. Unfortunately it looks like it will take some very crisp architectural guidance to get the IESG to refocus the DNS related WGs to even discuss the issues. The sad part is that many of the participants there already ship or run variants that help address this problem, but they have agreed not to work on standardizing it. > > >From that point of view, having an application go to the stack > and say "given these criteria, give me a handle on the interface > or address I should use" or "given this DNS name, and these > criteria, give me a handle on the address I should use" does not > involve the application being topology-aware, nor does it imply > the application doing something evil because it picks an address > (or virtual interface, or...) without understanding the > topology. The handle is opaque and and an abstraction -- as far > as the application is concerned, it doesn't have any semantics, > regardless of whether lower layers of the stack can derive > semantics from it or from whatever they (but not the > application) can figure out it is bound to. This points out that I have been imprecise by claiming that passing names are sufficient, all the criteria you would use for local communication with the stack are the 'name' in the context of my previous mail. As long as the handle stays contained within the machine you are fine. The problem arises when the app passes that handle to another node, believing that the topology specific information is already there. If the blob passed were the same as what the app used to acquire the local handle, the other nodes would acquire appropriate local handles. > > If the application is calling on, e.g., TCP, then it might pass > some criteria to TCP, or might not, and TCP might either pass > enhanced criteria to the handle-generating layer or generate the > handle itself. Again, the application doesn't care -- it just > needs to deal with an abstraction of the criteria in application > terms. I think that, from the application standpoint, it makes > little difference whether the criteria involve routing, speed, > reliability, or any of several potential QoS or security issues. I agree as long as the app keeps the handle for local use. It can't assume that handle will have an equivalent meaning somewhere else in the network. If it wants to pass a handle that it believes has sufficient topology information for the receiver to directly access the same point, it needs to understand the topology enough to know that the meaning will be consistent. Otherwise it needs to pass the original parameters. > > I'll also be the first to admit that we have handled the set of > issues this implies rather badly with IPv4 (and they certainly > are not new issues). We have gotten away with it because the > number of _hosts_ that need to understand, and choose between, > multiple addresses for themselves has been extremely small, at > least since routers were introduced into the network > architecture. Because it could mostly be seen as a router > problem, applications in IPv4 mostly punted (for better or > worse). Also, since CIDR went in, we basically haven't given a > damn when users who can't qualify for PI space can't multihome > (at least without resort to complex kludges). IPv6, with its > multiple-address-per-host architecture, turns the problem from > "mostly theoretical" to an acute one. It does so with or > without SL addresses being one of those on a host that has > public (global or otherwise) addresses as well. I agree that SL simply exposed the issue. The problems arise from the mismatched interpretation by the apps, that all 'handles' will be treated equally by the network, and the reality that the network has more than a single policy. As you noted earlier, this is not just about scoping of address reachability, it also applies to QoS and any other policy related variance in the topology. > > Finally, from the standpoint of that hypothetical application, > the syntax and construction of that opaque handle are > irrelevant. In particular, it makes zero difference if it is a > name-string that lower layers look up in a dictionary or a > symbol table, or [the name of] some sort of class object, or > whether it is, e.g., an IP address. The only properties the > application cares about is that it is a handle that it got from > somewhere that satisfies criteria it specified or that were > specified for it. I understand that is what the app wants to see. I am suggesting that in the absence of a central policy entity that can sort out all possible topology differences, multi-party apps will need to pass the original parameter set, and maintain local mappings to the stack handle at each participant node. Not pretty, but closer to a working solution than continuing to ignore the reality that the topology is inconsistent. > ... > See above. Applications have gotten away with ignoring that > reality because the occurrences have been infrequent -- with one > important class of exceptions, we have had few machines with > multiple addresses (and multiple interfaces) since routers > became common in the network. The exceptions have been larger > web hosts which support pre-1.1 versions of HTTP and hence use > one address per DNS name. But, for them, hosts opening > connections to them use the address that matches the DNS name > (hence no need to make choices or understand topological > information) and the servers either use "address matching the > one on which the connection was opened" or an arbitrary address > on the interface --since the interface is the same, and its > connectivity is the same, it really makes no difference. If the > reason for multiple addresses per host (or interface) in IPv6 is > to support different scopes (or connectivity, or multihoming > arrangements), then it does make a difference, and will make a > difference for a significant number of hosts. And _that_ > implies a new requirement. We could debate 'new' forever, since as you noted earlier this requirement existed before routers, but the point is that apps can't ignore it any longer. > Tony, there is a difference in perspective here. I'm going to > try to identify and explain it, with the understanding that it > has little to do with any of the discussion above, which I think > is far more important. From your point of view, as I understand > it, this feature has been in IPv6 for a long time, no one > questioned it, or the problem(s) it apparently solved, for > equally long, some implementations were designed to take > advantage of it, and now people are coming along and proposing > to remove it without a clearly-better solution to address those > solved problems. Yes. > From the viewpoint of many or most of the > applications-oriented folks on this list, and maybe some others, > the applications implications of the SL idea (and maybe the > "multiple addresses" idea more generally) are just now becoming > clear. What is becoming clear with them is that the costs in > complexity, in data abstraction failures, and in damage to the > applications view of the hourglass, are very severe and, indeed > that, from the standpoint of how applications are constructed, > SL would never have worked.. From that perspective, when you > argue that applications are already doing bad things, the > applications folks respond by saying "but IPv6 should make it > better, or at least not make it worse". It is inconsistent to claim that SL would never have worked while admitting that there are implementations that take advantage of it. But that aside, SL is not the issue, the issue is that apps have come to believe that the topology is flat so they can pass around handles constructed of topology specific information. The reality all along has been that some addresses were not reachable outside an administrative scope of relevance. Writing those cases off in a client/server world was mostly possible, but in the peer-to-peer world of IPv6 that is no longer possible. > > Those differences lead to discussions about religion and > ideology, which get us nowhere (although they generate a lot of > list traffic). It is clear to me (from my particular narrow > perspective) that our getting to this point at this time > indicates a failure on the part of several generations of IESG > members (probably including me). It also identifies a series of > issues in how we review things cross-area (or don't do that > successfully) and reinforces my perception that shifting the > responsibility for defining standards away from a > multiple-perspective IESG and onto WGs with much narrower > perspectives would be a really bad idea. I agree, and even restricting the cross-area review to the IESG is a bad idea because there aren't enough cycles in that small group. > > But, unfortunate though it may be, we have gotten here. We > differentiate between Proposed and Draft standards precisely to > make it easier to take something out that doesn't work, or > --more to the point in this case-- doesn't appear to do the job > it was designed to do at a pain level no worse than what was > anticipated. I don't think essentially procedural arguments > about how much proof is required to take something out get us > anywhere at this stage. Instead, we should be concentrating on > the real character of the problem we are trying to solve and > ways in which it can be solved without doing violence to > whatever architectural principles we can agree upon. I agree to a point. My button is pushed by those that claim a technology 'creates more problems than it solves', when they simultaneously admit they don't have a clue what problems need solving. To that end I started a draft on what problems need solving, so we can sort out the cases that the current technology does solve, as well as begin to identify alternatives. IF we get to a point were there are alternatives for all the cases people care about, we should drop the unused technology. 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 Apr 24 13:58: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 h3OKwphs008254; Thu, 24 Apr 2003 13:58:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OKwp1G008253; Thu, 24 Apr 2003 13:58:51 -0700 (PDT) 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 h3OKwmhs008246 for ; Thu, 24 Apr 2003 13:58:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OKwrFC020180 for ; Thu, 24 Apr 2003 13:58:53 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA11246 for ; Thu, 24 Apr 2003 13:58:48 -0700 (PDT) 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, 24 Apr 2003 20:58: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; Thu, 24 Apr 2003 20:58: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, 24 Apr 2003 20:58:47 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; Thu, 24 Apr 2003 20:58:47 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3OKw1ID022698; Thu, 24 Apr 2003 13:58:01 -0700 (PDT) Received: from cisco.com (dhcp-171-71-119-39.cisco.com [171.71.119.39]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA13837; Thu, 24 Apr 2003 13:58:00 -0700 (PDT) Message-Id: <3EA84FD8.5050908@cisco.com> Date: Thu, 24 Apr 2003 13:58:00 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'John C Klensin'" , "'Daniel Senie'" , ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question References: <042701c30a9b$6d3dc840$261e4104@eagleswings> In-Reply-To: <042701c30a9b$6d3dc840$261e4104@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: > But that aside, SL is not the issue, the issue is that apps have come to > believe that the topology is flat so they can pass around handles > constructed of topology specific information. The reality all along has > been that some addresses were not reachable outside an administrative > scope of relevance. Writing those cases off in a client/server world was > mostly possible, but in the peer-to-peer world of IPv6 that is no longer > possible. As there are many entities that provide firewalling functionality, it is unreasonable to assume that it would be possible for each of these to be the address authority for either end of a connection. Thus, an application must deal with multiple administrative domains today. In some circumstances, administrative firewalls exist specifically to block particular applications. And... network error messages may or may not be appropriate to a given circumstance. It all depends on your threat model. Along these same lines, there is no reason to assume that the end host will be trusted by the firewall sufficiently such that a POLICY exchange would be allowed. It is one thing to say, "Permission denied", and quite something else to say when one will deny permission. SLs and IPv6 provide neither advance nor regression in this regard. I take exception to this: > I agree to a point. My button is pushed by those that claim a technology > 'creates more problems than it solves', when they simultaneously admit > they don't have a clue what problems need solving. Most of us -- MOST OF US -- have a clue. That you refuse to recognize it and respect those opinions is unfortunate. > To that end I started > a draft on what problems need solving, so we can sort out the cases that > the current technology does solve, as well as begin to identify > alternatives. IF we get to a point were there are alternatives for all > the cases people care about, we should drop the unused technology. And many of us have been saying that we have something that works today, RIR policies not withstanding. It's IPv4. 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 Thu Apr 24 14:06:15 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 h3OL6Ehs008657; Thu, 24 Apr 2003 14:06:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OL6EBS008656; Thu, 24 Apr 2003 14:06:14 -0700 (PDT) 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 h3OL6Bhs008649 for ; Thu, 24 Apr 2003 14:06:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OL6GFC022475 for ; Thu, 24 Apr 2003 14:06:16 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA21466 for ; Thu, 24 Apr 2003 15:06:10 -0600 (MDT) 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, 24 Apr 2003 21:06: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; Thu, 24 Apr 2003 21:06:09 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, 24 Apr 2003 21:06:09 Z Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 21:06:07 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3OL4t08028597; Thu, 24 Apr 2003 14:04:55 -0700 (PDT) Received: from cisco.com (dhcp-171-71-119-39.cisco.com [171.71.119.39]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA00152; Thu, 24 Apr 2003 14:04:54 -0700 (PDT) Message-Id: <3EA85176.5010205@cisco.com> Date: Thu, 24 Apr 2003 14:04:54 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: erosen@cisco.com, "'Keith Moore'" , "'Stephen Sprunk'" , ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Architectural Considerations section in specs References: <042801c30a9b$72a91c80$261e4104@eagleswings> In-Reply-To: <042801c30a9b$72a91c80$261e4104@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: > I am not trying to place blame, but I would word it differently. Not to contradict you, but... > While the architecture has all along allowed for differentiating policy > restrictions, the app community chose to simplify their effort by > ignoring that there were policy differences in the lower layers. Nobody ignored anything. To start with, the application community has had to work around these sorts of problems. This is why there are SIP proxy gateways, STUN services, and MX gateways. All of these exist due to connectivity limitations (either intentional or architectural). All of these cases fall under the "Got Lemons? make lemonade" approach. So I believe you've mischaracterised the community. 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 Thu Apr 24 14:11: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 h3OLBLhs009034; Thu, 24 Apr 2003 14:11:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OLBKto009033; Thu, 24 Apr 2003 14:11:20 -0700 (PDT) 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 h3OLBFhs009015 for ; Thu, 24 Apr 2003 14:11:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OLBLFC024290 for ; Thu, 24 Apr 2003 14:11:21 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA25335 for ; Thu, 24 Apr 2003 15:11:15 -0600 (MDT) 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, 24 Apr 2003 21:11: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; Thu, 24 Apr 2003 21:11: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, 24 Apr 2003 21:11:02 Z Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 21:11:02 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 198nzU-0003NQ-00; Thu, 24 Apr 2003 14:10:48 -0700 Date: Thu, 24 Apr 2003 17:10:12 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, erosen@cisco.com, stephen@sprunk.org, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Architectural Considerations section in specs Message-Id: <20030424171012.4b0904cd.moore@cs.utk.edu> In-Reply-To: <042801c30a9b$72a91c80$261e4104@eagleswings> References: <200304241500.h3OF0IlY028110@rtp-core-1.cisco.com> <042801c30a9b$72a91c80$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > ... The fact that A gives B an address of C > > rather than a name of C doesn't seem relevant at all; > > after all, names just resolve to addresses; I think the > > name vs. address issue is a red herring in this context. > > If A gave the entire list of choices to B, you would be right. The > problem is that A will generally give B the one it chose, since it > believes that one works. there are multiple problems. one problem is when the network expects different hosts to choose different addresses in order to reach the same destination. another problem is that even if A passes a list of choices to B, neither A nor B typically has any idea about which choices will work for B, or for any third intermediary that B passes the list to. (no, it's not the case that A will "generally" give be the address it chose, because there's too much variation in behavior between distributed apps. often A has no need to choose from that set of addresses at all; it's just trying to provide some referral service.) another problem is that being able to pass a list of addresses is not the same thing as being able to fail over from one address to another, and yet people want to treat the existence of multiple addresses on a host as a substitute for multihoming. > > I think the underlying problem is that our comms architecture doesn't > > take the policy restrictions into account at all, and folks tend to > > assume that this needs to be accounted for at some other layer than the > > one they are most interested in. This generates frustration, and > > creates a high heat to light ratio. Usually everyone blames it on NAT, > > so it's nice to see the same issue come up in an IPv6 non-NAT context. > > > I am not trying to place blame, but I would word it differently. While > the architecture has all along allowed for differentiating policy > restrictions, the app community chose to simplify their effort by > ignoring that there were policy differences in the lower layers. another false statement. apps have been expected to deal with crude and inflexible policy implementation in lower layers for many years, so apps people are painfully aware that such differences exist. what some of us are saying is that the lack of flexibility in these mechanisms has increased complexity in both apps and the network without providing much in the way of useful policy control or security, and we need to reconsider some of the cruder mechanisms like private addressing. or in other words - don't create a mess at layer 2 or 3 and expect layer 7 to sort it out. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 24 14:25: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 h3OLPfhs009529; Thu, 24 Apr 2003 14:25:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OLPf0H009528; Thu, 24 Apr 2003 14:25:41 -0700 (PDT) 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 h3OLPbhs009521 for ; Thu, 24 Apr 2003 14:25:37 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OLPhFC028722 for ; Thu, 24 Apr 2003 14:25:43 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id OAA27658 for ; Thu, 24 Apr 2003 14:25:37 -0700 (PDT) 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, 24 Apr 2003 21:25:37 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, 24 Apr 2003 21:25: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; Thu, 24 Apr 2003 21:25:36 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 21:25:36 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h3OLOmvm058436; Thu, 24 Apr 2003 14:24:48 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h3OLOmDu058435; Thu, 24 Apr 2003 14:24:48 -0700 (PDT) Date: Thu, 24 Apr 2003 14:24:48 -0700 From: Shannon -jj Behrens To: Tony Hain Cc: "'Keith Moore'" , john-ietf@jck.com, dts@senie.com, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030424212448.GA56083@alicia.nttmcl.com> References: <20030424162808.GA52759@alicia.nttmcl.com> <042901c30a9b$757ed1c0$261e4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <042901c30a9b$757ed1c0$261e4104@eagleswings> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 24, 2003 at 12:55:29PM -0700, Tony Hain wrote: (I'm going to clip much of this email to concentrate on those areas that need further discussion.) > > o In light of the fact that not every host has a DNS name, > > how do you propose multi-party P2P applications should do > > referrals? It would be helpful if you established the normal > > mode of operation for such situations. > > As I said in the note to JCK, I have been imprecise about 'name' so > whatever the app uses to get a handle from the local stack is what it > needs to pass around. If A connects to B, and B wishes to pass the connection info to C, B only has the address with which A accessed B. If A and B are in the same site and used site-local communication, and C is not in that site, B does not have enough information to refer C to A. Hence, your suggestion does not solve this case. > Doing otherwise ignores the reality that the > network does not look the same from all points. I agree, and in fact, that's what I'm asking you how to work around. > > If I'm at > > work and wish to > > use both my work network *and* my home network via a VPN > > connection, I expect I would want my laptop to be a > > multi-site node. If this is the case, do I > > need to use %interface_name at the end of all IP's I give to > > applications I > > use? How would DNS lookups work on a multi-site node if > > site-locals are stored in DNS? > > The name resolver would have to track which interface / site it got > answers from because any limited scope resolution is only applicable in > that interface / site context. That's true, and that sufficiently solves one side of the problem. However, the other side of the problem is knowing which name resolver to go to in the first place. If I use my home resolver, I won't be able to get the address of (e.g.) my printer, but if I use my work resolver, I won't be able to get the address of my toaster. Do I need to always check both? It seems that we're encountering this situation because DNS implicitly assumes (at least in my limited understanding) that choice of a DNS proxy should not affect the results. > > o Do you envision support for Margaret's idea of multiple > > concentric rings of security (possibly using site-locals)? > > If a node in the outermost ring is not able to talk to a node > > in the innermost ring using a site-local address because of > > filtering, but is permitted to use a global address, how > > shall applications react when the site-local "hint" is > > actually misleading? > > Personally I consider those security zones as different sites. This gets > into the poor definition of 'site', but we were intentionally vague > there. There is no difference between an FEC0 or 2001-w/Bellovin-Zill > flag prefix in how one would solve this problem. The fact that SL does > not provide multiple concentric security zones is not a failure of SL, > because that was not a design requirement (again we need to agree on the > problems to be solved). Well, that's a fair answer. By the way, I do applaud your effort in making a site-locals requirements document. I think such a document will ultimately be useful if it presents requirements in such a way that people who wish to replace the functionality that site-locals provide know what needs replacing. Thanks, -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 Thu Apr 24 14:26:28 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 h3OLQShs009563; Thu, 24 Apr 2003 14:26:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OLQSFp009562; Thu, 24 Apr 2003 14:26:28 -0700 (PDT) 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 h3OLQMhs009555 for ; Thu, 24 Apr 2003 14:26:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OLQSFC028861 for ; Thu, 24 Apr 2003 14:26:28 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA28016 for ; Thu, 24 Apr 2003 14:26:23 -0700 (PDT) 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, 24 Apr 2003 21:26: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, 24 Apr 2003 21:22: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; Thu, 24 Apr 2003 21:26:16 Z Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 21:26:15 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 198oEI-00077J-00; Thu, 24 Apr 2003 14:26:07 -0700 Date: Thu, 24 Apr 2003 17:25:29 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, john-ietf@jck.com, dts@senie.com, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030424172529.710c9a73.moore@cs.utk.edu> In-Reply-To: <042701c30a9b$6d3dc840$261e4104@eagleswings> References: <299162132.1051138523@p3.JCK.COM> <042701c30a9b$6d3dc840$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The only way you > can get the handle you are looking for is to have something below you > sort out the topological reality. I agree the current name service is > not up to the task, and I believe that we need to get that fixed. > Unfortunately it looks like it will take some very crisp architectural > guidance to get the IESG to refocus the DNS related WGs to even discuss > the issues. if the architecutral guidance were crisp it certainly wouldn't be asking the DNS related WGs to discuss those issues. DNS cannot solve this problem. > As long as the handle stays contained within the machine you are fine. > The problem arises when the app passes that handle to another node, > believing that the topology specific information is already there. If > the blob passed were the same as what the app used to acquire the local > handle, the other nodes would acquire appropriate local handles. this presupposes that the blob that is passed is precisely and reliably bound to the specific host or process that the app wants to refer to, and also that the lookup process that maps blobs to locators and/or identifiers is sufficiently fast and robust. often neither of these conditions holds. > The problems arise from the > mismatched interpretation by the apps, that all 'handles' will be > treated equally by the network, heaven forbid that apps would assume the same thing that the IP network was designed to assume - that there is a uniform address space across the entire network. but you want to change this fundamental architectural design point at layer 3 and then claim that the resulting problems are caused by inappropriate assumptions at layer 7. some would say this is layering violation, but the sharing of identifiers between layer 7 and layer 3 is another fundamental architectural design point. > I agree to a point. My button is pushed by those that claim a technology > 'creates more problems than it solves', when they simultaneously admit > they don't have a clue what problems need solving. I do have an idea about what problems need solving, but I don't claim to be able to make a list that satisfies everyone at the drop of a hat. But it's not clear that SL was actually intended to solve any of these problems. Rather, it seems to me that somebody thought SL was a good idea, and put it into the v6 architecture. And then various people started saying "hey, we can use SL for X", and nobody bothered to examine whether there were conflicts between those various peoples' assumptions (whether specifically about SL or not), or even whether SL was worth the cost, until recently. The problem with trying to make a list of "SL-related problems" is that there is also a set of problems that don't directly involve SL but also need to be solved, and SL precludes solving those problems. 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 Apr 24 14:57: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 h3OLvihs010635; Thu, 24 Apr 2003 14:57:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OLviF6010634; Thu, 24 Apr 2003 14:57:44 -0700 (PDT) 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 h3OLvehs010627 for ; Thu, 24 Apr 2003 14:57:40 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OLvjFC009251 for ; Thu, 24 Apr 2003 14:57:45 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id PAA09416 for ; Thu, 24 Apr 2003 15:57:40 -0600 (MDT) 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, 24 Apr 2003 21:57:39 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, 24 Apr 2003 21:57: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; Thu, 24 Apr 2003 21:57:39 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; Thu, 24 Apr 2003 21:57:39 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 198oif-0005xe-00; Thu, 24 Apr 2003 14:57:29 -0700 Date: Thu, 24 Apr 2003 17:56:53 -0400 From: Keith Moore To: Daniel Senie Cc: moore@cs.utk.edu, alh-ietf@tndh.net, john-ietf@jck.com, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030424175653.6987720a.moore@cs.utk.edu> In-Reply-To: <5.2.1.1.2.20030424160322.01ad7248@mail.amaranth.net> References: <299162132.1051138523@p3.JCK.COM> <5.2.1.1.2.20030424160322.01ad7248@mail.amaranth.net> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It would make more sense for an application to make a call to an API that > says "I want to hand off identifying information about host X to host Y. > Please package me up information to sent to X so that it will be able to > understand what I mean." been there, tried to do that, in the context of PVM. by far the easiest way to accomplish this is to have a uniform address space at the network level. any other approach is just too complex. background: PVM was originally designed to as a uniform API for distributed memory parallel machines, and later as a way to provide a distributed memory programming environment across a network of computers (some of which were potentially distributed memory hosts). in order to allow applications to send messages to other "processing elements" or hosts, PVM assigned a task id to each "processing element" in its virtual machine, and the mapping between task ids to tasks was uniform across the virtual machine. this task id consisted of a host id to which a host-specific offset was added. we tried making the mapping non-uniform because it would have relieved us of the need to keep a mapping table consistent across all hosts in the machine (especially after we allowed new hosts to be added to the machine), but the most robust, and in general the most efficient, way to implement the host-id mapping function was to use consistent numbering for host-ids across the entire machine...that, and expecting apps to invoke a translation function every time they passed a task id to another task was just too cumbersome. uniform addressing models are very compelling, even when you don't have complete interconnection. > A mention of proper layering was made earlier in this discussion thread. > It's time we took a serious look at how to improve on the mechanisms used. > Solving this layering issue could benefit both IPv4 and IPv6 > implementations. As noted, the problem is not new at all, though perhaps > now is the time to shed light on the matter. proper layering is an art. it involves understanding when to enforce layering discipline, and when to escape it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 24 15:00:10 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 h3OM09hs010674; Thu, 24 Apr 2003 15:00:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OM09Iv010673; Thu, 24 Apr 2003 15:00:09 -0700 (PDT) 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 h3OM05hs010666 for ; Thu, 24 Apr 2003 15:00:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OM0Auc008667 for ; Thu, 24 Apr 2003 15:00:11 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA27242 for ; Thu, 24 Apr 2003 16:00:05 -0600 (MDT) 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 <0HDV00KHKBS4IR@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 16:00:05 -0600 (MDT) Received: from sun.com ([129.146.18.22]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HDV0030BBRX0N@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 15:59:58 -0600 (MDT) Date: Thu, 24 Apr 2003 14:59:57 -0700 From: Alain Durand Subject: TCPng/ multiple addresses per node (was Re: A follow up question)_ To: Dave Crocker , ietf@ietf.org, ipng@sunroof.eng.sun.com, john-ietf@jck.com Message-id: <3EA85E5D.10507@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: <038f01c309eb$2cc8af60$261e4104@eagleswings> <131474110615.20030423173851@brandenburg.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Dave Crocker that the post from John Klensin is the first one in thousand of emails that put the discussion in a new (and very interesting) perspective. In the goold old IPv4 word, locators & identificators are the same thing. This is, as many people pointed out, the root cause for a lot of the hard problems we see today, such as multi-homing & mobility. We have made the problem even harder in IPv6 by adding more sementic to specific addresses: we now have addresses that are non permanent with privacy extensions (RFC3041), transition addresses (6to4, isatap, IPv4 compatible,...), scoped addresses (Link locals and hoppefuly defunct site locals), home address vs care-of address, crypto-generated addresses, and the list grows every day. Add to this that it is now more and more common for nodes to have multiple interfaces to different types of networks with different physical caracteristics (wired/wireless, high bandwidth, expensive access..)... ...and we made it even more complex now in the early days of coexistence of IPv4 and IPv6, when an IPv6 address may have been registered in the DNS but there is no actual IPv6 path to go there, or if there is one, it is sometime so boggus that it leads to very bad performances. (note: nothing to do with v6, just the sate of current deployment) There is a proposal to create an API to enable the application creating the socket to specify some of the properties that it desires/requires. This is a step in the right direction, but I'm not convinced this can go far enough. So I fully support this idea of lifting the ban on TCPng (or any transport layer for that matter) to de-couple the abstraction needed by applications to the one required by the network. This is in fact introducing some of the semantic of a session layer between the application and the network. Can this be done at the transport layer in the form of TCPng or does this require and actual additional session layer? I'm not sure at this point in time. - 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 Apr 24 15:01: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 h3OM1rhs010768; Thu, 24 Apr 2003 15:01:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OM1rMw010767; Thu, 24 Apr 2003 15:01:53 -0700 (PDT) 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 h3OM1khs010738 for ; Thu, 24 Apr 2003 15:01:46 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OM1qFC010678 for ; Thu, 24 Apr 2003 15:01:52 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA09718 for ; Thu, 24 Apr 2003 16:01:45 -0600 (MDT) 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, 24 Apr 2003 22:01: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, 24 Apr 2003 22:01: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, 24 Apr 2003 22:01:44 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 22:01:44 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 24 Apr 2003 15:01:05 -0700 Reply-To: From: "Tony Hain" To: "'Eliot Lear'" Cc: "'John C Klensin'" , "'Daniel Senie'" , , Subject: RE: A follow up question Date: Thu, 24 Apr 2003 15:01:05 -0700 Message-Id: <044201c30aad$00df25b0$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3EA84FD8.5050908@cisco.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3OM1khs010741 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eliot Lear wrote: > ... > Most of us -- MOST OF US -- have a clue. That you refuse to > recognize > it and respect those opinions is unfortunate. Where is the document that shows what requirements need to be solved? How would you correlate the stated need from the network manager for: Stable addresses, both during ISP changes, and for intermittently connected networks. with: Why is it that stable addresses are so necessary? Could it be because renumbering is painful? Could that be one source of our ills? & Fix the underlying problem. Making renumbering easy. If we don't do that, IPv6 is no better than Ipv4. ??? While I agree that we need to get at the underlying problem, handwaving that easy renumbering will solve it is not helpful. In many cases the requirement for stable addresses is being handed to the enterprise network manager by unreasonable Sr. VPs who want to lower their internal development cost & don't care about anything more than getting their product out the door. Claiming that easy renumbering will solve that internal business issue is just an IETF fantasy. 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 Apr 24 15:01:59 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 h3OM1xhs010776; Thu, 24 Apr 2003 15:01:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OM1wPR010771; Thu, 24 Apr 2003 15:01:58 -0700 (PDT) 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 h3OM1mhs010750 for ; Thu, 24 Apr 2003 15:01:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OM1sFC010694 for ; Thu, 24 Apr 2003 15:01:54 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA09755 for ; Thu, 24 Apr 2003 16:01:47 -0600 (MDT) 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, 24 Apr 2003 22:01: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; Thu, 24 Apr 2003 21:57: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; Thu, 24 Apr 2003 22:01:46 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 22:01:45 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 24 Apr 2003 15:01:02 -0700 Reply-To: From: "Tony Hain" To: "'Eliot Lear'" Cc: , "'Keith Moore'" , "'Stephen Sprunk'" , , Subject: RE: Architectural Considerations section in specs Date: Thu, 24 Apr 2003 15:01:02 -0700 Message-Id: <044101c30aad$0016f3b0$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3EA85176.5010205@cisco.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3OM1mhs010752 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eliot Lear wrote: > Nobody ignored anything. To start with, the application > community has > had to work around these sorts of problems. This is why > there are SIP > proxy gateways, STUN services, and MX gateways. All of these > exist due > to connectivity limitations (either intentional or > architectural). All > of these cases fall under the "Got Lemons? make lemonade" > approach. So > I believe you've mischaracterised the community. Those are all examples of building complexity into the infrastructure so that the app can maintain the fantasy that the world is flat. Personally I would rather see the Lemons turned into a nice desert than squeezed and watered down. 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 Apr 24 15:02: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 h3OM21hs010784; Thu, 24 Apr 2003 15:02:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OM20DV010783; Thu, 24 Apr 2003 15:02:00 -0700 (PDT) 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 h3OM1ohs010760 for ; Thu, 24 Apr 2003 15:01:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OM1uFC010711 for ; Thu, 24 Apr 2003 15:01:56 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id QAA19076 for ; Thu, 24 Apr 2003 16:01:49 -0600 (MDT) 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, 24 Apr 2003 22:01: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; Thu, 24 Apr 2003 21:57: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; Thu, 24 Apr 2003 22:01:46 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 22:01:45 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 24 Apr 2003 15:00:55 -0700 Reply-To: From: "Tony Hain" To: "'Shannon -jj Behrens'" Cc: "'Keith Moore'" , , , , Subject: RE: A follow up question Date: Thu, 24 Apr 2003 15:00:54 -0700 Message-Id: <044001c30aac$fababaa0$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030424212448.GA56083@alicia.nttmcl.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3OM1ohs010761 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Shannon -jj Behrens wrote: > If A connects to B, and B wishes to pass the connection info > to C, B only has the address with which A accessed B. If A > and B are in the same site and used site-local communication, > and C is not in that site, B does not have enough information > to refer C to A. Hence, your suggestion does not solve this case. I agree, but is it reasonable for B to tell C to talk to A, or is it more reasonable for B to tell A to connect to C by the 'name blob' it would have used to contact C? Please don't think I am picking on this instance, but the whole mode of attack by finding a failure case, without thinking through alternatives is a waste of everyone's time. > > > Doing otherwise ignores the reality that the > > network does not look the same from all points. > > I agree, and in fact, that's what I'm asking you how to work around. See above about changing the message sequence. > ... > That's true, and that sufficiently solves one side of the > problem. However, > the other side of the problem is knowing which name resolver > to go to in the first place. Unless there is some hint in the name string, the only approach I know of is to shotgun all the servers. > If I use my home resolver, I > won't be able to get the address of > (e.g.) my printer, but if I use my work resolver, I won't be > able to get the > address of my toaster. Do I need to always check both? It > seems that we're encountering this situation because DNS > implicitly assumes (at least in my limited understanding) > that choice of a DNS proxy should not affect the results. Which is my argument to the IAB: the infrastructure components that pass around topology information are completely out of step with the reality of the deployed network topology. We need to fix this because it will not get better on its own. > ... > > The fact that SL does not provide multiple concentric > security zones > > is not a failure of SL, because that was not a design requirement > > (again we need to agree on the problems to be solved). > > Well, that's a fair answer. > > By the way, I do applaud your effort in making a site-locals > requirements document. I think such a document will > ultimately be useful if it presents requirements in such a > way that people who wish to replace the functionality that > site-locals provide know what needs replacing. I am not trying to claim I have all the answers, so if anyone has content for it, please send them. 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 Apr 24 15:11: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 h3OMBDhs011775; Thu, 24 Apr 2003 15:11:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OMBCLx011774; Thu, 24 Apr 2003 15:11:12 -0700 (PDT) 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 h3OMB8hs011764 for ; Thu, 24 Apr 2003 15:11:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OMBDFC014266 for ; Thu, 24 Apr 2003 15:11:13 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA04252 for ; Thu, 24 Apr 2003 16:11:08 -0600 (MDT) 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, 24 Apr 2003 22:11:07 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, 24 Apr 2003 22:11: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; Thu, 24 Apr 2003 22:11:06 Z Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 22:11:05 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 198ovh-0006Su-00; Thu, 24 Apr 2003 15:10:57 -0700 Date: Thu, 24 Apr 2003 18:10:19 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, jj@nttmcl.com, john-ietf@jck.com, dts@senie.com, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030424181019.77736d10.moore@cs.utk.edu> In-Reply-To: <044001c30aac$fababaa0$261e4104@eagleswings> References: <20030424212448.GA56083@alicia.nttmcl.com> <044001c30aac$fababaa0$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > If A connects to B, and B wishes to pass the connection info > > to C, B only has the address with which A accessed B. If A > > and B are in the same site and used site-local communication, > > and C is not in that site, B does not have enough information > > to refer C to A. Hence, your suggestion does not solve this case. > > I agree, but is it reasonable for B to tell C to talk to A, or is it > more reasonable for B to tell A to connect to C by the 'name blob' it > would have used to contact C? let me rephrase the question. is it reasonable to expect that every 'blob' that can be used to derive a set of locators for a host is tightly bound to that host? or is it more reasonable for the network infrastructure to provide a token, independent of any application-specific blob, that can be tightly bound to that host? back in the mid 1990s I had a system for looking up URLs or URNs in a distributed database which would return blobs that could be used to find accurate replicas of those resources. those blobs included IP addresses in order to speed up access (requiring clients to do extra DNS lookups drastically slowed the system down). but those blobs weren't bound to hosts, they were bound to resources, and the mapping between resources and hosts was (by design) arbitrary. 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 Apr 24 15:12: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 h3OMCfhs011923; Thu, 24 Apr 2003 15:12:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OMCfGO011920; Thu, 24 Apr 2003 15:12:41 -0700 (PDT) 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 h3OMCYhs011895 for ; Thu, 24 Apr 2003 15:12:34 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OMCeuc013610 for ; Thu, 24 Apr 2003 15:12:40 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3OMCYrZ012334 for ; Thu, 24 Apr 2003 15:12:34 -0700 (PDT) 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, 24 Apr 2003 22:12: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; Thu, 24 Apr 2003 22:12: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; Thu, 24 Apr 2003 22:12:34 Z Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 22:12:33 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 198owr-0005BB-00; Thu, 24 Apr 2003 15:12:10 -0700 Date: Thu, 24 Apr 2003 18:11:27 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, lear@cisco.com, erosen@cisco.com, stephen@sprunk.org, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Architectural Considerations section in specs Message-Id: <20030424181127.53837c49.moore@cs.utk.edu> In-Reply-To: <044101c30aad$0016f3b0$261e4104@eagleswings> References: <3EA85176.5010205@cisco.com> <044101c30aad$0016f3b0$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Those are all examples of building complexity into the infrastructure so > that the app can maintain the fantasy that the world is flat. maybe instead it's your fantasy that it's reasonable to expect apps to cope with 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 Thu Apr 24 15:27: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 h3OMRPhs012974; Thu, 24 Apr 2003 15:27:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OMRPXa012973; Thu, 24 Apr 2003 15:27:25 -0700 (PDT) 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 h3OMRKhs012959 for ; Thu, 24 Apr 2003 15:27:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OMRQuc018744 for ; Thu, 24 Apr 2003 15:27:26 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3OMRLrZ018127 for ; Thu, 24 Apr 2003 15:27:21 -0700 (PDT) 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, 24 Apr 2003 22:27: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; Thu, 24 Apr 2003 22:27: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, 24 Apr 2003 22:27:12 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; Thu, 24 Apr 2003 22:27:11 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3OMQP08003280; Thu, 24 Apr 2003 15:26:25 -0700 (PDT) Received: from cisco.com (dhcp-171-71-119-39.cisco.com [171.71.119.39]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA08695; Thu, 24 Apr 2003 15:26:24 -0700 (PDT) Message-Id: <3EA86490.8060501@cisco.com> Date: Thu, 24 Apr 2003 15:26:24 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'John C Klensin'" , "'Daniel Senie'" , ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question References: <044201c30aad$00df25b0$261e4104@eagleswings> In-Reply-To: <044201c30aad$00df25b0$261e4104@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: >>Most of us -- MOST OF US -- have a clue. That you refuse to >>recognize >>it and respect those opinions is unfortunate. > > > Where is the document that shows what requirements need to be solved? How about starting with the IPng archives?! They're actually more persistant than, say, an internet draft, anyway. > How would you correlate the stated need from the network manager for: > Stable addresses, both during ISP changes, and for intermittently > connected networks. I wouldn't. I would decompose the network manager's stated need for stable addresses. That's what responsible people do when they see a customer requirement with a bad solution. But see below... > > with: > Why is it that stable addresses are so necessary? > Could it be because renumbering is painful? > Could that be one source of our ills? > > & > > Fix the underlying problem. Making renumbering easy. > If we don't do that, IPv6 is no better than Ipv4. > > ??? > > While I agree that we need to get at the underlying problem, handwaving > that easy renumbering will solve it is not helpful. In many cases the > requirement for stable addresses is being handed to the enterprise > network manager by unreasonable Sr. VPs who want to lower their internal > development cost & don't care about anything more than getting their > product out the door. Claiming that easy renumbering will solve that > internal business issue is just an IETF fantasy. This strikes me like the old adage, "You're safe if you buy IBM" (no offense to IBMers). You were until you weren't because the processes you used were outmoded, only you didn't think about it. Frankly, the fantasy here (and I love your charged use of words) is that IPv6 provides any -- ANY -- added benefit to the customer base.(*) That same Sr. VP ought to be asking why he is spending what will for the forseable future be a huge amount of money to cut over to IPv6 when IPv4 will suit the vast percentage of enterprises and users just as well as IPv6, given their intended use of SLs, as stated by some of those very same network managers. Eliot (*) Indeed I question whether even the mobility features will be properly taken advantage of, given the stated network manager need for stable addresses reconciled with their need for Internet connectivity (i.e., NAT). What do you then use for your MN address? If that mobile node wants to have a stable identifier, then it's using site-locals. Nonsense? But if they don't use site-locals then they have all the same problems those network managers are complaining about, and you don't have a stable address for applications. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 24 15:27: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 h3OMRThs012980; Thu, 24 Apr 2003 15:27:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OMRTMQ012979; Thu, 24 Apr 2003 15:27:29 -0700 (PDT) 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 h3OMRKhs012960 for ; Thu, 24 Apr 2003 15:27:20 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OMRQuc018743 for ; Thu, 24 Apr 2003 15:27:26 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA23291 for ; Thu, 24 Apr 2003 16:27:21 -0600 (MDT) 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, 24 Apr 2003 22:27: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; Thu, 24 Apr 2003 22:27:12 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, 24 Apr 2003 22:27:12 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 22:27:12 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 24 Apr 2003 15:27:09 -0700 Reply-To: From: "Tony Hain" To: "'Keith Moore'" Cc: , , , Subject: RE: A follow up question Date: Thu, 24 Apr 2003 15:27:09 -0700 Message-Id: <044801c30ab0$a5d97680$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030424172529.710c9a73.moore@cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3OMRLhs012962 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > if the architecutral guidance were crisp it certainly > wouldn't be asking the DNS related WGs to discuss those > issues. DNS cannot solve this problem. I agree all infrastructure & components that pass around topology information need work, but DNS is one of those, so it is a good place to start. > > > As long as the handle stays contained within the machine > you are fine. > > The problem arises when the app passes that handle to another node, > > believing that the topology specific information is already > there. If > > the blob passed were the same as what the app used to acquire the > > local handle, the other nodes would acquire appropriate > local handles. > > this presupposes that the blob that is passed is precisely > and reliably bound to the specific host or process that the > app wants to refer to, and also that the lookup process that > maps blobs to locators and/or identifiers is sufficiently > fast and robust. often neither of these conditions holds. If the first one doesn't hold, the origin node can't use it so the whole app is broken. Speed is an implementation issue, not a spec issue. In any case, it is much faster to pass a blob that can be mapped into useful topology information, than it is to pass around useless topology information. > > > The problems arise from the > > mismatched interpretation by the apps, that all 'handles' will be > > treated equally by the network, > > heaven forbid that apps would assume the same thing that the > IP network was designed to assume - that there is a uniform > address space across the entire network. but you want to > change this fundamental architectural design point at layer 3 > and then claim that the resulting problems are caused by > inappropriate assumptions at layer 7. some would say this is > layering violation, but the sharing of identifiers between > layer 7 and layer 3 is another fundamental architectural design point. I am not saying that. From day one, a host that had one interface where the address prefix was not passed widely in the routing system, and another where the prefix was passed globally would have exactly the same issues you are complaining about. This says nothing about firewalling, qos, ambiguous addresses, etc. This is simply about a host having multiple addresses, where different points in the network have different perceptions about the viability of those. The fact that over the years a simplification was done through the assumption that there was only a single view is a failure. > > > I agree to a point. My button is pushed by those that claim a > > technology 'creates more problems than it solves', when they > > simultaneously admit they don't have a clue what problems need > > solving. > > I do have an idea about what problems need solving, but I > don't claim to be able to make a list that satisfies everyone > at the drop of a hat. I don't have a list either, but we need to collectively create that list. > > But it's not clear that SL was actually intended to solve any > of these problems. Rather, it seems to me that somebody > thought SL was a good idea, and put it into the v6 > architecture. And then various people started saying "hey, > we can use SL for X", and nobody bothered to examine whether > there were conflicts between those various peoples' > assumptions (whether specifically about SL or not), or even > whether SL was worth the cost, until recently. Fine, we need to create the list, figure out alternatives and as you said in SF, push SL into the corner cases, if we still need it. Getting rid of SL first does not solve the problems. > The problem with trying to make a list of "SL-related > problems" is that there is also a set of problems that don't > directly involve SL but also need to be solved, and SL > precludes solving those problems. I agree there are several problems to be solved, but don't agree that the existence of SL precludes solving anything. If we try to claim that we don't need to work on solving problem X because SL solves it, then I would agree, but so far I haven't heard anyone claim that we shouldn't work on solving the problems. The only thing I have heard is that we have found no use for SL (despite the shipping code that uses it), without the list of basic requirements to judge which problems it does solve. 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 Apr 24 15:36: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 h3OMaohs013609; Thu, 24 Apr 2003 15:36:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OManiF013608; Thu, 24 Apr 2003 15:36:49 -0700 (PDT) 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 h3OMakhs013601 for ; Thu, 24 Apr 2003 15:36:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OMaqFC024053 for ; Thu, 24 Apr 2003 15:36:52 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id QAA19713 for ; Thu, 24 Apr 2003 16:36:46 -0600 (MDT) 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, 24 Apr 2003 22:36:46 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, 24 Apr 2003 22:36: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, 24 Apr 2003 22:36:45 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, 24 Apr 2003 22:36:45 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 XAA12047; Thu, 24 Apr 2003 23:36:35 +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 XAA27491; Thu, 24 Apr 2003 23:36:35 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3OMaZj08077; Thu, 24 Apr 2003 23:36:35 +0100 Date: Thu, 24 Apr 2003 23:36:35 +0100 From: Tim Chown To: Eliot Lear Cc: alh-ietf@tndh.net, "'John C Klensin'" , "'Daniel Senie'" , ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030424223635.GB6776@login.ecs.soton.ac.uk> Mail-Followup-To: Eliot Lear , alh-ietf@tndh.net, 'John C Klensin' , 'Daniel Senie' , ietf@ietf.org, ipng@sunroof.eng.sun.com References: <044201c30aad$00df25b0$261e4104@eagleswings> <3EA86490.8060501@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EA86490.8060501@cisco.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 24, 2003 at 03:26:24PM -0700, Eliot Lear wrote: > Tony Hain wrote: > > > >Where is the document that shows what requirements need to be solved? > > How about starting with the IPng archives?! They're actually more > persistant than, say, an internet draft, anyway. No need to bother, just read any sample of 100 ipng emails in one day and the same arguments come up again and again. And again. Is there a WG chair in the house? 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 Thu Apr 24 15:44: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 h3OMiuhs014156; Thu, 24 Apr 2003 15:44:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3OMitYo014155; Thu, 24 Apr 2003 15:44:55 -0700 (PDT) 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 h3OMiphs014145 for ; Thu, 24 Apr 2003 15:44:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3OMiuuc024554 for ; Thu, 24 Apr 2003 15:44:56 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA10726 for ; Thu, 24 Apr 2003 15:44:51 -0700 (PDT) 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, 24 Apr 2003 22:44: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; Thu, 24 Apr 2003 22:40: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; Thu, 24 Apr 2003 22:44:50 Z Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 24 Apr 2003 22:44:50 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 198pRS-0003vZ-00; Thu, 24 Apr 2003 15:43:46 -0700 Date: Thu, 24 Apr 2003 18:43:10 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, john-ietf@jck.com, dts@senie.com, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030424184310.7328b605.moore@cs.utk.edu> In-Reply-To: <044801c30ab0$a5d97680$261e4104@eagleswings> References: <20030424172529.710c9a73.moore@cs.utk.edu> <044801c30ab0$a5d97680$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > if the architecutral guidance were crisp it certainly > > wouldn't be asking the DNS related WGs to discuss those > > issues. DNS cannot solve this problem. > > I agree all infrastructure & components that pass around topology > information need work, but DNS is one of those, so it is a good place to > start. disagree. "starting" to work on this within DNS would be a distraction at best. > > > As long as the handle stays contained within the machine you are fine. > > > The problem arises when the app passes that handle to another node, > > > believing that the topology specific information is already there. If > > > the blob passed were the same as what the app used to acquire the local > > > handle, the other nodes would acquire appropriate local handles. > > > > this presupposes that the blob that is passed is precisely > > and reliably bound to the specific host or process that the > > app wants to refer to, and also that the lookup process that > > maps blobs to locators and/or identifiers is sufficiently > > fast and robust. often neither of these conditions holds. > > If the first one doesn't hold, the origin node can't use it so the whole > app is broken. false. it happens all the time. a function that converts a service name to an address doesn't have to produce identical results each time to be useful. and yet, if two separate processes need to connect to the exact same process, the service name alone may not be sufficient to allow them to do that. > Speed is an implementation issue, not a spec issue. false. depending on how you architect a service there can be fundamental and/or practical limits to speed. > In any case, it is much faster to pass a blob that can be mapped into > useful topology information, than it is to pass around useless topology > information. it's even faster if the network provides uniform addressing; then the addresses are no longer useless. why do you keep trying to force useless addresses on us when we can have useful ones at less cost? > > heaven forbid that apps would assume the same thing that the > > IP network was designed to assume - that there is a uniform > > address space across the entire network. but you want to > > change this fundamental architectural design point at layer 3 > > and then claim that the resulting problems are caused by > > inappropriate assumptions at layer 7. some would say this is > > layering violation, but the sharing of identifiers between > > layer 7 and layer 3 is another fundamental architectural design point. > > I am not saying that. From day one, a host that had one interface where > the address prefix was not passed widely in the routing system, and > another where the prefix was passed globally would have exactly the same > issues you are complaining about. it's hardly relevant, since that's not the way things happened. > This says nothing about firewalling, > qos, ambiguous addresses, etc. This is simply about a host having > multiple addresses, where different points in the network have different > perceptions about the viability of those. yup. and the realization that this is a lousy way to design a network > The fact that over the years a > simplification was done through the assumption that there was only a > single view is a failure. and in fact it's a very useful and compelling simplification. > > But it's not clear that SL was actually intended to solve any > > of these problems. Rather, it seems to me that somebody > > thought SL was a good idea, and put it into the v6 > > architecture. And then various people started saying "hey, > > we can use SL for X", and nobody bothered to examine whether > > there were conflicts between those various peoples' > > assumptions (whether specifically about SL or not), or even > > whether SL was worth the cost, until recently. > > Fine, we need to create the list, figure out alternatives and as you > said in SF, push SL into the corner cases, if we still need it. Getting > rid of SL first does not solve the problems. we've tried going on the assumption that SL will work, and we've not been able to resolve the conflicts and problems that result from that assumption. now we need to try the assumption that we can do without SL, and see where that leads. perhaps we will find that we can do without SL, or perhaps we will still need SL for a couple of corner cases. we won't know for sure until we try to work out the details, and we won't have completely decided for sure until we actually approve a specification that incorporates those details. but that's the direction that the WG has decided to pursue, and I think it's the right one. 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 Apr 24 18:39: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 h3P1dfhs019715; Thu, 24 Apr 2003 18:39:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3P1den9019714; Thu, 24 Apr 2003 18:39:40 -0700 (PDT) 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 h3P1dahs019700 for ; Thu, 24 Apr 2003 18:39:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3P1ddFC021128 for ; Thu, 24 Apr 2003 18:39:39 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id TAA05126 for ; Thu, 24 Apr 2003 19:39:33 -0600 (MDT) 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, 25 Apr 2003 01:39:32 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, 25 Apr 2003 01:39:32 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, 25 Apr 2003 01:39:31 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; Fri, 25 Apr 2003 01:39:31 Z Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 175191A; Fri, 25 Apr 2003 10:39:28 +0900 (JST) To: vijayak@india.hp.com Cc: "'Bill Manning'" , Mark.Andrews@isc.org, jj@nttmcl.com, rashanmu@npd.hcltech.com, ravikrm@sify.com, ipng@sunroof.eng.sun.com In-reply-to: vijayak's message of Thu, 24 Apr 2003 19:53:58 +0530. <001d01c30a6d$257da490$38e62a0f@nt23056> 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: IPv6 Address validation From: itojun@iijlab.net Date: Fri, 25 Apr 2003 10:39:28 +0900 Message-Id: <20030425013928.175191A@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >since the rfc says that "x" should hold only 16 bits, >the leading zeros has to be ignored i would interpret it as "since the rfc says that "x" should hold only 16 bits," inet_pton() and stuff should reject more than 4 digits between colons. 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 Thu Apr 24 20:53: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 h3P3rMhs023101; Thu, 24 Apr 2003 20:53:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3P3rMvY023100; Thu, 24 Apr 2003 20:53:22 -0700 (PDT) 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 h3P3rJhs023093 for ; Thu, 24 Apr 2003 20:53:19 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3P3rPFC015620 for ; Thu, 24 Apr 2003 20:53:25 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3P3rJrZ007965 for ; Thu, 24 Apr 2003 20:53:19 -0700 (PDT) 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, 25 Apr 2003 03:53: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; Fri, 25 Apr 2003 03:53: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; Fri, 25 Apr 2003 03:53:18 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; Fri, 25 Apr 2003 03:53:18 Z Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3P3rG725897 for ; Fri, 25 Apr 2003 06:53:16 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Apr 2003 06:53:15 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 25 Apr 2003 06:53:15 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 25 Apr 2003 06:53:15 +0300 content-class: urn:content-classes:message Subject: RE: TCPng/ multiple addresses per node (was Re: A follow up question)_ MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 25 Apr 2003 06:53:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCPng/ multiple addresses per node (was Re: A follow up question)_ Thread-Index: AcMKrc6e7EZbcTUySQKrh1d6eAMVwgAL7SMA From: To: , , , , X-OriginalArrivalTime: 25 Apr 2003 03:53:15.0162 (UTC) FILETIME=[3306FFA0:01C30ADE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3P3rJhs023094 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alain, I agree with your intro (which I clipped to save space), one comment that I have is: > There is a proposal to create an API to enable the > application creating the socket to specify some of the > properties that it desires/requires. This is a step in the right > direction, but I'm not convinced this can go far enough. > So I fully support this idea of lifting the ban on TCPng > (or any transport layer for that matter) to de-couple > the abstraction needed by applications to the one required > by the network. This is in fact introducing some of the semantic > of a session layer between the application and the network. > Can this be done at the transport layer in the form of TCPng > or does this require and actual additional session layer? > I'm not sure at this point in time. There already something like this, I'm sure you know - SCTP. I'm actually not trying to promote SCTP, but it might be interesting, as we have an RFC that does most of the avove, to look at it critically & see how it performs. SCTP, as a background, uses sets of addresses/ports to identify a node. In the usual case, one node will pass all of its addresses(& ports) to its peer & the peer returns its addresses (&ports) for SCTP traffic. The application has the the option to choose the primary address to be used. Right now, SCTP has limited users (Diameter, SIGTRAN and probably a couple of other protocols). It would be interesting to see that others can do with it. 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 Apr 24 20:56: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 h3P3uahs023279; Thu, 24 Apr 2003 20:56:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3P3uae2023276; Thu, 24 Apr 2003 20:56:36 -0700 (PDT) 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 h3P3uWhs023262 for ; Thu, 24 Apr 2003 20:56:32 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3P3ucFC016177 for ; Thu, 24 Apr 2003 20:56:38 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id VAA10132 for ; Thu, 24 Apr 2003 21:56:32 -0600 (MDT) 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; Fri, 25 Apr 2003 03:56:32 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, 25 Apr 2003 03:56:32 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, 25 Apr 2003 03:56:32 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; Fri, 25 Apr 2003 03:56:31 Z Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3P3uUD12295 for ; Fri, 25 Apr 2003 06:56:30 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Apr 2003 06:56:30 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 25 Apr 2003 06:56:30 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 25 Apr 2003 06:56:29 +0300 content-class: urn:content-classes:message Subject: RE: A follow up question MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 25 Apr 2003 06:56:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A follow up question Thread-Index: AcMKsshATWyTs2g+SrmbVqs3GuqZGgAK7OZg To: , Cc: , X-OriginalArrivalTime: 25 Apr 2003 03:56:29.0659 (UTC) FILETIME=[A6F4E2B0:01C30ADE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3P3uWhs023263 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tim, > > How about starting with the IPng archives?! They're actually more > > persistant than, say, an internet draft, anyway. > > No need to bother, just read any sample of 100 ipng emails in one day and > the same arguments come up again and again. And again. Just to second this - and its a process guestion (wait, there is another working group focused on that ...) - I thought that, at the end of the day, we are supposed to be making standards, not mailing list archives .... 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 Apr 24 22:45: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 h3P5jrhs026887; Thu, 24 Apr 2003 22:45:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3P5jrY3026886; Thu, 24 Apr 2003 22:45:53 -0700 (PDT) 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 h3P5johs026879 for ; Thu, 24 Apr 2003 22:45:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3P5jtFC006231 for ; Thu, 24 Apr 2003 22:45:56 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id WAA10489 for ; Thu, 24 Apr 2003 22:45:50 -0700 (PDT) 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, 25 Apr 2003 05:45: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; Fri, 25 Apr 2003 05:45: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; Fri, 25 Apr 2003 05:45:49 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 25 Apr 2003 05:45:49 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 24 Apr 2003 22:45:30 -0700 Reply-To: From: "Tony Hain" To: "'Bob Hinden'" , "'Margaret Wasserman'" Cc: Subject: Appeal clarification ... Date: Thu, 24 Apr 2003 22:45:30 -0700 Message-Id: <047f01c30aed$e1f8ed20$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3P5johs026880 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Everyone should check out the video at: ftp://limestone.uoregon.edu/pub/videolab/video/ietf56/ietf56 - 03202003 - INT ipv6.mpg ... Starting at 1:02:05. It is very instructional about how not to call a question. The claimed consensus was over (and I quote from the AD & chair 2:18:20) 'just to be clear, deprecate I assume means ...' ... '...we may have to handwave - wave our hands around that a little bit...'. In further discussion with the chairs, the appeal issue is still not clear. This note attempts to make it clearer, and adds documentation from the video of the SF session. Appeal: The chairs have asserted an incorrect technical choice which places the quality and/or integrity of the Working Group's products in significant jeopardy. The working group did not make a decision as some of the YES votes were for removal of local scopes from the architecture, some for removal of the need for apps to recognize that local scopes exist, others were for removing ambiguous addresses as SL is currently defined, and others were for removing the threat of NAT. Those are technically different architectural concepts requiring different questions. In particular, local scope addresses are the result of an operational choice, and not in the purview of the IETF to decide. The IETF can decide to set aside a well known prefix for that use or not, but removing the well-known prefix does not mean local scope addresses go away, or that applications are exempted from handling them correctly. It only means that there is no consistent way to identify which addresses are local use. There is no document identifying the requirements and needs of the network operators, therefore no reasonable and complete evaluation could result in the conclusion that deprecation is an appropriate action. The chairs chose to ask an ambiguous question that the group clearly had different opinions about the meaning of, and shortly before the initial question was called there was an explicit statement about lack of clarity in the consequences of the alternatives. Forcing a YES/NO question for an end state rather than a process, without a widespread understanding of the consequences and trade-offs, was an inappropriate action by the chairs. The working group was mislead by an ambiguous question from the chairs. The asserted conclusion is invalid as the WG has not reached consensus on anything other than more work needs to be done. Background: The entire open discussion in SF started off misled by a bogus technical assertion by the chair: 1:42:04 ... it is always going to be possible to implement wrong unless we get rid of whole concept of private addresses ... you will always have the possibility ... for leaking addresses if they exist in the architecture >>> Existence in the address architecture is not what creates the possibility for limited scope addresses to be leaked, that only allows identification of them. The thing the creates the possibility for leaking limited scope addresses outside their realm of applicability is the ignorance by the applications that the real network has limited scope addresses and they require appropriate handling. Removing any tag for the application to identify which addresses have limited scope only ensures that they will be leaked. There was no enumeration of the requirements for any solution, therefore no reasonable and complete evaluation that the current SL is inadequate. 1:06:49 MW - you can only document the cost/benefit analysis of a point that's understood 1:36:30 - 'Do we have enough information to decide' >>> on slide but not discussed >>> discussion about overriding need to reach consensus 1:39:00 - Pekka - Exclusive is just broken ... if we want ... >>> indicates need to understand requirements without further analysis, that requirement is met by access prefix thing access prefix is less intrusive and easier to implement >>> where is the analysis that backs that up? 1:41:42 - Alain - ... if we want to avoid leaking ... >>> indicates need to understand requirements 1:50:05 - Erik - we don't have enough information to decide yet, and part of what I am looking for is so what are the benefits of these things anyhow >>> indicates need to understand requirements 1:52:33 - look at benefits before we try to decide something - MW 'anything we are doing here should be a cost/benefit tradeoff ... maybe we'll decide we need more information ... we need to do an intelligent cost/benefit analysis and have a supportable reason for our choice 1:58:00 Leif - Erik's comments were first time I heard purported benefits - applications shouldn't have to worry about topology that's a fundamental comparing the benefits with breaking fundamental assumption that apps shouldn't care about topology - its clear that you should eliminate SL >>> an informed conclusion after 5 1/2 minutes evaluation of a partial verbal list of requirements ??? How many others were in the same place? 2:11:39 Dave - I agree with Keith's attempt to clarify the wording of the question people are arguing for the eliminate proposal which there isn't any draft about ... In fact over the meeting it was clear that there was no common understanding about what 'deprecate' means even by the chairs, and this carried onto the list discussion: 2:09:24 MW - that would be eliminating it, you can always bring something back later someone can have a research group, but if take it out of the specs, ** that is what eliminating it means ** 2:09:35 Keith - alternate proposal for a way forward - I don't believe the bit patterns that are defined for SL will be allocated for some other use so I don't think we are eliminating them entirely, but I want to know if we can get a sense of the group that discouraging use of SL is the appropriate way to move forward - part 1 part 2 - identify the things that SL was supposed to solve and work out alternate solutions for those 2:10:20 MW - instead of eliminate I think the right word would be deprecate because I agree that we are not going to suddenly decide to use those bits for something else - I agree with you on that but discouraging ** is that deprecating? ** 2:10:35 Keith - deprecating in a sense, it also leaves the idea that until we find something else, you might have some usage of SL but the plan is in the future to deprecate it 2:11:39 Dave - I agree with Keith's attempt to clarify the wording of the question people are arguing for the eliminate proposal which there isn't any draft about - this is a question to you to clarify the question - Erik made and Dino added - zero conf asked what do routers do - do we want to enable a zero config thing - if so do you want to enable SL in a deprecated sense as Keith put it, for that or is the proposal to eliminate them and force zero config guys to not work because we don't care about that, or to force them to use some other well known prefix clarify which one of those is actually the proposal ? >>> questions never answered or even discussed 2:12:51 Christian - if we say that we are going to eliminate SL we have to actually eliminate it and ** that means ** that we have to make it explicit that at some point in the future all implementations are supposed to discard any packets sent to the specific prefix 2:13:19 MW - I'll resay what I said earlier which is I had said we would say eliminate it or keep it and then we'd have multiple choices if we kept it but apparently ** if we eliminate it we will also have multiple choices about what exactly that means ** >>> 'multiple choices' how does that indicate a clear meaning ??? 2:13:31 Erik - I think there area some details about what it means if we actually choose to eliminate ** I think that means ** that people at their leisure can go ahead and delete whatever code they have that currently recognizes FEC0 but they don't have to do it tomorrow, because we are not going to allocate this for any other purpose in the near future, but it means that you don't have to add any more code, but you can at your leisure delete what you have 2:14:05 Brian - I got up to say that the question that you were going to ask is one that ** I would have difficulty answering because I wouldn't vote for keeping SL unless I knew which of the options we were going to go for ** >>> though voting against without understanding the consequences didn't appear to be a problem 2:16:09 Bound - IPv4 NAT is a national security problem, at least in the US so ** what I am hearing to day is we should stop it and not give any credence to help proliferate them ** >>> a belief that removing SL removes the threat of NAT ??? 2:16:45 Keith - ... ** the real trick is ** that applications shouldn't have to special case these things, Dns shouldn't have to special case them, routing shouldn't; have to special case these things >>> in other words applications continue to ignore the reality of limited scope addresses, because without a well-known tag it is impossible to special case them 2:18:20 Thomas, just to be clear, ** deprecate I assume means ** somewhere to the left of the limited use model - MW Yes, somewhere to the left of limited, the bits would somehow become deprecated but probably you wouldn't get to reuse them and we would not want to invalidate existing implementations so we may have to wave our hands around that a little bit to make sure we do it right - Bob, Christian just added - and probably needed to be blackholed >>> 'somewhere to the left'; 'somehow be deprecated'; & '...may have to hand wave...' those are not clear indications of the meaning of the question or consequences of this action. 4/2 JB - Ambiguous addresses are a nightmare... >>> a common theme 4/5 MW - The proposal is to deprecate a prefix in the addressing architecture for which we have found no suitable use. >>> Translation - we refuse to acknowledge the uses in shipping code, though we do acknowledge that there is shipping code which uses them. 4/5 DL - I thought we were voting on something more meaningful, i.e., site-locals themselves. Now I understand that site-locals do not exist as such and we were just voting on the deprecation of the prefix itself. 4/7 AW - I have come to the conclusion that the consensus call email on the list failed to adequately describe what a YES for deprecation actually entailed, and has pretty effectively shot itself in the foot. 4/4 HA - Note: By "Deprecate Site-Local", ** I mean ** "Do not require any application, host, router, protocol or IETF practice to have to make special consideration for the idea that an IPv6 unicast address outside of the link-local range can refer to two different hosts". 4/4 PF - So, when I say I want Site Local deprecated ** I mean ** I want routing and addressing separated, and given that separation, we have to work on solving the real problems we have with Internet today While there was no single clear statement about what deprecate means (though many architecturally different assertions), there was a clear overriding concern by the chairs that some conclusion be reached, even a bad one: 2:07:43 Erik - call for comments for SL Bob - give us a second here MW - if we are going reach any conclusion we can't accept a sudden influx at mic 2:08:45 Bob - if you want to support SL independent of usage model come to the mic 2:15:22 Bob by the way... MW cut off> we have to cut off discussion with the people who are at the mic because we have to try to have some conclusion >>> where was the fire? If the question had not been called in SF, would the world have ended? Allowing 7 1/2 minutes for rebuttal comments to a discussion that was not on the agenda, there were no documents published, and people did not come to the meeting prepared to discuss is inappropriate in any case. Cutting off discussion just as people were getting their thoughts together to form reasonable statements about requirements is improper meeting management and biases any attempt to measure consensus. Despite the lack of agreement about exactly what deprecate means, there was a comment: 2:17:19 MW - lets see, just a sec ... we are going to call a question and the question is going to be a yes no question do we want to deprecate SL addresses or do we not want to deprecate SL addresses - we realize that both of those answers no matter which answer you give there is more details that need to be worked out, but we are trying to get what is the direction, does the group want to go away from SL addressing, deprecate it work out how to get it out, does the group want to keep it and figure out what the right usage model is for it OK, this is a usage model issue. its is like do we want to support usage of SL and come up with a usage model for it, or do we want to deprecate it which was not made to the mail list consensus call. >>> There is a vast difference between identifying direction of the group and the actual yes/no to deprecate SL question that was asked. In fact all other indications from the chairs were that the question was NOT about measuring direction of the WG, but actually about their intent to have local scoped addresses removed from the scoped address architecture and other documents. >>> This drive for a decision despite multiple statements (by the chairs no less), that a cost/benefit analysis can only be done with a complete set of requirements. Where is the supportable reason for the asserted choice to change the architecture? For that matter, where is the requirements document that a supportable reason would be built from? In preparing the question, it should have been clear that the chairs were not thinking this though clearly: 2:18:57 Perry when you say it is a yes or no question, therefore it must be phrased differently than do we wish to deprecate them or do we not wish to deprecate them - MW I am tired, did I actually say that? Yet seconds later: 2:19:20 MW Question - show of hands, how many people think that we should deprecate SL addressing? Keith's wording at 2:09:35 would have been an appropriate pair of questions for the chairs to ask (I acutally support part 2), but the chairs chose to ask an ambiguous question that the group (and even the chairs) clearly had different and inconsistent opinions about the meaning of. Shortly before the question was called there was an explicit statement about lack of clarity about the consequences of the alternatives. The fact that many of the YES responses were about removal of local scope addresses invalidates the asserted conclusion. The existence of limited scope addresses are an architectural consequence of operational choices, and not in the purview of the IETF to decide. Tony PS: 2:14:05 Brian ... I also a comment that RFC 1597 is one of the worst end runs in the history of the IETF. >>> I am arguing that through an ambiguous question this desperate drive for a conclusion which intends to remove local scope addresses from the architecture superseded it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 25 01:27: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 h3P8RMhs027836; Fri, 25 Apr 2003 01:27:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3P8RMem027835; Fri, 25 Apr 2003 01:27:22 -0700 (PDT) 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 h3P8RJhs027828 for ; Fri, 25 Apr 2003 01:27:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3P8RQFC008498 for ; Fri, 25 Apr 2003 01:27:26 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id CAA14887 for ; Fri, 25 Apr 2003 02:27:20 -0600 (MDT) 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, 25 Apr 2003 08:27: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; Fri, 25 Apr 2003 08:27: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; Fri, 25 Apr 2003 08:27:19 Z Received: from kirk.rvdp.org (kirk.rvdp.org [80.126.101.63]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 25 Apr 2003 08:27:19 Z Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6p2/8.11.6) id h3P8RHk09677 for ipng@sunroof.eng.sun.com; Fri, 25 Apr 2003 10:27:17 +0200 (CEST) Date: Fri, 25 Apr 2003 10:27:17 +0200 From: Ronald van der Pol To: ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030425082717.GC5176@rvdp.org> References: <044201c30aad$00df25b0$261e4104@eagleswings> <3EA86490.8060501@cisco.com> <20030424223635.GB6776@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030424223635.GB6776@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 24, 2003 at 23:36:35 +0100, Tim Chown wrote: > No need to bother, just read any sample of 100 ipng emails in one day and > the same arguments come up again and again. And again. True, and the problem is that we need to keep reading all those emails because there might be a new argument in there some day. > Is there a WG chair in the house? I think they tried a couple of times. I remember "top 10 posters" lists and requests to keep the number of replies down. What else can they do? I think it is up to the frequent emailers now. Maybe they can all setup web pages "what I think about X" and just point to them :-) I am truly interested in their opinions, but I don't like wasting time on reading the same things over and over. 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 Fri Apr 25 01:36: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 h3P8aWhs028043; Fri, 25 Apr 2003 01:36:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3P8aWBh028042; Fri, 25 Apr 2003 01:36:32 -0700 (PDT) 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 h3P8aThs028035 for ; Fri, 25 Apr 2003 01:36:29 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3P8aaFC009958 for ; Fri, 25 Apr 2003 01:36:36 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id CAA03150 for ; Fri, 25 Apr 2003 02:36:30 -0600 (MDT) 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, 25 Apr 2003 08:36: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, 25 Apr 2003 08:36: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, 25 Apr 2003 08:36:30 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; Fri, 25 Apr 2003 08:36:29 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 JAA20038 for ; Fri, 25 Apr 2003 09:36:28 +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 JAA02530 for ; Fri, 25 Apr 2003 09:36:27 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h3P8aRQ12295 for ipng@sunroof.eng.sun.com; Fri, 25 Apr 2003 09:36:27 +0100 Date: Fri, 25 Apr 2003 09:36:27 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: A follow up question Message-Id: <20030425083627.GA12258@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <044201c30aad$00df25b0$261e4104@eagleswings> <3EA86490.8060501@cisco.com> <20030424223635.GB6776@login.ecs.soton.ac.uk> <20030425082717.GC5176@rvdp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030425082717.GC5176@rvdp.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Apr 25, 2003 at 10:27:17AM +0200, Ronald van der Pol wrote: > > I think they tried a couple of times. I remember "top 10 posters" lists > and requests to keep the number of replies down. What else can they do? > I think it is up to the frequent emailers now. Maybe they can all setup > web pages "what I think about X" and just point to them :-) Or write I-Ds. Some people must have posted 100 I-D's worth of text, yet there is no "Site locals Considered Harmful" I-D... is there? 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 Fri Apr 25 12:42: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 h3PJgehs000614; Fri, 25 Apr 2003 12:42:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3PJge5F000611; Fri, 25 Apr 2003 12:42:40 -0700 (PDT) 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 h3PJgbhs000603 for ; Fri, 25 Apr 2003 12:42:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3PJghuc009298 for ; Fri, 25 Apr 2003 12:42:43 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id NAA00473 for ; Fri, 25 Apr 2003 13:42:37 -0600 (MDT) 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, 25 Apr 2003 19:42: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; Fri, 25 Apr 2003 19:42: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; Fri, 25 Apr 2003 19:42:36 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 25 Apr 2003 19:42:36 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3PJeGJ13672; Fri, 25 Apr 2003 22:40:18 +0300 Date: Fri, 25 Apr 2003 22:40:16 +0300 (EEST) From: Pekka Savola To: fred@cisco.com cc: ipng@sunroof.eng.sun.com Subject: Re: Operational Renumbering Procedure In-Reply-To: <200304181635.JAA04860@irp-view7.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 Fri, 18 Apr 2003 fred@cisco.com wrote: > I'd be interested in your comments on > http://www.ietf.org/internet-drafts/draft-baker-ipv6-renumber-procedure-00.txt. > > This document grew out of a brief exchange on the IETF list, and an > internal exchange with some operations folks at Cisco. What I'm trying to > explore in the document is why some people say "renumbering is easy" and > others say "renumbering is next to impossible" - the latter often with > expletives added for color. We get a whine from various and sundry saying > "please make renumbering easy to do", but we aren't especially told what to > make easy. > > It turns out that operationally, the best thing we can do to make > renumbering easy is make manual configuration really hard. It is the cases > of manual configuration - things that are not automated in the first place - > that are hard to automate. > > I'll take direction on what to do with the draft. I have had one network > operator (who has to renumber an IPv4 network) tell me that the procedure is > of value to him a it gives him a step in defining things. So it may be of > value as an informational document. But for me, the real value lies in > helping the IPv6 and the operational communities talk with each other. I think this is certainly something we need to do in the multi6 and even ipv6 wg context. There are two related processes, in my mind: 1) a) documenting best practices to have your network in a state you can renumber it if needed b) practices to use if/when you need to renumber and: 2) developing mechanisms which make the renumbering even a bit more easier. It's difficult, and we shouldn't expect too much of it, but I'm pretty sure there may be ways to at least eliminate the worst quirks. In the "optimal" case these would be tied together in a feedback loop :-) I've had some thoughts on both, but as there has not been a sufficient community interest, I haven't bothered to go deeper into it. ... As to your draft -- I didn't read it properly, but a few comments: - a bit much of too pretty language (e.g. the first paragraph), have to concentrate too much to understand what it means - the claim, originally made in RFC2072 I suppose: RFC 2072 [6] describes the implications of renumbering in an IPv4 network. A number of issues are raised, not the least of which is that while IPv4 in no sense precludes the configuration of more than one prefix on an interface in an equal sense, IPv4 equipment usually does not provide this capability. .. IMO appears to be wrong. The IPv4 equipment I use certainly allows all of this. Typically only those which are restricted anyway (like printers configured from an LCD panel or such!) may only allow one, but this doesn't seem to be an architectural limitation. - you're having (perhaps unintentionally) an ISP-driven perspective or some unstated assumtions; that is: 2.3 Stable routing both prefixes Once the network has been configured with the new prefix and has had sufficient time to stabilize, it becomes a stable platform with two addresses configured on each and every infrastructure component interface (apart from serial interfaces that use only the link local address), and two addresses available for the use of any end system, one in the old prefix and one in the new. However, due to DNS [3][4] advertisement and history, sessions are opened with the addresses in the old prefix; the new is idle. This is a stable configuration. ... in practice there is no such stable state with IPv6, in the generic case. Reason is that if the ISP's use ingress filtering for the site, using both prefixes will result in about 50% of packets getting dropped unless you have something like source-based routing. This problem has been noted earlier in host-centric multihoming, for example. The other explantions why this was overlooked may have been: - if you renumber an ISP or a major customer, there are typically no ingress filtering issues or at least you're in a position to negotiate about them - with IPv4, some get around these issues by using NAT in the border routers - I'd suggest removing the references and assumptions of RFC2894 -- or at least sweeping them up to a corner of a draft, as it seems to be practically useless & unimplemented approach. Nit: "presumes the use of IPv6 Autoconfiguration as described in RFC 2894" seems odd -- the main body of that RFC is *not* about autoconfiguration as we typically understand it (in the RFC2461/2462 sense). - section 3 should more clearly separate (both are mentioned to some extent, but after the mention, you go straight to the first) the cases of "manually configured but local" (in theory, you can keep a better track of these using some methods!) and "manually configured but remote" (e.g. someone else's access lists etc.). These issues have entirely different implications I think. - s/liklihood/likelihood/ - in acknowledgements, s/Michel P/Michel Py p/ ? -- 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 Apr 25 14:30: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 h3PLUehs002134; Fri, 25 Apr 2003 14:30:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3PLUeZe002133; Fri, 25 Apr 2003 14:30:40 -0700 (PDT) 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 h3PLUbhs002126 for ; Fri, 25 Apr 2003 14:30:37 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3PLUhuc009734 for ; Fri, 25 Apr 2003 14:30:44 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA13277 for ; Fri, 25 Apr 2003 14:30:38 -0700 (PDT) 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, 25 Apr 2003 21:30:37 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, 25 Apr 2003 21:30: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, 25 Apr 2003 21:30: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; Fri, 25 Apr 2003 21:30:36 Z Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3PLU1EL021655; Fri, 25 Apr 2003 14:30:26 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGM08756; Fri, 25 Apr 2003 14:26:24 -0700 (PDT) Message-Id: <5.2.0.9.2.20030425131251.02ed3cc0@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 25 Apr 2003 14:00:29 -0700 To: Pekka Savola From: Fred Baker Subject: Re: Operational Renumbering Procedure Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <200304181635.JAA04860@irp-view7.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:40 PM 4/25/2003 +0300, Pekka Savola wrote: > 1) > a) documenting best practices to have your network in a state you can >renumber it if needed > b) practices to use if/when you need to renumber > >and: > > 2) developing mechanisms which make the renumbering even a bit more >easier. It's difficult, and we shouldn't expect too much of it, but I'm >pretty sure there may be ways to at least eliminate the worst quirks. > >In the "optimal" case these would be tied together in a feedback loop :-) um, yes. In mentioning 2894, I was hoping that (2) was covered. Perhaps I should refer to 2461/2462. > - a bit much of too pretty language (e.g. the first paragraph), have to > concentrate too much to understand what it means OK. > - the claim, originally made in RFC2072 I suppose: > > RFC 2072 [6] describes the implications of renumbering in an IPv4 > network. A number of issues are raised, not the least of which is > that while IPv4 in no sense precludes the configuration of more than > one prefix on an interface in an equal sense, IPv4 equipment usually > does not provide this capability. > > .. IMO appears to be wrong. The IPv4 equipment I use certainly allows >all of this. Hmm. The equipment I am referring to is Cisco Routers, *nix machines, Microsoft Windows, and so on. To put two IPv4 prefixes on a Cisco Router interface, one needs to configure two sub-interfaces rather than one interface, and until relatively recently this was not necessarily supported. Sun Workstations and Linux machines have a very clear sense of what single IP prefix and address is used on an interface, as does Windows; I'm not at all certain how I would go about putting a second address on a Windows interface at all, and on a Sun, it would be a "secondary address" or an entry in the host file (such as localhost has). A secondary address is in no sense the same thing as having two co-equal prefixes on an interface. Cisco routers have secondary address as a capability, but it is not at all the same thing as having two addresses; if you remove the primary, the other doesn't simply "become" the primary... > - you're having (perhaps unintentionally) an ISP-driven perspective or >some unstated assumtions; that is: > >2.3 Stable routing both prefixes > > Once the network has been configured with the new prefix and has had > sufficient time to stabilize, it becomes a stable platform with two > addresses configured on each and every infrastructure component > interface (apart from serial interfaces that use only the link local > address), and two addresses available for the use of any end system, > one in the old prefix and one in the new. However, due to DNS [3][4] > advertisement and history, sessions are opened with the addresses in > the old prefix; the new is idle. This is a stable configuration. > >... in practice there is no such stable state with IPv6, in the generic >case. Reason is that if the ISP's use ingress filtering for the site, >using both prefixes will result in about 50% of packets getting dropped >unless you have something like source-based routing. This problem has >been noted earlier in host-centric multihoming, for example. um, I'm assuming that if someone is using a given prefix via an ISP, the ISP is not filtering it out. Either the ISP is routing that prefix to them and therefore it meets the RPF check or whatever at the ISP, or the user has provided the address to the ISP (in BGP or by contract) and asked them to please not filter it out. A scenario in which an enterprise or tertiary ISP intends to use multiple prefixes via the same transit ISP and doesn't advise their ISP to tune the ingress filtering seems a trifle daft, for the exact reason you point out. >The other explantions why this was overlooked may have been: > - if you renumber an ISP or a major customer, there are typically no >ingress filtering issues or at least you're in a position to negotiate >about them > - with IPv4, some get around these issues by using NAT in the border >routers yes to both, except that in this case I'm looking at IPv6. The same procedure can be used with IPv4, with some adaptations. The acronym "DHCP" becomes important. > - I'd suggest removing the references and assumptions of RFC2894 -- or at >least sweeping them up to a corner of a draft, as it seems to be >practically useless & unimplemented approach. Nit: "presumes the use of >IPv6 Autoconfiguration as described in RFC 2894" seems odd -- the main >body of that RFC is *not* about autoconfiguration as we typically >understand it (in the RFC2461/2462 sense). no, it is not about what one does to auto-renumber systems. It is how to use that facility at the operational level. Let me give you an IPv4 example of what I have visions of. My Cable ISP gives the router at my home an address using DHCP; the lease is two weeks (!). Imagine that someone at the ISP decided to renumber their network by going to each DNS server and replacing the A records with new ones in the new prefix, and simply changing each router interface, which has a configuration like interface ip address 12.107.10.1 255.255.255.128 and typing perhaps interface ip address 13.107.10.1 255.255.255.128 Now, the network would pretty quickly sort out routing, updating LSAs and constructing routes to the various parts of it. Anyone who had gotten a DNS translation of a name within the DNS time-to-live would continue to use the old (now unroutable) address for the server until the DNS translation expired, and only then get the new translation. Well, yes, that is a worst case, but a possible one. The router at my home wouldn't ask about its address and prefix until the DHCP lease expired, which might be two weeks. Basically, we would have a pretty serious outage. What I'm trying to propose here is not a new way to automatically renumber, but an operational procedure for using the existing automated facility. It says "when you beat your head against the wall, it hurts. Solution: don't beat your head against the wall. Configure both prefixes, route both prefixes, and let all those timers expire and people switch over to the new prefix. *Then* discard the old." The next question is "so what about all those things that aren't using the automated facility and as a result don't get the message?" Here, as some say, there be dragons. The *other* thought in the draft is "don't do that" and "if you're forced to do it anyway, here's where you get to run around and re-do all your static configurations." It turns out that there are some places where you're forced to use static configuration: ACLs and Route Maps come to mind pretty quickly. Those are examples of what has to be addressed with appropriate configuration. > - section 3 should more clearly separate (both are mentioned to some >extent, but after the mention, you go straight to the first) the cases of >"manually configured but local" (in theory, you can keep a better track >of these using some methods!) and "manually configured but remote" (e.g. >someone else's access lists etc.). These issues have entirely different >implications I think. OK > - s/liklihood/likelihood/ > > - in acknowledgements, s/Michel P/Michel Py p/ ? thanks. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 25 14:40: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 h3PLe9hs002418; Fri, 25 Apr 2003 14:40:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3PLe9te002417; Fri, 25 Apr 2003 14:40:09 -0700 (PDT) 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 h3PLe5hs002404 for ; Fri, 25 Apr 2003 14:40:05 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3PLeBuc012330 for ; Fri, 25 Apr 2003 14:40:11 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h3PLe5rZ021221 for ; Fri, 25 Apr 2003 14:40:06 -0700 (PDT) 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, 25 Apr 2003 21:40: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; Fri, 25 Apr 2003 21:40:05 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, 25 Apr 2003 21:40:05 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 25 Apr 2003 21:40:05 Z Content-class: urn:content-classes:message Subject: RE: Operational Renumbering Procedure MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Apr 2003 14:40:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Message-Id: <963621801C6D3E4A9CF454A1972AE8F5045799@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operational Renumbering Procedure Thread-Index: AcMFyTNdf9s7NLEQSeW1p3SE+zz6lgAA5eQw From: "Michel Py" To: "Fred Baker" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3PLe5hs002405 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, > Fred Baker wrote: > It turns out that operationally, the best thing we can do to > make renumbering easy is make manual configuration really hard. This summarizes it very well I think. I will comment on the draft later on when time permits (spread really thin these days), however on a super-fast read it appears to be shallow on internal policies and politics. For example, how do you make renumbering easy when the following (with matching SNMP config) is a requirement: line vty 0 4 no login transport input none 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 Apr 25 16:20:42 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 h3PNKfhs003242; Fri, 25 Apr 2003 16:20:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3PNKfcr003241; Fri, 25 Apr 2003 16:20:41 -0700 (PDT) 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 h3PNKbhs003233 for ; Fri, 25 Apr 2003 16:20:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3PNKhFC012887 for ; Fri, 25 Apr 2003 16:20:43 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA04291 for ; Fri, 25 Apr 2003 17:20:38 -0600 (MDT) 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 <0HDX00535A2L7Z@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 25 Apr 2003 17:18:22 -0600 (MDT) Received: from sun.com ([129.146.18.22]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HDX00181A2JV8@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 25 Apr 2003 17:18:21 -0600 (MDT) Date: Fri, 25 Apr 2003 16:18:19 -0700 From: Alain Durand Subject: Re: TCPng/ multiple addresses per node (was Re: A follow up question)_ To: john.loughney@nokia.com Cc: dcrocker@brandenburg.com, ietf@ietf.org, ipng@sunroof.eng.sun.com, john-ietf@jck.com Message-id: <3EA9C23B.80705@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: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: >Hi Alain, > >I agree with your intro (which I clipped to save space), > Thank you! > one >comment that I have is: > > > >>There is a proposal to create an API to enable the >>application creating the socket to specify some of the >>properties that it desires/requires. This is a step in the right >>direction, but I'm not convinced this can go far enough. >>So I fully support this idea of lifting the ban on TCPng >>(or any transport layer for that matter) to de-couple >>the abstraction needed by applications to the one required >>by the network. This is in fact introducing some of the semantic >>of a session layer between the application and the network. >>Can this be done at the transport layer in the form of TCPng >>or does this require and actual additional session layer? >>I'm not sure at this point in time. >> >> > >There already something like this, I'm sure you know - SCTP. >I'm actually not trying to promote SCTP, but it might be interesting, >as we have an RFC that does most of the avove, to look at it >critically & see how it performs. > >SCTP, as a background, uses sets of addresses/ports to identify a >node. In the usual case, one node will pass all of its addresses(& ports) >to its peer & the peer returns its addresses (&ports) for SCTP >traffic. The application has the the option to choose the primary >address to be used. > SCTP does not specify how the 'primary' source & destination are chosen, nor does it explain how to order those lists once it decides to try another pair. Two possible ways to do that could be: - use knowledge of the topology, that is pass some of the routing information to the end nodes. - use dynamic measurements.. For example start the connection using the initial src & dst, and then send regular probes (duplicates?) using the other combinations to do measurements and keep statistics. On top of that you might want to add social/economic information known by the end points, like this interface is cheap vs expensive at this particular moment. Similar information for other links within the network would be valuable but much more difficult to collect! Also, there is still a need to enable the application to specify the desired/required properties of the addresses, like use temporary vs use stable address, use home address vs care-of-address,... SCTP does not do any of that. - 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 Apr 25 16:29: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 h3PNT0hs003401; Fri, 25 Apr 2003 16:29:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3PNT01W003400; Fri, 25 Apr 2003 16:29:00 -0700 (PDT) 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 h3PNSvhs003393 for ; Fri, 25 Apr 2003 16:28:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3PNT3FC014918 for ; Fri, 25 Apr 2003 16:29:03 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA07185 for ; Fri, 25 Apr 2003 17:28:58 -0600 (MDT) 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, 25 Apr 2003 23:28: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; Fri, 25 Apr 2003 23:28: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; Fri, 25 Apr 2003 23:28:56 Z Received: from mailman.research.att.com ([135.207.24.32] [135.207.24.32]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 25 Apr 2003 23:28:56 Z Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h3PNPosV011936; Fri, 25 Apr 2003 19:26:00 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h3PNRAXs004493; Fri, 25 Apr 2003 19:27:10 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h3PNS4M00234; Fri, 25 Apr 2003 16:28:04 -0700 (PDT) Message-Id: <200304252328.h3PNS4M00234@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: fred@cisco.com Subject: Re: Operational Renumbering Procedure Cc: ipng@sunroof.eng.sun.com References: <200304181635.JAA04860@irp-view7.cisco.com> <5.2.0.9.2.20030425131251.02ed3cc0@mira-sjc5-b.cisco.com> Date: Fri, 25 Apr 2003 16:28:03 -0700 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Hmm. The equipment I am referring to is ... *nix machines, ... BSD 4.4-based operationg systems allow multiple IPv4 prefixes on an interface in an equal sense. Configuring the second and further prefixes requires an additional argument to the ifconfig command simply to signify that it's an additional address instead of a replacement; it does not make the address "primary" or "secondary" or different in any way. Deleting the "primary" address just means that there's another address that's "primary", since it's the arbitrary distinction of being first on the list of address/prefixes assigned to the interface. Source address selection is done based on the routing table; e.g. in the following configuration: fenestro% ifconfig de1 de1: flags=8943 mtu 1500 inet 172.24.37.94 netmask 0xffffffe0 broadcast 172.24.37.95 inet 10.0.1.242 netmask 0xffffff00 broadcast 10.0.1.255 if the nexthop of the route is on 10.0.1.0/24, the source address is 10.0.1.242 . If the nexthop is on 172.24.37.64/27, the source address is 172.24.37.94 . e.g. Destination Gateway Flags Refs Use Netif Expire 10.0.2/24 10.0.1.1 UGSc 0 6 de1 fenestro% ping 10.0.2.1 results in 16:20:02.815564 10.0.1.242 > 10.0.2.1: icmp: echo request and deleting the 172.24.37.94 address from the interface affects this not one whit: fenestro% sudo ifconfig de1 172.24.37.94 delete fenestro% ifconfig de1 de1: flags=8943 mtu 1500 inet 10.0.1.242 netmask 0xffffff00 broadcast 10.0.1.255 fenestro% ping 10.0.2.1 still results in 16:26:11.722139 10.0.1.242 > 10.0.2.1: icmp: echo request 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 Fri Apr 25 20:15:48 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 h3Q3Flhs004584; Fri, 25 Apr 2003 20:15:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3Q3FlxG004583; Fri, 25 Apr 2003 20:15:47 -0700 (PDT) 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 h3Q3Fihs004576 for ; Fri, 25 Apr 2003 20:15:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3Q3Fouc020831 for ; Fri, 25 Apr 2003 20:15:50 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id VAA29955 for ; Fri, 25 Apr 2003 21:15:42 -0600 (MDT) 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, 26 Apr 2003 03:15: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; Sat, 26 Apr 2003 03:15: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; Sat, 26 Apr 2003 03:15:41 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 26 Apr 2003 03:15:41 Z Content-class: urn:content-classes:message Subject: I never thought about hijacking an IPv4 /8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Apr 2003 20:15:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F7A5@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I never thought about hijacking an IPv4 /8 Thread-Index: AcMKstLcBXxwvUS/ShCz5+R4QVe0cwA7nv7A From: "Michel Py" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3Q3Fihs004577 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk But some people do.... http://www.wiana.org/ Gee, I think I'm going to hijack an IPv6 /8 prefix too. What could I do with it? Let's see. Mmmmm. Provide globally unique addresses, maybe. I wonder if these guys will let me have their scripts. 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 Apr 25 22:58: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 h3Q5wlhs005676; Fri, 25 Apr 2003 22:58:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3Q5wlna005675; Fri, 25 Apr 2003 22:58:47 -0700 (PDT) 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 h3Q5wihs005668 for ; Fri, 25 Apr 2003 22:58:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3Q5woFC020475 for ; Fri, 25 Apr 2003 22:58:50 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id WAA02632 for ; Fri, 25 Apr 2003 22:58:45 -0700 (PDT) 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, 26 Apr 2003 05:58: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; Sat, 26 Apr 2003 05: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 for ipng@sunroof.eng.sun.com; Sat, 26 Apr 2003 05:58:44 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 26 Apr 2003 05:58:43 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3Q5wXj17063; Sat, 26 Apr 2003 08:58:33 +0300 Date: Sat, 26 Apr 2003 08:58:32 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: ipng@sunroof.eng.sun.com Subject: Re: Operational Renumbering Procedure In-Reply-To: <5.2.0.9.2.20030425131251.02ed3cc0@mira-sjc5-b.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 Fri, 25 Apr 2003, Fred Baker wrote: > > - the claim, originally made in RFC2072 I suppose: > > > > RFC 2072 [6] describes the implications of renumbering in an IPv4 > > network. A number of issues are raised, not the least of which is > > that while IPv4 in no sense precludes the configuration of more than > > one prefix on an interface in an equal sense, IPv4 equipment usually > > does not provide this capability. > > > > .. IMO appears to be wrong. The IPv4 equipment I use certainly allows > >all of this. > > Hmm. The equipment I am referring to is Cisco Routers, *nix machines, > Microsoft Windows, and so on. To put two IPv4 prefixes on a Cisco Router > interface, one needs to configure two sub-interfaces rather than one > interface, and until relatively recently this was not necessarily > supported. Really? All the software versions in 3+ years I've used are supported multiple addresses on the same interface using "secondary" keyword. (But see below.) > Sun Workstations and Linux machines have a very clear sense of > what single IP prefix and address is used on an interface, as does Windows; Works in Linux just fine. Often, additional addresses are added as "aliased" or "sub" interfaces, but that's not necessary, you can put all of them in the main interface too. > I'm not at all certain how I would go about putting a second address on a > Windows interface at all, and on a Sun, it would be a "secondary address" > or an entry in the host file (such as localhost has). I'm not aware of these systems, but some windows boxes at least allow aliased IP addresses and more than one default gateway. I don't know what happens if you remove the ones you added first. > A secondary address > is in no sense the same thing as having two co-equal prefixes on an > interface. Cisco routers have secondary address as a capability, but it is > not at all the same thing as having two addresses; if you remove the > primary, the other doesn't simply "become" the primary... I'd say this is an implementation problem (or rather, a shortcut to make address selection etc. easier). For example in Linux, you can add/remove addresses freely, as with BSD. > > - you're having (perhaps unintentionally) an ISP-driven perspective or > >some unstated assumtions; that is: > > > >2.3 Stable routing both prefixes > > > > Once the network has been configured with the new prefix and has had > > sufficient time to stabilize, it becomes a stable platform with two > > addresses configured on each and every infrastructure component > > interface (apart from serial interfaces that use only the link local > > address), and two addresses available for the use of any end system, > > one in the old prefix and one in the new. However, due to DNS [3][4] > > advertisement and history, sessions are opened with the addresses in > > the old prefix; the new is idle. This is a stable configuration. > > > >... in practice there is no such stable state with IPv6, in the generic > >case. Reason is that if the ISP's use ingress filtering for the site, > >using both prefixes will result in about 50% of packets getting dropped > >unless you have something like source-based routing. This problem has > >been noted earlier in host-centric multihoming, for example. > > um, I'm assuming that if someone is using a given prefix via an ISP, the > ISP is not filtering it out. Depending on what you meant with "via" there are two interpretations: 1) ISP will allow the prefix that particular ISP gives you, that's without doubt. 2) You *cannot* control whether a prefix is used via an ISP, when it's selected as source address but the route goes to the destination. (For more, see explanation below.) An alternative would be pushing the whole routing table to the hosts. That has been proposed too, though.. > Either the ISP is routing that prefix to them > and therefore it meets the RPF check or whatever at the ISP, OK. > or the user > has provided the address to the ISP (in BGP or by contract) and asked them > to please not filter it out. I'm not completely sure which prefix you refer to. > A scenario in which an enterprise or tertiary ISP intends to use multiple > prefixes via the same transit ISP and doesn't advise their ISP to tune the > ingress filtering seems a trifle daft, for the exact reason you point out. You may be missing my original point. Let me try to elaborate even more. Let's simplify the network to a very minimal configuration: 2001:1::/32 2001:2::/32 ISP1 ISP2 \ / router 2001:1:1::/48 (statically routed from ISP1) | 2001:2:2::/48 ( ---"""--- ISP2) | host 2001:1:1::1, 2001:2:2::2 Assume the host has both 2001:1:1::1 and 2001:2:2::2 in DNS under "www.example.com". Some hosts in the Internet use these addresses. Client A uses the latter and client B uses the former (due to round-robin algorithm, these can be in either order). They're connected like: Client A Client B \ / ISP A ---- ISP B \ / ISP1 -- ISP2 \ / router | host (or whatever -- what's important that Client A/B are not direct customers using ISP1/ISP2's address space, respectively). Assume that the best return path from host to Client A goes through ISP1/ISPA and to Client B, through ISP2/ISPB. Now, packets from Client A to 2001:2:2::2 go through ISPA then to *ISP2* by some fashion, and from there to the router. However, the reply packets use 2001:2:2::2 as the source address, but are routed towards Client A through ISP1 and ISPA. Similar with Client B. The situation remains even if there is only one active default route at the site's router, there are two routers, or whatever. ISP1 allows through 2001:1:1::/48 but not 2001:2:2::/48. ISP2 allows through 2001:2:2::/48 but not 2001:1:1::/48. Therefore the packets get dropped. But you may be assuming that either: 1) the site is using provider-independent addresses, and this is not a problem (but then, renumbering is rarely a problem either). Such addresses do not exist for endsites at the moment though, which is good. 2) ISP1 would accept any BGP announcement from the site (like a prefix derived from ISP2). With provider-based addressing, that's pretty much unacceptable, or 3) the site could negotiate exceptions to the ingress filtering. However, these would have to be made everywhere, and there may be upstream ISP's also ingress-filtering. Doesn't seem like a realistic option, 4) there is some source-based routing implemented at the site router -- this would "fix" the problem. > >The other explantions why this was overlooked may have been: > > - if you renumber an ISP or a major customer, there are typically no > >ingress filtering issues or at least you're in a position to negotiate > >about them > > - with IPv4, some get around these issues by using NAT in the border > >routers > > yes to both, except that in this case I'm looking at IPv6. The same > procedure can be used with IPv4, with some adaptations. The acronym "DHCP" > becomes important. Of course -- I realize you talk about IPv6 -- but these were the reasons for the omission I thought possible in this case. > > - I'd suggest removing the references and assumptions of RFC2894 -- or at > >least sweeping them up to a corner of a draft, as it seems to be > >practically useless & unimplemented approach. Nit: "presumes the use of > >IPv6 Autoconfiguration as described in RFC 2894" seems odd -- the main > >body of that RFC is *not* about autoconfiguration as we typically > >understand it (in the RFC2461/2462 sense). > > no, it is not about what one does to auto-renumber systems. It is how to > use that facility at the operational level. I still think that gives a wrong impression as the reference introduces a protocol -- that's what's typically meant when the reference is flashed out. > Let me give you an IPv4 example of what I have visions of. My Cable ISP > gives the router at my home an address using DHCP; the lease is two weeks > (!). Imagine that someone at the ISP decided to renumber their network by > going to each DNS server and replacing the A records with new ones in the > new prefix, and simply changing each router interface, which has a > configuration like > > interface > ip address 12.107.10.1 255.255.255.128 > > and typing perhaps > > interface > ip address 13.107.10.1 255.255.255.128 > > Now, the network would pretty quickly sort out routing, updating LSAs and > constructing routes to the various parts of it. Anyone who had gotten a DNS > translation of a name within the DNS time-to-live would continue to use the > old (now unroutable) address for the server until the DNS translation > expired, and only then get the new translation. Well, yes, that is a worst > case, but a possible one. The router at my home wouldn't ask about its > address and prefix until the DHCP lease expired, which might be two weeks. > Basically, we would have a pretty serious outage. I think it's pretty much established that renumbering with a time span longer than lease/TTL times is just not realistic. In this case, they should lower the lease time, wait two weeks to make it kick in (unless you can "push" the new lease times), and see whether they could do the renumbering procedure with a shorter lease times (e.g. an hour). > What I'm trying to propose here is not a new way to automatically renumber, > but an operational procedure for using the existing automated facility. It > says "when you beat your head against the wall, it hurts. Solution: don't > beat your head against the wall. Configure both prefixes, route both > prefixes, and let all those timers expire and people switch over to the new > prefix. *Then* discard the old." I symphatize: this is the procedure I'd like too, but it has certain problems still. > The next question is "so what about all those things that aren't using the > automated facility and as a result don't get the message?" What exactly are you referring to with "the message"? Not a message, protocol-wise? > Here, as some > say, there be dragons. The *other* thought in the draft is "don't do that" > and "if you're forced to do it anyway, here's where you get to run around > and re-do all your static configurations." It turns out that there are some > places where you're forced to use static configuration: ACLs and Route Maps > come to mind pretty quickly. Those are examples of what has to be addressed > with appropriate configuration. Yep. -- 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 Apr 25 23:04: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 h3Q64hhs005811; Fri, 25 Apr 2003 23:04:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3Q64g03005810; Fri, 25 Apr 2003 23:04:42 -0700 (PDT) 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 h3Q64dhs005800 for ; Fri, 25 Apr 2003 23:04:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3Q64juc012541 for ; Fri, 25 Apr 2003 23:04:45 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id AAA27164 for ; Sat, 26 Apr 2003 00:04:39 -0600 (MDT) 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, 26 Apr 2003 06:04:39 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, 26 Apr 2003 06:04: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; Sat, 26 Apr 2003 06:04:38 Z Received: from lethargic.dyndns.org (lethargic.dyndns.org [216.254.151.222]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 26 Apr 2003 06:04:37 Z Received: from lethargic.dyndns.org (localhost [127.0.0.1]) by lethargic.dyndns.org (8.12.9/8.12.9) with ESMTP id h3Q64MlF093382; Sat, 26 Apr 2003 02:04:23 -0400 (EDT) (envelope-from leth@lethargic.dyndns.org) Received: (from leth@localhost) by lethargic.dyndns.org (8.12.9/8.12.9/Submit) id h3Q64LD5093381; Sat, 26 Apr 2003 02:04:21 -0400 (EDT) Date: Sat, 26 Apr 2003 02:04:20 -0400 From: Jason Hunt To: ietf@ietf.org Cc: ipng@sunroof.eng.sun.com, Keith Moore , Tony Hain Subject: My thoughts on local-use addresses Message-Id: <20030426060420.GA93218@lethargic.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I decided I will come out of "lurk mode" and try to express my thoughts about local-use addresses. I have been following the thread on the IETF general mailing list regarding site-local addresses. The following things may have already been discussed, as I only just recently subscribed to the IPNG mailing list. I think all unicast addresses should be "global", instead of having any scopes at all. I believe this would promote the whole E2E concept. Local-use addresses seem to be redundant. Why would one need to address a host on the same site or same link using an address other than its' global address? (Sorry if that is confusing) One scenario I thought of is back-end servers (ie: database servers) that do not need to be globally accessible, but other front-end servers (ie: web servers) need to communicate with these back-end servers. This is what a private address space would be for, and you would likely have multiple interfaces on seperate networks (one public, one private) to segregate the traffic. I suggest that: a) The site-local and link-local address scopes be abandoned. As I stated above, I believe they are redundant and therefore not needed. If you want to address all of the hosts at your site or on your link, why not use multicast? Are there any practical cases where one would use these scopes instead of global addresses that a private space or multi-cast would not solve? b) I believe that RFC 2462 (IPv6 Stateless Address Autoconfiguration) already deals with this, but I will mention it anyways; the link-local address space (or possibly some other space) be used as a fall-back for auto-configuration purposes. If a host is not configured with a static address, and does not have DHCP client capabilities or the host does not receive a response from a DHCP server, then an auto-configured address could be assigned to the interface. I think this would make it so that "it just works" if someone wants to plug a bunch of IPv6 hosts on to a LAN and use some type of neighbor disocvery mechanism to let the hosts find each other and start communicating. c) The link-local address space (or, again, some other space) be made available as private address space. It would for use by administrators of networks that are not planning to be connected to the Internet but still need an address space to use. Is this not the intention of RFC 1918 addresses as well? Is there any reason to not provide a private addres space? I don't want to start discussions about NAT because that's not what it the private address space will always be used for. Comments and constructive critisism are appreciated. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 26 08:49:40 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 h3QFnehs007391; Sat, 26 Apr 2003 08:49:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3QFnefq007390; Sat, 26 Apr 2003 08:49:40 -0700 (PDT) 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 h3QFjghs007361 for ; Sat, 26 Apr 2003 08:49:36 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3QFiHuc018888 for ; Sat, 26 Apr 2003 08:44:17 -0700 (PDT) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA16469 for ; Sat, 26 Apr 2003 08:44:10 -0700 (PDT) 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, 26 Apr 2003 15:44: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; Sat, 26 Apr 2003 15:44: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; Sat, 26 Apr 2003 15:44:07 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; Sat, 26 Apr 2003 15:44:06 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 834598D33; Sat, 26 Apr 2003 17:43:59 +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 A540C7A1A; Sat, 26 Apr 2003 17:43:50 +0200 (CEST) From: "Jeroen Massar" To: "'Michel Py'" , Subject: RE: I never thought about hijacking an IPv4 /8 Date: Sat, 26 Apr 2003 17:43:53 +0200 Organization: Unfix Message-Id: <000f01c30c0a$a4851fe0$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: <963621801C6D3E4A9CF454A1972AE8F504F7A5@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 h3QFnbhs007383 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: > But some people do.... > http://www.wiana.org/ > > Gee, I think I'm going to hijack an IPv6 /8 prefix too. What > could I do > with it? Let's see. Mmmmm. Provide globally unique addresses, maybe. I > wonder if these guys will let me have their scripts. Which is indeed something already which is available from some sites and nicely from sTLA space from some ISP's ;) Mucho better than plain default sitelocal crap. What is wrong though is indeed that these people hijacked it, one moment or the other one might think it's 'official' and start communicating using those addresses on the global internet. And then it's a real hijack. As long as they don't communicate with the rest of the world they can have as much fun as they want ;) >From their FAQ: 8<----------- Are the addresses routable? Yes, within the Wireless Internet, but not directly from the traditional wired internet. ----------->8 Hope they can uphold that.... it will imply NAT or other odd tricks to be able to access the rest of the world, ah well their problem :) 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 Sat Apr 26 09:44: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 h3QGiShs007818; Sat, 26 Apr 2003 09:44:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3QGiSIq007817; Sat, 26 Apr 2003 09:44:28 -0700 (PDT) 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 h3QGiPhs007810 for ; Sat, 26 Apr 2003 09:44:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3QGiBiX029796 for ; Sat, 26 Apr 2003 09:44:11 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3QGi4rZ008077 for ; Sat, 26 Apr 2003 09:44:04 -0700 (PDT) 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, 26 Apr 2003 16:43: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; Sat, 26 Apr 2003 16:43: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; Sat, 26 Apr 2003 16:43:54 Z Received: from lethargic.dyndns.org (lethargic.dyndns.org [216.254.160.56]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 26 Apr 2003 16:43:52 Z Received: from lethargic.dyndns.org (localhost [127.0.0.1]) by lethargic.dyndns.org (8.12.9/8.12.9) with ESMTP id h3QGgvlF098185; Sat, 26 Apr 2003 12:43:02 -0400 (EDT) (envelope-from leth@lethargic.dyndns.org) Received: (from leth@localhost) by lethargic.dyndns.org (8.12.9/8.12.9/Submit) id h3QGgu6D098184; Sat, 26 Apr 2003 12:42:56 -0400 (EDT) Date: Sat, 26 Apr 2003 12:42:55 -0400 From: Jason Hunt To: ipng@sunroof.eng.sun.com Cc: ietf@ietf.org, Keith Moore , Tony Hain Subject: Re: My thoughts on local-use addresses Message-Id: <20030426164255.GA98043@lethargic.dyndns.org> References: <20030426060420.GA93218@lethargic.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030426060420.GA93218@lethargic.dyndns.org> User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've done a bit more thinking regarding my previous post. I am going to restate the things that I suggested, in case my previous message left anything un-clear. I would like to suggest that: - The idea of scopes be removed from unicast addresses. Why add the complexity of scopes? Is it not better to keep things simple? - The link-local address space (FE80::/10), or some other space, be available as "private use" address space, similar to what RFC 1918 is to IPv4. I realize that the current definition of the local-use addresses already provides this, but since I am suggesting to change that definition it seemed necessary to make this point. - All interfaces be required to have at least one unicast address assigned to them, instead of being required to have a link-local address in addition to any other addresses. If an interface is not configured with an address, and the host is unable to obtain an address from a DHCP server (or some other dynamic configuration protocol) for that interface, then the interface will be auto- configured with an address from the above-mentioned "private use" space (FE80::/10 or otherwise). Can anyone point out any practical scenarios for scoped addresses to be required, which could not be dealt with by having a "private use" address space available? After reading the discussion on site-local addresses, I think that unicast address scopes may be un-necessary. If I happen to be mis-understanding something, I welcome any explanations or pointers to previous discussions. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 26 10:03: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 h3QH37hs008179; Sat, 26 Apr 2003 10:03:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3QH37uR008178; Sat, 26 Apr 2003 10:03:07 -0700 (PDT) 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 h3QH33hs008171 for ; Sat, 26 Apr 2003 10:03:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3QH39uc029773 for ; Sat, 26 Apr 2003 10:03:09 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA16466 for ; Sat, 26 Apr 2003 11:03:02 -0600 (MDT) 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; Sat, 26 Apr 2003 17:03: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; Sat, 26 Apr 2003 17:02:59 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, 26 Apr 2003 17:02:59 Z Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 26 Apr 2003 17:02:58 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 199T4g-0001ux-00; Sat, 26 Apr 2003 10:02:54 -0700 Date: Sat, 26 Apr 2003 13:02:11 -0400 From: Keith Moore To: Jason Hunt Cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com, ietf@ietf.org, alh-ietf@tndh.net Subject: Re: My thoughts on local-use addresses Message-Id: <20030426130211.321b0a4d.moore@cs.utk.edu> In-Reply-To: <20030426164255.GA98043@lethargic.dyndns.org> References: <20030426060420.GA93218@lethargic.dyndns.org> <20030426164255.GA98043@lethargic.dyndns.org> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jason, we need to get rid of site-locals. merely renaming them as private use addresses wouldn't solve any of their problems. there's no advantage to moving to IPv6 if it repeats the RFC 1918 mistake. Keith On Sat, 26 Apr 2003 12:42:55 -0400 Jason Hunt wrote: > I've done a bit more thinking regarding my previous post. I am going to > restate the things that I suggested, in case my previous message left > anything un-clear. > > I would like to suggest that: > > - The idea of scopes be removed from unicast addresses. Why add the > complexity of scopes? Is it not better to keep things simple? > > - The link-local address space (FE80::/10), or some other space, be > available as "private use" address space, similar to what RFC 1918 is > to IPv4. I realize that the current definition of the local-use > addresses already provides this, but since I am suggesting to change > that definition it seemed necessary to make this point. > > - All interfaces be required to have at least one unicast address > assigned to them, instead of being required to have a link-local > address in addition to any other addresses. If an interface is not > configured with an address, and the host is unable to obtain an > address from a DHCP server (or some other dynamic configuration > protocol) for that interface, then the interface will be auto- > configured with an address from the above-mentioned "private use" > space (FE80::/10 or otherwise). > > Can anyone point out any practical scenarios for scoped addresses to > be required, which could not be dealt with by having a "private use" > address space available? After reading the discussion on site-local > addresses, I think that unicast address scopes may be un-necessary. If > I happen to be mis-understanding something, I welcome any explanations > or pointers to previous discussions. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 26 10:31: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 h3QHVnhs008491; Sat, 26 Apr 2003 10:31:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3QHVnJ1008490; Sat, 26 Apr 2003 10:31:49 -0700 (PDT) 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 h3QHVkhs008483 for ; Sat, 26 Apr 2003 10:31:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3QHVnuc003858 for ; Sat, 26 Apr 2003 10:31:49 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA00844 for ; Sat, 26 Apr 2003 11:31:44 -0600 (MDT) 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, 26 Apr 2003 17:31: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; Sat, 26 Apr 2003 17:31:42 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, 26 Apr 2003 17:31:42 Z Received: from lethargic.dyndns.org ([216.254.160.56] [216.254.160.56]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 26 Apr 2003 17:31:41 Z Received: from lethargic.dyndns.org (localhost [127.0.0.1]) by lethargic.dyndns.org (8.12.9/8.12.9) with ESMTP id h3QHVTlF098348; Sat, 26 Apr 2003 13:31:30 -0400 (EDT) (envelope-from leth@lethargic.dyndns.org) Received: (from leth@localhost) by lethargic.dyndns.org (8.12.9/8.12.9/Submit) id h3QHVSID098347; Sat, 26 Apr 2003 13:31:28 -0400 (EDT) Date: Sat, 26 Apr 2003 13:31:27 -0400 From: Jason Hunt To: Keith Moore Cc: ipng@sunroof.eng.sun.com, ietf@ietf.org, alh-ietf@tndh.net Subject: Re: My thoughts on local-use addresses Message-Id: <20030426173127.GA98293@lethargic.dyndns.org> References: <20030426060420.GA93218@lethargic.dyndns.org> <20030426164255.GA98043@lethargic.dyndns.org> <20030426130211.321b0a4d.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030426130211.321b0a4d.moore@cs.utk.edu> User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Apr 26, 2003 at 01:02:11PM -0400, Keith Moore wrote: > we need to get rid of site-locals. merely renaming them as private use > addresses wouldn't solve any of their problems. there's no advantage to > moving to IPv6 if it repeats the RFC 1918 mistake. What is wrong with having addresses available for private use on networks that do not intend on being connected to the Internet? I suppose that if they are not going to be connected to the Internet, then really they could just use whatever space they feel like, since it should not affect any one else unless they do go to connect with other sites. Keith, do you have a draft or something you have been working on? For the most part I think that I do agree with your arguments against site-local addresses. What are your thoughts about link-local addresses? Do you want to get rid of all the local-use address space, which I suppose really means abandoning the idea of scoped addresses all together? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 26 10:36: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 h3QHaQhs008614; Sat, 26 Apr 2003 10:36:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3QHaQa2008613; Sat, 26 Apr 2003 10:36:26 -0700 (PDT) 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 h3QHaJhs008588 for ; Sat, 26 Apr 2003 10:36:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3QHaQuc004647 for ; Sat, 26 Apr 2003 10:36:26 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3QHaJrZ018720 for ; Sat, 26 Apr 2003 10:36:20 -0700 (PDT) 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, 26 Apr 2003 17:36: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; Sat, 26 Apr 2003 17:32: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; Sat, 26 Apr 2003 17:36:18 Z Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 26 Apr 2003 17:36:18 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 199Tav-00065R-00; Sat, 26 Apr 2003 10:36:13 -0700 Date: Sat, 26 Apr 2003 13:35:30 -0400 From: Keith Moore To: Jason Hunt Cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com, ietf@ietf.org, alh-ietf@tndh.net Subject: Re: My thoughts on local-use addresses Message-Id: <20030426133530.3e02b3ce.moore@cs.utk.edu> In-Reply-To: <20030426173127.GA98293@lethargic.dyndns.org> References: <20030426060420.GA93218@lethargic.dyndns.org> <20030426164255.GA98043@lethargic.dyndns.org> <20030426130211.321b0a4d.moore@cs.utk.edu> <20030426173127.GA98293@lethargic.dyndns.org> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) 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 Sat, 26 Apr 2003 13:31:27 -0400 Jason Hunt wrote: > On Sat, Apr 26, 2003 at 01:02:11PM -0400, Keith Moore wrote: > > we need to get rid of site-locals. merely renaming them as private use > > addresses wouldn't solve any of their problems. there's no advantage to > > moving to IPv6 if it repeats the RFC 1918 mistake. > > What is wrong with having addresses available for private use on > networks that do not intend on being connected to the Internet? in principle, nothing. but experience has shown that most of those networks do end up being connected to the Internet, while still keeping those addreses, and that applications are expected to cope with that. > What are your thoughts about link-local addresses? v6 link-locals are mostly harmless as long as they're only used for router discovery and similar things. applications should not use them. v4 link-locals have been touted as suitable for general-purpose use, and that's just wrong. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 26 10:54: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 h3QHsJhs009163; Sat, 26 Apr 2003 10:54:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3QHsJ4F009162; Sat, 26 Apr 2003 10:54:19 -0700 (PDT) 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 h3QHsFhs009155 for ; Sat, 26 Apr 2003 10:54:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3QHsHiX009440 for ; Sat, 26 Apr 2003 10:54:18 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id LAA27832 for ; Sat, 26 Apr 2003 11:54:09 -0600 (MDT) 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, 26 Apr 2003 17:54: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; Sat, 26 Apr 2003 17:54: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; Sat, 26 Apr 2003 17:54:06 Z Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 26 Apr 2003 17:54:06 Z Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 199Ts7-00021l-00; Sat, 26 Apr 2003 10:53:59 -0700 Date: Sat, 26 Apr 2003 13:53:16 -0400 From: Keith Moore To: james woodyatt Cc: moore@cs.utk.edu, alh-ietf@tndh.net, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A follow up question Message-Id: <20030426135316.14b14fe7.moore@cs.utk.edu> In-Reply-To: References: <042901c30a9b$757ed1c0$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Applications have bad habits. > > They cache network addresses when they should be caching names. nice theory. the fact is that names are imprecise; they're not always bound to what we think they're bound to, there's no way to tell what they're bound to, and the bindings are subject to change. and DNS in particular can be slow and unreliable. in short- you can lose by storing names in your application just as easily as you can lose by storing IP addresses in your application. anytime you do either one, you're making assumptions about the bindings of those names or addresses with hosts that are subject to change, often by factors outside your control. 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 Sat Apr 26 11:43: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 h3QIhOhs009564; Sat, 26 Apr 2003 11:43:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3QIhOlQ009563; Sat, 26 Apr 2003 11:43:24 -0700 (PDT) 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 h3QIhLhs009556 for ; Sat, 26 Apr 2003 11:43:21 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3QIhMiX015433 for ; Sat, 26 Apr 2003 11:43:23 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3QIhHrZ001780 for ; Sat, 26 Apr 2003 11:43:17 -0700 (PDT) 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, 26 Apr 2003 18:43: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; Sat, 26 Apr 2003 18:39: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; Sat, 26 Apr 2003 18:43:13 Z Received: from SERVER2000.arneill-py.sacramento.ca.us ([209.233.126.65] [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 26 Apr 2003 18:43:12 Z Content-class: urn:content-classes:message Subject: RE: I never thought about hijacking an IPv4 /8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 26 Apr 2003 11:43:11 -0700 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F7A7@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 never thought about hijacking an IPv4 /8 Thread-Index: AcMMCqsY585pdohrRq+dOWQfl0OZwAAFjYnw From: "Michel Py" To: "Jeroen Massar" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3QIhLhs009557 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeroen, > Jeroen Massar wrote: > What is wrong though is indeed that these people hijacked > it, one moment or the other one might think it's 'official' > and start communicating using those addresses on the global > internet. And then it's a real hijack. And this will happen and we know it. In their situation, the risk of leak of these addresses in the DFZ is low, as 1.0.0.0 /8 is indeed in the bogon list and enough people actually filter bogons. But for IPv6 it would be easier. Tomorrow I could create the MIANA (the Michel Internet Assigned Numbers Authority) (c) (tm), hijack a big block and begin to distribute mhhhmmm let's see, what about globally unique private IPv6 addresses. > Hope they can uphold that.... it will imply NAT or other > odd tricks to be able to access the rest of the world, > ah well their problem :) For IPv4 I don't see where the problem would be. RFC1918 addresses are not the only ones you can NAT... Ah what a wonderful world. 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 Sat Apr 26 18:05: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 h3R15vhs010460; Sat, 26 Apr 2003 18:05:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3R15vjq010459; Sat, 26 Apr 2003 18:05:57 -0700 (PDT) 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 h3R15rhs010452 for ; Sat, 26 Apr 2003 18:05:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3R15uuc029937 for ; Sat, 26 Apr 2003 18:06:00 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id TAA03206 for ; Sat, 26 Apr 2003 19:05:49 -0600 (MDT) 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, 27 Apr 2003 01:05: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; Sun, 27 Apr 2003 01:05: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; Sun, 27 Apr 2003 01:05:44 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; Sun, 27 Apr 2003 01:05:43 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id B71DA8D95; Sun, 27 Apr 2003 03:05:39 +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 3BB7F8A24; Sun, 27 Apr 2003 03:05:22 +0200 (CEST) From: "Jeroen Massar" To: "'Michel Py'" , Subject: RE: I never thought about hijacking an IPv4 /8 Date: Sun, 27 Apr 2003 03:05:22 +0200 Organization: Unfix Message-Id: <000701c30c59$15b71ad0$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.1165 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F7A7@server2000.arneill-py.sacramento.ca.us> 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 h3R15shs010453 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py [mailto:michel@arneill-py.sacramento.ca.us] wrote: > Jeroen, > > > Jeroen Massar wrote: > > What is wrong though is indeed that these people hijacked > > it, one moment or the other one might think it's 'official' > > and start communicating using those addresses on the global > > internet. And then it's a real hijack. > > And this will happen and we know it. In their situation, the risk of > leak of these addresses in the DFZ is low, as 1.0.0.0 /8 is indeed in > the bogon list and enough people actually filter bogons. But > for IPv6 it would be easier. Tomorrow I could create the MIANA (the > Michel Internet Assigned Numbers Authority) (c) (tm), hijack a big block and begin to > distribute mhhhmmm let's see, what about globally unique private IPv6 > addresses. Welcome to the Inter.Michel.Net, I wonder if such a thing could hit off then again, seeing the altroot dns servers aren't really hitting anywhere either, hmm... but 6bone is quite a success and kinda is an 'alternative' registry too. Seeing the fact that many ISP's don't have any filtering at all in IPv6, until some 'loathed' corp like tries to do some real work, next to that the fact that they are quite unreachable through the normal email channels, even though those are the given contacts or respond once and then let it rest for ever, I foresee some bad stuff happening in the future ;( > > Hope they can uphold that.... it will imply NAT or other > > odd tricks to be able to access the rest of the world, > > ah well their problem :) > > For IPv4 I don't see where the problem would be. RFC1918 addresses are > not the only ones you can NAT... > > Ah what a wonderful world. For some other, totally unrelated, reason I tend to agree quite hard :) 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 Apr 27 03:14: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 h3RAElhs011331; Sun, 27 Apr 2003 03:14:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3RAEl3P011330; Sun, 27 Apr 2003 03:14:47 -0700 (PDT) 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 h3RAEihs011323 for ; Sun, 27 Apr 2003 03:14:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3RAEoKw011969 for ; Sun, 27 Apr 2003 03:14:50 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3RAEfrZ004785 for ; Sun, 27 Apr 2003 03:14:43 -0700 (PDT) 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, 27 Apr 2003 09:55:03 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, 27 Apr 2003 09:55: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, 27 Apr 2003 09:55:03 Z Received: from panoramix.noc.ams-ix.net (panoramix.noc.ams-ix.net [193.194.136.132]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 27 Apr 2003 09:55:01 Z Received: from localhost (localhost [127.0.0.1]) by panoramix.noc.ams-ix.net (Postfix) with ESMTP id 0E39791FB; Sun, 27 Apr 2003 11:54:43 +0200 (MEST) Received: from [192.168.0.248] (plumb.xs4all.nl [213.84.188.208]) by panoramix.noc.ams-ix.net (Postfix) with ESMTP id DC34C91E3; Sun, 27 Apr 2003 11:54:41 +0200 (MEST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 27 Apr 2003 11:54:39 +0200 Subject: Re: My thoughts on local-use addresses From: Arien Vijn To: Keith Moore Cc: ipng , , Message-Id: In-Reply-To: <20030426133530.3e02b3ce.moore@cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS snapshot-20020300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 26-04-2003 19:35PM, "Keith Moore" wrote: >> What is wrong with having addresses available for private use on >> networks that do not intend on being connected to the Internet? > > in principle, nothing. but experience has shown that most of those networks > do end up being connected to the Internet, while still keeping those addreses, > and that applications are expected to cope with that. Ehm... What experience? You are referring to experiences with RFC1918 addresses in the IPv4-world, aren't you? But... Do you or anybody already have have similar experiences with regards to site-locals? Indeed, RFC1918 addresses are frequently used behind NAT-boxes. And these NAT-boxes do create all kinds of troubles. That is the main problem isn't it? For that matter will it be the same with regards to IPv6 site-locals? I think not. Because the most important reason for NAT is the lack of available IPv4 address space. I know there are more reasons why people use NAT. But this is by far the most important one. Because for many many end-users and small companies, it is very hard, if not impossible or at least expensive to get more than one IPv4 address. This is not the case in IPv6. ISPs typically provide their customers with a /48 of globally unique address space... Well, my home-ISP does. Do you really think I thought one minute of NATing IPv6? In other words: NAT makes networking complex, it breaks the end-to-end model, creates unwanted site-effects and it is not really needed with enough available address space. Therefore I do not think that site-locals will be used in the same fashion as RFC1918 addresses are mostly used today. Having said that, NAT might be a quick and dirty hack to satisfy the needs for: - address stability, due to the lack of easy renumbering; - multihoming; - (obscurity). Especially renumbering-issues might also be a reason for using NAT nowadays. Just because renumbering is too much pain in IPv4. Somehow addresses have to be configured at many different places. Implementers might be more thoughtful with regards to IPv6. Ironically, multihoming is typically a requirement of non-NAT users nowadays. They might become the new NAT-adepts if the market comes with means to do it via NAT and there is no good alternative. Obscurity (some seem to call it security) is just an implementation matter as well. Really don't want to discuss this. In any case, I do not think that deprecating site-locals will take away the NAT-threat. Neither does it bring us closer to alternatives. At least site-locals are easily recognisable so coping with becomes a possibility. Arien -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 27 05:44: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 h3RCiths012428; Sun, 27 Apr 2003 05:44:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3RCitSG012427; Sun, 27 Apr 2003 05:44:55 -0700 (PDT) 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 h3RCiphs012420 for ; Sun, 27 Apr 2003 05:44:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3RCiwuc003496 for ; Sun, 27 Apr 2003 05:44:58 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id GAA29718 for ; Sun, 27 Apr 2003 06:44:52 -0600 (MDT) 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, 27 Apr 2003 12:44:52 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, 27 Apr 2003 12:44: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, 27 Apr 2003 12:44:52 Z Received: from fuchsia.home ([203.146.155.23] [203.146.155.23]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 27 Apr 2003 12:44:49 Z Received: from delta.cs.mu.OZ.AU (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id h3RChPej020513; Sun, 27 Apr 2003 19:43:26 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3RCeDq23091; Sun, 27 Apr 2003 19:40:15 +0700 (ICT) From: Robert Elz To: Keith Moore cc: ipng@sunroof.eng.sun.com Subject: Re: Architectural Considerations section in specs In-Reply-To: <20030423193413.5d7c86bb.moore@cs.utk.edu> References: <20030423193413.5d7c86bb.moore@cs.utk.edu> <70125434335.20030419164712@brandenburg.com> <033901c309a9$45d0f130$261e4104@eagleswings> <20030423175937.3b28f432.moore@cs.utk.edu> <002701c309ef$5c64ced0$93b58742@ssprunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 27 Apr 2003 19:40:13 +0700 Message-Id: <23089.1051447213@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 23 Apr 2003 19:34:13 -0400 From: Keith Moore Message-ID: <20030423193413.5d7c86bb.moore@cs.utk.edu> [ietf list deleted, there's been way too much of this discussion there already]. | the property that I'm concerned about is not that an address | may only be usable within a particular portion of the network, it's | that the address is ambiguous. We have had ambiguous addresses since forever. Site locals don't cause that, they merely make it more obvious - that is, your application can trivially avoid using it if it wants to. Think back, way before IPv4 addresses became scarce, and remember all the sites that numbered their network using the 192.9.200 block. Aside from ignorance (which we have no good reason to believe has gone away anyway) people did that because they wanted an address immediately: "I'm just setting up this network, and I see I have to tell it an address to use, and no, I am not waiting until tomorrow, or even an hour, until someone tells me what to use." Assuming that I don't care about global routing (right now anyway), an address (prefix) is just a number, any number will work, so I will simply pick the first number that comes to hand - and something that is printed as an example in some documentation is an easy choice, and I'll just use that. So will many others. Later I'll connect, but unless there's some very good reason to do so, I'll just add the global prefix my ISP tells me to use, and keep the one I invented for myself. Ambiguous addresses - and no way at all for the app to tell, so no way to possibly make things work. Of course, "that's the network's problem, not the applications", right? Nonsense. Finger pointing doesn't help, we know this is going to happen. When you can foresee something, and deliberately ignore it, and harm results, you get the blame, and rightly. One use of site local addresses is to be that well known ambiguous address. One that anyone can simply take and use. Personally, I'd prefer unique addresses - and sticking a unique number in the upper 32 of the "spare" 38 bits (or something like that) in SL addresses would be just fine. Unique SL addresses, or the NUSLA proposal from a couple of years ago, are just fine - they're still SL addressesm unique or not. But for that to have a hope of working, that unique number has to be available, instantly, at no cost, anytime, from anywhere (even the cost of a phone call is too much, not the $0.25 so much, but the time it takes to discover the number, get to someone at the other end who can help, ...) If the allocation method doesn't meet those criteria, people will ignore it. The only method I know of which works is "well known prefix" (onto which a random number can be appended if you like). Know another? | so given an address there's no way to | know whether or not it is valid, If you're concerned, and it might not be valid, and you have a choice, then just don't use it. What's so hard about that, aside from the "might not be valid" test sometimes. If the doubtful address is site-local, even that is easy. Of course, if there is no other address (no other address type), then you have no choice - and it either works or doesn't. | wrong. it's useful to have unique names for hosts (or points on the | network) even if they're not directly reachable by everyone who might | possess those names. Well, if you believe other stuff that this WG won't let go of, then if even a SL address has the 'u' bit set, it is of global scope, and so perfectly useful as a unique name, if that's all you require of it. Even a LL address (even more likely to have 'u' set) would do for this. But wanting a unique name (which isn't a name, but an address anyway) is no argument for doing away with SLs, even assuming that they're not unique, one way or another. It is an argument for all hosts having global addresses, which is just fine - that's how I'd like it to be as much as possible. But having a global addr is no reason for not also having a SL addr. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Apr 27 07:27: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 h3RERqhs013157; Sun, 27 Apr 2003 07:27:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3RERq1n013156; Sun, 27 Apr 2003 07:27:52 -0700 (PDT) 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 h3RERmhs013148 for ; Sun, 27 Apr 2003 07:27:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3RERtuc015040 for ; Sun, 27 Apr 2003 07:27:55 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id IAA24611 for ; Sun, 27 Apr 2003 08:27:49 -0600 (MDT) 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, 27 Apr 2003 14:27:48 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP; Sun, 27 Apr 2003 14:27:48 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP; Sun, 27 Apr 2003 14:27:48 Z Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by relay2.sun.com with ESMTP; Sun, 27 Apr 2003 14:27:47 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3REQeCi046688; Sun, 27 Apr 2003 16:26:41 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h3REQdtl246894; Sun, 27 Apr 2003 16:26:40 +0200 Received: from gsine03.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA14756 from ; Sun, 27 Apr 2003 16:26:22 +0200 Message-Id: <3EABE44D.1966A69A@hursley.ibm.com> Date: Sun, 27 Apr 2003 16:08:13 +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: Alain Durand Cc: john.loughney@nokia.com, dcrocker@brandenburg.com, ietf@ietf.org, ipng@sunroof.eng.sun.com, john-ietf@jck.com Subject: Re: TCPng/ multiple addresses per node (was Re: A follow up question)_ References: <3EA9C23B.80705@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk below... Alain Durand wrote: > > john.loughney@nokia.com wrote: > > >Hi Alain, > > > >I agree with your intro (which I clipped to save space), > > > Thank you! > > > one > >comment that I have is: > > > > > > > >>There is a proposal to create an API to enable the > >>application creating the socket to specify some of the > >>properties that it desires/requires. This is a step in the right > >>direction, but I'm not convinced this can go far enough. > >>So I fully support this idea of lifting the ban on TCPng > >>(or any transport layer for that matter) to de-couple > >>the abstraction needed by applications to the one required > >>by the network. This is in fact introducing some of the semantic > >>of a session layer between the application and the network. > >>Can this be done at the transport layer in the form of TCPng > >>or does this require and actual additional session layer? > >>I'm not sure at this point in time. > >> > >> > > > >There already something like this, I'm sure you know - SCTP. > >I'm actually not trying to promote SCTP, but it might be interesting, > >as we have an RFC that does most of the avove, to look at it > >critically & see how it performs. > > > >SCTP, as a background, uses sets of addresses/ports to identify a > >node. In the usual case, one node will pass all of its addresses(& ports) > >to its peer & the peer returns its addresses (&ports) for SCTP > >traffic. The application has the the option to choose the primary > >address to be used. > > > SCTP does not specify how the 'primary' source & destination are chosen, > nor does it explain how to order those lists once it decides to try > another pair. > > Two possible ways to do that could be: > - use knowledge of the topology, that is pass some of the > routing information to the end nodes. > - use dynamic measurements.. For example start the connection > using the initial src & dst, and then send regular probes > (duplicates?) using > the other combinations to do measurements and keep statistics. > > On top of that you might want to add social/economic information > known by the end points, like this interface is cheap vs expensive > at this particular moment. Similar information for other links > within the network would be valuable but much more difficult > to collect! > > Also, there is still a need to enable the application > to specify the desired/required properties of the addresses, > like use temporary vs use stable address, use home address vs > care-of-address,... > > SCTP does not do any of that. SCTP was designed for a specific context, telphony signalling, where there are many intrinsic constraints and the alternative addresses will probably be explicitly managed as part of the applications environment. That's much easier than trying to solve these problems for the general case. In general, middleware designers simply don't want to know about such issues, however sophisticated an API they are offered. Before we go down this path, we would need a deep analysis jointly with the middleware community, otherwise it will all be in vain. 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 Sun Apr 27 17:21: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 h3S0LOhs014524; Sun, 27 Apr 2003 17:21:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3S0LOxT014523; Sun, 27 Apr 2003 17:21:24 -0700 (PDT) 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 h3S0LKhs014516 for ; Sun, 27 Apr 2003 17:21:21 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3S0LRKw022285 for ; Sun, 27 Apr 2003 17:21:27 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id SAA04384 for ; Sun, 27 Apr 2003 18:21:18 -0600 (MDT) 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, 28 Apr 2003 00:21:07 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, 28 Apr 2003 00:21: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; Mon, 28 Apr 2003 00:21:05 Z Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 00:21:03 Z Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Sun, 27 Apr 2003 17:20:36 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 27 Apr 2003 17:20:35 -0700 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 27 Apr 2003 17:20:35 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 27 Apr 2003 17:20:35 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 27 Apr 2003 17:20:34 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Sun, 27 Apr 2003 17:20:34 -0700 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="iso-8859-1" Subject: RE: Operational Renumbering Procedure Date: Sun, 27 Apr 2003 17:20:34 -0700 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operational Renumbering Procedure Thread-Index: AcMLubpA675kOk4fQiCS4/07JDFbwQBXn4Xy From: "Christian Huitema" To: "Pekka Savola" , "Fred Baker" Cc: X-OriginalArrivalTime: 28 Apr 2003 00:20:34.0616 (UTC) FILETIME=[FC637380:01C30D1B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3S0LLhs014517 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, Pekka points out one issue with the "stable with two addresses" phase. At that point, the network is in effect multihomed, and the two-address phase is only stable if we know how to handle well multi-homed sites. You don't discuss this in your draft, and in truth it would be conceivable to renumber a site just for the fun of it, without changing ISP. However, the practical case is that the site moves from "stable with one address from ISP A" to "multihomed to ISP A and ISP B" to "stable with one address from ISP B". Previous discussions of multi-homing have shown that to do that we must at a minimum handle "ingress filtering" issues. Suppose that in the dual-home site a host configures an address from ISP B's prefix, send a packet to a 3rd party P, and that the routing tables are such that traffic to B is routed through ISP A. If ISP A performs ingress filtering, it will reject the packets whose source addresses don't match the site prefix as know by A -- i.e. it will reject the packets sent by hosts constructing an address with ISP B's prefix. There are some possible simplifications. For example, for a site of any significant size, the second ISP who just won a contract for the site is likely to cooperate, e.g. by not performing ingress filtering, at least during the transition. But your draft ought to discuss these issues. -- 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 Sun Apr 27 17:28:06 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 h3S0S6hs014884; Sun, 27 Apr 2003 17:28:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3S0S6rf014883; Sun, 27 Apr 2003 17:28:06 -0700 (PDT) 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 h3S0S0hs014863 for ; Sun, 27 Apr 2003 17:28:00 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3S0S6Kw023610 for ; Sun, 27 Apr 2003 17:28:07 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA01885 for ; Sun, 27 Apr 2003 18:28:01 -0600 (MDT) 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, 28 Apr 2003 00:27: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; Mon, 28 Apr 2003 00: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; Mon, 28 Apr 2003 00:27:58 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, 28 Apr 2003 00:27:57 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA05891; Sun, 27 Apr 2003 17:27:10 -0700 (PDT) Message-Id: <5.1.0.14.2.20030427201509.033c6d68@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 27 Apr 2003 20:17:55 -0400 To: Dave Crocker From: Margaret Wasserman Subject: Re: A simple question Cc: "Tony Hain" , ipng@sunroof.eng.sun.com, ietf@ietf.org In-Reply-To: <036939506.20030418161216@brandenburg.com> References: <001a01c305f7$a902cd60$261e4104@eagleswings> <001a01c305f7$a902cd60$261e4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Dave, At 04:12 PM 4/18/2003 -0700, Dave Crocker wrote: >please point us to some text that gives a clear and complete discussion >of the benefits that accrue from this new feature, as well as a fair >consideration of its difficulties. I wrote such a document. It can be found at: http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.txt This is a personal draft, not a work item of the IPv6 WG. 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 Apr 27 17:28: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 h3S0SBhs014896; Sun, 27 Apr 2003 17:28:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3S0SBdL014895; Sun, 27 Apr 2003 17:28:11 -0700 (PDT) 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 h3S0S3hs014876 for ; Sun, 27 Apr 2003 17:28:03 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3S0SAKw023614 for ; Sun, 27 Apr 2003 17:28:10 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA01909 for ; Sun, 27 Apr 2003 18:28:05 -0600 (MDT) 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, 28 Apr 2003 00:28:03 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, 28 Apr 2003 00:28: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; Mon, 28 Apr 2003 00:28:03 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, 28 Apr 2003 00:28:02 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA05894; Sun, 27 Apr 2003 17:27:12 -0700 (PDT) Message-Id: <5.1.0.14.2.20030427201951.03184c10@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 27 Apr 2003 20:21:50 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: A simple question Cc: Keith Moore , dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org In-Reply-To: <14384.1050784134@munnari.OZ.AU> References: <20030419151329.66daf0de.moore@cs.utk.edu> <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:28 AM 4/20/2003 +0700, Robert Elz wrote: > Date: Sat, 19 Apr 2003 15:13:29 -0400 > From: Keith Moore > Message-ID: <20030419151329.66daf0de.moore@cs.utk.edu> > > | > No, it isn't. It is a cleaned up replacement for 1918 addresses. > | which by itself is reason enough to kill it. > >Nothing of the kind. 1918 addresses were created because there was >demonstrated demand for stable local use only addressing. Nothing >has changed in the Internet to cause that demand to go away. > >We either provide a mechanism, or the users provide one of their own. As John Klensin pointed out on this same list several weeks ago (and I'm sure he said it better than I will), the decision to use ambiguous local addressing in IPv4 (i.e. RFC 1918 addresses) was partially motivated by the desire to conserve IPv4 address space. In IPv6, we don't have an address space shortage, so there is no reason to introduce architectural complexity to conserve address space. 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 Apr 27 17:38: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 h3S0cchs015704; Sun, 27 Apr 2003 17:38:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3S0cc7m015703; Sun, 27 Apr 2003 17:38:38 -0700 (PDT) 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 h3S0cZhs015696 for ; Sun, 27 Apr 2003 17:38:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3S0cfuc020152 for ; Sun, 27 Apr 2003 17:38:41 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id SAA02457 for ; Sun, 27 Apr 2003 18:38:33 -0600 (MDT) 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, 28 Apr 2003 00:38: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; Mon, 28 Apr 2003 00:38: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, 28 Apr 2003 00:38:21 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, 28 Apr 2003 00:38:20 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA08509; Sun, 27 Apr 2003 17:37:02 -0700 (PDT) Message-Id: <5.1.0.14.2.20030427202610.03410518@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 27 Apr 2003 20:32:06 -0400 To: Keith Moore From: Margaret Wasserman Subject: Re: A simple question Cc: Daniel Senie , moore@cs.utk.edu, stephen@sprunk.org, ietf@ietf.org, ipng@sunroof.eng.sun.com In-Reply-To: <20030419191507.75dfcc39.moore@cs.utk.edu> References: <5.2.1.1.2.20030419181122.0290c090@mail.amaranth.net> <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14384.1050784134@munnari.OZ.AU> <20030419165921.782a8353.moore@cs.utk.edu> <5.2.1.1.2.20030419181122.0290c090@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 07:15 PM 4/19/2003 -0400, Keith Moore wrote: >it is indeed unfortunate that it took several years before there was serious >consideration to the impact of site-local on networks, DNS, and applications. >I view this as an indication of serious failures in our process - IPv6 was >approved (under pressure, it must be said) by the working group and IESG >despite serious technical omissions. fortunately proposed standards are not >carved in stone, and these particular omissions are easy to fix. There is currently no RFC that defines the usage model for IPv6 site-local addressing. The prefix is defined in the addressing architecture RFC (currently at PS), but the usage model is defined in the scoped addressing architecture (a WG I-D). This I-D has been relatively stable for a couple of years, but has not gone to the IESG, mostly due to IPv6 WG deadlock over the architectural issues regarding site-local addressing. During that time, we have been slowly working through the various architectural issues caused by site-local addressing, and building WG consensus regarding what to do about it. So, I think that this is actually a case of the WG process working properly (if a bit too slowly). 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 Apr 27 19:22: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 h3S2MThs016230; Sun, 27 Apr 2003 19:22:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3S2MT3t016229; Sun, 27 Apr 2003 19:22:29 -0700 (PDT) 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 h3S2MPhs016222 for ; Sun, 27 Apr 2003 19:22:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3S2MWuc002324 for ; Sun, 27 Apr 2003 19:22:32 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id TAA09414 for ; Sun, 27 Apr 2003 19:22:26 -0700 (PDT) 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, 28 Apr 2003 02:22: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; Mon, 28 Apr 2003 02:18: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; Mon, 28 Apr 2003 02:22:22 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; Mon, 28 Apr 2003 02:22:21 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA06652; Sun, 27 Apr 2003 19:21:08 -0700 (PDT) Message-Id: <5.1.0.14.2.20030427221502.033f2b38@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 27 Apr 2003 22:19:14 -0400 To: Tim Chown From: Margaret Wasserman Subject: WG Chair in the House? (Re: A follow up question) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20030424223635.GB6776@login.ecs.soton.ac.uk> References: <3EA86490.8060501@cisco.com> <044201c30aad$00df25b0$261e4104@eagleswings> <3EA86490.8060501@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tim, [I dropped the IETF list, as I think you were talking about the IPv6 list.] At 11:36 PM 4/24/2003 +0100, Tim Chown wrote: >Is there a WG chair in the house? Actually, on the 24th, there was no WG chair in the house. Bob and I were both on vacations last week that overlapped on Wednesday through Friday. That aside, though, do you have suggestions for how we should temper the discussion on the IPv6 list (which has lately been lopping over onto the IETF list). On occasion, we have written to frequent posters privately and we have asked them to reduce their volume, change their tone and/or stop repeating their arguments. This usually works for a while... Can you think of anything else that we could that is consistent with the IETF values of openness and fairness? Thanks, 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 Apr 27 19:38:53 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 h3S2cqhs016542; Sun, 27 Apr 2003 19:38:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3S2cqN7016541; Sun, 27 Apr 2003 19:38:52 -0700 (PDT) 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 h3S2cnhs016534 for ; Sun, 27 Apr 2003 19:38:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3S2ctKw015581 for ; Sun, 27 Apr 2003 19:38:56 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id UAA12513 for ; Sun, 27 Apr 2003 20:38:50 -0600 (MDT) 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, 28 Apr 2003 02:38: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; Mon, 28 Apr 2003 02:34: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; Mon, 28 Apr 2003 02:38:47 Z Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 02:38:46 Z Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id D7601137F09; Sun, 27 Apr 2003 19:38:41 -0700 (PDT) Date: Sun, 27 Apr 2003 19:38:37 -0700 Subject: Re: A simple question Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Robert Elz , Keith Moore , dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org To: Margaret Wasserman From: David Conrad In-Reply-To: <5.1.0.14.2.20030427201951.03184c10@mail.windriver.com> Message-Id: <83D73C86-7922-11D7-A953-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, On Sunday, April 27, 2003, at 05:21 PM, Margaret Wasserman wrote: > As John Klensin pointed out on this same list several weeks ago > (and I'm sure he said it better than I will), the decision to > use ambiguous local addressing in IPv4 (i.e. RFC 1918 addresses) > was partially motivated by the desire to conserve IPv4 address > space. Yes. Of course, there were and are other reasons, the most significant of which is in conjunction with the use of NAT to provide some level of provider independence (both in terms of avoiding the necessity to renumber when changing providers as well as not having to "purchase" additional IP addresses from the service provider). > In IPv6, we don't have an address space shortage, so there > is no reason to introduce architectural complexity to conserve > address space. While it is true that address conservation isn't that significant an issue, the whole issue of provider independence (or lack thereof) continues to exist. Continuing to ignore this fundamental requirement on the part of enterprise network operators is getting us no where. It certainly isn't getting us to IPv6 deployment. 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 Sun Apr 27 21:04:30 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 h3S44Ths016985; Sun, 27 Apr 2003 21:04:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3S44TMI016984; Sun, 27 Apr 2003 21:04:29 -0700 (PDT) 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 h3S44Qhs016977 for ; Sun, 27 Apr 2003 21:04:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3S44Wuc015080 for ; Sun, 27 Apr 2003 21:04:32 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id WAA12941 for ; Sun, 27 Apr 2003 22:04:27 -0600 (MDT) 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, 28 Apr 2003 04:04:25 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, 28 Apr 2003 04:04:25 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, 28 Apr 2003 04:04:24 Z Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 04:04:24 Z Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3S42EEL017291; Sun, 27 Apr 2003 21:04:10 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGN14699; Sun, 27 Apr 2003 20:58:17 -0700 (PDT) Message-Id: <5.2.0.9.2.20030427203349.058defa8@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 27 Apr 2003 20:48:41 -0700 To: "Christian Huitema" From: Fred Baker Subject: RE: Operational Renumbering Procedure Cc: "Pekka Savola" , 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 At 05:20 PM 4/27/2003 -0700, Christian Huitema wrote: >Pekka points out one issue with the "stable with two addresses" phase. At >that point, the network is in effect multihomed, and the two-address >phase is only stable if we know how to handle well multi-homed sites. I'm not quite sure I agree, given a network administration with a clue. But maybe this document is for those who lack a clue... It has two prefixes, yes, but his concern is still with a single ISP and presumably a single router in front of the (presumably enterprise) network. Hence, it is single-homed using multiple prefixes. His presupposition is that folks would be attempting to use the new prefix to send traffic into the network. If they do, I'll argue that something isn't as specified; that shouldn't happen until the next step, when the new prefix becomes the preferred prefix in RFC 2462-speak (and therefore might be used as a source address), and DNS is advised of the new set of addresses (and therefore the new prefix might be used as a destination address to a server). But apart from that, he is assuming that the ISP is filtering traffic coming from the network using the second prefix because it fails an RPF check - there is no route to that address, or the route faces into the ISP. Alternativeively, his words referred to RFC 2827, which suggests that traffic arriving from the enterprise network should be compared to a source address access list which permits traffic from the enterprises assigned prefix(es) and denies all other. I would argue that an enterprise legitimately using any prefix with any ISP, whether it is one or many, is responsible to tell the ISP it is doing so. The ISP might not be contracted to accept the route or to route to that prefix, but it should not be filtering out traffic using it. > You don't discuss this in your draft So I think you're suggesting that section 3 become section 3.1, enveloped in a section 3 entitled "how not to shoot one-self in the foot". Section 3.2, entitled "managing routing and ingress filtering issues" says "if you expect routing and filtering to work through your ISP, you should tell him what prefixes you are using". Close? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 27 22:25: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 h3S5Pohs017469; Sun, 27 Apr 2003 22:25:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3S5Pn9H017468; Sun, 27 Apr 2003 22:25:49 -0700 (PDT) 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 h3S5Pkhs017461 for ; Sun, 27 Apr 2003 22:25:46 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3S5PrKw009975 for ; Sun, 27 Apr 2003 22:25:53 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3S5PjrZ018947 for ; Sun, 27 Apr 2003 22:25:45 -0700 (PDT) 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, 28 Apr 2003 05:25: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; Mon, 28 Apr 2003 05:21: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; Mon, 28 Apr 2003 05:25:41 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; Mon, 28 Apr 2003 05:25:40 Z Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h3S5OqA04605; Sun, 27 Apr 2003 22:24:52 -0700 (PDT) From: Bill Manning Message-Id: <200304280524.h3S5OqA04605@boreas.isi.edu> Subject: Re: A simple question In-Reply-To: <5.1.0.14.2.20030427201951.03184c10@mail.windriver.com> from Margaret Wasserman at "Apr 27, 3 08:21:50 pm" To: mrw@windriver.com (Margaret Wasserman) Date: Sun, 27 Apr 2003 22:24:52 -0700 (PDT) Cc: kre@munnari.oz.au, moore@cs.utk.edu, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com, ietf@ietf.org 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 John Klensin pointed out on this same list several weeks ago % (and I'm sure he said it better than I will), the decision to % use ambiguous local addressing in IPv4 (i.e. RFC 1918 addresses) % was partially motivated by the desire to conserve IPv4 address % space. In IPv6, we don't have an address space shortage, so there % is no reason to introduce architectural complexity to conserve % address space. % % Margaret "dont' have an address space shortage..." - Margaret -YET- IPv4 didn't have one either, in its early days. --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 Mon Apr 28 02:01:18 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 h3S91Ihs018549; Mon, 28 Apr 2003 02:01:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3S91IaQ018548; Mon, 28 Apr 2003 02:01:18 -0700 (PDT) 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 h3S91Ehs018541 for ; Mon, 28 Apr 2003 02:01:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3S91Luc000289 for ; Mon, 28 Apr 2003 02:01:21 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA12584 for ; Mon, 28 Apr 2003 03:01:15 -0600 (MDT) 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, 28 Apr 2003 09:01: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, 28 Apr 2003 09:01: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; Mon, 28 Apr 2003 09:01:14 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 09:01:12 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3S90qJ08859; Mon, 28 Apr 2003 12:00:52 +0300 Date: Mon, 28 Apr 2003 12:00:51 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: Christian Huitema , Subject: RE: Operational Renumbering Procedure In-Reply-To: <5.2.0.9.2.20030427203349.058defa8@mira-sjc5-b.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 Sun, 27 Apr 2003, Fred Baker wrote: > At 05:20 PM 4/27/2003 -0700, Christian Huitema wrote: > >Pekka points out one issue with the "stable with two addresses" phase. At > >that point, the network is in effect multihomed, and the two-address > >phase is only stable if we know how to handle well multi-homed sites. > > I'm not quite sure I agree, given a network administration with a clue. But > maybe this document is for those who lack a clue... > > It has two prefixes, yes, but his concern is still with a single ISP and > presumably a single router in front of the (presumably enterprise) network. > Hence, it is single-homed using multiple prefixes. You missed the point. The example was simplified on purpose. But this shows that different people seem to have different expectations wrt. renumbering -- so this discussion is very worthwhile. My view is that people will not renumber to any interesting degree unless they're also changing ISP's (stuff like migrating from 6BONE address space to one obtained from RIR's is semi-exception, but it is not interesting yet either). It just isn't fun enough to warrant it. You may be assuming that "within an ISP" renumbering is interesting (and focus of the memo), and the document seems to be implicitly assuming that. That's ok -- if that's what you want to describe -- but the applicability must be spelled out. Because there is a subset of problems which may be very difficult to solve if you can't assume that. > His presupposition is that folks would be attempting to use the new > prefix to send traffic into the network. If they do, I'll argue that > something isn't as specified; that shouldn't happen until the next step, > when the new prefix becomes the preferred prefix in RFC 2462-speak (and > therefore might be used as a source address), This is a bit different ordering of events as one would suppose. To make that work, you'd have to advertise prefixes with preferred_lifetime=0 and have the hosts configure them as deprecated. I'm not sure if that'd work, and whether there might be similar other issues. You also can't configure any manual addresses as you typically can't set them deprecated. (The ordering I've always had in mind to get around certain issues is to try to instantaneously both deprecate the old addresses and introduce the new ones -- to avoid dual-use.) > and DNS is advised of the > new set of addresses (and therefore the new prefix might be used as a > destination address to a server). You have an assumption that having stable routing with two prefixes is possible. I argue that it's at least difficult if not impossible. > But apart from that, he is assuming that the ISP is filtering traffic > coming from the network using the second prefix because it fails an RPF > check - there is no route to that address, or the route faces into the ISP. > Alternativeively, his words referred to RFC 2827, which suggests that > traffic arriving from the enterprise network should be compared to a source > address access list which permits traffic from the enterprises assigned > prefix(es) and denies all other. > > I would argue that an enterprise legitimately using any prefix with any > ISP, whether it is one or many, is responsible to tell the ISP it is doing > so. The ISP might not be contracted to accept the route or to route to that > prefix, ... > but it should not be filtering out traffic using it. Many ISP's will filter them, you can be sure of that. That's the right thing to do, operationally and security-wise. And it's the simplest thing to do too: just a plain uRPF check without exceptions. We certainly do so. You may also consider a scenario with: customer--. |@ \@ ISP1-*---ISP2 $|* | ISPA ISPB Regular, "first-hop" ingress filtering is done at "@"'s. Now, ISPA might be performing address filtering at "$". That'd mean that ISP1 would have to tell about the customer's special case upstream too (possibly multiple hops). ISP1 might also be filtering out all the source addresses belonging to its space at "*"'s -- from other ISP's and from transits. We certainly do that. This would have to special-cased here too. Ingress filtering is just *not* a tool you may believe it is, a binary on/off toggle at the first-hop ISP -- the Internet is not a homogeneous, single-administration, single-security-domain place. > > You don't discuss this in your draft > > So I think you're suggesting that section 3 become section 3.1, enveloped > in a section 3 entitled "how not to shoot one-self in the foot". Section > 3.2, entitled "managing routing and ingress filtering issues" says "if you > expect routing and filtering to work through your ISP, you should tell him > what prefixes you are using". Close? Pretty close, but the thing is far from so trivial: what if the ISP says "you have our prefix, we can't route traffic which doesn't have it as the source address, please don't send other traffic here"? -- 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 Apr 28 02:32:04 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 h3S9W3hs018946; Mon, 28 Apr 2003 02:32:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3S9W30I018945; Mon, 28 Apr 2003 02:32:03 -0700 (PDT) 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 h3S9W0hs018938 for ; Mon, 28 Apr 2003 02:32:00 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3S9W7uc004435 for ; Mon, 28 Apr 2003 02:32:07 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA27645 for ; Mon, 28 Apr 2003 03:32:01 -0600 (MDT) 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, 28 Apr 2003 09:32:01 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, 28 Apr 2003 09:32: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; Mon, 28 Apr 2003 09:32:00 Z Received: from nebula.skynet.be (nebula.skynet.be [195.238.2.112]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 09:32:00 Z Received: from tsn (32.106-200-80.adsl.skynet.be [80.200.106.32]) by nebula.skynet.be (8.12.9/8.12.9/Skynet-OUT-2.21) with ESMTP id h3S9VuCq022803; Mon, 28 Apr 2003 11:31:56 +0200 (envelope-from ) Message-Id: <200304280931.h3S9VuCq022803@nebula.skynet.be> From: "Mario Goebbels" To: "'Jason Hunt'" Cc: Subject: RE: My thoughts on local-use addresses Date: Mon, 28 Apr 2003 11:32:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Microsoft Outlook, Build 11.0.4920 In-Reply-To: <20030426133530.3e02b3ce.moore@cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Thread-Index: AcMMHQTD1sM1hnTPR/6G85sL0rtRQABS/hiQ Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3S9W0hs018939 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > What is wrong with having addresses available for private use on > > networks that do not intend on being connected to the Internet? > > in principle, nothing. but experience has shown that most of > those networks do end up being connected to the Internet, > while still keeping those addreses, and that applications are > expected to cope with that. It would be still nice to have some sort of private addressing for backend servers. Using link local addresses does work for a small network, but we're running our database servers on different subnets (connected by routers) than the webservers. Though continuing to use IPv4 would work, but it's not what I would want to do on longterm. -mg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 02:58: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 h3S9w7hs019530; Mon, 28 Apr 2003 02:58:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3S9w70k019529; Mon, 28 Apr 2003 02:58:07 -0700 (PDT) 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 h3S9w3hs019519 for ; Mon, 28 Apr 2003 02:58:03 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3S9wAuc007872 for ; Mon, 28 Apr 2003 02:58:10 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id DAA08073 for ; Mon, 28 Apr 2003 03:58:05 -0600 (MDT) 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, 28 Apr 2003 09:58: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; Mon, 28 Apr 2003 09:58: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; Mon, 28 Apr 2003 09:58:04 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, 28 Apr 2003 09:58:04 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id CAA22098; Mon, 28 Apr 2003 02:57:15 -0700 (PDT) Message-Id: <5.1.0.14.2.20030428053937.047cbc68@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Apr 2003 05:53:20 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: A simple question Cc: Valdis.Kletnieks@vt.edu, Dave Crocker , ipng@sunroof.eng.sun.com, ietf@ietf.org In-Reply-To: <16388.1050790957@munnari.OZ.AU> References: <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, At 05:22 AM 4/20/2003 +0700, Robert Elz wrote: >But if you assume that there are people (and there most probably are) who >are so sold on the "benefits" of NAT, that they're going to use NAT no >matter how much you show them that there is in fact no benefit at all >(which for a site with an IPv6 global /48, and site locals, is certainly >true) then why would you care what address they're using behind the NAT? >That is, whether it is SL, LL, or some random "global" prefix they calculated >by tossing coins. Actually, it isn't true that an IPv6 global /48 prefix plus site locals would provide all of the "benefits" of NAT. In particular, you would still need to renumber your local network (the global prefixes) when your provider-allocated global addresses change. Having extra addresses available for internal traffic (the site-locals) does not make renumbering the global prefix any easier or less expensive. Although NAT causes various problems, it does offer a high degree of provider-independence for internal nodes. You won't get this using provider-allocated global addresses in IPv6, no matter how many other addresses you add to each node. Of course, this isn't why NAT is most often used... NAT is most often used to extend a single address to cover multiple systems in a home or small office environment. For that environment, an IPv6 /48 (without site-locals) would suffice to replace NAT. >I find it almost inconceivable to believe that anyone is deciding the fate >of SL addressing by reference to NAT - that's simply too ludicrous (and sad) >to contemplate. I am similarly disturbed that there are people who want to specify site-local addressing because they think it will offer the provider-independence currently offered by NAT. 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 Apr 28 04:04: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 h3SB4ths020829; Mon, 28 Apr 2003 04:04:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SB4sdT020828; Mon, 28 Apr 2003 04:04:54 -0700 (PDT) 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 h3SB4phs020821 for ; Mon, 28 Apr 2003 04:04:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SB4vKw005560 for ; Mon, 28 Apr 2003 04:04:57 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id FAA03720 for ; Mon, 28 Apr 2003 05:04:51 -0600 (MDT) 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, 28 Apr 2003 11:04: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, 28 Apr 2003 11:04: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, 28 Apr 2003 11:04:50 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 11:04:49 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3SB4e409931; Mon, 28 Apr 2003 14:04:40 +0300 Date: Mon, 28 Apr 2003 14:04:39 +0300 (EEST) From: Pekka Savola To: Mario Goebbels cc: "'Jason Hunt'" , Subject: RE: My thoughts on local-use addresses In-Reply-To: <200304280931.h3S9VuCq022803@nebula.skynet.be> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 28 Apr 2003, Mario Goebbels wrote: > > > What is wrong with having addresses available for private use on > > > networks that do not intend on being connected to the Internet? > > > > in principle, nothing. but experience has shown that most of > > those networks do end up being connected to the Internet, > > while still keeping those addreses, and that applications are > > expected to cope with that. > > It would be still nice to have some sort of private addressing for backend > servers. Using link local addresses does work for a small network, but we're > running our database servers on different subnets (connected by routers) > than the webservers. Though continuing to use IPv4 would work, but it's not > what I would want to do on longterm. Why not just use global IPv6 addresses, a part of the /48 prefix, for that -- and just not route that particular piece? That's what we do and it works 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 Apr 28 04:31: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 h3SBV7hs021221; Mon, 28 Apr 2003 04:31:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SBV7UC021220; Mon, 28 Apr 2003 04:31:07 -0700 (PDT) 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 h3SBV4hs021212 for ; Mon, 28 Apr 2003 04:31:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SBVAuc021762 for ; Mon, 28 Apr 2003 04:31:10 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id FAA22853 for ; Mon, 28 Apr 2003 05:31:05 -0600 (MDT) 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, 28 Apr 2003 11:31:05 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, 28 Apr 2003 11:31: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, 28 Apr 2003 11:31:04 Z Received: from gallantin.skynet.be (gallantin.skynet.be [195.238.2.124]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 11:31:04 Z Received: from tsn (32.106-200-80.adsl.skynet.be [80.200.106.32]) by gallantin.skynet.be (8.12.9/8.12.9/Skynet-OUT-2.21) with ESMTP id h3SBUrF1022430; Mon, 28 Apr 2003 13:30:53 +0200 (envelope-from ) Message-Id: <200304281130.h3SBUrF1022430@gallantin.skynet.be> From: "Mario Goebbels" To: "'Pekka Savola'" Cc: "'Jason Hunt'" , Subject: RE: My thoughts on local-use addresses Date: Mon, 28 Apr 2003 13:31:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook, Build 11.0.4920 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Thread-Index: AcMNd2OccV/XHg+RR+exOudXIRL5FQAAe46Q Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > What is wrong with having addresses available for > private use on > > > > networks that do not intend on being connected to the Internet? > > > > > > in principle, nothing. but experience has shown that > most of those > > > networks do end up being connected to the Internet, while still > > > keeping those addreses, and that applications are > expected to cope > > > with that. > > > > It would be still nice to have some sort of private addressing for > > backend servers. Using link local addresses does work for a small > > network, but we're running our database servers on > different subnets > > (connected by routers) than the webservers. Though > continuing to use > > IPv4 would work, but it's not what I would want to do on longterm. > > Why not just use global IPv6 addresses, a part of the /48 > prefix, for that -- and just not route that particular piece? > That's what we do and it works fine. Just not route? You mean using a filter on outgoing traffic, right? -mg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 06:53:42 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 h3SDrfhs022151; Mon, 28 Apr 2003 06:53:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SDrfLr022150; Mon, 28 Apr 2003 06:53:41 -0700 (PDT) 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 h3SDrchs022143 for ; Mon, 28 Apr 2003 06:53:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SDriuc013578 for ; Mon, 28 Apr 2003 06:53:44 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id HAA21105 for ; Mon, 28 Apr 2003 07:53:38 -0600 (MDT) 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, 28 Apr 2003 13:53: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; Mon, 28 Apr 2003 13:53: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; Mon, 28 Apr 2003 13:53:36 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, 28 Apr 2003 13:53:36 Z Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3SDrL0A000208; Mon, 28 Apr 2003 06:53:27 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGN36671; Mon, 28 Apr 2003 06:49:20 -0700 (PDT) Message-Id: <5.2.0.9.2.20030428063737.0671c770@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Apr 2003 06:42:17 -0700 To: Pekka Savola From: Fred Baker Subject: RE: Operational Renumbering Procedure Cc: Christian Huitema , In-Reply-To: References: <5.2.0.9.2.20030427203349.058defa8@mira-sjc5-b.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:00 PM 4/28/2003 +0300, Pekka Savola wrote: >(The ordering I've always had in mind to get around certain issues is to >try to instantaneously both deprecate the old addresses and introduce the >new ones -- to avoid dual-use.) So you really don't mind that the DNS (and DHCP?) records are still outstanding, and don't mind imposing an outage related to that? >what if the ISP says "you have our prefix, we can't route traffic which >doesn't have it as the >source address, please don't send other traffic here"? You are saying that you would rather drive your customer away than add a second line to the access list? The ISP is cutting its own nose off. You suggest that the enterprise is in the process of switching ISPs. In the case you present, though, I should think that the enterprise is adding an ISP (becoming multihomed); if he plans to drop the first later, he may, but he's not doing it now. Making life difficult for its customer would, if I were the enterprise's CIO, be a reason for converting that from "adding an ISP" to "switching ISPs". So, OK, this document is also for ISPs that have no concept of customer service. I'll point out that intransigence on the part of the ISP is not a wise marketing move. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 06:56:42 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 h3SDughs022189; Mon, 28 Apr 2003 06:56:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SDuf4q022188; Mon, 28 Apr 2003 06:56:41 -0700 (PDT) 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 h3SDuchs022178 for ; Mon, 28 Apr 2003 06:56:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SDuiuc014017 for ; Mon, 28 Apr 2003 06:56:44 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id HAA23205 for ; Mon, 28 Apr 2003 07:56:39 -0600 (MDT) 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, 28 Apr 2003 13:56:38 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, 28 Apr 2003 13:56: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; Mon, 28 Apr 2003 13:56:38 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 13:56:37 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3SDuRL11250; Mon, 28 Apr 2003 16:56:28 +0300 Date: Mon, 28 Apr 2003 16:56:27 +0300 (EEST) From: Pekka Savola To: Mario Goebbels cc: "'Jason Hunt'" , Subject: RE: My thoughts on local-use addresses In-Reply-To: <200304281130.h3SBUrF1022430@gallantin.skynet.be> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 28 Apr 2003, Mario Goebbels wrote: > > > > > What is wrong with having addresses available for > > private use on > > > > > networks that do not intend on being connected to the Internet? > > > > > > > > in principle, nothing. but experience has shown that > > most of those > > > > networks do end up being connected to the Internet, while still > > > > keeping those addreses, and that applications are > > expected to cope > > > > with that. > > > > > > It would be still nice to have some sort of private addressing for > > > backend servers. Using link local addresses does work for a small > > > network, but we're running our database servers on > > different subnets > > > (connected by routers) than the webservers. Though > > continuing to use > > > IPv4 would work, but it's not what I would want to do on longterm. > > > > Why not just use global IPv6 addresses, a part of the /48 > > prefix, for that -- and just not route that particular piece? > > That's what we do and it works fine. > > Just not route? You mean using a filter on outgoing traffic, right? Example: if you're using 3FFE:FFFF:1::/48 in your site, you could designate e.g. 3FFE:FFFF:1:F000::/52 as your "interconnect" block. In your site's border routers (at least), you would install a discard route to 3FFE:FFFF:1:F000::/52. Now, you'd just use 3FFE:FFFF:1:F000::/64 ... 3FFE:FFFF:1:FFFF::/64 in the private networks just as you chose. You could also filter out outgoing traffic (to the Internet) with source addresses belonging to that /52, but that would not be required. Hope this clarifies what I had in mind.. -- 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 Apr 28 07:03:18 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 h3SE3Ihs022583; Mon, 28 Apr 2003 07:03:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SE3Isn022582; Mon, 28 Apr 2003 07:03:18 -0700 (PDT) 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 h3SE3Ehs022572 for ; Mon, 28 Apr 2003 07:03:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SE3LKw009431 for ; Mon, 28 Apr 2003 07:03:21 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA27952 for ; Mon, 28 Apr 2003 08:03:15 -0600 (MDT) 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, 28 Apr 2003 14:03: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; Mon, 28 Apr 2003 13:58: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; Mon, 28 Apr 2003 14:03:04 Z Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 14:03:00 Z Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3SE2mID020374; Mon, 28 Apr 2003 07:02:49 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGN37197; Mon, 28 Apr 2003 06:58:47 -0700 (PDT) Message-Id: <5.2.0.9.2.20030428065819.0480d0e8@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Apr 2003 07:02:45 -0700 To: Pekka Savola From: Fred Baker Subject: RE: Operational Renumbering Procedure Cc: Christian Huitema , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:00 PM 4/28/2003 +0300, Pekka Savola wrote: >(The ordering I've always had in mind to get around certain issues is to >try to instantaneously both deprecate the old addresses and introduce the >new ones -- to avoid dual-use.) I think I need to ask you something. The title of the draft is "Procedures for Renumbering an IPv6 Network without a Flag Day". What you describe here - the simultaneous deprecation of the old and introduction of the new - is a flag day. Are you asking me to make having a flag day a premise? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 07:25:49 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 h3SEPnhs023314; Mon, 28 Apr 2003 07:25:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SEPmeT023313; Mon, 28 Apr 2003 07:25:48 -0700 (PDT) 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 h3SEPjhs023306 for ; Mon, 28 Apr 2003 07:25:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SEPpKw013770 for ; Mon, 28 Apr 2003 07:25:52 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id IAA25201 for ; Mon, 28 Apr 2003 08:25:45 -0600 (MDT) 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, 28 Apr 2003 14:25:45 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, 28 Apr 2003 14:21: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, 28 Apr 2003 14:25:43 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 14:25:41 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3SEPOP11500; Mon, 28 Apr 2003 17:25:24 +0300 Date: Mon, 28 Apr 2003 17:25:23 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: Christian Huitema , Subject: RE: Operational Renumbering Procedure In-Reply-To: <5.2.0.9.2.20030428063737.0671c770@mira-sjc5-b.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 Mon, 28 Apr 2003, Fred Baker wrote: > At 12:00 PM 4/28/2003 +0300, Pekka Savola wrote: > >(The ordering I've always had in mind to get around certain issues is to > >try to instantaneously both deprecate the old addresses and introduce the > >new ones -- to avoid dual-use.) > > So you really don't mind that the DNS (and DHCP?) records are still > outstanding, and don't mind imposing an outage related to that? I haven't followed that thought in enough detail to know whether this is a problem or not. In particular, it seems to depend on two issues: - the procedures of removing the old DNS etc. data, "outstanding information" - how a host would react to a TCP SYN to a deprecated address. TCP RST? If application is done properly, it will try the other record then, with a delay of one RTT. > >what if the ISP says "you have our prefix, we can't route traffic which > >doesn't have it as the > >source address, please don't send other traffic here"? > > You are saying that you would rather drive your customer away than add a > second line to the access list? To respond with an analogue.. Are you saying you would rather drive your customer away than punching a hole in some other ISP's aggregate by announcing a few (IPv4) /24's to the DFZ? Yes, someone has to say NO. Moreover: it's just not the ISP who is the "bad guy". There is zero guarantee that even if ISP made manual fixes in all its access lists, the site's use of the wrong source address would still work. Someone else (ISP's neighbors, transits, the owner of the superblock ie. the site's other ISP, etc.) would probably have similar filters. -- 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 Apr 28 07:37:30 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 h3SEbUhs023612; Mon, 28 Apr 2003 07:37:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SEbTOL023611; Mon, 28 Apr 2003 07:37:29 -0700 (PDT) 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 h3SEbQhs023604 for ; Mon, 28 Apr 2003 07:37:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SEbWKw016379 for ; Mon, 28 Apr 2003 07:37:33 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id IAA00076 for ; Mon, 28 Apr 2003 08:37:25 -0600 (MDT) 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, 28 Apr 2003 14:37:17 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, 28 Apr 2003 14:37: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; Mon, 28 Apr 2003 14:37:01 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 14:37:01 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3SEalb11574; Mon, 28 Apr 2003 17:36:47 +0300 Date: Mon, 28 Apr 2003 17:36:47 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: Christian Huitema , Subject: RE: Operational Renumbering Procedure In-Reply-To: <5.2.0.9.2.20030428065819.0480d0e8@mira-sjc5-b.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 Mon, 28 Apr 2003, Fred Baker wrote: > At 12:00 PM 4/28/2003 +0300, Pekka Savola wrote: > >(The ordering I've always had in mind to get around certain issues is to > >try to instantaneously both deprecate the old addresses and introduce the > >new ones -- to avoid dual-use.) > > I think I need to ask you something. The title of the draft is "Procedures > for Renumbering an IPv6 Network without a Flag Day". What you describe here > - the simultaneous deprecation of the old and introduction of the new - is > a flag day. Are you asking me to make having a flag day a premise? There may or may not be ways to achieve renumbering without a "flag day". Renumbering is difficult enough even if there *will* be a flag day to warrant pursuing both approaches (but not necessarily in the same document of course). The flag day argument has been made about Internet. I totally agree, flag days are not possible. A similar argument can be made about most ISP's (only very minor ones could be able synchronize it with their customers). But renumbering these is not the really difficult issue. End-sites would prefer renumbering without flag days, but if they have to bear it, they can endure one: it just has a cost label attached to it. And really, in the end, a properly executed & aided renumbering operation might not take more than minutes/hours to get into a "reasonably working" state (plan a time, make the network infrastructure ready, reduce DNS TTL's, lease times, autoconfigure the old prefixes, etc.). But the requirement for no flag day also has complications and tradeoffs attached to it. -- 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 Apr 28 07:41: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 h3SEf1hs023689; Mon, 28 Apr 2003 07:41:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SEf1nH023688; Mon, 28 Apr 2003 07:41:01 -0700 (PDT) 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 h3SEevhs023678 for ; Mon, 28 Apr 2003 07:40:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SEf4Kw017182 for ; Mon, 28 Apr 2003 07:41:04 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id IAA25743 for ; Mon, 28 Apr 2003 08:40:58 -0600 (MDT) 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, 28 Apr 2003 14:40:56 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, 28 Apr 2003 14:40:56 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, 28 Apr 2003 14:40:55 Z Received: from oak1a.cats.ohiou.edu ([132.235.8.44] [132.235.8.44]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 14:40:55 Z Received: from hkruse.csm.ohiou.edu (hkruse.csm.ohiou.edu [132.235.75.144]) (authenticated bits=0) by oak2a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id h3SELBlk1425454 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 28 Apr 2003 10:21:11 -0400 (EDT) Date: Mon, 28 Apr 2003 10:22:15 -0400 From: Hans Kruse To: ipng@sunroof.eng.sun.com Subject: Re: Operational Renumbering Procedure Message-Id: <3003312244.1051525335@hkruse.csm.ohiou.edu> In-Reply-To: <5.2.0.9.2.20030425131251.02ed3cc0@mira-sjc5-b.cisco.com> References: <5.2.0.9.2.20030425131251.02ed3cc0@mira-sjc5-b.cisco.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just to complete the list, Windows NT and up (2000, XP, I have not yet tried in 2003) all accept multiple IPv4s per interface. I believe there is a certain arbitrariness about what is "primary" depending on the application, but deleting the "first in the list" address does not take the machine off the network. --On Friday, April 25, 2003 14:00 -0700 Fred Baker wrote: >> .. IMO appears to be wrong. The IPv4 equipment I use certainly allows >> all of this. > > Hmm. The equipment I am referring to is Cisco Routers, *nix machines, > Microsoft Windows, and so on. To put two IPv4 prefixes on a Cisco Router > interface, one needs to configure two sub-interfaces rather than one > interface, and until relatively recently this was not necessarily > supported. Sun Workstations and Linux machines have a very clear sense of > what single IP prefix and address is used on an interface, as does > Windows; I'm not at all certain how I would go about putting a second > address on a Windows interface at all, and on a Sun, it would be a > "secondary address" or an entry in the host file (such as localhost has). > A secondary address is in no sense the same thing as having two co-equal > prefixes on an interface. Cisco routers have secondary address as a > capability, but it is not at all the same thing as having two addresses; > if you remove the primary, the other doesn't simply "become" the > primary... Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 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 Mon Apr 28 08:23: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 h3SFNohs024301; Mon, 28 Apr 2003 08:23:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SFNoln024300; Mon, 28 Apr 2003 08:23:50 -0700 (PDT) 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 h3SFNkhs024293 for ; Mon, 28 Apr 2003 08:23:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SFNrKw028426 for ; Mon, 28 Apr 2003 08:23:53 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id JAA27865 for ; Mon, 28 Apr 2003 09:23:46 -0600 (MDT) 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, 28 Apr 2003 15:23: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; Mon, 28 Apr 2003 15:23: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, 28 Apr 2003 15:23:18 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; Mon, 28 Apr 2003 15:23:17 Z Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3SFMnEL024277; Mon, 28 Apr 2003 08:22:54 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AGN42442; Mon, 28 Apr 2003 08:18:47 -0700 (PDT) Message-Id: <5.2.0.9.2.20030428081658.04804d10@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Apr 2003 08:21:51 -0700 To: Pekka Savola From: Fred Baker Subject: RE: Operational Renumbering Procedure Cc: Christian Huitema , In-Reply-To: References: <5.2.0.9.2.20030428063737.0671c770@mira-sjc5-b.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 05:25 PM 4/28/2003 +0300, Pekka Savola wrote: >Are you saying you would rather drive your customer >away than punching a hole in some other ISP's aggregate by announcing a >few (IPv4) /24's to the DFZ? There is routing and there is ingress filtering. If you don't choose to route the traffic *to* the other ISP's prefix, that's fine with me. The other ISP can do that just fine. We're discussing ingress filtering, and you're telling me that you will arbitrarily tell your customer that he may either use your service or be multihomed, but not both. You can say that if you want, but if the CIO of your customer's network has decided to be multihomed, you are deciding you don't need his business. For the price of adding a line to an access list on the ingress filter, you can retain his business and continue receiving money from a multihomed customer. Is this not your business objective? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 09:36: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 h3SGaYhs025401; Mon, 28 Apr 2003 09:36:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SGaYU9025400; Mon, 28 Apr 2003 09:36:34 -0700 (PDT) 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 h3SGaUhs025390 for ; Mon, 28 Apr 2003 09:36:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SGaaKw017424 for ; Mon, 28 Apr 2003 09:36:36 -0700 (PDT) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA11642 for ; Mon, 28 Apr 2003 10:36:30 -0600 (MDT) 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, 28 Apr 2003 16:36: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, 28 Apr 2003 16:32: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; Mon, 28 Apr 2003 16:36:21 Z Received: from defiant.dfw.nostrum.com (defiant.dfw.nostrum.com [65.67.187.82]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 16:36:13 Z Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3SGZjL26870; Mon, 28 Apr 2003 11:35:45 -0500 Message-Id: <00b401c30da4$390d81d0$93b58742@ssprunk> From: "Stephen Sprunk" To: "Robert Elz" , "Margaret Wasserman" Cc: , "Dave Crocker" , , References: <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <5.1.0.14.2.20030428053937.047cbc68@mail.windriver.com> Subject: Re: A simple question Date: Mon, 28 Apr 2003 11:23:25 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Margaret Wasserman" > Of course, this isn't why NAT is most often used... NAT is most > often used to extend a single address to cover multiple systems > in a home or small office environment. For that environment, > an IPv6 /48 (without site-locals) would suffice to replace NAT. When you are talking about tens of millions of customers, it's not feasible to give each a subnet even if you have the space to do it. IMHO, most customers will be placed on a /64 that's shared across hundreds of customers, similar to IPv4 common practice. There is nothing to indicate that ISPs are going to change their business models simply because IPv6 address space is plentiful; they charge extra for two hosts because it is assumed two hosts consume more bits than one, not because a second IPv4 address is hard to come by. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 09:41: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 h3SGfPhs025589; Mon, 28 Apr 2003 09:41:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SGfOw4025588; Mon, 28 Apr 2003 09:41:24 -0700 (PDT) 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 h3SGfLhs025581 for ; Mon, 28 Apr 2003 09:41:21 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SGfSuc026018 for ; Mon, 28 Apr 2003 09:41:28 -0700 (PDT) Received: from fuchsia.home (ip25.coe.tnet.co.th [203.146.155.25]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3SGfKrZ026394 for ; Mon, 28 Apr 2003 09:41:21 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3SGdffF001007; Mon, 28 Apr 2003 23:39:44 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3SFiNj09278; Mon, 28 Apr 2003 22:44:23 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: Mario Goebbels , "'Jason Hunt'" , ipng@sunroof.eng.sun.com Subject: Re: My thoughts on local-use addresses In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Apr 2003 22:44:23 +0700 Message-ID: <9276.1051544663@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 28 Apr 2003 16:56:27 +0300 (EEST) From: Pekka Savola Message-ID: | Hope this clarifies what I had in mind.. You described one, of many, methods of filtering traffic. If traffic filtering was all that was required, that will work fine (though personally I prefer explicit packet access lists, it is clearer what is happening and why). On the other hand, if tomorrow you wake up and find a message from your provider telling you that 3ffe:ffff:1::/48 is now your neighbour, and 3ffe:ffff:2::/48 is you, you have a problem. If you keep using 3ffe:ffff:1 for your servers, then nothing in your net can communicate with your neighbour, as the routes are all inwards, not outwards. If you stop, and switch to 3ffe:ffff:2 then all your server communications break for some period (your boss misses out on getting his paycheck on time, and you get fired). On the other hand, if your servers were using site local addresses, as Mario suggested, then none of this would affect them. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 09:41: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 h3SGfths025659; Mon, 28 Apr 2003 09:41:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SGftjU025658; Mon, 28 Apr 2003 09:41:55 -0700 (PDT) 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 h3SGfmhs025651 for ; Mon, 28 Apr 2003 09:41:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SGfsKw019049 for ; Mon, 28 Apr 2003 09:41:54 -0700 (PDT) Received: from fuchsia.home (ip25.coe.tnet.co.th [203.146.155.25]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3SGfhrZ026575 for ; Mon, 28 Apr 2003 09:41:45 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3SGdffH001007; Mon, 28 Apr 2003 23:39:56 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3SFbKj09230; Mon, 28 Apr 2003 22:37:20 +0700 (ICT) From: Robert Elz To: Margaret Wasserman cc: Valdis.Kletnieks@vt.edu, Dave Crocker , ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question In-Reply-To: <5.1.0.14.2.20030428053937.047cbc68@mail.windriver.com> References: <5.1.0.14.2.20030428053937.047cbc68@mail.windriver.com> <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Apr 2003 22:37:20 +0700 Message-ID: <9228.1051544240@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 28 Apr 2003 05:53:20 -0400 From: Margaret Wasserman Message-ID: <5.1.0.14.2.20030428053937.047cbc68@mail.windriver.com> | In particular, you would still need to renumber your local network | (the global prefixes) when your provider-allocated global | addresses change. Yes. | Having extra addresses available for internal | traffic (the site-locals) does not make renumbering the global | prefix any easier or less expensive. No, that's simply wrong. One of the biggest costs in renumbering is the disruption it causes. The actual cost of editing the files, etc, is trivial by comparison. If all of the internal operations of an organisation are going to be disrupted, then the organisation is really going to resist any renumbering. But if everything just sails on through, operating as normal, then adding a prefix, and later deleting an old one, is must less intrusive, and less costly. | Although NAT causes various problems, it does offer a high degree | of provider-independence for internal nodes. You won't get this | using provider-allocated global addresses in IPv6, no matter how | many other addresses you add to each node. It would be nice if everyone would stop using "provider" in this context. What matters here is the use of topology sensitive addresses. If the address reflects the topology of the network, then it has to change when the topology changes. It happens that in the current network environment, the topology is controlled by the providers, so we have provider supplied addressing to correctly reflect the topology. Getting provider independent addressing is plausible - we just need to make the network topology (somehow) stop being controlled by the providers. Getting addressing that is independent of the topology is a much more interesting problem. That one I don't believe we have any way to accomplish yet, that works with routing. Until we do, we need addressing for local use. | Of course, this isn't why NAT is most often used... NAT is most | often used to extend a single address to cover multiple systems | in a home or small office environment. I think you're living in a sanitised enviornment. NAT is used almost everywhere (perhaps outside the US) - almost everywhere. | For that environment, | an IPv6 /48 (without site-locals) would suffice to replace NAT. It might. I'm not sure it will however. I don't know that I want even my home connectivity (connections between controllers and appliances and such) to be disrupted when I change providers (or when my provider alters the prefix temporarily allocated to me). | I am similarly disturbed that there are people who want to | specify site-local addressing because they think it will offer | the provider-independence currently offered by NAT. I have no idea who those people are. I am surprised that you (seem to) believe that NAT offers provider independence. It doesn't. What it does is allows the renumbering task to be simplified (quite a lot usually in that case) - but that's all. Site locals do the same, they allow the renumbering task to be simplified, as there's one less thing that needs to be worried about. By no means do they solve the entire problem, they're just one nail. But they (or something essentially equivalent) are required, something needs to provide the kind of address stability that anyone can now have in IPv4 using NAT. We could recommend NAT for IPv6, that would certainly do it, but I hope we don't, there has to be better ways than that. If you think you have a better way than site locals, please describe it. I don't want to know what you think the problems with site locals are, I know they're not perfect. I want to know what is the better solution. Until there is one, site locals need to remain. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 09:46: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 h3SGklhs026018; Mon, 28 Apr 2003 09:46:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SGklOZ026017; Mon, 28 Apr 2003 09:46:47 -0700 (PDT) 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 h3SGkhhs026004 for ; Mon, 28 Apr 2003 09:46:43 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SGknKw020746 for ; Mon, 28 Apr 2003 09:46:50 -0700 (PDT) Received: from fuchsia.home (ip25.coe.tnet.co.th [203.146.155.25]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA13776 for ; Mon, 28 Apr 2003 09:46:42 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h3SGjPfF000448; Mon, 28 Apr 2003 23:45:25 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h3SGkHQ09524; Mon, 28 Apr 2003 23:46:17 +0700 (ICT) From: Robert Elz To: Margaret Wasserman cc: Keith Moore , dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com Subject: Re: A simple question In-Reply-To: <5.1.0.14.2.20030427201951.03184c10@mail.windriver.com> References: <5.1.0.14.2.20030427201951.03184c10@mail.windriver.com> <20030419151329.66daf0de.moore@cs.utk.edu> <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Apr 2003 23:46:17 +0700 Message-ID: <9522.1051548377@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 27 Apr 2003 20:21:50 -0400 From: Margaret Wasserman Message-ID: <5.1.0.14.2.20030427201951.03184c10@mail.windriver.com> | As John Klensin pointed out on this same list several weeks ago | (and I'm sure he said it better than I will), the decision to | use ambiguous local addressing in IPv4 (i.e. RFC 1918 addresses) | was partially motivated by the desire to conserve IPv4 address | space. That was most probably a small part of it. The real motivation was that people were simply numbering their nets out of random numbers, and that was a bigger problem, for everyone, than 1918 addresses ever were. Keith has said that he feels that the decision to go with 1918 (and 1597 before that) was wrong. He's mistaken. The net would have been a disaster without it, and not just because we would have run out of addresses more quickly (given sufficient incentive, we could have found a solution to that much more quickly than we have been doing). Please remember the dual goals of IPv6 - they show the dual problems that the net was facing in the early 90's. More addresses, and routing simplification. We haven't found a newer routing solution than (now) exists for IPv4 - which means topological addressing. We have to make that work, or find something else. | In IPv6, we don't have an address space shortage, so there | is no reason to introduce architectural complexity to conserve | address space. Of course there isn't. You can go on refuting claims that no-one is making forever if you want, that won't get us any closer to anything. I'd have every node given a global address (whether it wants to use it or not). Site local addresses are an extra. As are link locals. There's no address conservation happening here. Either of those -local addresses adds the architectural complexity. Only by removing both of them can you simplify things. While simplification is a good thing, I certainly don't feel that we can sacrifice link local addressing to get it. And as long as we're keeping link local, the extra complexity added by site local is close to zero (and essentially would be zero if we eliminated multi-site nodes from the architecture). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 09:52: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 h3SGqphs026546; Mon, 28 Apr 2003 09:52:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SGqpHE026545; Mon, 28 Apr 2003 09:52:51 -0700 (PDT) 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 h3SGqlhs026536 for ; Mon, 28 Apr 2003 09:52:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SGqsKw023260 for ; Mon, 28 Apr 2003 09:52:54 -0700 (PDT) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA23214 for ; Mon, 28 Apr 2003 10:52:48 -0600 (MDT) 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, 28 Apr 2003 16: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; Mon, 28 Apr 2003 16:48: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; Mon, 28 Apr 2003 16: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; Mon, 28 Apr 2003 16:52:35 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3SGqKX12605; Mon, 28 Apr 2003 19:52:20 +0300 Date: Mon, 28 Apr 2003 19:52:20 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: Mario Goebbels , "'Jason Hunt'" , Subject: Re: My thoughts on local-use addresses In-Reply-To: <9276.1051544663@munnari.OZ.AU> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 28 Apr 2003, Robert Elz wrote: > Date: Mon, 28 Apr 2003 16:56:27 +0300 (EEST) > From: Pekka Savola > Message-ID: > > | Hope this clarifies what I had in mind.. > > You described one, of many, methods of filtering traffic. If > traffic filtering was all that was required, that will work fine > (though personally I prefer explicit packet access lists, it is > clearer what is happening and why). Yes, I prefer it too. Personally I'd recommend using both, for defence in depth. > On the other hand, if tomorrow you wake up and find a message from > your provider telling you that 3ffe:ffff:1::/48 is now your neighbour, > and 3ffe:ffff:2::/48 is you, you have a problem. That would be a good chance to switch ISP's. Just doing something like taht one morning is not really acceptable. > If you keep using 3ffe:ffff:1 for your servers, then nothing in your > net can communicate with your neighbour, as the routes are all inwards, > not outwards. If you stop, and switch to 3ffe:ffff:2 then all your > server communications break for some period (your boss misses out on > getting his paycheck on time, and you get fired). Well, renumbering is a difficult issue. > On the other hand, if your servers were using site local addresses, > as Mario suggested, then none of this would affect them. Mario's particular scenario was internal links in private networking (like NFS, backup traffic etc.) -- not about addressing in general in the site. My sessions last for a long time -- even months -- but I'm not mad if they drop because now and then (once in a couple of years or so -- a semi-reasonable renumbering period) a renumbering happens. Now, if we need mechanisms to cope for renumbering every day, every week or every month -- we're talking about entirely different kind of requirements. IMO, it's best not to try that problem yet, first -- or we end up with nothing (I fear). -- 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 Apr 28 09:56: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 h3SGu5hs026902; Mon, 28 Apr 2003 09:56:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SGu5LW026901; Mon, 28 Apr 2003 09:56:05 -0700 (PDT) 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 h3SGu1hs026891 for ; Mon, 28 Apr 2003 09:56:01 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SGu7uc002131 for ; Mon, 28 Apr 2003 09:56:07 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA04836 for ; Mon, 28 Apr 2003 10:56:02 -0600 (MDT) 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, 28 Apr 2003 16:56: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; Mon, 28 Apr 2003 16:56: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; Mon, 28 Apr 2003 16:56:00 Z Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 16:56:00 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3SGt4lY016895; Mon, 28 Apr 2003 12:55:05 -0400 (EDT) Received: from cisco.com (sjc-vpn3-326.cisco.com [10.21.65.70]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA09227; Mon, 28 Apr 2003 09:55:03 -0700 (PDT) Message-Id: <3EAD5CE6.2050702@cisco.com> Date: Mon, 28 Apr 2003 09:55:02 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Sprunk CC: Robert Elz , Margaret Wasserman , Valdis.Kletnieks@vt.edu, Dave Crocker , ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question References: <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <5.1.0.14.2.20030428053937.047cbc68@mail.windriver.com> <00b401c30da4$390d81d0$93b58742@ssprunk> In-Reply-To: <00b401c30da4$390d81d0$93b58742@ssprunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stephen Sprunk wrote: > When you are talking about tens of millions of customers, it's not feasible > to give each a subnet even if you have the space to do it. IMHO, most > customers will be placed on a /64 that's shared across hundreds of > customers, similar to IPv4 common practice. Why? 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 Apr 28 09:59: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 h3SGxKhs027186; Mon, 28 Apr 2003 09:59:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SGxKBI027185; Mon, 28 Apr 2003 09:59:20 -0700 (PDT) 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 h3SGxFhs027160 for ; Mon, 28 Apr 2003 09:59:15 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SGxLKw025594 for ; Mon, 28 Apr 2003 09:59:21 -0700 (PDT) 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.3p2+Sun/8.9.3) with ESMTP id KAA06768 for ; Mon, 28 Apr 2003 10:59:16 -0600 (MDT) 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, 28 Apr 2003 16:59: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; Mon, 28 Apr 2003 16:58: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, 28 Apr 2003 16:58:57 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 16:58:57 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3SGwgA12666; Mon, 28 Apr 2003 19:58:42 +0300 Date: Mon, 28 Apr 2003 19:58:42 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: Christian Huitema , Subject: RE: Operational Renumbering Procedure In-Reply-To: <5.2.0.9.2.20030428081658.04804d10@mira-sjc5-b.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 Mon, 28 Apr 2003, Fred Baker wrote: > At 05:25 PM 4/28/2003 +0300, Pekka Savola wrote: > >Are you saying you would rather drive your customer > >away than punching a hole in some other ISP's aggregate by announcing a > >few (IPv4) /24's to the DFZ? > > There is routing and there is ingress filtering. If you don't choose to > route the traffic *to* the other ISP's prefix, that's fine with me. The > other ISP can do that just fine. > > We're discussing ingress filtering, and you're telling me that you will > arbitrarily tell your customer that he may either use your service or be > multihomed, but not both. No, that's not the point. The point is saying "use a mechanism that works". Sending packets with wrong source address is not that. > You can say that if you want, but if the CIO of > your customer's network has decided to be multihomed, you are deciding you > don't need his business. Thus, we need better multihoming mechanisms, which work without damaging the networks. > For the price of adding a line to an access list on the ingress filter, you > can retain his business and continue receiving money from a multihomed > customer. Is this not your business objective? It's not as simple as that. The changes need to be made pretty much everywhere, but even that could be manageable. What do you do when your multihomed customer complains that it can't reach a lot of networks when the traffic goes by you? (as other folks are doing ingress filtering from your direction) Of course, you can sell a service with no guarantees and strong disclaimers "this is probably not going to work", but IMO it's better to say "this really won't work properly, you'd be better off using a working multihoming technique". -- 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 Apr 28 10:22: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 h3SHMXhs028360; Mon, 28 Apr 2003 10:22:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SHMXAa028357; Mon, 28 Apr 2003 10:22:33 -0700 (PDT) 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 h3SHMShs028346 for ; Mon, 28 Apr 2003 10:22:28 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SHMZuc012381 for ; Mon, 28 Apr 2003 10:22:35 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA13093 for ; Mon, 28 Apr 2003 11:22:29 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3SHL3v18457; Mon, 28 Apr 2003 13:21:04 -0400 (EDT) Date: Mon, 28 Apr 2003 13:21:03 -0400 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, mrw@windriver.com, dcrocker@brandenburg.com, ipng@sunroof.eng.sun.com Subject: Re: A simple question Message-Id: <20030428132103.112b2cef.moore@cs.utk.edu> In-Reply-To: <9522.1051548377@munnari.OZ.AU> References: <5.1.0.14.2.20030427201951.03184c10@mail.windriver.com> <20030419151329.66daf0de.moore@cs.utk.edu> <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <9522.1051548377@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith has said that he feels that the decision to go with 1918 (and > 1597 before that) was wrong. He's mistaken. The net would have > been a disaster without it, IMHO, the net is a disaster with RFC 1918. We've got no way to tell for sure what would have happened had we not approved 1918. My guess is that it would have made NATs a tad more difficult to deploy in large numbers, and it would have increased the rate of v4 prefix consumption. Whether or not this would have increased demand for v6 is anybody's guess. It might even have increased demand for v6 to the point that we'd already be stuck with site-locals and A6 records and other unfortunate choices. > Please remember the dual goals of IPv6 - they show the dual problems > that the net was facing in the early 90's. More addresses, and > routing simplification. ...and more complications for applications... > Either of those -local addresses adds the architectural complexity. > Only by removing both of them can you simplify things. As long as you only use link-locals for a small number of network configuration functions, and apps aren't ever expected to use them, I don't see v6LL as a problem. Of course I bought a similar argument about 1918 - that it would stay within intended usage - and I was wrong there. Ultimately, I don't think there's any way to discourage people from doing shortsighted things. The best we can do is to try to provide farsighted ways to do those things. > While simplification is a good thing, I certainly don't feel that we > can sacrifice link local addressing to get it. And as long as we're > keeping link local, the extra complexity added by site local is close > to zero (and essentially would be zero if we eliminated multi-site > nodes from the architecture). Disagree. I think we can effectively eliminate both as far as apps are concerned, even if we keep LL for network configuration and deprecate SL. 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 Mon Apr 28 10:51: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 h3SHpshs028843; Mon, 28 Apr 2003 10:51:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SHpruI028842; Mon, 28 Apr 2003 10:51:53 -0700 (PDT) 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 h3SHpohs028835 for ; Mon, 28 Apr 2003 10:51:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SHpvKw013577 for ; Mon, 28 Apr 2003 10:51:57 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id LAA02387 for ; Mon, 28 Apr 2003 11:51:40 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3SHpXE18698 for ; Mon, 28 Apr 2003 12:51:33 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Apr 2003 12:51:33 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A080B3884@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'ipng@sunroof.eng.sun.com'" Subject: Router Lifetime question Date: Mon, 28 Apr 2003 12:51:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30DAE.C787A1F2" 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_01C30DAE.C787A1F2 Content-Type: text/plain; charset="iso-8859-1" Hi, A question regarding RFC 2461. Unless I am missing something, there seems to be some inconsistency in Sections 6.2.1 and 4.2 of RFC 2461 regarding the value of the Router Lifetime. How is this resolved? See below. Thanks. Pete ====== Section 6.2.1 of RFC 2461: MaxRtrAdvInterval The maximum time allowed between sending unsolicited multicast Router Advertisements from the interface, in seconds. MUST be no less than 4 seconds and no greater than 1800 seconds. Default: 600 seconds AdvDefaultLifetime The value to be placed in the Router Lifetime field of Router Advertisements sent from the interface, in seconds. MUST be either zero or between MaxRtrAdvInterval and 9000 seconds. A value of zero indicates that the router is not to be used as a default router. Default: 3 * MaxRtrAdvInterval Section 4.2 of RFC 2461. Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The maximum value corresponds to 18.2 hours. A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default router list. The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields. ------_=_NextPart_001_01C30DAE.C787A1F2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Router Lifetime question

Hi,

A question regarding RFC 2461. = Unless I am missing something, there seems to be some inconsistency in = Sections 6.2.1 and 4.2 of RFC 2461 regarding the value of the Router = Lifetime. How is this resolved? See below. Thanks.

Pete
=3D=3D=3D=3D=3D=3D

Section 6.2.1 of RFC = 2461:
MaxRtrAdvInterval
           &= nbsp;         The maximum time = allowed between sending
           &= nbsp;         unsolicited = multicast Router Advertisements from
           &= nbsp;         the interface, in = seconds.  MUST be no less than 4
           &= nbsp;         seconds and no = greater than 1800 seconds.

           &= nbsp;         Default: 600 = seconds

AdvDefaultLifetime
           &= nbsp;         The value to be = placed in the Router Lifetime field
           &= nbsp;         of Router = Advertisements sent from the interface,
           &= nbsp;         in seconds.  = MUST be either zero or between
           &= nbsp;         MaxRtrAdvInterval = and 9000 seconds.  A value of
           &= nbsp;         zero indicates = that the router is not to be used as
           &= nbsp;         a default = router.

           &= nbsp;         Default: 3 * = MaxRtrAdvInterval

Section 4.2 of RFC 2461.

Router Lifetime
           &= nbsp;         16-bit unsigned = integer.  The lifetime associated
           &= nbsp;         with the default = router in units of seconds.  The
           &= nbsp;         maximum value = corresponds to 18.2 hours.  A
           &= nbsp;         Lifetime of 0 = indicates that the router is not a
           &= nbsp;         default router = and SHOULD NOT appear on the default
           &= nbsp;         router = list.  The Router Lifetime applies only to
           &= nbsp;         the router's = usefulness as a default router; it
           &= nbsp;         does not apply to = information contained in other
           &= nbsp;         message fields or = options.  Options that need time
           &= nbsp;         limits for their = information include their own
           &= nbsp;         lifetime = fields.

------_=_NextPart_001_01C30DAE.C787A1F2-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 10:52: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 h3SHqChs028853; Mon, 28 Apr 2003 10:52:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SHqCK3028852; Mon, 28 Apr 2003 10:52:12 -0700 (PDT) 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 h3SHq6hs028845 for ; Mon, 28 Apr 2003 10:52:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SHqDKw013651 for ; Mon, 28 Apr 2003 10:52:13 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA27945 for ; Mon, 28 Apr 2003 11:52:07 -0600 (MDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Mon, 28 Apr 2003 10:52:07 -0700 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Apr 2003 10:52:07 -0700 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.3790.0); Mon, 28 Apr 2003 10:52:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 28 Apr 2003 10:52:06 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Mon, 28 Apr 2003 10:52:06 -0700 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: Operational Renumbering Procedure Date: Mon, 28 Apr 2003 10:52:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operational Renumbering Procedure Thread-Index: AcMNp30kasuVngqYRje7XhCyl3/5GAAA8h5A From: "Christian Huitema" To: "Pekka Savola" , "Fred Baker" Cc: X-OriginalArrivalTime: 28 Apr 2003 17:52:06.0194 (UTC) FILETIME=[E1E64120:01C30DAE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3SHq7hs028846 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe Fred's suggestion of adding 'a section 3 entitled "how not to shoot one-self in the foot"' is a practical way to address the issue. I also believe we should consider this under the hypothesis that the site is "adding a provider", or possibly adding a native prefix to an existing 6to4 prefix. Fred, the following is a first cut at your proposed section 3.2. In the intermediate phase of the renumbering, the site uses two prefixes, possibly allocated by two different providers. There are really three cases: both providers accept both prefix, a provider accepts both prefix and the other does not, and each provider only accepts its own prefix. The case of two providers both practicing ingress filtering is pretty hard to solve using the current tools. It requires that the exit link be chosen as a function of the source address, something current routing procedures don't do, or alternately that the source address is chosen as a function of the destination address, something current hosts don't do. Better tools may be available some day, but in the current state sites should ensure the cooperation of at least one of the two providers, and preferably both. The preferred scenario is indeed to convince both providers to support both prefixes. Providers often perform ingress filtering by using a "reverse path" check. Providers can bypass this reverse path check by adding a route for the second prefix in the router that performs ingress filtering. However, adding the second prefix requires some administrative action by the provider. The new provider may easily be convinced, since after all it is getting some additional business. The old provider may or may not be easily convinced. If only one provider supports both prefixes, then the only easy solution is to use that provider as the default route. That will work, but it has the obvious issue of relying on only one of the two providers for outgoing traffic. Multi-homing with 6to4 is a special case. In 6to4, ingress filtering is only an issue for the 6to4 relay routers, which are supposed to drop any traffic that does not originate from a 6to4 prefix. In a scenario where a site is adding a native IPv6 prefix to an existing 6to4 connectivity, ingress filtering issues are solved by convincing the new provider to accept traffic from both prefixes, by setting a default route through the new provider, and by only routing 6to4 traffic (2002::/16) through the existing 6to4 system. -- 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 Mon Apr 28 11:02: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 h3SI2fhs029326; Mon, 28 Apr 2003 11:02:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SI2f9p029325; Mon, 28 Apr 2003 11:02:41 -0700 (PDT) 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 h3SI2bhs029318 for ; Mon, 28 Apr 2003 11:02:37 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SI2hKw017692 for ; Mon, 28 Apr 2003 11:02:43 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA21658 for ; Mon, 28 Apr 2003 12:02:38 -0600 (MDT) 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 <0HE2001ROFEHBK@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 12:01:30 -0600 (MDT) Received: from sun.com ([129.146.18.22]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HE200D3JFEGUV@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 12:01:29 -0600 (MDT) Date: Mon, 28 Apr 2003 11:01:28 -0700 From: Alain Durand Subject: ipng mailing list update To: ipng@sunroof.eng.sun.com Message-id: <3EAD6C78.7070005@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: <20030407204740.GC31150@login.ecs.soton.ac.uk> <20030408102642.GG16238@rvdp.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As of this morning, our IT folks short-circuited the anti-spam filters for the mailing lists hosted on sunroof: mobile-ip, ngtrans & ipng. Thoses filters were the cause for the extra 'Received:' headers. The lists should operate more smoothly now. - 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 Apr 28 12:07: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 h3SJ7Lhs029896; Mon, 28 Apr 2003 12:07:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SJ7LN2029895; Mon, 28 Apr 2003 12:07:21 -0700 (PDT) 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 h3SJ7Hhs029888 for ; Mon, 28 Apr 2003 12:07:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SJ7OKw009686 for ; Mon, 28 Apr 2003 12:07:24 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA27501 for ; Mon, 28 Apr 2003 13:07:18 -0600 (MDT) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h3SJ7Gvm023792; Mon, 28 Apr 2003 12:07:16 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h3SJ7GQd023791; Mon, 28 Apr 2003 12:07:16 -0700 (PDT) Date: Mon, 28 Apr 2003 12:07:16 -0700 From: Shannon -jj Behrens To: ipng@sunroof.eng.sun.com Cc: "Charles E. Perkins" Subject: prefix delegation service Message-ID: <20030428190716.GB23370@alicia.nttmcl.com> 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 Just to throw some simple code out with my ideas, I've created a simple prefix delegation service to delegate unique, provider-independent, non-globally routed IPv6 prefixes for use with disconnected or intermittently-connected networks. The site is at: Here are some notes: o I'm currently using the prefix fcc0::/16, although this can easily be changed: - I think delegating from fec0::/10 is probably out of the question since this prefix is being deprecated. - I think creating a new prefix such as fcc0::/16 has the benefit that delegated prefixes will be instantly recognizable (although, in general, such prefixes should be treated as normal global unicast space). - I think using a prefix allocated by an RIR from 2002::/16 would make a lot of sense since the RIR could allocate such prefixes to anyone wishing to provide a similar service. o I have rate-limited the delegations so that: - No more than 10000 delegations can happen per day. - A connecting /24 (in IPv4) or /48 (in IPv6) can only receive 10 delegations per day. o All I ask for is an email address so that I can contact the user if there was a mistake in allocating the prefix or if the prefix is no longer valid. If anyone wants a copy of the code under a BSD license, shoot me an email. Thanks, -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 Mon Apr 28 12:32:22 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 h3SJWLhs000163; Mon, 28 Apr 2003 12:32:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SJWLcb000162; Mon, 28 Apr 2003 12:32:21 -0700 (PDT) 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 h3SJWIhs000155 for ; Mon, 28 Apr 2003 12:32:18 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SJWOKw021704 for ; Mon, 28 Apr 2003 12:32:24 -0700 (PDT) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA08152 for ; Mon, 28 Apr 2003 13:32:18 -0600 (MDT) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA26932 for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 15:32:17 -0400 (EDT) Date: Mon, 28 Apr 2003 15:32:17 -0400 (EDT) From: Dan Lanciani Message-Id: <200304281932.PAA26932@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: prefix delegation service Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk |Just to throw some simple code out with my ideas, I've created a simple prefix |delegation service to delegate unique, provider-independent, non-globally |routed IPv6 prefixes for use with disconnected or intermittently-connected |networks. The site is at: | | On my first try it tells me that I have already received 10 delegations today... Dan Lanciani ddl@danlan.*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 Apr 28 13:12: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 h3SKCbhs000537; Mon, 28 Apr 2003 13:12:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SKCb4V000536; Mon, 28 Apr 2003 13:12:37 -0700 (PDT) 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 h3SKCXhs000529 for ; Mon, 28 Apr 2003 13:12:33 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SKCeuc005354 for ; Mon, 28 Apr 2003 13:12:40 -0700 (PDT) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA01421 for ; Mon, 28 Apr 2003 14:12:33 -0600 (MDT) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id QAA27038; Mon, 28 Apr 2003 16:12:30 -0400 (EDT) Date: Mon, 28 Apr 2003 16:12:30 -0400 (EDT) From: Dan Lanciani Message-Id: <200304282012.QAA27038@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: Operational Renumbering Procedure Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anyone else find this thread ironic? During the site-local debate a number of people dismissed the need for a mechanism to provide connection survival during renumbering on the grounds that renumbering would always involve a generously long period of overlap between old and new prefixes. Now we are talking about flag days. It would have been nice if the folks who are currently (IMHO, correctly) pointing out the problems with the overlap scheme had jumped in back then. It would be nice if the folks who asserted the ease of overlap (even though it is very difficult to distinguish this overlap from the "hard" multi-homing problem) would jump in now and explain why the issues being raised are non-problems. In general, it would be nice if we could adopt a more wholistic view of the set of problems around which we continue to dance. Moving the hard work out of whatever piece of the protocol we are talking about today only makes it show up in next month's piece--often as harder work. Dan Lanciani ddl@danlan.*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 Apr 28 13:23: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 h3SKNPhs000765; Mon, 28 Apr 2003 13:23:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SKNPqM000764; Mon, 28 Apr 2003 13:23:25 -0700 (PDT) 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 h3SKNLhs000754 for ; Mon, 28 Apr 2003 13:23:21 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SKNRKw006486 for ; Mon, 28 Apr 2003 13:23:27 -0700 (PDT) Received: from albert.tavian.com (albert.tavian.com [66.149.217.205]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3SKNMrZ017232 for ; Mon, 28 Apr 2003 13:23:22 -0700 (PDT) Received: from localhost (doc@localhost) by albert.tavian.com (8.8.7/8.8.7) with ESMTP id NAA14051; Mon, 28 Apr 2003 13:23:19 -0700 Date: Mon, 28 Apr 2003 13:23:18 -0700 (PDT) From: Brian McGehee To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: prefix delegation service In-Reply-To: <200304281932.PAA26932@ss10.danlan.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I got the same problem... On Mon, 28 Apr 2003, Dan Lanciani wrote: > |Just to throw some simple code out with my ideas, I've created a simple prefix > |delegation service to delegate unique, provider-independent, non-globally > |routed IPv6 prefixes for use with disconnected or intermittently-connected > |networks. The site is at: > | > | > > On my first try it tells me that I have already received 10 delegations > today... > > Dan Lanciani > ddl@danlan.*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 Mon Apr 28 14:07:14 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 h3SL7Ehs001092; Mon, 28 Apr 2003 14:07:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SL7CFt001089; Mon, 28 Apr 2003 14:07:12 -0700 (PDT) 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 h3SL78hs001082 for ; Mon, 28 Apr 2003 14:07:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SL75Kw020048 for ; Mon, 28 Apr 2003 14:07:06 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id PAA27065 for ; Mon, 28 Apr 2003 15:06:51 -0600 (MDT) Received: from IDLEWYLDE.windriver.com ([147.11.46.211]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA04817; Mon, 28 Apr 2003 14:06:06 -0700 (PDT) Message-Id: <5.1.0.14.2.20030428165715.046a3888@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Apr 2003 17:02:02 -0400 To: Tony Hain From: Margaret Wasserman Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Cc: ipng@sunroof.eng.sun.com, Thomas Narten , Erik Nordmark , Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tony, We have considered your appeal regarding the IPv6 WG consensus to deprecate site-locals. Based on our analysis, we believe that your appeal makes the following points: (1) You believe that deprecating IPv6 site-local unicast addressing is an incorrect technical choice that places the work output of the IPv6 WG in jeopardy. (2) You believe that the question asked by the chairs was insufficiently clear to be understood properly by the WG. (3) You do not believe that there is rough consensus to deprecate IPv6 site-local addressing, because people provided different reasons for why they believe that IPv6 site-local addressing should be deprecated. In particular, some people want to deprecate the particular model of site-local addressing defined in the scoped addressing architecture (ambiguous, scoped addresses), while others do not believe that we need a local addressing mechanism at all. (4) You believe that it is invalid for the IPv6 WG to deprecate site-local addressing without publishing an IPv6 WG document that analyzes the operational requirements for local addressing. Without this analysis document, you believe that the IPv6 WG has made an uninformed choice. We will now respond to each of your points. -- Point (1): The chairs do not believe that deprecating IPv6 site-local addressing is an incorrect technical decision that will place the work output of the IPv6 WG in jeopardy. The consensus was to "deprecate" the usage of site-local addressing instead of simply removing it. This was done purposely to avoid interference with any current implementations or deployments that might use site-local addressing. In addition to the time it will take to formally deprecate site-local addressing by publishing an RFC, the WG understands that it will take some time after the publication of an RFC for implementations to change. The decision to deprecate site-local addressing, rather than simply removing it, was made to avoid harm to IPv6. In fact, we believe that the previous disagreement over the usage of IPv6 site-local addressing was damaging to the WG, and that our lack of consensus was delaying our work, particularly on the IPv6 scoped addressing architecture. The consensus to deprecate site-local addressing will allow us to move forward and complete our work. --- Point (2): The question was: "Should we deprecate IPv6 site-local unicast addressing?" Possible answers were YES or NO. The chairs believe that this question was sufficiently clear to be understood by the WG. This is supported by the following points: - Over 200 people responded to the question. - Many of the responses on the list (both YES and NO responses) included reasons or comments that followed from the question in a way that indicated that the responders understood the question. - There were only three requests for clarification of this consensus call on the mailing list, two of which were procedural. All of these requests were answered promptly by the chairs. - The chairs sent the consensus results to the list over two weeks ago, including a course of action for the deprecation of site-local addressing. There have been no objections from people who originally expressed YES opinions that the chairs' course of action fails to match their expectations. --- Point (3): The chairs do not believe that consensus on an issue is invalidated by the fact that people have multiple reasons for coming to the same conclusion. We suspect that this happens in most WG consensus calls, and this is not a reason to invalidate the consensus. All of the groups that you mentioned in your message agreed that IPv6 site-local unicast addressing should be deprecated. They may disagree on what we should do after deprecating site- local addressing, but that does not invalidate the consensus on this point. --- Point (4): It is true that the IPv6 WG has not produced a WG document that analyzes the operational requirements for local addressing. However, we do not believe that this is a reason to invalidate the IPv6 WG consensus to deprecate IPv6 site-local unicast addressing. There has been considerable discussion and analysis of site- local addressing performed over the past year, including extensive discussions during three IETF sessions. There have also been several drafts published on the subject, including one draft that attempts to analyze the cost/benefit trade-offs of site-local addressing. This period of discussion has offered sufficient time for anyone who has an operational need for any of the currently-defined usage models of site-local addressing to document those requirements in an Internet-Draft and/or to discuss those requirements on the IPv6 mailing list. During our discussions, several operational benefits of site-local addressing have been raised on the IPv6 WG mailing list, including benefits for disconnected sites, intermittently- connected sites, renumbered sites, etc. We have also uncovered several issues and complexities caused by the current model of ambiguous, scoped site-local addressing, and we have determined that this particular model places burdens on other parts of the TCP/IP protocol suite, particularly routing protocols and applications. In a recent phone discussion and in your appeal clarification, you have indicated that the chairs should void responses from people who do not think that the IPv6 WG should specify any type of local addressing mechanism, because you believe that those responders are uninformed about the operational conditions that require the use of local addressing. While operational necessity is certainly an appropriate argument to raise in support of your position that the IPv6 WG should specify some mechanism for local addressing, the fact that you disagree with the reasons that some people offered for why they want to deprecate the current IPv6 site-local unicast addressing mechanism does not invalidate their contribution to this consensus call. It is the opinion of the chairs that the IPv6 WG did have sufficient information to make an informed decision regarding whether or not to deprecate IPv6 site-local unicast addressing. --- So, to summarize, the chairs do not agree with the points that you have raised in your appeal, and we do not agree to overturn the consensus of the IPv6 WG based on the issues that you have raised. Tony, while we disagree with your position on this particular issue, we do respect your contributions to the IPv6 effort and we realize that your appeal is motivated by your desire to do the right thing for IPv6. We hope that you will accept our response to your appeal and focus on working to define the local addressing problem and solutions as we outlined in our email to the list. We think it is important for the working group to move forward on this issue. Best Regards, Bob Hinden & Margaret Wasserman IPv6 WG Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 14:33:58 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 h3SLXvhs001515; Mon, 28 Apr 2003 14:33:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SLXvjf001514; Mon, 28 Apr 2003 14:33:57 -0700 (PDT) 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 h3SLXrhs001507 for ; Mon, 28 Apr 2003 14:33:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SLXxKw000388 for ; Mon, 28 Apr 2003 14:34:00 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id PAA08914 for ; Mon, 28 Apr 2003 15:33:46 -0600 (MDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3SLXi027143; Mon, 28 Apr 2003 14:33:44 -0700 (PDT) Message-Id: <200304282133.h3SLXi027143@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3531 on A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block 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: Mon, 28 Apr 2003 14:33:44 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3531 Title: A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block Author(s): M. Blanchet Status: Informational Date: April 2003 Mailbox: Marc.Blanchet@viagenie.qc.ca Pages: 7 Characters: 11314 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipv6-ipaddressassign-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3531.txt This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC 1219 and can be used for IPv6 assignments. 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: <030428143217.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3531 --OtherAccess Content-Type: Message/External-body; name="rfc3531.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030428143217.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 Mon Apr 28 14:49: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 h3SLnZhs001826; Mon, 28 Apr 2003 14:49:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SLnZYr001825; Mon, 28 Apr 2003 14:49:35 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h3SLnWhs001818 for ; Mon, 28 Apr 2003 14:49:32 -0700 (PDT) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h3SLnc2g906612 for ; Mon, 28 Apr 2003 14:49:38 -0700 (PDT) Received: (from okie@localhost) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SLncV8906610 for ipng@sunroof.eng.sun.com; Mon, 28 Apr 2003 14:49:38 -0700 (PDT) Date: Mon, 28 Apr 2003 14:49:38 -0700 From: Renee Danson To: ipng@sunroof.eng.sun.com Subject: new dmca laws and rfc 3041 Message-ID: <20030428214938.GD904583@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've started hearing some concerns about the "Super-DMCA" legislation that various states in the US are considering or have already passed. It seems like these laws could have all kinds of bad consequences; among other things, they have provisions that could be interpreted as making RFC 3041 illegal. An article on the EFF's web site[1] mentions provisions that ban devices that "conceal...the existence or place of origin or destination of any communication." This raises concern for all kinds of things that are currently in more widespread use than RFC 3041, such as VPNs and NAT. But an implementation of RFC 3041 could be viewed as a tool which helps users to conceal their IP address, and thus the "place of origin" of communication. So, what do folks think about this? Should implementors make any changes to their RFC 3041 implementations in light of these laws? -renee [1] http://www.eff.org/IP/DMCA/states/200304_sdmca_eff_analysis.php -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 15:02: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 h3SM21hs002075; Mon, 28 Apr 2003 15:02:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SM20Ag002074; Mon, 28 Apr 2003 15:02:00 -0700 (PDT) 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 h3SM1vhs002067 for ; Mon, 28 Apr 2003 15:01:57 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SM23Kw010897 for ; Mon, 28 Apr 2003 15:02:04 -0700 (PDT) Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3SM1wrZ005435 for ; Mon, 28 Apr 2003 15:01:58 -0700 (PDT) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3SM1hd0021447; Mon, 28 Apr 2003 18:01:44 -0400 (EDT) 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.3.3-GR) with ESMTP id ADQ35431; Mon, 28 Apr 2003 15:00:23 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA01949; Mon, 28 Apr 2003 15:00:23 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16045.42103.34193.832949@thomasm-u1.cisco.com> Date: Mon, 28 Apr 2003 15:00:23 -0700 (PDT) To: Fred Baker Cc: "Christian Huitema" , "Pekka Savola" , Subject: RE: Operational Renumbering Procedure In-Reply-To: <5.2.0.9.2.20030427203349.058defa8@mira-sjc5-b.cisco.com> References: <5.2.0.9.2.20030427203349.058defa8@mira-sjc5-b.cisco.com> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred Baker writes: > I would argue that an enterprise legitimately using any prefix with any > ISP, whether it is one or many, is responsible to tell the ISP it is doing > so. The ISP might not be contracted to accept the route or to route to that > prefix, but it should not be filtering out traffic using it. Fred, I'm completely lost. An ISP certainly has the right to do RPF checking, and is encouraged to do so with BCP 38. If I put a source address of ISP A into a packet and it's routed to ISP B's link for whatever reason, it will be filtered by ISP B by default (or at least should). So it seems that Christian has a valid point. And operationally I wonder what "telling the ISP" might be. They allow me to inject a route? Does that apply to my DSL service provider when I use my cable service provider's prefix? Is there technology, security and business reasons for an ISP to do this? 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 Apr 28 15:38:06 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 h3SMc5hs002384; Mon, 28 Apr 2003 15:38:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SMc5Ax002383; Mon, 28 Apr 2003 15:38:05 -0700 (PDT) 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 h3SMc2hs002376 for ; Mon, 28 Apr 2003 15:38:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SMc8uc024786 for ; Mon, 28 Apr 2003 15:38:08 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA27466 for ; Mon, 28 Apr 2003 16:38:03 -0600 (MDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 28 Apr 2003 15:37:59 -0700 Reply-To: From: "Tony Hain" To: "'Renee Danson'" , Subject: RE: new dmca laws and rfc 3041 Date: Mon, 28 Apr 2003 15:37:54 -0700 Message-ID: <065101c30dd6$d1067690$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030428214938.GD904583@jurassic.eng.sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3SMc2hs002377 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Renee Danson wrote: > I've started hearing some concerns about the "Super-DMCA" > legislation that various states in the US are considering or > have already passed. It seems like these laws could have all > kinds of bad consequences; among other things, they have > provisions that could be interpreted as making RFC 3041 > illegal. An article on the EFF's web site[1] mentions > provisions that ban devices that "conceal...the existence or > place of origin or destination of any communication." > > This raises concern for all kinds of things that are > currently in more widespread use than RFC 3041, such as VPNs > and NAT. But an implementation of RFC 3041 could be viewed > as a tool which helps users to conceal their IP address, and > thus the "place of origin" of communication. > > So, what do folks think about this? Should implementors make > any changes to their RFC 3041 implementations in light of these laws? RFC 3041 does not conceal the IP address, or place of origin. All it does is limit the valid timeframe for that pairing. There is nothing illegal about showing up at a Starbucks, acquiring an IPv4 address using DHCP, then requesting a different one after a short period of time. Use of 3041 addresses has exactly the same technical effect. Besides being unnecessary, it is probably not wise to guess where decisions on legal issues will end up. That is a sure way to rebuilding the code many times. 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 Apr 28 16:20: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 h3SNKphs002902; Mon, 28 Apr 2003 16:20:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3SNKp1i002901; Mon, 28 Apr 2003 16:20:51 -0700 (PDT) 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 h3SNKlhs002894 for ; Mon, 28 Apr 2003 16:20:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3SNKsuc007967 for ; Mon, 28 Apr 2003 16:20:54 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA23758 for ; Mon, 28 Apr 2003 17:20:48 -0600 (MDT) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h3SNKFvm028013; Mon, 28 Apr 2003 16:20:15 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h3SNKEg0028012; Mon, 28 Apr 2003 16:20:14 -0700 (PDT) Date: Mon, 28 Apr 2003 16:20:14 -0700 From: Shannon -jj Behrens To: ipng@sunroof.eng.sun.com, Brian McGehee , Dan Lanciani Subject: Re: prefix delegation service Message-ID: <20030428232014.GA27610@alicia.nttmcl.com> References: <20030428190716.GB23370@alicia.nttmcl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030428190716.GB23370@alicia.nttmcl.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Fellow IETF Participants, I will be removing this service effective immediately. Best Regards, -jj On Mon, Apr 28, 2003 at 12:07:16PM -0700, Shannon -jj Behrens wrote: > Just to throw some simple code out with my ideas, I've created a simple prefix > delegation service to delegate unique, provider-independent, non-globally > routed IPv6 prefixes for use with disconnected or intermittently-connected > networks. The site is at: > > > > Here are some notes: > > o I'm currently using the prefix fcc0::/16, although this can easily be > changed: > - I think delegating from fec0::/10 is probably out of the question since > this prefix is being deprecated. > - I think creating a new prefix such as fcc0::/16 has the benefit that > delegated prefixes will be instantly recognizable (although, in general, > such prefixes should be treated as normal global unicast space). > - I think using a prefix allocated by an RIR from 2002::/16 would make a lot > of sense since the RIR could allocate such prefixes to anyone wishing to > provide a similar service. > > o I have rate-limited the delegations so that: > - No more than 10000 delegations can happen per day. > - A connecting /24 (in IPv4) or /48 (in IPv6) can only receive 10 delegations > per day. > > o All I ask for is an email address so that I can contact the user if there > was a mistake in allocating the prefix or if the prefix is no longer valid. > > If anyone wants a copy of the code under a BSD license, shoot me an email. > > Thanks, > -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 Mon Apr 28 18:28: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 h3T1Sphs004344; Mon, 28 Apr 2003 18:28:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3T1SpTh004339; Mon, 28 Apr 2003 18:28:51 -0700 (PDT) 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 h3T1Smhs004331 for ; Mon, 28 Apr 2003 18:28:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3T1Ssuc011723 for ; Mon, 28 Apr 2003 18:28:54 -0700 (PDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3T1SnrZ027016 for ; Mon, 28 Apr 2003 18:28:49 -0700 (PDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3T1RbF4022021; Mon, 28 Apr 2003 18:28:47 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (rtp-vpn1-1198.cisco.com [10.82.228.174]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGO05976; Mon, 28 Apr 2003 18:22:02 -0700 (PDT) Message-Id: <5.2.0.9.2.20030428150406.00b1ddb8@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Apr 2003 15:09:51 -0700 To: "Michel Py" From: Fred Baker Subject: RE: Operational Renumbering Procedure Cc: In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5045799@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 At 02:40 PM 4/25/2003 -0700, Michel Py wrote: >how do you make renumbering easy when the following (with matching SNMP >config) is a requirement: > >line vty 0 4 > no login > transport input none I think the fundamental answer is that the same procedure can be applied, but the duration will be (much) longer or the cost (much) will be higher, and perhaps (very probably) both. The ISP will have to transport appropriate operational staff to each relevant site, have them manually enter the required configuration changes, and proceed on. In the case that the trusted staff is relatively small (the only reason I can think of why someone would remove the permission from other operational staff), and especially in view of the fact that this procedure calls for as many as three visits to each site if not each network device (to add a prefix, to enable its use as a source address, and to remove the old prefix), the operation seems doomed to extreme griping. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 18:28: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 h3T1Suhs004350; Mon, 28 Apr 2003 18:28:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3T1SuYJ004349; Mon, 28 Apr 2003 18:28:56 -0700 (PDT) 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 h3T1Sphs004338 for ; Mon, 28 Apr 2003 18:28:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3T1Svuc011742 for ; Mon, 28 Apr 2003 18:28:57 -0700 (PDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3T1SqrZ027025 for ; Mon, 28 Apr 2003 18:28:52 -0700 (PDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3T1RbF2022021; Mon, 28 Apr 2003 18:28:43 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (rtp-vpn1-1198.cisco.com [10.82.228.174]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGO05970; Mon, 28 Apr 2003 18:21:56 -0700 (PDT) Message-Id: <5.2.0.9.2.20030428145842.00b1e1a8@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Apr 2003 15:01:47 -0700 To: Pekka Savola From: Fred Baker Subject: RE: Operational Renumbering Procedure Cc: Christian Huitema , In-Reply-To: References: <5.2.0.9.2.20030427203349.058defa8@mira-sjc5-b.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:00 PM 4/28/2003 +0300, Pekka Savola wrote: >>His presupposition is that folks would be attempting to use the new >>prefix to send traffic into the network. If they do, I'll argue that >>something isn't as specified; that shouldn't happen until the next step, >>when the new prefix becomes the preferred prefix in RFC 2462-speak (and >>therefore might be used as a source address), > >This is a bit different ordering of events as one would suppose. To make >that work, you'd have to advertise prefixes with preferred_lifetime=0 and >have the hosts configure them as deprecated. I'm not sure if that'd work, >and whether there might be similar other issues. You also >can't configure any manual addresses as you typically can't set them >deprecated. It seems to me, on further consideration, that you may have identified an issue in RFC 2462. If the network administrator cannot deploy a new prefix without it automatically coming into use in some set of cases, he cannot renumber without his network experiencing some level of outage while he does so or until routing has converged. Who is the proper target of a complaint with 2462? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 18:38: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 h3T1cWhs004744; Mon, 28 Apr 2003 18:38:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3T1cW73004743; Mon, 28 Apr 2003 18:38:32 -0700 (PDT) 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 h3T1cShs004736 for ; Mon, 28 Apr 2003 18:38:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3T1cYuc013911 for ; Mon, 28 Apr 2003 18:38:34 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id TAA13525 for ; Mon, 28 Apr 2003 19:38:28 -0600 (MDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 28 Apr 2003 18:38:26 -0700 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , "'Bob Hinden'" Cc: , "'Thomas Narten'" , "'Erik Nordmark'" Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Mon, 28 Apr 2003 18:38:26 -0700 Message-ID: <066f01c30df0$07ae4740$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5.1.0.14.2.20030428165715.046a3888@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3T1cThs004737 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > (3) You do not believe that there is rough consensus to > deprecate IPv6 site-local addressing, because people > provided different reasons for why they believe that > IPv6 site-local addressing should be deprecated. In > particular, some people want to deprecate the particular > model of site-local addressing defined in the scoped > addressing architecture (ambiguous, scoped addresses), > while others do not believe that we need a local > addressing mechanism at all. I was not objecting to 'different reasons'. The specific complaint is that many of YES votes were for removing the architectural construct, or need for applications to deal with addresses that are only accessable over a limited scope. That is not in the purview of the IETF to decide, it is an operational decision of the network manager. Those votes are not valid as a result. > Point (1): > > The chairs do not believe that deprecating IPv6 site-local > addressing is an incorrect technical decision that will place > the work output of the IPv6 WG in jeopardy. > > The consensus was to "deprecate" the usage of site-local > addressing instead of simply removing it. By asking an ambiguous question, it is easy to insert your interpretation as the collective consensus. How convenient. SF question -- ... how many people think that we should deprecate SL addressing? Mail list question -- Should we deprecate IPv6 site-local unicast addressing? Neither of those mention 'usage'. In fact if you watch the video of SF, you will find that you spent much more time talking about elimination than anything else. > This was done > purposely to avoid interference with any current > implementations or deployments that might use site-local > addressing. In addition to the time it will take to formally > deprecate site-local addressing by publishing an RFC, the WG > understands that it will take some time after the publication > of an RFC for implementations to change. The decision to > deprecate site-local addressing, rather than simply removing > it, was made to avoid harm to IPv6. There was no decision. You had an inconclusive discussion with Keith, then later a vague discussion with Thomas about a 'hand wave'. Neither of those even come close to a decision, let alone a WG decision. Are we supposed to just say YES to any ambiguous question you ask, so you can make up the content of the consensus later? > > In fact, we believe that the previous disagreement over the > usage of IPv6 site-local addressing was damaging to the WG, > and that our lack of consensus was delaying our work, > particularly on the IPv6 scoped addressing architecture. While you may believe that the disagreement over SL was delaying the work, most of those disagreements stemmed from a lack of agreement over the fundamental requirements. Removing SL does not solve the basic problems that need to be addressed in the scoped addressing architecture. > The > consensus to deprecate site-local addressing will allow us to > move forward and complete our work. No it won't. A scoped address architecture document that ignores the reality of addresses that are only reachable within a limited part of the network is incomplete on its major point. It is absolutely useless to pretend that we have a document that discusses a scoped architecture when the case for the majority of nodes in the Internet is missing. > > --- > Point (2): > > The question was: > > "Should we deprecate IPv6 site-local unicast > addressing?" Possible answers were YES or NO. > > The chairs believe that this question was sufficiently clear > to be understood by the WG. Clearly you didn't watch the video of the SF meeting. Why would Thomas, Keith, Dave, and Christian make a specific point of trying to clarify the question if it was clear to begin with? Since the question didn't change, it remained just as unclear as it started, and none of the 'somewhere to the left' & 'hand wave' comments were sent to the list. > This is supported by the following > points: > > - Over 200 people responded to the question. > > - Many of the responses on the list (both YES and NO > responses) included reasons or comments that > followed from the question in a way that indicated > that the responders understood the question. I disagree. Many of the responses indicated what they meant by saying yes, which is not the same as understanding the question. In fact, their need to explain what question they were answering is an implicit statement of lack of clarity in the question. > > - There were only three requests for clarification of > this consensus call on the mailing list, two of which > were procedural. All of these requests were answered > promptly by the chairs. > > - The chairs sent the consensus results to the list > over two weeks ago, including a course of action for > the deprecation of site-local addressing. There > have been no objections from people who originally > expressed YES opinions that the chairs' course of > action fails to match their expectations. Why would there be? They all have their own interpretations, so there won't be objections until the actual next steps begin. > > --- > > Point (3): > > The chairs do not believe that consensus on an issue is > invalidated by the fact that people have multiple reasons for > coming to the same conclusion. We suspect that this happens > in most WG consensus calls, and this is not a reason to > invalidate the consensus. You missed the point that many of those responses are for an architectural change that is not in the IETF's purview to decide. See above. > > All of the groups that you mentioned in your message agreed > that IPv6 site-local unicast addressing should be deprecated. No, some of them believed this is about removing local scoped addresses from the architecture, or consideration by applications. That is not the same as 'usage' of a defined prefix. > They may disagree on what we should do after deprecating > site- local addressing, but that does not invalidate the > consensus on this point. There is a vast and architectural difference between removing addresses which are only reachable over a limited part of the network, and usage of a specific prefix to identify those. You keep claiming there is a consensus, but any objective observer of the SF video would disagree. > > --- > > Point (4): > > It is true that the IPv6 WG has not produced a WG document > that analyzes the operational requirements for local > addressing. However, we do not believe that this is a reason > to invalidate the IPv6 WG consensus to deprecate IPv6 > site-local unicast addressing. You said it multiple times in SF yourself, the WG needs complete documentation to do an appropriate analysis. You appear to be letting your desire to 'be right' get in the way of your ability to analyze your own responses. I don't understand how can you objectively say 'we don't need a document describing the need for X to decide that we don't need X'? > > There has been considerable discussion and analysis of site- > local addressing performed over the past year, including > extensive discussions during three IETF sessions. There have > also been several drafts published on the subject, including > one draft that attempts to analyze the cost/benefit > trade-offs of site-local addressing. There have been personal drafts. The WG has not taken this on as a specific work item. > > This period of discussion has offered sufficient time for > anyone who has an operational need for any of the > currently-defined usage models of site-local addressing to > document those requirements in an Internet-Draft and/or to > discuss those requirements on the IPv6 mailing list. They have been discussed on the mail list to the point that people stop paying attention. This argument is disingenuous because there has never been a WG item about creating this document. In addition, I have offered a draft on the subject multiple times in the last month, yet have not even received as much as a simple 'no thanks' from the chairs. > > During our discussions, several operational benefits of > site-local addressing have been raised on the IPv6 WG mailing > list, including benefits for disconnected sites, > intermittently- connected sites, renumbered sites, etc. We > have also uncovered several issues and complexities caused by > the current model of ambiguous, scoped site-local addressing, > and we have determined that this particular model places > burdens on other parts of the TCP/IP protocol suite, > particularly routing protocols and applications. Most of those difficulties will persist, because they are the result of inconsistent views of the network topology. There is nothing about deprecating SL that will change this. The only affect will be to make it harder to figure out when the burdens exist. > > In a recent phone discussion and in your appeal > clarification, you have indicated that the chairs should void > responses from people who do not think that the IPv6 WG > should specify any type of local addressing mechanism, > because you believe that those responders are uninformed > about the operational conditions that require the use of > local addressing. > > While operational necessity is certainly an appropriate > argument to raise in support of your position that the IPv6 > WG should specify some mechanism for local addressing, the > fact that you disagree with the reasons that some people > offered for why they want to deprecate the current IPv6 > site-local unicast addressing mechanism does not invalidate > their contribution to this consensus call. I am pointing out that their 'reason' is not in the purview of the IETF to decide, so their YES votes are not informed or valid. I am not objecting to their opinion, just the chair's interpretation of consensus is in error because it fails to discount the votes for an architectural point that is out of the IETF's control. > > It is the opinion of the chairs that the IPv6 WG did have > sufficient information to make an informed decision regarding > whether or not to deprecate IPv6 site-local unicast addressing. Even though a long-term member of the WG said right before the question that he did not have enough information to vote NO ... and another participant stated he had never heard the requirements before Erik gave a verbal partial list. How do these create 'an informed decision'? > > --- > > So, to summarize, the chairs do not agree with the points > that you have raised in your appeal, and we do not agree to > overturn the consensus of the IPv6 WG based on the issues > that you have raised. I am not surprised. > > Tony, while we disagree with your position on this particular > issue, we do respect your contributions to the IPv6 effort > and we realize that your appeal is motivated by your desire > to do the right thing for IPv6. We hope that you will accept > our response to your appeal and focus on working to define > the local addressing problem and solutions as we outlined in > our email to the list. We think it is important for the > working group to move forward on this issue. I will be escalating to Erik & Thomas, because I do believe that is the right and expeditious thing to do in this case. 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 Apr 28 18:43: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 h3T1hqhs004925; Mon, 28 Apr 2003 18:43:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3T1hp5Q004924; Mon, 28 Apr 2003 18:43:51 -0700 (PDT) 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 h3T1hmhs004917 for ; Mon, 28 Apr 2003 18:43:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3T1hsKw019145 for ; Mon, 28 Apr 2003 18:43:54 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id TAA15219 for ; Mon, 28 Apr 2003 19:43:48 -0600 (MDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 28 Apr 2003 18:43:46 -0700 Reply-To: From: "Tony Hain" To: "'Thomas Narten'" , "'Erik Nordmark'" Cc: , "'Bob Hinden'" , "'Margaret Wasserman'" Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Mon, 28 Apr 2003 18:43:47 -0700 Message-ID: <067001c30df0$c7ae0ad0$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5.1.0.14.2.20030428165715.046a3888@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3T1hmhs004918 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas & Erik, I trust that you will take a more objective view of this, because any outsider who needs to watch that video will be rolling in the isles with laughter at the absurdity of the process abuse in this case. At least 5 long-time IETF participants (including yourself) felt the need to state what they meant by 'deprecate SL'. One has to assume they bothered to assert their interpretation because the YES/NO question was unclear to them, or that their need to explain which question they were answering is an implicit statement that the original question was unclear. Even though the question never changed, none of the (amazingly vague) clarifying remarks in SF were sent to the list version of the consensus call. If a legal professional were to watch the proceedings here, they would comment that the WG gave the chairs the freedom to interpret the meaning of the question any way they choose. In fact we have examples of that already on the mail list and in this response. 3/30 chair email claimed > 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. That question was never asked of the room, and those statements were not made by the chairs in SF. How could there be an agreement? > The decision to deprecate site-local addressing, > rather than simply removing it, was made to avoid > harm to IPv6. There was nothing more to this than vague conversations between Margaret & Keith, and Margaret & Thomas. There was no decision by the WG, just a chair proclamation that one had occurred. We can't allow the WG process to degenerate to the point that a chair can call an ambiguous YES/NO question, then make up anything they choose to have it mean later. In particular, when the chair explicitly states '... if we eliminate it we will also have multiple choices about what exactly that means ...', and '... may have to hand wave ...' there is not a clear indication about what question is being asked. I put specific rebuttal comments to the chair's rejection in a list response to the chairs. In summary I believe the chairs have declared a consensus when there really wasn't one due to the ambiguity of the question. Specifically the YES votes for removing addresses with local scope from the architecture or consideration by applications are void, as that is not something the IETF gets to decide. Had the chairs asked Keith's original question about finding an alternate way forward through replacement technologies, we would not be going through this process. As for a path forward, I would expect you to invalidate the consensus, then have the WG stop the pronouncements that SL is dead, and work on finding appropriate replacements. This effort must begin with identification of the requirements for addresses of local scope, and under local network manager control. With requirements in hand, the scoped address architecture document needs to specifically deal with handling mixed scope addresses, both between and for simultaneous use on a singe node. That document in particular is hopelessly gutted and meaningless without such a discussion. IF we get to the point were all requirements are met by alternatives, the current SL definition should appropriately be moved to historic. If not, it will likely end up in the corner case use that Keith was trying to achieve. Either way, the entire WG must decide exactly what happens. We must not allow the 'ambiguous YES/NO question - chairs subsequently decide what it means', process to set a precedent. Tony Margaret Wasserman wrote: > Hi Tony, > > We have considered your appeal regarding the IPv6 WG > consensus to deprecate site-locals. Based on our analysis, > we believe that your appeal makes the following points: > > (1) You believe that deprecating IPv6 site-local unicast > addressing is an incorrect technical choice that places > the work output of the IPv6 WG in jeopardy. > > (2) You believe that the question asked by the chairs > was insufficiently clear to be understood properly > by the WG. > > (3) You do not believe that there is rough consensus to > deprecate IPv6 site-local addressing, because people > provided different reasons for why they believe that > IPv6 site-local addressing should be deprecated. In > particular, some people want to deprecate the particular > model of site-local addressing defined in the scoped > addressing architecture (ambiguous, scoped addresses), > while others do not believe that we need a local > addressing mechanism at all. > > (4) You believe that it is invalid for the IPv6 WG to > deprecate site-local addressing without publishing an > IPv6 WG document that analyzes the operational requirements > for local addressing. Without this analysis document, you > believe that the IPv6 WG has made an uninformed choice. > > We will now respond to each of your points. > > -- > > Point (1): > > The chairs do not believe that deprecating IPv6 site-local > addressing is an incorrect technical decision that will place > the work output of the IPv6 WG in jeopardy. > > The consensus was to "deprecate" the usage of site-local > addressing instead of simply removing it. This was done > purposely to avoid interference with any current > implementations or deployments that might use site-local > addressing. In addition to the time it will take to formally > deprecate site-local addressing by publishing an RFC, the WG > understands that it will take some time after the publication > of an RFC for implementations to change. The decision to > deprecate site-local addressing, rather than simply removing > it, was made to avoid harm to IPv6. > > In fact, we believe that the previous disagreement over the > usage of IPv6 site-local addressing was damaging to the WG, > and that our lack of consensus was delaying our work, > particularly on the IPv6 scoped addressing architecture. The > consensus to deprecate site-local addressing will allow us to > move forward and complete our work. > > --- > Point (2): > > The question was: > > "Should we deprecate IPv6 site-local unicast > addressing?" Possible answers were YES or NO. > > The chairs believe that this question was sufficiently clear > to be understood by the WG. This is supported by the following > points: > > - Over 200 people responded to the question. > > - Many of the responses on the list (both YES and NO > responses) included reasons or comments that > followed from the question in a way that indicated > that the responders understood the question. > > - There were only three requests for clarification of > this consensus call on the mailing list, two of which > were procedural. All of these requests were answered > promptly by the chairs. > > - The chairs sent the consensus results to the list > over two weeks ago, including a course of action for > the deprecation of site-local addressing. There > have been no objections from people who originally > expressed YES opinions that the chairs' course of > action fails to match their expectations. > > --- > > Point (3): > > The chairs do not believe that consensus on an issue is > invalidated by the fact that people have multiple reasons for > coming to the same conclusion. We suspect that this happens > in most WG consensus calls, and this is not a reason to > invalidate the consensus. > > All of the groups that you mentioned in your message agreed > that IPv6 site-local unicast addressing should be deprecated. > They may disagree on what we should do after deprecating > site- local addressing, but that does not invalidate the > consensus on this point. > > --- > > Point (4): > > It is true that the IPv6 WG has not produced a WG document > that analyzes the operational requirements for local > addressing. However, we do not believe that this is a reason > to invalidate the IPv6 WG consensus to deprecate IPv6 > site-local unicast addressing. > > There has been considerable discussion and analysis of site- > local addressing performed over the past year, including > extensive discussions during three IETF sessions. There have > also been several drafts published on the subject, including > one draft that attempts to analyze the cost/benefit > trade-offs of site-local addressing. > > This period of discussion has offered sufficient time for > anyone who has an operational need for any of the > currently-defined usage models of site-local addressing to > document those requirements in an Internet-Draft and/or to > discuss those requirements on the IPv6 mailing list. > > During our discussions, several operational benefits of > site-local addressing have been raised on the IPv6 WG mailing > list, including benefits for disconnected sites, > intermittently- connected sites, renumbered sites, etc. We > have also uncovered several issues and complexities caused by > the current model of ambiguous, scoped site-local addressing, > and we have determined that this particular model places > burdens on other parts of the TCP/IP protocol suite, > particularly routing protocols and applications. > > In a recent phone discussion and in your appeal > clarification, you have indicated that the chairs should void > responses from people who do not think that the IPv6 WG > should specify any type of local addressing mechanism, > because you believe that those responders are uninformed > about the operational conditions that require the use of > local addressing. > > While operational necessity is certainly an appropriate > argument to raise in support of your position that the IPv6 > WG should specify some mechanism for local addressing, the > fact that you disagree with the reasons that some people > offered for why they want to deprecate the current IPv6 > site-local unicast addressing mechanism does not invalidate > their contribution to this consensus call. > > It is the opinion of the chairs that the IPv6 WG did have > sufficient information to make an informed decision regarding > whether or not to deprecate IPv6 site-local unicast addressing. > > --- > > So, to summarize, the chairs do not agree with the points > that you have raised in your appeal, and we do not agree to > overturn the consensus of the IPv6 WG based on the issues > that you have raised. > > Tony, while we disagree with your position on this particular > issue, we do respect your contributions to the IPv6 effort > and we realize that your appeal is motivated by your desire > to do the right thing for IPv6. We hope that you will accept > our response to your appeal and focus on working to define > the local addressing problem and solutions as we outlined in > our email to the list. We think it is important for the > working group to move forward on this issue. > > Best Regards, > > Bob Hinden & Margaret Wasserman > IPv6 WG Chairs > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 28 19:37:14 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 h3T2bDhs005329; Mon, 28 Apr 2003 19:37:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3T2bD7u005328; Mon, 28 Apr 2003 19:37:13 -0700 (PDT) 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 h3T2b8hs005320 for ; Mon, 28 Apr 2003 19:37:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3T2bFKw029237 for ; Mon, 28 Apr 2003 19:37:15 -0700 (PDT) Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id UAA03198 for ; Mon, 28 Apr 2003 20:37:08 -0600 (MDT) Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h3T2b8Q9005285 for ; Mon, 28 Apr 2003 19:37:08 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h3T2b4QL005883 for ; Mon, 28 Apr 2003 21:37:05 -0500 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 h3T2b2VI016054 for ; Tue, 29 Apr 2003 12:37:03 +1000 (EST) Message-ID: <3EADE54E.F26B2D0C@motorola.com> Date: Tue, 29 Apr 2003 12:37:02 +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@sunroof.eng.sun.com Subject: Re: A simple question References: <5.1.0.14.2.20030427201951.03184c10@mail.windriver.com> <20030419151329.66daf0de.moore@cs.utk.edu> <20030419151329.66daf0de.moore@cs.utk.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <9522.1051548377@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > > While simplification is a good thing, I certainly don't feel that we > can sacrifice link local addressing to get it. And as long as we're > keeping link local, the extra complexity added by site local is close > to zero (and essentially would be zero if we eliminated multi-site nodes > from the architecture). Where multi-site means nodes that are simultaneously operating in two (potentially) overlapping address spaces distinguished from each other only by a 'site identifier'? -- Andrew White -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 20:23:18 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 h3T3NIhs005739; Mon, 28 Apr 2003 20:23:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3T3NHc1005738; Mon, 28 Apr 2003 20:23:17 -0700 (PDT) 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 h3T3NEhs005731 for ; Mon, 28 Apr 2003 20:23:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3T3NKuc029885 for ; Mon, 28 Apr 2003 20:23:21 -0700 (PDT) Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA19589 for ; Mon, 28 Apr 2003 21:23:15 -0600 (MDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3T3MUIX024784; Mon, 28 Apr 2003 20:23:00 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (rtp-vpn1-1198.cisco.com [10.82.228.174]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGO11605; Mon, 28 Apr 2003 20:01:30 -0700 (PDT) Message-Id: <5.2.0.9.2.20030428195416.057d3200@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Apr 2003 20:00:01 -0700 To: Michael Thomas From: Fred Baker Subject: RE: Operational Renumbering Procedure Cc: "Christian Huitema" , "Pekka Savola" , In-Reply-To: <16045.42103.34193.832949@thomasm-u1.cisco.com> References: <5.2.0.9.2.20030427203349.058defa8@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030427203349.058defa8@mira-sjc5-b.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:00 PM 4/28/2003 -0700, Michael Thomas wrote: >Fred Baker writes: > > I would argue that an enterprise legitimately using any prefix with any > > ISP, whether it is one or many, is responsible to tell the ISP it is > doing > > so. The ISP might not be contracted to accept the route or to route to > that > > prefix, but it should not be filtering out traffic using it. > >Fred, I'm completely lost. An ISP certainly has >the right to do RPF checking, My point is that the customer should be able to tell his ISP what addresses he is legitimately using, and therefore bias the ingress filter, regardless of whether he is singly homed or multi-homed. If I have address X, Y, and Z, and X is provided by ISP X', I should be able to send traffic from addresses x', y', and z' to any of my ISPs and have them forward them. Asking otherwise requires source-destination addressing (you have a separate route table, or at least egress router, for each source address prefix), which is not a feature of IP routing, whether v4 or v6. We can discuss providing same, if you like, or we can discuss customers refusing to buy services from ISPs that require of them things that are not provided in the IP architecture as presently defined. Take your pick. I think the net result of ISP intransigence is ISP bankruptcy. But that's just my opinion. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 22:39:35 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 h3T5dZhs006500; Mon, 28 Apr 2003 22:39:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3T5dZUa006499; Mon, 28 Apr 2003 22:39:35 -0700 (PDT) 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 h3T5dWhs006492 for ; Mon, 28 Apr 2003 22:39:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3T5dcKw028746 for ; Mon, 28 Apr 2003 22:39:38 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id XAA04037 for ; Mon, 28 Apr 2003 23:39:31 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3T5dLM17333; Tue, 29 Apr 2003 08:39:21 +0300 Date: Tue, 29 Apr 2003 08:39:20 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: Christian Huitema , Subject: RE: Operational Renumbering Procedure In-Reply-To: <5.2.0.9.2.20030428145842.00b1e1a8@mira-sjc5-b.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 Mon, 28 Apr 2003, Fred Baker wrote: > At 12:00 PM 4/28/2003 +0300, Pekka Savola wrote: > >>His presupposition is that folks would be attempting to use the new > >>prefix to send traffic into the network. If they do, I'll argue that > >>something isn't as specified; that shouldn't happen until the next step, > >>when the new prefix becomes the preferred prefix in RFC 2462-speak (and > >>therefore might be used as a source address), > > > >This is a bit different ordering of events as one would suppose. To make > >that work, you'd have to advertise prefixes with preferred_lifetime=0 and > >have the hosts configure them as deprecated. I'm not sure if that'd work, > >and whether there might be similar other issues. You also > >can't configure any manual addresses as you typically can't set them > >deprecated. > > It seems to me, on further consideration, that you may have identified an > issue in RFC 2462. If the network administrator cannot deploy a new prefix > without it automatically coming into use in some set of cases, he cannot > renumber without his network experiencing some level of outage while he > does so or until routing has converged. > > Who is the proper target of a complaint with 2462? RFC2461/2462 will be revised at some point (it's on charter), so the complain should be filed with the chairs and the authors (I believe), or maybe a specific I-D describing the particular problem (and that only). 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 Mon Apr 28 23:17: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 h3T6HUhs006745; Mon, 28 Apr 2003 23:17:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3T6HUrG006744; Mon, 28 Apr 2003 23:17:30 -0700 (PDT) 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 h3T6HRhs006737 for ; Mon, 28 Apr 2003 23:17:27 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3T6HXuc027466 for ; Mon, 28 Apr 2003 23:17:33 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id AAA14245 for ; Tue, 29 Apr 2003 00:17:27 -0600 (MDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3T6HPju033110 for ; Tue, 29 Apr 2003 08:17:25 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h3T6HOuj239588 for ; Tue, 29 Apr 2003 08:17:24 +0200 Received: from dhcp21-82.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA17808 from ; Tue, 29 Apr 2003 08:17:13 +0200 Message-Id: <3EAE190E.91CC5AF0@hursley.ibm.com> Date: Tue, 29 Apr 2003 08:17:50 +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: new dmca laws and rfc 3041 References: <065101c30dd6$d1067690$261e4104@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quite apart from what Tony says, which is completely true, possible marginal interpretations of bizarre laws in a few odd corners of the world such as Michigan mustn't be allowed to distort international standards. Such battles have to be fought locally. Brian Tony Hain wrote: > > Renee Danson wrote: > > I've started hearing some concerns about the "Super-DMCA" > > legislation that various states in the US are considering or > > have already passed. It seems like these laws could have all > > kinds of bad consequences; among other things, they have > > provisions that could be interpreted as making RFC 3041 > > illegal. An article on the EFF's web site[1] mentions > > provisions that ban devices that "conceal...the existence or > > place of origin or destination of any communication." > > > > This raises concern for all kinds of things that are > > currently in more widespread use than RFC 3041, such as VPNs > > and NAT. But an implementation of RFC 3041 could be viewed > > as a tool which helps users to conceal their IP address, and > > thus the "place of origin" of communication. > > > > So, what do folks think about this? Should implementors make > > any changes to their RFC 3041 implementations in light of these laws? > > RFC 3041 does not conceal the IP address, or place of origin. All it > does is limit the valid timeframe for that pairing. There is nothing > illegal about showing up at a Starbucks, acquiring an IPv4 address using > DHCP, then requesting a different one after a short period of time. Use > of 3041 addresses has exactly the same technical effect. > > Besides being unnecessary, it is probably not wise to guess where > decisions on legal issues will end up. That is a sure way to rebuilding > the code many times. > > 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 Apr 29 04:08:48 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 h3TB8mhs007646; Tue, 29 Apr 2003 04:08:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3TB8ljW007645; Tue, 29 Apr 2003 04:08:47 -0700 (PDT) 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 h3TB8ihs007638 for ; Tue, 29 Apr 2003 04:08:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3TB8pKw025166 for ; Tue, 29 Apr 2003 04:08:52 -0700 (PDT) Received: from kira.skynet.be (kira.skynet.be [195.238.2.125]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3TB8jrZ005047 for ; Tue, 29 Apr 2003 04:08:46 -0700 (PDT) Received: from tsn (28.181-200-80.adsl.skynet.be [80.200.181.28]) by kira.skynet.be (8.12.9/8.12.9/Skynet-OUT-2.21) with ESMTP id h3TB8XNR018111 for ; Tue, 29 Apr 2003 13:08:33 +0200 (envelope-from ) Message-Id: <200304291108.h3TB8XNR018111@kira.skynet.be> From: "Mario Goebbels" To: Subject: Question about RFC 3306 Date: Tue, 29 Apr 2003 13:08:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: Microsoft Outlook, Build 11.0.4920 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Thread-Index: AcMOP7QTtHHg78zVREeT1bjMW4JYOA== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3TB8jhs007639 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a question about those unicast-prefix based multicast addresses. Since the whole prefix is embedded in the multicast address, are those multicast groups globally reachable from whatever other subnet? Let's say if on prefix 3FFE:FFFF:1::/48 I generate the multicast prefix FF3E:0030:3FFE:FFFF:0001::/96, and thus let's assume want to send a packet to all nodes on that prefix, e.g. address FF3E:0030:3FFE:FFFF:0001::1 (assuming it's the same as in e.g. FF02::1), would this work? Thanks for any further information. -mg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 04:54: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 h3TBschs008345; Tue, 29 Apr 2003 04:54:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3TBscMm008344; Tue, 29 Apr 2003 04:54:38 -0700 (PDT) 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 h3TBsYhs008337 for ; Tue, 29 Apr 2003 04:54:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3TBsfKw002039 for ; Tue, 29 Apr 2003 04:54:42 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA04765 for ; Tue, 29 Apr 2003 05:54:36 -0600 (MDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h3TBsao29829; Tue, 29 Apr 2003 04:54:36 -0700 Received: from innovationslab.net ([63.109.132.2]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h3TCFJQe010575 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 29 Apr 2003 05:15:22 -0700 Message-ID: <3EAE67EF.4000503@innovationslab.net> Date: Tue, 29 Apr 2003 07:54:23 -0400 From: Brian Haberman 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: Mario Goebbels CC: ipng@sunroof.eng.sun.com Subject: Re: Question about RFC 3306 References: <200304291108.h3TB8XNR018111@kira.skynet.be> In-Reply-To: <200304291108.h3TB8XNR018111@kira.skynet.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mario Goebbels wrote: > I have a question about those unicast-prefix based multicast > addresses. Since the whole prefix is embedded in the multicast > address, are those multicast groups globally reachable from whatever > other subnet? Let's say if on prefix 3FFE:FFFF:1::/48 I generate the > multicast prefix FF3E:0030:3FFE:FFFF:0001::/96, and thus let's assume > want to send a packet to all nodes on that prefix, e.g. address > FF3E:0030:3FFE:FFFF:0001::1 (assuming it's the same as in e.g. > FF02::1), would this work? The reachability of the multicast address is determined by the scope field in the multicast prefix. In your case, FF3E is a globably scoped address and could be routed as such. However, nodes are not required to join ANY multicast address generated using this mechanism. So, you would not be able to reach all nodes in the 3FFE:FFFF:1::/48 prefix by sending a multicast message to FF3E:0030:3FFE:FFFF:1::1. 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 Tue Apr 29 06:06: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 h3TD6phs008777; Tue, 29 Apr 2003 06:06:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3TD6puj008776; Tue, 29 Apr 2003 06:06:51 -0700 (PDT) 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 h3TD6lhs008769 for ; Tue, 29 Apr 2003 06:06:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3TD6sKw014880 for ; Tue, 29 Apr 2003 06:06:54 -0700 (PDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id HAA09599 for ; Tue, 29 Apr 2003 07:06:46 -0600 (MDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h3TD6cvV001360; Tue, 29 Apr 2003 09:06:38 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h3TD6cF4001359; Tue, 29 Apr 2003 09:06:38 -0400 (EDT) Date: Tue, 29 Apr 2003 09:06:38 -0400 (EDT) From: Scott Bradner Message-Id: <200304291306.h3TD6cF4001359@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com, renee.danson@Sun.COM Subject: Re: new dmca laws and rfc 3041 In-Reply-To: <20030428214938.GD904583@jurassic.eng.sun.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk not good stuff see: http://www.nwfusion.com/columnists/2003/0407bradner.html but the copyright people have backed off in many states and changed the suggested wording to be somewhat more limited (though some states passed the outlaw-vpn version. Scott ---- From owner-ipng@sunroof.eng.sun.com Mon Apr 28 17:55:07 2003 Date: Mon, 28 Apr 2003 14:49:38 -0700 From: Renee Danson To: ipng@sunroof.eng.sun.com Subject: new dmca laws and rfc 3041 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've started hearing some concerns about the "Super-DMCA" legislation that various states in the US are considering or have already passed. It seems like these laws could have all kinds of bad consequences; among other things, they have provisions that could be interpreted as making RFC 3041 illegal. An article on the EFF's web site[1] mentions provisions that ban devices that "conceal...the existence or place of origin or destination of any communication." This raises concern for all kinds of things that are currently in more widespread use than RFC 3041, such as VPNs and NAT. But an implementation of RFC 3041 could be viewed as a tool which helps users to conceal their IP address, and thus the "place of origin" of communication. So, what do folks think about this? Should implementors make any changes to their RFC 3041 implementations in light of these laws? -renee [1] http://www.eff.org/IP/DMCA/states/200304_sdmca_eff_analysis.php -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Apr 29 08:01:30 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 h3TF1Uhs009529; Tue, 29 Apr 2003 08:01:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3TF1U0q009528; Tue, 29 Apr 2003 08:01:30 -0700 (PDT) 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 h3TF1Rhs009521 for ; Tue, 29 Apr 2003 08:01:27 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3TF1YKw010253 for ; Tue, 29 Apr 2003 08:01:34 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA06488 for ; Tue, 29 Apr 2003 09:01:28 -0600 (MDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h3TF1Ks15378; Tue, 29 Apr 2003 17:01:20 +0200 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 h3TF1Kof023839; Tue, 29 Apr 2003 17:01:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200304291501.h3TF1Kof023839@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Scott Bradner cc: ipng@sunroof.eng.sun.com, renee.danson@Sun.COM Subject: Re: new dmca laws and rfc 3041 In-reply-to: Your message of Tue, 29 Apr 2003 09:06:38 EDT. <200304291306.h3TD6cF4001359@newdev.harvard.edu> Date: Tue, 29 Apr 2003 17:01:20 +0200 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: not good stuff see: http://www.nwfusion.com/columnists/2003/0407bradner.html but the copyright people have backed off in many states and changed the suggested wording to be somewhat more limited (though some states passed the outlaw-vpn version. => in a nearly funny way, here in Europe our laws are more and more towards the opposite side: IP addresses are considered as personal data and should be hidden... RFC 3041 is not yet mandatory just because it takes (a lot of) time. Regards Francis.Dupont@enst-bretagne.fr PS: cf the WP58 document (I have a PDF version, ask me). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 08:20: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 h3TFKchs009733; Tue, 29 Apr 2003 08:20:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3TFKcXj009732; Tue, 29 Apr 2003 08:20:38 -0700 (PDT) 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 h3TFKXhs009722 for ; Tue, 29 Apr 2003 08:20:33 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3TFKeuc021604 for ; Tue, 29 Apr 2003 08:20:40 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA01430 for ; Tue, 29 Apr 2003 09:20:34 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.12.8/8.12.8) with ESMTP id h3TFKT2Y013209; Tue, 29 Apr 2003 10:20:30 -0500 (CDT) Message-Id: <200304291520.h3TFKT2Y013209@gungnir.fnal.gov> To: Stephen Sprunk Cc: ipng@sunroof.eng.sun.com, ietf@ietf.org From: "Matt Crawford" Subject: Re: A simple question In-reply-to: Your message of Mon, 28 Apr 2003 11:23:25 CDT. <00b401c30da4$390d81d0$93b58742@ssprunk> Date: Tue, 29 Apr 2003 10:20:29 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > When you are talking about tens of millions of customers, it's not feasible > to give each a subnet even if you have the space to do it. Why on earth not? You give them one "thing" either way. Same overhead to issue, same overhead to route. > There is nothing to indicate that ISPs are going to change their business > models simply because IPv6 address space is plentiful; they charge extra for > two hosts because it is assumed two hosts consume more bits than one, not > because a second IPv4 address is hard to come by. This is not the least bit believable. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 12:24: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 h3TJO9hs011224; Tue, 29 Apr 2003 12:24:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3TJO8tH011223; Tue, 29 Apr 2003 12:24:08 -0700 (PDT) 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 h3TJO5hs011216 for ; Tue, 29 Apr 2003 12:24:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3TJOCKw011128 for ; Tue, 29 Apr 2003 12:24:12 -0700 (PDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA29286 for ; Tue, 29 Apr 2003 13:24:06 -0600 (MDT) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3TJNpYf012653; Tue, 29 Apr 2003 12:23:51 -0700 (PDT) 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.3.3-GR) with ESMTP id ADR18624; Tue, 29 Apr 2003 12:23:47 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA06911; Tue, 29 Apr 2003 12:23:46 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16046.53570.808621.138831@thomasm-u1.cisco.com> Date: Tue, 29 Apr 2003 12:23:46 -0700 (PDT) To: Fred Baker Cc: Michael Thomas , "Christian Huitema" , "Pekka Savola" , Subject: RE: Operational Renumbering Procedure In-Reply-To: <5.2.0.9.2.20030428195416.057d3200@mira-sjc5-b.cisco.com> References: <5.2.0.9.2.20030427203349.058defa8@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030428195416.057d3200@mira-sjc5-b.cisco.com> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred Baker writes: > At 03:00 PM 4/28/2003 -0700, Michael Thomas wrote: > >Fred, I'm completely lost. An ISP certainly has > >the right to do RPF checking, > > My point is that the customer should be able to tell his ISP what addresses > he is legitimately using, and therefore bias the ingress filter, regardless > of whether he is singly homed or multi-homed. If I have address X, Y, and > Z, and X is provided by ISP X', I should be able to send traffic from > addresses x', y', and z' to any of my ISPs and have them forward them. A few questions: 1) How do I assert the prefix in a way that my ISP would trust me? There are obvious security issues here. 2) At what scale would you expect this to work? If not my home between my cable and DSL provider, then how big? And is it acceptible to write those small fries off? > Asking otherwise requires source-destination addressing (you have a > separate route table, or at least egress router, for each source address > prefix), which is not a feature of IP routing, whether v4 or v6. We can > discuss providing same, if you like, or we can discuss customers refusing > to buy services from ISPs that require of them things that are not provided > in the IP architecture as presently defined. Take your pick. > > I think the net result of ISP intransigence is ISP bankruptcy. But that's > just my opinion. Well I'd say that something runs counter to BCP 38 is going to run into a lot of operational resistance, to say the least. Depending on the answers to the above, I'm not sure that this is solely a matter of ISP intransigence. 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 Apr 29 13:30: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 h3TKUNhs011649; Tue, 29 Apr 2003 13:30:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3TKUNCW011648; Tue, 29 Apr 2003 13:30:23 -0700 (PDT) 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 h3TKUJhs011641 for ; Tue, 29 Apr 2003 13:30:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3TKUPuc029598 for ; Tue, 29 Apr 2003 13:30:26 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA16453 for ; Tue, 29 Apr 2003 14:30:20 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.12.8/8.12.8) with ESMTP id h3TKUI2Y000410; Tue, 29 Apr 2003 15:30:18 -0500 (CDT) Message-Id: <200304292030.h3TKUI2Y000410@gungnir.fnal.gov> To: Valdis.Kletnieks@vt.edu Cc: ipng@sunroof.eng.sun.com, ietf@ietf.org From: "Matt Crawford" Subject: Re: A simple question In-reply-to: Your message of Tue, 29 Apr 2003 13:33:28 EDT. <200304291733.h3THXSFn006587@turing-police.cc.vt.edu> Date: Tue, 29 Apr 2003 15:30:18 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > ... they charge extra for two hosts because it is > > > assumed two hosts consume more bits than one, not because a > > > second IPv4 address is hard to come by. > > > > This is not the least bit believable. > > It's quite believable, in the context of blah blah blah ... Nothing you've said establishes any likelihood that the reason for charging more is the expected consumption of more bits. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 14: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 h3TLmVhs012102; Tue, 29 Apr 2003 14:48:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3TLmVQI012101; Tue, 29 Apr 2003 14:48:31 -0700 (PDT) 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 h3TLmRhs012094 for ; Tue, 29 Apr 2003 14:48:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3TLmYKw026980 for ; Tue, 29 Apr 2003 14:48:34 -0700 (PDT) Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id PAA07306 for ; Tue, 29 Apr 2003 15:48:25 -0600 (MDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3TLm71O025679; Tue, 29 Apr 2003 14:48:08 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (dhcp-64-100-225-55.cisco.com [64.100.225.55]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGO93196; Tue, 29 Apr 2003 14:43:53 -0700 (PDT) Message-Id: <5.2.0.9.2.20030429173403.02b11800@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Apr 2003 17:47:40 -0400 To: Michael Thomas From: Fred Baker Subject: RE: Operational Renumbering Procedure Cc: Michael Thomas , "Christian Huitema" , "Pekka Savola" , In-Reply-To: <16046.53570.808621.138831@thomasm-u1.cisco.com> References: <5.2.0.9.2.20030428195416.057d3200@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030427203349.058defa8@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030428195416.057d3200@mira-sjc5-b.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:23 PM 4/29/2003 -0700, Michael Thomas wrote: >1) How do I assert the prefix in a way that my ISP > would trust me? There are obvious security issues here. I would expect that this would either be by contract or by BGP, using the ISP/customer security environment (hopefully BGP/TCP+MD5 or IPSEC) that is in use today. >2) At what scale would you expect this to work? If not my home > between my cable and DSL provider, then how big? And is it > acceptible to write those small fries off? I don't see any reason that it would not work at home between cable and DSL providers, given that they were willing to play ball. Christian's point was that they are the folks with clout, not the SOHO network, so they are not motivated to do so. And I don't see any obvious reason that it wouldn't work on a continental scale, given an operator that was silly enough to try it on that scale. I doubt you'll find many, though. The would find a way to subdivide the problem and do it in pieces, for their own sake. >Well I'd say that something runs counter to BCP 38 is going to run into a >lot of operational resistance, to say the least. Depending on the answers >to the above, I'm not sure that this is solely a matter of ISP intransigence. We seem to differ on what it means to violate BCP 38. BCP 38 says "service providers should police their customers by verifying that the customers are sending from legitimate addresses" and "an example of such a procedure would use an access list on the customer-facing interface that discards traffic not sourced from the customer's prefix. It doesn't go into the complexities of multihomed networks, or networks that have over time accreted multiple prefixes - Cisco being an example of both. It simply says "don't forward traffic that comes from addresses the customer is not legitimately using." Now, let's take Cisco as a case. We are in fact multihomed, through eight or ten service providers and four DMZs. We have accreted a number of prefixes, in the 64.0.0.0/8, 128.0.0.0/8, 169.something, 170.something, 171.something, and 172.something, and by the way the 192.something spaces. And yes, we use NATs internally, such as in front of labs. If you're going to tell me that having multiple prefixes and multiple providers automatically breaks BCP 38, then this bumblebee doesn't fly, and you have some explaining to do as it quite obviously is in fact flying. What is required is that the enterprise keep all of its providers aware of all of the prefixes that it is legitimately using, and have the providers accept traffic from those prefixes. The provider can do it using RPF checks by putting static routes into the access router or by adding them to the ingress ACL, its choice. Whether or not it actually uses the routes itself or advertises them to other networks is its choice, and contracts come into play in making that judgement. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 16:12: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 h3TNCphs012616; Tue, 29 Apr 2003 16:12:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3TNCpVQ012615; Tue, 29 Apr 2003 16:12:51 -0700 (PDT) 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 h3TNCmhs012608 for ; Tue, 29 Apr 2003 16:12:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3TNCtuc022346 for ; Tue, 29 Apr 2003 16:12:55 -0700 (PDT) Received: from defiant.dfw.nostrum.com (adsl-65-67-187-82.dsl.rcsntx.swbell.net [65.67.187.82]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA20201 for ; Tue, 29 Apr 2003 16:12:49 -0700 (PDT) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3TNCiL29975; Tue, 29 Apr 2003 18:12:44 -0500 Message-ID: <005f01c30ea4$d74dee60$93b58742@ssprunk> From: "Stephen Sprunk" To: "Eliot Lear" , "S Woodside" Cc: , References: <224F012B-793C-11D7-A2F1-000393414368@yahoo.com> Subject: Re: policy domains Date: Tue, 29 Apr 2003 18:09:04 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "S Woodside" > Then if you conclude that policy domains are a Good Thing, or at least > Necessary Evil, then why is there all this talk to design a network > that can somehow route around them? There's reasonable arguments against private addresses, but unless allocation policies are radically different than IPv4 practice, expecting a public address for every host is a pipe dream. Sidebar: a thread has recently popped up on nanog regarding the practice of assigning public addresses to unconnected networks or hosts behind firewalls. It's not clear whether those for or against are in the majority, but the mere presence of the debate is rather telling. > My point is that A sends B a third-party address C, and the policy of > the domain is "you can't route that outside my domain" then it doesn't > matter whether C is site local, global, uses DNS, or whatever. Policy > says it still won't route! The expected usage model was that all hosts would have a site-local address as well as zero to many global addresses. Since we don't yet know how to handle multiple addresses per host cleanly, the removal of site-locals is thought to reduce the problem's complexity since site-locals are for some reason assumed to have different semantics than globals. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 16:29:14 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 h3TNTEhs013062; Tue, 29 Apr 2003 16:29:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3TNTDlt013061; Tue, 29 Apr 2003 16:29:13 -0700 (PDT) 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 h3TNTAhs013054 for ; Tue, 29 Apr 2003 16:29:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3TNTHuc027162 for ; Tue, 29 Apr 2003 16:29:17 -0700 (PDT) Received: from defiant.dfw.nostrum.com (adsl-65-67-187-82.dsl.rcsntx.swbell.net [65.67.187.82]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id RAA17549 for ; Tue, 29 Apr 2003 17:29:11 -0600 (MDT) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3TNT5L30355; Tue, 29 Apr 2003 18:29:06 -0500 Message-ID: <006e01c30ea7$2084fea0$93b58742@ssprunk> From: "Stephen Sprunk" To: , "Iljitsch van Beijnum" Cc: , References: <69412F1F-7A80-11D7-A72E-00039388672E@muada.com> Subject: Re: A Good Schism Brightens Anyone's Day (was: A Simple Question) Date: Tue, 29 Apr 2003 18:21:56 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Iljitsch van Beijnum" > On dinsdag, apr 29, 2003, at 20:24 Europe/Amsterdam, Peter Deutsch > wrote: > > > - So what percentage of machines really are being NATed right now? > > > - What percentage of traffic is generated and consumed by NATed > > hosts? > > How is answering any of these questions going to help us? "Oh, NATed > traffic is 7% and not 5%! You are right we should have site local > addresses then!" But if the number were 50% or higher, I'd think that would have some bearing on things. If nothing else, it should convince the anti-NAT crowd to work harder at finding other solutions. > - If we allow people to register non-routable globally unique addresses > for private use, eventually some of this address space will leak out > into the global routing table. In IPv4, filtering private address > ranges and long prefixes is well-established and if and when this > fails, the consequences are negligible. Without an explicit directive from the IETF (a la RFC2050), the RIRs will not do this. In words attributed to an ARIN staffer, "We only register addresses for the Internet, not private networks." S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 16:45:12 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 h3TNjChs013314; Tue, 29 Apr 2003 16:45:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3TNjCcU013313; Tue, 29 Apr 2003 16:45:12 -0700 (PDT) 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 h3TNj8hs013306 for ; Tue, 29 Apr 2003 16:45:08 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3TNjFuc001649 for ; Tue, 29 Apr 2003 16:45:15 -0700 (PDT) Received: from defiant.dfw.nostrum.com (adsl-65-67-187-82.dsl.rcsntx.swbell.net [65.67.187.82]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA25941 for ; Tue, 29 Apr 2003 17:45:10 -0600 (MDT) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3TNj4L30666; Tue, 29 Apr 2003 18:45:05 -0500 Message-ID: <00a501c30ea9$5c489b70$93b58742@ssprunk> From: "Stephen Sprunk" To: Cc: , References: <3EAEC35D.EFA0D754@earthlink.com><69412F1F-7A80-11D7-A72E-00039388672E@muada.com> <20030429164544.5aee6169.jtk@depaul.edu> Subject: Re: A Good Schism Brightens Anyone's Day (was: A Simple Question) Date: Tue, 29 Apr 2003 18:32:11 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "John Kristoff" > This seems OK to me and appears to put the burden in the right place. > Shouldn't it be the responsibility of those who are allocated address > space to properly manage it? Others can still filter on long and valid > prefixes that they expect to hear. Or, if these non-routed allocations were from a specific IANA-designated block, providers could simply filter them all with one directive. > ...and if its gonna leak anyway, it might as well be globally unique. > Other networks will certainly be less likely to collide and try to > communicate with the leaked space. Certainly. However, providers tend to advertise whatever customers pay them to advertise, so these "non routable" blocks may end up permanently reachable from non-trivial portions of the Internet. There are many applications, such as pre-positioned content caching, where it's desirable to only have connectivity to those topologically "close". Overall, though, this makes it even more important that we find a workable solution to the multiple-address problem. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 16:45: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 h3TNjlhs013324; Tue, 29 Apr 2003 16:45:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3TNjkCB013323; Tue, 29 Apr 2003 16:45:46 -0700 (PDT) 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 h3TNjfhs013316 for ; Tue, 29 Apr 2003 16:45:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3TNjmKw004065 for ; Tue, 29 Apr 2003 16:45:48 -0700 (PDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA05889 for ; Tue, 29 Apr 2003 16:45:43 -0700 (PDT) Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3TNj1Yf014527; Tue, 29 Apr 2003 16:45:02 -0700 (PDT) Received: from cisco.com (sjc-vpn1-280.cisco.com [10.21.97.24]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA17880; Tue, 29 Apr 2003 16:45:01 -0700 (PDT) Message-ID: <3EAF0E7B.7050307@cisco.com> Date: Tue, 29 Apr 2003 16:44:59 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Sprunk CC: S Woodside , ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: policy domains References: <224F012B-793C-11D7-A2F1-000393414368@yahoo.com> <005f01c30ea4$d74dee60$93b58742@ssprunk> In-Reply-To: <005f01c30ea4$d74dee60$93b58742@ssprunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stephen, I'm glad you sent this note. One of us is under a serious misconception, and if it's you, I suspect there are a lot more like you. Stephen Sprunk wrote: > There's reasonable arguments against private addresses, but unless > allocation policies are radically different than IPv4 practice, expecting a > public address for every host is a pipe dream. Tell me if http://www.arin.net/policy/ipv6_policy.html addresses your concern. Particularly section 3.2. The policy, as I read it, gives just about everyone a /48. When counting subnets and interfaces on routers, consider that the equivalent of an IPv4 /16. That's a lot of space. According to the above document, there's no real experience of someone having hit that point yet. 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 Tue Apr 29 17:01: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 h3U010hs013721; Tue, 29 Apr 2003 17:01:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3U010XY013720; Tue, 29 Apr 2003 17:01:00 -0700 (PDT) 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 h3U00vhs013713 for ; Tue, 29 Apr 2003 17:00:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3U014uc006115 for ; Tue, 29 Apr 2003 17:01:04 -0700 (PDT) Received: from defiant.dfw.nostrum.com (adsl-65-67-187-82.dsl.rcsntx.swbell.net [65.67.187.82]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA04055 for ; Tue, 29 Apr 2003 18:00:58 -0600 (MDT) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3U00qL31059; Tue, 29 Apr 2003 19:00:52 -0500 Message-ID: <00af01c30eab$90d795b0$93b58742@ssprunk> From: "Stephen Sprunk" To: Cc: , References: <3EAEC35D.EFA0D754@earthlink.com><69412F1F-7A80-11D7-A72E-00039388672E@muada.com> <20030429164544.5aee6169.jtk@depaul.edu> Subject: Re: A Good Schism Brightens Anyone's Day (was: A Simple Question) Date: Tue, 29 Apr 2003 18:45:35 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "John Kristoff" > This seems OK to me and appears to put the burden in the right place. > Shouldn't it be the responsibility of those who are allocated address > space to properly manage it? Others can still filter on long and valid > prefixes that they expect to hear. Or, if these non-routed allocations were from a specific IANA-designated block, providers could simply filter them all with one directive. > ...and if its gonna leak anyway, it might as well be globally unique. > Other networks will certainly be less likely to collide and try to > communicate with the leaked space. Certainly. However, providers tend to advertise whatever customers pay them to advertise, so these "non routable" blocks may end up permanently reachable from non-trivial portions of the Internet. There are some applications, such as pre-positioned content caching, where it's desirable to only have connectivity to those topologically "close". Overall, though, this makes it even more important that we find a workable solution to the multiple-address problem. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 17:16:48 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 h3U0Glhs013982; Tue, 29 Apr 2003 17:16:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3U0Glon013981; Tue, 29 Apr 2003 17:16:47 -0700 (PDT) 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 h3U0Ghhs013974 for ; Tue, 29 Apr 2003 17:16:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3U0Gcuc010633 for ; Tue, 29 Apr 2003 17:16:38 -0700 (PDT) Received: from defiant.dfw.nostrum.com (adsl-65-67-187-82.dsl.rcsntx.swbell.net [65.67.187.82]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA11909 for ; Tue, 29 Apr 2003 18:16:32 -0600 (MDT) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3U0GLL31475; Tue, 29 Apr 2003 19:16:22 -0500 Message-ID: <00d101c30ead$bc0f3470$93b58742@ssprunk> From: "Stephen Sprunk" To: "John C Klensin" , "Bill Manning" Cc: "Margaret Wasserman" , , References: <200304280524.h3S5OqA04605@boreas.isi.edu> <12729734.1051619514@p3.JCK.COM> Subject: Re: IPv6 address space shortages (was: Re: A simple question) Date: Tue, 29 Apr 2003 19:11:11 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "John C Klensin" > It seems to me that if you, or anyone else, wants to make the > case that the IPv6 address space isn't going to be large enough, > you need to do so explicitly and immediately (five years ago > would have been better, but maybe we know more now). While I, > personally, would have preferred extendable length addresses, it > feels to me that saying "yet" at this stage in the game is just > pointless sniping unless you are willing to argue for calling a > halt at this stage and redesigning. I see no reason to believe that the address length is insufficient on its own; however, allocation policies and the way those bits are used may cause exhaustion and/or a different way of looking at those bits. Based on the number of hosts connected to the Internet today compared to the total number of unicast IPv4 addresses, we are nowhere near a shortage. Even so, pre-CIDR allocation policies resulted in vast amounts of unused space. Rationing of the remaining space has made NAT a necessary evil just to keep the beast functional for the masses. Are we doing the same thing with IPv6? Maybe. At worst, we're not making any mistakes we can't correct later when we learn more. I'm particularly suspicious of the decision to use a /64 for each subnet instead of the original /80 plan, and the allocation of a /3 to the RIRs is mind-boggling. But I do think we bought ourselves enough headroom to seriously screw up several times and not need a whole new protocol. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 17:34:59 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 h3U0Yxhs014225; Tue, 29 Apr 2003 17:34:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3U0YxDq014224; Tue, 29 Apr 2003 17:34:59 -0700 (PDT) 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 h3U0Yuhs014217 for ; Tue, 29 Apr 2003 17:34:56 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3U0Z2uc015457 for ; Tue, 29 Apr 2003 17:35:03 -0700 (PDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA29784 for ; Tue, 29 Apr 2003 18:34:57 -0600 (MDT) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3U0YlYf004584; Tue, 29 Apr 2003 17:34:48 -0700 (PDT) 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.3.3-GR) with ESMTP id ADR54593; Tue, 29 Apr 2003 17:34:46 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA08272; Tue, 29 Apr 2003 17:34:46 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16047.6694.557154.382580@thomasm-u1.cisco.com> Date: Tue, 29 Apr 2003 17:34:46 -0700 (PDT) To: Fred Baker Cc: Michael Thomas , "Christian Huitema" , "Pekka Savola" , Subject: RE: Operational Renumbering Procedure In-Reply-To: <5.2.0.9.2.20030429173403.02b11800@mira-sjc5-b.cisco.com> References: <5.2.0.9.2.20030428195416.057d3200@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030427203349.058defa8@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030429173403.02b11800@mira-sjc5-b.cisco.com> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred Baker writes: > At 12:23 PM 4/29/2003 -0700, Michael Thomas wrote: > >1) How do I assert the prefix in a way that my ISP > > would trust me? There are obvious security issues here. > > I would expect that this would either be by contract or by BGP, using the > ISP/customer security environment (hopefully BGP/TCP+MD5 or IPSEC) that is > in use today. So, it seems to me that you're pretty much limiting yourself to either people you accept BGP advertisements from, or to the size of a crowd you could support using phones, faxes and web sites with the (??) human resources needed for verification about the prefix in question... which sounds like a pretty tier 1 kind of customer to me. > > >2) At what scale would you expect this to work? If not my home > > between my cable and DSL provider, then how big? And is it > > acceptible to write those small fries off? > > I don't see any reason that it would not work at home between cable and DSL > providers, given that they were willing to play ball. Christian's point was > that they are the folks with clout, not the SOHO network, so they are not > motivated to do so. And I don't see any obvious reason that it wouldn't > work on a continental scale, given an operator that was silly enough to try > it on that scale. I doubt you'll find many, though. The would find a way to > subdivide the problem and do it in pieces, for their own sake. Well, I'm fairly certain that my DSL provider's never going to be convinced to accept BGP announcements from me, and I sort of doubt that they're going to come up with the resources necessary to sort out who legitimately should be allowed to modify their RPF checks and/or routes, so I really can't see how this is applicable to small fries like me. Or for that matter, just about anybody off the Fortune 500 list. Unless you've got something else in mind, because I just don't get it, and it's not obvious in your draft... > > >Well I'd say that something runs counter to BCP 38 is going to run into a > >lot of operational resistance, to say the least. Depending on the answers > >to the above, I'm not sure that this is solely a matter of ISP intransigence. > > We seem to differ on what it means to violate BCP 38. > > BCP 38 says "service providers should police their customers by verifying > that the customers are sending from legitimate addresses" and "an example > of such a procedure would use an access list on the customer-facing > interface that discards traffic not sourced from the customer's prefix. It > doesn't go into the complexities of multihomed networks, or networks that > have over time accreted multiple prefixes - Cisco being an example of both. > It simply says "don't forward traffic that comes from addresses the > customer is not legitimately using." Sure, and RPF works great for that until you start throwing multihoming into the equation which is really what this renumbering proposal is in disguise. And it seems to me that the basic problem is the security problem of how do you deal with customers claiming that they are multihomed off of another provider's prefix -- a customer that you probably trust between very little or not at all. For starters, there isn't a way to, say, cryptographically assert ownership of a prefix. And it's not clear that even if you could, you'd want that. So I have real questions about how you could make that scale up to millions of sites, which is what you'd need in the residential case, and even if you s-can residential, I would assume you'd want this to at least scale for small and medium sized business and organizations, right? > Now, let's take Cisco as a case. We are in fact multihomed, through eight > or ten service providers and four DMZs. We have accreted a number of > prefixes, in the 64.0.0.0/8, 128.0.0.0/8, 169.something, 170.something, > 171.something, and 172.something, and by the way the 192.something spaces. > And yes, we use NATs internally, such as in front of labs. If you're going > to tell me that having multiple prefixes and multiple providers > automatically breaks BCP 38, then this bumblebee doesn't fly, and you have > some explaining to do as it quite obviously is in fact flying. No, I'm saying that Cisco is an outlier mainly because we are a 900lb primate. This seems like a fairly plausible case where high touch or high trust is feasible. It's JoeClueless.com and 3liteHax0r.net that are much more problematic. 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 Apr 29 17:44: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 h3U0i4hs014374; Tue, 29 Apr 2003 17:44:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3U0i4rX014372; Tue, 29 Apr 2003 17:44:04 -0700 (PDT) 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 h3U0hxhs014364 for ; Tue, 29 Apr 2003 17:43:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3U0i6uc018175 for ; Tue, 29 Apr 2003 17:44:06 -0700 (PDT) Received: from TheWorld.com (pcls1.std.com [199.172.62.103]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA02591 for ; Tue, 29 Apr 2003 17:44:01 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id h3U0hwZK004541 for ; Tue, 29 Apr 2003 20:43:59 -0400 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id UAA2146431 for ; Tue, 29 Apr 2003 20:43:59 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Tue, 29 Apr 2003 20:43:58 -0400 From: Quality Quorum To: ipng@sunroof.eng.sun.com Subject: Re: A Good Schism Brightens Anyone's Day (was: A Simple Question) In-Reply-To: <006e01c30ea7$2084fea0$93b58742@ssprunk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 29 Apr 2003, Stephen Sprunk wrote: > Thus spake "Iljitsch van Beijnum" > > On dinsdag, apr 29, 2003, at 20:24 Europe/Amsterdam, Peter Deutsch > > wrote: > > > > > - So what percentage of machines really are being NATed right now? > > > > > - What percentage of traffic is generated and consumed by NATed > > > hosts? > > > > How is answering any of these questions going to help us? "Oh, NATed > > traffic is 7% and not 5%! You are right we should have site local > > addresses then!" > > But if the number were 50% or higher, I'd think that would have some bearing > on things. If nothing else, it should convince the anti-NAT crowd to work > harder at finding other solutions. Counting by network nodes it is around 100%, very few PCs in the world have global address. > > > - If we allow people to register non-routable globally unique addresses > > for private use, eventually some of this address space will leak out > > into the global routing table. In IPv4, filtering private address > > ranges and long prefixes is well-established and if and when this > > fails, the consequences are negligible. > > Without an explicit directive from the IETF (a la RFC2050), the RIRs will > not do this. In words attributed to an ARIN staffer, "We only register > addresses for the Internet, not private networks." > > S > 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 Apr 29 17:49: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 h3U0n4hs014581; Tue, 29 Apr 2003 17:49:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3U0n49x014580; Tue, 29 Apr 2003 17:49:04 -0700 (PDT) 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 h3U0mxhs014562 for ; Tue, 29 Apr 2003 17:49:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3U0n6Kw022937 for ; Tue, 29 Apr 2003 17:49:06 -0700 (PDT) Received: from bsdi.dv.isc.org (c17249.carlnfd1.nsw.optusnet.com.au [210.49.138.109]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3U0n0rZ004167 for ; Tue, 29 Apr 2003 17:49:01 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h3U0mDab056540; Wed, 30 Apr 2003 10:48:13 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h3U0mB54024561; Wed, 30 Apr 2003 10:48:12 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200304300048.h3U0mB54024561@drugs.dv.isc.org> To: "Matt Crawford" Cc: Stephen Sprunk , ipng@sunroof.eng.sun.com, ietf@ietf.org From: Mark.Andrews@isc.org Subject: Re: A simple question In-reply-to: Your message of "Tue, 29 Apr 2003 10:20:29 EST." <200304291520.h3TFKT2Y013209@gungnir.fnal.gov> Date: Wed, 30 Apr 2003 10:48:11 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is nothing to indicate that ISPs are going to change their business > models simply because IPv6 address space is plentiful; they charge extra for > two hosts because it is assumed two hosts consume more bits than one, not > because a second IPv4 address is hard to come by. There is nothing to indicate that they won't change either. ISP will meet their customers expectations or they will go out of business. Today you expect to get a single IP address. If you make the expectation be that you will get a prefix ISP that fail to do this will go the way of the dodo. The cable provider I'm using didn't allow home networks at one time (they also had a single flat fee). They do now though they leave the implementation and support to you (multiple volume based plans). Customers expect to be able to connect their home network and the expectation is now being met. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 17:52: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 h3U0qohs014748; Tue, 29 Apr 2003 17:52:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3U0qoG0014747; Tue, 29 Apr 2003 17:52:50 -0700 (PDT) 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 h3U0qjhs014740 for ; Tue, 29 Apr 2003 17:52:45 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3U0qqKw024145 for ; Tue, 29 Apr 2003 17:52:52 -0700 (PDT) Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA07081 for ; Tue, 29 Apr 2003 18:52:47 -0600 (MDT) Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h3U0qitU008722; Tue, 29 Apr 2003 20:52:44 -0400 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h3U0qixQ008721; Tue, 29 Apr 2003 20:52:44 -0400 Date: Tue, 29 Apr 2003 20:52:44 -0400 From: "J. Noel Chiappa" Message-Id: <200304300052.h3U0qixQ008721@ginger.lcs.mit.edu> To: ietf@ietf.org Subject: Re: IPv6 address space shortages (was: Re: A simple question) Cc: ipng@sunroof.eng.sun.com, jnc@ginger.lcs.mit.edu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: S Woodside > For purposes of geographic routing The Multi6 WG just went over geographic addressing again, for about the 17th time in the IETF (I seem to recall previous go-rounds on it in CIDRD and IPng), and finally left off talking about it, on the grounds that there were enough people against it that it was extremely unlikely there would ever be rough consensus for it. I suggest the same calculation ought to occur in this forum, i.e. that there's no point discussing geographic addressing, since there's never going to be rough consensus for it. Noel -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 18: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 h3U1B6hs015320; Tue, 29 Apr 2003 18:11:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3U1B6Vq015319; Tue, 29 Apr 2003 18:11:06 -0700 (PDT) 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 h3U1B2hs015312 for ; Tue, 29 Apr 2003 18:11:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3U1B9uc026378 for ; Tue, 29 Apr 2003 18:11:09 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id TAA08654 for ; Tue, 29 Apr 2003 19:11:03 -0600 (MDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 29 Apr 2003 18:10:26 -0700 Reply-To: From: "Tony Hain" To: "'S Woodside'" , "'John C Klensin'" Cc: "'Bill Manning'" , "'Margaret Wasserman'" , , Subject: RE: IPv6 address space shortages (was: Re: A simple question) Date: Tue, 29 Apr 2003 18:10:24 -0700 Message-ID: <076401c30eb5$47bf1380$261e4104@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <10A9C0CD-7A9D-11D7-ACAF-000393414368@yahoo.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h3U1B2hs015313 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk S Woodside wrote: > ... > 44 bits are provider independent and encode GPS coordinates. > It's enough to have accuracy to roughly 10 meter squares. The 04 version reduced that to 6.4 m, but your point about it being somewhat course is valid. I stopped at 44 bits because the goal was creating a /48. If that is expanded to a /52 you are looking at > .5 m resolution. While this is possible to encode, the publicly available gear is not capable of measuring that accurately. > BUT ... that doesn't consider altitude. Depending on the intended use, that can be further encoded in the remaining bits to create a unique /64 per cubic .5 m, 2 km deep. > In addition, it's quite easy to see that 10 > meter squares may be a little bit too big for some purposes, even if > you're just talking about individual homes. Also, it doesn't > provide a > mechanism to define an area rather than a point. I could go on. > > So it's clear at least to me that under this scheme there is > not enough > space in IPv6 to do proper justice to georouting. We have the option of using longer than /64 prefixes if necessary. I would prefer not to go there, but given a unique need it could be done. Tony > > simon > > > [1] http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-04.txt > > > -- > www.simonwoodside.com -- 99% Devil, 1% Angel > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 04:03: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 h3UB3shs018327; Wed, 30 Apr 2003 04:03:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UB3rGc018326; Wed, 30 Apr 2003 04:03:53 -0700 (PDT) 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 h3UB3ohs018319 for ; Wed, 30 Apr 2003 04:03:50 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UB3vKw022164 for ; Wed, 30 Apr 2003 04:03:57 -0700 (PDT) Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3UB3qrZ024123 for ; Wed, 30 Apr 2003 04:03:52 -0700 (PDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3UB3oIP025216; Wed, 30 Apr 2003 04:03:50 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (rtp-vpn2-94.cisco.com [10.82.240.94]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGP47155; Wed, 30 Apr 2003 03:59:24 -0700 (PDT) Message-Id: <5.2.0.9.2.20030430000613.05975e28@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Apr 2003 00:07:15 -0400 To: Michael Thomas From: Fred Baker Subject: RE: Operational Renumbering Procedure Cc: In-Reply-To: <16047.6694.557154.382580@thomasm-u1.cisco.com> References: <5.2.0.9.2.20030429173403.02b11800@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030428195416.057d3200@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030427203349.058defa8@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030429173403.02b11800@mira-sjc5-b.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'm not sure where you're going with your comments. It sounds for all the world like you're saying that because you can think of a case where two ISPs might choose to not cooperate with what they consider an insignificant customer, or because there exist ISPs that will remove their nose to spite their face, the question of how a network that chooses to renumber itself might do so operationally is illegitimate to ask. If that's your perspective, tell me now. I'll know to ignore any commentary from you as pointless and unproductive. I don't have that low an opinion of ISPs, or of enterprise network managers. I will admit readily to the existence of homo ignoramus; I will not presume that every person I meet belongs to that species. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 05:14: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 h3UCErhs018958; Wed, 30 Apr 2003 05:14:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UCErw3018957; Wed, 30 Apr 2003 05:14:53 -0700 (PDT) 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 h3UCEohs018950 for ; Wed, 30 Apr 2003 05:14:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UCEvuc018416 for ; Wed, 30 Apr 2003 05:14:57 -0700 (PDT) Received: from bt0rjw.god.bel.alcatel.be (alc240.alcatel.be [195.207.101.240]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA10301 for ; Wed, 30 Apr 2003 06:14:51 -0600 (MDT) From: Robert.Peschi@alcatel.be Received: from bemail01.net.alcatel.be (bemail01.net.alcatel.be [138.203.145.85]) by bt0rjw.god.bel.alcatel.be (8.12.9/8.11.4) with ESMTP id h3UCEnLt000842 for ; Wed, 30 Apr 2003 14:14:50 +0200 (MEST) Sensitivity: Subject: May one configure IID= "0" for an address ? To: ipng@sunroof.eng.sun.com Date: Wed, 30 Apr 2003 14:14:47 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/30/2003 14:14:49 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have found nowhere in (draft)-RFCs a restriction on the value an Interface ID can take. So in principle any values in [0, 2**64-1] could be configured as IID for an IPv6 address. However, RFC 3513, section 2.6.1 defines the "Subnet-Router Anycast address" as being :: Does that mean that configuring IID = 0 might interfere or conflict with some anycast mechanism ? and consequently that configuring IID=0 for an address should be avoided ? ...or what do I miss there ? Thanks, Kind regards, Robert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 05:53: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 h3UCrRhs019466; Wed, 30 Apr 2003 05:53:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UCrRWq019465; Wed, 30 Apr 2003 05:53:27 -0700 (PDT) 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 h3UCrNhs019458 for ; Wed, 30 Apr 2003 05:53:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UCrUuc024200 for ; Wed, 30 Apr 2003 05:53:30 -0700 (PDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id GAA19400 for ; Wed, 30 Apr 2003 06:53:24 -0600 (MDT) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3SKGO08005790; Mon, 28 Apr 2003 13:16:25 -0700 (PDT) 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.3.3-GR) with ESMTP id ADQ23631; Mon, 28 Apr 2003 13:16:12 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA01463; Mon, 28 Apr 2003 13:16:11 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16045.35851.830913.532844@thomasm-u1.cisco.com> Date: Mon, 28 Apr 2003 13:16:11 -0700 (PDT) To: Eliot Lear Cc: Stephen Sprunk , Robert Elz , Margaret Wasserman , Valdis.Kletnieks@vt.edu, Dave Crocker , ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A simple question In-Reply-To: <3EAD5CE6.2050702@cisco.com> References: <200304192151.h3JLpKuL019276@turing-police.cc.vt.edu> <200304191923.h3JJNOuL018209@turing-police.cc.vt.edu> <16890640984.20030419070719@brandenburg.com> <002401c30605$e22da070$261e4104@eagleswings> <9540645034.20030418171403@brandenburg.com> <11870.1050777166@munnari.OZ.AU> <14570.1050784897@munnari.OZ.AU> <5.1.0.14.2.20030428053937.047cbc68@mail.windriver.com> <00b401c30da4$390d81d0$93b58742@ssprunk> <3EAD5CE6.2050702@cisco.com> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eliot Lear writes: > Stephen Sprunk wrote: > > > When you are talking about tens of millions of customers, it's not feasible > > to give each a subnet even if you have the space to do it. IMHO, most > > customers will be placed on a /64 that's shared across hundreds of > > customers, similar to IPv4 common practice. > > Why? Network puritanism: the haunting fear that someone, somewhere may be happy with their own subnet. 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 Apr 30 07:29:40 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 h3UETdhs019941; Wed, 30 Apr 2003 07:29:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UETdbc019940; Wed, 30 Apr 2003 07:29:39 -0700 (PDT) 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 h3UETZhs019933 for ; Wed, 30 Apr 2003 07:29:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UEThKw028491 for ; Wed, 30 Apr 2003 07:29:43 -0700 (PDT) Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA25926 for ; Wed, 30 Apr 2003 08:29:37 -0600 (MDT) 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 h3UETZ1O021447; Wed, 30 Apr 2003 07:29:35 -0700 (PDT) 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.3.3-GR) with ESMTP id ADR94848; Wed, 30 Apr 2003 07:29:34 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA11734; Wed, 30 Apr 2003 07:29:34 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16047.56782.20611.602139@thomasm-u1.cisco.com> Date: Wed, 30 Apr 2003 07:29:34 -0700 (PDT) To: Fred Baker Cc: Michael Thomas , Subject: RE: Operational Renumbering Procedure In-Reply-To: <5.2.0.9.2.20030430000613.05975e28@mira-sjc5-b.cisco.com> References: <5.2.0.9.2.20030429173403.02b11800@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030428195416.057d3200@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030427203349.058defa8@mira-sjc5-b.cisco.com> <5.2.0.9.2.20030430000613.05975e28@mira-sjc5-b.cisco.com> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk No. I'm saying that it's not at all obvious how the renumbering scales to anything much smaller than Cisco sized companies, if you have the barrier of RPF checking at your provider. If you think that it can scale larger, and indeed to even residential multihoming/renumbering, what, *specifically*, would I have to do with my two providers, or between themselves that they could hope to deploy operationally without lessening the security that RFP, etc, give? Mike, who suspects this isn't news to the multi-6 crowd. Fred Baker writes: > I'm not sure where you're going with your comments. It sounds for all the > world like you're saying that because you can think of a case where two > ISPs might choose to not cooperate with what they consider an insignificant > customer, or because there exist ISPs that will remove their nose to spite > their face, the question of how a network that chooses to renumber itself > might do so operationally is illegitimate to ask. > > If that's your perspective, tell me now. I'll know to ignore any commentary > from you as pointless and unproductive. I don't have that low an opinion of > ISPs, or of enterprise network managers. I will admit readily to the > existence of homo ignoramus; I will not presume that every person I meet > belongs to that species. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 07:43: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 h3UEhchs020221; Wed, 30 Apr 2003 07:43:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UEhc1A020220; Wed, 30 Apr 2003 07:43:38 -0700 (PDT) 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 h3UEhYhs020212 for ; Wed, 30 Apr 2003 07:43:34 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UEhguc013185 for ; Wed, 30 Apr 2003 07:43:42 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3UEhZrZ019222 for ; Wed, 30 Apr 2003 07:43:36 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3UEhOk31636; Wed, 30 Apr 2003 17:43:24 +0300 Date: Wed, 30 Apr 2003 17:43:24 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: Michael Thomas , Subject: RE: Operational Renumbering Procedure In-Reply-To: <5.2.0.9.2.20030430000613.05975e28@mira-sjc5-b.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well.. For what it's worth, IMHO, Mike shows a surprising amount (to this wg :-) of operational/security clue. Source address checking is not a thing to be dusted under the carpet, and those who refuse to put the dust under the carpet are *not* the bad guys. Instead, we should try to figure out the extent of such an approach, and more importantly, work on mechanisms that do not require such violations. On Wed, 30 Apr 2003, Fred Baker wrote: > I'm not sure where you're going with your comments. It sounds for all the > world like you're saying that because you can think of a case where two > ISPs might choose to not cooperate with what they consider an insignificant > customer, or because there exist ISPs that will remove their nose to spite > their face, the question of how a network that chooses to renumber itself > might do so operationally is illegitimate to ask. > > If that's your perspective, tell me now. I'll know to ignore any commentary > from you as pointless and unproductive. I don't have that low an opinion of > ISPs, or of enterprise network managers. I will admit readily to the > existence of homo ignoramus; I will not presume that every person I meet > belongs to that species. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 30 08:31: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 h3UFVhhs020944; Wed, 30 Apr 2003 08:31:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UFVhq0020943; Wed, 30 Apr 2003 08:31:43 -0700 (PDT) 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 h3UFVchs020936 for ; Wed, 30 Apr 2003 08:31:38 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UFVkKw013769 for ; Wed, 30 Apr 2003 08:31:46 -0700 (PDT) Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA06399 for ; Wed, 30 Apr 2003 09:31:40 -0600 (MDT) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19AtYW-0006j5-00; Wed, 30 Apr 2003 08:31:36 -0700 Date: Wed, 30 Apr 2003 11:30:37 -0400 From: Keith Moore To: Iljitsch van Beijnum Cc: moore@cs.utk.edu, pdeutsch@earthlink.net, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A Good Schism Brightens Anyone's Day (was: A Simple Question) Message-Id: <20030430113037.5ffa287c.moore@cs.utk.edu> In-Reply-To: References: <3EAEFFA7.63A14F72@earthlink.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Today, dial-up concentrators usually have an address > range that it used to assign addresses to people that dial in. That > means at most a handful of routes per dial-up concentrator in the > interior routing protocol. If everyone has their own /48, that means a > route in the IGP for each customer that's online. There are no hard and > fast rules about how many routes you can have in an IGP, but somewhere > between 10k and 1M you run into trouble. this is an interesting point, but I think it has more to do with whether the prefixes are statically bound to customers than the length of those prefixes. why would giving customers static /64s result in fewer routes in your IGP than giving them static /48s? in neither case is there a direct correspondence between the customer's address and the concentrator. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 09:34: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 h3UGY0hs022128; Wed, 30 Apr 2003 09:34:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UGY01p022127; Wed, 30 Apr 2003 09:34:00 -0700 (PDT) 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 h3UGXuhs022120 for ; Wed, 30 Apr 2003 09:33:56 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UGY3uc012866 for ; Wed, 30 Apr 2003 09:34:03 -0700 (PDT) Received: from defiant.dfw.nostrum.com (adsl-65-67-187-82.dsl.rcsntx.swbell.net [65.67.187.82]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA19531 for ; Wed, 30 Apr 2003 10:33:57 -0600 (MDT) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3UGXeL17024; Wed, 30 Apr 2003 11:33:40 -0500 Message-ID: <005a01c30f36$435dd7a0$93b58742@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" , "Iljitsch van Beijnum" Cc: , , , References: <3EAEFFA7.63A14F72@earthlink.com> <20030430113037.5ffa287c.moore@cs.utk.edu> Subject: Re: A Good Schism Brightens Anyone's Day (was: A Simple Question) Date: Wed, 30 Apr 2003 11:20:14 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Keith Moore" > > Today, dial-up concentrators usually have an address > > range that it used to assign addresses to people that dial in. That > > means at most a handful of routes per dial-up concentrator in the > > interior routing protocol. If everyone has their own /48, that means > > a route in the IGP for each customer that's online. There are no > > hard and fast rules about how many routes you can have in an > > IGP, but somewhere between 10k and 1M you run into trouble. > > this is an interesting point, but I think it has more to do with whether > the prefixes are statically bound to customers than the length of those > prefixes. why would giving customers static /64s result in fewer > routes in your IGP than giving them static /48s? in neither case is > there a direct correspondence between the customer's address and > the concentrator. IMHO, dialup is a bad example because static IPs per customer are rare; let's switch to the cable/dsl market. Standard practice is to connect all customers in a given area (or signed up in a given period) to a single concentrator via some sort of virtual circuit (PPPoE, ATM, FR, etc). This concentrator then internally bridges all of these virtual circuits into a single subnet with a single prefix, giving you one route for N customers. OTOH, if you assign a prefix to each customer, you then have between N+1 and 2N routes for N customers. The latter might be justified if we're truly committed to eliminating NATs, but it costs a lot more in routes, in administration, and in address waste (assigning a /48 to what is, in nearly all cases, 1-4 hosts). S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 09:46:18 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 h3UGkIhs022518; Wed, 30 Apr 2003 09:46:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UGkI50022516; Wed, 30 Apr 2003 09:46:18 -0700 (PDT) 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 h3UGkBhs022501 for ; Wed, 30 Apr 2003 09:46:11 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UGkIKw008344 for ; Wed, 30 Apr 2003 09:46:19 -0700 (PDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA28170 for ; Wed, 30 Apr 2003 10:46:13 -0600 (MDT) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3UGj8Lr017664; Wed, 30 Apr 2003 09:45:08 -0700 (PDT) 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.3.3-GR) with ESMTP id ADS07588; Wed, 30 Apr 2003 09:45:06 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA12587; Wed, 30 Apr 2003 09:45:06 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16047.64914.599665.968428@thomasm-u1.cisco.com> Date: Wed, 30 Apr 2003 09:45:06 -0700 (PDT) To: "Stephen Sprunk" Cc: "Keith Moore" , "Iljitsch van Beijnum" , , , Subject: Re: A Good Schism Brightens Anyone's Day (was: A Simple Question) In-Reply-To: <005a01c30f36$435dd7a0$93b58742@ssprunk> References: <3EAEFFA7.63A14F72@earthlink.com> <20030430113037.5ffa287c.moore@cs.utk.edu> <005a01c30f36$435dd7a0$93b58742@ssprunk> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stephen Sprunk writes: > Standard practice is to connect all customers in a given area (or signed up > in a given period) to a single concentrator via some sort of virtual circuit > (PPPoE, ATM, FR, etc). This concentrator then internally bridges all of > these virtual circuits into a single subnet with a single prefix, giving you > one route for N customers. OTOH, if you assign a prefix to each customer, > you then have between N+1 and 2N routes for N customers. The latter might > be justified if we're truly committed to eliminating NATs, but it costs a > lot more in routes, in administration, and in address waste (assigning a /48 > to what is, in nearly all cases, 1-4 hosts). Huh? Why wouldn't these prefixes summarized at the first hop router? And even the first hop router needs to have routes to get to the last mile, so whether you do it with an arp cache, SID binding, or routing table seems like a rather minor difference in kind. 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 Apr 30 09:54: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 h3UGs1hs022888; Wed, 30 Apr 2003 09:54:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UGs1Si022887; Wed, 30 Apr 2003 09:54:01 -0700 (PDT) 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 h3UGruhs022874 for ; Wed, 30 Apr 2003 09:53:56 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UGs3uc019262 for ; Wed, 30 Apr 2003 09:54:03 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA03647 for ; Wed, 30 Apr 2003 10:53:58 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3UGrMv21915; Wed, 30 Apr 2003 12:53:23 -0400 (EDT) Date: Wed, 30 Apr 2003 12:53:22 -0400 From: Keith Moore To: "Stephen Sprunk" Cc: moore@cs.utk.edu, iljitsch@muada.com, pdeutsch@earthlink.net, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: A Good Schism Brightens Anyone's Day (was: A Simple Question) Message-Id: <20030430125322.6b3e0bcd.moore@cs.utk.edu> In-Reply-To: <005a01c30f36$435dd7a0$93b58742@ssprunk> References: <3EAEFFA7.63A14F72@earthlink.com> <20030430113037.5ffa287c.moore@cs.utk.edu> <005a01c30f36$435dd7a0$93b58742@ssprunk> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > this is an interesting point, but I think it has more to do with > > whether the prefixes are statically bound to customers than the > > length of those prefixes. why would giving customers static /64s > > result in fewer routes in your IGP than giving them static /48s? > > in neither case is there a direct correspondence between the > > customer's address and the concentrator. > > IMHO, dialup is a bad example because static IPs per customer are > rare; let's switch to the cable/dsl market. well, they might not be so rare in the IPv6 market, but whatever... > Standard practice is to connect all customers in a given area (or > signed up in a given period) to a single concentrator via some sort of > virtual circuit(PPPoE, ATM, FR, etc). This concentrator then > internally bridges all of these virtual circuits into a single subnet > with a single prefix, giving you one route for N customers. OTOH, if > you assign a prefix to each customer, you then have between N+1 and 2N > routes for N customers. well, for cable at least, seems like you'd want to assign a prefix to each concentrator and give each customer a /48 subnet out of the concentrator that serves that location. as I understand dsl it affords more flexibility than that, since each customer can get a VC to a concentrator which can essentially be anywhere, but you'd still want to assign an appropriate-sized prefix to the concentrator and dole /48 subnets out of that. either way you get to do route aggregation at the concentrator. I suspect a lot of "standard practice" for IPv4 is designed to conserve address space; it's not clear that such practices are either desirable or optimal for IPv6. more generally, IPv6 is going to be driven by different markets, different applications, and a different set of customer demands than IPv4. so anytime you find yourself thinking that "standard practice" (meaning v4 practice) axiomatically applies to IPv6, it might be worth re-examining the assumptions behind that practice. 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 Apr 30 10:28: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 h3UHSHhs023614; Wed, 30 Apr 2003 10:28:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UHSH5R023613; Wed, 30 Apr 2003 10:28:17 -0700 (PDT) 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 h3UHSDhs023606 for ; Wed, 30 Apr 2003 10:28:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UHSLKw023991 for ; Wed, 30 Apr 2003 10:28:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA14463 for ; Wed, 30 Apr 2003 10:28:16 -0700 (PDT) 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 KAA11168; Wed, 30 Apr 2003 10:28:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h3UHSEB02765; Wed, 30 Apr 2003 10:28:14 -0700 X-mProtect: <200304301728> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.159, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIqAE3i; Wed, 30 Apr 2003 10:28:13 PDT Message-Id: <4.3.2.7.2.20030430101549.02b948d8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Apr 2003 10:27:56 -0700 To: Robert.Peschi@alcatel.be From: Bob Hinden Subject: Re: May one configure IID= "0" for an address ? 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 Robert, At 05:14 AM 4/30/2003, Robert.Peschi@alcatel.be wrote: >Hi, >I have found nowhere in (draft)-RFCs a restriction on the value >an Interface ID can take. So in principle any values in [0, 2**64-1] could >be configured as IID for an IPv6 address. Zero is a legitimate address for any field in an IPv6 address. >However, RFC 3513, section 2.6.1 defines the "Subnet-Router Anycast >address" as being :: As you noted that RFC3513 (and it's predecessors) defines the "subnet=router anycast address" as any prefix with the remaining bits of the address set to zero. >Does that mean that configuring IID = 0 might interfere or conflict with >some anycast mechanism ? and consequently that configuring IID=0 >for an address should be avoided ? ...or what do I miss there ? Using a IID of zero does conflict with the subnet anycast address. So zero IID's are legal, but are reserved for the "subnet=router anycast address". Does that help? Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 30 10:58:46 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 h3UHwkhs024137; Wed, 30 Apr 2003 10:58:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UHwk9C024136; Wed, 30 Apr 2003 10:58:46 -0700 (PDT) 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 h3UHwghs024129 for ; Wed, 30 Apr 2003 10:58:42 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UHwnuc012193 for ; Wed, 30 Apr 2003 10:58:49 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA10606 for ; Wed, 30 Apr 2003 11:58:43 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3UHwWv22127; Wed, 30 Apr 2003 13:58:34 -0400 (EDT) Date: Wed, 30 Apr 2003 13:58:32 -0400 From: Keith Moore To: John C Klensin Cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: My thoughts on local-use addresses Message-Id: <20030430135832.1a645f93.moore@cs.utk.edu> In-Reply-To: <13367010.1051372503@p3.JCK.COM> References: <20030426060420.GA93218@lethargic.dyndns.org> <20030426164255.GA98043@lethargic.dyndns.org> <20030426130211.321b0a4d.moore@cs.utk.edu> <13367010.1051372503@p3.JCK.COM> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) 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 need to get rid of site-locals. merely renaming them as > > private use addresses wouldn't solve any of their problems. > > there's no advantage to moving to IPv6 if it repeats the RFC > > 1918 mistake. > Hyperbole does not serve either the community, or one's own > position, well in this situation or others like it. John, If I understand what you are calling hyperbole I would instead call it the 10,000 meter view. That is, I don't see a significant market for IPv6 if it doesn't support applications that cannot be run on NATted IPv4. Yes, there may still be some small advantage of IPv6 for some groups of users if this doesn't happen, but not for the Internet community as a whole. So "no advantage" can be taken as an exaggeration, but the intent was to avoid getting bogged down in detail about exactly what minor advantages there might be and why they're unlikely to create enough incentive for any widespread adoption of IPv6. And no, I don't think that reducing the number of NATs by 25-50% would create a significant advantage to moving to IPv6. In order to create a significant advantage, there need to be so few NATs in IPv6 that application developers can write applications that will fail in the presence of NATs without fear of losing a significant number of customers. I agree that there's a requirement for PI addresses, and perhaps, for PI addresses that don't require RIR allocation. Various solutions have been proposed, but we seem to be unable to evaluate them or choose between them because we're too busy arguing about whether the v6 network should be saddled with the baggage from v4. The discussion about SL also seems to be couched in those terms, as well as being confused by efforts to conflate different notions of scope that are better understood separately. IMHO, those who think that hosts or apps should have to bear the burden of picking which address or interface to use in order to get packets to their destination need to explain (a) where the hosts or apps get the information necessary to make those choices in a reliable and timely fashion, and probably (b) how to provide a usable endpoint identifier under those conditions that can be passed between hosts at arbitrary locations. Until then, I'm not convinced that the v6 assumptions about multihoming are workable. Which further leads me to conclude that we still haven't figured out a way to make IP routing scale in a practical sense. 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 Apr 30 11:28: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 h3UISths024462; Wed, 30 Apr 2003 11:28:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UISttm024461; Wed, 30 Apr 2003 11:28:55 -0700 (PDT) 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 h3UISphs024454 for ; Wed, 30 Apr 2003 11:28:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UISxKw014616 for ; Wed, 30 Apr 2003 11:28:59 -0700 (PDT) Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA08756 for ; Wed, 30 Apr 2003 12:28:53 -0600 (MDT) 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 h3UIS5xK027074; Wed, 30 Apr 2003 11:28:07 -0700 (PDT) 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.3.3-GR) with ESMTP id ADS21769; Wed, 30 Apr 2003 11:28:05 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA13127; Wed, 30 Apr 2003 11:28:05 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16048.5557.124583.930323@thomasm-u1.cisco.com> Date: Wed, 30 Apr 2003 11:28:05 -0700 (PDT) To: Keith Moore Cc: John C Klensin , ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: My thoughts on local-use addresses In-Reply-To: <20030430135832.1a645f93.moore@cs.utk.edu> References: <20030426060420.GA93218@lethargic.dyndns.org> <20030426164255.GA98043@lethargic.dyndns.org> <20030426130211.321b0a4d.moore@cs.utk.edu> <13367010.1051372503@p3.JCK.COM> <20030430135832.1a645f93.moore@cs.utk.edu> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore writes: > The discussion about SL also seems to be couched in those terms, as well > as being confused by efforts to conflate different notions of scope that > are better understood separately. IMHO, those who think that hosts or > apps should have to bear the burden of picking which address or > interface to use in order to get packets to their destination need to > explain (a) where the hosts or apps get the information necessary to > make those choices in a reliable and timely fashion, and probably (b) > how to provide a usable endpoint identifier under those conditions that > can be passed between hosts at arbitrary locations. Until then, I'm not > convinced that the v6 assumptions about multihoming are workable. Which > further leads me to conclude that we still haven't figured out a way to > make IP routing scale in a practical sense. It seems to me that what needs to be answered first is whether we are already resigned to dealing with that problem with mobility, renumbering, and multihoming. There's good reason to want to use a local prefix rather than mobile IP for new communiation if possible since it more cleanly eliminates the dog leg through the home agent. Likewise, there's pretty good reason to want to renumber. Neither of these have a very strong policy component though: the host wants to do this for efficiency and/or continued communication. So I'd say that there's pretty good motivation for hosts to want to at the very least deal with more than one globally routable address. Multihoming is similar, obviously, but also introduces an element of policy to the discussion: it would be nice to prefer one path over others; having -- somehow -- hosts know the policy would be one way to achieve that. Have we just gone to hell in a hand basket? This strikes me as part of what is getting discussed with site-locals. Is selection based upon policy -- and hence knowing finer grained properties of IP prefixes -- the road to hell? It sure seems to drag a lot more baggage into the discussion than with the mobility and renumbering problems when you start talking about policy. Keeping prefix knowledge on hosts opaque would certainly be one way to draw a line in the sand. This has implications with both site-locals (bad) and multihoming (policy-based selection bad). 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 Apr 30 11:51: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 h3UIpBhs024734; Wed, 30 Apr 2003 11:51:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UIpA8G024732; Wed, 30 Apr 2003 11:51:10 -0700 (PDT) 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 h3UIp4hs024718 for ; Wed, 30 Apr 2003 11:51:04 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UIpBuc029091 for ; Wed, 30 Apr 2003 11:51:11 -0700 (PDT) Received: from caronte.gmv.es ([212.0.110.2]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA25689 for ; Wed, 30 Apr 2003 12:51:05 -0600 (MDT) Received: (from uucp@localhost) by caronte.gmv.es (8.11.6+Sun/8.11.6) id h3UImLR26233 for ; Wed, 30 Apr 2003 20:48:21 +0200 (MEST) Received: from scanmail.gmv.es(172.22.2.37) by caronte.gmv.es via csmap (V6.0) id srcAAACSaWoZ; Wed, 30 Apr 03 20:48:21 +0200 Received: from 172.22.2.1 by scanmail (InterScan E-Mail VirusWall NT); Wed, 30 Apr 2003 20:51:31 +0200 Received: (from uucp@localhost) by caronte.gmv.es (8.11.6+Sun/8.11.6) id h3UIl3J26186 for ; Wed, 30 Apr 2003 20:47:03 +0200 (MEST) Received: from ran.ietf.org(132.151.6.60) by caronte.gmv.es via csmap (V6.0) id srcAAAxyaajZ; Wed, 30 Apr 03 20:47:02 +0200 Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 19AwOx-00082k-00 for ietf-list@ran.ietf.org; Wed, 30 Apr 2003 14:33:55 -0400 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 19AwKH-0007c3-00 for ietf@ran.ietf.org; Wed, 30 Apr 2003 14:29:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15986 for ; Wed, 30 Apr 2003 14:25:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AwJG-0002M8-00 for ietf@ietf.org; Wed, 30 Apr 2003 14:28:03 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19AwJF-0002LF-00 for ietf@ietf.org; Wed, 30 Apr 2003 14:28:02 -0400 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 h3UIS5xK027074; Wed, 30 Apr 2003 11:28:07 -0700 (PDT) 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.3.3-GR) with ESMTP id ADS21769; Wed, 30 Apr 2003 11:28:05 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA13127; Wed, 30 Apr 2003 11:28:05 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16048.5557.124583.930323@thomasm-u1.cisco.com> Date: Wed, 30 Apr 2003 11:28:05 -0700 (PDT) To: Keith Moore Cc: John C Klensin , ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: My thoughts on local-use addresses In-Reply-To: <20030430135832.1a645f93.moore@cs.utk.edu> References: <20030426060420.GA93218@lethargic.dyndns.org> <20030426164255.GA98043@lethargic.dyndns.org> <20030426130211.321b0a4d.moore@cs.utk.edu> <13367010.1051372503@p3.JCK.COM> <20030430135832.1a645f93.moore@cs.utk.edu> 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: 7bit X-GCMulti: 1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore writes: > The discussion about SL also seems to be couched in those terms, as well > as being confused by efforts to conflate different notions of scope that > are better understood separately. IMHO, those who think that hosts or > apps should have to bear the burden of picking which address or > interface to use in order to get packets to their destination need to > explain (a) where the hosts or apps get the information necessary to > make those choices in a reliable and timely fashion, and probably (b) > how to provide a usable endpoint identifier under those conditions that > can be passed between hosts at arbitrary locations. Until then, I'm not > convinced that the v6 assumptions about multihoming are workable. Which > further leads me to conclude that we still haven't figured out a way to > make IP routing scale in a practical sense. It seems to me that what needs to be answered first is whether we are already resigned to dealing with that problem with mobility, renumbering, and multihoming. There's good reason to want to use a local prefix rather than mobile IP for new communiation if possible since it more cleanly eliminates the dog leg through the home agent. Likewise, there's pretty good reason to want to renumber. Neither of these have a very strong policy component though: the host wants to do this for efficiency and/or continued communication. So I'd say that there's pretty good motivation for hosts to want to at the very least deal with more than one globally routable address. Multihoming is similar, obviously, but also introduces an element of policy to the discussion: it would be nice to prefer one path over others; having -- somehow -- hosts know the policy would be one way to achieve that. Have we just gone to hell in a hand basket? This strikes me as part of what is getting discussed with site-locals. Is selection based upon policy -- and hence knowing finer grained properties of IP prefixes -- the road to hell? It sure seems to drag a lot more baggage into the discussion than with the mobility and renumbering problems when you start talking about policy. Keeping prefix knowledge on hosts opaque would certainly be one way to draw a line in the sand. This has implications with both site-locals (bad) and multihoming (policy-based selection bad). 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 Apr 30 12:18: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 h3UJIchs025835; Wed, 30 Apr 2003 12:18:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UJIcdq025834; Wed, 30 Apr 2003 12:18:38 -0700 (PDT) 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 h3UJIYhs025827 for ; Wed, 30 Apr 2003 12:18:34 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UJIfuc009008 for ; Wed, 30 Apr 2003 12:18:41 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3UJIarZ011858 for ; Wed, 30 Apr 2003 12:18:36 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3UJGmv22369; Wed, 30 Apr 2003 15:16:48 -0400 (EDT) Date: Wed, 30 Apr 2003 15:16:48 -0400 From: Keith Moore To: Michael Thomas Cc: moore@cs.utk.edu, john-ietf@jck.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: My thoughts on local-use addresses Message-Id: <20030430151648.3c3d352e.moore@cs.utk.edu> In-Reply-To: <16048.5557.124583.930323@thomasm-u1.cisco.com> References: <20030426060420.GA93218@lethargic.dyndns.org> <20030426164255.GA98043@lethargic.dyndns.org> <20030426130211.321b0a4d.moore@cs.utk.edu> <13367010.1051372503@p3.JCK.COM> <20030430135832.1a645f93.moore@cs.utk.edu> <16048.5557.124583.930323@thomasm-u1.cisco.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > IMHO, those who think > > that hosts or apps should have to bear the burden of picking which > > address or interface to use in order to get packets to their > > destination need to explain (a) where the hosts or apps get the > > information necessary to make those choices in a reliable and > > timely fashion, and probably (b) how to provide a usable endpoint > > identifier under those conditions that can be passed between hosts > > at arbitrary locations. > > It seems to me that what needs to be answered first is whether we are > already resigned to dealing with that problem with mobility, > renumbering, and multihoming. If we're resigned to dealing with an intractable problem, maybe we need to rethink that assumption. But it's not clear that either mobility or renumbering presents the same kind of challenge. In the case of mobility I think it's fairly simple to decide whether to use a home or in-care-of address as the source address, and this can be dictated by the application. In the case of renumbering then both old and new prefixes should be valid for a considerable overlap period, which would make the choice less critical except for apps that maintain associations for a very long time (say, for several weeks). As for "multihoming" - these days people mean different things when they say that, so I can't tell for sure what you mean. But I think the assumption that having multiple prefixes for a site and advertising multiple addresses for hosts through DNS will provide sufficient redundancy in network access to that site, across all or most applications, is dubious at best. > There's good reason to want to use a > local prefix rather than mobile IP for new communiation if possible > since it more cleanly eliminates the dog leg through the home agent. Taken in isolation, that's certainly true. But it presumes several things, one of which is that a sending host can tell which of several prefixes is the best to use. (or if not the best, which ones are more likely to work well than others). It's easy to construct cases where it's possible for the sending host to do this; somewhat more difficult to construct a convincing argument that this can be done in general. For instance, I spent some time investigating an idea which I'll call "relative addresses" - the idea being that if source and destination absolute/global addresses share enough bits of a common prefix the sending host can assume they're on the same network, it can substitute that many bits of "relative address prefix" for the global prefixes in those addresses, the local network will route the traffic to the same destination, and the addresses don't need to change when the network's global prefix changes. The idea has some nice properties. In particular, this is an optimization between hosts and the network - applications can use it explicitly if they wish, but they don't have to be aware of it to benefit from it. There's no need to advertise the "relative addresses" in DNS or in referrals between apps because they can automatically be inferred by hosts. And it would even work well in conjunction with mobile IP-like mechanisms for forwarding and/or redirecting traffic to PI prefixes - since local traffic would bypass such mechanisms completely. However - at least in its current incarnation, it doesn't work if a network has multiple prefixes that aren't available to the same set of hosts. In other words, just because a source and destination share *a* common prefix doesn't mean that the conversion from absolute to relative address is invertable - the substitution of a single common prefix can create an address that is ambiguous even within the local site. (But I'm still working on the idea...) Ketih -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 13:45: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 h3UKjihs026203; Wed, 30 Apr 2003 13:45:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UKjix3026202; Wed, 30 Apr 2003 13:45:44 -0700 (PDT) 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 h3UKjehs026195 for ; Wed, 30 Apr 2003 13:45:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UKjmuc003237 for ; Wed, 30 Apr 2003 13:45:48 -0700 (PDT) Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id OAA24955 for ; Wed, 30 Apr 2003 14:45:40 -0600 (MDT) 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 h3UKhvxI028024; Wed, 30 Apr 2003 13:43:58 -0700 (PDT) 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.3.3-GR) with ESMTP id ADS38304; Wed, 30 Apr 2003 13:43:56 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA13716; Wed, 30 Apr 2003 13:43:56 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16048.13708.414125.689623@thomasm-u1.cisco.com> Date: Wed, 30 Apr 2003 13:43:56 -0700 (PDT) To: Keith Moore Cc: Michael Thomas , john-ietf@jck.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: My thoughts on local-use addresses In-Reply-To: <20030430151648.3c3d352e.moore@cs.utk.edu> References: <20030426060420.GA93218@lethargic.dyndns.org> <20030426164255.GA98043@lethargic.dyndns.org> <20030426130211.321b0a4d.moore@cs.utk.edu> <13367010.1051372503@p3.JCK.COM> <20030430135832.1a645f93.moore@cs.utk.edu> <16048.5557.124583.930323@thomasm-u1.cisco.com> <20030430151648.3c3d352e.moore@cs.utk.edu> 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! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore writes: > > > IMHO, those who think > > > that hosts or apps should have to bear the burden of picking which > > > address or interface to use in order to get packets to their > > > destination need to explain (a) where the hosts or apps get the > > > information necessary to make those choices in a reliable and > > > timely fashion, and probably (b) how to provide a usable endpoint > > > identifier under those conditions that can be passed between hosts > > > at arbitrary locations. > > > > It seems to me that what needs to be answered first is whether we are > > already resigned to dealing with that problem with mobility, > > renumbering, and multihoming. > > If we're resigned to dealing with an intractable problem, maybe we need > to rethink that assumption. Well, that's what I'm trying to tease apart here: what's tractible, and what's intractible. If the entire problem space is intractible, then we probably have some pretty big problems. It's not clear to me that it is though... read on. > But it's not clear that either mobility or > renumbering presents the same kind of challenge. In the case of > mobility I think it's fairly simple to decide whether to use a home or > in-care-of address as the source address, and this can be dictated by > the application. I'd say it's the stack, (for MIP at least) but that's a small point. > As for > "multihoming" - these days people mean different things when they say > that, so I can't tell for sure what you mean. Nothing exciting: two different interfaces, two different prefixes. > > There's good reason to want to use a > > local prefix rather than mobile IP for new communiation if possible > > since it more cleanly eliminates the dog leg through the home agent. > > Taken in isolation, that's certainly true. But it presumes several > things, one of which is that a sending host can tell which of several > prefixes is the best to use. (or if not the best, which ones are more > likely to work well than others). It's easy to construct cases where > it's possible for the sending host to do this; somewhat more difficult > to construct a convincing argument that this can be done in general. Correct. Naively, when you're, say, starting a TCP connection from a mobile node, if one of your prefixes is bound to a tunnel (eg, a home agent), you'd almost certainly like to use a CoA prefix instead... unless you think you might move, and the router which owns CoA prefix can't be a home agent for whatever reason. So it appears that even this fairly simple bit of policy: "Use CoA prefix on outbound TCP connections" isn't quite as simple as it first appears. How on earth do I know if I might move? Thus, it sort of reduces to "only if the current router will support mobility in case I move", or "I'm willing to deal with a loss of connectivity on some sessions". But, this still seems to not rely on anything extra about the prefix itself other than what we already know. I think that a similar argument can be made for renumbering. That is, we can finesse the issue such that end hosts don't have to know any sort of qualities about the prefix other than either what it currently knows, or what a real router told it to believe (eg, the preference). So I get back to my larger point: is the real devil here hosts trying to know policy information about prefixes that we currently have no way (or desire) to spread around? I mean, I've always thought that that was a pretty basic part of the internet architecture, which is one of the reasons I don't like the implications of scoped addresses. Abandoning that philosophy pretty much says there is no practical difference between a host and a router. 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 Apr 30 13:59:59 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 h3UKxwhs026436; Wed, 30 Apr 2003 13:59:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UKxwnX026435; Wed, 30 Apr 2003 13:59:58 -0700 (PDT) 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 h3UKxshs026428 for ; Wed, 30 Apr 2003 13:59:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UL01Kw006590 for ; Wed, 30 Apr 2003 14:00:01 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id OAA02702 for ; Wed, 30 Apr 2003 14:59:53 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h3UKxUv22772; Wed, 30 Apr 2003 16:59:30 -0400 (EDT) Date: Wed, 30 Apr 2003 16:59:30 -0400 From: Keith Moore To: Michael Thomas Cc: moore@cs.utk.edu, mat@cisco.com, john-ietf@jck.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: My thoughts on local-use addresses Message-Id: <20030430165930.3b7af536.moore@cs.utk.edu> In-Reply-To: <16048.13708.414125.689623@thomasm-u1.cisco.com> References: <20030426060420.GA93218@lethargic.dyndns.org> <20030426164255.GA98043@lethargic.dyndns.org> <20030426130211.321b0a4d.moore@cs.utk.edu> <13367010.1051372503@p3.JCK.COM> <20030430135832.1a645f93.moore@cs.utk.edu> <16048.5557.124583.930323@thomasm-u1.cisco.com> <20030430151648.3c3d352e.moore@cs.utk.edu> <16048.13708.414125.689623@thomasm-u1.cisco.com> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > If we're resigned to dealing with an intractable problem, maybe we > > need to rethink that assumption. > > Well, that's what I'm trying to tease apart > here: what's tractible, and what's intractible. > If the entire problem space is intractible, > then we probably have some pretty big problems. > It's not clear to me that it is though... read on. > > > But it's not clear that either mobility or > > renumbering presents the same kind of challenge. In the case of > > mobility I think it's fairly simple to decide whether to use a home > > or in-care-of address as the source address, and this can be > > dictated by the application. > > I'd say it's the stack, (for MIP at least) but > that's a small point. nope, the app. the stack doesn't know whether the app prefers stability or efficiency, unless the app tells it which it prefers. but at least the app probably has an idea which one is better. this is fundamentally different than expecting either the host or the app to choose between multiple source or destination addresses, each pair imposing apparently (to the host and app) arbitrary constraints on what the network will pass. 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 Apr 30 15:06: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 h3UM6nhs027012; Wed, 30 Apr 2003 15:06:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UM6nWV027011; Wed, 30 Apr 2003 15:06:49 -0700 (PDT) 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 h3UM6khs027004 for ; Wed, 30 Apr 2003 15:06:46 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UM6rKw027723 for ; Wed, 30 Apr 2003 15:06:53 -0700 (PDT) Received: from defiant.dfw.nostrum.com (adsl-65-67-187-82.dsl.rcsntx.swbell.net [65.67.187.82]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3UM6lrZ004703 for ; Wed, 30 Apr 2003 15:06:48 -0700 (PDT) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h3UM6aL23620; Wed, 30 Apr 2003 17:06:36 -0500 Message-ID: <010101c30f64$c7792f20$93b58742@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" , "Michael Thomas" Cc: , , , , References: <20030426060420.GA93218@lethargic.dyndns.org><20030426164255.GA98043@lethargic.dyndns.org><20030426130211.321b0a4d.moore@cs.utk.edu><13367010.1051372503@p3.JCK.COM><20030430135832.1a645f93.moore@cs.utk.edu><16048.5557.124583.930323@thomasm-u1.cisco.com><20030430151648.3c3d352e.moore@cs.utk.edu><16048.13708.414125.689623@thomasm-u1.cisco.com> <20030430165930.3b7af536.moore@cs.utk.edu> Subject: Re: My thoughts on local-use addresses Date: Wed, 30 Apr 2003 17:06:07 -0500 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Keith Moore" > nope, the app. the stack doesn't know whether the app prefers stability > or efficiency, unless the app tells it which it prefers. but at least > the app probably has an idea which one is better. The app developer often doesn't know these things either -- if the app understands this new API at all, I think it'd most often end up as a user knob, meaning we could just call it a stack option and leave the app out of things entirely. > this is fundamentally different than expecting either the host or the app > to choose between multiple source or destination addresses, each > pair imposing apparently (to the host and app) arbitrary constraints > on what the network will pass. Which is harder, having the stack give the app a list of source and destination addresses and then expect the app to figure out which to use, or have the stack attempt various combinations of source and destination addresses and just notify the application which one(s) worked? Something tells me the latter is both easier and more likely to be implemented correctly. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 15:22:48 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 h3UMMlhs027426; Wed, 30 Apr 2003 15:22:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UMMlBF027421; Wed, 30 Apr 2003 15:22:47 -0700 (PDT) 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 h3UMMhhs027414 for ; Wed, 30 Apr 2003 15:22:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UMMpKw002602 for ; Wed, 30 Apr 2003 15:22:51 -0700 (PDT) Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h3UMMjrZ011079 for ; Wed, 30 Apr 2003 15:22:45 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 30 Apr 2003 18:22:40 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141B9D6@ftmail.lab.flarion.com> From: Hesham Soliman To: "'Stephen Sprunk'" , Keith Moore , Michael Thomas Cc: moore@cs.utk.edu, mat@CISCO.COM, john-ietf@jck.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: RE: My thoughts on local-use addresses Date: Wed, 30 Apr 2003 18:22:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A side comment independent of the site-local discussion. > Thus spake "Keith Moore" > > nope, the app. the stack doesn't know whether the app > prefers stability > > or efficiency, unless the app tells it which it prefers. > but at least > > the app probably has an idea which one is better. > > The app developer often doesn't know these things either -- > if the app > understands this new API at all, I think it'd most often end > up as a user > knob, meaning we could just call it a stack option and leave > the app out of > things entirely. > > > this is fundamentally different than expecting either the > host or the app > > to choose between multiple source or destination addresses, each > > pair imposing apparently (to the host and app) arbitrary > constraints > > on what the network will pass. > > Which is harder, having the stack give the app a list of source and > destination addresses and then expect the app to figure out > which to use, or > have the stack attempt various combinations of source and destination > addresses and just notify the application which one(s) worked? > => There is another option: _Abstract_ the API to the app to reflect the "benefits" or "meaning" of either option. For instance, if you compare the MIP home address and CoA, you can abstract the meaning of these addresses to indicate things like whether the connection needs to be "stable" or not. There are other cases where the stack might already know what a well-known app might need. So there maybe a need for both sides to provide input. And things get more complex of course when the app has many requirements. If we have to make a general rule then I'd prefer the app to decide. But I'm not sure that there is a need for a general rule here. Hesham > Something tells me the latter is both easier and more likely to be > implemented correctly. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 30 16:20: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 h3UNK0hs028143; Wed, 30 Apr 2003 16:20:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3UNK0FC028142; Wed, 30 Apr 2003 16:20:00 -0700 (PDT) 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 h3UNJuhs028135 for ; Wed, 30 Apr 2003 16:19:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h3UNK3uc019296 for ; Wed, 30 Apr 2003 16:20:03 -0700 (PDT) Received: from garlic.apnic.net (garlic.apnic.net [202.12.29.224]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id RAA00467 for ; Wed, 30 Apr 2003 17:19:56 -0600 (MDT) Received: from garlic.apnic.net (localhost [127.0.0.1]) by garlic.apnic.net (8.12.8p1/8.12.8) with ESMTP id h3UNJ8BX001051 for ; Thu, 1 May 2003 09:19:09 +1000 (EST) Received: (from ggm@localhost) by garlic.apnic.net (8.12.8p1/8.12.8) id h3UNJ8TT000917; Thu, 1 May 2003 09:19:08 +1000 (EST) Date: Thu, 1 May 2003 09:19:08 +1000 From: George Michaelson To: ipng@sunroof.eng.sun.com Subject: RFID in V6? Message-Id: <20030501091908.0831e0c9.ggm@apnic.net> Organization: APNIC Pty Ltd X-Mailer: Sylpheed version 0.8.11claws87 (GTK+ 1.2.10; i386-pc-netbsdelf1.6R) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [ posted to multi6 17 March 2003. Nobody replied, but I really am interested in this question, and it was suggested I try here. -ggm] Will RFID map into V6 in a sensible manner? If there was even a restricted subset mapping, what kinds of things could we do with it? -George -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 18:04: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 h4114ths028513; Wed, 30 Apr 2003 18:04:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4114t8p028512; Wed, 30 Apr 2003 18:04:55 -0700 (PDT) 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 h4114phs028505 for ; Wed, 30 Apr 2003 18:04:51 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4114xuc016074 for ; Wed, 30 Apr 2003 18:04:59 -0700 (PDT) Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id TAA26376 for ; Wed, 30 Apr 2003 19:04:53 -0600 (MDT) Received: from [127.0.0.1] (flets2-79.sfc.keio.ac.jp [133.27.133.79]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id F003D5D0C9; Thu, 1 May 2003 10:04:51 +0900 (JST) Date: Thu, 01 May 2003 10:04:49 +0900 From: Jun Murai To: "George Michaelson" Subject: re: RFID in V6? Cc: Message-Id: <20030501093442.CB2D.JUN@wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Mailer: Becky! ver. 2.05.06 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4114qhs028506 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk George, my answer is 'possible'. it all depends on the definition of 'RFID' and an architecture to handle RFIDs. RFIDs are in very wide range from its intelligence level; >From dumb ic-tags which are just responding its id back to a request, to basically a computer system containing an ID. Some IDs are smaller than 128 bit, but there are IDs with 256bit and more are introduced. the mapping you are talking about can anyway be defined. I think some active studies on the subject (architectual definition of rf-ids) are starting in several places. jun ----- Original Message ----- From: "George Michaelson" To: Sent: Thursday, May 01, 2003 1:19 AM Subject: RFID in V6? > > [ posted to multi6 17 March 2003. Nobody replied, but I really am interested in > this question, and it was suggested I try here. -ggm] > > Will RFID map into V6 in a sensible manner? > > If there was even a restricted subset mapping, what kinds of things could we > do with it? > > -George > > -- > George Michaelson | APNIC > Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 > Phone: +61 7 3367 0490 | Australia > Fax: +61 7 3367 0482 | http://www.apnic.net > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 30 18:17: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 h411H5hs028728; Wed, 30 Apr 2003 18:17:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h411H5Xa028727; Wed, 30 Apr 2003 18:17:05 -0700 (PDT) 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 h411H2hs028720 for ; Wed, 30 Apr 2003 18:17:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h411H9uc018614 for ; Wed, 30 Apr 2003 18:17:09 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id TAA11801 for ; Wed, 30 Apr 2003 19:17:03 -0600 (MDT) Received: from SGOSWAMIPCL ([63.164.145.161]) by changeofhabit.mr.itd.umich.edu (rsug3/3.2r) with ESMTP id h411H2C22961 for ; Wed, 30 Apr 2003 21:17:02 -0400 (EDT) From: "Subrata Goswami" To: Subject: RE: RFID in V6? Date: Wed, 30 Apr 2003 18:15:25 -0700 Message-ID: <00bf01c30f7f$25a0bc20$10c0140a@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 In-Reply-To: <20030501091908.0831e0c9.ggm@apnic.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The Electronic Product Code (EPC) from MIT's Auto-ID center is 96 bits - should fit into the original 128 bit IPv6 address with a unique 32 bit prefix. Although Auto-ID center is reserving the right to define longer EPC's. A 96 bit EPC has the following components. Header: 8 bits contains version, length etc. Manager: 28 bits - manufacturer Object: 24 bits - the Stock Keeping Unit (SKU) # Serial #: 36 bits Subrata > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of George Michaelson > Sent: Wednesday, April 30, 2003 4:19 PM > To: ipng@sunroof.eng.sun.com > Subject: RFID in V6? > > > > [ posted to multi6 17 March 2003. Nobody replied, but I > really am interested in > this question, and it was suggested I try here. -ggm] > > Will RFID map into V6 in a sensible manner? > > If there was even a restricted subset mapping, what kinds of > things could we do with it? > > -George > > -- > George Michaelson | APNIC > Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 > Phone: +61 7 3367 0490 | Australia > Fax: +61 7 3367 0482 | http://www.apnic.net > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Apr 30 18:31:15 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 h411VFhs028941; Wed, 30 Apr 2003 18:31:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h411VFHX028940; Wed, 30 Apr 2003 18:31:15 -0700 (PDT) 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 h411VBhs028933 for ; Wed, 30 Apr 2003 18:31:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h411VJKw028871 for ; Wed, 30 Apr 2003 18:31:19 -0700 (PDT) Received: from garlic.apnic.net (garlic.apnic.net [202.12.29.224]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id TAA17614 for ; Wed, 30 Apr 2003 19:31:12 -0600 (MDT) Received: from garlic.apnic.net (localhost [127.0.0.1]) by garlic.apnic.net (8.12.8p1/8.12.8) with ESMTP id h411UPBX002276; Thu, 1 May 2003 11:30:25 +1000 (EST) Received: (from ggm@localhost) by garlic.apnic.net (8.12.8p1/8.12.8) id h411UOP0002657; Thu, 1 May 2003 11:30:24 +1000 (EST) Date: Thu, 1 May 2003 11:30:24 +1000 From: George Michaelson To: Jun Murai Cc: Subject: Re: RFID in V6? Message-Id: <20030501113024.53beed26.ggm@apnic.net> In-Reply-To: <20030501093442.CB2D.JUN@wide.ad.jp> References: <20030501093442.CB2D.JUN@wide.ad.jp> Organization: APNIC Pty Ltd X-Mailer: Sylpheed version 0.8.11claws87 (GTK+ 1.2.10; i386-pc-netbsdelf1.6R) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Good to hear an architecture/planning process is in progress. For the dumb ic-tags, having a mapping could still be useful for some people. In a previous work context, they discussed the 'tag all cans of soup' model, and wanted to present a view where these tagged devices asserted as IP addressable objects via some other box. This means you can know the RFID for a class of objects, and effectively 'ping' them to find where there is a smarter box which knows about them. Doing it in applications space implies restricting yourself to that application-space model of what behaviours you want, while doing it in an IP address namespace might be more general I didn't realize the tags now exceeded 128bits. That also implies the reverse mapping function: embed all IPv6 128bit addresses as a sub-set of the bigger footprint RFID. Then, you can make more complex RF equipment which is a computer but it responds for a legal RFID on an RFID scanner in that RF space. That might require IANA or somebody to ask the RFID agencies for a prefix in 256bit space which can reserve the 128bits under there for IPv6. cheers -George On Thu, 01 May 2003 10:04:49 +0900 Jun Murai wrote: > George, > my answer is 'possible'. > it all depends on the definition of 'RFID' and an architecture to handle > RFIDs. > > RFIDs are in very wide range from its intelligence level; > >From dumb ic-tags which are just responding its id back to a request, to > basically a computer system containing an ID. > > Some IDs are smaller than 128 bit, but there are IDs with 256bit and > more are introduced. the mapping you are talking about can anyway be > defined. > > I think some active studies on the subject (architectual definition of > rf-ids) are starting in several places. > > jun > > ----- Original Message ----- > From: "George Michaelson" > To: > Sent: Thursday, May 01, 2003 1:19 AM > Subject: RFID in V6? > > > > > > [ posted to multi6 17 March 2003. Nobody replied, but I really am interested > > in > > this question, and it was suggested I try here. -ggm] > > > > Will RFID map into V6 in a sensible manner? > > > > If there was even a restricted subset mapping, what kinds of things could we > > do with it? > > > > -George > > > > -- > > George Michaelson | APNIC > > Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 > > Phone: +61 7 3367 0490 | Australia > > Fax: +61 7 3367 0482 | http://www.apnic.net > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 30 19:02: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 h4122Xhs029192; Wed, 30 Apr 2003 19:02:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4122XUe029191; Wed, 30 Apr 2003 19:02:33 -0700 (PDT) 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 h4122Ths029184 for ; Wed, 30 Apr 2003 19:02:29 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4122bKw004507 for ; Wed, 30 Apr 2003 19:02:37 -0700 (PDT) Received: from mailout2.samsung.com (u25.gpu114.samsung.co.kr [203.254.224.25]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id TAA09644 for ; Wed, 30 Apr 2003 19:02:31 -0700 (PDT) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HE600D05QZXWR@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 01 May 2003 11:02:21 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HE600HHUQZWSF@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 01 May 2003 11:02:21 +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 <0HE6007FUQZWIA@mmp1.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 01 May 2003 11:02:20 +0900 (KST) Date: Mon, 31 Mar 2003 11:01:21 +0900 From: Soohong Daniel Park Subject: RE: RFID in V6? In-reply-to: <00bf01c30f7f$25a0bc20$10c0140a@SGOSWAMIPCL> To: "'Subrata Goswami'" , ipng@sunroof.eng.sun.com Message-id: <005f01c2f729$6d4e6810$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 Hello Subrata Basically I am wondering below formation of Auto-ID is a standard or not. If we want to use an IPv6 address with Auto-ID (96bit), there is no extra space to make an address. We only have to use 32bit prefix length. What I want to say is that if we want to reduce Auto-ID, is it possible or not ? Daniel -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Subrata Goswami Sent: Thursday, May 01, 2003 10:15 AM To: ipng@sunroof.eng.sun.com Subject: RE: RFID in V6? The Electronic Product Code (EPC) from MIT's Auto-ID center is 96 bits - should fit into the original 128 bit IPv6 address with a unique 32 bit prefix. Although Auto-ID center is reserving the right to define longer EPC's. A 96 bit EPC has the following components. Header: 8 bits contains version, length etc. Manager: 28 bits - manufacturer Object: 24 bits - the Stock Keeping Unit (SKU) # Serial #: 36 bits Subrata > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of George Michaelson > Sent: Wednesday, April 30, 2003 4:19 PM > To: ipng@sunroof.eng.sun.com > Subject: RFID in V6? > > > > [ posted to multi6 17 March 2003. Nobody replied, but I > really am interested in > this question, and it was suggested I try here. -ggm] > > Will RFID map into V6 in a sensible manner? > > If there was even a restricted subset mapping, what kinds of > things could we do with it? > > -George > > -- > George Michaelson | APNIC > Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 > Phone: +61 7 3367 0490 | Australia > Fax: +61 7 3367 0482 | http://www.apnic.net > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Wed Apr 30 19:36:49 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 h412anhs029425; Wed, 30 Apr 2003 19:36:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h412andQ029424; Wed, 30 Apr 2003 19:36:49 -0700 (PDT) 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 h412aihs029417 for ; Wed, 30 Apr 2003 19:36:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h412aqKw009965 for ; Wed, 30 Apr 2003 19:36:52 -0700 (PDT) Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h412alrZ006712 for ; Wed, 30 Apr 2003 19:36:47 -0700 (PDT) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19B3w9-00001M-00; Wed, 30 Apr 2003 19:36:41 -0700 Date: Wed, 30 Apr 2003 22:35:35 -0400 From: Keith Moore To: "Stephen Sprunk" Cc: moore@cs.utk.edu, mat@cisco.com, john-ietf@jck.com, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: My thoughts on local-use addresses Message-Id: <20030430223535.5dd95ad6.moore@cs.utk.edu> In-Reply-To: <010101c30f64$c7792f20$93b58742@ssprunk> References: <20030426060420.GA93218@lethargic.dyndns.org> <20030426164255.GA98043@lethargic.dyndns.org> <20030426130211.321b0a4d.moore@cs.utk.edu> <13367010.1051372503@p3.JCK.COM> <20030430135832.1a645f93.moore@cs.utk.edu> <16048.5557.124583.930323@thomasm-u1.cisco.com> <20030430151648.3c3d352e.moore@cs.utk.edu> <16048.13708.414125.689623@thomasm-u1.cisco.com> <20030430165930.3b7af536.moore@cs.utk.edu> <010101c30f64$c7792f20$93b58742@ssprunk> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > nope, the app. the stack doesn't know whether the app prefers stability > > or efficiency, unless the app tells it which it prefers. but at least > > the app probably has an idea which one is better. > > The app developer often doesn't know these things either -- if the app > understands this new API at all, I think it'd most often end up as a user > knob, meaning we could just call it a stack option and leave the app out of > things entirely. at least some apps do know these things. a web browser, for instance, understands that its TCP connections are ephemeral, and it knows how to recover from broken connections. same thing for an SMTP MTA or a mail reader. OTOH an interactive login using ssh is probably better off using stable addresses, as is an NFS mount. however if the API exists then nothing prevents the app from having a knob that lets the user override the default. > Which is harder, having the stack give the app a list of source and > destination addresses and then expect the app to figure out which to use, or > have the stack attempt various combinations of source and destination > addresses and just notify the application which one(s) worked? from experience, the delay in the latter case is often unacceptable, and even if it isn't, the stack often makes the wrong choice for the app. > Something tells me the latter is both easier and more likely to be > implemented correctly. you're simply wrong about that. 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 Apr 30 19:56: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 h412u5hs029684; Wed, 30 Apr 2003 19:56:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h412u4Jn029683; Wed, 30 Apr 2003 19:56:04 -0700 (PDT) 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 h412u1hs029676 for ; Wed, 30 Apr 2003 19:56:01 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h412u9uc005983 for ; Wed, 30 Apr 2003 19:56:09 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id TAA28758 for ; Wed, 30 Apr 2003 19:56:03 -0700 (PDT) Received: from SGOSWAMIPCL ([63.164.145.161]) by changeofhabit.mr.itd.umich.edu (rsug3/3.2r) with ESMTP id h412u1C03925; Wed, 30 Apr 2003 22:56:01 -0400 (EDT) From: "Subrata Goswami" To: "'Soohong Daniel Park'" , Subject: RE: RFID in V6? Date: Wed, 30 Apr 2003 19:54:07 -0700 Message-ID: <00e701c30f8c$f99b79e0$10c0140a@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 In-Reply-To: <005f01c2f729$6d4e6810$b7cbdba8@daniel7209> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Daniel, the Auto-ID center also has an EPC of 64 bits. It is always possible to reduce a longer range of number to a smaller one - hashing, selectively picking some bits (i.e. SKU and SN), etc. The issue is what makes sense and where. I am not sure enough known about usages of RFTAG ID's with IPv6/v4 addresses. Subrata > -----Original Message----- > From: Soohong Daniel Park [mailto:soohong.park@samsung.com] > Sent: Sunday, March 30, 2003 6:01 PM > To: 'Subrata Goswami'; ipng@sunroof.eng.sun.com > Subject: RE: RFID in V6? > > > Hello Subrata > > Basically I am wondering below formation of Auto-ID is a > standard or not. If we want to use an IPv6 address with > Auto-ID (96bit), there is no extra space to make an address. > We only have to use 32bit prefix length. > > What I want to say is that if we want to reduce Auto-ID, is > it possible or not ? > > Daniel > > > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Subrata Goswami > Sent: Thursday, May 01, 2003 10:15 AM > To: ipng@sunroof.eng.sun.com > Subject: RE: RFID in V6? > > > The Electronic Product Code (EPC) from MIT's Auto-ID center > is 96 bits - should fit into the original 128 bit IPv6 > address with a unique 32 bit prefix. Although Auto-ID center > is reserving the right to define longer EPC's. A 96 bit EPC > has the following components. > > Header: 8 bits contains version, length etc. > Manager: 28 bits - manufacturer > Object: 24 bits - the Stock Keeping Unit (SKU) # > Serial #: 36 bits > > > Subrata > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of George > Michaelson > > Sent: Wednesday, April 30, 2003 4:19 PM > > To: ipng@sunroof.eng.sun.com > > Subject: RFID in V6? > > > > > > > > [ posted to multi6 17 March 2003. Nobody replied, but I really am > > interested in > > this question, and it was suggested I try here. -ggm] > > > > Will RFID map into V6 in a sensible manner? > > > > If there was even a restricted subset mapping, what kinds of things > > could we do with it? > > > > -George > > > > -- > > George Michaelson | APNIC > > Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 > > Phone: +61 7 3367 0490 | Australia > > Fax: +61 7 3367 0482 | http://www.apnic.net > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 --------------------------------------------------------------------