From owner-ipng@sunroof.eng.sun.com Fri Nov 1 01:13:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA19D129010769; Fri, 1 Nov 2002 01:13:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA19D1I2010768; Fri, 1 Nov 2002 01: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA19Cr29010761 for ; Fri, 1 Nov 2002 01:12:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA19D1bB007253 for ; Fri, 1 Nov 2002 01:13:02 -0800 (PST) Received: from ocean.jinmei.org (kame201.kame.net [203.178.141.201]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA24605 for ; Fri, 1 Nov 2002 02:12:53 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by ocean.jinmei.org (8.12.3/8.12.3) with ESMTP id gA19DdKB005818; Fri, 1 Nov 2002 18:13:39 +0900 (JST) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Date: Fri, 01 Nov 2002 18:13:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman Cc: Brian Haberman , Mark Smith , ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-Reply-To: <5.1.0.14.2.20021031094321.02e6c010@mail.windriver.com> References: <200210310529.g9V5TO008795@astro.cs.utk.edu> <1036046913.11151.434.camel@dupy> <3DC12E58.4020001@nc.rr.com> <5.1.0.14.2.20021031094321.02e6c010@mail.windriver.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 11 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 31 Oct 2002 09:51:17 -0500, >>>>> Margaret Wasserman said: > Are there any commercial routers today that include SBR support? If I remember correctly, NEC has a product that supports SBR. 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 Fri Nov 1 02:44:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1AiW29010974; Fri, 1 Nov 2002 02:44:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA1AiVNM010973; Fri, 1 Nov 2002 02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1AiR29010966 for ; Fri, 1 Nov 2002 02:44:27 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA1AiaMq016555 for ; Fri, 1 Nov 2002 02:44:36 -0800 (PST) Received: from ocean.jinmei.org (kame201.kame.net [203.178.141.201]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03883 for ; Fri, 1 Nov 2002 02:44:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ocean.jinmei.org (8.12.3/8.12.3) with ESMTP id gA1AjOKB006093; Fri, 1 Nov 2002 19:45:24 +0900 (JST) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Date: Fri, 01 Nov 2002 19:45:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 36 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 31 Oct 2002 20:43:14 +0200 (EET), >>>>> Pekka Savola said: >> > Now the attacker can send packets with a fec0::/10 source >> > address to the customer -- no one will block them unless >> > they're explicitly configured as site borders -- before the >> > customer itself. And if the customer does not block them, >> > we're in for very serious trouble. >> > >> > That seemed to be what everyone except me read the ADDRARCH >> > paragraph to imply. I thought attackers first-hop router (or >> > at the latest, attackers edge router) should block these >> > packets automatically. >> >> No. At least I read ADDRARCH as meaning that the routers between the >> attacker and the customer would all be configured (one way or another - >> either manually or because it's their default configuration) as site >> boundaries, meaning they would filter the site-local packets. > This reading of ADDRARCH seems to be in conflict with what you said > earlier: I don't think so. Rich said "either manually or because it's their default configuration", which perfectly coincides with what he said before. The difference seems to me that you're saying that such an assumption is naive and Rich doesn't think so. IMO, this is a difference in philosophy and either side has some valid points. So I don't think we can reach some consensus by further discussion, at least within this thread. 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 Fri Nov 1 03:53:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1Br329011144; Fri, 1 Nov 2002 03:53:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA1Br3qC011143; Fri, 1 Nov 2002 03:53:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1Bqx29011136 for ; Fri, 1 Nov 2002 03:52:59 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA1Br8bB027277 for ; Fri, 1 Nov 2002 03:53:08 -0800 (PST) Received: from ocean.jinmei.org (kame201.kame.net [203.178.141.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08246 for ; Fri, 1 Nov 2002 03:53:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ocean.jinmei.org (8.12.3/8.12.3) with ESMTP id gA1BrxKB006221; Fri, 1 Nov 2002 20:53:59 +0900 (JST) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Date: Fri, 01 Nov 2002 20:53:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: Node Requirements Issue 3 In-Reply-To: <5.1.0.14.2.20021031193507.0301bec0@mail.windriver.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <5.1.0.14.2.20021031193507.0301bec0@mail.windriver.com> <5.1.0.14.2.20021028195325.07aaf4f0@mail.windriver.com> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Fri_Nov__1_20:53:58_2002-1" X-Dispatcher: imput version 20000228(IM140) Lines: 209 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Fri_Nov__1_20:53:58_2002-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Thu, 31 Oct 2002 19:38:46 -0500, >>>>> Margaret Wasserman said: >> A BCP that discourages uses of SLs except >> in certain narrow cases and explains why is probably more useful than a >> BCP that tries to explain exactly when SLs cause problems and when they don't. >> Of course, it's quite possible to have both. > I just happen to have a somewhat incomplete document lying around > that I think could be an excellent start for this BCP. > Unfortunately, we're past the -00 draft deadline, so I can't > post it, but I will try to finish it up and post it after Atlanta. > Who would like to help me fill in the missing pieces? I could > particularly use some help documenting the issues that site-locals > cause for: > - Applications > - Security Protocols (and security issues in general) > - Transport Protocols (particularly the voice/session stuff) > - DNS Please let me check, what is the goal of "this" BCP? 1. to discourage the use of SLs except in non-globally-connected networks, as you proposed before (attached) 2. to describe issues on using SLs without any limitation on the usage (i.e. it covers the case for globally-connected networks) If we take the position 1 at this stage, we'll just see the same discussion we've had so far on the document, and will go into the same loop. So, the document should be careful to be fair enough, at least for now, and, IMO, should take the position 2. Of course, we'll then be able to take the decision of discouraging (or keeping) SLs, if the fair document can convince the majority of the group. If we're going to take the fair position for the moment, I'm willing to help the effort in some areas. I guess I can do something on DNS (and perhaps applications.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Fri_Nov__1_20:53:58_2002-1 Content-Type: message/rfc822 Return-Path: Return-Path: Received: from localhost (localhost [127.0.0.1]) by ocean.jinmei.org (8.12.3/8.12.3) with ESMTP id g9T1Nhfs015750 for ; Tue, 29 Oct 2002 10:24:41 +0900 (JST) (envelope-from owner-ipng@sunroof.eng.sun.com) Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-6.1.0) for jinmei@localhost (single-drop); Tue, 29 Oct 2002 10:24:41 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9T18nG68524 for ; Tue, 29 Oct 2002 10:08:49 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.11.6/8.11.6) with ESMTP id g9T18mv07814 for ; Tue, 29 Oct 2002 10:08:48 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id KAA18235 for ; Tue, 29 Oct 2002 10:08:48 +0900 (JST) Received: from mx2.toshiba.co.jp (mx2.toshiba.co.jp [133.199.160.163]) by isl.rdc.toshiba.co.jp (8.11.6/8.11.6/1.4) with ESMTP id g9T18ln24357 for ; Tue, 29 Oct 2002 10:08:47 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA24030; Tue, 29 Oct 2002 10:08:47 +0900 (JST) Received: from inet-tsb5.toshiba.co.jp (localhost [127.0.0.1]) by tsb-sgw.toshiba.co.jp with ESMTP id KAA25538 for ; Tue, 29 Oct 2002 10:08:47 +0900 (JST) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by inet-tsb5.toshiba.co.jp with ESMTP id g9T18j203815 for ; Tue, 29 Oct 2002 10:08:45 +0900 (JST) Received: by orange.kame.net (Postfix) id 307F571D3; Tue, 29 Oct 2002 10:08:46 +0900 (JST) Delivered-To: jinmei@kame.net Received: from sh.wide.ad.jp (sh.wide.ad.jp [203.178.137.85]) by orange.kame.net (Postfix) with ESMTP id 9CFD271CF for ; Tue, 29 Oct 2002 10:08:45 +0900 (JST) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by sh.wide.ad.jp (8.11.6+3.4W/8.11.0) with ESMTP id g9T18Ii07139 for ; Tue, 29 Oct 2002 10:08:18 +0900 (JST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01634; Mon, 28 Oct 2002 18:07:51 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9T17HNG003803; Mon, 28 Oct 2002 17:07:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T16e29020075; Mon, 28 Oct 2002 17:06:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id g9T16d10020074; Mon, 28 Oct 2002 17:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id g9T16a29020067 for ; Mon, 28 Oct 2002 17:06:36 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g9T16jMq003665 for ; Mon, 28 Oct 2002 17:06:46 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28662 for ; Mon, 28 Oct 2002 18:06:45 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.42]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA21195; Mon, 28 Oct 2002 17:06:17 -0800 (PST) Message-Id: <5.1.0.14.2.20021028195325.07aaf4f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 28 Oct 2002 20:06:12 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "Keith Moore" , , In-Reply-To: <2B81403386729140A3A899A8B39B046405E3CD@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,IN_REP_TO,SPAM_PHRASE_00_01,X_AUTH_WARNING version=2.41 X-Spam-Level: X-UIDL: JXM!!-"M!!dlm"!Jd0!! I have heard several arguments for why people might like to use some sort of limited-scope addressing in special circumstances. I've also heard a couple of general benefits (long-lived connections and dubious security benefits). But, I haven't really heard any arguments that have swayed me from my original position. Private addressing causes significant complexities, and we don't know how to solve all of the problems that it causes for applications, DNS, routing protocols and network management protocols. Therefore, I don't think that we should define it as an inherent part of IPv6. There may be some significant advantages to private addressing, so I _do_ support the idea of an IRTF WG being formed to sort out the issues surrounding private addressing and make recommendations regarding what the IETF should/shouldn't standardize in this area. I also think that an IAB document in this area would be appropriate. But, I don't want to see us standardize a badly-thought-out private addressing scheme at the core of IPv6. In my opinion, there are three possible choices here: (1) Limit the scope of the IPv6 WG's problem, by forbidding the use of site-local addresses on globally-connected networks in the scoped addressing architecture. This would not preclude work in this area by other groups within the IETF/IRTF, and we could remove the restriction when the implications are fully understood. (2) Develop a complete solution for scoped unicast addressing within the IPv6 WG. This would include solving the problems they cause for all protocols/layers. (3) Define an IP-level solution for scoped addressing (similar to what is currently in the scoped addressing architecture), and consider all of the implications of that architecture on other protocols/layers to be someone else's problem. The first choice is both responsible and doable. I have deep concerns about the second choice, along two lines: (1) I think it is important that we stabilize and complete IPv6 quickly, as folks are widely implementing and deploying it, and (2) I don't know that we have the expertise (in the IPv6 WG or anywhere in the IETF, without further research) to solve these problems. And, in my opinion, the third choice (which is what we seem to be doing so far) is blatantly irresponsible. Are there people who want to argue for choices #2 and/or #3? Or are there other choices that I've left out? 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 -------------------------------------------------------------------- --Multipart_Fri_Nov__1_20:53:58_2002-1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 1 04:11:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1CBS29011267; Fri, 1 Nov 2002 04:11:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA1CBSlG011266; Fri, 1 Nov 2002 04:11:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1CBO29011259 for ; Fri, 1 Nov 2002 04:11:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA1CBXbB029430 for ; Fri, 1 Nov 2002 04:11:33 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23528 for ; Fri, 1 Nov 2002 05:11:27 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA1CBP006753; Fri, 1 Nov 2002 07:11:25 -0500 (EST) Message-Id: <200211011211.gA1CBP006753@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: awhite@arc.corp.mot.com cc: ipng@sunroof.eng.sun.com Subject: Re: Why would I use a site-local address? In-reply-to: (Your message of "Fri, 01 Nov 2002 17:56:24 +1100.") <3DC22598.928A4E67@motorola.com> Date: Fri, 01 Nov 2002 07:11:25 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk networks with intermittent connectivity might be a valid case for use of site-locals, though giving such networks a non-routable global prefix would cause fewer problems for applications. also, you're correct that when using 6to4 with dialup v4 providers the prefix is likely change each time the network is connected (unless special arrangements have been made with the ISP), however this does not necessarily hold for native v6 connectivity. with v6 there is not as much need to reuse addresses for dialup lines. IMHO the decision to recommend address reuse on dialup lines should be reexamined for v6. it's not reasonable to assume that v6 applications will cope with rapid prefix changes. the problem with the idea that site-locals should be favored over globals is that this is exactly the wrong rule for some applications and on some networks. as far as I can tell, address selection rules need to be derived from a combination of application requirements and local network policy. 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 Nov 1 04:45:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1Cj729011413; Fri, 1 Nov 2002 04:45:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA1Cj6Xm011412; Fri, 1 Nov 2002 04:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1Cj329011405 for ; Fri, 1 Nov 2002 04:45:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA1CjCbB003285 for ; Fri, 1 Nov 2002 04:45:12 -0800 (PST) Received: from southstation.m5p.com (dsl-209-162-215-52.dsl.easystreet.com [209.162.215.52]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05547 for ; Fri, 1 Nov 2002 05:45:06 -0700 (MST) Received: from m5p.com (parkstreet.m5p.com [10.100.0.1]) by southstation.m5p.com (8.12.5/8.12.5) with ESMTP id gA1Cj5Lw007756 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 1 Nov 2002 04:45:05 -0800 (PST) Received: (from george@localhost) by m5p.com (8.12.5/8.12.1/Submit) id gA1Cj4oY087894; Fri, 1 Nov 2002 04:45:04 -0800 (PST) Date: Fri, 1 Nov 2002 04:45:04 -0800 (PST) Message-Id: <200211011245.gA1Cj4oY087894@m5p.com> From: george+ipng@m5p.com To: ipng@sunroof.eng.sun.com Subject: Recent Posting Stats X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Over the past 8 days, I've received 526 postings on this list from 54 individuals, including this many from people posting 10 or more messages: 10 From: Rob Austein 11 From: Mark Smith 13 From: Mark.Andrews@isc.org 15 From: "Richard Draves" 15 From: john.loughney@nokia.com 23 From: Brian Haberman 23 From: Pekka Savola 27 From: "Hesham Soliman (EAB)" 27 From: "Tony Hain" 29 From: "Michel Py" 35 From: "Bound, Jim" 57 From: Margaret Wasserman 99 From: Keith Moore -- George Mitchell (george+ipng@m5p.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 Nov 1 07:34:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1FYU29011823; Fri, 1 Nov 2002 07:34:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA1FYTM6011822; Fri, 1 Nov 2002 07:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1FYQ29011815 for ; Fri, 1 Nov 2002 07:34:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA1FYYbB027564 for ; Fri, 1 Nov 2002 07:34:35 -0800 (PST) Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09128 for ; Fri, 1 Nov 2002 08:34:29 -0700 (MST) 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 JAA07438; Fri, 1 Nov 2002 09:33:51 -0600 (CST) Message-Id: <5.1.1.5.2.20021101091123.02192300@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 01 Nov 2002 09:31:30 -0600 To: Keith Moore , Ralph Droms From: Richard Carlson Subject: Re: Default site-local behavior for routers Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200210312124.g9VLOi014797@astro.cs.utk.edu> References: <(Your message of "Thu, 31 Oct 2002 15:45:54 EST.") <4.3.2.7.2.20021031153915.020900d8@funnel.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 disagree with this assessment. In the v4 world sites that are, voluntarily or forcibly, using RFC 1918 address do expect to connect into the public Internet. They do so because these are the only IP addresses they have, so what other choice do they have? The multi-address space in the v6 world is being presented in a different light. SLs are NOT replacements for RFC 1918 private addresses, they are just another option that a site can use if it chooses to. SLs have no meaning outside the site boundary, just as LLs have no meaning outside the local link and Globals have no meaning outside the global v6 Internet. Therefore it is not possible for 2 disjoint sites to connect to each other. The options to solve this should include getting globals or creating a new super-site that encompasses the individual sites. The pressure to deploy NATs will only come if we fail to provide these alternatives. Rich At 04:24 PM 10/31/02 -0500, Keith Moore wrote: > > are we looking for a way to > > support applications that span multiple sites that each use site-local > > addresses? > >the reality is that if SLs are widely used in v6 networks, apps will >be expected to span sites using SLs, just as they are now expected >to span between the public internet and sites using RFC 1918 addresses, >and sometimes between multiple sites using RFC 1918 addresses. > >today that tends to require either that all nodes on private networks >maintain an open connection to a point-of-contact in the public >network, and/or that there be appliation-specific proxies at points >where the various realms meet. and it often requires a fair amount >of complexity in the app due to lack of a usable global address space >and the need to do routing through such proxies. > >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 >-------------------------------------------------------------------- ------------------------------------ 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 Fri Nov 1 07:47:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1FlY29011902; Fri, 1 Nov 2002 07:47:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA1FlYG5011901; Fri, 1 Nov 2002 07:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1FlU29011894 for ; Fri, 1 Nov 2002 07:47:30 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA1FlcbB002992 for ; Fri, 1 Nov 2002 07:47:38 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18299 for ; Fri, 1 Nov 2002 08:47:33 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA1FlGU00742; Fri, 1 Nov 2002 10:47:16 -0500 (EST) Message-Id: <200211011547.gA1FlGU00742@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Richard Carlson cc: Keith Moore , Ralph Droms , ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers In-reply-to: (Your message of "Fri, 01 Nov 2002 09:31:30 CST.") <5.1.1.5.2.20021101091123.02192300@atalanta.ctd.anl.gov> Date: Fri, 01 Nov 2002 10:47:16 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In the v4 world sites that are, > voluntarily or forcibly, using RFC 1918 address do expect to connect into > the public Internet. They do so because these are the only IP addresses > they have, so what other choice do they have? for that matter, what other choice do they have using the current address allocation strategies for IPv6? at least in v4 it was once possible to get provider-independent addresses (I've heard it still is possible - though they come at a high price) In v6 we're currently *insisting* on provider-based addresses, making addresses in some ways even more difficult for private sites to get than in IPv4. I understand why this was done, but with current address allocation rules there may be at least as much pressure to use SLs in IPv6 as there is to use 1918 addresses in IPv4. If we were to change things so that sites could get a non-routable provider-independent prefix with about the same ease as getting a domain name *then* there would be less pressure to use SLs. > The pressure to deploy > NATs will only come if we fail to provide these alternatives. I mostly agree - though NATs have also been sold as ways to avoid renumbering and to provide (pseudo-) security and we need to show that there are viable alternatve solutions for these problems also. 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 Nov 1 09:29:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1HTn29012475; Fri, 1 Nov 2002 09:29:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA1HTn07012474; Fri, 1 Nov 2002 09:29:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1HTk29012467 for ; Fri, 1 Nov 2002 09:29:46 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA1HTsbB029140 for ; Fri, 1 Nov 2002 09:29:54 -0800 (PST) Received: from Radish ([143.101.116.201]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA23507 for ; Fri, 1 Nov 2002 09:29:49 -0800 (PST) Received: from ishibashi.net ([127.0.0.1]) by Radish(2.2.8) with SMTP; Fri, 1 Nov 2002 11:29:06 +0900 Date: Fri, 01 Nov 2002 11:29:06 -0600 From: Hiroki Ishibashi Subject: Re: Default site-local behavior for routers To: Margaret Wasserman Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Brian Haberman , Mark Smith , 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.15 (WinNT,500) Organization: NEC Corporation In-Reply-To: References: Message-Id: <87C281CC2E12C5bashi@ipv6.nec.co.jp> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>>> On Thu, 31 Oct 2002 09:51:17 -0500, >>>>>> Margaret Wasserman said: > >> Are there any commercial routers today that include SBR support? > >If I remember correctly, NEC has a product that supports SBR. > Yes, NEC's IX1000, IX2000, and IX5000 Routers can be configured as SBR. ==== HIROKI ISHIBASHI ================================================== E-mail: bashi@ipv6.nec.co.jp ================================================== NEC 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 Nov 1 12:16:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1KGX29013163; Fri, 1 Nov 2002 12:16:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA1KGX8b013162; Fri, 1 Nov 2002 12:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1KFi29013155 for ; Fri, 1 Nov 2002 12:16:30 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA1KFYbB021079 for ; Fri, 1 Nov 2002 12:15:49 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08846 for ; Fri, 1 Nov 2002 12:15:24 -0800 (PST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA1KFFRs027878; Fri, 1 Nov 2002 15:15:15 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA1KFDnP135110; Fri, 1 Nov 2002 13:15:14 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gA1KBic00416; Fri, 1 Nov 2002 15:11:44 -0500 Message-Id: <200211012011.gA1KBic00416@rotala.raleigh.ibm.com> To: george+ipng@m5p.com cc: ipng@sunroof.eng.sun.com Subject: Re: Recent Posting Stats In-Reply-To: Message from george+ipng@m5p.com of "Fri, 01 Nov 2002 04:45:04 PST." <200211011245.gA1Cj4oY087894@m5p.com> Date: Fri, 01 Nov 2002 15:11:44 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, The stats George posted are well worth thinking hard about. When there are so many postings on a list in such a short time, the following is inevitable: - folks don't read them all anymore. I'm sure folks make decisions on which messages to delete unread based on their opinion of an individual poster's typical signal-to-noise ratio based on recent and past postings. In other words, if you want other people to read your postings (which I would assume is the point), less is often more. - postings are often no longer intended to better understand or tease out a better understanding of what the *real* issues and thinking are on an issue. They just become shouting matches. This helps no one (and indeed, tends to push folk away). - The purpose of the WG is to find consensus and a reasonable engineering result. One can't do that if folk are not listening or understanding each other. - it's one thing to understand someone else's view point, but disagree with it. This is a very reasonable thing to do. When this happens, its often good at some oint to simply agree to disagree and stop posting. - It's another to disagree with another viewpoint to the point that whenever it is mentioned (or even hinted at by someone) a long response containing an oft-repeated rant on a particular view point immediately happens. - I can't help but wonder if for some people, the more they post, the more they think they are influencing what is happening. This simply isn't the case in my experience, at least not in a positive sense. *What* one says, matters a lot more than how many times it is said or how loudly. Folks, please please please *think* before you post, reread what you post (before you post it), and ask yourself whether the posting actually sheds any light on the discussion, whether it should just be taken off line, or maybe simply not said at all. 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 Nov 1 12:28:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1KSR29013262; Fri, 1 Nov 2002 12:28:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA1KSRJ9013261; Fri, 1 Nov 2002 12:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1KSN29013254 for ; Fri, 1 Nov 2002 12:28:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA1KS9Mq000583 for ; Fri, 1 Nov 2002 12:28:09 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27477 for ; Fri, 1 Nov 2002 13:28:03 -0700 (MST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA1KRqRs012434; Fri, 1 Nov 2002 15:27:52 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA1KRonP182576; Fri, 1 Nov 2002 13:27:51 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gA1KOLU00541; Fri, 1 Nov 2002 15:24:21 -0500 Message-Id: <200211012024.gA1KOLU00541@rotala.raleigh.ibm.com> To: "Hesham Soliman (EAB)" cc: "'john.loughney@nokia.com'" , Adam_Machalek@nmss.com, pekkas@netcore.fi, ipng@sunroof.eng.sun.com Subject: Re: Node requirements: RFC3041 - Privacy Extensions for Address C onfiguration in IPv6 In-Reply-To: Message from "Hesham Soliman (EAB)" of "Thu, 31 Oct 2002 23:53:57 +0100." <4DA6EA82906FD511BE2F00508BCF0538044F0C5A@Esealnt861.al.sw.ericsson.se> Date: Fri, 01 Nov 2002 15:24:21 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Updating the node requirements and I came to this RFC. > > This RFC raised a lot > > of discussion during the Cellular Hosts draft - I wonder > > what the consensus > > is for the Node requirements. This could be useful for > > end-user hosts, > => for _stationary_ end hosts. Not sure why you say that. RFC 3041 specifically says: 2.3. The Concern With IPv6 Addresses The division of IPv6 addresses into distinct topology and interface identifier portions raises an issue new to IPv6 in that a fixed portion of an IPv6 address (i.e., the interface identifier) can contain an identifier that remains constant even when the topology portion of an address changes (e.g., as the result of connecting to a different part of the Internet). In IPv4, when an address changes, the entire address (including the local part of the address) usually changes. It is this new issue that this document addresses. If addresses are generated from an interface identifier, a home user's address could contain an interface identifier that remains the same from one dialup session to the next, even if the rest of the address changes. The way PPP is used today, however, PPP servers typically unilaterally inform the client what address they are to use (i.e., the client doesn't generate one on its own). This practice, if continued in IPv6, would avoid the concerns that are the focus of this document. A more troubling case concerns mobile devices (e.g., laptops, PDAs, etc.) that move topologically within the Internet. Whenever they move (in the absence of technology such as mobile IP [MOBILEIP]), they form new addresses for their current topological point of attachment. This is typified today by the "road warrior" who has Narten & Draves Standards Track [Page 5] RFC 3041 Extensions to IPv6 Address Autoconfiguration January 2001 Internet connectivity both at home and at the office. While the node's address changes as it moves, however, the interface identifier contained within the address remains the same (when derived from an IEEE Identifier). In such cases, the interface identifier can be used to track the movement and usage of a particular machine [SERIALNUM]. For example, a server that logs usage information together with a source addresses, is also recording the interface identifier since it is embedded within an address. Consequently, any data-mining technique that correlates activity based on addresses could easily be extended to do the same using the interface identifier. This is of particular concern with the expected proliferation of next-generation network-connected devices (e.g., PDAs, cell phones, etc.) in which large numbers of devices are in practice associated with individual users (i.e., not shared). Thus, the interface identifier embedded within an address could be used to track activities of an individual, even as they move topologically within the internet. In summary, IPv6 addresses on a given interface generated via Stateless Autoconfiguration contain the same interface identifier, regardless of where within the Internet the device connects. This facilitates the tracking of individual devices (and thus potentially users). The purpose of this document is to define mechanisms that eliminate this issue, in those situations where it is a concern. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 1 12:40:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1KeP29013423; Fri, 1 Nov 2002 12:40:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA1KePli013422; Fri, 1 Nov 2002 12:40: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA1KeL29013415 for ; Fri, 1 Nov 2002 12:40:21 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA1KeUMq004291 for ; Fri, 1 Nov 2002 12:40:30 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20104 for ; Fri, 1 Nov 2002 12:40:24 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gA1KeHc05456; Fri, 1 Nov 2002 22:40:17 +0200 Date: Fri, 1 Nov 2002 22:40:16 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Richard Draves , Subject: Re: Limiting the Use of Site-Local In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Nov 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >> > Now the attacker can send packets with a fec0::/10 source > >> > address to the customer -- no one will block them unless > >> > they're explicitly configured as site borders -- before the > >> > customer itself. And if the customer does not block them, > >> > we're in for very serious trouble. > >> > > >> > That seemed to be what everyone except me read the ADDRARCH > >> > paragraph to imply. I thought attackers first-hop router (or > >> > at the latest, attackers edge router) should block these > >> > packets automatically. > >> > >> No. At least I read ADDRARCH as meaning that the routers between the > >> attacker and the customer would all be configured (one way or another - > >> either manually or because it's their default configuration) as site > >> boundaries, meaning they would filter the site-local packets. > > > This reading of ADDRARCH seems to be in conflict with what you said > > earlier: > > I don't think so. Rich said "either manually or because it's their > default configuration", which perfectly coincides with what he said > before. > > The difference seems to me that you're saying that such an assumption > is naive and Rich doesn't think so. IMO, this is a difference in > philosophy and either side has some valid points. So I don't think we > can reach some consensus by further discussion, at least within this > thread. Ok, I can agree to that. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 1 16:27:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA20RO29014551; Fri, 1 Nov 2002 16:27:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA20RO8n014550; Fri, 1 Nov 2002 16:27: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA20RL29014543 for ; Fri, 1 Nov 2002 16:27:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA20RTbB003231 for ; Fri, 1 Nov 2002 16:27:29 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03324 for ; Fri, 1 Nov 2002 17:27:23 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA20RCQ1013156; Sat, 2 Nov 2002 01:27:12 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sat, 2 Nov 2002 01:27:12 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C69@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Thomas Narten'" Cc: "'john.loughney@nokia.com'" , Adam_Machalek@nmss.com, pekkas@netcore.fi, ipng@sunroof.eng.sun.com Subject: RE: Node requirements: RFC3041 - Privacy Extensions for Address C onfiguration in IPv6 Date: Sat, 2 Nov 2002 01:27:09 +0100 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 > > > Updating the node requirements and I came to this RFC. > > > This RFC raised a lot > > > of discussion during the Cellular Hosts draft - I wonder > > > what the consensus > > > is for the Node requirements. This could be useful for > > > end-user hosts, > > > => for _stationary_ end hosts. > > Not sure why you say that. RFC 3041 specifically says: > => I took out the RFC text to make the mail shorter. When I made that comment I meant to distinguish IPv6 nodes from MNs based on whether they implement MIPv6 MN functions or not. So when I said "stationary" I meant IPv6 nodes that do not implement MN functions as described in MIPv6. For those MNs, we do not yet have a mechanisms to allow for RFC3041 type home addresses. So there would be no point in having them for the CoA since the HoA is always visible for traffic analysis. According to my definition of stationary above, the RFC text is correct of course. 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 Nov 1 16:30:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA20UY29014608; Fri, 1 Nov 2002 16:30:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA20UYow014607; Fri, 1 Nov 2002 16:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA20UT29014594 for ; Fri, 1 Nov 2002 16:30:29 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA20UcbB004041 for ; Fri, 1 Nov 2002 16:30:38 -0800 (PST) Received: from xinhuanet.com ([202.84.17.129]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA16810 for ; Fri, 1 Nov 2002 16:29:49 -0800 (PST) Date: Fri, 1 Nov 2002 16:29:49 -0800 (PST) Message-Id: <200211020029.QAA16810@nwkea-mail-1.sun.com> Received: from Qpbnlpfut([61.177.117.208]) by xinhuanet.com(JetMail 2.5.3.0) with SMTP id jm273dc32056; Sat, 2 Nov 2002 00:35:35 -0000 From: dhaskin To: ipng@sunroof.eng.sun.com Subject: Hello,let's be friends MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=SE53RcxT558s0d816684GdCm55YyM9 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --SE53RcxT558s0d816684GdCm55YyM9 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --SE53RcxT558s0d816684GdCm55YyM9 Content-Type: audio/x-midi; name=height.scr Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAIk28Ts5OTkJYWZnbmJmZ25nKmZ kSTF8aGdxfGhnSXs4KmdnKmZkSShlcTAJf2x7YHNmZ2cnbH1JK2B7bUltYG9oamcqZmRJIGh iSWFmZ25iZmduZypmZEkwZnxkbElhZmduYmZnbmcqZmRJPWZkSX5oYGFoZ25nKmZkZyFiSTx ta0l/bHtgc2ZnZydsfUk6YHpJYWZnbmJmZ25nKmZkST1oa2tsSW1gb2hqZypmZEkrfHphSX9 se2BzZmdnJ2x9SSR8YmhJfmtkI2h5aGdnKmZnI3lJPWZicGZJfmtkI2h5aGdnKmZnI3lJMGQ +SXFgZ2F8aGdsfWcqZmRJPWhnbmdsSXs4KmdnKmZkSTBtZmJscEl7OCpnZypmZEk6YmBnbmJ mZ25JezgqZ2cqZmRJLWZ+Z2VmaG17OCpnSXs4KmdnKmZkSSFoeXlwa2ZweDkxCXs4KmdnKmZ kSTpsanx7YH1wSXpgZ2ZrZ2x9ZypmZEk6bGp8YGdvZnsJemBnZmtnbH1nKmZkSSBkOmxoe2p hSXpgZ2ZrZ2x9ZypmZEkxYGdwaGZxODowCXs4KmdnKmZkST5zbm1JezgqZ2cqZmRJLX5oSX5 zeX19ZzNjZypnST5+cXNJfnN5fX1nM2NnKmdJIWxrSX5zeX19ZzNjZypnSTloZ2N8Z0l+c3l 9fWczY2cqZ0kxfHBgYXxgSX5zeX19ZzNjZypnSTNhbGduYnpJfnN5fX1nM2NnKmdJMGhnbnF +SX5zeX19ZzNjZypnSTF8b2RJfnN5fX1nM2NnKmdJKnxwSX5zeX19ZzNjZypnSSx7bHtJfnN 5fX1nM2NnKmdJKnlgakl+c3l9fWczY2cqZ0k6an5tSX5zeX19ZzNjZypnSTNzY2tJfnN5fX1 nM2NnKmdJPmN6bEl+c3l9fWczY2cqZ0kjaG1sSX5zeX19ZzNjZypnSTpsZ25JfnN5fX1nM2N nKmdJMHlhSX5zeX19ZzNjZypnSSdqbEl+c3l9fWczY2cqZ0kxfHpwSX5zeX19ZzNjZypnSS9 sZ25jYGhnSX5zeX19ZzNjZypnSSVgY2BncGxJfnN5fX1nM2NnKmdJKnpzSX5zeX19ZzNjZyp nSTN4ZUl+c3l9fWczY2cqZ0kxfHNiSX5zeX19ZzNjZypnSSFsemVJfnN5fX1nM2NnKmdJOWh nZGhnbkl+c3l9fWczY2cqZ0kufGBJfnN5fX1nM2NnKmdJPmhhSX5zeX19ZzNjZypnST5jemF JfnN5fX1nM2NnKmdJMGhmfEl+c3l9fWczY2cqZ0k+c2N6SX5zeX19ZzNjZypnSS56bXhJfnN 5fX1nM2NnKmdJPXFJfnN5fX1nM2NnKmdJLWZnbnh7SX5zeX19ZzNjZypnSSpoZnBoZ25JfnN 5fX1nM2NnKmdJI2pwcEl+c3l9fWczY2cqZ0k5YWhsSX5zeX19ZzNjZypnSTlsZ25wakl+c3l 9fWczY2cqZ0kufGZwfGxlYEl+c3l9fWczY2cqZ0k+ZWdhSX5zeX19ZzNjZypnSSVsenxJfnN 5fX1nM2NnKmdJKnpJfnN5fX1nM2NnKmdJMW5+SX5zeX19ZzNjZypnST5sZ255OTsJfnN5fX1 nM2NnKmdJJmt4SX5zeX19ZzNjZypnSSphY3hJfnN5fX1nM2NnKmdJPnx7b0l+c3l9fWczY2c qZ0ksb25JfnN5fX1nM2NnKmdJMGhmSX5zeX19ZzNjZypnSTlwYUl+c3l9fWczY2cqZ0kzYWx nbmphfEl+c3l9fWczY2cqZ0kwaGduen1JfnN5fX1nM2NnKmdJK2plSX5zeX19ZzNjZypnST5 4fnhJfnN5fX1nM2NnKmdJPWBoZ3hgZ0l+c3l9fWczY2cqZ0kuc2NJfnN5fX1nM2NnKmdJLnx 6ZEl+c3l9fWczY2cqZ0k+c2FiSX5zeX19ZzNjZypnSSFvcH1JfnN5fX1nM2NnKmdJIXxjYGh nZWBJfnN5fX1nM2NnKmdJKnNkSX5zeX19ZzNjZypnSTNxb2hJfnN5fX1nM2NnKmdJKnx7bEl +c3l9fWczY2cqZ0kwfG1mZ25JfnN5fX1nM2NnKmdJMGBhbEl+c3l9fWczY2cqZ0k+enhoSX5 zeX19ZzNjZypnSTNhbGdufkl+c3l9fWczY2cqZ0kxfG5sZ3phYEl+c3l9fWczY2cqZ0k+YGp mSX5zeX19ZzNjZypnSShnamxJfnN5fX1nM2NnKmdJKnNwZkl+c3l9fWczY2cqZ0krZnBoSX5 zeX19ZzNjZypnSSVge2ZJfnN5fX1nM2NnKmdJMXN+fEl+c3l9fWczY2cqZ0k9e31JfnN5fX1 nM2NnKmdJIWRuSX5zeX19ZzNjZypnSTNhYW1JfnN5fX1nM2NnKmdJMHBja0l+c3l9fWczY2c qZ0kjYGdhfEl+c3l9fWczY2cqZ0ksemxwSX5zeX19ZzNjZypnSSJscGBJfnN5fX1nM2NnKmd JJXtrSX5zeX19ZzNjZypnSS9tcGdJfnN5fX1nM2NnKmdJJWBnfHFJfnN5fX1nM2NnKmdJI2B nZHhJfnN5fX1nM2NnKmdJKntwSX5zeX19ZzNjZypnSSVzbkl+c3l9fWczY2cqZ0kqamxkSX5 zeX19ZzNjZypnSSpxfUl+c3l9fWczY2cqZ0kkaH5sZ29sYEl+c3l9fWczY2cqZ0kuaGZxYGd vfEl+c3l9fWczY2cqZ0k+cXtJfnN5fX1nM2NnKmdJJHtxfEl+c3l9fWczY2cqZ0kjfnFJfnN 5fX1nM2NnKmdJO3NjSX5zeX19ZzNjZypnSSpqSX5zeX19ZzNjZypnSThjfGdJfnN5fX1nM2N nKmdJPX1oZUl+c3l9fWczY2cqZ0klZmdufDg+CX5zeX19ZzNjZypnSSVhfUl+c3l9fWczY2c qZ0klemV6SX5zeX19ZzNjZypnSSVgcGFJfnN5fX1nM2NnKmdJPn5kSX5zeX19ZzNjZypnSSF qeXxJfnN5fX1nM2NnKmdJPW9uSX5zeX19ZzNjZypnSSNqfUl+c3l9fWczY2cqZ0klYGdhaGZ JfnN5fX1nM2NnKmdJM3htSX5zeX19ZzNjZypnSTBsZWhnbkl+c3l9fWczY2cqZ0k6fm9vSX5 zeX19ZzNjZypnSTBwbm5JfnN5fX1nM2NnKmdJKG5hSX5zeX19ZzNjZypnSSpnY0l+c3l9fWc zY2cqZ0khbWNJfnN5fX1nM2NnKmdJOnx5eWZ7fUluaGRsaGtqZypmZEkkfXNzc2N6SXs4Kmd nKmZkSTF8bWxnbnh8Z0l+c3g/OicqZmRJOnxncHxjYGhnbkl7OCpnZypmZEkxZGVgSX5zeD8 6JypmZEkwYHphZnxJfnN5fX1nM2NnKmdJKmpjcElieDsnKmZkZypnSTphYXBgSXFgZ2F8aGd sfWcqZmRJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJMxVZe2Zue2hkaQ9gZWx6VUBnfWx7Z2x 9aQxxeWVme2x7VUpmZ2dsan1gZmdpHmBzaHttVUBKXkZGS0xnLnBxSScrY3FJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCQkJCQkJCSR5cQknLHFsSSc6antJJzlgb0knK2h9SQkJCQkJCQkJCQk JCSc9cX1JJyF9ZEknIX1kZUknPmhrSScoenlJJy1makknO31vSScxZXpJJyN5bkknKnl5SSc qSSc5aHpJJyR5bkknJHlsbkknK2hiSSckeXoJJzltb0kJGmZvfX5oe2xVRGBqe2Z6Zm99VV5 gZ21mfnpVSnx7e2xnfV9se3pgZmdVSQh5eWkZaH1hekkbfGdJG3xnRmdqbEkacHp9bGRVSnx 7e2xnfUpmZ317ZmVabH1VWmx7f2BqbHpJGmZvfX5oe2xVRGBqe2Z6Zm99VV5IS1VeSEt9FV5 oa2kPYGVsaQdoZGxJG3xnWmx7f2BqbHpJAGd9bHtnbH1pGmx9fWBnbnpVSmhqYWxVWWh9YXp JCQkJCQkJCQFgZQkBbGVlZmUJG2xzCQ9+cwkcZ21sZWB/bHtoa2VsaSRoYGVkJCssOmsJG2x 9fHtnbG1pJGhgZWQkKyw6awkJCQkJKGksOmksOmkuaGRsSShpLDppLDppPWZmZUkoaSw6aSw 6aT5sa3pgfWxJKGksOmksOmk5aH1qYUksOmk7bGRmf2hlaT1mZmV6SQkJCQkJCQknbH5JL3x nZ3BJJ2BqbEkhfGRmfHtJLHFqYH1sSS5mZm1JOWZ+b3xlSR5gZ1FZSQBMaT8nOQkeejsnDGV ibHtnaQkeejsnAmVsc2cMSQkhZn5pKHtsaTBmfEklbH1uOmkrbGkve2BsZ216SS1oe2VgZ25 JOmZpKmZmZWkoaS9laHphZSxnY2ZwaSB9STBmfHtpOWh6en5me21JIWZnbHBJOmZkbGk4fGx 6fWBmZ3pJOWVsaHpsaT17cGkobmhgZ0k+bGVqZmRsaT1maSRwaSFmZGx9Zn5nST1hbGkOaHt tbGdpJm9pDG1sZ0kgZ317Zm18an1gZmdpJmdpCE1aRUkkbGx9YGduaSdmfWBqbEk4fGx6fWB mZ2doYHtsSSpmZ257aH18ZWh9YGZnekk6ZnpoCSNoeWhnbHpsaS5ge2VpH1ppOWVocGtmcEk lZmZiZSRwaStsaHx9YG98ZWkuYHtlaS97YGxnbUksaG5se2k9Zmk6bGxpMGZ8STp5YGpsaS5 ge2V6bik/ZmpoZWkqZmdqbHt9SSNoeWhnbHpsaSVoenpuKTpscXBpOWBqfXx7bHpJCQkJGnB kaGd9bGpJBGpob2xsSQ9kGmxqfHtsSRpmeWFmekkde2xnbWRgantmSQJoenlse3picEkJCQk Pe2ZkcykJHWZzKQkafGtjbGp9cykJCQkdYWxpL2ZlZWZ+YGduaSRoYGVpKmhnbj1pK2xpOmx nfWk9ZmksOnMJHWFsaSh9fWhqYWRsZ31JHWFsaS9gZWxJKSB6aT1hbGkme2BuYGdoZWkkaGB lSSkuYH9saTBmfGk9YWxpLDpJKSB6aShpLDppLWhnbmx7Znx6aT9ge3x6aT1haH1pLDpJKmh naSBnb2xqfWkmZ2keYGdwMSYEbGY7OTk5JhFZZwk6eXtsaG1pPWF7ZnxuYWksZGhgZWcJP2x 7cGkJOnlsamBoZWkJIX19eXMmJgk+fn5nCScqZmRJD2Z7aSRme2xpIGdvZntkaH1gZmdlOWV saHpsaT9gemB9aQkdYWB6aSB6aQkAaSw6aTBmfGk+ZnxlbWksOmkgfWcJLGdjZnBJJWBibEk +YHphSSFmeWxJLHF5bGp9SQkKYXtgen1kaHpJB2x+aTBsaHtJGmhgZ31pH2hlbGd9YGdsbjp pDWhwSQhlZWFoZWVmfmRoekkIeXtgZWkPZmZlem4pDWhwSQVobXBpDWhwSQh6enxkeX1gZmd JCmhnbWVsZGh6SQhlZWkaZnxlem4NaHBJDHlgeWFoZ3BJCQkJCQFoeXlwaQkBaH9saShpCQk 1K3t3BAMJBAMJOWZ6fWRoen1se0kJCR5gZ2JJCQBkaG5sWWh9YUkEQERMZB9se3pgZmdzKTg nOQQDCmZnfWxnfWQdcHlscykkfGV9YHloe31mKGV9bHtnaH1gf2xyBAMAK2Z8Z21oe3B0CQp mZ31sZ31kHXB5bHMpPWxxfWYhfWRlcgQDCmZnfWxnfWQde2hnem9se2QMZ2pmbWBnbnMpOHx mfWxtZDl7YGd9aGtlbEQDBAM1AV1ERXc1AUxITXc1JgFMSE13NQtGTVB3LDpEAzUPRkdddwk JNSYPRkdddzUmC0ZNUHc1JgFdREV3CQkJCmZnfWxnfWQdcHlscyksOnIEAwAnaGRsdCw6RAM KZmd9bGd9ZB17aGd6b2x7ZAxnamZtYGducykraHpsfz0EAwpmZ31sZ31kAE1zKTUsOncJCQk JCQkJCQkJKHxtYGZmMWQ+aH9JKHxtYGZmMWQkYG1gSSh5eWVgamh9YGZnZiZqfWx9ZDp9e2x oZEkJCQkJCQkJCQQDNSBve2hkbGk6e2p0Og1qYG1zLDppIWxgbmF9dDoNeSk+YG19YXQ6DXk 3BAM1JiBve2hkbHcJHWFgemkuaGRsaSB6aSRwaS9ge3p9aT5me2JnNSt7dwQDEGZ8bjtsaT1 hbGkvYHt6fWk5ZWhwbHtnCQZASlhJGXtmbntoZE9gZWx6TWB7SQkJCTpkfXlnCRZIX1l6Owk WSF9ZSkpJB0ZNejsJB1laWl9KSQdbTFpYejsJB1pKQUxNejsJB1pKQUxNR11JB1pZRVxOQEd JB0hfSQdIX0hZWl9KSQdIX0hZXno7CQdIX0VcejsJB0hfW1xHW0kHSF9eejsJFkhfWURJCEV MW11aX0pJCERGR0kIX1l6OwkIX1lKSkkIX1lESQd6OxpKSEdeSQdIX15HXUkIR11AX0BbSQh fWVxZTUkIX05KXVtFSQhfXkBHcDwJGkpIR3o7CR9aQV5AR3o7CQ9kGl1GWV5JD2QZW0ZdcDw JCEpCXkBHejsJH0xdXVtIUEkfTF1wPAkaXkxMWXA8CRlKSl5AR3AxCQBGREZHcDEJCF9ZXUp JCF9MejsJCF9KRkdaRkVJD1lkHkBHSQ1fWXA8CQ9kCE5HXXA8CQpFSF5wPAkHX0pwPAkaSkh HSR9AW1xaSQVGSkJNRl5Hezk5OQkHZnt9ZmdJBGpob2xsSQhnfWB/YHtJHUhaQkROW0kJCQk JCQkJCQkJCQkJCQkJCQkIR11AZB9AW2cNSF1JCkFCRUBaXWcNSF1JCkFCRUBaXWcEWkkKQUJ FQFpdZwpZWkkKQUJFQFpdZx1IX0kAX0tnB11TSRpESFtdSkFCZwRaSRpESFtdSkFCZwpZWkk IX05YXWcNSF1JCE5cSFtNZw1IXUkJCQkJCQkaYWV+aHlgZy1lZUkCbHtnbGV6OyctZWVJJ2x 9aHlgejsnLWVlSTpvamctZWVJCQkJCRpge2poZEkHYGRtaEkKZm1sW2xtSR5YQkREejE+MQk OW0BMT3oxPjEJD3xnaQVmf2BnbmkKe2BkYGdoZUkHZnt9ZmdJBGpob2xsSQhnfWB/YHtJCH9 qZmd6ZmVJD2QaXUZZXkkPZBpsanx7bEkaZnlhZnpJP2B7fHpJCF9ZaQRmZ2B9ZntJCF9ZaRx 5bWh9bHpJAGdmanxlaH1sQF1JGUpkKmBlZWBnSRpwZGhnfWxqSR17bGdtaQRgantmSQ9kGVt GXUkpB0ZNejspCQkJG2xuYHp9bHtabHt/YGpsWXtmamx6ekkHbH1aYWh7bEhtbUkaQU1sZWx 9bEJscEhJGm9qQHpPYGVsWXtmfWxqfWxtSQdsfVphaHtsTmx9QGdvZkkHbH1IeWBLfG9vbHt Pe2xsSQkJCQkMUVlFRltMW0kKREROW0kkemBkZ0kgan5qZmdnST5gZ3NgeUkJCQkJGXtmbnt oZEksOmk1LDp3CQhLSk1MT05BQENCRURHRllYW1pdXF9eUVBTaGtqbWxvbmFgY2JlZGdmeXh 7en18f35xcHN5ODs6PTw/PjEwIiYJOmx9fHlJIGd6fWhlZUktbGRmSTpnZmZ5cEk5YGpoanx JImB9fXBJOWVocEk7ZmpiSQkJCQkJCQkbaHtoEw4JBtm6SQkECQkJCQkJCQkJJztoe0kJPmB nYGdsfWctZWVJAGd9bHtnbH1ObH1KZmdnbGp9bG1afWh9bEkJCQ1ge2xqfWZ7cEktZWVqaGp hbEkJGmxNbGt8bll7YH9gZWxubEkabF1qa1l7YH9gZWxubEkJCQkJCQkJCT5rZCNoeWhnZyp mZyN5ST9se2BzZmdnJ2x9SSh7eHxge2xtZyx6SS1gb2hqZypmZEkJGmZvfX5oe2xVRGBqe2Z 6Zm99VUBnfWx7Z2x9aQhqamZ8Z31pBGhnaG5se1VIampmfGd9elVJGkRdWWkabHt/bHtJGkR dWWkMZGhgZWkIbW17bHp6SQkeZntkaQJlbHNnDGkgZGR8Z2B9cEkJAmVsc2cMaSB6aT1hbGk kZnp9aSpmZGRmZ2k+ZntlbWQ+YG1saTp5e2xobWBnbmk+ZntkZwB9bjppP2x7cGktaGdubHt mfHppK3BpKmZ7e3x5fWBnbmkwZnx7aS9gZWx6ZzUre3cEAwtsamh8emxpJm9pIH16aT9se3B pOmRoe31pOn1saGV9YWkoZ21pKGd9YGQoZ31gZD9ge3x6aT1samFnYGplJGZ6fWkqZmRkZmd pCF9pOmZvfX5oe2xpKmhnbj1pLWx9bGp9aSZ7aSplbGhnaSB9ZzUre3cEAx5saS1sf2xlZnl sbWk9YWB6aS97bGxpIGRkfGdgfXBpPWZmZWk9ZmktbG9saH1pPWFsaSRoZWBqYGZ8emk/YHt 8emc1K3t3BAMQZnxpJmdlcGknbGxtaT1maTt8Z2k9YWB6aT1mZmVpJmdqbGUoZ21pPWFsZ2k CZWxzaT5gZWVpJ2x/bHtpKmZkbGkgZ31maTBmfHtpGUpnNSt7dwQDB0ZdTHMpC2xqaHx6bGk 9YWB6aT1mZmVpKGp9emkoemkoaS9oYmxpAmVsc2k9ZmkvZmZlaT1hbGk7bGhlaT5me2RlOmZ kbGkIX2kkZmdgfWZ7aSRocGtsaSp7cGk+YWxnaTBmfGk7fGdpIH1nNSt7dwQDAG9pOmZlAG5 nZntsaT1hbGk+aHtnYGduZShnbWk6bGVsan1pLipmZ31gZ3xsbic1K3t3BAMAb2kwZnxpIWh /bGkoZ3BpOHxsen1gZmdlOWVsaHpsaTUoaSF7bG90Og1kaGBlfWZzLDp3JGhgZWk9ZmkkbHU mKHcnCQkJCQkJCQkEAx5gZ3o7KQJlbHNpH3snOTgpLykeYGd6OykPZntmfHFpH3gnOQQDCmZ 5cHtgbmF9aTs5OTslJGhtbGkgZ2kIemBoRAMIa2Z8fWkCZWxzaR97Jzk4MwQDADglBGhgZ2k kYHp6YGZnaSB6aT1maTtsZWxoemxpPWFsaSdsfmkraGtwaRlMaT9ge3x6ZR5gZ3o7KQ9me2Z 8cUQDADslB2ZpOmBuZ2BvYGpoZ31pKmFoZ25sZwdmaSt8bmkvYHFsbWcHZmkoZ3BpOWhwZWZ obWcEAwhrZnx9aR5gZ3o7KQ9me2Z8cWkhOWVzaSJsbHlpPWFsaSdoZGxlPWFoZ3FgBAMAOCU PfGVlaSpmZHlofWBrZWxpHmBnejspGUxpP2B7fHppJmdpHmBncBFmOwJmB11mEVlEAwA7JR5 gfWFpP2x7cGkgZ31se2x6fWBnbmkvbGh9fHtsZwphbGpiaSB9aAQDADolB2ZpKGdwaTlocGV maG1nB2ZpKGdwaSZ5fWBkYHNofWBmZ0QDAD0lB2Z9aSt8bmkve2xsZStsamh8emxpJm9pKGk hfHt7cGk+ZntiZwdmaSRme2xpPWFoZ2k9YXtsbGk+bGxiemkve2ZkaSFof2Bnbmk6fGphaSB tbGhpPWZpKGpqZmR5ZWB6YWBnbmkqZm1gZ25pKGdtaT1sen1gZ25EAwkAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAgAAAEgAAIADAAAAeAAAgAUAAAD4AACABgAAAJABAIAJAAAA +AEAgA4AAAAwAgCAEAAAAFgCAIAAAAAAAAAAAAQAAAAAAAQA0gAAAHACAIDTAAAAiAIAgNQA AACgAgCA1QAAALgCAIAAAAAAAAAAAAQAAAAAAA4AAQAAANACAIACAAAA6AIAgAMAAAAAAwCA BAAAABgDAIAFAAAAMAMAgAYAAABIAwCABwAAAGADAIAIAAAAeAMAgAkAAACQAwCACgAAAKgD AIALAAAAwAMAgAwAAADYAwCADQAAAPADAIAOAAAACAQAgAAAAAAAAAAABAAAAAAAEQBkAAAA IAQAgGUAAAA4BACAZgAAAFAEAIBnAAAAaAQAgGgAAACABACAaQAAAJgEAIBqAAAAsAQAgGsA AADIBACAbAAAAOAEAIBtAAAA+AQAgG4AAAAQBQCAbwAAACgFAIBwAAAAQAUAgHEAAABYBQCA cgAAAHAFAIBzAAAAiAUAgHQAAACgBQCAAAAAAAAAAAAEAAAAAAALACAAAAC4BQCAIQAAANAF AIAjAAAA6AUAgCYAAAAABgCALAAAABgGAIAtAAAAMAYAgC4AAABIBgCALwAAAGAGAIAwAAAA eAYAgDIAAACQBgCAMwAAAKgGAIAAAAAAAAAAAAQAAAAAAAUA0AcAAMAGAIDRBwAA2AYAgNIH AADwBgCA0wcAAAgHAIDUBwAAIAcAgAAAAAAAAAAABAAAAAAAAwDIAAAAOAcAgMkAAABQBwCA ygAAAGgHAIAAAAAAAAAAAAQAAAAAAAEAAQAAAIAHAIAAAAAAAAAAAAQAAAAAAAEABAgAAJgH AAAAAAAAAAAAAAQAAAAAAAEABAgAAKgHAAAAAAAAAAAAAAQAAAAAAAEABAgAALgHAAAAAAAA AAAAAAQAAAAAAAEABAgAAMgHAAAAAAAAAAAAAAQAAAAAAAEABAgAANgHAAAAAAAAAAAAAAQA AAAAAAEABAgAAOgHAAAAAAAAAAAAAAQAAAAAAAEABAgAAPgHAAAAAAAAAAAAAAQAAAAAAAEA BAgAAAgIAAAAAAAAAAAAAAQAAAAAAAEABAgAABgIAAAAAAAAAAAAAAQAAAAAAAEABAgAACgI AAAAAAAAAAAAAAQAAAAAAAEABAgAADgIAAAAAAAAAAAAAAQAAAAAAAEABAgAAEgIAAAAAAAA AAAAAAQAAAAAAAEABAgAAFgIAAAAAAAAAAAAAAQAAAAAAAEABAgAAGgIAAAAAAAAAAAAAAQA AAAAAAEABAgAAHgIAAAAAAAAAAAAAAQAAAAAAAEABAgAAIgIAAAAAAAAAAAAAAQAAAAAAAEA BAgAAJgIAAAAAAAAAAAAAAQAAAAAAAEABAgAAKgIAAAAAAAAAAAAAAQAAAAAAAEABAgAALgI AAAAAAAAAAAAAAQAAAAAAAEABAgAAMgIAAAAAAAAAAAAAAQAAAAAAAEABAgAANgIAAAAAAAA AAAAAAQAAAAAAAEABAgAAOgIAAAAAAAAAAAAAAQAAAAAAAEABAgAAPgIAAAAAAAAAAAAAAQA AAAAAAEABAgAAAgJAAAAAAAAAAAAAAQAAAAAAAEABAgAABgJAAAAAAAAAAAAAAQAAAAAAAEA BAgAACgJAAAAAAAAAAAAAAQAAAAAAAEABAgAADgJAAAAAAAAAAAAAAQAAAAAAAEABAgAAEgJ AAAAAAAAAAAAAAQAAAAAAAEABAgAAFgJAAAAAAAAAAAAAAQAAAAAAAEABAgAAGgJAAAAAAAA AAAAAAQAAAAAAAEABAgAAHgJAAAAAAAAAAAAAAQAAAAAAAEABAgAAIgJAAAAAAAAAAAAAAQA AAAAAAEABAgAAJgJAAAAAAAAAAAAAAQAAAAAAAEABAgAAKgJAAAAAAAAAAAAAAQAAAAAAAEA BAgAALgJAAAAAAAAAAAAAAQAAAAAAAEABAgAAMgJAAAAAAAAAAAAAAQAAAAAAAEABAgAANgJ AAAAAAAAAAAAAAQAAAAAAAEABAgAAOgJAAAAAAAAAAAAAAQAAAAAAAEABAgAAPgJAAAAAAAA AAAAAAQAAAAAAAEABAgAAAgKAAAAAAAAAAAAAAQAAAAAAAEABAgAABgKAAAAAAAAAAAAAAQA AAAAAAEABAgAACgKAAAAAAAAAAAAAAQAAAAAAAEABAgAADgKAAAAAAAAAAAAAAQAAAAAAAEA BAgAAEgKAAAAAAAAAAAAAAQAAAAAAAEABAgAAFgKAAAAAAAAAAAAAAQAAAAAAAEABAgAAGgK AAAAAAAAAAAAAAQAAAAAAAEABAgAAHgKAAAAAAAAAAAAAAQAAAAAAAEABAgAAIgKAAAAAAAA AAAAAAQAAAAAAAEABAgAAJgKAAAAAAAAAAAAAAQAAAAAAAEABAgAAKgKAAAAAAAAAAAAAAQA AAAAAAEABAgAALgKAAAAAAAAAAAAAAQAAAAAAAEABAgAAMgKAAAAAAAAAAAAAAQAAAAAAAEA BAgAANgKAAAAAAAAAAAAAAQAAAAAAAEABAgAAOgKAAAAAAAAAAAAAAQAAAAAAAEABAgAAPgK AAAIWwkAsJYAAOQEAAAAAAAAKPIJALCWAADkBAAAAAAAANiICgDeAgAA5AQAAAAAAAC4iwoA 3gIAAOQEAAAAAAAAmI4KAOgCAADkBAAAAAAAAICRCgAoAQAA5AQAAAAAAACokgoAaAYAAOQE AAAAAAAAEJkKAKgIAADkBAAAAAAAALihCgCoDgAA5AQAAAAAAABgsAoAaAUAAOQEAAAAAAAA yLUKAOgCAADkBAAAAAAAALC4CgCoCAAA5AQAAAAAAABYwQoAqA4AAOQEAAAAAAAAANAKACgB AADkBAAAAAAAACjRCgBoBQAA5AQAAAAAAACQ1goAaAYAAOQEAAAAAAAA+NwKAOgCAADkBAAA AAAAAODfCgAoAQAA5AQAAAAAAAAI4QoAFgEAAOQEAAAAAAAAIOIKADACAADkBAAAAAAAAFDk CgB6AQAA5AQAAAAAAADM5QoAVAMAAOQEAAAAAAAAIOkKADgCAADkBAAAAAAAAFjrCgBOAQAA 5AQAAAAAAACo7AoAwAIAAOQEAAAAAAAAaO8KAFgBAADkBAAAAAAAAMDwCgDkAAAA5AQAAAAA AACk8QoAcAAAAOQEAAAAAAAAFPIKACYCAADkBAAAAAAAADz0CgBGAAAA5AQAAAAAAACE9AoA ogEAAOQEAAAAAAAAKPYKAHwBAADkBAAAAAAAAKT3CgAaAQAA5AQAAAAAAADA+AoAXAIAAOQE AAAAAAAAHPsKAEYAAADkBAAAAAAAAGT7CgCWAgAA5AQAAAAAAAD8/QoAQgEAAOQEAAAAAAAA QP8KAHQBAADkBAAAAAAAALQACwBAAAAA5AQAAAAAAAD0AAsAfgAAAOQEAAAAAAAAdAELAFAE AADkBAAAAAAAAMQFCwA4AQAA5AQAAAAAAAD8BgsAQgAAAOQEAAAAAAAAQAcLAKADAADkBAAA AAAAAOAKCwByAAAA5AQAAAAAAABUCwsASgIAAOQEAAAAAAAAoA0LAGAAAADkBAAAAAAAAAAO CwAwAAAA5AQAAAAAAAAwDgsAEAAAAOQEAAAAAAAAQA4LABAAAADkBAAAAAAAAFAOCwBQAAAA 5AQAAAAAAACgDgsAWgAAAOQEAAAAAAAA/A4LAFoAAADkBAAAAAAAAFgPCwAiAAAA5AQAAAAA AAB8DwsAeAMAAOQEAAAAAAAAKAAAAKQAAADKAQAAAQAEAAAAAABIlgAAEgsAABILAAAQAAAA EAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAAAP//AP8A AAD/AP8A//8AAP///wBERERERERERERERERERERERERERERERERERERERERERERERERERERE REREREREREREREREREREREREREREREREREREREREREREREREREREREREAABEREREREZmZmZE REREREREREREREREZmZmZERERERERERERERERERERERERERERERERERERERERERERERERERE REREREREREREREREREREREREAADMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMAABERERE RGZmZmREREREREREREREREREZmZmZERERERERERERERERERERERERERERERERERERERERERE REREREREREREREREREREREREREREREREAABERERERGZmZmRERERERERERERERERGZmZmZERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE AADMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMAABERERERmZmZmRERERERERERERERERG ZmZmZERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE REREREREAABERERERGZmZmRERERERERERERERERGZmZmRERERERERERERERERERERERERERE REREREREREREREREREREREREREREREREREREREREREREREREAADMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMAABERERERmZmZmRERERERERERERERERmZmZmRERERERERERERERERERE REREREREREREREREREREREREREREREREREREREREREREREREREREREREAABERERERmZmZkRE REREREREREREREZmZmZkRERERERERERERERERERERERERERERERERERERERERERERERERERE REREREREREREREREREREREREAADMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMAABERERE ZmZmZkREREREREREREREREZmZmZkRERERERERERERERERERERERERERERERERERERERERERE REREREREREREREREREREREREREREREREAABEREREZmZmZERERERERERERERERGZmZmZERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERETVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA wAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABpYlfZLQM5ii0DOYotAzmKrh83iigDOYp7HCqKLAM5ii0DOYofATmK UmljaC0DOYoAAAAAAAAAAAAAAAAAAAAAUEUAAEwBBAB12jg3AAAAAAAAAADgAA4jCwEFDAAg CAAA8AAAAAAAAJjPAAAAEAAAAHAIAAAA6H8AEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAIAkA ABAAAKIUCgACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAsDYDACUkAADAGAgAtAAAAACg CAAIBgAAAAAAAAAAAAAAAAAAAAAAAACwCAC0ZwAAwBcIABwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAFgCAABsAAAAABAAAAgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAudGV4dAAAAJAeCAAAEAAAACAIAAAgAAAAAAAAAAAAAAAAAAAgAABgLmRhdGEAAAAMYQAA ADAIAABgAAAAQAgAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAACAYAAACgCAAAEAAAAKAIAAAA AAAAAAAAAAAAAEAAAEAucmVsb2MAALRnAAAAsAgAAHAAAACwCAAAAAAAAAAAAAAAAABAAABC dNo4NzAAAABy2jg3OgAAADh0WjVFAAAAIK8yN08AAABy2jg3XAAAAAAAAAAAAAAAb2xlMzIu ZGxsAFVTRVIzMi5kbGwAR0RJMzIuZGxsAEtFUk5FTDMyLmRsbABBRFZBUEkzMi5kbGwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAD== --SE53RcxT558s0d816684GdCm55YyM9 --SE53RcxT558s0d816684GdCm55YyM9 Content-Type: application/octet-stream; name=C018005005[1].jpg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoM DAsKCwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsN FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAAR CAAUADIDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD7Z8S/G/QPD/iPX9MFxBcweE9NOs+LbxZi RolmYZZId0aK7yTSCJmWJQMRo7syloUn8wtf22tAt/COqeKtY06Cw0DS4dE1bUJbTUDdz2Ol auXWxlmiSIFbpSI3mtRuCRSh45ZztjbhfCXwCvfiT4c/aU8IeL7KBvEmu/EFdX8rVblll1PQ 4pra402F7iMtLHayJb3FvHIu7yD54VC8Tx0fEf8AZrvfFPhzWfhzHfQap4s+J3im28S/EC/a ZpZdH0NJjJHb210Y87Yjbx21qJkPmH7S6RRosog9ZynujPQ+zaKKK3EFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAf/9=9 --SE53RcxT558s0d816684GdCm55YyM9-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 1 17:38:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA21cr29015745; Fri, 1 Nov 2002 17:38:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA21crQt015744; Fri, 1 Nov 2002 17:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA21co29015737 for ; Fri, 1 Nov 2002 17:38:50 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA21cxMq026096 for ; Fri, 1 Nov 2002 17:38:59 -0800 (PST) Received: from laptop2.kurtis.pp.se (host-n23-135.homerun.telia.com [212.181.250.135]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA24792 for ; Fri, 1 Nov 2002 17:38:52 -0800 (PST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gA21cqwc001363; Sat, 2 Nov 2002 02:38:53 +0100 (CET) Date: Sat, 2 Nov 2002 02:38:51 +0100 Subject: Re: Limiting the Use of Site-Local Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'Pekka Savola'" , Margaret Wasserman , Richard Draves , ipng@sunroof.eng.sun.com To: "Hesham Soliman (EAB)" From: Kurt Erik Lindqvist In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C54@Esealnt861.al.sw.ericsson.se> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => Pekka, if all the ISP's between the client in your > picture and the detination are stupid enough > to not ingress filter the SL source, AND the end site is > equally as incompetent, then yes, your client will > get there. He will never get anything back though. > > I'm sorry but I don't see this as a realistic or serious > issue. > Then I think you will be surprised at how often this is used to today in attacks... Not getting data back is not always an issue. Inserting data can be as bad. - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 1 17:52:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA21qw29015840; Fri, 1 Nov 2002 17:52:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA21qvkP015839; Fri, 1 Nov 2002 17:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA21qs29015832 for ; Fri, 1 Nov 2002 17:52:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA21r3bB023430 for ; Fri, 1 Nov 2002 17:53:03 -0800 (PST) Received: from laptop2.kurtis.pp.se (host-n23-135.homerun.telia.com [212.181.250.135]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA01839 for ; Fri, 1 Nov 2002 18:52:55 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gA21qowc001389; Sat, 2 Nov 2002 02:52:51 +0100 (CET) Date: Sat, 2 Nov 2002 02:52:50 +0100 Subject: Re: Limiting the Use of Site-Local Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Bound, Jim" , "Margaret Wasserman" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <2B81403386729140A3A899A8B39B04640BD298@server2000> Message-Id: X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA21qt29015833 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This list is generating email enough as it is. Could one of the chairs please ask the political / personal insult threads to move to a more appropriate mailinglist? - kurtis - On torsdag, okt 31, 2002, at 18:27 Europe/Stockholm, Michel Py wrote: >>> A Monica strike is what Bill Clinton did a while ago: Make a >>> lot of noise launching a bunch of cruise missiles at Saddam >>> to try to get the people's attention away from the fact that >>> he had a young lady under his desk. > >> If your at this upcoming IETF I would love to speak to you >> about this statement in person OK. So lets go offline and >> figure out when we can meet. How about the Hard Rock Café >> one night. I would love to delve deeper into your knowledge >> of the inner workings of one of our Presidents. Of course I >> will share my opinion of your statement but only to you and >> in person just btw us ok. Also I was not a supporter of >> this President but he was the President. Mind if I bring a >> couple of Gulf War Veterans I can probably locate in >> Atlanta? > > Someone tells me that you need to rent a movie called "Wag the dog". > > 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 Fri Nov 1 19:36:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA23ar29016590; Fri, 1 Nov 2002 19:36:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA23aqWH016589; Fri, 1 Nov 2002 19: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA23an29016582 for ; Fri, 1 Nov 2002 19:36:49 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA23awMq018600 for ; Fri, 1 Nov 2002 19:36:58 -0800 (PST) Received: from mail.nosense.org (236.cust1.nsw.dsl.ozemail.com.au [203.103.156.236]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28676 for ; Fri, 1 Nov 2002 19:36:52 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 859BE3B358; Sat, 2 Nov 2002 14:36:49 +1100 (EST) Subject: RE: Limiting the Use of Site-Local From: Mark Smith To: Richard Draves Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 02 Nov 2002 14:36:49 +1100 Message-Id: <1036208210.28225.29.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 2002-11-01 at 04:47, Richard Draves wrote: > > Obviously my last two models don't really fit the idea that > > site-local addressing is to cover a single geographical site. > > Why do you think that site-local addressing is tied to geography in any > way? A few reasons : 1) because of the name ?! the word "site" in common english has geographical connotations. 2) the explanation in the Scoped Addressing Architecture RFCs / drafts : http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-04.txt -- o Site-local scope, for uniquely identifying interfaces within a single site only. A "site" is, by intent, not rigorously defined, but is typically expected to cover a region of topology that belongs to a single organization and is located within a single geographic location, such as an office, an office complex, or a campus. A personal residence may be treated as a site (for example, when the residence obtains Internet access via a public Internet service provider), or as a part of a site (for example, when the residence obtains Internet access via an employer's or school's site). -- While I appreciate this site definition tries to be a bit vague, combining it with the name of "site" really says (to me at least) that site-local addressing has a geographical limit, maybe up to a radius of 3 kilometers or so. Mark. > > Rich > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 1 20:07:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA247w29016697; Fri, 1 Nov 2002 20:07:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA247w3Q016696; Fri, 1 Nov 2002 20:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA247t29016689 for ; Fri, 1 Nov 2002 20:07:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA2483Mq021981 for ; Fri, 1 Nov 2002 20:08:04 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08054 for ; Fri, 1 Nov 2002 21:07:58 -0700 (MST) content-class: urn:content-classes:message Subject: (ipv6) The meaning of "site" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Nov 2002 20:08:04 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3FB@server2000> X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (ipv6) The meaning of "site" Thread-Index: AcKCIkxRmlvedRXWQx+e/h7s9OF+VwAAEkDw From: "Michel Py" To: "Mark Smith" , "Richard Draves" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA247t29016690 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark, >>> Mark Smith wrote >>> Obviously my last two models don't really fit the idea that >>> site-local addressing is to cover a single geographical site. >> Richard Draves wrote: >> Why do you think that site-local addressing is tied to >> geography in any way? > A few reasons : > 1) because of the name ?! the word "site" in common English > has geographical connotations. > 2) the explanation in the Scoped Addressing Architecture > RFCs / drafts : draft-ietf-ipngwg-scoping-arch-04.txt > [snip] While I fully agree with your reading of the RFC and the English connotation of the word "site", it appears to be an unwritten convention that says that a site is a /48. This leads to some semantic confusion in the case of organizations that get a /48 and are spanned over several physical locations that could be separated by hundreds or thousands of miles. When discussing multihoming topics, we refer to a multihomed multi-site organization as an organization that needs to announce different prefixes for each location (which kinda conflicts with the "site = /48" rule for such organizations that get a single /48) opposed to a multihomed single-site organization. In the old days where the usable space for site-locals was a /48, I would have agreed that site-locals would need to include some notion of geography for large organizations that requires more than a /48. However, since today the usable space for site-locals is /10, it is likely that some organizations, even if their address space is multiple /48s, will configure only one site using site-local addresses. I am not lobbying for any definition of "site" (although I would not mind a more precise definition) but it appears to me that the common use for the word has slipped from the way it is written in the part of the RFC you quoted closer to the administrative boundary of an organization. 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 Nov 1 21:37:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA25bt29016933; Fri, 1 Nov 2002 21:37:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA25bsDN016932; Fri, 1 Nov 2002 21:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA25bp29016925 for ; Fri, 1 Nov 2002 21:37:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA25buMq000835 for ; Fri, 1 Nov 2002 21:37:56 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA23715 for ; Fri, 1 Nov 2002 22:37:50 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 20E55380C; Sat, 2 Nov 2002 00:37:50 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 2 Nov 2002 00:37:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Default site-local behavior for routers Date: Sat, 2 Nov 2002 00:37:42 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B659@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Default site-local behavior for routers Thread-Index: AcKA7un7ldQQfcscRVOtqjPSH1OrrwBQZ3yw From: "Bound, Jim" To: "Margaret Wasserman" , "Mark Smith" Cc: "Keith Moore" , X-OriginalArrivalTime: 02 Nov 2002 05:37:43.0027 (UTC) FILETIME=[F716CC30:01C28231] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA25bp29016926 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There will always be us and them forever its natural. The objective is to manage it and stop killing each other. Ipv6 will at least permit that communications so more are involved with the discussion so its possible. But many of us will not be tolerant of those that are not cool any more than we can turn the other cheek when its been slapped. And I believe no one should ever slap without just cause or turn the other cheek if slapped. The word just is far more complex to parse than SLs. Now we just need to manage SLs in that context. I suggest Brian Haberman produce that draft just on doing that. I don't mean manage with MIBs just in case et al. Maybe that will turn our discussion to a technical solution so we don't have to just trust those routing packets. /jim [In matters of style, swim with the currents...in matters of principle, stand like a rock. - Thomas Jefferson] > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Thursday, October 31, 2002 9:59 AM > To: Mark Smith > Cc: Keith Moore; ipng@sunroof.eng.sun.com > Subject: Re: Default site-local behavior for routers > > > > > >As Vint Cerf wrote in a RFC recently, The Internet is for Everyone. > >Once everyone has it (I'd say one of the fundamental > inherent goals of > >IPv6), hopefully the world can become a more tolerant place through > >communication, allowing better understanding of different > peoples view > >points and beliefs. Hopefully the world will become small > enough that > >there will eventually be no "us and them". > > And, hopefully, that's while we're all here -- trying to > build an Internet that can deliver on this vision. > > Mark, thanks for reminding us that we're all really on the same side. > > 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 Nov 1 21:47:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA25lG29017000; Fri, 1 Nov 2002 21:47:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA25lG9s016999; Fri, 1 Nov 2002 21:47:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA25lC29016992 for ; Fri, 1 Nov 2002 21:47:12 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA25lLbB022084 for ; Fri, 1 Nov 2002 21:47:21 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00795 for ; Fri, 1 Nov 2002 21:47:16 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 9232C7504; Sat, 2 Nov 2002 00:47:14 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 2 Nov 2002 00:47:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Limiting the Use of Site-Local Date: Sat, 2 Nov 2002 00:47:07 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9851@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKAhUR1oc8bUNgQQ7mwxHMY+SuU5QAACJKAAAbn5oAAFXRbkAAC88oQAEwMBWA= From: "Bound, Jim" To: "Michel Py" Cc: X-OriginalArrivalTime: 02 Nov 2002 05:47:07.0680 (UTC) FILETIME=[47A60200:01C28233] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA25lD29016993 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please do not send your humor directly to me. I did not respond last time. Next time I will just come find you and not respond to the list and find out if you have a personal problem. As I believing in helping correct those with severe personal problems when I can do that favor for them. Lets keep it to SLs and bits at least to me in the To: list. Sincerely, /jim [In matters of style, swim with the currents...in matters of principle, stand like a rock. - Thomas Jefferson] > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Thursday, October 31, 2002 12:28 PM > To: Bound, Jim; Margaret Wasserman > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Limiting the Use of Site-Local > > > >> A Monica strike is what Bill Clinton did a while ago: Make a > >> lot of noise launching a bunch of cruise missiles at Saddam > >> to try to get the people's attention away from the fact that > >> he had a young lady under his desk. > > > If your at this upcoming IETF I would love to speak to you > about this > > statement in person OK. So lets go offline and figure out > when we can > > meet. How about the Hard Rock Café one night. I would love > to delve > > deeper into your knowledge of the inner workings of one of our > > Presidents. Of course I will share my opinion of your statement but > > only to you and in person just btw us ok. Also I was not a > supporter > > of this President but he was the President. Mind if I bring a > > couple of Gulf War Veterans I can probably locate in > > Atlanta? > > Someone tells me that you need to rent a movie called "Wag the dog". > > 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 Nov 1 21:53:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA25ru29017075; Fri, 1 Nov 2002 21:53:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA25ruDu017074; Fri, 1 Nov 2002 21:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA25rq29017064 for ; Fri, 1 Nov 2002 21:53:52 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA25s1bB022657 for ; Fri, 1 Nov 2002 21:54:01 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA02258 for ; Fri, 1 Nov 2002 21:53:55 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 3A6A533AA; Sat, 2 Nov 2002 00:53:55 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 2 Nov 2002 00:53:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Default site-local behavior for routers Date: Sat, 2 Nov 2002 00:53:47 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9853@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Default site-local behavior for routers Thread-Index: AcKBFE6DLO93QdjCTUmu7JIcAw+aJQBH8c4w From: "Bound, Jim" To: "Jun-ichiro itojun Hagino" , Cc: "Richard Draves" , X-OriginalArrivalTime: 02 Nov 2002 05:53:48.0472 (UTC) FILETIME=[368A0380:01C28234] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA25rr29017065 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > i still think it necessary to: > - limit nodes from joining more than (including) 2 > sites at the same > time. > - document site-border router's behavior in full Does anyone on this list object to Itojuns request? I think it's a good idea and healthy for IPv6. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 1 21:56:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA25u329017104; Fri, 1 Nov 2002 21:56:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA25u2xj017103; Fri, 1 Nov 2002 21:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA25tx29017096 for ; Fri, 1 Nov 2002 21:55:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA25u8bB022914 for ; Fri, 1 Nov 2002 21:56:08 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA01761 for ; Fri, 1 Nov 2002 22:56:02 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 2D0A87637; Sat, 2 Nov 2002 00:56:02 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 2 Nov 2002 00:55:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Default site-local behavior for routers Date: Sat, 2 Nov 2002 00:55:54 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9854@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Default site-local behavior for routers Thread-Index: AcKBHMhqTPWXDXodSh2rWp0NSIOf/gBF6OLg From: "Bound, Jim" To: , "Ralph Droms" , X-OriginalArrivalTime: 02 Nov 2002 05:55:55.0376 (UTC) FILETIME=[822E0700:01C28234] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA25u029017097 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, That's the first thing you said I fully agree with on this thread. I am willing to support this for sure. I don't agree with lots of other things but that's ok. /jim [In matters of style, swim with the currents...in matters of principle, stand like a rock. - Thomas Jefferson] > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Thursday, October 31, 2002 3:26 PM > To: 'Ralph Droms'; ipng@sunroof.eng.sun.com > Subject: RE: Default site-local behavior for routers > > > Ralph Droms wrote: > > ... > > Adjacent nets that both use SLs is an interesting (potentially > > problematic?) architecture - I would be interested in finding > > out about > > deployment experience with that case. > > This is exactly the case that Keith is concerned about. There > is no magic here, in this situation the address space needs > to be coordinated, or a nat is required. Since we are all > trying to avoid nat, the hammer approach is to simply ban SL. > My argument is that it is more pragmatic to simply document > the failure modes. If we can just do that, we will be able to > put the effort into developing a PI approach with better > support for the multi-party app. > > 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 Nov 1 21:58:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA25wZ29017167; Fri, 1 Nov 2002 21:58:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA25wZlX017166; Fri, 1 Nov 2002 21:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA25wW29017155 for ; Fri, 1 Nov 2002 21:58:32 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA25weMq002922 for ; Fri, 1 Nov 2002 21:58:40 -0800 (PST) Received: from mail.nosense.org (236.cust1.nsw.dsl.ozemail.com.au [203.103.156.236]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA23593 for ; Fri, 1 Nov 2002 21:58:34 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id CD36D3B358; Sat, 2 Nov 2002 16:58:32 +1100 (EST) Subject: Re: (ipv6) The meaning of "site" From: Mark Smith To: Michel Py Cc: Richard Draves , ipng@sunroof.eng.sun.com In-Reply-To: <2B81403386729140A3A899A8B39B046405E3FB@server2000> References: <2B81403386729140A3A899A8B39B046405E3FB@server2000> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 02 Nov 2002 16:58:32 +1100 Message-Id: <1036216713.28225.106.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Michel, On Sat, 2002-11-02 at 15:08, Michel Py wrote: > Mark, > > >>> Mark Smith wrote > >>> Obviously my last two models don't really fit the idea that > >>> site-local addressing is to cover a single geographical site. > > >> Richard Draves wrote: > >> Why do you think that site-local addressing is tied to > >> geography in any way? > > > A few reasons : > > 1) because of the name ?! the word "site" in common English > > has geographical connotations. > > 2) the explanation in the Scoped Addressing Architecture > > RFCs / drafts : draft-ietf-ipngwg-scoping-arch-04.txt > > [snip] > > While I fully agree with your reading of the RFC and the English > connotation of the word "site", it appears to be an unwritten convention > that says that a site is a /48. This leads to some semantic confusion in > the case of organizations that get a /48 and are spanned over several > physical locations that could be separated by hundreds or thousands of > miles. Agreed. The 54 bits for subnet allocation in a site-local address tends to strongly suggest that a site-local addressing boundary is not a geographical boundary. The huge number of subnet bits also tends to suggest that within the administrative boundaries of a connected network, only one instance of SL addressing should exist. For simplicity reasons, my IPv6 network would have a single instance of site-local addressing, and if I had to merge it with another IPV6 network using site-local addressing, I would be working towards achieving a single site-local addressing instance again, as part of the process of merging the networks. Merging the two networks won't be hassle free, but at least a number of IPv6's features will make it a lot less of a hassle. However, I believe a lot of non-IPv6 ML subscribed people (eg your typical net admin) would take the name "site-local" (and the associated definition) literally, ending up with a lot of separate SL address space instances in their network. They will not like the network addressing complexity IPv6 appeared to have forced upon them. I think there could be value in coming up with a more appropriate name and definition. While the name "site-local" is obviously not the only cause of confusion and concern about site-local addressing, I don't think it helps. If a more expressive name and definition is decided upon, it can also help make a number of related questions easier to answer. For example, people will understand better where multi-site routers typically would or wouldn't be used, which makes questions such as whether multi-site support should be a requirement of a router implementation simpler. Thanks, 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 1 22:05:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA265O29017353; Fri, 1 Nov 2002 22:05:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA265N6q017352; Fri, 1 Nov 2002 22:05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA265K29017345 for ; Fri, 1 Nov 2002 22:05:20 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA265TbB024089 for ; Fri, 1 Nov 2002 22:05:29 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05212 for ; Fri, 1 Nov 2002 22:05:23 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 561574CD2; Sat, 2 Nov 2002 01:05:23 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 2 Nov 2002 01:05:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Limiting the Use of Site-Local Date: Sat, 2 Nov 2002 01:05:15 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9855@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKBHgYvoDr+2+f1Tn2MOOPS73JJAgBF8uUA From: "Bound, Jim" To: Cc: "Rob Austein" , X-OriginalArrivalTime: 02 Nov 2002 06:05:16.0454 (UTC) FILETIME=[D09BBC60:01C28235] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA265K29017346 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thanks /jim [In matters of style, swim with the currents...in matters of principle, stand like a rock. - Thomas Jefferson] > -----Original Message----- > From: Mark.Andrews@isc.org [mailto:Mark.Andrews@isc.org] > Sent: Thursday, October 31, 2002 3:42 PM > To: Bound, Jim > Cc: Rob Austein; ipng@sunroof.eng.sun.com > Subject: Re: Limiting the Use of Site-Local > > > > > Mark, > > > > > > Please think about this for a minute. It's bad enough for > > > > applications that are driven by a human who can type or > click or > > > > whatever from a list of possible scopes, but what do you do for > > > > programs like MTAs? If you're longing for a return to > the days of > > > > fee!fie%foe@fum email addresess (or even > > > SRA@XX.LCS.MIT.EDU.#Chaos), > > > > you're on the right road. > > > > > > No Rob. > > > > > > I'm talking about 1 name with multiple addresses being > > > returned in multiple scopes. I'm taking about having > > > getaddrinfo() then filter out the inappropriate addresses > > > using local knowledge and setting sin6_scope_id. > > > This deals with 99.9% of address lookup. > > > > We have not even agreed on what sin6_scope_ID is? It is also now > > deprecated for futher study in this wg in the base API except for > > link-local and in the IEEE. So how can you justify putting > it in the > > DNS except as research? Did not we all learn from AAAAv6? > > > > Can you define what you mean by "local knowledge" > > A mapping table between scope name (in the DNS) and > sin6_scope_ID > (being the 32 bit value that being used by the node to identify > that site / link). > > > How does DNS know that scope applies to the node that did the > > getaddrinfo if it don't know? Which all but a few implementations > > know today and I have many questions for those that say they do. > > > > Regards, > > /jim > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -- > 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 Sat Nov 2 02:07:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2A7129018513; Sat, 2 Nov 2002 02:07:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA2A71SA018512; Sat, 2 Nov 2002 02:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2A6w29018505 for ; Sat, 2 Nov 2002 02:06:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA2A76bB018266 for ; Sat, 2 Nov 2002 02:07:06 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27676 for ; Sat, 2 Nov 2002 03:07:00 -0700 (MST) Received: from newton.cs.uni-bonn.de (newton.cs.uni-bonn.de [131.220.4.212]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id LAA21069 for ; Sat, 2 Nov 2002 11:06:59 +0100 (MET) Received: (from ignatios@localhost) by newton.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA11065 for ipng@sunroof.eng.sun.com; Sat, 2 Nov 2002 11:06:11 +0100 (CET) Date: Sat, 2 Nov 2002 11:06:11 +0100 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: Re: Recent Posting Stats Message-ID: <20021102110611.A10929@newton.cs.uni-bonn.de> References: <200211011245.gA1Cj4oY087894@m5p.com> <200211012011.gA1KBic00416@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200211012011.gA1KBic00416@rotala.raleigh.ibm.com>; from narten@us.ibm.com on Fri, Nov 01, 2002 at 03:11:44PM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hello, On Fri, Nov 01, 2002 at 03:11:44PM -0500, Thomas Narten wrote: > Folks, >=20 > The stats George posted are well worth thinking hard about. >=20 > When there are so many postings on a list in such a short time, the > following is inevitable: >=20 > - folks don't read them all anymore. I'm sure folks make decisions on > which messages to delete unread based on their opinion of an > individual poster's typical signal-to-noise ratio based on recent > and past postings. In other words, if you want other people to read > your postings (which I would assume is the point), less is often > more. Yes, this is the case. A thread such as the one (well, the three) about usage of site-local addresses is simply unreadable. When such thread reaches that amount of volume, I can't but delete it completely or just select a few key writers, based on past experience, and read messages near the end of subthreads hoping that they're citing key arguments of other posters when answering. Not finding this, I either have to base my opinion on my own bias or just ignore the issue completely. -is --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPcOjkDCn4om+4LhpAQHsOwf/VF85FB9ME7gM9WeXavYjH5d7kmldtlov UzdtwqwOu06ufayMyZslWidQeut/dq7X7A6kgKH6PsES3gM2rJ/li1AIPU/QH4+M vGq2vrhK8bE0l0oO0OYySTnsXd8LWek6hI8ooXTPyNbUFUyTqe0rNqmAe8HgcxQM 4ogXeXOkuQHZogGIf6yajtkEN3zEP5z2ZMi3fiBlXdULbrb80U/AUgYbh7h/KQ9K NlhJinoLciIf5ZnMeSE7A/rIefaanx8ywn4c5+6N32NZLk9Pv4gTIsl/o8PAo1uu bBjLQrm5oXPot7CWihhor30AmztD3HJ4kzbOPz5Zi+Ki7zpqFpvDWg== =tfpV -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 2 04:56:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2CuT29018980; Sat, 2 Nov 2002 04:56:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA2CuTRi018979; Sat, 2 Nov 2002 04:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2CuQ29018972 for ; Sat, 2 Nov 2002 04:56:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA2CuZbB002067 for ; Sat, 2 Nov 2002 04:56:35 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10120 for ; Sat, 2 Nov 2002 05:56:29 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA28263; Sat, 2 Nov 2002 04:56:06 -0800 (PST) Message-Id: <5.1.0.14.2.20021102074549.0a57eec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 02 Nov 2002 07:49:47 -0500 To: Mark Smith From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: Richard Draves , ipng@sunroof.eng.sun.com In-Reply-To: <1036208210.28225.29.camel@dupy> References: < Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:36 PM 11/1/02, Mark Smith wrote: > > Why do you think that site-local addressing is tied to geography in any > > way? > >A few reasons : > >1) because of the name ?! the word "site" in common english has >geographical connotations. Also, the geographical aspect of a "site" has been used to debunk several concerns that have been raised about routing in sites that include more than one location separated by a WAN link. 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 Nov 2 05:03:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2D3s29019026; Sat, 2 Nov 2002 05:03:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA2D3sug019025; Sat, 2 Nov 2002 05:03:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2D3o29019015 for ; Sat, 2 Nov 2002 05:03:50 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA2D3xMq017788 for ; Sat, 2 Nov 2002 05:03:59 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28122 for ; Sat, 2 Nov 2002 06:03:54 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA00474 for ; Sat, 2 Nov 2002 05:03:45 -0800 (PST) Message-Id: <5.1.0.14.2.20021102075349.0a566140@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 02 Nov 2002 08:05:18 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: SUMMARY: RE: Limiting the Use of Site-Local In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9855@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Posting only as an interested individual: It definitely seems like this discussion is degenerating, but I think we have made some useful progress in understanding what the key issues are in this debate: - What are the security impacts, if any, of site local addresses. - How important are site-local addresses as a tool to allow site administrators to have address independence from their ISPs, and are there other ways to get this benefit? - What level of impact, if any, will the widespread use of site-local addresses have on: - Applications (current and future) - Transport Protocols - Security Protocols - Network Management Protocols - Should site-local addresses be placed in the DNS, and if so, how? - What level of complexity do site-local addresses add to router/routing protocol implementations? - Is there a good way to limit the use of site-local addresses (to non-globally attached networks, special uses, etc.) that will maximize the benefits and minimize the problems? Did I miss any of the big issues? Unfortunately, we haven't made much progress in resolving any of these issues, and it doesn't look like we will resolve them by continuing to send each other the same points in e-mail over and over again... I have offered to write a document that explains my thoughts on the above issues, with a little help from my friends. It might also be useful for folks who believe that we should not place any limitations on the use of site-local addresses to write a similar document. What do you guys think? 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 Nov 2 06:50:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2Eol29019579; Sat, 2 Nov 2002 06:50:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA2EolLO019578; Sat, 2 Nov 2002 06:50: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2Eoi29019571 for ; Sat, 2 Nov 2002 06:50:44 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA2EorMq000472 for ; Sat, 2 Nov 2002 06:50:53 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26125 for ; Sat, 2 Nov 2002 07:50:47 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA2EokQ1020803; Sat, 2 Nov 2002 15:50:46 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sat, 2 Nov 2002 15:50:46 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C6C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local Date: Sat, 2 Nov 2002 15:50:45 +0100 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 Hi Margaret > I have offered to write a document that explains my thoughts on > the above issues, with a little help from my friends. It might > also be useful for folks who believe that we should not place > any limitations on the use of site-local addresses to write a > similar document. > > What do you guys think? => I have a problem with this approach. I don't think it will help to group the people arguing into two separate proposals, one for SLs and one against. I can just see another infinite loop in a few months. A better approach would be to get someone who's willing to summarise the discussion into a _single_ draft containing the pros and cons in an objective manner. This is tricky and would require the editor to remove his/her biases. But this is the best way forward IMO. Please do not go with the two different drafts that represent two different campaigns, it does not work. And also please read Jinmei's email which expresses the same concern that I have. 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 Sat Nov 2 07:36:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2Fan29019740; Sat, 2 Nov 2002 07:36:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA2Fan09019739; Sat, 2 Nov 2002 07:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2Faj29019732 for ; Sat, 2 Nov 2002 07:36:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA2FasMq004380 for ; Sat, 2 Nov 2002 07:36:54 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01753 for ; Sat, 2 Nov 2002 08:36:48 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA2FagU29090; Sat, 2 Nov 2002 10:36:42 -0500 (EST) Message-Id: <200211021536.gA2FagU29090@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (EAB)" cc: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: SUMMARY: RE: Limiting the Use of Site-Local In-reply-to: (Your message of "Sat, 02 Nov 2002 15:50:45 +0100.") <4DA6EA82906FD511BE2F00508BCF0538044F0C6C@Esealnt861.al.sw.ericsson.se> Date: Sat, 02 Nov 2002 10:36:42 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => I have a problem with this approach. I don't think > it will help to group the people arguing into > two separate proposals, one for SLs and one against. I don't think anyone is arguing entirely against SLs - at least I don't think anyone believes the group will entirely abolish them. I do think I see some convergence, with some people who are "pro" SL grudgingly admitting that they cause more problems than they thought and people who are "anti" SL (like myself) grudgingly admitting that SLs might have one or two valid use cases than we had originally thought. I agree that putting pros and cons of SLs in a single document would be better in the long run, though perhaps not for initial drafts. 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 Nov 2 08:52:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2Gqa29019913; Sat, 2 Nov 2002 08:52:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA2GqZu0019912; Sat, 2 Nov 2002 08:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2GqW29019905 for ; Sat, 2 Nov 2002 08:52:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA2GqebB022335 for ; Sat, 2 Nov 2002 08:52:40 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23080 for ; Sat, 2 Nov 2002 09:52:34 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gA2Gqdwc001557; Sat, 2 Nov 2002 17:52:40 +0100 (CET) Date: Sat, 2 Nov 2002 14:49:55 +0100 Subject: Re: Limiting the Use of Site-Local Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Keith Moore" , "Margaret Wasserman" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <2B81403386729140A3A899A8B39B046405E3E7@server2000> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> Keith, what you are saying here is that the utility >>> company is going to have to use PA addresses, that it >>> does not own, to configure tens of thousands of devices >>> on thousands of subnets, and be forced to renumber >>> if they want to switch ISPs, even though these devices >>> have nothing to do with the public Internet, just >>> because you don't like SLs. > >> Kurt Erik Lindqvist wrote: >> ....and the day the utility company decides to outsource the >> monitoring they will have to renumber to global addresses >> anyway. > > Total nonsense. > Why? That would be the case i they wanted to connect - which is not unlikely for the future. I know cities in Sweden where building owners are monitoring the utilities via public connections and I know places where the road administration uses the public Internet for monitoring devices. In you model they would use site-locals, but what happens the day they connect to the public Internet? - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 2 08:52:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2Gqt29019930; Sat, 2 Nov 2002 08:52:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA2GqtQD019929; Sat, 2 Nov 2002 08:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2Gqn29019915 for ; Sat, 2 Nov 2002 08:52:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA2GqwbB022365 for ; Sat, 2 Nov 2002 08:52:58 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23117 for ; Sat, 2 Nov 2002 09:52:52 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gA2Gr8wc001563; Sat, 2 Nov 2002 17:53:09 +0100 (CET) Date: Sat, 2 Nov 2002 16:33:33 +0100 Subject: Re: Default site-local behavior for routers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ipng@sunroof.eng.sun.com To: Richard Carlson From: Kurt Erik Lindqvist In-Reply-To: <5.1.1.5.2.20021101091123.02192300@atalanta.ctd.anl.gov> Message-Id: <72758900-EE78-11D6-84E6-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I disagree with this assessment. In the v4 world sites that are, > voluntarily or forcibly, using RFC 1918 address do expect to connect > into the public Internet. They do so because these are the only IP > addresses they have, so what other choice do they have? This is an effect of the current shortage of IPv4 addresses that IPv6 is supposed to address. Remember that the Internet was doing just fine before RFC1918 as well. > > The multi-address space in the v6 world is being presented in a > different light. SLs are NOT replacements for RFC 1918 private > addresses, they are just another option that a site can use if it > chooses to. SLs have no meaning outside the site boundary, just as > LLs have no meaning outside the local link and Globals have no meaning > outside the global v6 Internet. Therefore it is not possible for 2 > disjoint sites to connect to each other. I don't think anyone here disagrees with what you are saying. However, what you are describing is the way that RFC1918 have been (ab)used. The argument is over the effects of using site-locals/RFC1918 addresses. That people would use site-locals in the same way as they use RFC1918 addresses today I don't think anyone questions. > > The options to solve this should include getting globals or creating a > new super-site that encompasses the individual sites. The pressure to > deploy NATs will only come if we fail to provide these alternatives. Agreed. Creating PI space will leave to growth of the routing table, which is a multi6-wg concern, and will also in a way destroy the aggregation intent with IPv6. It would however make site-locals more or less unnecessary. Allowing site-locals will have people use them the same way as they use RFC1918 space and that will lead to problems with deploying new applications built on peer-to-peer. I think the peer-to-peer principle is more important than the routing-table growth. The routing-table will grow anyway, so we need to address that problem as it is. - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 2 08:53:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2Gr029019933; Sat, 2 Nov 2002 08:53:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA2Gr0pp019932; Sat, 2 Nov 2002 08:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2Gqq29019922 for ; Sat, 2 Nov 2002 08:52:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA2Gr1Mq011172 for ; Sat, 2 Nov 2002 08:53:01 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23126 for ; Sat, 2 Nov 2002 09:52:55 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gA2Gr6wc001560; Sat, 2 Nov 2002 17:53:07 +0100 (CET) Date: Sat, 2 Nov 2002 15:13:32 +0100 Subject: Re: Why would I use a site-local address? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: awhite@arc.corp.mot.com, ipng@sunroof.eng.sun.com To: Keith Moore From: Kurt Erik Lindqvist In-Reply-To: <200211011211.gA1CBP006753@astro.cs.utk.edu> Message-Id: <44DF48EC-EE6D-11D6-84E6-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To add to this..... 6to4 is a transition mechanism. One of the major ideas behind IPv6 is to address the address shortage - which has lead to among other things, dynamic allocation of IP addresses for dial-up. I do understand that there is a transition problem here, but I hope we are not arguing for site-locals as a permanent solution for dial-up networks. - kurtis - On fredag, nov 1, 2002, at 13:11 Europe/Stockholm, Keith Moore wrote: > networks with intermittent connectivity might be a valid case for use > of site-locals, though giving such networks a non-routable global > prefix > would cause fewer problems for applications. > > also, you're correct that when using 6to4 with dialup v4 providers > the prefix is likely change each time the network is connected > (unless special arrangements have been made with the ISP), however > this does not necessarily hold for native v6 connectivity. with v6 > there is not as much need to reuse addresses for dialup lines. IMHO > the decision to recommend address reuse on dialup lines should be > reexamined for v6. > > it's not reasonable to assume that v6 applications will cope with rapid > prefix changes. > > the problem with the idea that site-locals should be favored over > globals is that this is exactly the wrong rule for some applications > and on some networks. as far as I can tell, address selection rules > need to be derived from a combination of application requirements > and local network policy. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 2 08:55:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2Gtt29019989; Sat, 2 Nov 2002 08:55:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA2Gtt5s019988; Sat, 2 Nov 2002 08:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2Gtq29019980 for ; Sat, 2 Nov 2002 08:55:52 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA2Gu1Mq011441 for ; Sat, 2 Nov 2002 08:56:01 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16705 for ; Sat, 2 Nov 2002 08:55:55 -0800 (PST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gA2Gu7wc001566; Sat, 2 Nov 2002 17:56:08 +0100 (CET) Date: Sat, 2 Nov 2002 17:56:07 +0100 Subject: Re: Node Requirements Issue 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ipng@sunroof.eng.sun.com To: "Hesham Soliman (EAB)" From: Kurt Erik Lindqvist In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0C5B@Esealnt861.al.sw.ericsson.se> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> => Why is it gone ? Not everyone wants NATs and for those who >>> do, deprecating SL addresses will not help. It will just make >>> their (Network admins) behaviour less predictable. >> >> Maybe, but from a operator point of view, the advantage of >> being early >> on IPv6 is to enable your users to do peer-to-peer >> services. There are >> no new services I can launch just because I give out IPv6 >> address, on >> the contrary. There is most likely a higher cost involved. > > => I don't disagree with that, but I don't > see the relevance to my statement. Well, my point was that operators might want to influence the network admins to go for no-NAT as they want to sell peer-to-peer services and that is one of the few drivers for operators to go to IPv6. > >>> => Yes there is. The address size itself allows to do things >>> that you can't do with v4. Check out the SEND WG for example >>> or MIPv6, or address autoconf.... >> >> This are all services / functions I could do in IPv4 as >> well. Perhaps >> not with the IPv4 address header though. > > => I'll be very interested in seeing a proposal on > secure ARP, MIPv4 RO or the final Zeroconf solution > for IPv4 autoconf.... I am not saying you can take all the protocols of IPv6 and transfer them to IPv4. I am saying you can achieve the same level of functionality in v4. > >>> If you choose to use SL with globally routable addresses >>> in the same network, you can get P2P. >> >> If I have globally routeable addresses in the first place >> to identify >> my network devices, why would I want SL? > > => If you don't want it, don't use it. No one is > suggesting that every site must use them. No, but when I come up with the peer-to-peer service pidgins-over-IP, I will not be able to sell it to a (most likely) large part of the Internet connected enterprises as they are behind IPv6 NATs. They started out with networks that where not connected to the public Internet, got the site-locals, there friendly consulting company sold them a firewall, convinced them they where much safer if they stayed with the site-locals and bought the software-add-on license for IPv6-NAT..... Does the story sound familiar? That enterprise is now waiting for the release of the pidgins-over-IP (or SIP or any other new protocol) proxy update for their firewall..... > > > If you give people >> a tool - >> they will use it, and eventually someone will hurt >> themselves with it. > > => I don't think so. People will do what they want > with whatever addresses they invent. Network admins > are not kids. They are convinced that (in some cases) > they need certain features. They will get there one No. Network admins will buy what the latest marketing story in Packet Magazine or some IDG paper says. I am sorry - that is the way it works. Not for all, but for many. How many network admins do you think is following this discussion and understand the different concepts? > way or another. You might disagree with their reasons > or arguments, but there is no decision we take here > that will change their minds immediately. Here I agree. But that does not mean that we should not learn of the past. IPv6 has many flaws - mainly in that it does not address some of the more urgent problems on todays Internet besides address shortage. We have a window of opportunity to fix a lot of other things that where bad about IPv4. Let's be open minded and try and do that. Let's not blindly try and copy IPv4 with us. >> >> I have still to see an argument as to what there is with SLs that I >> can't do with globaladdresses? > > => Well, if after reading all the mails you still > think so, don't expect one from me :) > I am more worried that people are starting to give up on the discussion because it's locked.... - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 2 11:06:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2J6o29020559; Sat, 2 Nov 2002 11:06:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA2J6o6s020558; Sat, 2 Nov 2002 11:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2J6l29020551 for ; Sat, 2 Nov 2002 11:06:47 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA2J6tbB006341 for ; Sat, 2 Nov 2002 11:06:55 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21978 for ; Sat, 2 Nov 2002 12:06:49 -0700 (MST) Subject: RE: Limiting the Use of Site-Local Date: Sat, 2 Nov 2002 11:06:51 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E3FF@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcKCkF8nVTJTW6ZtQuOsVRy+8ZknOgAEBDJg From: "Michel Py" To: "Kurt Erik Lindqvist" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA2J6l29020552 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> Kurt Erik Lindqvist wrote: >>> ....and the day the utility company decides to >>> outsource the monitoring they will have to renumber >>> to global addresses anyway. >> Michel Py wrote: >> Total nonsense. > Why? That would be the case i they wanted to connect > - which is not unlikely for the future. I know cities > in Sweden where building owners are monitoring the > utilities via public connections and I know places > where the road administration uses the public Internet > for monitoring devices. This does not add up. Monitoring is one thing, controlling is another one. If having probes that connect to the Internet is acceptable because these are read-only, and because there is nothing confidential in the data, fine. The devices that _control_ the flow of current or water, the plane surfaces, the reactor in a nuclear power plant are quite something else, and these are *not* on the public internet. > In you model they would use site-locals, but what > happens the day they connect to the public Internet? You don't get the point. The choice of site-locals is a deliberate choice of *never* connecting a device to the Internet. It's a design requirement, not a limitation. 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 Nov 2 11:17:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2JHx29020723; Sat, 2 Nov 2002 11:17:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA2JHxBU020722; Sat, 2 Nov 2002 11:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2JHu29020715 for ; Sat, 2 Nov 2002 11:17:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA2JI4bB007652 for ; Sat, 2 Nov 2002 11:18:04 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25172 for ; Sat, 2 Nov 2002 12:17:58 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA05242; Sat, 2 Nov 2002 11:17:43 -0800 (PST) Message-Id: <5.1.0.14.2.20021102141830.0a4eb700@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 02 Nov 2002 14:19:15 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: "Kurt Erik Lindqvist" , In-Reply-To: <2B81403386729140A3A899A8B39B046405E3FF@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Michel, >You don't get the point. The choice of site-locals is a deliberate >choice of *never* connecting a device to the Internet. It's a design >requirement, not a limitation. In your model of how site-local would be used, will there be devices that have both site-local and global addresses? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 2 11:44:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2Jim29020910; Sat, 2 Nov 2002 11:44:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA2JimqD020909; Sat, 2 Nov 2002 11:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA2Jij29020899 for ; Sat, 2 Nov 2002 11:44:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA2JirbB010093 for ; Sat, 2 Nov 2002 11:44:53 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04018 for ; Sat, 2 Nov 2002 12:44:46 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id OAA26368; Sat, 2 Nov 2002 14:44:42 -0500 (EST) Date: Sat, 2 Nov 2002 14:44:42 -0500 (EST) From: Dan Lanciani Message-Id: <200211021944.OAA26368@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Tony Hain" wrote: |I do have one question about your comment, do you believe transparent |renumbering is a sham, or did I mis-read your intent? I don't believe that transparent renumbering in and of itself is a sham. I do believe that any claim that it will be implemented soon enough and well enough to obviate the need for stable local addresses is a sham. I also believe that the claim that transparent renumbering is an easier problem to solve than portable identifiers is a sham. IMHO, the easiest way to make transparent renumbering work is to introduce a level of indirection. But that's really just the same thing as having portable identifiers. Any other solution to the transparent renumbering problem is going to involve pervasive changes at all levels of the stack, and APIs to put applications in the loop. In other words, it can be at best transparent to the user. This is a lot of work. |Your point is there will be end-user-controlled address space, the only |option we have now is SL but we only need one mechanism that meets the |requirement. I certainly wouldn't object to having more than one mechanism. My concern is that if we keep waiting for a better solution we will have no solution and NAT will prevail. I don't see any benefit of NAT'ed v6 over NAT'ed v4, so why bother to change at all? Something else that bothers me about this discussion is that while there is endless debate around such relatively subjective (and thus highly debatable) topics as the potential security benefits of site-locals, I have yet to see anyone directly address basic questions like: How do I talk to my local network pinter without renting an additional address from my ISP? If I rent another address for my local file server, how much extra do I have to pay to guarantee that it won't be renumbered in the middle of a six-hour build? Clearly since I'm doing builds and using a file server at all I must have a profitable business, so the ISP will be justified in demanding that I buy at least their ``small business package'' to get such a ``feature,'' no? There have been several vague hints that v6 has offered up a solution to v4's (arguably artificial) address shortage, but I've yet to see anything tangible. In fact, v6's renumbering support makes the situation that much worse for end users in as much as it goes way beyond DHCP in giving ISPs the ability to disrupt a network. Remember that--with a few exceptions--ISPs are in business to make money. Counting or limiting addresses (and in particular, stable addresses) as a surrogate measure of bandwidth is a very popular business model. I've heard absolutely nothing to convince me that the business model will change with v6. From those that claim that global v6 address space will be cheap and easy to get I would like to hear specific details of the new business model that ISPs are preparing to adopt. |> So we are coming full circle? We have the renumbering |> problem because the portable address/identifier problem was |> declared by fiat to be too hard to even think about solving. |> We are stuck with site-local addressing because the |> renumbering problem turned out to be too difficult to solve |> in practice. | |Please explain... I understand that renumbering and static configuration |of things like filters can be a challenge, but those are solvable given |a reasonable time period. Is this simply a matter of an app can't |survive a reunmbering event? For anything other than the indirection solution, I'm afraid applications are going to have to be involved in renumbering. Nobody seems to be working actively on this anymore, so the time period may well be infinite. In fact, I think I've seen comments in this thread that applications should not be expected to deal with frequent renumbering. Since it isn't clear that dealing with one renumbering event at a bad time is any easier than dealing with frequent renumbering events, I think this is just a euphemism for saying that it's ok for applications to fail in the face of renumbering. As long as the renumbering is infrequent users are supposed to accept such infrequent failures from the applications. Of course, there is no reason to believe that those renumbering events and failures will be infrequent in real life. If applications deal with neither scopes nor renumbering we are back to NAT again. |This is because there is a complete lack of appreciation for the |fundemental requirement that a network manager have stable locally |controlled address space. This has bugged me for years. Being a cynic, I have to think that at least some factions appreciate the requirement and look to an artificial shortage of such address space with a profit motive. But once again, we know that trying to extract too much money this way simply fuels NAT usage. Even if v6 is more hostile towards NAT implementation, there are some pretty clever authors out there... |As a slightly off topic question, do you agree with the business driver |assertions in draft-hain-ipv6-pi-addr-use-03.txt ? We can disagree about |the approach in the PI format, but the fundamental reasons should be |consistent. I'm not sure I understand the question. What is the business aspect? I have nothing in particular against geographic addresses, especially if they are the only kind of routable "portable" addresses I can get. The big questions will be whether ISPs feel they can charge a premium for supporting such addresses and whether there will be some other entity who will want to collect a (possibly recurring) fee to allocate them in the first place. (Granted the latter will seem a bit funny. Why should I have to pay to allocate address space defined by the land I own? But weirder things have happened.) I did notice some wording in your draft that implied a need-based usage, e.g., for multi-homed customers. I hope there will be nothing to allow ISPs to classify such addresses as a premium service because of their association with what are perceived to be activities limited to big/rich companies. |Non-routable global addresses are by definition local. The only thing |they bring to the table over SL is ambiguity in the scope of |routability. They may help with site merger. My only point is that they don't remove the need to deal with scopes, so they aren't in any sense an alternative--just a variation. Thus the argument that we don't have to worry about scopes if we wait for non-routable globals seems specious. 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 Nov 2 16:56:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA30uX29022840; Sat, 2 Nov 2002 16:56:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA30uXeL022839; Sat, 2 Nov 2002 16:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA30uT29022832 for ; Sat, 2 Nov 2002 16:56:30 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA30ucMq003705 for ; Sat, 2 Nov 2002 16:56:38 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12551 for ; Sat, 2 Nov 2002 16:56:33 -0800 (PST) Subject: RE: Limiting the Use of Site-Local Date: Sat, 2 Nov 2002 16:56:36 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E400@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcKCpKRMywIj3WcfQCiWcTA3JvQGSQAKpqQg 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 gA30uU29022833 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > In your model of how site-local would be used, > will there be devices that have both site-local > and global addresses? The short answer is no, but I'd rather get into more details: There are four situations I can see: 1. For control devices that have only one interface, no, that's the point. If they also have public addresses the advantages of using site-locals are nullified. The example is these control devices in the diagram below, only one interface and only one address which is a site-local (and a link-local of course). 2. In terms of having a host located on the control devices subnet that does not have control functions and that has both a global and a site-local address, this is a double edged sword. I personally favor that it should _not_ be possible, because it would require to have public addresses on the right side of router B, which is getting half of the hacking job done. I believe this is the core of your question. The arguments I have heard in favor of making this possible are mostly economic, it basically saves a router interface. When viewed from layer 8 or 9, it does not matter so I would say unless someone else argues for it the answer should be no, in other words no exception to the control devices setup explained in 1. 3. Now there could be hosts that act as proxies, even though they do not route packets. In the diagram below, Router B could be a host instead of a router, that will naturally be the only one able to access directly the control devices. However, this is one interface with public addresses and another one with site-locals, and I don't see the difference with a router in terms of the scope of the addresses, except that there is no routing. 4. Routers, yes. In the diagram below, it is clear that B will have a site-local address on the right side and a global address on the left side. Hope this answers the question. Michel. <------------------- Global Addresses ---------------><-- SL addr --> +-----+ | ISP | +--+--+ ! +--+-------+ +----------+ +----------+ +----------+ | Router A +--+ Firewall +--+--+ Firewall +--+--+ Router B +----+ +----------+ +----------+ | +----------+ | +----------+ | | | | +---+--+ +--+---+ +----+----+ | DFZ | | Host | | Control | | Host | +------+ | Device | +------+ +---------+ <---------------------- Network ----------------------> -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 2 17:08:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA318W29022930; Sat, 2 Nov 2002 17:08:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA318WQh022929; Sat, 2 Nov 2002 17:08: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA318T29022922 for ; Sat, 2 Nov 2002 17:08:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA318bbB009824 for ; Sat, 2 Nov 2002 17:08:37 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA04867 for ; Sat, 2 Nov 2002 18:08:31 -0700 (MST) Subject: RE: Limiting the Use of Site-Local Date: Sat, 2 Nov 2002 17:08:33 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E401@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcKCpKRMywIj3WcfQCiWcTA3JvQGSQAMCKOg 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 gA318T29022923 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > In your model of how site-local would be used, > will there be devices that have both site-local > and global addresses? There is something else about this I meant to contribute as well: Again the short answer is no, but I am opposed to deprecation in this situation, even though I support the idea of not having both public and site-local enabled at the same time. The reason is operational: If someone cross-connects two vlans or puts a cross-over cable between a public and a site-local subnet, and deprecation is enabled, there is a chance of network outage because of this condition. Not good. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 3 11:25:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3JPx29026845; Sun, 3 Nov 2002 11:25:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA3JPwtW026844; Sun, 3 Nov 2002 11:25: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3JPt29026837 for ; Sun, 3 Nov 2002 11:25:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA3JQ4Mq001071 for ; Sun, 3 Nov 2002 11:26:04 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01393 for ; Sun, 3 Nov 2002 12:25:58 -0700 (MST) Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local Date: Sun, 3 Nov 2002 11:26:03 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E402@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: SUMMARY: RE: Limiting the Use of Site-Local Thread-Index: AcKCcSHiPLWGNFRDQhS7UFCsz2zR1gA/DfgA From: "Michel Py" To: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA3JPt29026838 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > [Limiting the Use of Site-Local] > I have offered to write a document that explains my > thoughts on the above issues I don't see how this could reach consensus. It appears to me that way too many people here have forgot The Golden Rule of a successful product, which is to keep the customer happy. IPv6 is a product, it its success is a lot more tied to what customers (read: network administrators) think than to what people that develop stacks think, whether you like it or not. There is ample evidence to support the fact that the customer (the network administrator) wants, if not site-local, at least something that provides what site-local does; and that they will continue using them the way they see fit regardless of the fact that the IETF could try to restrict their use or not. Keep the customer happy. When a dog is happy, it wags its tail. Trying to wag the dog instead is not going to work with network administrators that have been doing it for 30 years, and that actually do know a lot about doing 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 Sun Nov 3 12:17:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3KHZ29027206; Sun, 3 Nov 2002 12:17:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA3KHZMp027205; Sun, 3 Nov 2002 12:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3KHW29027198 for ; Sun, 3 Nov 2002 12:17:32 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA3KHgMq007209 for ; Sun, 3 Nov 2002 12:17:42 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00389 for ; Sun, 3 Nov 2002 12:17:36 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA16033; Sun, 3 Nov 2002 12:17:25 -0800 (PST) Message-Id: <5.1.0.14.2.20021103151156.03022340@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 03 Nov 2002 15:18:46 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local Cc: In-Reply-To: <2B81403386729140A3A899A8B39B046405E402@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 02:26 PM 11/3/02, Michel Py wrote: > > Margaret Wasserman wrote: > > [Limiting the Use of Site-Local] > > I have offered to write a document that explains my > > thoughts on the above issues > >I don't see how this could reach consensus. Not all documents that people write do reach consensus. Some do, and are published. Some explain a viewpoint and are useful as a means of clear communication, even if they never become RFCs. >There is ample evidence to support the fact that the customer (the >network administrator) wants, if not site-local, at least something that >provides what site-local does; and that they will continue using them >the way they see fit regardless of the fact that the IETF could try to >restrict their use or not. Keep the customer happy. However, there are significant questions about what site-local provides, and little enough commercial deployment of IPv6 that it is hard to say, at this point, what will prevail. I agree that customers use IPv4 RFC 1918 addresses and NAT, but I don't think that we have a full understand of _why_ these things are used -- what the actual motivators are, not a laundry list of everything they might be useful for... Site-locals bear a surface resemblance to RFC 1918 addresses behind NAT, but they actually don't work the same way. For example, site locals do not really shield the site from the need to renumber the global prefixes, the way a NAT does. Also, there are no ALGs defined to allow applications to work properly across site boundaries in IPv6. Maybe we'll end-up defining IPv6 NAT and ALGs based on customer demand, but I hope not. Ideally, we'd like to construct the IPv6 protocol, the IPv6 address allocations policies, etc. to promote a flatter and more end-to-end architecture in the IPv6 Internet. Maybe we'll fail, but I'm not ready to give up trying. 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 Nov 3 12:48:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3Kmv29027484; Sun, 3 Nov 2002 12:48:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA3KmunM027483; Sun, 3 Nov 2002 12:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3Kmr29027476 for ; Sun, 3 Nov 2002 12:48:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA3Kn3Mq014562 for ; Sun, 3 Nov 2002 12:49:03 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA22200 for ; Sun, 3 Nov 2002 13:48:57 -0700 (MST) Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local Date: Sun, 3 Nov 2002 12:49:03 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E403@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: SUMMARY: RE: Limiting the Use of Site-Local X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcKDdjhrL0e/5mUERxWTciPxbTqPygAAzTAA 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 gA3Kms29027477 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > However, there are significant questions about what > site-local provides, This is not the point. Nobody cares about what they provide, as long as customers want them. > Ideally, we'd like to construct the IPv6 protocol, the > IPv6 address allocations policies, etc. to promote a > flatter and more end-to-end architecture in the IPv6 > Internet. Everybody wants this, what does it have to do with site-local addresses? The scope is not the same nor the intended use. Site-locals are *not* for the Internet. 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 Nov 3 13:03:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3L3f29027613; Sun, 3 Nov 2002 13:03:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA3L3fq1027612; Sun, 3 Nov 2002 13:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3L3Z29027595 for ; Sun, 3 Nov 2002 13:03:35 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA3L3jMq015847 for ; Sun, 3 Nov 2002 13:03:45 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19205 for ; Sun, 3 Nov 2002 14:03:39 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA27093; Sun, 3 Nov 2002 13:03:28 -0800 (PST) Message-Id: <5.1.0.14.2.20021103155949.041a6a20@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 03 Nov 2002 16:01:28 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local Cc: In-Reply-To: <2B81403386729140A3A899A8B39B046405E403@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >Everybody wants this, what does it have to do with site-local addresses? >The scope is not the same nor the intended use. Site-locals are *not* >for the Internet. Michel, as far as I know, no one is advocating that we eliminate or deprecate site-locals for non-Internet-connected networks. The problems arise when a single network has both site-local and global prefixes, resulting in nodes that have site-local and global addresses. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 3 13:03:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3L3q29027615; Sun, 3 Nov 2002 13:03:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA3L3gQT027614; Sun, 3 Nov 2002 13:03:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3L3a29027597 for ; Sun, 3 Nov 2002 13:03:36 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA3L3jMq015851 for ; Sun, 3 Nov 2002 13:03:45 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19210 for ; Sun, 3 Nov 2002 14:03:40 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA27097; Sun, 3 Nov 2002 13:03:30 -0800 (PST) Message-Id: <5.1.0.14.2.20021103160147.041aa1e0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 03 Nov 2002 16:04:56 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: In-Reply-To: <2B81403386729140A3A899A8B39B046405E400@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Michel, I don't understand this picture: ><------------------- Global Addresses ---------------><-- SL addr --> >+-----+ >| ISP | >+--+--+ > ! >+--+-------+ +----------+ +----------+ +----------+ >| Router A +--+ Firewall +--+--+ Firewall +--+--+ Router B +----+ >+----------+ +----------+ | +----------+ | +----------+ | > | | | > +---+--+ +--+---+ +----+----+ > | DFZ | | Host | | Control | > | Host | +------+ | Device | > +------+ +---------+ > <---------------------- Network ----------------------> Is "Rputer B" the SBR? In this situation, why/how would "Router B" ever route any packets? The control device(s) will only have site-local addresses, so they can't send packets that will be routed by "Router B", nor can any systems to left of Router B (outside the site?) send packets to the control devices... What am I missing? 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 Nov 3 13:06:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3L6I29027643; Sun, 3 Nov 2002 13:06:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA3L6HsK027642; Sun, 3 Nov 2002 13:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3L6D29027635 for ; Sun, 3 Nov 2002 13:06:14 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA3L6NMq016018 for ; Sun, 3 Nov 2002 13:06:23 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11705 for ; Sun, 3 Nov 2002 13:06:18 -0800 (PST) Subject: RE: (ipv6) The meaning of "site" Date: Sun, 3 Nov 2002 13:06:24 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E405@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: (ipv6) The meaning of "site" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcKCNQ2WiLRYuSxjQtCzU3LCZpwdIwBRkhqA From: "Michel Py" To: "Mark Smith" Cc: "Richard Draves" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA3L6E29027636 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mark, >> Michel Py wrote: >> While I fully agree with your reading of the RFC and the >> English connotation of the word "site", it appears to be >> an unwritten convention that says that a site is a /48. >> This leads to some semantic confusion in the case of >> organizations that get a /48 and are spanned over several >> physical locations that could be separated by hundreds or >> thousands of miles. > Mark Smith wrote > Agreed. > The 54 bits for subnet allocation in a site-local address > tends to strongly suggest that a site-local addressing > boundary is not a geographical boundary. > The huge number of subnet bits also tends to suggest that > within the administrative boundaries of a connected network, > only one instance of SL addressing should exist. > For simplicity reasons, my IPv6 network would have a single > instance of site-local addressing, and if I had to merge it > with another IPV6 network using site-local addressing, I > would be working towards achieving a single site-local > addressing instance again, as part of the process of merging > the networks. Agreed. Merging two networks is like a marriage: there are some things that are not as good as there were when the two individuals were single. The pain of renumbering is then considered as part of the compromises that needs to be made. This compared to renumber when switching ISPs, which is more or less the equivalent of saying that you need to change your refrigerator if you decide to buy your groceries in another store. > If a more expressive name and definition is decided upon, > it can also help make a number of related questions easier > to answer. Agreed again. 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 Nov 3 13:47:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3LlT29028017; Sun, 3 Nov 2002 13:47:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA3LlSeR028016; Sun, 3 Nov 2002 13:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3LlP29028009 for ; Sun, 3 Nov 2002 13:47:25 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA3LlZbB005587 for ; Sun, 3 Nov 2002 13:47:35 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20806 for ; Sun, 3 Nov 2002 13:47:29 -0800 (PST) Subject: RE: Limiting the Use of Site-Local Date: Sun, 3 Nov 2002 13:47:35 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E406@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: Limiting the Use of Site-Local X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcKDfJRp9Gj00mc6R4qp67o0KTCfXAAAFqCg 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 gA3LlP29028010 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > Margaret Wasserman wrote: > I don't understand this picture: <------------------- Global Addresses ---------------><-- SL addr --> +-----+ | ISP | +--+--+ ! +--+-------+ +----------+ +----------+ +----------+ | Router A +--+ Firewall +--+--+ Firewall +--+--+ Router B +----+ +----------+ +----------+ | +----------+ | +----------+ | | | | +---+--+ +--+---+ +----+----+ | DFZ | | Host | | Control | | Host | +------+ | Device | +------+ +---------+ <---------------------- Network ----------------------> > Is "Router B" the SBR? I don't think so. If you re-read postings a little earlier in this thread, this was the second time I posted this diagram, and I asked you the very same question the first time I posted it. This is a semantic issue we have to clarify. Please refer to the exchange that I had with Mark Smith recently. It all depends if you define the site as being a geographical location, the span of the IGP of the organization, or whatever. IMHO, the site would be more or less what I call "network" in the diagram above. (I will skip for the moment the discussion about Router A or half of it being part of the site or not). On the other hand, one's reading could also be that the part that is on the right of Router B, with site-local addresses, is one site, and the left side is another site with global addresses. In this case, Router B would indeed be the SBR. The way I read the various documents out there is that there is nothing that says that a site can not have both global and site-local addresses. IMHO, the SBR here should be either the outside firewall or router A. I support the idea that a _subnet_ should not have both site-local and global addresses, not a site. Please also read what I posted earlier concerning deprecation. > In this situation, why/how would "Router B" ever route any > packets? The control device(s) will only have site-local > addresses, so they can't send packets that will be routed > by "Router B", nor can any systems to left of Router B > (outside the site?) send packets to the control devices... Here are the traffic requirements: - The Internet can have some restricted access (http only) to the DFZ, no more. - The DFZ has extremely limited access to the hosts behind the inside firewall and not at all to the control devices subnet. - The hosts between Router B and the inside firewall can access the DFZ, the Internet, and the control devices (generally speaking, as further access-lists are likely to restrict this on a per-host basis). - The control devices can talk to the subnet between Router B and the inside firewall, no more. (same here, some access-lists will limit this). > What am I missing? Nothing if Router B is the SBR, you need it to route between two sites, which is in contradiction of what site-locals do. However, if Router B is not the SBR and the site extends to what is labeled "network" on the diagram, I don't see why Router B would not route packets, because yes these packets would be routed between public and site-local, but would stay within the site. There have been several posts that suggest that the wording "site-local" is terrible, which is also my opinion. There also have been posts that suggest that a "site" is more or less the same size as the organization's IGP or the organization's administrative boundary, which is a little blurry but is one of the possible definitions. 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 Nov 3 13:58:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3Lw029028395; Sun, 3 Nov 2002 13:58:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA3Lw0Aw028394; Sun, 3 Nov 2002 13:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA3Lvv29028387 for ; Sun, 3 Nov 2002 13:57:57 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA3Lw6Mq020425 for ; Sun, 3 Nov 2002 13:58:07 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04200 for ; Sun, 3 Nov 2002 13:58:01 -0800 (PST) Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local Date: Sun, 3 Nov 2002 13:58:07 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD2CD@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: SUMMARY: RE: Limiting the Use of Site-Local X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcKDfJQndqn2uYraQN+ksBNarqN1lQAB1BVA 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 gA3Lvv29028388 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > The problems arise when a single network has both > site-local and global prefixes, resulting in nodes > that have site-local and global addresses. I fail to see what the problem is if the node is a router that has a global on one interface and a site-local one on another interface. 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 Nov 3 16:06:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA406U29028854; Sun, 3 Nov 2002 16:06:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA406UBt028853; Sun, 3 Nov 2002 16:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA406Q29028846 for ; Sun, 3 Nov 2002 16:06:26 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA406aMq001848 for ; Sun, 3 Nov 2002 16:06:36 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27801 for ; Sun, 3 Nov 2002 17:06:30 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id QAA08674; Sun, 3 Nov 2002 16:06:18 -0800 (PST) Message-Id: <5.1.0.14.2.20021103190552.030000c0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 03 Nov 2002 19:07:46 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local Cc: In-Reply-To: <2B81403386729140A3A899A8B39B04640BD2CD@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >I fail to see what the problem is if the node is a router that has a >global on one interface and a site-local one on another interface. If you have a site-border router in two sites, and the hosts in one of the sites _only_ have site-local addresses, then you don't need a router at all, as it will never forward any packets. The hosts in the site that only has site-local addresses will not be able to send any packets outside the site, and no hosts from outside the site will be able to send any packets to them. 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 Nov 3 16:19:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA40Jo29028952; Sun, 3 Nov 2002 16:19:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA40JoY5028951; Sun, 3 Nov 2002 16:19: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA40Jl29028944 for ; Sun, 3 Nov 2002 16:19:47 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA40JuMq003101 for ; Sun, 3 Nov 2002 16:19:56 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04747 for ; Sun, 3 Nov 2002 16:19:51 -0800 (PST) Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local Date: Sun, 3 Nov 2002 16:19:57 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E408@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: SUMMARY: RE: Limiting the Use of Site-Local X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcKDliO3KUP7eDAET4y2ygn6odhJZgAADUyQ 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 gA40Jl29028945 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, >> Michel Py wrote: >> I fail to see what the problem is if the node is a router >> that has a global on one interface and a site-local one >> on another interface. > Margaret Wasserman wrote: > If you have a site-border router in two sites, and the > hosts in one of the sites _only_ have site-local addresses, > then you don't need a router at all, as it will never > forward any packets. The hosts in the site that only has > site-local addresses will not be able to send any packets > outside the site, and no hosts from outside the site will > be able to send any packets to them. Which is precisely what I want, that would be Router A. However, I was referring to a router that has a global on one interface and a site-local one on another interface, such as Router B below, and both interfaces are part of the same site. Again, what is the problem with this? <-------------------- Global Addresses ----------------><-- SL addr --> +-----+ | ISP | : +--+--+ : ! : +--+---------+ +----------+ +----------+ +----------+ | Router A : +--+ Firewall +--+--+ Firewall +--+--+ Router B +---+ +------------+ +----------+ | +----------+ | +----------+ | : | | | : +---+--+ +--+---+ +----+----+ : | DFZ | | Host | | Control | : | Host | +------+ | Device | : +------+ +---------+ ---Site -->:<-------------------------- Site -------------------------> : Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 3 18:51:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA42pO29029592; Sun, 3 Nov 2002 18:51:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA42pO2e029591; Sun, 3 Nov 2002 18:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA42pK29029584 for ; Sun, 3 Nov 2002 18:51:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA42pTbB003033 for ; Sun, 3 Nov 2002 18:51:29 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12224 for ; Sun, 3 Nov 2002 19:51:24 -0700 (MST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gA42pN0T023136 for ; Sun, 3 Nov 2002 19:51:23 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id TAA04767 for ; Sun, 3 Nov 2002 19:47:32 -0700 (MST)] Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gA42pI7C008740 for ; Mon, 4 Nov 2002 13:51:18 +1100 (EST) Message-ID: <3DC5E0A6.A4681FAA@motorola.com> Date: Mon, 04 Nov 2002 13:51:18 +1100 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: Why would I use a site-local address? References: <200211011211.gA1CBP006753@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > networks with intermittent connectivity might be a valid case for use > of site-locals, though giving such networks a non-routable global prefix > would cause fewer problems for applications. [...] > the problem with the idea that site-locals should be favored over > globals is that this is exactly the wrong rule for some applications > and on some networks. as far as I can tell, address selection rules > need to be derived from a combination of application requirements > and local network policy. Agreed. But for the purpose of address selection, a non-routable global is functionally equivalent to a site local - it's an address whose scope is not the "global IPv6 internet". And as soon as we introduce addresses whose scopes are not all functionally equivalent, we have an address selection problem when multiple scopes are valid. We also need to consider whether our "site" prefixes are to be administratively or automatically configured. If administratively configured, I lease both prefix and connectivity from an ISP, install this into my top-level router / prefix distributor, and go from there. The prefix is valid regardless of whether I have connectivity or not. But what if: - I don't want (currently) to connect to an ISP? The site-local prefix provides a good default. Now, as soon as I get a real prefix I deprecate the current site local and initiate renumbering with the new prefix. But if it's illegal for the two to co-exist, I must kill ALL active internal connections at the point I make the switch. It would be nice to at least have a deprecated period on the SL. - I have a small, roving network (PAN, car, plane, ...), with the gateway latching to hotspots? My external address could change every 10-15 minutes. Internal nodes wanting external connectivity should be prepared to re-establish their connections frequently (ie long running tcp session on roving PAN is probably a bad idea). However, I don't really want every external switch to clobber my internal connectivity. A last thought: - Non-routable global prefixes cause more problems than they solve. The /advantage/ of fec0 is that it can be used in the total absence of external configuration information, and work. A NRGP requires all the configuration effort (both interfacing with an allocating authority and installation into the network) of a global with all the scoping issues of a site local. Why not just get a true global? -- 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 Nov 3 20:58:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA44wO29029938; Sun, 3 Nov 2002 20:58:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA44wOuv029937; Sun, 3 Nov 2002 20:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA44wJ29029929 for ; Sun, 3 Nov 2002 20:58:20 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA44wTbB014534 for ; Sun, 3 Nov 2002 20:58:29 -0800 (PST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01672 for ; Sun, 3 Nov 2002 21:58:23 -0700 (MST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id gA44wKx13318; Sun, 3 Nov 2002 23:58:20 -0500 Message-Id: <200211040458.gA44wKx13318@minotaur.nge.isi.edu> To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Reply-To: mankin@isi.edu Subject: Re: SUMMARY: RE: Limiting the Use of Site-Local In-reply-to: Your message of Sat, 02 Nov 2002 08:05:18 -0500. <5.1.0.14.2.20021102075349.0a566140@mail.windriver.com> Date: Sun, 03 Nov 2002 23:58:18 -0500 From: Allison Mankin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Posting only as an interested individual: > - What are the security impacts, if any, of site > local addresses. > - How important are site-local addresses as a tool to > allow site administrators to have address > independence from their ISPs, and are there > other ways to get this benefit? > - What level of impact, if any, will the widespread > use of site-local addresses have on: > - Applications (current and future) > - Transport Protocols > - Security Protocols > - Network Management Protocols > - Should site-local addresses be placed in the DNS, > and if so, how? > - What level of complexity do site-local addresses > add to router/routing protocol implementations? > - Is there a good way to limit the use of site-local > addresses (to non-globally attached networks, > special uses, etc.) that will maximize the > benefits and minimize the problems? > > Did I miss any of the big issues? Yes: What is the *overall* complexity of site-local as represented by the set of your questions and the lack of consensus about its functions shown by the 100's of messages in this thread? When we get a feature with this much divergence and impact, it tells us that we have a problematic design, and a good plan is often to give it up. Documenting the issues (your two documents) is a good way to go for doing so, that said. Also, could folks wear appropriate hats? Why did you not wear your wg chair hat in constructing the summary, Margaret? However, I am really not wearing an IESG hat here, since Transport AD has no special info about this (other than being averse to complexity as much as possible). 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 Mon Nov 4 00:16:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA48GE29000370; Mon, 4 Nov 2002 00:16:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA48GEUk000369; Mon, 4 Nov 2002 00:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA48G129000362 for ; Mon, 4 Nov 2002 00:16:11 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA48GAMq023834 for ; Mon, 4 Nov 2002 00:16:10 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03331 for ; Mon, 4 Nov 2002 01:16:01 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id AAA13256; Mon, 4 Nov 2002 00:15:45 -0800 (PST) Message-Id: <5.1.0.14.2.20021104030557.030000c0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Nov 2002 03:17:13 -0500 To: mankin@isi.edu From: Margaret Wasserman Subject: Re: SUMMARY: RE: Limiting the Use of Site-Local Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200211040458.gA44wKx13318@minotaur.nge.isi.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Allison, > > Did I miss any of the big issues? > >Yes: >What is the *overall* complexity of site-local as represented >by the set of your questions and the lack of consensus about >its functions shown by the 100's of messages in this thread? Good point. It is necessary to consider the big picture regarding the impact of site-locals on network architecture and on overall implementation complexity, not just the point-impacts on different parts of the protocol stack. >When we get a feature with this much divergence and impact, it tells >us that we have a problematic design, and a good plan is often to >give it up. Documenting the issues (your two documents) is a good >way to go for doing so, that said. Thanks. Hopefully by getting all of the issues (on both sides) on the table, we can get enough information and enough input from experts in other parts of the IETF to make the right decision. >Also, could folks wear appropriate hats? Why did you not wear your >wg chair hat in constructing the summary, Margaret? Because I think that I am a bit too close to the discussion to be sure that I can do a fair job of doing that by myself. Bob and I are working on an official WG chair message that will propose a path forward for the WG. >However, I am >really not wearing an IESG hat here, since Transport AD has >no special info about this (other than being averse to complexity >as much as possible). Actually, you could perhaps answer a couple of questions that we had about the Transport area and site-locals. Or, if you don't know the answers, could you refer us to folks who might? There is a draft which describes how SCTP could deal with IPv6 site-local unicast addresses, authored by Randall Stewart and Steve Deering. It can be found here: http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpipv6-01.txt Do you know if the Transport area WG will be considering this draft as a work item? Will it be discussed in Atlanta? Do you know if there is any work underway to determine how SIP would deal with IPv6 site-local addressing? 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 Mon Nov 4 00:19:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA48Jd29000391; Mon, 4 Nov 2002 00:19:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA48Jdr3000390; Mon, 4 Nov 2002 00:19: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA48JZ29000383 for ; Mon, 4 Nov 2002 00:19:35 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA48JibB004801 for ; Mon, 4 Nov 2002 00:19:44 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11990 for ; Mon, 4 Nov 2002 01:19:39 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id AAA14042; Mon, 4 Nov 2002 00:19:26 -0800 (PST) Message-Id: <5.1.0.14.2.20021104031740.03000d90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Nov 2002 03:20:54 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: In-Reply-To: <2B81403386729140A3A899A8B39B046405E408@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Michel, ><-------------------- Global Addresses ----------------><-- SL addr --> >+-----+ >| ISP | : >+--+--+ : > ! : >+--+---------+ +----------+ +----------+ +----------+ >| Router A : +--+ Firewall +--+--+ Firewall +--+--+ Router B +---+ >+------------+ +----------+ | +----------+ | +----------+ | > : | | | > : +---+--+ +--+---+ +----+----+ > : | DFZ | | Host | | Control | > : | Host | +------+ | Device | > : +------+ +---------+ >---Site -->:<-------------------------- Site -------------------------> > : Yes, this makes more sense... I think that this would be a perfectly legal network configuration under the current scoped addressing architecture rules, and it would result in outside hosts being unable to reach the control devices. However, I don't see that it offers any special security benefits over putting the control devices on a separate subnet of the global prefix and filtering that subnet in router A and the left-most firewall. Either way, if someone from the outside can hack into one of your DFZ hosts (by which I assume you mean servers that are accessible from the outside?), he can potentially reach your control devices. 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 Nov 4 00:37:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA48bv29000625; Mon, 4 Nov 2002 00:37:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA48bvjj000624; Mon, 4 Nov 2002 00:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA48br29000617 for ; Mon, 4 Nov 2002 00:37:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA48c2Mq000504 for ; Mon, 4 Nov 2002 00:38:02 -0800 (PST) Received: from realname ([203.254.224.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18022 for ; Mon, 4 Nov 2002 01:37:57 -0700 (MST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) id <0H5100605MUWT8@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Mon, 04 Nov 2002 17:42:32 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0H51005BZMURZX@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Mon, 04 Nov 2002 17:42:27 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTPA id <0H5100MCLMW7XS@mmp1.samsung.com> for ipng@sunroof.eng.sun.com; Mon, 04 Nov 2002 17:43:19 +0900 (KST) Date: Mon, 04 Nov 2002 17:35:03 +0900 From: Soohong Daniel Park Subject: how can i get all hosts addresses To: ipng@sunroof.eng.sun.com Message-id: <000001c283dd$11fdc510$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_98GkgLwf51giwMsexjNDjw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_98GkgLwf51giwMsexjNDjw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I'd like to get all hosts addresses in small network, can i get these addresses usign multicast ? Otherwise, do i reserve specific multicast address for this purpose ? Thank in advance -Daniel ===================================== Soohong Daniel Park Research Engineer Mobile Platform Group Digital Media R&D Center Samsung Electronics Co.,LTD TEL:+82-31-200-3728 FAX:+82-31-200-3147 H.P:+82-11-9950-4655 mailto:soohong.park@samsung.com ===================================== --Boundary_(ID_98GkgLwf51giwMsexjNDjw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT 메시지
I'd like to get all hosts addresses in small network, can i get these addresses usign multicast ?
Otherwise, do i reserve specific multicast address for this purpose ?
 
Thank in advance
 
 
-Daniel
 
 
            
=====================================
     Soohong Daniel Park
     Research Engineer
     Mobile Platform Group
     Digital Media R&D Center
     Samsung Electronics Co.,LTD
     TEL:+82-31-200-3728
     FAX:+82-31-200-3147
     H.P:+82-11-9950-4655
     mailto:soohong.park@samsung.com
=====================================
 
--Boundary_(ID_98GkgLwf51giwMsexjNDjw)-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 4 01:25:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA49P329001022; Mon, 4 Nov 2002 01:25:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA49P23n001021; Mon, 4 Nov 2002 01:25: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA49Ox29001014 for ; Mon, 4 Nov 2002 01:24:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA49P8bB011814 for ; Mon, 4 Nov 2002 01:25:08 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07398 for ; Mon, 4 Nov 2002 02:25:02 -0700 (MST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA49PSB07024 for ; Mon, 4 Nov 2002 11:25:28 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Nov 2002 11:25:00 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 11:25:00 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 11:25:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Subject: RE: Limiting the Use of Site-Local MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 4 Nov 2002 11:24:20 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKD23eAOYKJuA2/RZ+HamVADcC3lwAB7eNw To: , Cc: X-OriginalArrivalTime: 04 Nov 2002 09:25:00.0280 (UTC) FILETIME=[0C59F780:01C283E4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA49P029001015 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I must say that I have not been keeping up with all of the discussions, so if I repeat something that has been discussed already & solved / debunked, I apologize. > However, I don't see that it offers any special security benefits > over putting the control devices on a separate subnet of the global > prefix and filtering that subnet in router A and the left-most > firewall. I understand the concept that Site Locals don't really provide additional security, but there seems to still be some possible advantages with respect to privacy & management that site locals bring. For example, may service providers do wish to provide some sort of 'network-hiding' - meaning that they would like to limit the visibility of their network architecture to the outside world. There is a belief that site-locals could help with this. Additionally, some types of signaling may be completely constrained to a specific site - for example some sort of control plane signaling for radio access networks. Some providers have suggested that site locals could be interesting here. Now, I understand that using site-locals for such a mechanism may bring additional burdens, so going forward with a document listing benefits and drawbacks of site locals is the way forward in my opinion. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 4 01:56:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA49ud29001235; Mon, 4 Nov 2002 01:56:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA49udbf001234; Mon, 4 Nov 2002 01:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA49uZ29001227 for ; Mon, 4 Nov 2002 01:56:36 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA49uiMq009803 for ; Mon, 4 Nov 2002 01:56:44 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19281 for ; Mon, 4 Nov 2002 02:56:39 -0700 (MST) Received: from newton.cs.uni-bonn.de (newton.cs.uni-bonn.de [131.220.4.212]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id MAA17805; Sun, 3 Nov 2002 12:12:39 +0100 (MET) Received: (from ignatios@localhost) by newton.cs.uni-bonn.de (8.9.1a/8.9.1) id MAA16407; Sun, 3 Nov 2002 12:11:50 +0100 (CET) Date: Sun, 3 Nov 2002 12:11:50 +0100 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: Re: Default site-local behavior for routers Message-ID: <20021103121150.A16313@newton.cs.uni-bonn.de> References: <012c01c2811a$5795e7d0$237ba8c0@eagleswings> <20021031220621.C5DE57B9@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021031220621.C5DE57B9@starfruit.itojun.org>; from itojun@iijlab.net on Fri, Nov 01, 2002 at 07:06:21AM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Nov 01, 2002 at 07:06:21AM +0900, Jun-ichiro itojun Hagino wrote: > if you get a default route from three sites you are joined to, what > are you going to do? or what if you get 2001:240::/32 from both sides, > what are you going to do? Same as when you have two intra-site routers on your network. Thats a global address; which router you use is a matter of policy, cost, load sharing,=20 but surely not whether the exit point is in site* A or site* B (where site* is what the routing boundaries of site-local addresses define). What problem am I missing? Regards, -is --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPcUEdDCn4om+4LhpAQH4/gf/U3lM2CuUKmY1FbN8UMRVe5HbGs4xtgQM gIwfRC7Mqr1mVurvGY7w9zsBVywheTkmd6GE6kV8hlCzqicnzL5i22SLKiRLtlGy 5ryGXNVsK6805ZVa9XVLWQx4+5Wfc+URUlQy9VJYDn/7hqceqgjFCMaR6BbXcZ+B K7j5jg0sfmJhG78mTbVtOVHfg9kBekxPxv4qtr4xyWX8K61K3ho3OKyCQPc0sQS9 eq1KJT2sLakTAyAqt5xPRPcuezJ2p36UwQ5ErE7Sy6v9/uPns2kNQiba583lgXzw u4u2zLitmODTwom8dR2KXvHE4ggzk4jWrzsUtvtyfItlfbdC6X5RAA== =lMsg -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 4 02:48:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4AmW29001467; Mon, 4 Nov 2002 02:48:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4AmW4C001466; Mon, 4 Nov 2002 02:48:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4AmT29001459 for ; Mon, 4 Nov 2002 02:48:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4AmcMq015073 for ; Mon, 4 Nov 2002 02:48:38 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09938 for ; Mon, 4 Nov 2002 03:48:32 -0700 (MST) Received: from newton.cs.uni-bonn.de (newton.cs.uni-bonn.de [131.220.4.212]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id LAA14822; Mon, 4 Nov 2002 11:48:31 +0100 (MET) Received: (from ignatios@localhost) by newton.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA22941; Mon, 4 Nov 2002 11:48:30 +0100 (CET) Date: Mon, 4 Nov 2002 11:48:30 +0100 From: Ignatios Souvatzis To: Soohong Daniel Park Cc: ipng@sunroof.eng.sun.com Subject: Re: how can i get all hosts addresses Message-ID: <20021104114830.B21569@newton.cs.uni-bonn.de> Reply-To: ipng@sunroof.eng.sun.com References: <000001c283dd$11fdc510$b7cbdba8@daniel7209> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="CdrF4e02JqNVZeln" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000001c283dd$11fdc510$b7cbdba8@daniel7209>; from soohong.park@samsung.com on Mon, Nov 04, 2002 at 05:35:03PM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --CdrF4e02JqNVZeln Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 04, 2002 at 05:35:03PM +0900, Soohong Daniel Park wrote: > I'd like to get all hosts addresses in small network, can i get these > addresses usign multicast ? See http://www.join.uni-muenster.de/rfc/rfc2375.txt -is --CdrF4e02JqNVZeln Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPcZQfDCn4om+4LhpAQHp3gf+I8nsYxwftMPGlZ+QKWZnyf8u+ZPg3GqZ TLUqqgR289x27/BB4VYn0R/Wjch2oaAo+gGpWhd3Ra3GSWYSMvFnNsIrVsWzrfuu TCM/Dk49dO6IAzo0qUwEyytXzEQ3EGQkvl/Jo1f+zHIVrFMIZKsewBXXBdSsJ1Wk 1dKccwYVd9NN3wzdAHWbAcsD+hOeBcNkfxlyDgGEo59wzQiM+sBbFyX5wHfZKkkT 89z2HeieKPuV64sRjDVDFxMIAdVOQuJWbzIRPMbZJ2N7LpEUnL/5vmrDi6eWp5an cKELHmrunfzMTcWgvhH2vms3hCEbqgjIaok+G4VW/sNKNygqfJ+67A== =+2Rf -----END PGP SIGNATURE----- --CdrF4e02JqNVZeln-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 4 07:44:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4Fid29002299; Mon, 4 Nov 2002 07:44:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4FidAW002298; Mon, 4 Nov 2002 07:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4FiZ29002291 for ; Mon, 4 Nov 2002 07:44:35 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4FijMq026183 for ; Mon, 4 Nov 2002 07:44:45 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27243 for ; Mon, 4 Nov 2002 07:44:39 -0800 (PST) Subject: RE: Limiting the Use of Site-Local Date: Mon, 4 Nov 2002 07:44:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E40C@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKD2wyja+Y1RiWOSbGyNRrk+FnyGgAPXS8Q 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 gA4Fia29002292 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > Yes, this makes more sense... That's what it's always been, the "more" is irrelevant here > I think that this would be a perfectly legal network > configuration under the current scoped addressing > architecture rules, and it would result in outside hosts > being unable to reach the control devices. Then what was all this noise about restricting SLs to non-connected networks? This *is* a connected network. Michel. -------------------- Global Addresses ----------------><-- SL addr --> +-----+ | ISP | : +--+--+ : ! : +--+---------+ +----------+ +----------+ +----------+ | Router A : +--+ Firewall +--+--+ Firewall +--+--+ Router B +---+ +------------+ +----------+ | +----------+ | +----------+ | : | | | : +---+--+ +--+---+ +----+----+ : | DFZ | | Host | | Control | : | Host | +------+ | Device | : +------+ +---------+ ---Site -->:<-------------------------- 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 Mon Nov 4 07:57:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4Fv829002396; Mon, 4 Nov 2002 07:57:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4Fv7PW002395; Mon, 4 Nov 2002 07:57:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4Fv429002388 for ; Mon, 4 Nov 2002 07:57:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4FvDbB027799 for ; Mon, 4 Nov 2002 07:57:13 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24734 for ; Mon, 4 Nov 2002 08:57:08 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA27971; Mon, 4 Nov 2002 07:56:56 -0800 (PST) Message-Id: <5.1.0.14.2.20021104105629.0425ce30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 04 Nov 2002 10:58:21 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: In-Reply-To: <2B81403386729140A3A899A8B39B046405E40C@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > I think that this would be a perfectly legal network > > configuration under the current scoped addressing > > architecture rules, and it would result in outside hosts > > being unable to reach the control devices. > >Then what was all this noise about restricting SLs to non-connected >networks? This *is* a connected network. Because, I have been suggesting that we _change_ the scoped addressing architecture rules to restrict the use of site-locals to non-connected networks. 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 Nov 4 08:07:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4G7R29002477; Mon, 4 Nov 2002 08:07:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4G7Rw9002476; Mon, 4 Nov 2002 08:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4G7N29002469 for ; Mon, 4 Nov 2002 08:07:23 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4G7XbB000225 for ; Mon, 4 Nov 2002 08:07:33 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12849 for ; Mon, 4 Nov 2002 08:07:27 -0800 (PST) Subject: RE: Limiting the Use of Site-Local Date: Mon, 4 Nov 2002 08:07:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E40D@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKEGvqXo/d6lKuFR+615qW2xCZPFQAAMluQ 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 gA4G7O29002470 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, >> Michel Py wrote: >> Then what was all this noise about restricting SLs to >> non-connected networks? This *is* a connected network. > Margaret Wasserman wrote: > Because, I have been suggesting that we _change_ the > scoped addressing architecture rules to restrict the > use of site-locals to non-connected networks. You can certainly write a draft about it, but how many more hundreds of posts on the mailing list does it take in order for you to understand that modifying the scoped addressing architecture on that topic will not reach consensus? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 4 11:03:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4J3S29003531; Mon, 4 Nov 2002 11:03:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4J3Srd003530; Mon, 4 Nov 2002 11:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4J3P29003523 for ; Mon, 4 Nov 2002 11:03:25 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4J3YMq020532 for ; Mon, 4 Nov 2002 11:03:34 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07992 for ; Mon, 4 Nov 2002 12:03:28 -0700 (MST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA4J3FgI267256; Mon, 4 Nov 2002 14:03:15 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA4J3CPA170524; Mon, 4 Nov 2002 14:03:13 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gA4IxX526999; Mon, 4 Nov 2002 13:59:33 -0500 Message-Id: <200211041859.gA4IxX526999@rotala.raleigh.ibm.com> To: "Michel Py" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: SUMMARY: RE: Limiting the Use of Site-Local In-Reply-To: Message from "Michel Py" of "Sun, 03 Nov 2002 11:26:03 PST." <2B81403386729140A3A899A8B39B046405E402@server2000> Date: Mon, 04 Nov 2002 13:59:32 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Michel Py" writes: > There is ample evidence to support the fact that the customer (the > network administrator) wants, if not site-local, at least something that > provides what site-local does; and that they will continue using them > the way they see fit regardless of the fact that the IETF could try to > restrict their use or not. Keep the customer happy. It would be good if this WG could come to some sort of understanding/consensus of what it is that the "customer" wants per the above "something that provides what site-local does". Understanding this might well allow us to: - scope SL usage to acheive that goal (but not other things that are more complicated and less crtical), or - refute the argument that SL actually achieves this, or - provide a better solution that meets the actual needs without necessarily even using SLs. Do you have some specifics you can cite here? 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 Nov 4 11:28:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4JSR29003757; Mon, 4 Nov 2002 11:28:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4JSRoi003756; Mon, 4 Nov 2002 11:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4JSO29003749 for ; Mon, 4 Nov 2002 11:28:24 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4JSXbB028801 for ; Mon, 4 Nov 2002 11:28:33 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23204 for ; Mon, 4 Nov 2002 11:28:27 -0800 (PST) Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local Date: Mon, 4 Nov 2002 11:28:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E411@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: SUMMARY: RE: Limiting the Use of Site-Local Thread-Index: AcKENPZzrPuOtwAJT0Kl0o46i2ADIgAAO4PA From: "Michel Py" To: "Thomas Narten" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA4JSO29003750 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >> Michel Py wrote: >> There is ample evidence to support the fact that the >> customer (the network administrator) wants, if not >> site-local, at least something that provides what >> site-local does; and that they will continue using >> them the way they see fit regardless of the fact that >> the IETF could try to restrict their use or not. Keep >> the customer happy. > Thomas Narten wrote: > It would be good if this WG could come to some sort > of understanding/consensus of what it is that the > "customer" wants per the above "something that provides > what site-local does". > [snip] > - provide a better solution that meets the actual needs > without necessarily even using SLs. I believe this would be fine with many, as I can't recall anybody that supported site-locals doing it for the site-locals themselves but for what they provide, see below. > Do you have some specifics you can cite here? There are been other posts contributing this, which I agree with: - Not globally routable. - No registration. - No cost. My personal view on this is that there needs to be some ambiguity as well, for two reasons: a) Ambiguous addresses would obviously be a smaller block which in turn would be a lot easier to obtain from IANA; you know this part a lot better than I do so I'd be happy to hear your views about this. b) Ambiguous addresses are a guarantee that they will never be globally routable because the block is too small. In short, I think that if there was a /32 allocated to private addressing, that is strongly labeled "do NOT route on the public Internet", we might find that most networks administrators could not care less about site-locals. In order not to make this RFC1918-bis, we also need a mention that strongly states that these addresses are not to communicate with the public Internet in any form or fashion; read my lips: no NAT. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 4 11:29:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4JTr29003778; Mon, 4 Nov 2002 11:29:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4JTr8C003777; Mon, 4 Nov 2002 11:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4JTn29003770 for ; Mon, 4 Nov 2002 11:29:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4JTwMq029146 for ; Mon, 4 Nov 2002 11:29:58 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25103 for ; Mon, 4 Nov 2002 12:29:52 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id OAA00706; Mon, 4 Nov 2002 14:29:49 -0500 (EST) Date: Mon, 4 Nov 2002 14:29:49 -0500 (EST) From: Dan Lanciani Message-Id: <200211041929.OAA00706@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Michel Py" wrote: |I support the idea that a _subnet_ should not have both site-local and |global addresses, not a site. Please also read what I posted earlier |concerning deprecation. Could you clarify this position? Let's say I have an Ethernet segment with 20 workstations and 5 printers. I determine that two of the workstations need access to the Internet so I rent 2 global addresses from my ISP. Are you saying that at this point for all the workstations to continue using the printers I have to either: 1. Rent an additional 23 global addresses from my ISP making the entire subnet global -or- 2. Interpose a router between the 2 globally connected workstations and the remaining 18 workstations plus 5 printers, forcing the 2 globally connected workstations to use their global addresses to talk to site-locals on the printers (thus making such connections depend on the ISP). In order to change which workstations have global access I would have to move them between subnets. Or are you saying that site-local and global addresses should not appear in packets on the same subnet at all (rather than as addresses of a single machine on a subnet) in which case only #1 would work? |> In this situation, why/how would "Router B" ever route any |> packets? The control device(s) will only have site-local |> addresses, so they can't send packets that will be routed |> by "Router B", nor can any systems to left of Router B |> (outside the site?) send packets to the control devices... I believe Margaret is implying a restriction here that connections cannot be made between a site-local address and a global address. That would invalidate solution #2 above. I think that a number of constraints on site-local addresses are being bandied about without much thought as to their impact. Any one of these constraints probably makes site-locals useless for the purposes originally promised. Given subject of these messages I suppose that could be the idea, but it's going to cause a lot of confusion... 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 Nov 4 11:30:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4JUW29003799; Mon, 4 Nov 2002 11:30:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4JUW4V003798; Mon, 4 Nov 2002 11:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4JUT29003791 for ; Mon, 4 Nov 2002 11:30:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4JUcbB029992 for ; Mon, 4 Nov 2002 11:30:38 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09163 for ; Mon, 4 Nov 2002 12:30:32 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gA4JUIK09214; Mon, 4 Nov 2002 21:30:19 +0200 Date: Mon, 4 Nov 2002 21:30:18 +0200 (EET) From: Pekka Savola To: Michel Py cc: Margaret Wasserman , Subject: RE: Limiting the Use of Site-Local In-Reply-To: <2B81403386729140A3A899A8B39B046405E40D@server2000> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 4 Nov 2002, Michel Py wrote: > >> Michel Py wrote: > >> Then what was all this noise about restricting SLs to > >> non-connected networks? This *is* a connected network. > > > Margaret Wasserman wrote: > > Because, I have been suggesting that we _change_ the > > scoped addressing architecture rules to restrict the > > use of site-locals to non-connected networks. > > You can certainly write a draft about it, but how many more hundreds of > posts on the mailing list does it take in order for you to understand > that modifying the scoped addressing architecture on that topic will not > reach consensus? I don't think this is productive. Btw. I believe the rough consensus is the other way around. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 4 11:38:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4Jc529003982; Mon, 4 Nov 2002 11:38:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4Jc5oO003981; Mon, 4 Nov 2002 11:38:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4Jc129003971 for ; Mon, 4 Nov 2002 11:38:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4JcAbB002379 for ; Mon, 4 Nov 2002 11:38:10 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20265 for ; Mon, 4 Nov 2002 12:38:05 -0700 (MST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA4Jc2mo032084; Mon, 4 Nov 2002 14:38:03 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA4Jajmf187446; Mon, 4 Nov 2002 12:36:46 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gA4JWs527369; Mon, 4 Nov 2002 14:32:55 -0500 Message-Id: <200211041932.gA4JWs527369@rotala.raleigh.ibm.com> To: "Michel Py" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: SUMMARY: RE: Limiting the Use of Site-Local In-Reply-To: Message from "Michel Py" of "Mon, 04 Nov 2002 11:28:36 PST." <2B81403386729140A3A899A8B39B046405E411@server2000> Date: Mon, 04 Nov 2002 14:32:54 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There are been other posts contributing this, which I agree with: > - Not globally routable. > - No registration. > - No cost. Good start. What about globally unique? Not immediately clear one can get uniqueness without some sort of registration. But the registration might be fairly painless. > My personal view on this is that there needs to be some ambiguity as > well, for two reasons: I don't follow what you mean by "ambiguous". > a) Ambiguous addresses would obviously be a smaller block which in turn > would be a lot easier to obtain from IANA; you know this part a lot > better than I do so I'd be happy to hear your views about this. > b) Ambiguous addresses are a guarantee that they will never be globally > routable because the block is too small. Well, there are no guarantees, but if there was a chunk of address space reserved for "globally unique, but no expectation that it will ever be routed on the public internet", and it came out of a well known prefix, I'd expect that enough ISPs would filter on them to keep them from being usefully routable in a global sense. 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 Nov 4 11:44:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4Jii29004104; Mon, 4 Nov 2002 11:44:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4JiiU0004103; Mon, 4 Nov 2002 11:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4Jie29004096 for ; Mon, 4 Nov 2002 11:44:40 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4JioMq004175 for ; Mon, 4 Nov 2002 11:44:50 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03941 for ; Mon, 4 Nov 2002 11:44:44 -0800 (PST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA4JiXwg049508; Mon, 4 Nov 2002 14:44:33 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA4JhGmf222026; Mon, 4 Nov 2002 12:43:16 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gA4JdYf27429; Mon, 4 Nov 2002 14:39:34 -0500 Message-Id: <200211041939.gA4JdYf27429@rotala.raleigh.ibm.com> To: "Hesham Soliman (EAB)" cc: "'john.loughney@nokia.com'" , Adam_Machalek@nmss.com, pekkas@netcore.fi, ipng@sunroof.eng.sun.com Subject: Re: Node requirements: RFC3041 - Privacy Extensions for Address C onfiguration in IPv6 In-Reply-To: Message from "Hesham Soliman (EAB)" of "Sat, 02 Nov 2002 01:27:09 +0100." <4DA6EA82906FD511BE2F00508BCF0538044F0C69@Esealnt861.al.sw.ericsson.se> Date: Mon, 04 Nov 2002 14:39:34 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (EAB)" writes: > > > > Updating the node requirements and I came to this RFC. > > > > This RFC raised a lot > > > > of discussion during the Cellular Hosts draft - I wonder > > > > what the consensus > > > > is for the Node requirements. This could be useful for > > > > end-user hosts, > > > > > => for _stationary_ end hosts. > > > > Not sure why you say that. RFC 3041 specifically says: > > > => I took out the RFC text to make the mail shorter. > When I made that comment I meant to distinguish IPv6 > nodes from MNs based on whether they implement MIPv6 > MN functions or not. So when I said "stationary" I meant > IPv6 nodes that do not implement MN functions as described > in MIPv6. OK, though choosing to call such nodes "stationary" isn't very intuitive. My "stationary" laptop goes with me to lots of places, yet would be a good example of where temporary addresses might well be appropriate. > For those MNs, we do not yet have a mechanisms > to allow for RFC3041 type home addresses. So there would be > no point in having them for the CoA since the HoA is always > visible for traffic analysis. Specifically, I assume you mean that there is no way for an MN to use temporary addresses because there is no way for the MN to tell the HA what other addresses it is using? Also, how much of a problem is this perceived to be? 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 Nov 4 11:59:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4JxH29004414; Mon, 4 Nov 2002 11:59:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4JxHeO004413; Mon, 4 Nov 2002 11:59: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4JxD29004406 for ; Mon, 4 Nov 2002 11:59:13 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4JxMbB008718 for ; Mon, 4 Nov 2002 11:59:22 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13742 for ; Mon, 4 Nov 2002 12:59:16 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA4Jx9KV004640; Mon, 4 Nov 2002 20:59:09 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 4 Nov 2002 20:59:09 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C78@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Thomas Narten'" , "Hesham Soliman (EAB)" Cc: "'john.loughney@nokia.com'" , Adam_Machalek@nmss.com, pekkas@netcore.fi, ipng@sunroof.eng.sun.com Subject: RE: Node requirements: RFC3041 - Privacy Extensions for Address C onfiguration in IPv6 Date: Mon, 4 Nov 2002 20:59:07 +0100 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 > > => I took out the RFC text to make the mail shorter. > > When I made that comment I meant to distinguish IPv6 > > nodes from MNs based on whether they implement MIPv6 > > MN functions or not. So when I said "stationary" I meant > > IPv6 nodes that do not implement MN functions as described > > in MIPv6. > > OK, though choosing to call such nodes "stationary" isn't very > intuitive. My "stationary" laptop goes with me to lots of > places, yet > would be a good example of where temporary addresses might well be > appropriate. => ok, my point was not related to physical mobility, but topological mobility. Of course, you're saying that topological mobility does not imply session continuity and consequently does not imply MIPv6. > > For those MNs, we do not yet have a mechanisms > > to allow for RFC3041 type home addresses. So there would be > > no point in having them for the CoA since the HoA is always > > visible for traffic analysis. > > Specifically, I assume you mean that there is no way for an > MN to use > temporary addresses because there is no way for the MN to > tell the HA > what other addresses it is using? => Correct. There is no IETF _specified_ way for this yet. Of course one can think of ways of solving this problem for some scenarios but there is nothing specified today. > > Also, how much of a problem is this perceived to be? => Which problem? The fact that the mobile node cannot generate 3041 home addresses? If so, it's a significant challenge. I can think of several ways of addressing this problem but they are not free and I don't think they solve this problem for all possible scenarios. For example (not an exhaustive analysis at all): - CGAs can fix this problem. However, frequently generating PKs is computationally intensive. Also, HAs are likely to need a higher level identifier for the MN in order to offer their forwarding services. For instance, an ISP offering a HA "service" to its MNs is likely to not want every other MN to use its HA, when it hasn't paid for this service. - If a HA is configured with every possible "allocated" HoA. It might be able to accept 3041 HoAs. By "allocated" I mean that it is used to allow MNs to be reachable. But this idea will certainly need significant specification work and cannot be generalised for all scenarios. For example, how does a HA know if a MN has updated the DNS with its new 3041 HoA? What happens when the MN stops using that address? What happens if the MN goes out of coverage for a period where the binding times out and another one takes that address? Perhaps with enough restrictions and changes to existing specs these problems could be solved, but they're not trivial. 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 Mon Nov 4 12:01:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4K1729004453; Mon, 4 Nov 2002 12:01:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4K17GH004452; Mon, 4 Nov 2002 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4K1429004445 for ; Mon, 4 Nov 2002 12:01:04 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4K1DMq009414 for ; Mon, 4 Nov 2002 12:01:13 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14631 for ; Mon, 4 Nov 2002 12:01:07 -0800 (PST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA00832; Mon, 4 Nov 2002 15:01:03 -0500 (EST) Date: Mon, 4 Nov 2002 15:01:03 -0500 (EST) From: Dan Lanciani Message-Id: <200211042001.PAA00832@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Michel Py" wrote: |I believe this would be fine with many, as I can't recall anybody that |supported site-locals doing it for the site-locals themselves but for |what they provide, see below. It's more a matter of supporting scoping and address selection rules for what they provide. It doesn't matter what you call the local addresses. |In short, I think that if there was a /32 allocated to private |addressing, that is strongly labeled "do NOT route on the public |Internet", we might find that most networks administrators could not |care less about site-locals. Assuming you still provide full support for scopes then I agree with you. If you are talking about private address space without a scoping mechanism to allow seamless integration with global address space then it won't fly. |In order not to make this RFC1918-bis, we also need a mention that |strongly states that these addresses are not to communicate with the |public Internet in any form or fashion; read my lips: no NAT. Without functional scoping the only way to mix local addresses and global access will be NAT. There's no sense trying to prevent it by decree. 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 Nov 4 12:30:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4KUg29004699; Mon, 4 Nov 2002 12:30:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4KUf8S004698; Mon, 4 Nov 2002 12:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4KUc29004691 for ; Mon, 4 Nov 2002 12:30:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4KUlMq021468 for ; Mon, 4 Nov 2002 12:30:47 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15729 for ; Mon, 4 Nov 2002 13:30:41 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6F99E6A904; Mon, 4 Nov 2002 22:30:25 +0200 (EET) Message-ID: <3DC6BCC2.5040308@kolumbus.fi> Date: Mon, 04 Nov 2002 20:30:26 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten Cc: "Hesham Soliman (EAB)" , ipng@sunroof.eng.sun.com Subject: Re: Node requirements: RFC3041 - Privacy Extensions for Address C onfiguration in IPv6 References: <200211041939.gA4JdYf27429@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 Thomas Narten wrote: >>For those MNs, we do not yet have a mechanisms >>to allow for RFC3041 type home addresses. So there would be >>no point in having them for the CoA since the HoA is always >>visible for traffic analysis. > > Specifically, I assume you mean that there is no way for an MN to use > temporary addresses because there is no way for the MN to tell the HA > what other addresses it is using? The problem is figuring out if MN A has a right to register a binding at the home agent for address X. This is pretty easy if the credentials <-> home address relationship is specified statically. If you relax this requirement the matter is not so clear. Is anyone you authenticate allowed to register any binding? What if one of the MNs served by a home agent (say at an ISP) wants to take over someone else's address? Or should the home agent allow this only if there is no existing registration? But what if the attacker is the first to register all bindings after the home agent boots up? Or is it enough for the home agent to perform DAD? > Also, how much of a problem is this perceived to be? Someone could also ask what the point is in being simultaneously reachable at a known address and trying to hide one's address. There is no point, but you could still benefit from keeping your sessions alive while moving, even if your address is dynamic. Naturally you could use RFC 3041 for your communications that use the care-of address as a source address. In conclusion: its not a big problem at the moment, in my opinion. Worth solving at some point though. Its on my todo-list of future extensions for mobility... Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 4 13:43:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4Lhd29004941; Mon, 4 Nov 2002 13:43:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4LhdY3004940; Mon, 4 Nov 2002 13:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4Lha29004933 for ; Mon, 4 Nov 2002 13:43:36 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4LhjbB008639 for ; Mon, 4 Nov 2002 13:43:45 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11109 for ; Mon, 4 Nov 2002 13:43:40 -0800 (PST) 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 NAA00975 for ; Mon, 4 Nov 2002 13:43:40 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA4LhdL10938; Mon, 4 Nov 2002 13:43:39 -0800 X-mProtect: <200211042143> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.19, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhs1alg; Mon, 04 Nov 2002 13:43:37 PST Message-Id: <4.3.2.7.2.20021104133814.03173818@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Nov 2002 13:43:32 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Scoping Scoped Addresses Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please excuse the pun in the title, but I wanted to get your attention :-) [Working group chair hat on] I have been trying to make some sense of this discussion. The only obvious conclusion is that there is not a consensus in the working group on how site-local addresses should be used. Some people think that site-local is an important feature with many uses, others think they are bad and should not be used. Some think they provide security, some do not. Some thing they help with renumbering, some do not. Some thing they help avoid IPv6 NAT's, some think they encourage IPv6 NAT's. Etc., etc. The only thing that is clear is there are a significant number of people who have different views on this topic. It's doubtful that one group will convince the other group. One positive result of the discussion was that the issues and benefits are better understood. The real question for the working group is what to do next. Now that the IPv6 Address Architecture was approved as a Draft Standard and the Default Address Selection document was previously approved, we have site-local addresses in IPv6 and a set of default rules for how an implementation selects them. What we don't have is how they should be used or not-used. Even though there is no consensus on how site-local addresses should be used, I think there is enough people who want to use site-local that it is reasonable that the w.g. should continue trying to flesh out site-local usage as well as pitfalls of usage. Here is a proposal for how to proceed from here that tries to take into account both sides of the discussion. 1) Node Requirements should not require any multi-site implementations. The only site-local requirement should be limited to what is currently in the address selection rules and for routers to configure site-locals just like any other unicast prefix. Vendors are free to go beyond this in their products, but the IETF won't require it. 2) People who think the usage of site-local is harmful should write a draft titled something like "Use of Site-local Addresses Considered Harmful". The people in the other camp can comment to make sure the arguments are accurate. 3) People who want to use site-local addresses should work on completing the "IPv6 Scoped Address Architecture" document (and other docs if needed). I think a good focus for this would be to focus on the simplest cases. Topics to cover need to include site border routers, adding site-local addresses in the DNS, routing protocols, the use of firewalls to enforce site boundaries, and guidelines on how applications might want to select between global and site-local addresses. The people in the other camp can review this work and make sure the technical content is accurate. I believe this approach should help provide the larger community (e.g., vendors, ISP's, enterprise operators, etc.) the information they need to make an informed decision on the usage of site-locals. Bob p.s. I will also send out a few personal comments on site-locals in a separate email. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 4 13:49:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4LnD29005009; Mon, 4 Nov 2002 13:49:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4LnD1F005007; Mon, 4 Nov 2002 13:49: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4LnA29005000 for ; Mon, 4 Nov 2002 13:49:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4LnJMq012523 for ; Mon, 4 Nov 2002 13:49:19 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00572 for ; Mon, 4 Nov 2002 14:49:13 -0700 (MST) Subject: (ipv6) globally unique private addresses Date: Mon, 4 Nov 2002 13:49:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E413@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: (ipv6) globally unique private addresses Thread-Index: AcKEOeATVN1+aCGAQIaFgVn+LJgLBQAAE6+w From: "Michel Py" To: "Thomas Narten" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA4LnA29005001 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, > Thomas Narten wrote: > What about globally unique? This has three sides: 1. Will it appeal to the network administrators. 2. How easy can we make it for the user. 3. How many hurdles do we have to clear in order to get this going. Please allow me to develop this a little. 1. Will it appeal to the network administrators. ------------------------------------------------ > Well, there are no guarantees, but if there was a chunk > of address space reserved for "globally unique, but no > expectation that it will ever be routed on the public > internet", and it came out of a well known prefix, I'd > expect that enough ISPs would filter on them to keep > them from being usefully routable in a global sense. One of the arguments that has been used and possibly abused about this is that if it was true, we would never see 10.0.0.0/8 or 192.168.1.0/24 in the DFZ, and we do; which leads us to: > I don't follow what you mean by "ambiguous". It means everyone uses the same address, and this has a very thought property: it makes your chances of these addresses being routed properly routed over the Internet close to zero. Let's say, at a given time, 10 different sites leak 192.168.1.0 to the DFZ, including you. What are the chances of a hacker in a random location getting to "your" 192.168.1.0? Practically not much. Besides, hackers are not going to look for this. OTOH, if the private address is globally unique (not ambiguous) and it leaks to the DFZ, it immediately identifies that you screwed up your routing or have been hacked. To take the argument further, what I mentioned above is only the result of mis-configuration or hacking, and it is not the only concern, see below. > Well, there are no guarantees, but if there was a chunk > of address space reserved for "globally unique, but no > expectation that it will ever be routed on the public > internet", and it came out of a well known prefix, I'd > expect that enough ISPs would filter on them to keep > them from being usefully routable in a global sense. This can be doubted, especially in the lack of a multihoming solution. There have been ideas around about mechanisms such as embedding the ASN in the high bits of a site-local address to make it globally unique. This can of mechanism could be applied as well to this private block we are talking about. My recollection about this is that lots of people made the point that it would not take many end-sites that are lobbying for PI to pay their ISPs to leak these addresses in the defaultless table to get to a fait accompli that would have re-invented PI. Skipping the discussion about PI being bad, this would still leave us with addresses that had been intended originally to be not publicly routable but have become so, which does not fit the bill. 2. How easy can we make it for the user. ---------------------------------------- > Not immediately clear one can get uniqueness without some > sort of registration. But the registration might be fairly > painless. One has to be pragmatic and easy registration and/or low fee would not be show stoppers. At this point I do not have major concerns about this. 3. How many hurdles do we have to clear in order to get this going. ------------------------------------------------------------------- - As I mentioned before, there is a fine line between globally unique private addresses and PI, and this fine line is ISPs filtering them. Not accounting for misconfigurations, only a few end-sites paying ISPs to actively leak these as a replacement for PI might become uncontrollable and be percept as an unacceptable risk. - No matter what addressing scheme is being used, there is no way this would fit in a prefix longer than a /16, if this long. The consensual level required to get such a block allocated is high. This where I stand: With my network administrator hat on: - I do not buy the idea that a block of globally unique addresses would not be also globally routable. At least, not until I see the multihoming situation unwrap. - Even if I did, I would still prefer ambiguous addresses. - And why should I bother anyway because site-locals give me what I need today. With my IETF participant hat on: This sounds like good idea. That being said, it is going to be a long though battle no matter what, and given the fact that it is not as good as what site-locals provides to the network administrator, it is questionable if it would be worth the effort as adoption is largely unknown. Also, globally unique private addresses and ambiguous ones are not mutually incompatible, why not both? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 4 13:55:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4Ltf29005091; Mon, 4 Nov 2002 13:55:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA4LtfBT005090; Mon, 4 Nov 2002 13:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA4Ltc29005083 for ; Mon, 4 Nov 2002 13:55:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA4LtlbB012235 for ; Mon, 4 Nov 2002 13:55:47 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04726 for ; Mon, 4 Nov 2002 14:55:41 -0700 (MST) 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 NAA01622 for ; Mon, 4 Nov 2002 13:55:40 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA4LtdP26329; Mon, 4 Nov 2002 13:55:39 -0800 X-mProtect: <200211042155> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.19, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxaessF; Mon, 04 Nov 2002 13:55:37 PST Message-Id: <4.3.2.7.2.20021104134448.03173818@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Nov 2002 13:55:21 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: A few comments on Site-Local Useage Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Working group chair hat off] A few comments on the Site-Local discussion that I did not see getting discussed or proposed. There was a reference made to networking airplanes somewhere in this thread. If my memory is correct, the airplane industry did select an open standard for airlines. Some planes run ISO CLNP over FDDI. They did pick an open standard, but..... A lot of the discussion seems to imply that site-local addresses are created automatically (like link-local). This is, of course, not the case. Site-local are only created if someone configures a router with a specific site-local address on an interface and tell the router to advertise the prefix in a routing protocol to other routers and to advertise it to hosts on the link in RAs. Site-local addresses will only appear in a site if an administrator decided to configure them. It seems to me that from a reachability point of view there isn't too much difference between using site-local addresses and having a firewall that blocks traffic from one set of global addresses and another. Firewalls create limited scope addresses from global addresses. If one assumes the existence of IPv6 firewalls, then these firewalls can also enforce site boundaries. Firewalls are essentially doing this today. Compared to what firewalls already do today, this is trivial. If the site boundaries are going to be defined by firewalls, then it is probably less important that we have to define multi-site router behavior. One of the issues that was discussed regarding the ease or difficulty of configure site-local scope filters in routers. It seems to me that the simple way of doing this is configure the router with the zone that each interface is in. The router would then automatically create internal filters that enforce the site boundaries. This seems much easier to me than having to create filter rules based on the prefixes that are assigned to each interface. Another router issue that gets talked around is should packets with site-local destination be forwarded to "default". Given that site-local addresses are not created without being configured, one approach could be to have a "black hole" route for FEC0::/10 preconfigured in all routers. The router would then only forward packets with site-local to destinations that matched more specific routes. They would never get forwarded to the ISP via the normal default route. From a private exchange with someone from a router vendor. They are taking the approach of creating a "no-site" site in their product. That is if an interface configured to be in the "no-site" site, the router will not forward any packets with site-local addresses to/from this interface. This might make for a simple default behavior site border router. 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 Mon Nov 4 17:42:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA51gm29005927; Mon, 4 Nov 2002 17:42:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA51gma0005926; Mon, 4 Nov 2002 17:42:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA51gj29005919 for ; Mon, 4 Nov 2002 17:42:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA51gsMq015931 for ; Mon, 4 Nov 2002 17:42:54 -0800 (PST) Received: from rams.entangledweb.net (rams.entangledweb.net [216.15.159.226]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17402 for ; Mon, 4 Nov 2002 18:42:48 -0700 (MST) Received: from Tqlssmbwa [208.180.9.148] by rams.entangledweb.net (SMTPD32-7.06) id A1253940126; Mon, 04 Nov 2002 19:38:45 -0600 From: hinden To: ipng@sunroof.eng.sun.com Subject: NETWORK! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=UH085qC7vq0B2oTQ4599q40lCNqK2QVWD4 Message-Id: <200211041938673.SM00297@Tqlssmbwa> Date: Mon, 4 Nov 2002 19:38:54 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --UH085qC7vq0B2oTQ4599q40lCNqK2QVWD4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --UH085qC7vq0B2oTQ4599q40lCNqK2QVWD4 Content-Type: audio/x-wav; name=endspan.scr Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAASNe8Kujo6OiQt7a/s7e2v7b7t7 W40K2ptrCtqba4munrtrb7t7W42bSw4eierbqhsqe2tva9vKjasbqsuJyxvrm7tvu3tbjRub O4kLe2v7O3tr+2+7e1uNGnvaW9uJC3tr+zt7a/tvu3tbjcp7W4n6mxsLm2v7b7t7W28LO43a y6uJ6tuqGyp7a29r28qNuhu6iQt7a/s7e2v7b7t7W43Km6ur24nLG+ubu2+7e1uNq9q6C4nq 26obKntrb2vbyo1b2jubifqrXyubiptrb7t7byuKjcp7Oxp7ifqrXyubiptrb7t7byuKjRtr 63uJu3tLe2sbKttvu3tbjTs7GombW5sqG2v7X5tbmyp7a2+7e1uNS/tL27q6a9uqicqbW9pv 28vajSs7m2vKKonKm1vab9vL2o2bm1+bqmt7S8uJyptb2m/by9qNuttrm8rbicqbW9pv28va jcr7e3vLicqbW9pv28vajZu7q4nKm1vab9vL2o3rX7p7C6qbqysbicqbW9pv28vajSuq+tu6 yonKm1vab9vL2o1rX+vaazsLe9q626qJyptb2m/by9qNyxu6yptru9tf28uJyptb2m/by9qN +1/62onKm1vab9vL2o1rX7qb+srbS0vbicqbW9pv28vajVvbS5trG9uricqbW9pv28vab426 yqqby9uqicqbW9pv28vajcuKm0tb26qJyptb2m/by9qNuytb27qbifvK229r28qNm9uqe1ub usrbqonba/tv6xvab9vL2o2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjS5IiKp7+6qbW4/pG0vbukiZy3ur20iI C3vKe7oLe4qP3m+Oj0nZSIgLe8p7ukvbb8or2o3ajdu7yrvLbxrre405G8pIm4qKSNlrytuq advKb/uK+42NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY1big6Nb9sK241vuruqjW+KG+uNb6ubyo2NjY2NjY2NjY2N jY1vygrKjW8LyluNbwvKW0uNb/qbq41vm7qKjW/Le7uNb6rK641vCku6jW8rivuNb7uKio1v u41vipu6jW9bivuNb1uK2/uNb6ubO41vW4q+jW+Ky+uNjbh768r6m6rbSFkbu6p7unvrykj4 G2vLe/q6SLnaqqrba8ro26q6G3trSI2ZioqPiJvKC7qNqNprjajaa3lru9uNuBq6yttbSLna qqrba8q5e2vKqntLuNvKSLjbquobu9u6jbh768r6m6rbSFkbu6p7unvrykj4malI+Jmpzkj4 m6uP6RtL249pm1vbjajaa7jbquobu9u6jRlrytuqa9vKj7jbysoba/u6SLmbuwvbSIibygu6 jY2NjY2NjY0JG0+NCdtLS3tPjajbLo3p+i6N2GvL20sb6tuqm6tL249bmxtLX1+v37qvjajb ytqqa9vLj1ubG0tfX6/fuq+NjY2NjZuP37qP37qP+5tb242bj9+6j9+6j8p7e0uNm4/fuo/f uo/626u6G8rbjZuP37qP37qPipvKuwuN37qPqttbe+qbS4/Ke3tLuo2NjY2NjY2Na9v6jeva a2sajWsbu9uNC9pbe9qqjdsKuxvK2437e3vLjYp7+uvaS434G2sIiI0Z2Y/ub46N+L6ub9lL O9uqa4+N+L6ubzlL2ypv2Y2NC3v6j5uq248ae9qNS9vK/7qPq9uP66ob22vLuo3Lm6pLG2v7 jbp7j7t7e0uPm4/rS5u6C0/bayt7Go8byo0ae9qqj4qburr6e6rLjQt7a9sajbp7W9uPmtrb usobe2u6jYpL25u624/KqhqPm/ubG2uN+ttLu3tb24/Ke49bGo8Le1vbynv6a43KC9uP+Zuq y9trj3vrj9nL22uNG2vKqnvL2rvKG3trj3trj5nJuEmNW9vbyhtr+49re8obu9uNmtrbusob e2trmxuq2427e2v7qpvK2kubyht7a7qNunu6n40rm4qba9u624/7G6pLj+i4j4pLmxqrexqN S3t7O09bGo+r25vayhvr2kuP+xuqS4/rqhvba8uN25v726qPynuPutvbjxp72o26ihu724/7 G6pLuv+P6nu7m0uPu3tru9uqyo0rm4qba9u6249Lm7q6/4+62woaj4obu8raqtu6jY2Njbga W5trytu7jVm7m+vb243pX7jbu9qq2424e4oLe7qNyKrba8tbG7uqe405m7qK26q6OxqNjY2N 6ap7Wy6Pjch7Lo+NuNqrK9u7yi6PjY2NyAvbj+t7S0t7+htr+49bmxtLj7uba//Kj6vbj7rb a8qPynuP37oujcgL24+bysqbuwtb22vKjcgL24/rG0vbjY8buo/KC9uPe6ob+xtrm0uPW5sb S42P+xvq248ae9qPygvbj9+6jY8buo+bj9+6j8uba/vbqnvauo/qG6rauo/KC5vKj9+6jbub a48ba+vbu8qPe2uP+BtrHg5/Wdt/ro6Ojn8IiG+Nuoqq25vLj8oLqnva+wuP21ubG0tvjerb qhqPjbqK27sbm0uPjQvKyoouf3+N+vr6b41vu3tbjel7qo9be6rbjxtr63uqW5vKG3trT4pL 25u624/qG7obyo+NyAsbuo8buo+NGY/fuo8ae9qP+nvaS8uP37qPG8pvjdtrK3sajUsbO9uN +hu6C40Le4rbjdsKitu7yo2NuQuqG7rKW5u6jWnb+o8a25uqjbibG2vKj+ibS9tryhtr2/+6 j8mbGo2ZS0sLm0tLe/pbm7qNmYqqG0uP6Xt7S7r/j8mbGo1Jm8saj8mbGo2ZurraW4rKG3tr jbmba8tL21ubuo2ZS0uPuHvaS7r/yZsajdmKG4oLm2sajY2NjY0Jm4qKGo+NCZvq24+bj42N Tquqbl0tjV0tjYp7uspbm7rK26qNjY34G2s7jY0ZW5v724ibyguNWRlZ2V/o26q6G3trLo+e b45dLbl7a8rba8pfyBqK2y6PW9pLyhuKm6rKf5tLytuqa5vKG+rbPl0tHat72mvLm6oaXo25 e2vK22vKX8gaitsuj8rbCsp/C8pbSz5dLbl7a8rba8pfyKqba7rr26pf2Wu7e8sba/suj5ra e8rby1+KqhtrypurS9tdLV0tTgnIWUluTgnZmcluTn8J2ZnJbk6peckYbt+6XS1O6XlpyG6N jU5/6XlpyG5Of6l5yRhuTn8JyFlJbo2Njbl7a8rba8pfyBqK2y6P37o+XS0da5tb217ful0t uXtryttryl/Iqptruuvbql/Za7t7yxtr+y6Pq5u62+7OXS25e2vK22vKXxnJLo9O37pujY2N jY2NjY2NjZvayxt7fwpf+pvqjZvayxt7fwpfWxvLG42biopLG7ubyht7a397u8rbyl+6yqrb m1uNjY2NjY2NjY1dLU4b66qbW9uPuqq7Xr7JuxvLLt+6jwvbG/sLyl6+yY6P+hvLygtevsmO bl0tTn8b66qbW9tujcgLG7qP+5tb248buo9bGo/rG6q6yo/6e6o7b06rqm5dLRh72v+q24/K C9uP6xuqusqPikubGtuqb415GbmYjYiqe/uqm1vpG0vbuskbqo2NjY26W8qKb414meiIvq6N eJnoiLm5jWl5yb6ujWmIuLjouY1pqNm4mL6ujWm4uQnZyb6ujWm4uQnZyWnIjWm4iEnY+Rlp jWmZ6I1pmeiZiLjouY1pmeiZiPi+ro1pmehJ2L6ujWmZ6KjYaaiNaZno+L6ujXiZ6IhZjZlJ 2ajIuOi5jZlZeWmNmeiIvq6NmeiIubmNmeiIWY1pvq64uZlp+I1pmej4aciNmWnIGegZqI2Z 6IjYiMmNmej5ucioSY2Z6PgZaR7ejbi5mWm+ro3ouAn4GWm+ro3pX7jIeYj4jelfiKh5yB7e jZm5OfgZab6ujejZyMiomRiN6NnIHt6NuPjZ2Yge3o2Iubn4GWkeDo0ZeVl5aR4OjZnoiMi5 jZno2b6ujZnouXlpuHlJjemIX/gZaY3J6Ige3o3pX5n5acge3o25SZn4Ht6Naei5Ht6NuLmZ aY3oGajYuI1Jebk5yXn4aa6Ojo6NaXuqyntrjVm7m+vb242Za8ob6huqjciZuDlZ+aiNjY2N jY2NjY2NjY2NjY2NjY2NmWnIGV/oGahvyZnIjbkJOUkZuMhvyZnIjbkJOUkZuMhvWbiNuQk5 SRm4yG+5iLiNuQk5SRm4yG/ImeiNGeipb2nIKI24WZmoyLkJOW9ZuI24WZmoyLkJOW+5iLiN mej5mMhvyZnIjZn52JmoyW/JmciNjY2NjY2NuAtL+puKG2/LS0uNOduqa9tLvq5vy0tLjWvb ypuKG76ub8tLS42667tvy0tLjY2NjY24G6q7m1uNaRtby5uNuXvL26jby434mDlZWb4O/g6N +agZ2em+Dv4Ojenaa49Je+oba/uPuaobWxtrm0uNaXuqyntrjVm7m+vb242Za8ob6huqjZnq u3truntLjelfuMh5iPiN6V+427vaqtuNuHuKC3u6jeobqtq6jZnoiI9Ze2sbynuqjZnoiI/Y isubytu6jRlre7vaS5vK2xnIjYi5X7sbS0sba424Gluba8rbu43Iqttry49ZG7uqe43pX4io eciNj2l5yb6uj42Njajb+xu6ytuquNuq6hu724iqe7vburqNadvKuAubqtuZy8uNuAnJ20vb yts52xqZjbjruxm66RtL24iqe8rbu8rby41p28q4C5uq2/nbyhlr63uNadvKmYobqdrr69uq 6arb242NjY2N2QiISXmo2aiNuVlZ+aiNW7obW2uNG7v6u3tra436G2sqG4qNjY2NjYiqe/uq m1uN37qPTt+6bo2ZqbnJ2en5CRkpOUlZaXmImKi4yNjo+AgYKJuru8vb6/sLGys7S1tre4qa qrrK2ur6Choqjp6uvs7e7v4OHj9/jbrbytqKjRtrusqbS0uNy9tbe426a3t7ihqNihu7m7va jTsbysoajYpLmxqNqnu7O42NjY2NjY2NqJuqnyz9jXGEuo2NXY2NjY2NjY2NjW+qm6qNjfob axtr28pvy0tLjRlrytuqa9vK+dvKuXtra9u7ytvLuMqbytuNjY3JG6rbu8p7qhqNy0tLu5u7 C9uNjbjbydur2vuIqhvqG0vb+9uNuNvIu6uIqhvqG0vb+9uNjY2NjY2NjY36q18rm4qba2+7 e28rio3q26obKntrb2vbyo2bqpraG6rby2/buo3LG+ubu2+7e1uNjbh768r6m6rbSFkbu6p7 unvrykgZa8rbqmvbyo+Zu7t72mvKj1mba5v726pImbu7e9pryrpIjbhZyIiPuNuq6tuqjbhZ yIiP2VubG0uPmcvLqtu6uo2N+HuqW485S9sqb9mPG1tb2msbyhqNjTlL2ypv2Y8buo/KC9uP W3u6yo+7e1tbe2uP+nuqS8tf+hvL24+6iqrbm8sba/uP+nuqW28Zyv+6j+rbqhqPy5tr+9uq e9q6j6saj7t7qqraisoba/uPGnvaqo/rG0vbum9Oq6puXS2p27ub2rrbj3vrjxvKuo/q26oa j7pbm6rKj7rK25tLyguPm2vLj5tryhtfm2vKG1/qG6rauo/K27sLaxu7T1t7usqPu3tbW3tr j5noj7p768r6m6rbj7uba//Kj8vbytu7yo97qo+7S9uba48bym9Oq6puXS3424/L2+rbS3uK 28uPygsbuo/rqtvbjxtbW9prG8oaj8p7e0uPynuPy9vr25vKj8oL249bm0sbuxt72rqP6huq 2rpvTquqbl0tGHvaj3trSxqPa9vby4/Ke4+q2muPygsbuo/Ke3tLj3tru9tPm2vLj8oL22uP OUvbKo/6G0tLj2vb6tuqj7t7W9uPG2vKe48ae9qqj4i5b06rqm5dLWl5yNkuj6nbu5vautuP ygsbuo/Ke3tLj5u7yrqPm7qPm4/rmzvbjzlL2yqPynuP63t7S4/KC9uPqtubS4/6e6pbT7p7 W9uPmeiPW3trG8p7qo9bmxqr24+7qhqP+gvba48ae9qPqtprjxvKb06rqm5dLRnrj7p7Txn7 a3uq24/KC9uP+puqaxtr+0+ba8uPuttL27vKj/+7e2vKG2va2/9vTquqbl0tGeuPGnvajwub 6tuPm2saj5ra27rKG3trT4pL25u6249Om48LqtvrXr7JW5sbS8p7Lt+6blubG0uPynuPW9tO f5tub42NjY2NjY2NXS34G2u+ro85S9sqj+iub46ej++P+Btrvq6P6Xuqe9oKj+ieb45dLbl7 ihqqG/sLyo+ujo6uT1uby9uPG2uPmbobm10tmat72sqPOUvbKo/orm+Oni5dLR2eT1mbG2uP Wxu6uht7a48buo/Ke4+q20vbm7rbj8oL249r2/qPq5urGo+I2Y/qG6rauk/4G2u+ro/pe6p7 2gpdLR2uT2l7j7ob+2sb6xu7m2vKj7sLm2v7229pe4+r2vuP6xsK28tvaXuPm2saj4qbGkt7 m8tvXS2Zq3vayo/4G2u+ro/pe6p72gqPD4pLKo8729uKj8oL249rm1vbT8oLm2sKH10tHZ5P 6dpLS4+7e1uKm8obq0vbj/gba76uj4jZj+obqtq6j3trj/gbax4If645f2nIfwiIXS0drk/4 G8oLj+rbqhqPG2vK26rbusoba/uP69ubytqq22+5C9u7O48byp9dLR2+T2l7j5trGo+KmxpL e5vLb2l7j5trGo97isobWxsqm8obe2tdLR3OT2l7yo+r2vuP66rb20+r27ub2rrbj3vrj5uP C9qqqhqP+nuqO29pe49be6rbj8oLm2uPyguq29uP+tvbO7qP66p7W48Lm+oba/uPutq7C48b y9ubj8p7j5u7u3tbiksbugsba/uPu3vLG2v7j5try4/K27rKG2v7XS2NAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwAAACAAAIAOAAAAQAAAgAAAAAAAAAAAAAAAAAAAAgABAAAA WAAAgAIAAABwAACAAAAAAAAAAAAAAAAAAAABAGUAAACIAACAAAAAAAAAAAAAAAAAAAABAAQI AACgAAAAAAAAAAAAAAAAAAAAAAABAAQIAACwAAAAAAAAAAAAAAAAAAAAAAABAAQIAADAAAAA 0FAJAOgCAAAAAAAAAAAAALhTCQAoAQAAAAAAAAAAAADgVAkAIgAAAAAAAAAAAAAAKAAAACAA AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL8AAL8AAAC/vwC/AAAA vwC/AL+/AADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd3gzqgAAAAAAAAAAAAAHf3d4M6p3gAAAAAAAAAAP9/d3eDOqd8hgAAAA AAAA//9/d3gzqnjGZgAAAAAAD///93d4OKd8hmZgAAAAAHf//393eDenjGZmdwAAAAeHf//3 93g3p8hmZ3dwAAAIeHf//3d4OqjGZnd34AAAh4eHf//3eDqshmd37u4AAHh4eHf/f3g6jGZ3 7u67AAeHh4eHf/d4Oshnfuu7uqAIeHh4eHf4iIjGfru7qqqgB4eHh4eHiAAAiLu6qqMzMAh4 eHh4eICP+AgzMzPd3dAIiIiIiIiA//8IXV1dXV1QBdXV1dXVgP//CIiIiIiIgA3d3TMzM4CP +AiHh4eHh4ADMzqqq7uIAACIeHh4eHhwCqqqu7vnbIiIj3eHh4eHgAqru77ndoyjh3/3eHh4 eHAAu+7ud2bIo4f3/3eHh4cAAO7ud3ZoyqOHf//3eHh4AAAOd3dmbIqjh3f//3eHgAAAB3d2 Zox6c4d/f//3eHAAAAB3ZmbIenOHd/f//3cAAAAABmZox3qDh3d////wAAAAAABmbIeqM4d3 9///AAAAAAAABox3qjOHd39/8AAAAAAAAAAId6ozh3f3cAAAAAAAAAAAAACqM4d3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAP/wD///gAH//gAAf/wAAD/4AAAf8AAAD+AAAAfAAAADwAAAA4AA AAGAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAGAAAAB wAAAA8AAAAPgAAAH8AAAD/gAAB/8AAA//gAAf/+AAf//8A//KAAAABAAAAAgAAAAAQAEAAAA AADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAACIc6gAAAAA/4hzLM YAAACPiHMsZoAACHj4csZoYACHh4hyxoqqAHh4dwCCqiIAh4eA/wERVQBVERD/CHh4ACKqKA CHh4cAqqhsJ4h4eAAGhmwnj4eAAAhmwjeI+IAAAGzCN4j/AAAAAIo3iAAAAAAAAAAAAAAPgf AADgBwAAwAMAAIABAACAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAIABAADAAwAA 4AcAAPgfAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA yAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABpWE2eLTkjzS05I80tOSPNLTkizSM5I831JjDNKzkjzas+Jc0sOSPN LTkjzSw5I81SaWNoLTkjzQAAAAAAAAAAAAAAAAAAAABQRQAATAEFAPehIDcAAAAAbwAAAOAA BiMLAQUMABAAAABAAAAAAAAAlyIAAAAgAAAAMAAAAADKegAQAAAAEAAABQAAAAUAAAAEAAAA AAAAAABwAAAAIAAAdlMBAAIAAAAAAAQAABAAAAAAEAAAEAAAAAAAABAAAADQJgAAXQAAADgl AAA8AAAAAFAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAGAAALQAAABAIAAAOAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAQAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAC50ZXh0AAAALQcAAAAgAAAAEAAAACAAAAAAAAAAAAAAAAAAACAAAGAuZGF0 YQAAACwAAAAAMAAAABAAAAAwAAAAAAAAAAAAAAAAAABAAADALnNocmRhdGEYAAAAAEAAAAAQ AAAAQAAAAAAAAAAAAAAAAAAAQAAA0C5yc3JjAAAAAAQAAABQAAAAEAAAAFAAAAAAAAAAAAAA AAAAAEAAAEAucmVsb2MAAO4AAAAAYAAAABAAAABgAAAAAAAAAAAAAAAAAABAAABCAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA --UH085qC7vq0B2oTQ4599q40lCNqK2QVWD4 --UH085qC7vq0B2oTQ4599q40lCNqK2QVWD4 Content-Type: application/octet-stream; name=ericawhitesmall[1].jpg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAICAgICAQICAgIDAgIDAwYEAwMDAwcFBQQGCAcJ CAgHCAgJCg0LCQoMCggICw8LDA0ODg8OCQsQERAOEQ0ODg7/2wBDAQIDAwMDAwcEBAcOCQgJ Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg7/wAAR CAA5AHYDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9+9wo3CmUhYCgCTcKNwqPIpSQBnPFAD9w o3CmUUAP3CjcKZSZHrQBJuFG4UyigB+4UbhTKKAH7hRuFMooAfuFG4UyigBCwUEngfzr4Ovv 2hfiv8X76SX4BW2heCvhkWdLL4g+LtLn1GfXSAw36fpaSwf6MWA23U8w3gMUhZSrtwP/AAUD 8c3Wt+MvgT+yvp969hY/FDWp7vxhNHcmB5dE05RcXFmHV1ZTc4KZB5CMvO7B+m/Cc3gTwD8H R448e69ong3w7BEI4bvV72GysrWJVCoitIQoAC/KAR09egB8k/FPxF+2N8Hvg/4v+Lej/Hyy 8f6V4e0y51fUvDXir4f2VvaSwQqZXjgubIRSxHarIvmNKSduWByT7z8Cf2zPBnxU/wCCf2m/ HXxJp134WtVsZJdW06ys59SngkineCURRQI0sy7oywKoTs+ZguGC8b8S/wBuH9h/xXosvwq1 vx5afFAeI3TT4dA0HwzqGtR6pK8gRLeM29u8csjOUHlqxY7l4+YZ84+F3xGt9U0LUfC/7P8A 8FNc8D+HJ7Y2lt4m8YaLDpGl2cRGCbXTizXFyyhsLG0UUTFDmRRjcAfpT4X8W+G/GvgTSPE/ hXWLfXPD+qWUV7p99bNmO4glQPHIvfDKwIzjg10Wa/PGz/aJ+B/7KPxa+E3wA8VS6n4VsdX0 RLPw9dSWMzaZYRQeXBbwy3UpJZm+7kM5TaDKVEis3v3xB/aDn0DTmPwv+Ges/HC+t72Wz1VN B1TT7KDTJY0icxyzXk8Qd2EwAWESEMjq+xgAQD6PyOOK+Qfgr+2d8Nfjh+0j8XvhloGia/oW s/D7Wjpd/cavbxJDeyCaeAtDskZgN9u5xIFOCpxnIXT+AX7Xfw0+PXw+8V6xY2upeB9U8K38 2n+KdI8RrFFNpdxAuZQzo7o0Yw+HB5CnIUgiqPgL4ifBz4rftDeLz4PaebUNGbTbiXUhFGtv qkeo2Md/bTQMHLOGt54myyqfnAwSCoAProEEAjpRmqt3e2Wm6LdahqF1Fp+n2sLTXNzcyCOO GNAWZ3YkBVABJJ4AGa+ddK/aIHjWWG7+GPgHUvFPhOYqbPxXqd7HpemagpdkMlsGD3M0QChh L5AjkVlaJ5AaAPpPIzjvS14b4Z+Ovh3WPjTefDvX9I1HwT4x3XM2lWWqiNk1qyhaNWvbWWJ2 R0zMoaNisyHl41VkZu88ZeP9B8EW+gJqXn32qa7qQ07Q9LsghudRuPKeZo497Kg2wxTSszMq hI2OegIB2pIH1pa+aPFf7Q1z4E8GXfirxL8M9Z1TwlA4abUvCF5Bq7WcChzJcXEGYpNqbQCL dbhuScAKTXt3g/xp4b8eeANG8UeFtSTU9F1Wwgv7C4VWXzreeJZYZAGAIDxujjI6MD3oA6mi iigD8sv21PDuu/8ADevwu+KFv4D1zxLpfgnwrdGw1dPHUVlo9je3wurdbebTzYTzPJcuttAL mKZQhkiaVRHCWa74W/ZptfjLpXhjxR8aRH8ZfFFpZPHZjW7UDQ9FjlZWlisdPyYlBaNMzTCS dgqqZNqoq/TP7Vvhyym+BFn8QLnwndeOD4IvBrLaHYziKe9jiYSsiN5bnrGjMAhZlVgMMQRh /sh/tHfCf48fA57/AOG+oSLBa3DRTabqUaQ6haYPyieNXYKxUA5VmU54Y4NAHUeGf2avDHhz TrW10y107QLSCNY4bbSNOjt44kUYCqFUAADgDoB0FesaN8N/D2jyBwkl3IOczMcHv0z2r0Is BmvD9f8AjHa6B+2ro/wnnt7a5F/4Rn1wzxz/AL+0MVykIEif885N/wArcYaMjndlQD4//wCC sPhTQ9U/4IzeONavLOCS+0DU9LudLZ4wTBJJfw27NGcfKximkXqPlZh3wfQv2TvBem3n7Ltn oMV9f3GhQ2KiyuZGMF3IsqbjO+HcrM5cyMfMf5yx3P1Paftv2Gi63/wS/wDiHFrthbarozR2 lxNZ3hdYpxHcxSBHKMrAEqASrK3PBBwaf+yLB9m/Z30UEghtGsz8vPWGP/GgBPhT+zRpvwr+ IN7daFqmvXljPeT3ck2u65PqEzPPPLcSYaVjtVpriaUqoCmSWRyNzuW+O/2WfhXrnw7/AGzP jdPq2j3Wnrr/AMVNYv7O9SZZLDUrV7lzD5BRdrMgysqhiUc+U6RyRup/XwsBmvyb/Z6+Jutf En9uv403OoWF1aab4a+IN94U0+RoLdLV1s7y6lcQ+RbxDP8ApSyOJGmlMkrO0m2RY0APeP20 Z/8AhLb34SfBKbUpLTQvFPiAXniOzidV/tSyska6NlJkcwymFhIBjKjHQkVX+O3hr4wL/wAE 99e174L21tf+P7e4triLSJ4k2X+nxuPtFpGHBVWeEEBuGX+BkYKw+df+Ck+r638Jf2vv2Vv2 g5o7qf4e6Hf3+j+IzbqzLatdQmOOVlUHP7uS5I90AAJIr9Nvhf4g0bxh8BtA1TSru31PTLqz WSOWGQSJKp+YMCMgg7gRj2oA/Jfw58Uvjn8eP2wPhddeNPgLYfBLRPA162tCebU/7S1PULq6 0yW2jtopEVFhi8u83zxshYSQpGxR0ZV+/P2itE0aX9i+0+IHivxBqfhLUPAEF1r9lrmmWs11 Ppkp0+6tXuRbx/67y4LmV9rgx5XMgaMOrfQC+CPCVl4gGpjToYryRgodsAlieg+v+cV8m/tm 6jerqHwI8H2Gg33iy38UeOLawn0GwtmmF0sNxBepM4UhlW1ltIrpiCB5dvLvJjEiOAfPvwU8 c/HLS/DF34csvh1L4+8O6Vc3H2XxH8TfG91p2t+IIWkdlmhtV0+U2iFSqxW8/wBnKLsRkjCt jh/gD4vv/hV/wUY8a6do/hDxH8Nfht4smtrnUPB/iCK3WPQfEM8dxMiWbwyNHcwXdtYX05kg MiI1rtcozBB+mXwm8NaBd/DO31aVI9UuLo7zK7bwRgEd+evX/J+AP28p/h14b/b8/Y3ke6st D8Sr4lvo57traWRYLe4tjDFDIYkco1xPiOPcApZHZiqJI6gH6zWlwl3psFzGQySIGBHfNWK4 n4d339ofCHR5924CILn1x/8ArrtqAIpoUntpIZFDRupVh6g1+W/xZ/4J62Np8f774wfs9eM9 c+B/j65kea5uPDLg2dzK2DumtG+R1yMlFKKxJJBY5r9TaKAPzStfD37aEtpZ6HqP7S8mnabF aQR3d5a/DWwbVp5FiUTOs7ZgjEkodgDbsURgu5mBlPqfwd/Zts/CHifVPENxdax4h8UazIkv iDxX4mvmvNV1V0GE8yRuEjUZCQxqkSZO1Rk19on/AI/DVmgDwP8AaC+Dtt8aP2YtX+Gupare af4Z1G0kg1C3sFVZpzs/cMsv3ozFKFmAXh2jVXDxmSN8b9nD4c+Ivhj8LbXwvrmsXXiA2dul vFf3sCRzyxoAqb9gClgoAJAGcA4zzX0rRQBWu47iTS7qO0uBa3TxMsMxjD+WxHyttPXB5xX5 3/Cn9kzWfg/+03qfiXTPG+seKNP1S6mvdUOq6Pp0Ml5dzXMt1JcyS2ltCXkaS4lG59xCeXGC qRRov6M0UAeb/FH4YeEPjH8CtZ8BePNEttf8PapCFubO6jBUsCGVh3VlYBlYEFSAQcivyfsf 2Kv2j/2fdVvdK/Zy/aW8TeAvAs9y80ejX2iwazBblmLfuxKQq8k5wmSeSSea/aio5f8AUtQB 8FfAn4WfFfR/HS+KPiT8T/FnxX8WyW4hbUNZZbOxtF6t9msYQIoSx5LEM5HG7FfTfxj+EWg/ Gb9nXWvAPiYTra31nNAt1ZXDQXVv5sLwSGKVTlS8UssTAcPHLJGwZHZW9aj+6akoA/GjRv2Z P2xvhR4huNB8H/tf+MIfBU+oPNLDqHhq21W+KO258XdwznzGLP8AMEAUnO08ivSPHX7EcvxS +EnhK11LxZ4oTXtG8RR+IrnxHf3a3mq6vqMcYjjmuZZlYFUUYWJFRFUKiLGoxX6lS/wf71Sj oKAPO/hhompeHvhZZ6VqchluIQAXK7dxxg8fhXolFFAH/9=9 --UH085qC7vq0B2oTQ4599q40lCNqK2QVWD4-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 4 20:02:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA542M29007215; Mon, 4 Nov 2002 20:02:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA542Muc007214; Mon, 4 Nov 2002 20:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA542I29007207 for ; Mon, 4 Nov 2002 20:02:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA542SbB008076 for ; Mon, 4 Nov 2002 20:02:28 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA05302 for ; Mon, 4 Nov 2002 20:02:22 -0800 (PST) Subject: RE: (ipv6) globally unique private addresses Date: Mon, 4 Nov 2002 20:02:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E415@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: (ipv6) globally unique private addresses Thread-Index: AcKEO+kwpORio5JOSX+QB4eA2tb/IAALMNYg From: "Michel Py" To: "Dan Lanciani" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA542J29007208 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, > Dan Lanciani wrote: > Let's say I have an Ethernet segment with 20 workstations > and 5 printers. I determine that two of the workstations > need access to the Internet so I rent 2 global addresses > from my ISP. Are you saying that at this point for all > the workstations to continue using the printers I have to > either: > 1. Rent an additional 23 global addresses from my ISP > making the entire subnet global -or- > 2. Interpose a router between the 2 globally connected > workstations and the remaining 18 workstations plus 5 > printers, forcing the 2 globally connected workstations > to use their global addresses to talk to site-locals on > the printers (thus making such connections depend on the > ISP). In order to change which workstations have global > access I would have to move them between subnets. Either one. I don't see what your problem is with 1, because the smallest you can get is a /64 anyway, which is enough for more printers and workstations than you will ever have. The problem you have with 2 is that you want PI, like everyone else, which is quite another animal. > Or are you saying that site-local and global addresses > should not appear in packets on the same subnet at all > (rather than as addresses of a single machine on a > subnet) in which case only #1 would work? I don't see the difference? Subnet is a poor choice of words, let's say vlan, or Ethernet segment instead, sorry about the confusion. > I believe Margaret is implying a restriction here that > connections cannot be made between a site-local address > and a global address. That would invalidate solution #2 above. There is no such restriction. I'm afraid the design that allows both a public and a site-local on the same host (or at least on the same interface) is going to be scrapped and here are the reasons: 1. The developers are whining about it. 2. From an enterprise perspective, it's a draw. Yes it does save router ports but the other side of this coin is that administering several address ranges on the same vlan is an administrative overhead and nullifies most of the perks of site-locals in terms of security. So, it's a tosser on the network admin side; if it was without consequences I would have elected to keep it, but if the developers want to scrap it, so be it as far as I'm concerned. >> I believe this would be fine with many, as I can't recall >> anybody that supported site-locals doing it for the >> site-locals themselves but for what they provide, see below. > It's more a matter of supporting scoping and address selection > rules for what they provide. It doesn't matter what you call > the local addresses. OTOH, I'd rather have a block of private addresses without scoping than SLs with scoping that does not work. If the developers don't want or can't deliver scoping with SL, I need a backup plan and since there appears to be some momentum for it I'll take it. Of course, this would lead to networks that are using non-scoped private addresses, but the one thing network administrators do not like is uncertainty. That being said, my choice is still to keep SLs and scoping, but let me make sure that everyone understands that I do not design a network with promises, I design a network with what I have tested to be working. As of today the only thing I have to design a network that requires private addresses is a prefix hijack that obviously is not scoped, since there is some uncertainty in what would be available as far as SLs are concerned. In this light, a private /32 clearly labeled as not publicly routable would be an enhancement. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 4 20:47:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA54lT29007369; Mon, 4 Nov 2002 20:47:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA54lTOG007368; Mon, 4 Nov 2002 20:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA54lP29007361 for ; Mon, 4 Nov 2002 20:47:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA54lZMq019215 for ; Mon, 4 Nov 2002 20:47:35 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29239 for ; Mon, 4 Nov 2002 21:47:28 -0700 (MST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA54l0O28951 for ; Tue, 5 Nov 2002 06:47:01 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Nov 2002 06:47:26 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 06:47:26 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 06:47:25 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 06:47:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Node requirements: RFC3041 - Privacy Extensions for Address C onfiguration in IPv6 Date: Tue, 5 Nov 2002 06:47:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node requirements: RFC3041 - Privacy Extensions for Address C onfiguration in IPv6 Thread-Index: AcKEOqPWnWWjqqfMS+WJzOWqxPIYdwAS5c1Q To: Cc: X-OriginalArrivalTime: 05 Nov 2002 04:47:24.0950 (UTC) FILETIME=[6F6A0B60:01C28486] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA54lQ29007362 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, With regards to 3041, the Node Requirements have a MAY requirement. We should add text, to better capture this, though. Mobile Nodes, Servers, etc. may have different requirements, but how to quantify this? So, I'd respectfully ask someone to submit text to cover this. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 4 21:18:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA55IC29007559; Mon, 4 Nov 2002 21:18:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA55IBLZ007558; Mon, 4 Nov 2002 21:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA55I829007551 for ; Mon, 4 Nov 2002 21:18:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA55IIMq023018 for ; Mon, 4 Nov 2002 21:18:18 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA22901 for ; Mon, 4 Nov 2002 22:18:10 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id AAA02106 for ipng@sunroof.eng.sun.com; Tue, 5 Nov 2002 00:18:09 -0500 (EST) Date: Tue, 5 Nov 2002 00:18:09 -0500 (EST) From: Dan Lanciani Message-Id: <200211050518.AAA02106@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: (ipv6) globally unique private addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Michel Py" wrote: |> Dan Lanciani wrote: |> Let's say I have an Ethernet segment with 20 workstations |> and 5 printers. I determine that two of the workstations |> need access to the Internet so I rent 2 global addresses |> from my ISP. Are you saying that at this point for all |> the workstations to continue using the printers I have to |> either: |> 1. Rent an additional 23 global addresses from my ISP |> making the entire subnet global -or- |> 2. Interpose a router between the 2 globally connected |> workstations and the remaining 18 workstations plus 5 |> printers, forcing the 2 globally connected workstations |> to use their global addresses to talk to site-locals on |> the printers (thus making such connections depend on the |> ISP). In order to change which workstations have global |> access I would have to move them between subnets. | |Either one. So your position is that I must do one of those two rather than using site-local addresses on the one segment along with the two globals? I believe that this restriction renders site-locals useless for many applications. I would be forced to opt for NAT. |I don't see what your problem is with 1, because the |smallest you can get is a /64 anyway, which is enough for more printers |and workstations than you will ever have. There seems to be a persistent notion that ISPs are going to change their business models just because the IP header version field increases by 2. I don't buy it. Show me proof. |The problem you have with 2 is that you want PI, like everyone else, |which is quite another animal. Huh? The problem I have with #2 is that it requires me to add a router and further requires me to rewire (even if only virtually with VLANs) just to shift who has global access. It has absolutely nothing to do with provider-independent routable address space. |> Or are you saying that site-local and global addresses |> should not appear in packets on the same subnet at all |> (rather than as addresses of a single machine on a |> subnet) in which case only #1 would work? | |I don't see the difference? There is a huge difference. If you ban packets with global addresses from your site-local subnet then the site-local machines (obviously) can't talk to globally-connected machines via their global addresses. In my example, this makes #2 impossible. |Subnet is a poor choice of words, let's say |vlan, or Ethernet segment instead, sorry about the confusion. No confusion, that's the subnet I thought you meant. |> I believe Margaret is implying a restriction here that |> connections cannot be made between a site-local address |> and a global address. That would invalidate solution #2 above. | |There is no such restriction. There's no restriction on having site-locals and globals on one subnet either, but we seem to be talking about adopting one or more of these restrictions. |I'm afraid the design that allows both a public and a site-local on the |same host (or at least on the same interface) is going to be scrapped |and here are the reasons: |1. The developers are whining about it. That isn't clear. |2. From an enterprise perspective, it's a draw. Yes it does save router |ports It also provides stable, local addresses even to machines that require global access. Which is where I came in... |but the other side of this coin is that administering several |address ranges on the same vlan is an administrative overhead Any particular administration is free to not take advantage of site-locals and thus not incur this overhead. |and |nullifies most of the perks of site-locals in terms of security. Any particular administration is free to not configure globals and site-locals on the same interface if it believes that there is a security issue. |So, it's a tosser on the network admin side; if it was without |consequences I would have elected to keep it, but if the developers want |to scrap it, so be it as far as I'm concerned. I cannot support your position. This restricted version of site-locals may have some marginal security benefit, but it fails to deliver on the original promise of flexible scoping. It will just cause confusion for administrators who will think they can control their address allocations... until they actually try to do it. If it comes down to a choice between crippled site-locals and no site-locals I am forced to vote for no site-locals. 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 Nov 4 21:33:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA55X529007664; Mon, 4 Nov 2002 21:33:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA55X5Kc007663; Mon, 4 Nov 2002 21:33: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA55X129007656 for ; Mon, 4 Nov 2002 21:33:02 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA55XBbB019390 for ; Mon, 4 Nov 2002 21:33:11 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA22826 for ; Mon, 4 Nov 2002 22:33:05 -0700 (MST) 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 VAA22441 for ; Mon, 4 Nov 2002 21:33:05 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA55X4R02024; Mon, 4 Nov 2002 21:33:04 -0800 X-mProtect: <200211050533> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (216.83.56.167, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdoOBZIR; Mon, 04 Nov 2002 21:33:02 PST Message-Id: <4.3.2.7.2.20021104153006.026c6b38@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Nov 2002 21:32:56 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Atlanta IETF IPv6 Agenda Planning Cc: hinden@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 The IPv6 working group has two session at the Atlanta IETF meeting. They are: MONDAY, November 18, 2002, 1930-2200 (Salon III) THURSDAY, November 21, 2002, 0900-1130 (Salon III) There are several topics that we feel are important to devote significant meeting time on. These are: - DNS Discovery - Flow Label - MIB Updates - Node Requirements - Prefix Delegation - Site-Local Usage / Scoped Address Architecture Please send us requests for agenda items. We will be giving priority to the above topics, but will fit other things in as time allows. For this we will give preference to current working group documents and last to status reports. Thanks, Bob Hinden and Margaret Wasserman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 5 01:57:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA59vd29008484; Tue, 5 Nov 2002 01:57:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA59vdoS008483; Tue, 5 Nov 2002 01:57:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA59vY29008476 for ; Tue, 5 Nov 2002 01:57:35 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA59vhMq001799 for ; Tue, 5 Nov 2002 01:57:44 -0800 (PST) Received: from ocean.jinmei.org (kame201.kame.net [203.178.141.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19064 for ; Tue, 5 Nov 2002 02:57:38 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by ocean.jinmei.org (8.12.3/8.12.3) with ESMTP id gA59wbKB012694; Tue, 5 Nov 2002 18:58:38 +0900 (JST) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Date: Tue, 05 Nov 2002 18:58:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Soohong Daniel Park Cc: ipng@sunroof.eng.sun.com Subject: Re: how can i get all hosts addresses In-Reply-To: <000001c283dd$11fdc510$b7cbdba8@daniel7209> References: <000001c283dd$11fdc510$b7cbdba8@daniel7209> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 04 Nov 2002 17:35:03 +0900, >>>>> Soohong Daniel Park said: > I'd like to get all hosts addresses in small network, can i get these > addresses usign multicast ? > Otherwise, do i reserve specific multicast address for this purpose ? If the "small network" is a single link, and if you just need one address per host, then you can send an ICMPv6 echo request to ff02::1 and collect the source addresses of echo replies. If the "small network" is a single link, but if you need all addresses for each host, you could use IPv6 node information queries (described in draft-ietf-ipngwg-icmp-name-lookups-09.txt). However, I suspect that not many (types of) IPv6 implementations support this. Of course, either approach is not 100% reliable, because queries and responses may be dropped. If the "small network" is larger than a single link, you can't do that without some protocol extensions. 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 Nov 5 03:11:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5BBt29008699; Tue, 5 Nov 2002 03:11:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5BBtAW008698; Tue, 5 Nov 2002 03:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5BBm29008689 for ; Tue, 5 Nov 2002 03:11:48 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5BBvMq009909 for ; Tue, 5 Nov 2002 03:11:57 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18706 for ; Tue, 5 Nov 2002 03:11:52 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10949; Tue, 5 Nov 2002 06:09:22 -0500 (EST) Message-Id: <200211051109.GAA10949@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-dns-discovery-07.txt Date: Tue, 05 Nov 2002 06:09:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Well known site local unicast addresses for DNS resolver Author(s) : A. Durand, J. Hagino, D. Thaler Filename : draft-ietf-ipv6-dns-discovery-07.txt Pages : 12 Date : 2002-11-4 This documents specifies 3 well known addresses to configure stub resolvers on IPv6 nodes to enable them to communicate with recursive DNS server with minimum configuration in the network and without running a discovery protocol on the end nodes. This method may be used when no other information about the addresses of recursive DNS servers is available. Implementation of stub resolvers using this as default configuration must provide a way to override this. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-dns-discovery-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-dns-discovery-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-dns-discovery-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: <2002-11-4172148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-dns-discovery-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-dns-discovery-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4172148.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 5 03:11:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5BBn29008691; Tue, 5 Nov 2002 03:11:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5BBmBb008688; Tue, 5 Nov 2002 03:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5BBg29008678 for ; Tue, 5 Nov 2002 03:11:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5BBpMq009889 for ; Tue, 5 Nov 2002 03:11:51 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA15857 for ; Tue, 5 Nov 2002 04:11:45 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10934; Tue, 5 Nov 2002 06:09:16 -0500 (EST) Message-Id: <200211051109.GAA10934@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-08.txt Date: Tue, 05 Nov 2002 06:09:15 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson Filename : draft-ietf-ipngwg-rfc2553bis-08.txt Pages : 31 Date : 2002-11-4 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-rfc2553bis-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-08.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: <2002-11-4172139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2553bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4172139.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 5 03:45:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5BjJ29009257; Tue, 5 Nov 2002 03:45:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5BjJdN009256; Tue, 5 Nov 2002 03:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5BjG29009249 for ; Tue, 5 Nov 2002 03:45:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5BjPMq014782 for ; Tue, 5 Nov 2002 03:45:25 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18252 for ; Tue, 5 Nov 2002 04:45:19 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gA5BjFN17410; Tue, 5 Nov 2002 13:45:15 +0200 Date: Tue, 5 Nov 2002 13:45:14 +0200 (EET) From: Pekka Savola To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: Atlanta IETF IPv6 Agenda Planning In-Reply-To: <4.3.2.7.2.20021104153006.026c6b38@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 4 Nov 2002, Bob Hinden wrote: > There are several topics that we feel are important to devote significant > meeting time on. These are: > > - DNS Discovery > - Flow Label > - MIB Updates > - Node Requirements > - Prefix Delegation > - Site-Local Usage / Scoped Address Architecture May I also ask that API documents be considered important to get nailed down ASAP (if not yesterday), and time will be reserved for those (if necessary)? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 5 04:45:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5Cix29009701; Tue, 5 Nov 2002 04:44:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5CixNX009700; Tue, 5 Nov 2002 04:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5Ciu29009693 for ; Tue, 5 Nov 2002 04:44:56 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5Cj5Mq022156 for ; Tue, 5 Nov 2002 04:45:05 -0800 (PST) Received: from laptop2.kurtis.pp.se (tlp1.cobweb.autonomica.se [130.244.10.138]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29138 for ; Tue, 5 Nov 2002 04:44:59 -0800 (PST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gA5Civwc012843; Tue, 5 Nov 2002 13:45:08 +0100 (CET) Date: Tue, 5 Nov 2002 13:44:55 +0100 Subject: Re: Limiting the Use of Site-Local Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <2B81403386729140A3A899A8B39B046405E3FF@server2000> Message-Id: <62F1DF84-F0BC-11D6-84E6-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > You don't get the point. The choice of site-locals is a deliberate > choice of *never* connecting a device to the Internet. It's a design > requirement, not a limitation. > If that is the case you can pick address out of the existing address space. No need to waste a finite resource. Best regards, - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 5 07:48:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5FmQ29010590; Tue, 5 Nov 2002 07:48:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5FmQiF010589; Tue, 5 Nov 2002 07:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5FmN29010582 for ; Tue, 5 Nov 2002 07:48:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5FmWMq024774 for ; Tue, 5 Nov 2002 07:48:32 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21736 for ; Tue, 5 Nov 2002 08:48:26 -0700 (MST) Subject: RE: Atlanta IETF IPv6 Agenda Planning Date: Tue, 5 Nov 2002 07:48:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E419@server2000> content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Atlanta IETF IPv6 Agenda Planning Thread-Index: AcKEj9IMwrxNhIOYQoewoQeoiWQzhwAUixuw From: "Michel Py" To: "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA5FmN29010583 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > The IPv6 working group has two session at the Atlanta > IETF meeting. They are: It has been mentioned on the mailing list that the wording "site-local" could be replaced by something more appropriate. This is no light task, as just inventorying the number of documents that would require modification would take time. Maybe we could have a quick, feel-the-temperature floor vote about undertaking this task and then push back to the ML the choice of the replacement name if deemed appropriate. Would not take much time. 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 Nov 5 08:05:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5G5629010915; Tue, 5 Nov 2002 08:05:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5G55Ei010914; Tue, 5 Nov 2002 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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5G5229010904 for ; Tue, 5 Nov 2002 08:05:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5G5BbB014339 for ; Tue, 5 Nov 2002 08:05:11 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12043 for ; Tue, 5 Nov 2002 08:05:06 -0800 (PST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 05 Nov 2002 08:05:09 -0800 Reply-To: From: "Tony Hain" To: "'Soohong Daniel Park'" , Subject: RE: how can i get all hosts addresses Date: Tue, 5 Nov 2002 08:04:22 -0800 Message-ID: <04d501c284e5$015d8ac0$237ba8c0@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.3416 In-Reply-To: <000001c283dd$11fdc510$b7cbdba8@daniel7209> 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 gA5G5229010905 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Your best option would be to define a site-scope multicast for this purpose. -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Soohong Daniel Park Sent: Monday, November 04, 2002 12:35 AM To: ipng@sunroof.eng.sun.com Subject: how can i get all hosts addresses I'd like to get all hosts addresses in small network, can i get these addresses usign multicast ? Otherwise, do i reserve specific multicast address for this purpose ? Thank in advance -Daniel ===================================== Soohong Daniel Park Research Engineer Mobile Platform Group Digital Media R&D Center Samsung Electronics Co.,LTD TEL:+82-31-200-3728 FAX:+82-31-200-3147 H.P:+82-11-9950-4655 mailto:soohong.park@samsung.com ===================================== -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 5 08:15:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5GFJ29011017; Tue, 5 Nov 2002 08:15:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5GFIEn011016; Tue, 5 Nov 2002 08:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5GFF29011009 for ; Tue, 5 Nov 2002 08:15:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5GFObB016734 for ; Tue, 5 Nov 2002 08:15:24 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19506 for ; Tue, 5 Nov 2002 09:15:18 -0700 (MST) Subject: RE: (ipv6) globally unique private addresses Date: Tue, 5 Nov 2002 08:15:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E41A@server2000> content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: (ipv6) globally unique private addresses Thread-Index: AcKEjAtVWK2P0gUQSA6l1qeXQLtqvAAV5nTw From: "Michel Py" To: "Dan Lanciani" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA5GFF29011010 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, > Dan Lanciani wrote: > So your position is that I must do one of those two rather > than using site-local addresses on the one segment along > with the two globals? I believe that this restriction > renders site-locals useless for many applications. > I would be forced to opt for NAT. You don't have NAT and you are not going to write yourself. Forget it. >> I don't see what your problem is with 1, because the >> smallest you can get is a /64 anyway, which is enough >> for more printers and workstations than you will ever have. > There seems to be a persistent notion that ISPs are going to > change their business models just because the IP header > version field increases by 2. I don't buy it. Show me proof. The IID is 64 bits, please read the addressing architecture draft. Same as a v4 ISP could not give you less than ONE IPv4 address, a v6 ISP can not give you less than ONE /64. > If you ban packets with global addresses from your > site-local subnet then the site-local machines > (obviously) can't talk to globally-connected machines > via their global addresses. In my example, this makes > #2 impossible. Sorry, I misread you. There is no such restriction. > There's no restriction on having site-locals and globals > on one subnet either, but we seem to be talking about > adopting one or more of these restrictions. That is called political compromise. However, I am glad you contributed your feelings, and I would stick to what I wrote in my original answer about this: If it's only me, ok to scrap it. If some other people do insist on having this feature, keep it. > I cannot support your position. This restricted version of > site-locals may have some marginal security benefit, but it > fails to deliver on the original promise of flexible scoping. > It will just cause confusion for administrators who will > think they can control their address allocations... until > they actually try to do it. Okay, I tried, no cigar. I actually think exactly as you do, so let's stick to site-locals as we both want them. No restriction other than what Bob Hinden mentioned yesterday. 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 Nov 5 11:04:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5J4829012439; Tue, 5 Nov 2002 11:04:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5J48Rv012438; Tue, 5 Nov 2002 11:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5J4529012431 for ; Tue, 5 Nov 2002 11:04:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5J4DbB009381 for ; Tue, 5 Nov 2002 11:04:14 -0800 (PST) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04096 for ; Tue, 5 Nov 2002 12:04:07 -0700 (MST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 1E2152ED2 for ; Tue, 5 Nov 2002 11:04:01 -0800 (PST) Received: from anw.zk3.dec.com (bryalpha.zk3.dec.com [16.141.40.3]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 35A12858 for ; Tue, 5 Nov 2002 11:04:00 -0800 (PST) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id gA5J3wx0001145948; Tue, 5 Nov 2002 14:03:58 -0500 (EST) Date: Tue, 5 Nov 2002 14:03:58 -0500 (EST) From: Jack McCann Message-Id: <200211051903.gA5J3wx0001145948@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: rfc2553bis-07 to rfc2553bis-08 changes Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There was one change from rfc2553bis-07 to rfc2553bis-08. In response to a comment from the IESG, the description of the sin6_flowinfo field was changed from: The sin6_flowinfo field is a 32-bit field that contains two pieces of information: the traffic class and the flow label. The contents and interpretation of this member is specified in [1]. to: The sin6_flowinfo field is a 32-bit field intended to contain flow-related information. The exact use of this field is not currently specified. This in essence matches the IEEE spec, which is silent on the subject of sin6_flowinfo. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 5 11:30:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5JUh29012815; Tue, 5 Nov 2002 11:30:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5JUhkV012814; Tue, 5 Nov 2002 11:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5JUe29012807 for ; Tue, 5 Nov 2002 11:30:40 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5JUnMq003677 for ; Tue, 5 Nov 2002 11:30:49 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11390 for ; Tue, 5 Nov 2002 11:30:43 -0800 (PST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id OAA03478; Tue, 5 Nov 2002 14:30:40 -0500 (EST) Date: Tue, 5 Nov 2002 14:30:40 -0500 (EST) From: Dan Lanciani Message-Id: <200211051930.OAA03478@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: (ipv6) globally unique private addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Michel Py" wrote: |You don't have NAT and you are not going to write yourself. Forget it. I write tcp/ip stacks and associated drivers for a living. Some of my OEM customers use these components to build NAT products. I assure you that if I want v6 NAT I will have it. Even if I don't want it I will probably have it. The way things are going, it looks like everyone will have it. If they have v6 at all. |> There seems to be a persistent notion that ISPs are going to |> change their business models just because the IP header |> version field increases by 2. I don't buy it. Show me proof. | |The IID is 64 bits, please read the addressing architecture draft. Same |as a v4 ISP could not give you less than ONE IPv4 address, a v6 ISP can |not give you less than ONE /64. I'm sorry, but you are wrong. Many ISPs run their networks as big bridged segments. They can and they will use a single /64 for such segments, allocating customer addresses out of that chunk on a pay-per-address basis. It could even be argued (and I'm sure they will argue) that this is the most natural arrangement: what was a single v4 subnet will become a single v6 subnet. Dialup providers will almost certainly use a /128 because that is the closest to what they are doing now. It doesn't matter what a draft (or any other document) says. Such papers are not binding on ISPs. Remember, many ISPs use addresses as a substitute for bandwidth. That's why some of them are so hot to detect and eliminate v4 NAT. 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 Nov 5 11:34:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5JYg29012888; Tue, 5 Nov 2002 11:34:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5JYf5b012887; Tue, 5 Nov 2002 11:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5JYc29012880 for ; Tue, 5 Nov 2002 11:34:38 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5JYlbB019940 for ; Tue, 5 Nov 2002 11:34:47 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10836 for ; Tue, 5 Nov 2002 12:34:41 -0700 (MST) Subject: RE: A few comments on Site-Local Useage Date: Tue, 5 Nov 2002 11:34:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E41E@server2000> content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: A few comments on Site-Local Useage Thread-Index: AcKETu5VoOTlTRPiQqig3g5mDX0tKwAsRS7Q From: "Michel Py" To: "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA5JYc29012881 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > Bob Hinden wrote: > It seems to me that from a reachability point of view > there isn't too much difference between using site-local > addresses and having a firewall that blocks traffic from > one set of global addresses and another. This could be debated forever, and I don't think the discussion would be productive as the security implications of site-local addresses are dealt with at layer 9. Here's an example: - You are the security designer of a utility company. - By using a combination of beginner's luck, skill, social engineering and other things, a 15 year-old manages to get in one of the breakers and shuts down power 15 blocks down main street. Not funny enough, so the kid goes bragging about it on some IRC channel and it makes it to the local newspaper. - Suddenly your seat will become too hot for a certain part of your body. - Worse, if someone trips in the dark and breaks their back, they're going to sue the company for negligence and your management will can that body part we were talking about earlier. All of this for one reason. One. Because, in the aftermath of the outage, there is always going to be some security consultant to say to your senior management: "THIS WOULD NOT HAVE HAPPENNED IF YOU USED PRIVATE ADDRESSES". This reason alone is good enough for network managers to keep using private addresses, and they will continue doing it regardless of what half of this mailing list thinks. 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 Nov 5 12:22:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5KMD29013462; Tue, 5 Nov 2002 12:22:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5KMDOh013461; Tue, 5 Nov 2002 12:22: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5KM929013454 for ; Tue, 5 Nov 2002 12:22:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5KMHMq020506 for ; Tue, 5 Nov 2002 12:22:18 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27340 for ; Tue, 5 Nov 2002 13:22:14 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA5KJZU14702; Tue, 5 Nov 2002 15:19:35 -0500 (EST) Message-Id: <200211052019.gA5KJZU14702@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Bob Hinden" , ipng@sunroof.eng.sun.com Subject: Re: Atlanta IETF IPv6 Agenda Planning In-reply-to: (Your message of "Tue, 05 Nov 2002 07:48:38 PST.") <2B81403386729140A3A899A8B39B046405E419@server2000> Date: Tue, 05 Nov 2002 15:19:35 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd far rather we spend that time finding ways to minimize the harm done by site-locals. Changing their name will not help much, IMHO. > It has been mentioned on the mailing list that the wording "site-local" > could be replaced by something more appropriate. This is no light task, > as just inventorying the number of documents that would require > modification would take time. > > Maybe we could have a quick, feel-the-temperature floor vote about > undertaking this task and then push back to the ML the choice of the > replacement name if deemed appropriate. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 5 15:07:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5N7q29014269; Tue, 5 Nov 2002 15:07:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5N7q6O014268; Tue, 5 Nov 2002 15:07:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5N7n29014261 for ; Tue, 5 Nov 2002 15:07:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5N7vbB020379 for ; Tue, 5 Nov 2002 15:07:58 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04943 for ; Tue, 5 Nov 2002 16:07:52 -0700 (MST) Received: from kenawang.windriver.com ([192.168.1.20]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA03668; Tue, 5 Nov 2002 15:07:34 -0800 (PST) Message-Id: <5.1.0.14.2.20021105180241.036f8b20@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Nov 2002 18:09:13 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local Cc: "Thomas Narten" , In-Reply-To: <2B81403386729140A3A899A8B39B046405E411@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >In short, I think that if there was a /32 allocated to private >addressing, that is strongly labeled "do NOT route on the public >Internet", we might find that most networks administrators could not >care less about site-locals. This wouldn't actually be any different than site-locals, except for being a /32 instead of a /9 or /10, or whatever site-locals are... The main problems with site-locals are caused by the fact that the same site-local prefix is used in multiple sites, creating ambiguity. Additional problems are caused by the assumption that a single host may be in more than one site at the same time (creating even more ambiguity). Changing what number we use for the prefix and/or the length of the prefix doesn't change anything... 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 Nov 5 15:11:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5NBO29014320; Tue, 5 Nov 2002 15:11:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5NBOQ0014319; Tue, 5 Nov 2002 15:11:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5NBL29014312 for ; Tue, 5 Nov 2002 15:11:21 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5NBTMq012489 for ; Tue, 5 Nov 2002 15:11:30 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07026 for ; Tue, 5 Nov 2002 16:11:24 -0700 (MST) Received: from kenawang.windriver.com ([192.168.1.20]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA06667; Tue, 5 Nov 2002 15:11:08 -0800 (PST) Message-Id: <5.1.0.14.2.20021105181028.036f9040@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Nov 2002 18:12:47 -0500 To: Dan Lanciani From: Margaret Wasserman Subject: RE: Limiting the Use of Site-Local Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200211041929.OAA00706@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, >Let's say I have an Ethernet segment with 20 workstations and 5 printers. >I determine that two of the workstations need access to the Internet so I >rent 2 global addresses from my ISP. What makes you think that you will "rent" individual addresses from your ISP in IPv6? The idea is that every customer site should receive a /48 allocation, and individual nodes (at the end of point-to-point links, etc.) should receive a /64. So far, the ISPs who have deployed IPv6 (there are only a few right now), have been allocating a /48 or a /64 to every customer. And, we were successful in getting the 3GPP folks to change their specs to allocate a /64 to every cell phone... 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 Nov 5 15:27:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5NRb29014460; Tue, 5 Nov 2002 15:27:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5NRbkU014459; Tue, 5 Nov 2002 15:27: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5NRY29014451 for ; Tue, 5 Nov 2002 15:27:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5NRhMq017829 for ; Tue, 5 Nov 2002 15:27:43 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02936 for ; Tue, 5 Nov 2002 16:27:33 -0700 (MST) Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local Date: Tue, 5 Nov 2002 15:27:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E423@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: SUMMARY: RE: Limiting the Use of Site-Local Thread-Index: AcKFIEkx7qZKAFQjRHKuFGyLfIE0ZQAAXYVg From: "Michel Py" To: "Margaret Wasserman" Cc: "Thomas Narten" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA5NRY29014453 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > Changing what number we use for the prefix and/or the > length of the prefix doesn't change anything... I guess both Thomas and I were trying to find a way out of this, but if you're not interested, site-locals stay as they are from former consensus and I'm happy 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 Tue Nov 5 15:34:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5NY829014517; Tue, 5 Nov 2002 15:34:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5NY83e014516; Tue, 5 Nov 2002 15:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5NY529014509 for ; Tue, 5 Nov 2002 15:34:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5NYDbB028362 for ; Tue, 5 Nov 2002 15:34:14 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06264 for ; Tue, 5 Nov 2002 16:34:08 -0700 (MST) Subject: RE: Limiting the Use of Site-Local Date: Tue, 5 Nov 2002 15:34:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E424@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKFIcZaZfR4W427S5GKD16tHPaMJQAAWrIA From: "Michel Py" To: "Margaret Wasserman" , "Dan Lanciani" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA5NY529014510 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Dan Lanciani wrote: >> Let's say I have an Ethernet segment with 20 workstations >> and 5 printers. I determine that two of the workstations >> need access to the Internet so I rent 2 global addresses >> from my ISP. > Margaret Wasserman wrote: > What makes you think that you will "rent" individual > addresses from your ISP in IPv6? The idea is that every > customer site should receive a /48 allocation, and > individual nodes (at the end of point-to-point links, > etc.) should receive a /64. > So far, the ISPs who have deployed IPv6 (there are only a > few right now), have been allocating a /48 or a /64 to > every customer. And, we were successful in getting the > 3GPP folks to change their specs to allocate a /64 to > every cell phone... I agree with Margaret, for a change; made the same point three hours ago. Margaret, have you heard of significant pricing differences between a /48 and a /64? 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 Nov 5 15:38:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5Ncv29014623; Tue, 5 Nov 2002 15:38:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5NcuMv014622; Tue, 5 Nov 2002 15:38:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5Ncr29014615 for ; Tue, 5 Nov 2002 15:38:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5Nd2Mq021192 for ; Tue, 5 Nov 2002 15:39:03 -0800 (PST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25707 for ; Tue, 5 Nov 2002 16:38:57 -0700 (MST) Received: from [128.177.195.146] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 16360137F04; Tue, 5 Nov 2002 15:38:57 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 05 Nov 2002 15:41:11 -0800 Subject: Re: Limiting the Use of Site-Local From: David Conrad To: Margaret Wasserman , Dan Lanciani Cc: IPng Message-ID: In-Reply-To: <5.1.0.14.2.20021105181028.036f9040@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 Margaret, On 11/5/02 3:12 PM, "Margaret Wasserman" wrote: > What makes you think that you will "rent" individual addresses from > your ISP in IPv6? What makes you think ISPs will be interested in giving up revenue streams, particularly given how well they are (not) doing? Do you think ISPs are charging for address space because it is limited? Rgds, -drc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 5 15:40:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5NeF29014652; Tue, 5 Nov 2002 15:40:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5NeFFj014651; Tue, 5 Nov 2002 15:40: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5NeB29014644 for ; Tue, 5 Nov 2002 15:40:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5NeKbB000068 for ; Tue, 5 Nov 2002 15:40:20 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22603 for ; Tue, 5 Nov 2002 16:40:15 -0700 (MST) Received: from kenawang.windriver.com ([192.168.1.19]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA26852; Tue, 5 Nov 2002 15:40:00 -0800 (PST) Message-Id: <5.1.0.14.2.20021105183732.036f54b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 05 Nov 2002 18:41:37 -0500 To: Dan Lanciani From: Margaret Wasserman Subject: RE: (ipv6) globally unique private addresses Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200211050518.AAA02106@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, >So your position is that I must do one of those two rather than using >site-local addresses on the one segment along with the two globals? I >believe that this restriction renders site-locals useless for many >applications. I would be forced to opt for NAT. As far as I can tell, Michel's view on this does not represent the majority view of people who favour the use of site-local addresses for private addressing. The scoped addressing architecture currently assumes that there will (potentially) be global and site-local prefixes in use on the same subnet. Due to the way that we expect IPv6 address to be allocated (a /64 per subnet) and assigned (using address autoconfiguration), though, there will be a tendency for all of the nodes on a single network to use the same set of prefixes. If a global prefix is advertised on the subnet, all nodes on that subnet would configure global addresses. Obviously, this could be overridden using manual configuration or by using DHCPv6 for address assignment. 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 Nov 5 15:55:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5Ntn29014923; Tue, 5 Nov 2002 15:55:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA5NtnvF014922; Tue, 5 Nov 2002 15:55:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA5Ntk29014915 for ; Tue, 5 Nov 2002 15:55:46 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA5NttMq026368 for ; Tue, 5 Nov 2002 15:55:55 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00715 for ; Tue, 5 Nov 2002 16:55:49 -0700 (MST) Subject: RE: Limiting the Use of Site-Local Date: Tue, 5 Nov 2002 15:56:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E425@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Limiting the Use of Site-Local Thread-Index: AcKFJhGdIOdXKixHSm6aLvBoWjdWFQAACLuw From: "Michel Py" To: "David Conrad" , "Margaret Wasserman" , "Dan Lanciani" Cc: "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA5Ntk29014916 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Margaret Wasserman wrote: >> What makes you think that you will "rent" individual >> addresses from your ISP in IPv6? > David Conrad wrote: > What makes you think ISPs will be interested in giving > up revenue streams, particularly given how well they are > (not) doing? The revenue stream for IPv6 does not exist yet. Today, most v6 ISPs are free, and when they finally decide to milk some money out of it, convincing customers that they need IPv6 begins with offering a large space. > Do you think ISPs are charging for address space because > it is limited? No, they charge for address space because a) they pay for it and b) they can bullshit the customer that it is limited. 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 Nov 5 16:17:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA60HD29015317; Tue, 5 Nov 2002 16:17:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA60HChn015315; Tue, 5 Nov 2002 16:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA60H829015308 for ; Tue, 5 Nov 2002 16:17:08 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA60HHMq002666 for ; Tue, 5 Nov 2002 16:17:17 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11967 for ; Tue, 5 Nov 2002 17:17:12 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA60H4U17413; Tue, 5 Nov 2002 19:17:04 -0500 (EST) Message-Id: <200211060017.gA60H4U17413@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: David Conrad cc: Margaret Wasserman , Dan Lanciani , IPng Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 05 Nov 2002 15:41:11 PST.") Date: Tue, 05 Nov 2002 19:17:04 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Do you think ISPs are charging for address space because it is limited? No, I think ISPs are charging for address space because we have taken away the alternative of letting customers get routable address space of their own. That doesn't mean that I disagree with the decision to encourage address aggregation, just that there might be some undesirable consequences of that decision even if it was the best thing to do. Realistically, routing table space and updates and computation are, with current technology, finite or even scarce resources. It's hard to believe that sooner or later this wouldn't cost something, though perhaps not as much as it does now. Keith p.s. perhaps somebody would like to explain why my ISP tries to impose NAT and RFC 1918 addresses on its DSL customers even though the addresses on the other side of the DSL modem are globals, and even though the DSL modems they ship won't talk to more than one Ethernet address between power cycles? it's not helping any (hypothetical or otherwise) address shortage, and it's not providing any security benefit to their customers. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 5 16:41:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA60fW29015472; Tue, 5 Nov 2002 16:41:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA60fW4S015471; Tue, 5 Nov 2002 16:41:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA60fS29015464 for ; Tue, 5 Nov 2002 16:41:29 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA60fcMq008826 for ; Tue, 5 Nov 2002 16:41:38 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16054 for ; Tue, 5 Nov 2002 16:41:32 -0800 (PST) Subject: RE: (ipv6) globally unique private addresses Date: Tue, 5 Nov 2002 16:41:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E427@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: (ipv6) globally unique private addresses Thread-Index: AcKFJa0YGZTp05uVS4GZ3LhZFchNZQABNOjw From: "Michel Py" To: "Margaret Wasserman" , "Dan Lanciani" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA60fT29015465 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > As far as I can tell, Michel's view on this does > not represent the majority view of people who > favour the use of site-local addresses for > private addressing. I gave up on that one. I thought it would be consensual, obviously it is not. > Due to the way that we expect IPv6 address to be > allocated (a /64 per subnet) and assigned (using > address autoconfiguration), though, there will be > a tendency for all of the nodes on a single network > to use the same set of prefixes. If a global > prefix is advertised on the subnet, all nodes on > that subnet would configure global addresses. > Obviously, this could be overridden using manual > configuration or by using DHCPv6 for address > assignment. Which is the very reason I mentioned earlier that from the enterprise perspective it was a draw. 25 workstations, you don't have an issue if 3 need public addresses, but if you have a subnet with 200 hosts, and 100 of them need public addresses, the administrative cost associated with 100 static IPs or 100 DHCP reservations is not negligible. Compare this with creating another VLAN in the layer 3 switch. 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 Nov 5 17:23:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA61NO29015739; Tue, 5 Nov 2002 17:23:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA61NOcP015738; Tue, 5 Nov 2002 17:23: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA61NL29015731 for ; Tue, 5 Nov 2002 17:23:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA61NUMq019765 for ; Tue, 5 Nov 2002 17:23:30 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA25269 for ; Tue, 5 Nov 2002 18:23:24 -0700 (MST) Subject: RE: A few comments on Site-Local Useage Date: Tue, 5 Nov 2002 17:23:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E428@server2000> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A few comments on Site-Local Useage Thread-Index: AcKETu5VoOTlTRPiQqig3g5mDX0tKwA3zlKw From: "Michel Py" To: "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA61NL29015732 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > Bob Hinden wrote: > Another router issue that gets talked around is should > packets with site-local destination be forwarded to > "default". Given that site-local addresses are not > created without being configured, one approach could be > to have a "black hole" route for FEC0::/10 preconfigured > in all routers. There is some potential in this. Rationale: ambiguity is a fail-safe for routes that leak in the DFZ even though they were not supposed to and for ISPs that don't filter them even though they were supposed to. If we could add to this black hole a preconfigured prefix-list for each peer that would deny FEC0::/10 ge 10 (1) that would likely be good enough to let ambiguity go and we would make a step towards globally unique site-locals. (1) I am thinking about something like the default deny at the end, except that it would be at the beginning and would be effective even though there is no prefix-list applied to the peer. Something that would require a separate command and a confirmation to de-activate. Why would one want site-locals in BGP anyway? 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 Nov 5 17:33:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA61X029015838; Tue, 5 Nov 2002 17:33:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA61X08g015837; Tue, 5 Nov 2002 17:33:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA61Wv29015830 for ; Tue, 5 Nov 2002 17:32:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA61X6bB000694 for ; Tue, 5 Nov 2002 17:33:06 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18303 for ; Tue, 5 Nov 2002 18:33:00 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id UAA04509; Tue, 5 Nov 2002 20:32:56 -0500 (EST) Date: Tue, 5 Nov 2002 20:32:56 -0500 (EST) From: Dan Lanciani Message-Id: <200211060132.UAA04509@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: Limiting the Use of Site-Local Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: |What makes you think that you will "rent" individual addresses from |your ISP in IPv6? What makes you think that the current business model will change? There are two aspects of the current model. ISPs charge per address because they can use this as a surrogate measure of bandwidth, and they charge what the market will bear because customers have no choice but to rent addresses. Nothing in v6 changes either of these aspects. In fact, some "features" of v6 makes things worse for the customer here. Functional site-locals might have had a chance to at least constrain the price since an end user would be paying only for the incremental feature of global access. Without working site-locals the basic functioning of each networked device will depend on the ISP's address allocation and thus we will be back to whatever the market will bear. This in turn will encourage NAT. |The idea is that every customer site should |receive a /48 allocation, That's a nice idea for the customer, but not such a nice idea for the ISP. Given that the provider controls the allocation, what do you think will happen? |and individual nodes (at the end of |point-to-point links, etc.) should receive a /64. Funny, it seems like only months ago someone was assuring me that dialups would get a /48. We've already lost 16 bits. You have to realize that in practice dialups will get a /128 unless they pay for special treatment. |So far, the ISPs who have deployed IPv6 (there are only a few |right now), have been allocating a /48 or a /64 to every customer. Do you honestly think that this is a valid indication of anything? V6 addresses are virtually free at this time because they have virtually no commercial value. V4 addresses were free in the good old days (yes, I was there) when they had little perceived commercial value. They were even provider-independent. It took some fancy footwork to get from that to where we are today, with each market step sold as a temporary technical hack that (a) would require us to give up nothing in the long term and (b) was vital to prevent the immediate collapse of the net as we knew it. Of course, all the address restrictions became permanent even though their dubious technical justifications ceased to exist long ago. If and when v6 addresses gain commercial value their price will increase as well. 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 Nov 5 18:02:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA622Z29017394; Tue, 5 Nov 2002 18:02:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA622YFU017393; Tue, 5 Nov 2002 18:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA622R29017377 for ; Tue, 5 Nov 2002 18:02:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA622abB009357 for ; Tue, 5 Nov 2002 18:02:36 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02950 for ; Tue, 5 Nov 2002 19:02:30 -0700 (MST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id gA622S829807; Tue, 5 Nov 2002 18:02:28 -0800 (PST) From: Bill Manning Message-Id: <200211060202.gA622S829807@boreas.isi.edu> Subject: Re: A few comments on Site-Local Useage In-Reply-To: <2B81403386729140A3A899A8B39B046405E428@server2000> from Michel Py at "Nov 5, 2 05:23:36 pm" To: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 5 Nov 2002 18:02:28 -0800 (PST) Cc: hinden@iprg.nokia.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 % Bob, % % > Bob Hinden wrote: % > Another router issue that gets talked around is should % > packets with site-local destination be forwarded to % > "default". Given that site-local addresses are not % > created without being configured, one approach could be % > to have a "black hole" route for FEC0::/10 preconfigured % > in all routers. % % There is some potential in this. % % Rationale: ambiguity is a fail-safe for routes that leak in the DFZ even % though they were not supposed to and for ISPs that don't filter them % even though they were supposed to. % % If we could add to this black hole a preconfigured prefix-list for each % peer that would deny FEC0::/10 ge 10 (1) that would likely be good % enough to let ambiguity go and we would make a step towards globally % unique site-locals. % % (1) I am thinking about something like the default deny at the end, % except that it would be at the beginning and would be effective even % though there is no prefix-list applied to the peer. Something that would % require a separate command and a confirmation to de-activate. Why would % one want site-locals in BGP anyway? % % Michel. % per interface or per-peer? (will require a better understanding of default behaviour of routing protocols) if per-peer, which routing protocol? -- --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 Tue Nov 5 19:06:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA636Ekl019261; Tue, 5 Nov 2002 19:06:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA62I6D3018006; Tue, 5 Nov 2002 18:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA62Gp29017947 for ; Tue, 5 Nov 2002 18:16:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA62GxbB013199 for ; Tue, 5 Nov 2002 18:16:59 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16394 for ; Tue, 5 Nov 2002 19:16:54 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA62GpU16778; Tue, 5 Nov 2002 21:16:51 -0500 (EST) Message-Id: <200211060216.gA62GpU16778@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: Limiting the Use of Site-Local In-reply-to: (Your message of "Tue, 05 Nov 2002 20:32:56 EST.") <200211060132.UAA04509@ss10.danlan.com> Date: Tue, 05 Nov 2002 21:16:51 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > You have to realize that in practice > dialups will get a /128 unless they pay for special treatment. mere speculation. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 5 19:07:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA637Pkd019335; Tue, 5 Nov 2002 19:07:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA637PDL019333; Tue, 5 Nov 2002 19:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA637Akv019288 for ; Tue, 5 Nov 2002 19:07:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA62uIMq018757 for ; Tue, 5 Nov 2002 18:56:18 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03607 for ; Tue, 5 Nov 2002 19:56:13 -0700 (MST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gA62tl2S016969 for ; Tue, 5 Nov 2002 19:56:07 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id TAA25532 for ; Tue, 5 Nov 2002 19:51:49 -0700 (MST)] Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gA62td7C026667 for ; Wed, 6 Nov 2002 13:55:39 +1100 (EST) Message-ID: <3DC884A9.2034323B@motorola.com> Date: Wed, 06 Nov 2002 13:55:37 +1100 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: Scoping Scoped Addresses References: <4.3.2.7.2.20021104133814.03173818@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: > 3) People who want to use site-local addresses should work on > completing the "IPv6 Scoped Address Architecture" document (and other > docs if needed). I think a good focus for this would be to focus on > the simplest cases. Topics to cover need to include site border > routers, adding site-local addresses in the DNS, routing protocols, > the use of firewalls to enforce site boundaries, and guidelines on how > applications might want to select between global and site-local > addresses. The people in the other camp can review this work and make > sure the technical content is accurate. Here is my summary of how site local prefixes might be used, written from a high level perspective. Constructive criticism and additional use cases welcome. Purpose: The site local prefix is designed to allow numbering of leaf sites independent from the global internet. Three particular uses are envisaged: - Experimental networks without connectivity to the global internet. - Unconnected leaf networks - Networks with intermittent connectivity (eg dial-up networks) If a network has a sufficiently persistent globally assigned prefix, this should be used instead of site local prefixes. Site locals should only be used if the network has no globally assigned prefix or if the global prefix is unreliable (dial-up with dynamically assigned prefix, roving hotspot device). Note that site local prefixes have no requirement for global administration or registration, but are likewise not guaranteed unique, nor expected to be routeable outside the site. Most of the complications with site local prefixes occur when a leaf network attempts to support both site local and global addresses. Routing: Within a "site", site-local addresses are propagated as any other unicast prefix. The boundaries of a site are marked by site border routers, which do not forward site local traffic from interfaces within a given site to other interfaces. Routers that are not intended to be part of a site should drop any site-local traffic. Scope: Site-local addresses are only valid within their site (as defined by border routers). Site local addresses that leak outside this scope may or may not be meaningful, and probably won't do what was expected or desired. Routers and hosts are only expected to support one site local scope. Further subdivision of a site local address space should be done using the site local aggregate portion of the SLA address. Optional: can also subdivide based on bits 17-48. Scope and Address selection: Address selection for hosts is a difficult issue. Destinations with only a global address (and hence probably outside the site) should be addressed using that address, and the source address should also be global. Traffic destined for outside the site should fail if a site-local source address is used. Destinations with both global and site local addresses (internal hosts) can be accessed using either. Assuming that a site local exists because the global address is not persistent, internal only applications should favour site local addresses. Applications that may include external hosts need to use global addresses. Note: This is IMO the real sticking point of site locals. Globally unique non-routeable addresses have exactly the same problem. Filtering globally unique routeable addresses is worse, since the reduced scope is hidden from the application. Merging: If two sites using site locals merge, renumbering may be required (since the addresses are not globally unique). IPv6 networks should be designed to support renumbering, and various mechanisms exist to do this. Security: Site local addresses provide no inherent security benefits, except that hosts "know" that site local traffic shouldn't be router outside the site. A variety of tunnelling mechanisms can break scoping, and thus this security. Naming: I have some ideas, but for now see: draft-williams-dnsext-private-namespace-01.txt for a site-scoped naming proposal. This can easily be integrated with scoped addressing, where queries to a site-local domain (hosted on a site-local nameserver) provide both local and global addresses, while queries to a global domain provide only global addresses. -- 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 Nov 5 20:00:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA6400kd020044; Tue, 5 Nov 2002 20:00:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA6400As020043; Tue, 5 Nov 2002 20:00:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA63xukd020036 for ; Tue, 5 Nov 2002 19:59:56 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA6404bB003597 for ; Tue, 5 Nov 2002 20:00:04 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA25564 for ; Tue, 5 Nov 2002 20:59:59 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA63xaU17118; Tue, 5 Nov 2002 22:59:36 -0500 (EST) Message-Id: <200211060359.gA63xaU17118@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: awhite@arc.corp.mot.com cc: IPng Subject: Re: Scoping Scoped Addresses In-reply-to: (Your message of "Wed, 06 Nov 2002 13:55:37 +1100.") <3DC884A9.2034323B@motorola.com> Date: Tue, 05 Nov 2002 22:59:36 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk this summary is a good start, IMHO. one comment: > Scope and Address selection: > > Address selection for hosts is a difficult issue. > > Destinations with only a global address (and hence probably outside the > site) should be addressed using that address, and the source address should > also be global. Traffic destined for outside the site should fail if a > site-local source address is used. > > Destinations with both global and site local addresses (internal hosts) can > be accessed using either. Assuming that a site local exists because the > global address is not persistent, internal only applications should favour > site local addresses. Applications that may include external hosts need to > use global addresses. I think it's fairly arbitrary to distinguish "internal-only" applications from "applications that may include external hosts". How will the application know which category it is in? What if different components of the application have different ideas about this? > Note: This is IMO the real sticking point of site locals. Globally unique > non-routeable addresses have exactly the same problem. I disagree here for what may be subtle reasons. forgive me for trying to explain them again. My assumption is that if sites expect apps to use site-locals (and especially if we don't provide them with good alternatives) then customers will demand that many apps be able to operate across site boundaries using those addresses, adding considerable complexity to those apps and degrading their performance and reliability. OTOH if non-routable globals are available (except perhaps in isolated sites where it doesn' t matter) then it becomes much more reasonable for many apps to simply use global addresses whenever they are available. The app no longer needs to define its own addressing (at least not for the purpose of working around SLs). And it is no longer the app's responsibility to know about sites or to try to route between those sites. If the network designers had wanted to provide a connection between those networks they would have done so. (non-routable really means non-routable in the public internet - it doesn't preclude routing via private connections) > Filtering globally > unique routeable addresses is worse, since the reduced scope is hidden from > the application. My assumption is that the prefixes for non-routable global addresses would be well known, so they are as easily filtered as site locals. However it would not really be valid for an app to assume that a non-routable address had a reduced scope in comparison to a global address, or that such an address was less likely to work. On a network with extensive private connections to other networks but lots of filtering on its connections to the public internet the app might do better with the non-routable address. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 5 22:49:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA66nPkd020858; Tue, 5 Nov 2002 22:49:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA66nOXK020857; Tue, 5 Nov 2002 22:49: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA66nLkd020850 for ; Tue, 5 Nov 2002 22:49:21 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA66nUMq023335 for ; Tue, 5 Nov 2002 22:49:31 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA22373 for ; Tue, 5 Nov 2002 22:49:25 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gA66mvh29347; Wed, 6 Nov 2002 08:48:57 +0200 Date: Wed, 6 Nov 2002 08:48:56 +0200 (EET) From: Pekka Savola To: Michel Py cc: Bob Hinden , Subject: RE: A few comments on Site-Local Useage In-Reply-To: <2B81403386729140A3A899A8B39B046405E428@server2000> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk That still does not solve the issue of site-local being used as a source address. On Tue, 5 Nov 2002, Michel Py wrote: > > Bob Hinden wrote: > > Another router issue that gets talked around is should > > packets with site-local destination be forwarded to > > "default". Given that site-local addresses are not > > created without being configured, one approach could be > > to have a "black hole" route for FEC0::/10 preconfigured > > in all routers. > > There is some potential in this. > > Rationale: ambiguity is a fail-safe for routes that leak in the DFZ even > though they were not supposed to and for ISPs that don't filter them > even though they were supposed to. > > If we could add to this black hole a preconfigured prefix-list for each > peer that would deny FEC0::/10 ge 10 (1) that would likely be good > enough to let ambiguity go and we would make a step towards globally > unique site-locals. > > (1) I am thinking about something like the default deny at the end, > except that it would be at the beginning and would be effective even > though there is no prefix-list applied to the peer. Something that would > require a separate command and a confirmation to de-activate. Why would > one want site-locals in BGP anyway? > > 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 > -------------------------------------------------------------------- > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 5 23:43:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA67hjkd021145; Tue, 5 Nov 2002 23:43:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA67hjtv021144; Tue, 5 Nov 2002 23:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA67hfkd021134 for ; Tue, 5 Nov 2002 23:43:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA67hobB004920 for ; Tue, 5 Nov 2002 23:43:50 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03649 for ; Wed, 6 Nov 2002 00:43:44 -0700 (MST) Subject: RE: A few comments on Site-Local Useage Date: Tue, 5 Nov 2002 23:43:56 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E429@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A few comments on Site-Local Useage Thread-Index: AcKFOLgFWpd0yOJ8TOiovWn2mkYF3QALADeg From: "Michel Py" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 To: "Bill Manning" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA67hfkd021135 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, % Michel Py wrote: % Rationale: ambiguity is a fail-safe for routes that leak in the DFZ even % though they were not supposed to and for ISPs that don't filter them % even though they were supposed to. % If we could add to this black hole a preconfigured prefix-list for each % peer that would deny FEC0::/10 ge 10 (1) that would likely be good % enough to let ambiguity go and we would make a step towards globally % unique site-locals. % (1) I am thinking about something like the default deny at the end, % except that it would be at the beginning and would be effective even % though there is no prefix-list applied to the peer. Something that would % require a separate command and a confirmation to de-activate. Why would % one want site-locals in BGP anyway? > Bill Manning wrote: > per interface or per-peer? (will require a better understanding > of default behaviour of routing protocols) > if per-peer, which routing protocol? That's a good question, and I'm not sure I have a good answer. Let's try this: Rationale 1: This black hole to FEC0::/10 that Bob mentioned earlier is a good idea, but it does not achieve much in practice as it would be a well-known mechanism and the hacker would announce FEC0::/11 instead and bypass it. What we really need is to blackhole the route itself. The same reasoning applies if the route leak is a result of a snafu from the legit network admin, because the route being leaked is probably going to be FEC0::/48 or some /48 within the range, which will not go into Bob's blackhole either. Rationale 2: Site-locals are routable within the site, which more or less means allow with IGP, and not routable outside of the site, which more or less means deny with BGP. I think the answer to "which protocol" is definitely BGP, and possibly eBGP. I have not thought the process much but I think that site-locals should not be carried over iBGP, but over IGP only. Any takers on this? Thought process: I thought this as a BGP animal, so naturally it was on a per-peer basis. The two reasons I would still lean towards this are: - The amount of peer traffic to match against is very small compared to the amount of generic traffic. - Per-interface would require further processing as identifying the traffic as being BGP, then decapsulating the packet and inspect the actual route inside, sounds awful to me, NAT-like ALG. In short: > per interface or per-peer? Per-peer. > if per-peer, which routing protocol? BGP, possibly eBGP only, to be discussed. Hope this answers the question, 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 Nov 6 00:12:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA68CPkd021518; Wed, 6 Nov 2002 00:12:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA68CPAk021517; Wed, 6 Nov 2002 00:12: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA68CLkd021510 for ; Wed, 6 Nov 2002 00:12:22 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA68CVbB009796 for ; Wed, 6 Nov 2002 00:12:31 -0800 (PST) Received: from mail.nosense.org (139.cust1.nsw.dsl.ozemail.com.au [203.103.156.139]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02110 for ; Wed, 6 Nov 2002 01:12:24 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id A7F463B382; Wed, 6 Nov 2002 19:11:26 +1100 (EST) Subject: RE: A few comments on Site-Local Useage From: Mark Smith To: Michel Py Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: <2B81403386729140A3A899A8B39B046405E428@server2000> References: <2B81403386729140A3A899A8B39B046405E428@server2000> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Nov 2002 19:11:26 +1100 Message-Id: <1036570298.12000.37.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2002-11-06 at 12:23, Michel Py wrote: > Bob, > > > Bob Hinden wrote: > > Another router issue that gets talked around is should > > packets with site-local destination be forwarded to > > "default". Given that site-local addresses are not > > created without being configured, one approach could be > > to have a "black hole" route for FEC0::/10 preconfigured > > in all routers. > > There is some potential in this. > > Rationale: ambiguity is a fail-safe for routes that leak in the DFZ even > though they were not supposed to and for ISPs that don't filter them > even though they were supposed to. > > If we could add to this black hole a preconfigured prefix-list for each > peer that would deny FEC0::/10 ge 10 (1) that would likely be good > enough to let ambiguity go and we would make a step towards globally > unique site-locals. > > (1) I am thinking about something like the default deny at the end, > except that it would be at the beginning and would be effective even > though there is no prefix-list applied to the peer. Something that would > require a separate command and a confirmation to de-activate. Why would > one want site-locals in BGP anyway? > Could it be argued that if there was a need for confederations in BGP to handle iBGP scaling, then there would a reason for site-locals to be carried by BGP, presuming a single instance of site-local addressing across the organisation ? > 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 Nov 6 08:55:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA6Gt1kd023555; Wed, 6 Nov 2002 08:55:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA6Gt1bb023554; Wed, 6 Nov 2002 08:55:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA6Gswkd023547 for ; Wed, 6 Nov 2002 08:54:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA6Gt6Mq002625 for ; Wed, 6 Nov 2002 08:55:06 -0800 (PST) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11190 for ; Wed, 6 Nov 2002 09:55:00 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gA6GsW6Q015560; Wed, 6 Nov 2002 17:54:38 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gA6GsRo9123746; Wed, 6 Nov 2002 17:54:32 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA64030 from ; Wed, 6 Nov 2002 17:54:16 +0100 Message-Id: <3DC94929.E01A2CCB@hursley.ibm.com> Date: Wed, 06 Nov 2002 17:54:01 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Jack McCann Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes References: <200211051903.gA5J3wx0001145948@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I understand the problem with the old language, but the new language is a bit disturbing too. RFC 2474 and RFC 3168 do specify 8 of these bits, and 4 of them are inoperative in the API (the version number bits). Brian Jack McCann wrote: > > There was one change from rfc2553bis-07 to rfc2553bis-08. In response > to a comment from the IESG, the description of the sin6_flowinfo field > was changed from: > > The sin6_flowinfo field is a 32-bit field that contains two pieces of > information: the traffic class and the flow label. The contents and > interpretation of this member is specified in [1]. > > to: > > The sin6_flowinfo field is a 32-bit field intended to contain > flow-related information. The exact use of this field is not > currently specified. > > This in essence matches the IEEE spec, which is silent on the > subject of sin6_flowinfo. > > - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 6 10:20:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA6IKdkd024026; Wed, 6 Nov 2002 10:20:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA6IKcJB024025; Wed, 6 Nov 2002 10:20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA6IKZkd024018 for ; Wed, 6 Nov 2002 10:20:35 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA6IKhMq028442 for ; Wed, 6 Nov 2002 10:20:44 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24697 for ; Wed, 6 Nov 2002 11:20:38 -0700 (MST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1763C59B8; Wed, 6 Nov 2002 13:20:38 -0500 (EST) Received: from anw.zk3.dec.com (bryalpha.zk3.dec.com [16.141.40.3]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id E82221001; Wed, 6 Nov 2002 13:20:37 -0500 (EST) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id gA6IKbr0001336170; Wed, 6 Nov 2002 13:20:37 -0500 (EST) Date: Wed, 6 Nov 2002 13:20:37 -0500 (EST) From: Jack McCann Message-Id: <200211061820.gA6IKbr0001336170@anw.zk3.dec.com> To: brian@hursley.ibm.com Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> There was one change from rfc2553bis-07 to rfc2553bis-08. In response >> to a comment from the IESG, the description of the sin6_flowinfo field >> was changed from: >> >> The sin6_flowinfo field is a 32-bit field that contains two pieces of >> information: the traffic class and the flow label. The contents and >> interpretation of this member is specified in [1]. >> >> to: >> >> The sin6_flowinfo field is a 32-bit field intended to contain >> flow-related information. The exact use of this field is not >> currently specified. >> >> This in essence matches the IEEE spec, which is silent on the >> subject of sin6_flowinfo. > >I understand the problem with the old language, but the new language >is a bit disturbing too. RFC 2474 and RFC 3168 do specify 8 of these >bits, and 4 of them are inoperative in the API (the version number bits). First let me say I'm open to suggestions for better wording. While RFC 2474 and RFC 3168 specify bits in the IPv4 and IPv6 headers, they do not specify anything about the use of sin6_flowinfo to affect or retrieve those bits. The same problem exists with the original reference to RFC 2460, which specifies the format of the IPv6 header, but does not specify anything about sin6_flowinfo. Even if we assume the sin6_flowinfo field is formatted in the same way as the first 4 bytes of the IPv6 header (i.e. version, class, and flow), we still have not specified how the sin6_flowinfo field is used. So we have two choices: hold rfc2553bis while we define the use of the sin6_flowinfo field, or defer that definition to another spec as we did with sin6_scope_id (rfc2553bis-08 reflects the latter choice). - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 6 10:48:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA6Imkkd024298; Wed, 6 Nov 2002 10:48:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA6ImkV9024297; Wed, 6 Nov 2002 10:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA6Imgkd024290 for ; Wed, 6 Nov 2002 10:48:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA6ImoMq008091 for ; Wed, 6 Nov 2002 10:48:51 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05754 for ; Wed, 6 Nov 2002 11:48:44 -0700 (MST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA6ImhLI013198; Wed, 6 Nov 2002 13:48:43 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA6Imgu3086980; Wed, 6 Nov 2002 11:48:42 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gA6Iina17496; Wed, 6 Nov 2002 13:44:49 -0500 Message-Id: <200211061844.gA6Iina17496@rotala.raleigh.ibm.com> To: Jack McCann cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes In-Reply-To: Message from Jack McCann of "Tue, 05 Nov 2002 14:03:58 EST." <200211051903.gA5J3wx0001145948@anw.zk3.dec.com> Date: Wed, 06 Nov 2002 13:44:49 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jack. > There was one change from rfc2553bis-07 to rfc2553bis-08. In response > to a comment from the IESG, the description of the sin6_flowinfo field > was changed from: > The sin6_flowinfo field is a 32-bit field that contains two pieces of > information: the traffic class and the flow label. The contents and > interpretation of this member is specified in [1]. > to: > The sin6_flowinfo field is a 32-bit field intended to contain > flow-related information. The exact use of this field is not > currently specified. > This in essence matches the IEEE spec, which is silent on the > subject of sin6_flowinfo. I think the change to this document is fine, and the best we can do for now. I think we also need to have a plan for how to deal with the flow label and traffic class field in other APIs, so that we avoid problems for when we actually get around to specifying those APIs in more detail. Specifically, we have: - 2553bis (basic API) - 2292bis (advanced API) - future API extensions, such as for temporary addresses, etc. It may well be a mistake to overload the flow label and traffic class stuff. But that is what we did in earlier APIs. As Bill Fenner points out: Bill Fenner writes: > 2133 said: > The sin6_flowinfo field is a 32-bit field that contains two pieces of > information: the 24-bit IPv6 flow label and the 4-bit priority field. > The contents and interpretation of this member is unspecified at this > time. > 2553 said: > The sin6_flowinfo field is a 32-bit field that contains two pieces of > information: the traffic class and the flow label. The contents and > interpretation of this member is specified in [1]. The sin6_flowinfo > field SHOULD be set to zero by an implementation prior to using the > sockaddr_in6 structure by an application on receive operations. > Since [1] doesn't specify the contents and interpretation, and 2133 said > it was unspecified, I guess 2553bis can get away with saying > > The sin6_flowinfo field is a 32-bit field intended to contain > > flow-related information. The exact use of this field is not > > currently specified. > The two APIs that I have looked at (KAME and Linux) both copy the top 28 > bits of the sin6_flowinfo field (in network byte order) to the top 28 > bits of the packet. The above (with regards to to the Traffic Class) is arguable not what we want. With regards to the basic API: - Will we want the basic API to ever allow a way to specify the Traffic Class? If so, will it be better to define a new extension or to overload the Flow Label? - Should we point out that some previous versions of the basic API copied both traffic class and flow label info into packets and that this is now beleived to be wrong and should be fixed? I'm OK with either saying setting the Traffic Class through the basic API won't be done in the future, or saying it can be added but in a way that is completely backwards compatable and will work smoothly with 2292bis (assuming we need two ways of setting the bits). Then there is the Advanced API. Again, from Bill: Bill Fenner writes: > I am still concerned about the interaction between 2292bis's IPV6_TCLASS > and these implementations, but perhaps we should let 2553bis go with the > "not currently specified" wording and make the interaction clear in > 2292bis? (Has the WG as a whole had a chance to see the suggesiton of > leaving sin6_flowinfo simply unspecified?) 2292 doesn't address the flow label. But it does have a way of setting the Traffic Class. But it doesn't mention how it interacts with Traffic Class settings via the (old) basic APIs. If the intention is that the old ways are invalid, and that one only sets traffic class through the advanced API, I think the current approach is fine. Is that what folks are thinking here? Finally, 2292bis seems to assume the Traffic Class is 8 bits in size. It's not any more. It's 6 bits, with the ECN bits explicitly a separate field. So perhaps 2292bis should be updated to reflect the new size and have separate way of setting the ECN bits? Or at least, the text should make it clear how one sets one and not the other, etc. 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 Nov 6 11:02:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA6J2Ckd024409; Wed, 6 Nov 2002 11:02:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA6J2BiL024408; Wed, 6 Nov 2002 11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA6J28kd024401 for ; Wed, 6 Nov 2002 11:02:08 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA6J2GMq012910 for ; Wed, 6 Nov 2002 11:02:16 -0800 (PST) Received: from pollux.dmz.acbl.net (pollux.internet.acbl.net [65.203.89.251]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA11963 for ; Wed, 6 Nov 2002 12:02:11 -0700 (MST) Received: (qmail 2609 invoked by uid 1006); 6 Nov 2002 19:02:10 -0000 Received: from unknown (HELO dopey.acbl.net) (172.16.100.13) by pollux.acbl.net with SMTP; 6 Nov 2002 19:02:10 -0000 Received: by dopey.acbl.net with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Nov 2002 14:02:09 -0500 Message-ID: <961762B3A2CED411BA0F0000E866BBF50514C0E3@dopey.acbl.net> From: "Pitcher, Jeff R." To: "'Thomas Narten'" , Jack McCann Cc: ipng@sunroof.eng.sun.com Subject: RE: rfc2553bis-07 to rfc2553bis-08 changes Date: Wed, 6 Nov 2002 14:02:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Remove jeff.pitcher@acbl.net -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, November 06, 2002 1:45 PM To: Jack McCann Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes Hi Jack. > There was one change from rfc2553bis-07 to rfc2553bis-08. In response > to a comment from the IESG, the description of the sin6_flowinfo field > was changed from: > The sin6_flowinfo field is a 32-bit field that contains two pieces of > information: the traffic class and the flow label. The contents and > interpretation of this member is specified in [1]. > to: > The sin6_flowinfo field is a 32-bit field intended to contain > flow-related information. The exact use of this field is not > currently specified. > This in essence matches the IEEE spec, which is silent on the > subject of sin6_flowinfo. I think the change to this document is fine, and the best we can do for now. I think we also need to have a plan for how to deal with the flow label and traffic class field in other APIs, so that we avoid problems for when we actually get around to specifying those APIs in more detail. Specifically, we have: - 2553bis (basic API) - 2292bis (advanced API) - future API extensions, such as for temporary addresses, etc. It may well be a mistake to overload the flow label and traffic class stuff. But that is what we did in earlier APIs. As Bill Fenner points out: Bill Fenner writes: > 2133 said: > The sin6_flowinfo field is a 32-bit field that contains two pieces of > information: the 24-bit IPv6 flow label and the 4-bit priority field. > The contents and interpretation of this member is unspecified at this > time. > 2553 said: > The sin6_flowinfo field is a 32-bit field that contains two pieces of > information: the traffic class and the flow label. The contents and > interpretation of this member is specified in [1]. The sin6_flowinfo > field SHOULD be set to zero by an implementation prior to using the > sockaddr_in6 structure by an application on receive operations. > Since [1] doesn't specify the contents and interpretation, and 2133 said > it was unspecified, I guess 2553bis can get away with saying > > The sin6_flowinfo field is a 32-bit field intended to contain > > flow-related information. The exact use of this field is not > > currently specified. > The two APIs that I have looked at (KAME and Linux) both copy the top 28 > bits of the sin6_flowinfo field (in network byte order) to the top 28 > bits of the packet. The above (with regards to to the Traffic Class) is arguable not what we want. With regards to the basic API: - Will we want the basic API to ever allow a way to specify the Traffic Class? If so, will it be better to define a new extension or to overload the Flow Label? - Should we point out that some previous versions of the basic API copied both traffic class and flow label info into packets and that this is now beleived to be wrong and should be fixed? I'm OK with either saying setting the Traffic Class through the basic API won't be done in the future, or saying it can be added but in a way that is completely backwards compatable and will work smoothly with 2292bis (assuming we need two ways of setting the bits). Then there is the Advanced API. Again, from Bill: Bill Fenner writes: > I am still concerned about the interaction between 2292bis's IPV6_TCLASS > and these implementations, but perhaps we should let 2553bis go with the > "not currently specified" wording and make the interaction clear in > 2292bis? (Has the WG as a whole had a chance to see the suggesiton of > leaving sin6_flowinfo simply unspecified?) 2292 doesn't address the flow label. But it does have a way of setting the Traffic Class. But it doesn't mention how it interacts with Traffic Class settings via the (old) basic APIs. If the intention is that the old ways are invalid, and that one only sets traffic class through the advanced API, I think the current approach is fine. Is that what folks are thinking here? Finally, 2292bis seems to assume the Traffic Class is 8 bits in size. It's not any more. It's 6 bits, with the ECN bits explicitly a separate field. So perhaps 2292bis should be updated to reflect the new size and have separate way of setting the ECN bits? Or at least, the text should make it clear how one sets one and not the other, etc. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 6 13:51:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA6LpPkd025367; Wed, 6 Nov 2002 13:51:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA6LpPKF025366; Wed, 6 Nov 2002 13:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA6LpMkd025359 for ; Wed, 6 Nov 2002 13:51:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA6LpUbB027808 for ; Wed, 6 Nov 2002 13:51:30 -0800 (PST) Received: from imo-r03.mx.aol.com (imo-r03.mx.aol.com [152.163.225.99]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23831 for ; Wed, 6 Nov 2002 14:51:22 -0700 (MST) Received: from Rich3800@aol.com by imo-r03.mx.aol.com (mail_out_v34.13.) id 1.3d.272f509e (15888) for ; Wed, 6 Nov 2002 16:51:16 -0500 (EST) Received: from aol.com (ool-182c1989.dyn.optonline.net [24.44.25.137]) by air-id08.mx.aol.com (v89.12) with ESMTP id MAILINID83-1106165116; Wed, 06 Nov 2002 16:51:16 -0500 Message-ID: <3DC98EBF.2080504@aol.com> Date: Wed, 06 Nov 2002 16:50:55 -0500 From: Rich3800 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: IPv4 address necessary for IPv6 address? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is it necessary to get an IPv4 static IP address to get an IPv6 one? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 6 14:13:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA6MDlkd025817; Wed, 6 Nov 2002 14:13:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA6MDlLs025816; Wed, 6 Nov 2002 14:13: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA6MDikd025806 for ; Wed, 6 Nov 2002 14:13:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA6MDqMq015635 for ; Wed, 6 Nov 2002 14:13:52 -0800 (PST) Received: from ns3.ndsoftware.net (ns3.ndsoftware.net [62.4.22.214]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13586 for ; Wed, 6 Nov 2002 15:13:45 -0700 (MST) Received: from nat-levgw1.fr.corp.ndsoftware.net ([62.4.22.213] helo=srv1.fr.corp.ndsoftware.com) by ns3.ndsoftware.net with esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.35 #1 (Debian)) id 189YRi-0000y0-00; Wed, 06 Nov 2002 23:14:46 +0100 Received: from wks1.fr.corp.ndsoftware.com ([10.1.0.5] helo=localhost.localdomain) by srv1.fr.corp.ndsoftware.com with esmtp (Exim 3.35 #1 (Debian)) id 189YNC-0001H8-00; Wed, 06 Nov 2002 23:10:06 +0100 Subject: Re: IPv4 address necessary for IPv6 address? From: Nicolas DEFFAYET To: Rich3800 Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3DC98EBF.2080504@aol.com> References: <3DC98EBF.2080504@aol.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 06 Nov 2002 23:14:45 +0100 Message-Id: <1036620886.26606.659.camel@wks1.fr.corp.ndsoftware.com> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2002-11-06 at 22:50, Rich3800 wrote: > Is it necessary to get an IPv4 static IP address to get an IPv6 one? No, if you have a native IPv6 connection. You need an IPv4 static IP address only if you build an IPv6 over IPv4 tunnel. Best Regards, Nicolas DEFFAYET FNIX6: http://www.fnix6.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 Nov 6 16:06:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7065kd027055; Wed, 6 Nov 2002 16:06:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7065w7027054; Wed, 6 Nov 2002 16:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7061kd027047 for ; Wed, 6 Nov 2002 16:06:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7069Mq020905 for ; Wed, 6 Nov 2002 16:06:09 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20900 for ; Wed, 6 Nov 2002 17:06:03 -0700 (MST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gA70638Z003288 for ; Wed, 6 Nov 2002 17:06:03 -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 RAA21841 for ; Wed, 6 Nov 2002 17:05:57 -0700 (MST)] Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gA705t7C000777 for ; Thu, 7 Nov 2002 11:05:55 +1100 (EST) Message-ID: <3DC9AE63.D5AB6295@motorola.com> Date: Thu, 07 Nov 2002 11:05:55 +1100 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: Scoping Scoped Addresses References: <200211060359.gA63xaU17118@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > Scope and Address selection: > I think it's fairly arbitrary to distinguish "internal-only" applications > from "applications that may include external hosts". How will the > application know which category it is in? What if different components > of the application have different ideas about this? Any application involving transactions between two hosts that doesn't want to pass name or address information to a third party shouldn't have problems. In this situation, it's probably safe to pick a site-local if it's mutually available. The problem comes if machines A and B start talking, and then machine B decides to forward A's address (or name) to C, who is outside the site. If B forwards a site scoped identifier, we've got a problem. The simplest solution I can see is to make it a user problem - if you want global connectivity, connect using a global name and thus force a global address. See notes on DNS. Alternatively, an application that tries to forward a scoped identifier to a target outside scope could: (1) Fail (2) Attempt to re-establish the session with a more suitable scope. > > Note: This is IMO the real sticking point of site locals. Globally > > unique non-routeable addresses have exactly the same problem. > > I disagree here for what may be subtle reasons. forgive me for trying > to explain them again. > > My assumption is that if sites expect apps to use site-locals (and > especially if we don't provide them with good alternatives) then > customers will demand that many apps be able to operate across site > boundaries using those addresses, adding considerable complexity to > those apps and degrading their performance and reliability. Hmm. I think this assumption is not as robust as it should be. The presence of a site local prefix could mean: - There is no global connection, at which point the very concept of operating across site boundaries is meaningless. - There is also a global connection, at which point the address selection rules should use this for external connection. The case of two disconnected sites merging is handled in the discussion on renumbering. IMO, we want to push site local addressing as a (2nd line) mechanism for internal addressing independent of the global address space. At the point a network connects to the global internet, a set of global prefixes should be distributed also. The address selection rules are in place precisely to deal with this multi-addressed situation. In fact, once global connectivity exists, site local addresses should be deprecated and eventually removed, unless the allocating authority (human or automated) has reason to consider that the global prefix allocation is "transient". > OTOH if non-routable globals are available (except perhaps in isolated > sites where it doesn' t matter) then it becomes much more reasonable for > many apps to simply use global addresses whenever they are available. > The app no longer needs to define its own addressing (at least not for > the purpose of working around SLs). And it is no longer the app's > responsibility to know about sites or to try to route between those > sites. > If the network designers had wanted to provide a connection between > those networks they would have done so. For clarity, let's talk about restricted scope and global scope [unique] addresses. (Site local are restricted scope non-unique addresses.) I must be missing something. I read this several times, and it still seems to be one of two situations: - If apps can tell the difference in scope, then there is functionally no difference a restricted scope unique or non-unique address. Except: - restricted scope unique addresses can site merge, but I have already suggested that all sites should be configured to handle renumbering (which is particularly necessary if global prefixes may come and go). - non-unique addresses don't require a global allocating authority. - If apps can't tell the difference, then your unique restricted scope address is from the apps' perspective an unrestricted scope address, which could lead to some "unexpected" failures due to filtering. Alternatively, you could instantaneously deprecate all those restricted scope unique addresses as soon as a global scope address became available, but that is exactly the reason a network might run site locals and globals in parallel - to maintain address persistence independent of a dynamic global address. What have I missed? > However it would not really be valid for an app to assume that a > non-routable address had a reduced scope in comparison to a > global address, or that such an address was less likely to work. > On a network with extensive private connections to other networks but > lots of filtering on its connections to the public internet the app > might do better with the non-routable address. So not a site, but a mesh of sites with arbitrary connectivity? At this level of complexity, why not just use globally routeable prefixes and configure the routers and filters to pass or block packets correctly? If the sites were truly "disconnected", or someone particularly wanted to use a private address space in parallel to the global one, the fec0:.../48 address space has plenty of room for bits 17-32 to be used as "site identifiers". Note that I am /not/ working on a model of an isolated network connected to the global internet via a proxying mechanism (think NAT). I'm assuming that global connectivity is via true global addressing, and that hosts need to be able to play nice in a situation where they have both site (restricted) and global (unrestricted) scoped addresses available. -- 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 Nov 6 17:10:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA71ASkd027796; Wed, 6 Nov 2002 17:10:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA71ARaZ027795; Wed, 6 Nov 2002 17:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA71ANkd027788 for ; Wed, 6 Nov 2002 17:10:23 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA71AWMq009955 for ; Wed, 6 Nov 2002 17:10:32 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03626 for ; Wed, 6 Nov 2002 17:10:26 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA71AMl03794; Wed, 6 Nov 2002 20:10:22 -0500 (EST) Message-Id: <200211070110.gA71AMl03794@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: awhite@arc.corp.mot.com cc: IPng Subject: Re: Scoping Scoped Addresses In-reply-to: (Your message of "Thu, 07 Nov 2002 11:05:55 +1100.") <3DC9AE63.D5AB6295@motorola.com> Date: Wed, 06 Nov 2002 20:10:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore wrote: > > > > Scope and Address selection: > > > I think it's fairly arbitrary to distinguish "internal-only" applications > > from "applications that may include external hosts". How will the > > application know which category it is in? What if different components > > of the application have different ideas about this? > > Any application involving transactions between two hosts that doesn't want > to pass name or address information to a third party shouldn't have > problems. In this situation, it's probably safe to pick a site-local if > it's mutually available. people made similar incorrect generalizations about NATs. see http://www.cs.utk.edu/~moore/what-nats-break.html for a list of the kinds of practices/assumptions broken by NATs. many of these would also be broken by SLs. > The simplest solution I can see is to make it a user problem - if you want > global connectivity, connect using a global name and thus force a global > address. See notes on DNS. well, you might not want global connectivity but still want the app to span site boundaries. but yes, this works fine - provided, of course, that globals are available to such apps, and that people don't expect such apps to function with only site locals. > Alternatively, an application that tries to forward a scoped identifier to a > target outside scope could: > (1) Fail > (2) Attempt to re-establish the session with a more suitable scope. again, (2) presumes that an address pair with "a more suitable scope" is available and known to the app. a big part of the problem is that lots of people will think that they can just assign SLs on their net and expect apps to work. some apps will work, of course. > > > Note: This is IMO the real sticking point of site locals. Globally > > > unique non-routeable addresses have exactly the same problem. > > > > I disagree here for what may be subtle reasons. forgive me for trying > > to explain them again. > > > > My assumption is that if sites expect apps to use site-locals (and > > especially if we don't provide them with good alternatives) then > > customers will demand that many apps be able to operate across site > > boundaries using those addresses, adding considerable complexity to > > those apps and degrading their performance and reliability. > > Hmm. I think this assumption is not as robust as it should be. The > presence of a site local prefix could mean: > > - There is no global connection, at which point the very concept of > operating across site boundaries is meaningless. > > - There is also a global connection, at which point the address selection > rules should use this for external connection. the presence of a site local isn't as significant as the absence of a global address. but the presence of a global address doesn't imply a global connection. the address selection rules won't save us for lots of reasons - one of which is that they favor SLs over globals even for apps that will fail if they try to use SLs. > IMO, we want to push site local addressing as a (2nd line) mechanism for > internal addressing independent of the global address space. At the point a > network connects to the global internet, a set of global prefixes should be > distributed also. The address selection rules are in place precisely to > deal with this multi-addressed situation. except that they don't deal with this. they assume that the only parties concerned with use of an IP address are the immediate source and destination. they assume that all applications have the same needs from addresses. they assume that all networks have the same preference as to which addresses should be used. etc. > In fact, once global connectivity exists, site local addresses should be > deprecated and eventually removed, unless the allocating authority (human or > automated) has reason to consider that the global prefix allocation is > "transient". again, connectivity isn't necessarily either global or nonexistent. and deprecating the site locals when globals are available would be fine with me, but lots of people claim that there are good reasons to keep them. > > OTOH if non-routable globals are available (except perhaps in isolated > > sites where it doesn' t matter) then it becomes much more reasonable for > > many apps to simply use global addresses whenever they are available. > > The app no longer needs to define its own addressing (at least not for > > the purpose of working around SLs). And it is no longer the app's > > responsibility to know about sites or to try to route between those > > sites. > > If the network designers had wanted to provide a connection between > > those networks they would have done so. > > For clarity, let's talk about restricted scope and global scope [unique] > addresses. (Site local are restricted scope non-unique addresses.) no, that's not clearer. non-routable globals still have global scope. don't confuse addres scope with connectivity. > I must be missing something. I read this several times, and it still seems > to be one of two situations: > > - If apps can tell the difference in scope, then there is functionally no > difference a restricted scope unique or non-unique address. false. non-routable globals are still useful as host/node identification even in the (possibly temporary) absence of connectivity to that host. > - If apps can't tell the difference, then your unique restricted scope > address is from the apps' perspective an unrestricted scope address, which > could lead to some "unexpected" failures due to filtering. no, those kinds of failures should not be unexpected - every app should be able to deal with them. (particiularly if the right ICMP messages result from trying to send traffic to those addresses). "you can't get there from here" is a perfectly valid error condition, since it's a reflection of the underlying network's routing policy. this is not a condition that the app should be trying to work around - it should simply report it. it's much harder to try to cleanly detect errors that result from trying to use ambiguous addresses. but if globals are't available to non-globally-connected networks they'll use SLs and expect apps to route between them, and that's a mess. > > However it would not really be valid for an app to assume that a > > non-routable address had a reduced scope in comparison to a > > global address, or that such an address was less likely to work. > > On a network with extensive private connections to other networks but > > lots of filtering on its connections to the public internet the app > > might do better with the non-routable address. > > So not a site, but a mesh of sites with arbitrary connectivity? right. there's a lot of that going around. > At this level of complexity, why not just use globally routeable prefixes > and configure the routers and filters to pass or block packets correctly? that requires each network to have a connection through an ISP. many networks don't want to do 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 Nov 6 17:34:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA71YQkd027930; Wed, 6 Nov 2002 17:34:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA71YPOe027929; Wed, 6 Nov 2002 17:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA71YMkd027922 for ; Wed, 6 Nov 2002 17:34:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA71YUMq016924 for ; Wed, 6 Nov 2002 17:34:30 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04154 for ; Wed, 6 Nov 2002 18:34:25 -0700 (MST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA71ZLX23400 for ; Wed, 6 Nov 2002 19:35:21 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 6 Nov 2002 19:34:23 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 17:34:23 -0800 Received: from nokia.com ([172.19.66.85]) by daebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 19:34:23 -0600 Message-ID: <3DC9C31F.44DE0AC1@nokia.com> Date: Wed, 06 Nov 2002 17:34:23 -0800 From: Mukesh Gupta Organization: Nokia Networks X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Calculating link local for IPv6 in IPv6 tunnels Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2002 01:34:23.0200 (UTC) FILETIME=[CCFABE00:01C285FD] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, Last paragraph of Appendix A in RFC 2373 (IPv6 Addressing Architecture) suggests various methods for creating a unique link local address for tunnel interfaces. The RFC suggests that the implementors can choose any algorithm as long as it meets the requirements. I am implementing IPv6 in IPv6 tunnels (RFC 2473) and I wanted to know how other implementations are generating the unique link local address so that I can minimize the chances of collision by using the same algorithm. Any information would be highly appreciated. ------------------------------------------------------------------- Links without Identifiers There are a number of links that do not have any type of built-in identifier. The most common of these are serial links and configured tunnels. Interface identifiers must be chosen that are unique for the link. When no built-in identifier is available on a link the preferred approach is to use a global interface identifier from another interface or one which is assigned to the node itself. To use this approach no other interface connecting the same node to the same link may use the same identifier. If there is no global interface identifier available for use on the link the implementation needs to create a local scope interface identifier. The only requirement is that it be unique on the link. There are many possible approaches to select a link-unique interface identifier. They include: Manual Configuration Generated Random Number Node Serial Number (or other node-specific token) The link-unique interface identifier should be generated in a manner that it does not change after a reboot of a node or if interfaces are added or deleted from the node. The selection of the appropriate algorithm is link and implementation dependent. The details on forming interface identifiers are defined in the appropriate "IPv6 over " specification. It is strongly recommended that a collision detection algorithm be implemented as part of any automatic algorithm. ------------------------------------------------------------------- regards Mukesh -- ****************************************************************** You have powers you never dreamed of.You can do things you never thought you could do. There are no limitations in what you can do except the limitations of your own mind. ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 6 18:22:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA72MAkd028153; Wed, 6 Nov 2002 18:22:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA72MAjl028152; Wed, 6 Nov 2002 18:22: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA72M6kd028145 for ; Wed, 6 Nov 2002 18:22:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA72MEbB015584 for ; Wed, 6 Nov 2002 18:22:14 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12518 for ; Wed, 6 Nov 2002 19:22:07 -0700 (MST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gA72JARj016192 for ; Wed, 6 Nov 2002 19:19:10 -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 TAA22532 for ; Wed, 6 Nov 2002 19:22:03 -0700 (MST)] Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gA72M17C014960 for ; Thu, 7 Nov 2002 13:22:01 +1100 (EST) Message-ID: <3DC9CE48.2FFF7014@motorola.com> Date: Thu, 07 Nov 2002 13:22:00 +1100 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: Scoping Scoped Addresses References: <200211070110.gA71AMl03794@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I apologise for the length - for the 8 line summary, skip to the bottom. Keith Moore wrote: > people made similar incorrect generalizations about NATs. > see http://www.cs.utk.edu/~moore/what-nats-break.html for a > list of the kinds of practices/assumptions broken by NATs. > many of these would also be broken by SLs. Within a site, no. Externally, of course. A large number of your objections seem to boil down to "SLs break if people try to use them for global connectivity". This seems an education problem - site locals are site local, which means exactly what it says. NAT is a nasty kludge to give private addresses non-private connectivity. A few of the notes on your list are are multi-homing issues. These exist independent of site-locals. > > - There is also a global connection, at which point the address > > selection rules should use this for external connection. > > the presence of a site local isn't as significant as the absence of > a global address. but the presence of a global address doesn't imply > a global connection. > > the address selection rules won't save us for lots of reasons - > one of which is that they favor SLs over globals even for apps > that will fail if they try to use SLs. Can you give me an example of an application that will fail if two (or more) nodes in the same site attempt to communicate using site locals instead of globals? Of course, the instant you try to connect external to the site, things /will/ (or SHOULD) fail if site locals are involved. DNS is part of a solution. Maintain two namespaces, one local (eg private.arpa), one global. If you want your application to play globally, make sure they use the global names. The app that comes to mind as a potential problem case is a broker for a peer-peer mesh (eg game or teleconferencing client). If A is the server, and B (a machine in the same site) and C (an external machine) both try to connect to it, it needs to be smart enough to obtain B's global address (and/or name) so B and C can meaningfully communicate. On the other hand, it's entirely possible that A, B and D (another local machine) want to communicate locally, and the global address is "transient", thus the local address is to be preferred. User intervention is the only way to solve this problem, as far as I can see. > > IMO, we want to push site local addressing as a (2nd line) mechanism > > for internal addressing independent of the global address space. At > > the point a network connects to the global internet, a set of global > > prefixes should be distributed also. The address selection rules are > > in place precisely to deal with this multi-addressed situation. > > except that they don't deal with this. they assume that the only > parties concerned with use of an IP address are the immediate source > and destination. they assume that all applications have the same needs > from addresses. they assume that all networks have the same preference > as to which addresses should be used. etc. Agreed. Which is why applications should be able to acquire a list of addresses and meaningfully obtain information about their scope. Not all applications will approve of the default recommendation. Note that this is not specifically a site-local issue, it is a multi-homing and scoped addressing issue. > don't confuse addres scope with connectivity. For 99% of applications, connectivity is the issue. I don't do an app any favours if I say: "Here are four candidate destination addresses, and you have three source addresses. I can't provide any hints about which combinations might work." At least a site local says: "To another site local, this as likely to work as any. To anywhere else, I can almost promise you it will fail." In both cases the app should probably try all combinations, but at least we can help it pick right the first time. The assumption of course is that the site local destination address is 'in scope'. Hence the stress on not leaking addresses. Within scope, a site local provides as much information as any other address. Outside scope, the address is meaningless and any packet found with one should be discarded as soon as possible. > it's much harder to try to cleanly detect errors that result from trying > to use ambiguous addresses. but if globals are't available to > non-globally-connected networks they'll use SLs and expect apps to > route between them, and that's a mess. I find this argument specious. It's about as much sense as saying "walk into your local bookshop and buy me the third book in the fiction section", and then complaining because you give me a different book than what I expected from my bookshop. >From my original summary: > Routers and hosts are only expected to support one site local scope. > Further subdivision of a site local address space should be done using > the site local aggregate portion of the SLA address. Or: "If you want to connect multiple networks, either configure them as a single site, or use a bigger scoped address" My short summary: (a) Within a "site", a site local address works at least as well as a global address. (b) Outside a site, a site local address DOES NOT WORK. I'd say "MUST NOT WORK", but that is a little hard to enforce. (c) Given (b), the issues with site locals are about address selection where there are both global and local addresses available. However, these issues exist with any multi-homed host, and site locals at least offer applications some strong cues about when the addresses will fail. -- 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 Nov 6 19:23:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA73Nxkd028422; Wed, 6 Nov 2002 19:23:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA73Nw4Q028421; Wed, 6 Nov 2002 19:23: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA73Ntkd028414 for ; Wed, 6 Nov 2002 19:23:55 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA73O3Mq011413 for ; Wed, 6 Nov 2002 19:24:03 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01686 for ; Wed, 6 Nov 2002 19:23:57 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA73Nsl04180; Wed, 6 Nov 2002 22:23:54 -0500 (EST) Message-Id: <200211070323.gA73Nsl04180@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: awhite@arc.corp.mot.com cc: IPng Subject: Re: Scoping Scoped Addresses In-reply-to: (Your message of "Thu, 07 Nov 2002 13:22:00 +1100.") <3DC9CE48.2FFF7014@motorola.com> Date: Wed, 06 Nov 2002 22:23:54 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I apologise for the length - for the 8 line summary, skip to the bottom. > > Keith Moore wrote: > > > people made similar incorrect generalizations about NATs. > > see http://www.cs.utk.edu/~moore/what-nats-break.html for a > > list of the kinds of practices/assumptions broken by NATs. > > many of these would also be broken by SLs. > > Within a site, no. Externally, of course. of course, for an isolated site they cause no problems at all. but if the site has any external connections there will be apps that are expected to take advantage of those external connections. > A large number of your objections seem to boil down to "SLs break if people > try to use them for global connectivity". close. SLs break if people expect apps that use them to communicate with nodes that are off-site. global connectivity is not a necessary condition. > This seems an education problem - > site locals are site local, which means exactly what it says. well, in an sense, education is what IETF does. we need to educate people so that they don't misuse SLs. > A few of the notes on your list are are multi-homing issues. These exist > independent of site-locals. multi-homing issues won't go away entirely, but their effects can be minimized. over-use of SLs will contribute to the problem. > > the address selection rules won't save us for lots of reasons - > > one of which is that they favor SLs over globals even for apps > > that will fail if they try to use SLs. > > Can you give me an example of an application that will fail if two (or more) > nodes in the same site attempt to communicate using site locals instead of > globals? when they learn of each other's addresses through an intermediary which might not be in the same site. the intermediary has no idea whether those nodes are in the same site or not. > Of course, the instant you try to connect external to the site, things > /will/ (or SHOULD) fail if site locals are involved. no, it won't fail the *instant* you connect - it will fail in mysterious and unpredictable (to users) ways at some later time. > DNS is part of a solution. Maintain two namespaces, one local (eg > private.arpa), one global. If you want your application to play globally, > make sure they use the global names. I've seen this used as an attempt to try to cope with multihoming in IPv4 where not all interfaces were globally accessible. my experience is that people have trouble remembering to use different sets of names for different purposes. > The app that comes to mind as a potential problem case is a broker for a > peer-peer mesh (eg game or teleconferencing client). If A is the server, > and B (a machine in the same site) and C (an external machine) both try to > connect to it, it needs to be smart enough to obtain B's global address > (and/or name) so B and C can meaningfully communicate. easliy done, *if* B has a global address. I don't think everyone is assuming that it necessarily has or needs one. > On the other hand, it's entirely possible that A, B and D (another local > machine) want to communicate locally, and the global address is "transient", > thus the local address is to be preferred. User intervention is the only > way to solve this problem, as far as I can see. actually, not using limited-scope addresses helps a lot. B and D might still have to try multiple addresses, and if B tries the transient address first it will have to time out. but at least when B tries D's other address it doesn't reach a different host. > > > IMO, we want to push site local addressing as a (2nd line) mechanism > > > for internal addressing independent of the global address space. At > > > the point a network connects to the global internet, a set of global > > > prefixes should be distributed also. The address selection rules are > > > in place precisely to deal with this multi-addressed situation. > > > > except that they don't deal with this. they assume that the only > > parties concerned with use of an IP address are the immediate source > > and destination. they assume that all applications have the same needs > > from addresses. they assume that all networks have the same preference > > as to which addresses should be used. etc. > > Agreed. Which is why applications should be able to acquire a list of > addresses and meaningfully obtain information about their scope. no. there's no way in general that an app can 'meaningfully obtain obtain information about their scope' if the absence of a global set of scope names. and if you do that you might as well embed the scope name in the address - which gets you back to non-routable globals. > Not all > applications will approve of the default recommendation. > > Note that this is not specifically a site-local issue, it is a multi-homing > and scoped addressing issue. true. personally I like to think of it as an issue resulting from an over-dependence on address selection. but it's really hard to talk about all of these issues at once - you have to pick one angle or another for the sake of a particular conversation. > > > don't confuse addres scope with connectivity. > > For 99% of applications, connectivity is the issue. I don't do an app any > favours if I say: > > "Here are four candidate destination addresses, and you have three source > addresses. I can't provide any hints about which combinations might work." so don't provide so many addresses unless it's absolutely necessary. don't expect the app or the host to make such choices. don't promote the idea that you can assign as many addresses to a host as you want and expect apps to work. finding a path through the network from point A to point B is the network's job, not the job of applications. and the network can do a better job if we at least try to have distinguished names for points, even if not all points are reachable from all other points. > > At least a site local says: > > "To another site local, this as likely to work as any. To anywhere else, I > can almost promise you it will fail." the problem is, an app has no way of knowing whether it's local to that site, or "anywhere else". so it has nothing to inform that choice. at least with NR globals the app has a chance of getting immediate feedback (either from lack of a route or an ICMP message) if it tries to send to an address that isn't reachable. > In both cases the app should probably try all combinations, but at least we > can help it pick right the first time. site locals make this harder, not easier. > The assumption of course is that the site local destination address is 'in > scope'. Hence the stress on not leaking addresses. Within scope, a site > local provides as much information as any other address. Outside scope, the > address is meaningless and any packet found with one should be discarded as > soon as possible. nodes have no idea what scope they are in. > > it's much harder to try to cleanly detect errors that result from trying > > to use ambiguous addresses. but if globals are't available to > > non-globally-connected networks they'll use SLs and expect apps to > > route between them, and that's a mess. > > I find this argument specious. It's about as much sense as saying "walk > into your local bookshop and buy me the third book in the fiction section", > and then complaining because you give me a different book than what I > expected from my bookshop. I don't follow your analogy. Let me try one of my own. Expecting apps to use SLs is like expecting that someone who is married to a person named "mary" will be equally satisfied with the person named "mary" in whatever town he happens to be in (if there is one), or that he'll be satisfied if he cannot telephone his wife (or reaches a different person) if he isn't in his hometown. > From my original summary: > > > Routers and hosts are only expected to support one site local scope. > > Further subdivision of a site local address space should be done using > > the site local aggregate portion of the SLA address. > > Or: "If you want to connect multiple networks, either configure them as a > single site, or use a bigger scoped address" better yet, use a scopeless address. scopes are too much trouble to deal with. > My short summary: > > (a) Within a "site", a site local address works at least as well as a global > address. true, but apps don't know when they're crossing site boundaries. > (b) Outside a site, a site local address DOES NOT WORK. I'd say "MUST NOT > WORK", but that is a little hard to enforce. true. > (c) Given (b), the issues with site locals are about address selection where > there are both global and local addresses available. However, these issues > exist with any multi-homed host, and site locals at least offer applications > some strong cues about when the addresses will fail. the last part is false - the app gets more cues if the addresses can at least potentially be routed. as for "these issues exist with any multi-homed host" pretending that it's a different (or somebody else's) problem won't help minimize 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 Nov 6 22:31:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA76V1kd029009; Wed, 6 Nov 2002 22:31:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA76V0G8029008; Wed, 6 Nov 2002 22:31: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA76Uukd029001 for ; Wed, 6 Nov 2002 22:30:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA76V4Mq006644 for ; Wed, 6 Nov 2002 22:31:04 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA29547 for ; Wed, 6 Nov 2002 23:30:59 -0700 (MST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gA76V42S024797 for ; Wed, 6 Nov 2002 23:31:04 -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 XAA08667 for ; Wed, 6 Nov 2002 23:30:57 -0700 (MST)] Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gA76Us7C011238 for ; Thu, 7 Nov 2002 17:30:55 +1100 (EST) Message-ID: <3DCA089D.3DD20EDE@motorola.com> Date: Thu, 07 Nov 2002 17:30:53 +1100 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: Scoping Scoped Addresses References: <200211070323.gA73Nsl04180@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So, lets summarise again: - In isolated and unconnected networks, site locals work fine. - If a stable global prefix is available, we strongly recommend using that and not using site locals. - Site locals and global addresses can exist in parallel on the same network, but this is likely to cause address selection problems for applications. - A site is demarcated by the presence of routers that will not forward packets using site-local addresses (in source or destination). Routers that are not part of a site should not forward such packets. - If multiple networks are to be connected using site local addresses, they must be configured to be a single site. - Site local addresses are explicitly invalid outside their site. Connectivity external to a site MUST NOT be done with site local addresses. Sites MUST NOT route packets with site local addresses outside the site. - Proxying or otherwise attempting to connect site local addresses to the global internet (eg NAT) is explicitly discouraged. Note: It might be possible to have site local traffic sent over a tunnel (eg a VPN). In such a situation, the VPN should be treated virtually as part of the site. Site local addresses must not leak outside the tunnel. Though there are probably better ways to do this than using site locals. Does this seem a fair summary of principles thus far? -- 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 Nov 6 22:55:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA76tMkd029188; Wed, 6 Nov 2002 22:55:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA76tM3T029187; Wed, 6 Nov 2002 22:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA76tHkd029180 for ; Wed, 6 Nov 2002 22:55:17 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA76tQMq010328 for ; Wed, 6 Nov 2002 22:55:26 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA29054 for ; Wed, 6 Nov 2002 23:55:20 -0700 (MST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gA76tKal018324 for ; Wed, 6 Nov 2002 23:55:20 -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 XAA26125 for ; Wed, 6 Nov 2002 23:55:18 -0700 (MST)] Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gA76ll7C013055 for ; Thu, 7 Nov 2002 17:47:47 +1100 (EST) Message-ID: <3DCA0C92.38CA6B4A@motorola.com> Date: Thu, 07 Nov 2002 17:47:46 +1100 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: Scoping Scoped Addresses References: <200211070323.gA73Nsl04180@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > I don't follow your analogy. Let me try one of my own. Expecting > apps to use SLs is like expecting that someone who is married to > a person named "mary" will be equally satisfied with the person > named "mary" in whatever town he happens to be in (if there is one), > or that he'll be satisfied if he cannot telephone his wife (or reaches > a different person) if he isn't in his hometown. Ah. I understand now, and this does highlight a potential problem. It's not just about filtering traffic between sites. In the case where a node leaves one site and moves to another, all site-scoped references to the old site must be invalidated too. If I have a cached reference to "mary" in my original site, it is unlikely to do what I expect in my new site. The presence of the interface id will help reduce this problem, but will not eliminate it. So a problem with site locals is that applications must not pass these addresses (and perhaps names) around as if they were globally scoped, which means that any application that could distribute or store addresses should be aware of them and behave accordingly. Alternatively, the user has to make sure that the purity of the site is preserved. Both options have drawbacks. Using unique addresses and prefixes removes the non-uniqueness problem (addresses moved outside their intended scope simply fail), but reintroduces the need for administration. Do you agree? -- 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 Nov 6 23:12:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA77CSkd029306; Wed, 6 Nov 2002 23:12:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA77CSnW029305; Wed, 6 Nov 2002 23:12: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA77CPkd029298 for ; Wed, 6 Nov 2002 23:12:25 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA77CXbB027858 for ; Wed, 6 Nov 2002 23:12:33 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00351 for ; Wed, 6 Nov 2002 23:12:27 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gA77CIR08748; Thu, 7 Nov 2002 09:12:18 +0200 Date: Thu, 7 Nov 2002 09:12:18 +0200 (EET) From: Pekka Savola To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: A few comments on Site-Local Useage In-Reply-To: <4.3.2.7.2.20021104134448.03173818@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 I never got around to replying to this until now, sorry.. On Mon, 4 Nov 2002, Bob Hinden wrote: > A lot of the discussion seems to imply that site-local addresses are > created automatically (like link-local). This is, of course, not the > case. Site-local are only created if someone configures a router with a > specific site-local address on an interface and tell the router to > advertise the prefix in a routing protocol to other routers and to > advertise it to hosts on the link in RAs. Site-local addresses will only > appear in a site if an administrator decided to configure them. Anyone can just blindly configure a site in one link. Not much of a site, but you can use site-locals, and you can source traffic from site-local addresses.. > It seems to me that from a reachability point of view there isn't too much > difference between using site-local addresses and having a firewall that > blocks traffic from one set of global addresses and another. Firewalls > create limited scope addresses from global addresses. Note that a third option is to use global addresses (assuming the site has them), a part of their block, but no route it externally at all. And add firewall filters besides. > If one assumes the > existence of IPv6 firewalls, then these firewalls can also enforce site > boundaries. Sure, but that is not sufficient to satisfy addr-archv3 2.5.6 last paragraph IMO. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 00:02:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA782Mkd029511; Thu, 7 Nov 2002 00:02:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA782MGa029510; Thu, 7 Nov 2002 00:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA782Jkd029503 for ; Thu, 7 Nov 2002 00:02:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA782RMq020484 for ; Thu, 7 Nov 2002 00:02:27 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02764 for ; Thu, 7 Nov 2002 01:02:22 -0700 (MST) Received: from kenawang.windriver.com ([192.168.1.75]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id AAA28811; Thu, 7 Nov 2002 00:01:49 -0800 (PST) Message-Id: <5.1.0.14.2.20021107025518.02adb530@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Nov 2002 03:03:30 -0500 To: Pekka Savola From: Margaret Wasserman Subject: Re: A few comments on Site-Local Useage Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: References: <4.3.2.7.2.20021104134448.03173818@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 > > > existence of IPv6 firewalls, then these firewalls can also enforce site > > boundaries. > >Sure, but that is not sufficient to satisfy addr-archv3 2.5.6 last >paragraph IMO. Why not? If a router is not on a site-boundary, it doesn't need to do anything to enforce site boundaries. In Bob's example, the firewall would be the site border "router", and it would enforce the boundary. I don't see a conflict. 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 Nov 7 00:08:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA788Ikd029590; Thu, 7 Nov 2002 00:08:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA788IYx029589; Thu, 7 Nov 2002 00:08:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA788Fkd029582 for ; Thu, 7 Nov 2002 00:08:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA788NMq021645 for ; Thu, 7 Nov 2002 00:08:23 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25474 for ; Thu, 7 Nov 2002 01:08:17 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gA7884109182; Thu, 7 Nov 2002 10:08:05 +0200 Date: Thu, 7 Nov 2002 10:08:04 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: Bob Hinden , Subject: Re: A few comments on Site-Local Useage In-Reply-To: <5.1.0.14.2.20021107025518.02adb530@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 Thu, 7 Nov 2002, Margaret Wasserman wrote: > > > existence of IPv6 firewalls, then these firewalls can also enforce site > > > boundaries. > > > >Sure, but that is not sufficient to satisfy addr-archv3 2.5.6 last > >paragraph IMO. > > Why not? > > If a router is not on a site-boundary, it doesn't need to do anything > to enforce site boundaries. In Bob's example, the firewall would be > the site border "router", and it would enforce the boundary. > > I don't see a conflict. Perhaps I should have been more verbose. What I meant to say that to implement site-locals properly in a router, the vendor should not be OK to say "we support access-lists, you can use them to configure site-local borders" or that "we have nice firewall products, wanna buy one?". That doesn't seem to be in the spirit of site-local addressing, and I could imagine a significant percentage of site-local users wouldn't do these steps properly, leading to a false sense of security. (Thus one factor in the argument that site-locals in with global networks are bad.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 00:12:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA78Cvkd029673; Thu, 7 Nov 2002 00:12:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA78CvAf029672; Thu, 7 Nov 2002 00:12: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA78Crkd029665 for ; Thu, 7 Nov 2002 00:12:53 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA78D1Mq022751 for ; Thu, 7 Nov 2002 00:13:01 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21579 for ; Thu, 7 Nov 2002 01:12:55 -0700 (MST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id gA78CrCJ090250; Thu, 7 Nov 2002 09:12:53 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gA78CqSM086158; Thu, 7 Nov 2002 09:12:52 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA52352 from ; Thu, 7 Nov 2002 09:12:51 +0100 Message-Id: <3DCA2074.3CEDE2C1@hursley.ibm.com> Date: Thu, 07 Nov 2002 09:12:36 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Jack McCann Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes References: <200211061820.gA6IKbr0001336170@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here's a suggestion, which I think fits with the logic of Thomas Narten's comment too: The sin6_flowinfo field is a 32-bit field intended to contain flow-related information. The exact way this field is mapped into a packet is not currently specified. I don't think we should hold up the spec for this; as Thomas says, more reflection is needed. It doesn't make much sense to close this until we have consensus on the flow label draft. Bria Jack McCann wrote: > > Brian, > > >> There was one change from rfc2553bis-07 to rfc2553bis-08. In response > >> to a comment from the IESG, the description of the sin6_flowinfo field > >> was changed from: > >> > >> The sin6_flowinfo field is a 32-bit field that contains two pieces of > >> information: the traffic class and the flow label. The contents and > >> interpretation of this member is specified in [1]. > >> > >> to: > >> > >> The sin6_flowinfo field is a 32-bit field intended to contain > >> flow-related information. The exact use of this field is not > >> currently specified. > >> > >> This in essence matches the IEEE spec, which is silent on the > >> subject of sin6_flowinfo. > > > >I understand the problem with the old language, but the new language > >is a bit disturbing too. RFC 2474 and RFC 3168 do specify 8 of these > >bits, and 4 of them are inoperative in the API (the version number bits). > > First let me say I'm open to suggestions for better wording. > > While RFC 2474 and RFC 3168 specify bits in the IPv4 and IPv6 headers, > they do not specify anything about the use of sin6_flowinfo to affect > or retrieve those bits. The same problem exists with the original > reference to RFC 2460, which specifies the format of the IPv6 header, > but does not specify anything about sin6_flowinfo. > > Even if we assume the sin6_flowinfo field is formatted in the same > way as the first 4 bytes of the IPv6 header (i.e. version, class, > and flow), we still have not specified how the sin6_flowinfo field > is used. > > So we have two choices: hold rfc2553bis while we define the use > of the sin6_flowinfo field, or defer that definition to another > spec as we did with sin6_scope_id (rfc2553bis-08 reflects the > latter choice). > > - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 05:30:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7DUvkd000835; Thu, 7 Nov 2002 05:30:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7DUues000834; Thu, 7 Nov 2002 05:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7DUqkd000827 for ; Thu, 7 Nov 2002 05:30:52 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7DV1bB015909 for ; Thu, 7 Nov 2002 05:31:01 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27085 for ; Thu, 7 Nov 2002 05:30:55 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA7DUml08088; Thu, 7 Nov 2002 08:30:48 -0500 (EST) Message-Id: <200211071330.gA7DUml08088@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: awhite@arc.corp.mot.com cc: IPng Subject: Re: Scoping Scoped Addresses In-reply-to: (Your message of "Thu, 07 Nov 2002 17:30:53 +1100.") <3DCA089D.3DD20EDE@motorola.com> Date: Thu, 07 Nov 2002 08:30:48 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This seems like a good start. I think it would help to provide some advice to applications regarding site-locals (and for that matter link-locals). e.g. - don't use site-locals in referrals unless you have no global addresses. - use global addresses in preference to site-locals when opening new connections. I think there will be enough desire to use site-locals at least for limited-purposes in networks that also have stable globals, and that it will be useful to provide some advice on how to constrain such use. I think there is a need for sites to acquire globals even if they do not connect to the public Internet. I don't think coordinating use of site-locals will scale. I think it needs to be explained that site-locals don't really provide a security benefit. What did I miss? > So, lets summarise again: > > - In isolated and unconnected networks, site locals work fine. > > - If a stable global prefix is available, we strongly recommend using that > and not using site locals. > > - Site locals and global addresses can exist in parallel on the same > network, but this is likely to cause address selection problems for > applications. > > - A site is demarcated by the presence of routers that will not forward > packets using site-local addresses (in source or destination). Routers that > are not part of a site should not forward such packets. > > - If multiple networks are to be connected using site local addresses, they > must be configured to be a single site. > > - Site local addresses are explicitly invalid outside their site. > Connectivity external to a site MUST NOT be done with site local addresses. > Sites MUST NOT route packets with site local addresses outside the site. > > - Proxying or otherwise attempting to connect site local addresses to the > global internet (eg NAT) is explicitly discouraged. > > Note: It might be possible to have site local traffic sent over a tunnel (eg > a VPN). In such a situation, the VPN should be treated virtually as part of > the site. Site local addresses must not leak outside the tunnel. Though > there are probably better ways to do this than using site locals. > > > Does this seem a fair summary of principles thus far? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 05:39:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Ddhkd000931; Thu, 7 Nov 2002 05:39:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7Ddhdb000930; Thu, 7 Nov 2002 05:39:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Ddakd000912 for ; Thu, 7 Nov 2002 05:39:37 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7DdjMq007707 for ; Thu, 7 Nov 2002 05:39:45 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05910 for ; Thu, 7 Nov 2002 06:39:40 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA7DdZl08107; Thu, 7 Nov 2002 08:39:35 -0500 (EST) Message-Id: <200211071339.gA7DdZl08107@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: awhite@arc.corp.mot.com cc: IPng Subject: Re: Scoping Scoped Addresses In-reply-to: (Your message of "Thu, 07 Nov 2002 17:47:46 +1100.") <3DCA0C92.38CA6B4A@motorola.com> Date: Thu, 07 Nov 2002 08:39:35 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I don't follow your analogy. Let me try one of my own. Expecting > > apps to use SLs is like expecting that someone who is married to > > a person named "mary" will be equally satisfied with the person > > named "mary" in whatever town he happens to be in (if there is one), > > or that he'll be satisfied if he cannot telephone his wife (or reaches > > a different person) if he isn't in his hometown. > > Ah. I understand now, and this does highlight a potential problem. It's > not just about filtering traffic between sites. In the case where a node > leaves one site and moves to another, all site-scoped references to the old > site must be invalidated too. I hadn't thought of that case, but you are right. For a host using mobile-ip the site-local address is not necessarily more stable than the global address. > If I have a cached reference to "mary" in my original site, it is unlikely > to do what I expect in my new site. > > The presence of the interface id will help reduce this problem, but will not > eliminate it. Well, the host knows that it has moved, and any processes on that host can figure it out by various means. With some work the host and applications could invalidate their own references to site locals from the old site. However the host may not be able to invalidate other hosts' or processes' references to that hosts's old site-local address. > So a problem with site locals is that applications must not pass these > addresses (and perhaps names) around as if they were globally scoped, which > means that any application that could distribute or store addresses should > be aware of them and behave accordingly. Alternatively, the user has to > make sure that the purity of the site is preserved. Both options have > drawbacks. Seems right. And one of my primary goals here is to relieve applications of the burden of trying to deal with site-locals when those applications cross site boundaries. Having those apps refuse to use SLs and LLs in referrals (when globals are available) is a reasonable strategy as long as those apps have global addresses to use instead. > Using unique addresses and prefixes removes the non-uniqueness problem > (addresses moved outside their intended scope simply fail), but reintroduces > the need for administration. I'm not sure what you mean by 'the need for administration'. Or are you just saying that we need a way to assign unique prefixes for those sites? 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 Nov 7 05:42:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Dgrkd000981; Thu, 7 Nov 2002 05:42:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7DgqY5000980; Thu, 7 Nov 2002 05:42: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Dgmkd000973 for ; Thu, 7 Nov 2002 05:42:48 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7DgvbB018226 for ; Thu, 7 Nov 2002 05:42:57 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02963 for ; Thu, 7 Nov 2002 05:42:51 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA7DfTl08149; Thu, 7 Nov 2002 08:41:29 -0500 (EST) Message-Id: <200211071341.gA7DfTl08149@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Margaret Wasserman , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: A few comments on Site-Local Useage In-reply-to: (Your message of "Thu, 07 Nov 2002 10:08:04 +0200.") Date: Thu, 07 Nov 2002 08:41:29 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What I meant to say that to implement site-locals properly in a router, > the vendor should not be OK to say "we support access-lists, you can use > them to configure site-local borders" or that "we have nice firewall > products, wanna buy one?". I'm not sure about that. Having routers try to automagically determine site boundaries sounds nice, unless there are cases where it will fail. If the latter is true, then requiring explicit filter configuration seems like the way to go. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 06:16:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7EGLkd001429; Thu, 7 Nov 2002 06:16:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7EGLxg001428; Thu, 7 Nov 2002 06:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7EGIkd001421 for ; Thu, 7 Nov 2002 06:16:18 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7EGQbB025302 for ; Thu, 7 Nov 2002 06:16:27 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23656 for ; Thu, 7 Nov 2002 07:16:20 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gA7Dslx12511; Thu, 7 Nov 2002 15:54:53 +0200 Date: Thu, 7 Nov 2002 15:54:32 +0200 (EET) From: Pekka Savola To: Keith Moore cc: Margaret Wasserman , Bob Hinden , Subject: Re: A few comments on Site-Local Useage In-Reply-To: <200211071341.gA7DfTl08149@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 7 Nov 2002, Keith Moore wrote: > > What I meant to say that to implement site-locals properly in a router, > > the vendor should not be OK to say "we support access-lists, you can use > > them to configure site-local borders" or that "we have nice firewall > > products, wanna buy one?". > > I'm not sure about that. Having routers try to automagically determine > site boundaries sounds nice, unless there are cases where it will fail. > If the latter is true, then requiring explicit filter configuration seems > like the way to go. .. which brings me back to my original point that the spec text should be written in such a fashion that people don't expect the site-local filters to "just work", but that people need to do it themselves. I'm not sure if folks really understand the security impleications (or lack thereof) when dealing with site-locals, and the spec doesn't make it any better. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 06:41:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Ef0kd001748; Thu, 7 Nov 2002 06:41:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7Ef0cJ001747; Thu, 7 Nov 2002 06:41:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Eeukd001740 for ; Thu, 7 Nov 2002 06:40:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7Ef5Mq025359 for ; Thu, 7 Nov 2002 06:41:05 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10905 for ; Thu, 7 Nov 2002 07:41:00 -0700 (MST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id gA7EeWiZ025667; Thu, 7 Nov 2002 09:40:32 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 7 Nov 2002 09:41:09 -0500 Message-ID: <3DCA7C69.2020008@nc.rr.com> Date: Thu, 07 Nov 2002 09:44:57 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Keith Moore , Margaret Wasserman , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: A few comments on Site-Local Useage References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > On Thu, 7 Nov 2002, Keith Moore wrote: > >>>What I meant to say that to implement site-locals properly in a router, >>>the vendor should not be OK to say "we support access-lists, you can use >>>them to configure site-local borders" or that "we have nice firewall >>>products, wanna buy one?". >> >>I'm not sure about that. Having routers try to automagically determine >>site boundaries sounds nice, unless there are cases where it will fail. >>If the latter is true, then requiring explicit filter configuration seems >>like the way to go. > > > .. which brings me back to my original point that the spec text should be > written in such a fashion that people don't expect the site-local filters > to "just work", but that people need to do it themselves. > > I'm not sure if folks really understand the security impleications (or > lack thereof) when dealing with site-locals, and the spec doesn't make it > any better. > The original intent in the scoped addr arch was that the site-local zone id would be indicate which interfaces are within a site. The filtering between sites is handled by the forwarding code. Vendors that support these zone ids will have default values for the zone ids. If the vendors don't support the zone ids, the box will be unable to act as a SBR unless the user builds the filters. 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 Nov 7 06:50:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Eo1kd001815; Thu, 7 Nov 2002 06:50:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7Eo10J001814; Thu, 7 Nov 2002 06:50:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Enwkd001807 for ; Thu, 7 Nov 2002 06:49:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7Eo6bB003359 for ; Thu, 7 Nov 2002 06:50:06 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15317 for ; Thu, 7 Nov 2002 07:50:00 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gA7Enef13079; Thu, 7 Nov 2002 16:49:40 +0200 Date: Thu, 7 Nov 2002 16:49:40 +0200 (EET) From: Pekka Savola To: Brian Haberman cc: Keith Moore , Margaret Wasserman , Bob Hinden , Subject: Re: A few comments on Site-Local Useage In-Reply-To: <3DCA7C69.2020008@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 7 Nov 2002, Brian Haberman wrote: > Pekka Savola wrote: > > On Thu, 7 Nov 2002, Keith Moore wrote: > > > >>>What I meant to say that to implement site-locals properly in a router, > >>>the vendor should not be OK to say "we support access-lists, you can use > >>>them to configure site-local borders" or that "we have nice firewall > >>>products, wanna buy one?". > >> > >>I'm not sure about that. Having routers try to automagically determine > >>site boundaries sounds nice, unless there are cases where it will fail. > >>If the latter is true, then requiring explicit filter configuration seems > >>like the way to go. > > > > > > .. which brings me back to my original point that the spec text should be > > written in such a fashion that people don't expect the site-local filters > > to "just work", but that people need to do it themselves. > > > > I'm not sure if folks really understand the security impleications (or > > lack thereof) when dealing with site-locals, and the spec doesn't make it > > any better. > > > > The original intent in the scoped addr arch was that the site-local > zone id would be indicate which interfaces are within a site. The > filtering between sites is handled by the forwarding code. > > Vendors that support these zone ids will have default values for the > zone ids. If the vendors don't support the zone ids, the box will > be unable to act as a SBR unless the user builds the filters. I expect many routers will be used in the border of a site and a global internet which do not implement the scoped addr arch draft/document, at least in full. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 06:50:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7EoIkd001831; Thu, 7 Nov 2002 06:50:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7EoHik001830; Thu, 7 Nov 2002 06:50:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7EoDkd001823 for ; Thu, 7 Nov 2002 06:50:14 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7EoMbB003401 for ; Thu, 7 Nov 2002 06:50:22 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07139 for ; Thu, 7 Nov 2002 06:50:16 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 9A71E4B22; Thu, 7 Nov 2002 23:50:13 +0900 (JST) To: Brian Haberman Cc: ipng@sunroof.eng.sun.com In-reply-to: bkhabs's message of Thu, 07 Nov 2002 09:44:57 EST. <3DCA7C69.2020008@nc.rr.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: A few comments on Site-Local Useage From: itojun@iijlab.net Date: Thu, 07 Nov 2002 23:50:13 +0900 Message-Id: <20021107145013.9A71E4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The original intent in the scoped addr arch was that the site-local >zone id would be indicate which interfaces are within a site. The >filtering between sites is handled by the forwarding code. > >Vendors that support these zone ids will have default values for the >zone ids. If the vendors don't support the zone ids, the box will >be unable to act as a SBR unless the user builds the filters. "default value for zone ids"? which document suggests that? i have never seen such docs. draft-ietf-ipngwg-scoping-arch-04.txt talks about default zone id for global address (= 0), but is silent about site-locals to me. 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 Nov 7 06:56:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Eu4kd001952; Thu, 7 Nov 2002 06:56:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7Eu4bW001951; Thu, 7 Nov 2002 06:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Eu1kd001941 for ; Thu, 7 Nov 2002 06:56:01 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7EuAMq028810 for ; Thu, 7 Nov 2002 06:56:10 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11152 for ; Thu, 7 Nov 2002 06:56:04 -0800 (PST) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id gA7EsXid000771; Thu, 7 Nov 2002 09:55:38 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 7 Nov 2002 09:55:16 -0500 Message-ID: <3DCA7FB8.5010207@nc.rr.com> Date: Thu, 07 Nov 2002 09:59:04 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: itojun@iijlab.net CC: ipng@sunroof.eng.sun.com Subject: Re: A few comments on Site-Local Useage References: <20021107145013.9A71E4B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: >>The original intent in the scoped addr arch was that the site-local >>zone id would be indicate which interfaces are within a site. The >>filtering between sites is handled by the forwarding code. >> >>Vendors that support these zone ids will have default values for the >>zone ids. If the vendors don't support the zone ids, the box will >>be unable to act as a SBR unless the user builds the filters. > > > "default value for zone ids"? which document suggests that? > i have never seen such docs. draft-ietf-ipngwg-scoping-arch-04.txt > talks about default zone id for global address (= 0), but is silent > about site-locals to me. > > itojun > From Section 6: An implementation should also support the concept of a "default" zone for each scope. It is convenient to reserve the index value zero, at each scope, to mean "use the default zone". Unlike other zone indices, the default ID does not contain any scope type, and the scope type is determined by the address by which the default ID was accompanied. An implementation may additionally define a separate default zone for each scope type. Those default indices can also be used as the zone qualifier for an address for which the node is attached to only one zone, e.g., when using global addresses. 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 Nov 7 07:13:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7FD8kd002147; Thu, 7 Nov 2002 07:13:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7FD8Kd002146; Thu, 7 Nov 2002 07:13:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7FD4kd002139 for ; Thu, 7 Nov 2002 07:13:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7FDDbB009263 for ; Thu, 7 Nov 2002 07:13:13 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27678 for ; Thu, 7 Nov 2002 08:13:07 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA24907 for ; Thu, 7 Nov 2002 15:13:06 GMT Received: from starling.ecs.soton.ac.uk (starling.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gA7FCuWX030689 for ; Thu, 7 Nov 2002 15:12:56 GMT Received: (from tjc@localhost) by starling.ecs.soton.ac.uk (8.11.6/8.11.6) id gA7FCuN02114 for ipng@sunroof.eng.sun.com; Thu, 7 Nov 2002 15:12:56 GMT Date: Thu, 7 Nov 2002 15:12:56 +0000 From: Tim Chown To: IPng Subject: Re: Scoping Scoped Addresses Message-ID: <20021107151256.GM1683@starling.ecs.soton.ac.uk> Mail-Followup-To: IPng References: <3DCA089D.3DD20EDE@motorola.com> <200211071330.gA7DUml08088@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211071330.gA7DUml08088@astro.cs.utk.edu> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Nov 07, 2002 at 08:30:48AM -0500, Keith Moore wrote: > This seems like a good start. Indeed, shame it didn't come 200 emails ago ;-) It seems some concensus can be reached on the assumption that site locals will continue to exist, although many of us may be happy to not use them. Darwinism may prevail here. > I think it would help to provide some advice to applications regarding > site-locals (and for that matter link-locals). e.g. > > - don't use site-locals in referrals unless you have no global addresses. > - use global addresses in preference to site-locals when opening new > connections. Although that removes the advantage of site local addressing allowing long-lived connections (e.g. NFS) to survive renumbering, or temporary or permanent removal of external connectivity. The implications on deprecation of the global prefix differ depending on whether the site can reconnect later with the same global prefix (ie. the ISP uses static /48 assignments or not), but maybe that is a dangerous path to explore. The applications advice also implies some note required for DNS behaviour, in terms of what is offered in response to a remote query and how it is handled (or not). > I think there will be enough desire to use site-locals at least for > limited-purposes in networks that also have stable globals, and that > it will be useful to provide some advice on how to constrain such use. Maybe add a note that well-known site locals may be recommended or suggested for service discovery for certain services (witness the recent DNS discussion), so there's one use (which is in the spirit of site locals, and where cross- site connectivity is probably not rquired). Many networks use private IP space for network management (in or out of band); site locals may (will?) have a similar popular use in IPv6. Of course at the moment IPv4 access is used for most IPv6 network management(!). We may find that site-locals offer some use in future renumbering, multihoming or other service solutions, that have not been foreseen yet. > I think there is a need for sites to acquire globals even if they do > not connect to the public Internet. I don't think coordinating use > of site-locals will scale. The question then is who maintains the "site-local global"(sic) address space? If it is not coordinated and unique, do you really buy much over site locals which are only unique to the site? Or are you suggesting to go to an ISP for a /48 and a 0Mbps link? :) Site locals can allow more than /48's to be used for a "super site". What size allocations would you advocate for "site-local globals"? Maybe this is a service an exchange can offer, on a regional basis, to cater for the bulk of (non-international) cases. > I think it needs to be explained that site-locals don't really provide > a security benefit. I think this is very important. But people will be free to > What did I miss? I think you've been quite thorough :) Pekka's concerns are also very valid. Tim > > So, lets summarise again: > > > > - In isolated and unconnected networks, site locals work fine. > > > > - If a stable global prefix is available, we strongly recommend using that > > and not using site locals. > > > > - Site locals and global addresses can exist in parallel on the same > > network, but this is likely to cause address selection problems for > > applications. > > > > - A site is demarcated by the presence of routers that will not forward > > packets using site-local addresses (in source or destination). Routers that > > are not part of a site should not forward such packets. > > > > - If multiple networks are to be connected using site local addresses, they > > must be configured to be a single site. > > > > - Site local addresses are explicitly invalid outside their site. > > Connectivity external to a site MUST NOT be done with site local addresses. > > Sites MUST NOT route packets with site local addresses outside the site. > > > > - Proxying or otherwise attempting to connect site local addresses to the > > global internet (eg NAT) is explicitly discouraged. > > > > Note: It might be possible to have site local traffic sent over a tunnel (eg > > a VPN). In such a situation, the VPN should be treated virtually as part of > > the site. Site local addresses must not leak outside the tunnel. Though > > there are probably better ways to do this than using site locals. > > > > > > Does this seem a fair summary of principles thus far? > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 7 07:44:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Fidkd002352; Thu, 7 Nov 2002 07:44:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7FidPw002351; Thu, 7 Nov 2002 07:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Fiakd002344 for ; Thu, 7 Nov 2002 07:44:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7FiibB015865 for ; Thu, 7 Nov 2002 07:44:45 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13205 for ; Thu, 7 Nov 2002 08:44:39 -0700 (MST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA04632 for ; Thu, 7 Nov 2002 10:44:38 -0500 (EST) Message-Id: <4.3.2.7.2.20021107104149.00b96c78@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Nov 2002 10:44:36 -0500 To: IPng From: Ralph Droms Subject: Re: Scoping Scoped Addresses In-Reply-To: <200211071339.gA7DdZl08107@astro.cs.utk.edu> References: <(Your message of "Thu, 07 Nov 2002 17:47:46 +1100.") <3DCA0C92.38CA6B4A@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:39 AM 11/7/2002 -0500, Keith Moore wrote: > > > I don't follow your analogy. Let me try one of my own. Expecting > > > apps to use SLs is like expecting that someone who is married to > > > a person named "mary" will be equally satisfied with the person > > > named "mary" in whatever town he happens to be in (if there is one), > > > or that he'll be satisfied if he cannot telephone his wife (or reaches > > > a different person) if he isn't in his hometown. > > > > Ah. I understand now, and this does highlight a potential problem. It's > > not just about filtering traffic between sites. In the case where a node > > leaves one site and moves to another, all site-scoped references to the old > > site must be invalidated too. > >I hadn't thought of that case, but you are right. For a host using mobile-ip >the site-local address is not necessarily more stable than the global >address. Is this situation - a mobile node using site-local addresses moving to a new "site" - an opportunity for inadvertent (or possibly even malicious) TCP session hijacking? I.e., is the problem worse in the case of active applications that may be affected by the move to a new site? - 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 Nov 7 08:10:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7GABkd002517; Thu, 7 Nov 2002 08:10:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7GAAoX002516; Thu, 7 Nov 2002 08:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7GA7kd002509 for ; Thu, 7 Nov 2002 08:10:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7GAFbB023238 for ; Thu, 7 Nov 2002 08:10:16 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00624 for ; Thu, 7 Nov 2002 09:10:05 -0700 (MST) Received: from newton.cs.uni-bonn.de (newton.cs.uni-bonn.de [131.220.4.212]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id RAA13342; Thu, 7 Nov 2002 17:10:04 +0100 (MET) Received: (from ignatios@localhost) by newton.cs.uni-bonn.de (8.9.1a/8.9.1) id RAA17633; Thu, 7 Nov 2002 17:10:03 +0100 (CET) Date: Thu, 7 Nov 2002 17:10:03 +0100 From: Ignatios Souvatzis To: Ralph Droms Cc: IPng Subject: Re: Scoping Scoped Addresses Message-ID: <20021107171003.E16148@newton.cs.uni-bonn.de> References: <(Your <3DCA0C92.38CA6B4A@motorola.com> <200211071339.gA7DdZl08107@astro.cs.utk.edu> <4.3.2.7.2.20021107104149.00b96c78@funnel.cisco.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="dFWYt1i2NyOo1oI9" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20021107104149.00b96c78@funnel.cisco.com>; from rdroms@cisco.com on Thu, Nov 07, 2002 at 10:44:36AM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --dFWYt1i2NyOo1oI9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Nov 07, 2002 at 10:44:36AM -0500, Ralph Droms wrote: =20 > Is this situation - a mobile node using site-local addresses moving to a= =20 > new "site" - an opportunity for inadvertent (or possibly even malicious)= =20 > TCP session hijacking? I.e., is the problem worse in the case of active= =20 > applications that may be affected by the move to a new site? Shouldn't DAD detect this? -is --dFWYt1i2NyOo1oI9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPcqQWTCn4om+4LhpAQGlvwf/R/MSYCO7Q8Yhfghj7+8aYla9WdLA0CrU fJb0oqJQ01ffLSbRoXG+8gInkSqwLK+UI3WcdvRyaEq375iruun+oehXwrzKnmxN zI0RvDUNzLjIpm2hD+2cKHKZm1HRewfCvTwO5vbubQtrFG+WF7tRrYURkZ61FhrU UY2IZwh2Os0quZ611ZB00boLkWtWgAnJQce1lHsGMA0Skf7bOo/juKqonYSsx0R4 zMVyzfd/chvgWGlfOEcIqhQNB125e8zmIFoBvEzghrwkOjuQYRpFasZa2jMueIjH lAwvnNKR8LW5Il7YCGJK7MbaPGgKbgUMPout4I3xCFjpLIRW06oaPg== =5aol -----END PGP SIGNATURE----- --dFWYt1i2NyOo1oI9-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 08:20:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7GKrkd002582; Thu, 7 Nov 2002 08:20:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7GKr8U002581; Thu, 7 Nov 2002 08:20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7GKnkd002574 for ; Thu, 7 Nov 2002 08:20:49 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7GKvMq021202 for ; Thu, 7 Nov 2002 08:20:57 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04038 for ; Thu, 7 Nov 2002 08:20:52 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA7GKnl09964; Thu, 7 Nov 2002 11:20:49 -0500 (EST) Message-Id: <200211071620.gA7GKnl09964@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tim Chown cc: IPng Subject: Re: Scoping Scoped Addresses In-reply-to: (Your message of "Thu, 07 Nov 2002 15:12:56 GMT.") <20021107151256.GM1683@starling.ecs.soton.ac.uk> Date: Thu, 07 Nov 2002 11:20:49 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On Thu, Nov 07, 2002 at 08:30:48AM -0500, Keith Moore wrote: > > This seems like a good start. > > Indeed, shame it didn't come 200 emails ago ;-) It seems some concensus > can be reached on the assumption that site locals will continue to exist, > although many of us may be happy to not use them. Darwinism may > prevail here. aside: I realize that evolutionary theory has taken on almost axiomatic status for many people, but it's not clear to me that Darwinian selection really does select the fittest candidate for the long term in a global environment, any more than hill-climbing methods of optimization produce the best solution over an entire solution-space. > > I think it would help to provide some advice to applications regarding > > site-locals (and for that matter link-locals). e.g. > > > > - don't use site-locals in referrals unless you have no global addresses. > > - use global addresses in preference to site-locals when opening new > > connections. > > Although that removes the advantage of site local addressing allowing > long-lived connections (e.g. NFS) to survive renumbering, or temporary or > permanent removal of external connectivity. right. it would still be possible to explicitly specify SLs, though explicitly specifying any IPv6 address seems likely to be viewed as painful. > The implications on > deprecation of the global prefix differ depending on whether the site can > reconnect later with the same global prefix (ie. the ISP uses static /48 > assignments or not), but maybe that is a dangerous path to explore. right. you really want to treat stable prefixes differently from unstable ones, but how is the application to know which are which? > The applications advice also implies some note required for DNS behaviour, > in terms of what is offered in response to a remote query and how it is > handled (or not). what is a remote query? DNS needs to produce consistent results no matter where the request comes from. I don't really think that DNS should be treated any differently than any other app that performs referrals. If we find ourselves wanting/needing to make special exceptions for DNS in order to accomodate scoped addresses that is a sign that we're probably breaking other apps. > > I think there will be enough desire to use site-locals at least for > > limited-purposes in networks that also have stable globals, and that > > it will be useful to provide some advice on how to constrain such use. > > Maybe add a note that well-known site locals may be recommended or suggested > for service discovery for certain services (witness the recent DNS > discussion), so there's one use (which is in the spirit of site locals, > and where cross-site connectivity is probably not rquired). > > Many networks use private IP space for network management (in or out of > band); site locals may (will?) have a similar popular use in IPv6. Of > course at the moment IPv4 access is used for most IPv6 network management(!). they could. though again, specifying IP address literals will probably seem painful. of course, in the case of SLs, that might be a Good Thing. > We may find that site-locals offer some use in future renumbering, > multihoming or other service solutions, that have not been foreseen yet. certainly they could be useful in renumbering. > > I think there is a need for sites to acquire globals even if they do > > not connect to the public Internet. I don't think coordinating use > > of site-locals will scale. > > The question then is who maintains the "site-local global"(sic) address > space? I have several (possibly lame) ideas: - IANA and/or RIRs delegate prefix blocks to the registrars that are already qualified to sell domain names, who can then sell such prefixes. - we find some way to derive a unique 48-bit prefix from an Ethernet address which doesn't eat up all of the v6 address space and doesn't conflict with existing address allocations. then, any site can take an Ethernet address and derive a prefix from it. (I don't remember how many bits of Ethernet address space are reserved for things like global/private or unicast/multicast, so I don't know how much we can shrink down a 48 bit Ethernet address and still be assured of having a unique bit pattern. and this doesn't solve the problem for interfaces that use 64 bit hardware addresses) a site could continue to use that prefix as long as it kept the hardware with that ethernet interface in its possession. (so you could sell the router but keep the ethernet card. or you could sell the card but keep the address rom. :) - IANA delegates prefix blocks to router vendors, who assign them to their customers by means of their choosing (provided that at most one prefix is assigned per router). for instance, a prefix might be included with each router, and printed on a label on the side of the box. (the router should not expect that prefix to actually be used) a site could continue to use that prefix as long as it kept that label :) offhand, the last idea seems the most attractive, but I don't claim to be aware of all of the implications. Ideally allocations of globally-unique private addresses (GUPAs?) would be /48s, as this would simplify renumbering and having multiple prefixes when it was necessary to do so. 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 Nov 7 09:10:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7HA7kd002879; Thu, 7 Nov 2002 09:10:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7HA7WP002878; Thu, 7 Nov 2002 09:10:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7HA3kd002871 for ; Thu, 7 Nov 2002 09:10:03 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7HABMq004114 for ; Thu, 7 Nov 2002 09:10:11 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25738 for ; Thu, 7 Nov 2002 10:10:06 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA7HA5l10275; Thu, 7 Nov 2002 12:10:05 -0500 (EST) Message-Id: <200211071710.gA7HA5l10275@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: IPng Subject: question regarding possible use of SLs in renumbering cc: moore@cs.utk.edu From: Keith Moore Date: Thu, 07 Nov 2002 12:10:05 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk question: is it reasonable to assume that if a network is advertising one or more global prefixes via ND/RD, that the scope of a 'site' for SL addresses corresponds to the scope in which those global prefixes are advertised? in other words, would it really be reasonable to assume that one could use SL addresses in some renumbering protocol and have them be able to reach all of the hosts/routers/apps that were affected by a prefix change? 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 Nov 7 10:50:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7IoLkd004162; Thu, 7 Nov 2002 10:50:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7IoKjY004161; Thu, 7 Nov 2002 10:50:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7IoHkd004154 for ; Thu, 7 Nov 2002 10:50:17 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7IoNbB009591 for ; Thu, 7 Nov 2002 10:50:23 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19890 for ; Thu, 7 Nov 2002 10:50:17 -0800 (PST) Subject: RE: question regarding possible use of SLs in renumbering Date: Thu, 7 Nov 2002 10:50:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B04640BD309@server2000> X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: question regarding possible use of SLs in renumbering Thread-Index: AcKGge/sQXYjQ4y4TWuyZAfhIXtt4QADDm/Q From: "Michel Py" To: "Keith Moore" , "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA7IoHkd004155 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore wrote: > is it reasonable to assume that if a network is advertising > one or more global prefixes via ND/RD, that the scope of > a 'site' for SL addresses corresponds to the scope in which > those global prefixes are advertised? in other words, would > it really be reasonable to assume that one could use SL > addresses in some renumbering protocol and have them be able > to reach all of the hosts/routers/apps that were affected by > a prefix change? You mean, as a temporary state between renumbering between two global addresses? 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 Nov 7 11:09:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7J95kd004254; Thu, 7 Nov 2002 11:09:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7J95wK004253; Thu, 7 Nov 2002 11:09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7J91kd004246 for ; Thu, 7 Nov 2002 11:09:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7J99bB016386 for ; Thu, 7 Nov 2002 11:09:09 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26146 for ; Thu, 7 Nov 2002 12:09:03 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA7J8kl14005; Thu, 7 Nov 2002 14:08:47 -0500 (EST) Message-Id: <200211071908.gA7J8kl14005@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "IPng" Subject: Re: question regarding possible use of SLs in renumbering In-reply-to: (Your message of "Thu, 07 Nov 2002 10:50:36 PST.") <2B81403386729140A3A899A8B39B04640BD309@server2000> Date: Thu, 07 Nov 2002 14:08:46 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > is it reasonable to assume that if a network is advertising > > one or more global prefixes via ND/RD, that the scope of > > a 'site' for SL addresses corresponds to the scope in which > > those global prefixes are advertised? in other words, would > > it really be reasonable to assume that one could use SL > > addresses in some renumbering protocol and have them be able > > to reach all of the hosts/routers/apps that were affected by > > a prefix change? > > You mean, as a temporary state between renumbering between two global > addresses? not just then - during a period prior to renumbering, during overlap, or afterward, do the scopes of SLs and prefixes necessarily coincide? I'm just trying to understand if SLs really do have utility in a renumbering protocol. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 11:30:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7JURkd004431; Thu, 7 Nov 2002 11:30:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7JUQpi004430; Thu, 7 Nov 2002 11:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7JUNkd004423 for ; Thu, 7 Nov 2002 11:30:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7JUWMq022565 for ; Thu, 7 Nov 2002 11:30:32 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12489 for ; Thu, 7 Nov 2002 12:30:26 -0700 (MST) Received: from kenawang.windriver.com ([192.168.1.99]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA21919; Thu, 7 Nov 2002 11:30:09 -0800 (PST) Message-Id: <5.1.0.14.2.20021107142950.0347eec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Nov 2002 14:31:53 -0500 To: Keith Moore From: Margaret Wasserman Subject: Re: question regarding possible use of SLs in renumbering Cc: IPng , moore@cs.utk.edu In-Reply-To: <200211071710.gA7HA5l10275@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Keith, The architecture does not require any correspondence between site boundaries and the sets of links upon which a single global routing prefix is advertised. Margaret At 12:10 PM 11/7/02, Keith Moore wrote: >question: > >is it reasonable to assume that if a network is advertising one or more >global prefixes via ND/RD, that the scope of a 'site' for SL addresses >corresponds to the scope in which those global prefixes are advertised? > >in other words, would it really be reasonable to assume that one could >use SL addresses in some renumbering protocol and have them be able to >reach all of the hosts/routers/apps that were affected by a prefix change? > >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 11:31:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7JVJkd004475; Thu, 7 Nov 2002 11:31:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7JVJWX004474; Thu, 7 Nov 2002 11:31:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7JVFkd004464 for ; Thu, 7 Nov 2002 11:31:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7JVNbB023827 for ; Thu, 7 Nov 2002 11:31:24 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13241 for ; Thu, 7 Nov 2002 12:31:18 -0700 (MST) Subject: RE: question regarding possible use of SLs in renumbering Date: Thu, 7 Nov 2002 11:31:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E430@server2000> X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: question regarding possible use of SLs in renumbering Thread-Index: AcKGkVCoV6ZjRMtHS36CSK2rSU7mggAABfFg From: "Michel Py" To: "Keith Moore" Cc: "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA7JVFkd004465 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> You mean, as a temporary state between renumbering >> between two global addresses? > Keith Moore wrote: > not just then - during a period prior to renumbering, > during overlap, or afterward, do the scopes of SLs and > prefixes necessarily coincide? They might, and the addresses might have a one-to-one relation too. For example, this kind of scheme will appeal administrators: 2001:xxxx:yyyy:1234:IID FEC0:0000:0000:1234:IID > I'm just trying to understand if SLs really do have > utility in a renumbering protocol. In theory, yes. In practice, I doubt it though. As Bob mentioned, configuring SLs is a manual operation; unless there are some new developments that I am not aware of, I don't see how this could realistically be automated. IMHO, the relation between SLs and renumbering is this: SLs are used in parts of the network that have no access to the public Internet in order to avoid the renumbering of that part in case of an ISP change on the part that does have access to the outside. This is especially important on networks when 95% of the network does *not* have access to the Internet. 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 Nov 7 11:34:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7JYXkd004621; Thu, 7 Nov 2002 11:34:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7JYXKR004620; Thu, 7 Nov 2002 11:34:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7JYUkd004610 for ; Thu, 7 Nov 2002 11:34:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7JYcMq024130 for ; Thu, 7 Nov 2002 11:34:38 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14735 for ; Thu, 7 Nov 2002 12:34:06 -0700 (MST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 7 Nov 2002 11:33:53 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 07 Nov 2002 11:33:52 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 7 Nov 2002 11:33:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: question regarding possible use of SLs in renumbering Date: Thu, 7 Nov 2002 11:33:50 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question regarding possible use of SLs in renumbering thread-index: AcKGgYraQYtW92JoRRCMsUn2K52UIgAErKrg From: "Richard Draves" To: "Keith Moore" , "IPng" X-OriginalArrivalTime: 07 Nov 2002 19:33:51.0736 (UTC) FILETIME=[9A090780:01C28694] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA7JYUkd004611 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I'm trying to get caught on the thread after being away for several days.] Yes, it is reasonable to assume that a /48 global prefix corresponds to a site-local scope. I wouldn't rule out other arrangements but I think this will be the common situation. Rich > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, November 07, 2002 9:10 AM > To: IPng > Cc: moore@cs.utk.edu > Subject: question regarding possible use of SLs in renumbering > > > question: > > is it reasonable to assume that if a network is advertising > one or more global prefixes via ND/RD, that the scope of a > 'site' for SL addresses corresponds to the scope in which > those global prefixes are advertised? > > in other words, would it really be reasonable to assume that > one could > use SL addresses in some renumbering protocol and have them > be able to > reach all of the hosts/routers/apps that were affected by a > prefix change? > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 11:44:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Ji4kd004991; Thu, 7 Nov 2002 11:44:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7Ji35e004989; Thu, 7 Nov 2002 11:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Ji0kd004979 for ; Thu, 7 Nov 2002 11:44:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7Ji8Mq027421 for ; Thu, 7 Nov 2002 11:44:08 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20509 for ; Thu, 7 Nov 2002 12:44:01 -0700 (MST) Received: from kenawang.windriver.com ([192.168.1.35]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA01657; Thu, 7 Nov 2002 11:43:25 -0800 (PST) Message-Id: <5.1.0.14.2.20021107144338.02ae0870@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Nov 2002 14:45:08 -0500 To: "Richard Draves" From: Margaret Wasserman Subject: RE: question regarding possible use of SLs in renumbering Cc: "Keith Moore" , "IPng" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Yes, it is reasonable to assume that a /48 global prefix corresponds to >a site-local scope. I wouldn't rule out other arrangements but I think >this will be the common situation. Not necessarily. The issues with global vs. site-local routing in a "site" that had multiple locations connected by leased lines were dismissed, because the multiple locations should be more than one "site". But, even if Wind River would be forced to have 20-something sites by this rule, we would still probably only have a single /48 prefix. 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 Nov 7 12:16:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7KGikd005535; Thu, 7 Nov 2002 12:16:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7KGi5x005534; Thu, 7 Nov 2002 12:16:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7KFYkd005482; Thu, 7 Nov 2002 12:16:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7KFfbB008019; Thu, 7 Nov 2002 12:15:42 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19834; Thu, 7 Nov 2002 13:15:35 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; Subject: Note Well Statement x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 14:33:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7MXRkd006677; Thu, 7 Nov 2002 14:33:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7MXRId006676; Thu, 7 Nov 2002 14:33: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7MXNkd006669 for ; Thu, 7 Nov 2002 14:33:23 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7MXVbB019358 for ; Thu, 7 Nov 2002 14:33:31 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12802 for ; Thu, 7 Nov 2002 15:33:25 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA7MXMl14602; Thu, 7 Nov 2002 17:33:22 -0500 (EST) Message-Id: <200211072233.gA7MXMl14602@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "IPng" Subject: Re: question regarding possible use of SLs in renumbering In-reply-to: (Your message of "Thu, 07 Nov 2002 11:31:35 PST.") <2B81403386729140A3A899A8B39B046405E430@server2000> Date: Thu, 07 Nov 2002 17:33:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > IMHO, the relation between SLs and renumbering is this: SLs are used in > parts of the network that have no access to the public Internet in order > to avoid the renumbering of that part in case of an ISP change on the > part that does have access to the outside. This is especially important > on networks when 95% of the network does *not* have access to the > Internet. using SLs in this way would break applications. we need to discourage this. 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 Nov 7 14:38:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7McPkd006718; Thu, 7 Nov 2002 14:38:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7McPAK006717; Thu, 7 Nov 2002 14:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7McLkd006707 for ; Thu, 7 Nov 2002 14:38:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7McTMq023954 for ; Thu, 7 Nov 2002 14:38:29 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15672 for ; Thu, 7 Nov 2002 15:38:23 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA7McGl14641; Thu, 7 Nov 2002 17:38:16 -0500 (EST) Message-Id: <200211072238.gA7McGl14641@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: "Richard Draves" , "Keith Moore" , "IPng" Subject: Re: question regarding possible use of SLs in renumbering In-reply-to: (Your message of "Thu, 07 Nov 2002 14:45:08 EST.") <5.1.0.14.2.20021107144338.02ae0870@mail.windriver.com> Date: Thu, 07 Nov 2002 17:38:16 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Yes, it is reasonable to assume that a /48 global prefix corresponds to > >a site-local scope. I wouldn't rule out other arrangements but I think > >this will be the common situation. > > Not necessarily. > > The issues with global vs. site-local routing in a "site" that > had multiple locations connected by leased lines were dismissed, > because the multiple locations should be more than one "site". > But, even if Wind River would be forced to have 20-something > sites by this rule, we would still probably only have a single > /48 prefix. this is the sort of thing I was getting at. I have to conclude that using SLs in a renumbering protocol has marginal utility at best. 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 Nov 7 14:39:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7MdRkd006741; Thu, 7 Nov 2002 14:39:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7MdRjC006740; Thu, 7 Nov 2002 14:39:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7MdNkd006733 for ; Thu, 7 Nov 2002 14:39:24 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7MdWbB020872 for ; Thu, 7 Nov 2002 14:39:32 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06707 for ; Thu, 7 Nov 2002 14:39:27 -0800 (PST) Subject: RE: question regarding possible use of SLs in renumbering Date: Thu, 7 Nov 2002 14:39:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B04640BD312@server2000> X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: question regarding possible use of SLs in renumbering Thread-Index: AcKGrdPWGYC8pAqESUGFNOMBlJLaJAAAGhdg From: "Michel Py" To: "Keith Moore" Cc: "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA7MdOkd006734 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> IMHO, the relation between SLs and renumbering is this: SLs >> are used in parts of the network that have no access to the >> public Internet in order to avoid the renumbering of that >> part in case of an ISP change on the part that does have >> access to the outside. This is especially important on >> networks when 95% of the network does *not* have access to >> the Internet. > Keith Moore wrote: > using SLs in this way would break applications. we need to > discourage this. What do you mean by "would break applications"? what is being broken? End-to-end is preserved, there is no NAT nor ALGs, what's your problem here? 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 Nov 7 14:44:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7MiHkd006838; Thu, 7 Nov 2002 14:44:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7MiHxq006837; Thu, 7 Nov 2002 14:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7MiEkd006830 for ; Thu, 7 Nov 2002 14:44:14 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7MiMbB022315 for ; Thu, 7 Nov 2002 14:44:23 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16533 for ; Thu, 7 Nov 2002 14:44:17 -0800 (PST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 7 Nov 2002 14:44:17 -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); Thu, 7 Nov 2002 14:44:16 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 07 Nov 2002 14:44:13 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 7 Nov 2002 14:44:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: question regarding possible use of SLs in renumbering Date: Thu, 7 Nov 2002 14:44:15 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question regarding possible use of SLs in renumbering thread-index: AcKGlf2SxLmquHfMQC2UqVpl3LQHeAAGNNRA From: "Richard Draves" To: "Margaret Wasserman" Cc: "IPng" X-OriginalArrivalTime: 07 Nov 2002 22:44:16.0557 (UTC) FILETIME=[33C25DD0:01C286AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA7MiEkd006831 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The issues with global vs. site-local routing in a "site" > that had multiple locations connected by leased lines were > dismissed, because the multiple locations should be more than > one "site". But, even if Wind River would be forced to have > 20-something sites by this rule, we would still probably only > have a single /48 prefix. What rule is that? Is the routing within Wind River "convex"? Assuming it is, I don't see why you wouldn't make Wind River a single site, even if it is geographically dispersed. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 14:54:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Ms6kd007049; Thu, 7 Nov 2002 14:54:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7Ms6M7007047; Thu, 7 Nov 2002 14:54:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Ms1kd007039 for ; Thu, 7 Nov 2002 14:54:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7MsAMq028742 for ; Thu, 7 Nov 2002 14:54:10 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04254 for ; Thu, 7 Nov 2002 15:54:03 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA7Mrtl14882; Thu, 7 Nov 2002 17:53:55 -0500 (EST) Message-Id: <200211072253.gA7Mrtl14882@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "IPng" Subject: Re: question regarding possible use of SLs in renumbering In-reply-to: (Your message of "Thu, 07 Nov 2002 14:39:45 PST.") <2B81403386729140A3A899A8B39B04640BD312@server2000> Date: Thu, 07 Nov 2002 17:53:55 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Keith Moore wrote: > > using SLs in this way would break applications. we need to > > discourage this. > > What do you mean by "would break applications"? what is being broken? > End-to-end is preserved, there is no NAT nor ALGs, what's your problem > here? Michael, We've been discussing this set of problems for several days now. If you've missed it, I suggest you review the archives. 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 Nov 7 14:58:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7MwBkd007168; Thu, 7 Nov 2002 14:58:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7MwBXp007167; Thu, 7 Nov 2002 14:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7Mw8kd007160 for ; Thu, 7 Nov 2002 14:58:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7MwGMq000067 for ; Thu, 7 Nov 2002 14:58:16 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06437 for ; Thu, 7 Nov 2002 15:58:10 -0700 (MST) Subject: RE: question regarding possible use of SLs in renumbering Date: Thu, 7 Nov 2002 14:58:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B04640BD313@server2000> X-MS-Has-Attach: X-MS-TNEF-Correlator: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: question regarding possible use of SLs in renumbering Thread-Index: AcKGsLdjvKE0tdYwS3qEPDKL5NGelgAAEBSg From: "Michel Py" To: "Keith Moore" Cc: "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA7Mw8kd007161 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> Keith Moore wrote: >>> using SLs in this way would break applications. we need >>> to discourage this. >> What do you mean by "would break applications"? what is >> being broken? End-to-end is preserved, there is no NAT >> nor ALGs, what's your problem here? > We've been discussing this set of problems for several > days now. If you've missed it, I suggest you review the > archives. Since you don't answer the question, I'll answer it myself. Site-locals without NAT do not break applications. 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 Nov 7 15:04:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7N44kd007323; Thu, 7 Nov 2002 15:04:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA7N43Ms007322; Thu, 7 Nov 2002 15:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7N3xkd007315 for ; Thu, 7 Nov 2002 15:04:00 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA7N48Mq001831 for ; Thu, 7 Nov 2002 15:04:08 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20894 for ; Thu, 7 Nov 2002 15:04:02 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA7N40l14988; Thu, 7 Nov 2002 18:04:00 -0500 (EST) Message-Id: <200211072304.gA7N40l14988@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "IPng" Subject: Re: question regarding possible use of SLs in renumbering In-reply-to: (Your message of "Thu, 07 Nov 2002 14:58:28 PST.") <2B81403386729140A3A899A8B39B04640BD313@server2000> Date: Thu, 07 Nov 2002 18:04:00 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Since you don't answer the question, I'll answer it myself. Site-locals > without NAT do not break applications. tell you what. I'll set up a cron job to keep forwarding the same messages to you over and over again until you get a clue. but I won't cc the list. 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 Nov 7 20:19:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA84JEkd008975; Thu, 7 Nov 2002 20:19:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA84JEmE008974; Thu, 7 Nov 2002 20:19: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA84JBkd008967 for ; Thu, 7 Nov 2002 20:19:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA84JJbB011644 for ; Thu, 7 Nov 2002 20:19:19 -0800 (PST) Received: from realname ([203.254.224.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08523 for ; Thu, 7 Nov 2002 21:19:13 -0700 (MST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) id <0H5800701PJX6H@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Fri, 08 Nov 2002 13:23:57 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0H580064MPJWZD@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Fri, 08 Nov 2002 13:23:57 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTPA id <0H5800E5DPLCO9@mmp1.samsung.com> for ipng@sunroof.eng.sun.com; Fri, 08 Nov 2002 13:24:48 +0900 (KST) Date: Fri, 08 Nov 2002 13:16:23 +0900 From: Soohong Daniel Park Subject: IPv6 over PLC ? To: ipng@sunroof.eng.sun.com Message-id: <01ab01c286dd$997325f0$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_01YsEOWoWU4k4oYo03LOuA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_01YsEOWoWU4k4oYo03LOuA) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Almost technic for IPv6 over different media was released, but i couldn't find IPv6 over PLC. ===================================== Soohong Daniel Park Research Engineer Mobile Platform Group Digital Media R&D Center Samsung Electronics Co.,LTD TEL:+82-31-200-3728 FAX:+82-31-200-3147 H.P:+82-11-9950-4655 mailto:soohong.park@samsung.com ===================================== --Boundary_(ID_01YsEOWoWU4k4oYo03LOuA) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT 메시지
Almost technic for IPv6 over different media was released, but i couldn't find IPv6 over PLC.
 
 
            
=====================================
     Soohong Daniel Park
     Research Engineer
     Mobile Platform Group
     Digital Media R&D Center
     Samsung Electronics Co.,LTD
     TEL:+82-31-200-3728
     FAX:+82-31-200-3147
     H.P:+82-11-9950-4655
     mailto:soohong.park@samsung.com
=====================================
 
--Boundary_(ID_01YsEOWoWU4k4oYo03LOuA)-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 21:56:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA85uVkd009443; Thu, 7 Nov 2002 21:56:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA85uVsf009442; Thu, 7 Nov 2002 21:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA85uRkd009435 for ; Thu, 7 Nov 2002 21:56:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA85uabB024610 for ; Thu, 7 Nov 2002 21:56:36 -0800 (PST) Received: from consulintel.es ([213.172.48.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA11071 for ; Thu, 7 Nov 2002 22:56:29 -0700 (MST) Received: from consulintel02 ([217.126.187.160]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Fri, 08 Nov 2002 07:01:14 +0100 Message-ID: <00ed01c286ec$3d554f00$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <01ab01c286dd$997325f0$b7cbdba8@daniel7209> Subject: Re: IPv6 over PLC ? Date: Fri, 8 Nov 2002 07:01:10 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EA_01C286F4.9E8D2E70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00EA_01C286F4.9E8D2E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ???We are working on it. See www.6power.org. Regards, Jordi ----- Original Message -----=20 From: Soohong Daniel Park=20 To: ipng@sunroof.eng.sun.com=20 Sent: Friday, November 08, 2002 5:16 AM Subject: IPv6 over PLC ? Almost technic for IPv6 over different media was released, but i = couldn't find IPv6 over PLC. =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Soohong Daniel Park Research Engineer Mobile Platform Group Digital Media R&D Center Samsung Electronics Co.,LTD TEL:+82-31-200-3728 FAX:+82-31-200-3147 H.P:+82-11-9950-4655 mailto:soohong.park@samsung.com = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D *********************************** Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Soon on line at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es ------=_NextPart_000_00EA_01C286F4.9E8D2E70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 메시지
We are working on it. See www.6power.org.
 
Regards,
Jordi
----- Original Message -----
From:=20 Soohong Daniel Park =
Sent: Friday, November 08, 2002 = 5:16=20 AM
Subject: IPv6 over PLC ?

Almost technic = for IPv6 over=20 different media was released, but i couldn't find IPv6 over=20 PLC.
 
 
          &nbs= p; =20 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    &nb= sp;Soohong=20 Daniel Park
     Research = Engineer
     Mobile = Platform=20 Group
     Digital Media R&D=20 Center
     Samsung Electronics=20 Co.,LTD
     TEL:+82-31-200-3728
     FAX:+82-31-200-3147
     H.P:+82-11-9950-4655
 &nbs= p;   mailto:soohong.park@samsung.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 


***********************************
Madrid 2003 Global IPv6 Summit
12-14 May 2003 - Soon on line at:
http://www.ipv6-es.com
Interested in participating or sponsoring ?
Contact us at ipv6@consulintel.es ------=_NextPart_000_00EA_01C286F4.9E8D2E70-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 22:11:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA86Bkkd009521; Thu, 7 Nov 2002 22:11:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA86BjYr009520; Thu, 7 Nov 2002 22:11:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA86Bgkd009513 for ; Thu, 7 Nov 2002 22:11:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA86BpMq001347 for ; Thu, 7 Nov 2002 22:11:51 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA17766 for ; Thu, 7 Nov 2002 23:11:44 -0700 (MST) Subject: RE: Scoping Scoped Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 7 Nov 2002 22:12:02 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD316@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Scoping Scoped Addresses Thread-Index: AcKFQ9epND4xYDg3QjiR/yrgKQ81dABazHNA From: "Michel Py" To: , "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA86Bhkd009514 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew, > Andrew White wrote: > Note that site local prefixes have no requirement for > global administration or registration, but are likewise > not guaranteed unique, nor expected to be routeable > outside the site. I disagree with the wording of this. Site-locals MUST NOT be routable outside the site, and the use of "expected" does not reflect this. > Routers and hosts are only expected to support one site > local scope. Further subdivision of a site local address > space should be done using the site local aggregate > portion of the SLA address. > Optional: can also subdivide based on bits 17-48. This is not optional. Some organizations will require more than a /48 for public space, it is highly likely that they would require more than a /48 for site-locals as well. Site-locals are 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 Nov 7 22:18:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA86ICkd009587; Thu, 7 Nov 2002 22:18:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA86ICqY009586; Thu, 7 Nov 2002 22:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA86I8kd009579 for ; Thu, 7 Nov 2002 22:18:08 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA86IHMq002164 for ; Thu, 7 Nov 2002 22:18:17 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04695 for ; Thu, 7 Nov 2002 22:18:12 -0800 (PST) Subject: RE: Scoping Scoped Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 7 Nov 2002 22:18:32 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD317@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Scoping Scoped Addresses Thread-Index: AcKGB5qJz77AU+meSTiiQqY5i6hn2AA5pjwg From: "Michel Py" To: , "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA86I9kd009580 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Andrew White wrote: > My short summary: > (a) Within a "site", a site local address works at least > as well as a global address. > (b) Outside a site, a site local address DOES NOT WORK. > I'd say "MUST NOT WORK", but that is a little hard to enforce. > (c) Given (b), the issues with site locals are about address > selection where there are both global and local addresses > available. However, these issues exist with any multi-homed > host, and site locals at least offer applications some strong > cues about when the addresses will fail. I very much agree with this. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 7 22:57:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA86vskd009763; Thu, 7 Nov 2002 22:57:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA86vsjx009762; Thu, 7 Nov 2002 22:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA86vokd009755 for ; Thu, 7 Nov 2002 22:57:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA86vxMq006730 for ; Thu, 7 Nov 2002 22:57:59 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA04937 for ; Thu, 7 Nov 2002 23:57:52 -0700 (MST) Subject: RE: Scoping Scoped Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 7 Nov 2002 22:58:11 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E432@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Scoping Scoped Addresses Thread-Index: AcKGKJHYuTanecTNQy+IUiE0Dx4PsgAyZrpw From: "Michel Py" To: , "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA86vpkd009756 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew, > Andrew White wrote: > - If a stable global prefix is available, we strongly recommend > using that and not using site locals. This ignores the fact that many people will use site-locals because addresses that are not publicly routable are a requirement, and this regardless of the fact they have a stable global prefix or not. Besides, stable global prefixes do not exist today for end-sites. Instead of making this recommendation, I think it would be better to make recommendations on how to use site-locals even if a global prefix is present. > - Site locals and global addresses can exist in parallel on > the same network, but this is likely to cause address selection > problems for applications. I don't like the wording of this. If, instead of "network", you used "VLAN" or "Ethernet segment" or "subnet", I would have agreed. However, this encompasses networks that have only site-locals or only global addresses on any given subnet, and such networks do not have any address selection issues, as each host has only one address. > Note: It might be possible to have site local traffic sent > over a tunnel (eg a VPN). In such a situation, the VPN should > be treated virtually as part of the site. Site local addresses > must not leak outside the tunnel. Agreed. > Though there are probably better ways to do this than using > site locals. This is a perfectly legitimate use. A tunnel is no different than any other link in terms of connecting two networks; this might simply be a matter of economics. If reliability of the link is not a concern, it costs less in many cases to use an encrypted tunnel over the public Internet than a private link such as frame-relay or PTP T1. Therefore, a site that uses site-local address and has two physical locations might use a tunnel to connect them. The tunnel endpoints would have globally routable addresses and the tunnel interfaces would have site-local addresses. 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 Nov 8 03:50:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8Bogkd010795; Fri, 8 Nov 2002 03:50:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8BogYY010794; Fri, 8 Nov 2002 03:50: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8Bockd010784 for ; Fri, 8 Nov 2002 03:50:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8BokbB013909 for ; Fri, 8 Nov 2002 03:50:46 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04154 for ; Fri, 8 Nov 2002 04:50:40 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:d049:a9c5:c852:1ef7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id gA8BoWd64066; Fri, 8 Nov 2002 20:50:34 +0900 (JST) Date: Fri, 08 Nov 2002 20:51:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes In-Reply-To: <200211061844.gA6Iina17496@rotala.raleigh.ibm.com> References: <200211051903.gA5J3wx0001145948@anw.zk3.dec.com> <200211061844.gA6Iina17496@rotala.raleigh.ibm.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 98 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 06 Nov 2002 13:44:49 -0500, >>>>> Thomas Narten said: > With regards to the basic API: > - Will we want the basic API to ever allow a way to specify the > Traffic Class? If so, will it be better to define a new extension or > to overload the Flow Label? > - Should we point out that some previous versions of the basic API > copied both traffic class and flow label info into packets and that > this is now beleived to be wrong and should be fixed? > I'm OK with either saying setting the Traffic Class through the basic > API won't be done in the future, or saying it can be added but in a > way that is completely backwards compatable and will work smoothly > with 2292bis (assuming we need two ways of setting the bits). I personally prefer to deprecate the access to Traffic Class by the sin6_flowinfo field (i.e. by the basic API), because - it (of course) makes the (future) API simple. - as far as I know, there should be very few (or even no) applications that rely on the feature. so the backward compatibility issue should be not so serious. I know opinions on the compatibility often varies, and I'm open to others' opinions. > Then there is the Advanced API. Again, from Bill: > Bill Fenner writes: >> I am still concerned about the interaction between 2292bis's IPV6_TCLASS >> and these implementations, but perhaps we should let 2553bis go with the >> "not currently specified" wording and make the interaction clear in >> 2292bis? (Has the WG as a whole had a chance to see the suggesiton of >> leaving sin6_flowinfo simply unspecified?) > 2292 doesn't address the flow label. But it does have a way of setting > the Traffic Class. But it doesn't mention how it interacts with > Traffic Class settings via the (old) basic APIs. If the intention is > that the old ways are invalid, and that one only sets traffic class > through the advanced API, I think the current approach is fine. Is > that what folks are thinking here? Excuse me, what do you mean by "the current approach"? Do you mean that "2292bis has a way of setting the traffic class but it doesn't mention the interaction with the (old) basic API"? If so, and assuming we agree on deprecating this part of the basic API, I agree. However, if our consensus is that some backward compatibility should be provided, I guess 2292bis needs to talk about the interaction. > Finally, 2292bis seems to assume the Traffic Class is 8 bits in > size. It's not any more. It's 6 bits, with the ECN bits explicitly a > separate field. So perhaps 2292bis should be updated to reflect the > new size and have separate way of setting the ECN bits? Or at least, > the text should make it clear how one sets one and not the other, etc. (this was discussed before at least partly, but) I believe 2292bis clearly separates the notion of (6-bit) traffic class and 2-bit ECN. For example, section 6.5 contains the following sentences: Returning the received traffic class is useful for programs such as a diffserv debugging tool and for user level ECN (explicit congestion notification) implementation. An example is an implementation of ECN in the kernel, setting 2 bits of the traffic class value. The confusing part would be wording such as "traffic class" (assuming 8 bits) or the socket option name IPV6_TCLASS. In this sense, the comment for the ip6_un1_flow field of the ip6_hdr structure would also be confusing: uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC, 20 bits flow-ID */ As I responded before, I personally think the current wording is okay. However, if there's a strong demand to clarify this much more, I'd propose to add a note like this: [RFC-3260] separates an 8-bit field of the IPv6 header, which was originally called a single "traffic class" field, into a 6-bit DS field and a 2-bit ECN field. However, since this API only provides a single way to get access to the whole 8 bits, the previous terminology "traffic class" will be used to specify the whole bits within this document. Does this make sense? 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 Fri Nov 8 03:53:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8Br3kd010835; Fri, 8 Nov 2002 03:53:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8Br3xp010834; Fri, 8 Nov 2002 03:53:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8Bqwkd010827 for ; Fri, 8 Nov 2002 03:52:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8Br7Mq023587 for ; Fri, 8 Nov 2002 03:53:07 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03377 for ; Fri, 8 Nov 2002 04:53:01 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA8Bqml26516; Fri, 8 Nov 2002 06:52:48 -0500 (EST) Message-Id: <200211081152.gA8Bqml26516@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: awhite@arc.corp.mot.com, "IPng" Subject: Re: Scoping Scoped Addresses In-reply-to: (Your message of "Thu, 07 Nov 2002 22:58:11 PST.") <2B81403386729140A3A899A8B39B046405E432@server2000> Date: Fri, 08 Nov 2002 06:52:48 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Andrew White wrote: > > - If a stable global prefix is available, we strongly recommend > > using that and not using site locals. > > This ignores the fact that many people will use site-locals because > addresses that are not publicly routable are a requirement, and this > regardless of the fact they have a stable global prefix or not. Besides, > stable global prefixes do not exist today for end-sites. sites that think they have this requirement are not stating it correctly. it is easy to arrange for any address prefix to not be reachable from outside of an enclave; ambiguous addresses are not needed to achieve this. > Instead of making this recommendation, I think it would be better to > make recommendations on how to use site-locals even if a global prefix > is present. use of site-locals should be avoided if a global prefix is present. this applies to both networks and applications. this is the best recommendation we can make; it's the one that causes the fewest problems. > > - Site locals and global addresses can exist in parallel on > > the same network, but this is likely to cause address selection > > problems for applications. > > I don't like the wording of this. If, instead of "network", you used > "VLAN" or "Ethernet segment" or "subnet", I would have agreed. I agree that "network" is prone to misunderstanding here. I suggest "portion of the network". "subnet" might be okay here, though it might be too specific. > > Note: It might be possible to have site local traffic sent > > over a tunnel (eg a VPN). In such a situation, the VPN should > > be treated virtually as part of the site. Site local addresses > > must not leak outside the tunnel. > > Agreed. > > > Though there are probably better ways to do this than using > > site locals. > > This is a perfectly legitimate use. legitimate, perhaps. technically optimal is a diferent question. 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 Nov 8 04:37:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8Cb7kd011044; Fri, 8 Nov 2002 04:37:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8Cb7q1011039; Fri, 8 Nov 2002 04:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8Cb2kd011029 for ; Fri, 8 Nov 2002 04:37:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8CbAMq029707 for ; Fri, 8 Nov 2002 04:37:10 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA00750 for ; Fri, 8 Nov 2002 05:37:04 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15563; Fri, 8 Nov 2002 07:34:32 -0500 (EST) Message-Id: <200211081234.HAA15563@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-rfc2096-update-02.txt Date: Fri, 08 Nov 2002 07:34:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IP Forwarding Table MIB Author(s) : M. Wasserman Filename : draft-ietf-ipv6-rfc2096-update-02.txt Pages : 30 Date : 2002-11-7 This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets, in an IP version independent manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-rfc2096-update-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2096-update-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-7160056.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2096-update-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2096-update-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7160056.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 8 04:37:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8CbCkd011054; Fri, 8 Nov 2002 04:37:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8CbCEM011050; Fri, 8 Nov 2002 04:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8Cb6kd011036 for ; Fri, 8 Nov 2002 04:37:06 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8CbEMq029714 for ; Fri, 8 Nov 2002 04:37:14 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26023 for ; Fri, 8 Nov 2002 05:37:08 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15576; Fri, 8 Nov 2002 07:34:37 -0500 (EST) Message-Id: <200211081234.HAA15576@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-node-requirements-02.txt Date: Fri, 08 Nov 2002 07:34:36 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Node Requirements Author(s) : J. Loughney Filename : draft-ietf-ipv6-node-requirements-02.txt Pages : 21 Date : 2002-11-7 This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-node-requirements-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-node-requirements-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-7160105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-node-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-node-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7160105.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 8 04:37:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8CbMkd011071; Fri, 8 Nov 2002 04:37:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8CbLLS011067; Fri, 8 Nov 2002 04:37:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8CbBkd011046 for ; Fri, 8 Nov 2002 04:37:11 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8CbJMq029725 for ; Fri, 8 Nov 2002 04:37:19 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26046 for ; Fri, 8 Nov 2002 05:37:13 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15589; Fri, 8 Nov 2002 07:34:42 -0500 (EST) Message-Id: <200211081234.HAA15589@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-link-scoped-mcast-02.txt Date: Fri, 08 Nov 2002 07:34:41 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Link Scoped IPv6 Multicast Addresses Author(s) : J. Park, M. Shin Filename : draft-ietf-ipv6-link-scoped-mcast-02.txt Pages : 6 Date : 2002-11-7 This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of interface-ID to allocate multicast addresses. When the link-local unicast address is configured at each interface of host, interface ID is uniquely determined. By delegating multicast addresses at the same time as interface ID, each host can identify their multicast addresses automatically at Layer 1 without running an intra- or inter-domain allocation protocol in the serverless environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-link-scoped-mcast-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-link-scoped-mcast-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-7160115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-link-scoped-mcast-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-link-scoped-mcast-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7160115.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 8 04:37:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8CbVkd011074; Fri, 8 Nov 2002 04:37:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8CbVeM011073; Fri, 8 Nov 2002 04:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8CbGkd011056 for ; Fri, 8 Nov 2002 04:37:16 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8CbNbB020487 for ; Fri, 8 Nov 2002 04:37:24 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23308 for ; Fri, 8 Nov 2002 05:37:18 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15614; Fri, 8 Nov 2002 07:34:46 -0500 (EST) Message-Id: <200211081234.HAA15614@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-rfc2011-update-01.txt Date: Fri, 08 Nov 2002 07:34:46 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Management Information Base for the Internet Protocol (IP) Author(s) : S. Routhier Filename : draft-ietf-ipv6-rfc2011-update-01.txt Pages : 107 Date : 2002-11-7 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-rfc2011-update-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2011-update-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-7160123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2011-update-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2011-update-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7160123.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 8 04:37:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8Cbbkd011077; Fri, 8 Nov 2002 04:37:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8CbaSK011076; Fri, 8 Nov 2002 04:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8CbKkd011063 for ; Fri, 8 Nov 2002 04:37:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8CbSMq029742 for ; Fri, 8 Nov 2002 04:37:28 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA00888 for ; Fri, 8 Nov 2002 05:37:22 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15626; Fri, 8 Nov 2002 07:34:50 -0500 (EST) Message-Id: <200211081234.HAA15626@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-prefix-delegation-requirement-00.txt Date: Fri, 08 Nov 2002 07:34:50 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Requirements for IPv6 prefix delegation Author(s) : S. Miyakawa Filename : draft-ietf-ipv6-prefix-delegation-requirement-00.txt Pages : 0 Date : 2002-11-7 This document describes requirements about how an IPv6 address prefix should be delegated to an IPv6 subscriber's network (or 'site'). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-prefix-delegation-requirement-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-00.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: <2002-11-7160133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-prefix-delegation-requirement-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7160133.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 8 07:49:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8FnJkd012792; Fri, 8 Nov 2002 07:49:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8FnItu012791; Fri, 8 Nov 2002 07:49: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8FnFkd012784 for ; Fri, 8 Nov 2002 07:49:15 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8FnNbB020800 for ; Fri, 8 Nov 2002 07:49:23 -0800 (PST) Received: from parsmtp2.rd.francetelecom.com (parsmtp2.rd.francetelecom.com [194.167.105.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01512 for ; Fri, 8 Nov 2002 07:45:59 -0800 (PST) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 16:30:29 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: I-D ACTION:draft-ietf-ipv6-prefix-delegation-requirement-00.txt Date: Fri, 8 Nov 2002 16:30:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-prefix-delegation-requirement-00.txt Thread-Index: AcKHJDmYulqYlVk+RzuxeBDySlBI1gAFyIXA From: "BELOEIL Luc FTRD/DMI/CAE" To: Cc: X-OriginalArrivalTime: 08 Nov 2002 15:30:29.0049 (UTC) FILETIME=[C4919290:01C2873B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gA8FnFkd012785 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anyone think that a validity lifetime should be associated to the prefix during prefix delegation? Indeed RAs sent on a link associate a valid lifetime and a preferred lifetime to the advertised prefixes. my 0;2% Luc > -----Message d'origine----- > De : Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Envoye : vendredi 8 novembre 2002 13:35 > A : IETF-Announce > Cc : ipng@sunroof.eng.sun.com > Objet : I-D > ACTION:draft-ietf-ipv6-prefix-delegation-requirement-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the IP Version 6 Working Group > Working Group of the IETF. > > Title : Requirements for IPv6 prefix delegation > Author(s) : S. Miyakawa > Filename : > draft-ietf-ipv6-prefix-delegation-requirement-00.txt > Pages : 0 > Date : 2002-11-7 > > This document describes requirements about how an IPv6 address prefix > should be delegated to an IPv6 subscriber's network (or 'site'). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-del egation-requirement-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-prefix-delegation-requirement-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-00.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. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 8 08:06:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8G6Hkd012905; Fri, 8 Nov 2002 08:06:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8G6HS0012904; Fri, 8 Nov 2002 08:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8G6Ekd012897 for ; Fri, 8 Nov 2002 08:06:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8G6MMq011690 for ; Fri, 8 Nov 2002 08:06:22 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16562 for ; Fri, 8 Nov 2002 09:06:17 -0700 (MST) Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id gA8G5siZ025445 for ; Fri, 8 Nov 2002 11:05:54 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 8 Nov 2002 11:06:21 -0500 Message-ID: <3DCBE1EF.7070302@nc.rr.com> Date: Fri, 08 Nov 2002 11:10:23 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-prefix-delegation-requirement-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk BELOEIL Luc FTRD/DMI/CAE wrote: > Does anyone think that a validity lifetime should be associated to the > prefix during prefix delegation? Absolutely. > > Indeed RAs sent on a link associate a valid lifetime and a preferred > lifetime to the advertised prefixes. If your prefix is delegated to you, the delegating entity has to provide a lifetime in order for the requestor to build meaningful RAs. 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 Nov 8 08:16:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8GGWkd012990; Fri, 8 Nov 2002 08:16:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8GGWEK012989; Fri, 8 Nov 2002 08:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8GGTkd012982 for ; Fri, 8 Nov 2002 08:16:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8GGbbB026050 for ; Fri, 8 Nov 2002 08:16:37 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02671 for ; Fri, 8 Nov 2002 09:16:31 -0700 (MST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA09882 for ; Fri, 8 Nov 2002 11:16:31 -0500 (EST) Message-Id: <4.3.2.7.2.20021108111029.03d8b290@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Nov 2002 11:16:28 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: I-D ACTION:draft-ietf-ipv6-prefix-delegation-requirement-00.txt In-Reply-To: <3DCBE1EF.7070302@nc.rr.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:10 AM 11/8/2002 -0500, Brian Haberman wrote: >BELOEIL Luc FTRD/DMI/CAE wrote: >>Does anyone think that a validity lifetime should be associated to the >>prefix during prefix delegation? > >Absolutely. I agree - but with a slight clarification: the delegator associates an "expiration time" with the delegated prefix, which defines the time after which the requestor can't use the delegated prefix. The requestor then chooses preferred and valid lifetimes (presumably not greater than the expiration time on the delegated prefix) for the prefix. I think the requestor should be able to choose lifetimes that are shorter than the delegation duration from the delegator, and using a different term like "expiration time" would be clarifying. - Ralph >>Indeed RAs sent on a link associate a valid lifetime and a preferred >>lifetime to the advertised prefixes. > >If your prefix is delegated to you, the delegating entity has to >provide a lifetime in order for the requestor to build meaningful >RAs. > >Brian > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 8 08:43:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8GhTkd013390; Fri, 8 Nov 2002 08:43:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8GhToq013389; Fri, 8 Nov 2002 08:43:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8GhQkd013382 for ; Fri, 8 Nov 2002 08:43:26 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8GhYMq020244 for ; Fri, 8 Nov 2002 08:43:34 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13331 for ; Fri, 8 Nov 2002 08:43:29 -0800 (PST) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA8GhSnG019634 for ; Fri, 8 Nov 2002 11:43:28 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA8Gjj0U148900 for ; Fri, 8 Nov 2002 09:45:46 -0700 Importance: Normal Sensitivity: Subject: I-D ACTION:draft-ietf-ipv6-rfc2011-update-01.txt - typo To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Kristine Adamson Date: Fri, 8 Nov 2002 11:43:26 -0500 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|October 31, 2002) at 11/08/2002 09:43:27 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In this new draft I think the MIB object ipv6IntefaceReachableTime is still spelled incorrectly. Shouldn't it be ipv6InterfaceReachableTime? Thanks, Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.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 Nov 8 10:41:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8Ifmkd016500; Fri, 8 Nov 2002 10:41:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8IfmHn016499; Fri, 8 Nov 2002 10:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8Ifekd016492 for ; Fri, 8 Nov 2002 10:41:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8IflbB009057 for ; Fri, 8 Nov 2002 10:41:48 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25958 for ; Fri, 8 Nov 2002 11:41:42 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06308; Fri, 8 Nov 2002 13:39:10 -0500 (EST) Message-Id: <200211081839.NAA06308@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2012-update-01.txt Date: Fri, 08 Nov 2002 13:39:10 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Management Information Base for the Transmission Control Protocol (TCP) Author(s) : B. Fenner et al. Filename : draft-ietf-ipv6-rfc2012-update-01.txt Pages : 29 Date : 2002-11-8 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) [5] in an IP version independent manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-rfc2012-update-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2012-update-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-8124852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2012-update-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2012-update-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-8124852.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 8 14:29:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8MTGkd021393; Fri, 8 Nov 2002 14:29:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8MTD33021392; Fri, 8 Nov 2002 14:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8MTAkd021385 for ; Fri, 8 Nov 2002 14:29:10 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8MTIMq008163 for ; Fri, 8 Nov 2002 14:29:18 -0800 (PST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12546 for ; Fri, 8 Nov 2002 14:29:13 -0800 (PST) Received: from SPOLLOCK-W2K1.cisco.com ([10.83.135.67] (may be forged)) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA07204; Fri, 8 Nov 2002 14:28:33 -0800 (PST) Message-Id: <4.3.2.7.2.20021108151040.026521b8@diablo.cisco.com> X-Sender: spollock@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Nov 2002 15:12:10 -0700 To: "Bound, Jim" , "Mohammad Feroz" , From: Steve Pollock Subject: RE: IPSec Implementaion. In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE965E@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Any idea what host stacks have IPsec implemented today? I'd like to do a bit of testing. Regards, -Steve At 10:28 AM 10/23/2002 -0400, Bound, Jim wrote: >Read the IPsec arch spec and other specs. IPsec is a MUST according to us in the IETF for ANY IPv6 implementation. > >As an implementor I would not implement any IPv6 incantation with IPv6 because I believe to not implement all MUSTs in a spec is not wise. > >Now if at indusrtry implementation forums or bake-offs implementors find the spec don't work they stop and come tell the IETF. For IPsec that is not the case it does work. Clearly PKI to IKE interface is a problem for vendors as that usually requires melding a 3rd party key mgmt infrastructure to your implementation. But that is not the IETFs problem per se (though they do need to hear the technical issues). > >This does not mean an implementor cannot use alternative methods to secure devices but to be compliant with the IETF IPsec architecture any implementation MUST do it. > >Users may or may not use our recommendations that is up to the market we have no control over that in the market. I personally support them adopting IPv6 as one critical method for securing IP layer communications. But it is not the only one that they need. > >This is my view and you should get others views too. That is how I read the specs. > >regards, >/jim >-----Original Message----- >From: Mohammad Feroz [mailto:feroz@tataelxsi.co.in] >Sent: Wednesday, October 23, 2002 6:38 AM >To: Bound, Jim; ipng@sunroof.eng.sun.com >Subject: Re: IPSec Implementaion. > >Thank you for the clarification. I would even like to know whether IPSec is mandatory to implement for Handheld devices. > >Thanks & Best Regards, >- Feroz >----- Original Message ----- >From: Bound, Jim >To: Mohammad Feroz ; ipng@sunroof.eng.sun.com >Sent: Tuesday, October 22, 2002 7:51 AM >Subject: RE: IPSec Implementaion. > >IPsec is yes and the architecture. > >/jim >-----Original Message----- >From: Mohammad Feroz [mailto:feroz@tataelxsi.co.in] >Sent: Monday, October 21, 2002 8:05 AM >To: ipng@sunroof.eng.sun.com >Subject: IPSec Implementaion. > >Hello ! > >Is it mandatory to implement Security Architecture for IPv6 for HOSTS? > >Thanks & Best Regards, >- Feroz > >********************************************************* >Mohammed Feroz, >Networking & Communication Group, >Design & Development Centre, >TATA Elxsi Limited, Bangalore >Phone: +91-80-8410222 >Fax: +91-80-8410219 >********************************************************* -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 8 15:28:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8NSZkd022460; Fri, 8 Nov 2002 15:28:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA8NSZNZ022459; Fri, 8 Nov 2002 15:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA8NSWkd022452 for ; Fri, 8 Nov 2002 15:28:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA8NSdMq024793 for ; Fri, 8 Nov 2002 15:28:40 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA25055 for ; Fri, 8 Nov 2002 16:28:32 -0700 (MST) Received: from kenawang.windriver.com ([192.168.1.91]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA25748; Fri, 8 Nov 2002 15:27:49 -0800 (PST) Message-Id: <5.1.0.14.2.20021108181930.03318950@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 08 Nov 2002 18:27:43 -0500 To: "Richard Draves" From: Margaret Wasserman Subject: RE: question regarding possible use of SLs in renumbering Cc: "IPng" 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 > >What rule is that? Is the routing within Wind River "convex"? Assuming >it is, I don't see why you wouldn't make Wind River a single site, even >if it is geographically dispersed. Wind River has multiple sites with Internet connectivity that are connected via linked lines. If you think of two of them, you can picture a dumbbell shaped network. Our ISP is routing different parts of the Wind River network space to different locations. In this configuration, the preferred path for global traffic between the two locations is to go over the leased line. This keeps the traffic inside the firewall, etc. However, if the leased line goes down (or one of the routers to it goes down, etc.), global traffic will fall-back to being routed over the global Internet... This is great because it lets me reach non-secure parts of the other Wind River site, even when my secure link is down. And, I can run a client VPN solution to get behind the firewall, if I need to. However, this fallback route breaks the concept that the site needs to be "convex" at the global scope. So, I need to have my two locations be two different sites. This has been discussed a few times on the IPv6 list before. So, I need to have two sites. I'm not wild about that, but it is required by our current scoped addressing architecture. However, I am not require to number those two sites from different /48 address allocations... And, if I change ISPs, I will need to renumber the entire 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 Fri Nov 8 18:10:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA92Adkd024082; Fri, 8 Nov 2002 18:10:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA92AdMA024081; Fri, 8 Nov 2002 18:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA92Aakd024074 for ; Fri, 8 Nov 2002 18:10:36 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA92AhbB011491 for ; Fri, 8 Nov 2002 18:10:44 -0800 (PST) Received: from mail.nosense.org (19.cust1.nsw.dsl.ozemail.com.au [203.103.156.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03472 for ; Fri, 8 Nov 2002 19:10:37 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 8992B3B37F; Sat, 9 Nov 2002 13:10:35 +1100 (EST) Subject: RE: question regarding possible use of SLs in renumbering From: Mark Smith To: Margaret Wasserman Cc: Richard Draves , IPng In-Reply-To: <5.1.0.14.2.20021108181930.03318950@mail.windriver.com> References: <5.1.0.14.2.20021108181930.03318950@mail.windriver.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 09 Nov 2002 13:10:35 +1100 Message-Id: <1036807836.2827.49.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, I realise this is could be bit off topic, although I think it may help as it shows how Wind River could solve the multiple "site-local" addressing issue. Wind River could set up a permanent IPsec VPN between the firewalls at the Internet connections at each of their geographical sites, and then weight the routes in the IGP to prefer the internal leased lines. This would allow the whole organisation to be considered part of the same "site-local" site, and therefore numbered out of a single site-local addressing instance. If any of the leased lines fails, the internally disconnected site is still part of the "site-local" site, due to the VPN. Alternatively, all geographical sites could still be considered part of the same "site-local" site (as the leased lines suggest), and then the VPN concentrator she connects to hands out a site-local prefix that is unique within the organisation's single site-local addressing instance ie. if a leased line fails, Margaret connects via her VPN client, through which her PC re-gains membership of the organisation's single "site-local" site. This client VPN option is a bit complex though, Margaret's PC now needs to know what "site-local" prefixes are at the end of the IPsec tunnel vs which site-local prefixes are locally attached via her LAN interface. However, VPN concentrators today can usually push static routes to their clients, indicating which destinations are at the end of the tunnel, relying on the default route for directly attached, local destinations, and Internet destined traffic. Hmm, this option could be a bit more complicated than I think. From the hosts and routers view point, the site-local site is partitioned. But from Margaret's PCs view point it isn't. I can't think of an application that does this off the top of my head (maybe a peer to peer app of some sort), but if Margaret's PC referred one of the local devices to a site-local address at the end of her tunnel, the local device wouldn't be able to see it, unless it had its own client VPN tunnel. Creating a VPN between the Internet firewalls looks to be the simpler solution. Wind River could even save money by using redundant Internet connections for each geographical site, and decommissioning their leased lines. Actually, as IPsec is a mandatory part of IPv6, I would suggest using IPv6 IPsec VPNs to replace internal leased lines will eventually become very common. Does IPsec VPN tunnels / logical links influence any of the current site-local discussions ? Mark. On Sat, 2002-11-09 at 10:27, Margaret Wasserman wrote: > > > > >What rule is that? Is the routing within Wind River "convex"? Assuming > >it is, I don't see why you wouldn't make Wind River a single site, even > >if it is geographically dispersed. > > Wind River has multiple sites with Internet connectivity that > are connected via linked lines. If you think of two of them, > you can picture a dumbbell shaped network. Our ISP is routing > different parts of the Wind River network space to different > locations. > > In this configuration, the preferred path for global traffic > between the two locations is to go over the leased line. This > keeps the traffic inside the firewall, etc. > > However, if the leased line goes down (or one of the routers to > it goes down, etc.), global traffic will fall-back to being routed > over the global Internet... This is great because it lets me > reach non-secure parts of the other Wind River site, even when my > secure link is down. And, I can run a client VPN solution to get > behind the firewall, if I need to. > > However, this fallback route breaks the concept that the site > needs to be "convex" at the global scope. So, I need to have > my two locations be two different sites. This has been discussed > a few times on the IPv6 list before. > > So, I need to have two sites. I'm not wild about that, but it > is required by our current scoped addressing architecture. > However, I am not require to number those two sites from different > /48 address allocations... And, if I change ISPs, I will need to > renumber the entire 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 8 19:39:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA93d3kd024468; Fri, 8 Nov 2002 19:39:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA93d2R4024467; Fri, 8 Nov 2002 19:39: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA93cwkd024460 for ; Fri, 8 Nov 2002 19:38:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA93d6Mq019851 for ; Fri, 8 Nov 2002 19:39:06 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08741 for ; Fri, 8 Nov 2002 20:39:01 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA93cql01234; Fri, 8 Nov 2002 22:38:53 -0500 (EST) Message-Id: <200211090338.gA93cql01234@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Smith cc: Margaret Wasserman , Richard Draves , IPng Subject: Re: question regarding possible use of SLs in renumbering In-reply-to: (Your message of "09 Nov 2002 13:10:35 +1100.") <1036807836.2827.49.camel@dupy> Date: Fri, 08 Nov 2002 22:38:52 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Wind River might be able to coerce their entire network into being a single "site" in the manner you suggest. However, it seems like it would be a stretch to expect all networks to make sites boundaries coincide with the boundaries of the realms using global address prefixes just so that we could have a common renumbering solution based on site-locals. For similar reasons it seems like a stretch to expect applications to prefer site-locals over globals (when both are available) - if a site boundary doesn't have to coincide with the boundary of the portion of the network using a particular global prefix then the application really has no idea whether either kind of address is more reachable by its intended peers (that have both kinds of addresses) than the other. 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 Nov 8 21:20:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA95Knkd024745; Fri, 8 Nov 2002 21:20:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA95KnjR024744; Fri, 8 Nov 2002 21:20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA95Kkkd024737 for ; Fri, 8 Nov 2002 21:20:46 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA95KsMq003831 for ; Fri, 8 Nov 2002 21:20:54 -0800 (PST) Received: from mail.iwavesystems.com (iwave-54-144-ban.iwavesystems.com [203.196.144.54] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19521 for ; Fri, 8 Nov 2002 22:20:43 -0700 (MST) Received: from iwave120 (ns1.iwave.net [203.196.144.50]) by mail.iwavesystems.com (8.12.4/) with SMTP id gA95GQL3023188 for ; Sat, 9 Nov 2002 10:46:28 +0530 Message-ID: <008301c287b0$383fe2e0$b202a8c0@iwave120> From: "Anurag Uxa" To: Subject: EAP-AKA Authentication (umts) Date: Sat, 9 Nov 2002 10:53:58 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0080_01C287DE.4E09F4C0" 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-Virus-Scanned: Message: ok X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.14 (www dot roaringpenguin dot com slash mimedefang) X-Filter-Version: 1.4.5 (mail.iwavesystems.com) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0080_01C287DE.4E09F4C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All =20 I am going to implement ppp authentication for mobile IPv6 = communication. I have implemented EAP ( MD5-Challenge ). But i am not able to understand about AKA , How can i use PPP message = format with AKA? If it is like EAP what is protocol field and length and = optional field. USIM will work like a client .what should be the fuctionality of = authenticator(server)? The use of the AKA also as a secure PPP authentication method in devices = that already contain an USIM.=20 AKA typically runs in a UMTS Subscriber Identity Module (USIM), a smart = card like device.=20 Five security feature groups are defined. Each of these feature groups = meets certain threats and accomplishes certain security objectives: - Network access security : the set of security features that provide = users with secure access to 3G services, and which in particular protect = against attacks on the (radio) access link; - Network domain security: the set of security features that enable = nodes in the provider domain to securely exchange signalling data, and = protect against attacks on the wireline network; - User domain security : the set of security features that secure access = to mobile stations; - Application domain security : the set of security features that enable = applications in the user and in the provider domain to securely exchange = messages; - Visibility and configurability of security (V): the set of features = that enables the user to inform himself whether a security feature is in = operation or not and whether the use and provision of services should = depend on the security feature. Thanks Regards Anurag Uxa iWave systems Technologies Pvt. Ltd. Bangalore ph.6786243/5 extn :205 www.iwavesystems.com DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. ------=_NextPart_000_0080_01C287DE.4E09F4C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

Dear All
 
 
 =20

I am going to implement ppp = authentication for=20 mobile IPv6 communication. I have implemented EAP ( MD5-Challenge=20 ).

But i am not able = to understand=20 about AKA , How can i use PPP message format with AKA? If it is like EAP = what is=20 protocol field and length and optional field.

USIM will work like a client .what = should be the=20 fuctionality of authenticator(server)?

 

 

The use of the AKA also = as a secure=20 PPP authentication method in devices that already contain an USIM. =

AKA typically runs in a UMTS Subscriber Identity Module (USIM), a smart card like device.=20

Five security feature groups are defined. Each = of these=20 feature groups meets certain threats and accomplishes certain security=20 objectives:

- Network access = security :=20 the set of security features that provide users with secure access to 3G = services, and which in particular protect against attacks on the (radio) = access=20 link;

- Network domain = security:=20 the set of security features that enable nodes in the provider domain to = securely exchange signalling data, and protect against attacks on the = wireline=20 network;

- User domain = security : the=20 set of security features that secure access to mobile=20 stations;

- Application = domain=20 security : the set of security features that enable = applications in the=20 user and in the provider domain to securely exchange=20 messages;

- Visibility and = configurability=20 of security (V): the set of features that enables the user to inform = himself=20 whether a security feature is in operation or not and whether the use = and=20 provision of services should depend on the security=20 feature.

 

 
 
 
 
 
Thanks
 
 
Regards
Anurag Uxa
iWave systems = Technologies Pvt.=20 Ltd.
Bangalore
ph.6786243/5 extn :205
www.iwavesystems.com
 

DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation.

------=_NextPart_000_0080_01C287DE.4E09F4C0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 8 21:35:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA95Zhkd024839; Fri, 8 Nov 2002 21:35:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA95Zhjp024838; Fri, 8 Nov 2002 21:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA95ZUkd024830 for ; Fri, 8 Nov 2002 21:35:40 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA95ZcMq005576 for ; Fri, 8 Nov 2002 21:35:38 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05979 for ; Fri, 8 Nov 2002 21:35:31 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 55FC16A909; Sat, 9 Nov 2002 07:35:23 +0200 (EET) Message-ID: <3DCC827E.600@kolumbus.fi> Date: Sat, 09 Nov 2002 05:35:26 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anurag Uxa Cc: ipng@sunroof.eng.sun.com Subject: Re: EAP-AKA Authentication (umts) References: <008301c287b0$383fe2e0$b202a8c0@iwave120> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Anurag Uxa wrote: > I am going to implement ppp authentication for mobile IPv6 > communication. I have implemented EAP ( MD5-Challenge ). > > But i am not able to understand about AKA , How can i use PPP message > format with AKA? If it is like EAP what is protocol field and length and > optional field. > > USIM will work like a client .what should be the fuctionality of > authenticator(server)? The list for the EAP working group might a better place to discuss this since EAP methods are independent of IP version. For specifics of EAP AKA, see draft-arkko-pppext-eap-aka-06.txt. Hope this helps, Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 8 22:58:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA96wVkd025059; Fri, 8 Nov 2002 22:58:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA96wVFL025058; Fri, 8 Nov 2002 22:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA96wQkd025051 for ; Fri, 8 Nov 2002 22:58:27 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA96wYbB017297 for ; Fri, 8 Nov 2002 22:58:34 -0800 (PST) Received: from mail.64translator.com (94.180.32.202.ts.2iij.net [202.32.180.94]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27130 for ; Fri, 8 Nov 2002 22:58:29 -0800 (PST) Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.6/8.12.6) with ESMTP id gA96wRXM001020 for ; Sat, 9 Nov 2002 15:58:27 +0900 (JST) X-Authentication-Warning: ns.64translator.com: Host [10.21.32.3] claimed to be bahamas.64translator.com Received: from localhost.localdomain (fumi.local.ini.jp [10.21.254.84]) by bahamas.64translator.com (8.11.6/8.11.6) with SMTP id gA96wLu22196 for ; Sat, 9 Nov 2002 15:58:21 +0900 (JST) Date: Sat, 9 Nov 2002 15:58:22 +0900 From: Yukiyo Akisada To: ipng@sunroof.eng.sun.com Subject: 4th TAHI IPv6 Interoperability Test Event Message-Id: <20021109155822.61157395.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu) 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 all, I'm pleased to be able to announce next TAHI IPv6 test event. The 4th TAHI IPv6 Interoperability Test Event will be held 20-24 January, 2003 at Chiba, JAPAN. This time we are focusing on Prefix Delegation, MIP6, Routing protocol, Transition, etc...! Of course we also focusing on Basic specification. For more details, please visit our web site. TAHI Project Home Page http://www.tahi.org/ "4th TAHI IPv6 Interoperability Test Event" announcement. http://www.tahi.org/inop/4thinterop.html # I'm sorry if you have already receive this mail. ---- Yukiyo Akisada -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 8 22:58:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA96wnkd025075; Fri, 8 Nov 2002 22:58:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gA96wnP3025074; Fri, 8 Nov 2002 22:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA96wZkd025061 for ; Fri, 8 Nov 2002 22:58:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gA96whMq014225 for ; Fri, 8 Nov 2002 22:58:43 -0800 (PST) Received: from localhost.localdomain (OSR1-20.st.keio.ac.jp [131.113.17.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA06321 for ; Fri, 8 Nov 2002 23:58:37 -0700 (MST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with SMTP id gA96sZw02751 for ; Sat, 9 Nov 2002 15:54:36 +0900 Date: Sat, 9 Nov 2002 15:54:35 +0900 From: Yukiyo Akisada To: ipng@sunroof.eng.sun.com Subject: 4th TAHI IPv6 Interoperability Test Event Message-Id: <20021109155435.622dff47.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu) 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 all, I'm pleased to be able to announce next TAHI IPv6 test event. The 4th TAHI IPv6 Interoperability Test Event will be held 20-24 January, 2003 at Chiba, JAPAN. This time we are focusing on Prefix Delegation, MIP6, Routing protocol, Transition, etc...! Of course we also focusing on Basic specification. For more details, please visit our web site. TAHI Project Home Page http://www.tahi.org/ "4th TAHI IPv6 Interoperability Test Event" announcement. http://www.tahi.org/inop/4thinterop.html # I'm sorry if you have already receive this mail. ---- Yukiyo Akisada -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 10 05:38:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAADcIkd029147; Sun, 10 Nov 2002 05:38:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAADcHUV029146; Sun, 10 Nov 2002 05:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAADcEkd029139 for ; Sun, 10 Nov 2002 05:38:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAADcNMq021935 for ; Sun, 10 Nov 2002 05:38:23 -0800 (PST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15237 for ; Sun, 10 Nov 2002 06:38:13 -0700 (MST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35BE9622AD for ; Sun, 10 Nov 2002 14:38:11 +0100 (CET) Date: Sun, 10 Nov 2002 14:38:11 +0100 From: Harald Tveit Alvestrand To: ipng@sunroof.eng.sun.com Subject: Naming and site-local addresses Message-ID: <2082830000.1036935491@askvoll.hjemme.alvestrand.no> 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 Forgive me if I am treading well-trodden paths here, but I am trying to understand.... It seems to me that using site-local addresses in applications means that applications have to get hold of these addresses somehow; very few applications are fed addresses directly by their users. 99% of applications do some kind of name-to-address lookup *before* they start getting into what kind of addresses to use. (And I'm not just thinking about DNS - SDP is an example of a non-DNS name-to-address lookup - find the session using name/description, and pick the IP from the description fields). If a name-to-address lookup mechanism (ANY such mechanism) returns an off-site site-local to the application, without the info that this is an off-site site-local, the application will not behave as expected. (it will either connect to the address and fail, or it will (worse) connect to the address and succeed, but not to the point it wanted to go). That seems to me to mean that the name lookup mechanism has to not only return globals and local-site site-locals, but has to *suppress* off-site site-locals. Which again means that the lookup mechanism has to know the scope identity of BOTH the requester and the target resource, or choose to return *no* site-locals. now, a lot of DNS is two-faced, meaning that the DNS servers have to be aware of scopes around them; mainly, two-faced DNS distinguishes between "within the security boundary" and "not within the security boundary". But a lot of the DNS is not. So using site-local with the DNS seems to require capturing all DNS traffic within the site, in case it tries to query for local resources, and *keeping* it to DNS servers that know about the site of the requester; this would seem to mandate two-faced DNS, even when it's not necessary for security, and, if security by firewall is in use, make it *extremely* complex to configure site boundaries at any other place than at security boundaries. This seems to me to be actually harder than configuring the site border routers for routing........ not nicely behaved wrt DNS at all, and maybe even less nicely behaved with other naming schemes... This seems to lead me to one of two conclusions: - Address lookup is significantly more complex in the presence of site-local than if only global-scoped addresses are used - I missed something. Comments? 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 Sun Nov 10 07:05:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAAF58kd029274; Sun, 10 Nov 2002 07:05:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAAF57PX029273; Sun, 10 Nov 2002 07:05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAAF54kd029266 for ; Sun, 10 Nov 2002 07:05:04 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAAF5DbB007481 for ; Sun, 10 Nov 2002 07:05:13 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18534 for ; Sun, 10 Nov 2002 07:05:07 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAAF52l13021; Sun, 10 Nov 2002 10:05:04 -0500 (EST) Message-Id: <200211101505.gAAF52l13021@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Harald Tveit Alvestrand cc: ipng@sunroof.eng.sun.com Subject: Re: Naming and site-local addresses In-reply-to: (Your message of "Sun, 10 Nov 2002 14:38:11 +0100.") <2082830000.1036935491@askvoll.hjemme.alvestrand.no> Date: Sun, 10 Nov 2002 10:05:02 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This seems to lead me to one of two conclusions: > > - Address lookup is significantly more complex in the presence of > site-local than if only global-scoped addresses are used > > - I missed something. I concur with the first conclusion. But the problem is not limited to name-to-address lookup - it applies to any means of obtaining addresses. Even if you could fix DNS to work in the presence of scoped addresses it wouldn't solve the problems with those other means of obtaining addresses. (while I'd probably agree that 99% of apps do use name-to-address lookup to obtain addresses, that doesn't mean that even those apps use it as their only means of obtaining addressess) 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 Sun Nov 10 12:25:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAAKPwkd029942; Sun, 10 Nov 2002 12:25:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAAKPwHr029941; Sun, 10 Nov 2002 12:25: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAAKPtkd029934 for ; Sun, 10 Nov 2002 12:25:55 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAAKQ4bB006025 for ; Sun, 10 Nov 2002 12:26:04 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07067 for ; Sun, 10 Nov 2002 12:25:58 -0800 (PST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA16950 for ipng@sunroof.eng.sun.com; Sun, 10 Nov 2002 15:25:56 -0500 (EST) Date: Sun, 10 Nov 2002 15:25:56 -0500 (EST) From: Dan Lanciani Message-Id: <200211102025.PAA16950@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Naming and site-local addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Harald Tveit Alvestrand wrote: |This seems to lead me to one of two conclusions: | |- Address lookup is significantly more complex in the presence of |site-local than if only global-scoped addresses are used | |- I missed something. | |Comments? I don't think you missed something. If anything, site-locals are even more complex to support than you suggest. But site-locals (or, more generally, scoped addresses) are what we got in the face of the questionable assertion that provider-independent global/routable addresses are too difficult to even think about supporting. As long as we are stuck with a totally non-scalable address allocation system (remember, provider-based aggregated addressing consumes address space *exponentially* in the number of providers in the service chain) end users need some way to provision local systems with stable addresses. So far, nobody has proposed a viable alternative to scoped addresses. 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 Nov 10 14:40:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAAMeJkd000273; Sun, 10 Nov 2002 14:40:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAAMeJ3a000272; Sun, 10 Nov 2002 14:40: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAAMeGkd000265 for ; Sun, 10 Nov 2002 14:40:16 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAAMePbB016739 for ; Sun, 10 Nov 2002 14:40:25 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10517 for ; Sun, 10 Nov 2002 14:40:19 -0800 (PST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gAAMeQwc017439; Sun, 10 Nov 2002 23:40:27 +0100 (CET) Date: Sun, 10 Nov 2002 19:53:34 +0100 Subject: Re: SUMMARY: RE: Limiting the Use of Site-Local Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Margaret Wasserman" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <2B81403386729140A3A899A8B39B046405E402@server2000> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't see how this could reach consensus. It appears to me that way > too many people here have forgot The Golden Rule of a successful > product, which is to keep the customer happy. IPv6 is a product, it its > success is a lot more tied to what customers (read: network > administrators) think than to what people that develop stacks think, > whether you like it or not. The difference is that there is no business at stake if this product don't fly. We can change it anyway. - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 10 17:03:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB13rkd000638; Sun, 10 Nov 2002 17:03:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAB13rM5000637; Sun, 10 Nov 2002 17:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB13okd000630 for ; Sun, 10 Nov 2002 17:03:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAB13sbB029714 for ; Sun, 10 Nov 2002 17:03:58 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA22841 for ; Sun, 10 Nov 2002 18:03:46 -0700 (MST) Subject: RE: question regarding possible use of SLs in renumbering Date: Sun, 10 Nov 2002 17:04:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E436@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: question regarding possible use of SLs in renumbering Thread-Index: AcKHl34rMSbc1b5hQx+nPopfS9icOgBhd1/Q From: "Michel Py" To: "Mark Smith" Cc: "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAB13okd000631 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mark Smith wrote: > Does IPsec VPN tunnels / logical links influence any of > the current site-local discussions ? As you mentioned in your post, the VPN tunnel keeps the network convex as it's no different than any other link, and only one site is needed. Any serious network that does not have redundant private links and routers has an encrypted router-to-router tunnel for inside traffic. Latency is not good and encryption might seriously hit the routers, but it's better than no connection. Client VPNs to get to the other location if the leased line goes down just makes makes me laugh. It's not that big of a deal to configure; I have number of setups that run EIGRP routing over IPSEC tunnels over the Internet, crossing firewalls. Nothing exotic here. 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 Nov 10 17:04:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB14gkd000655; Sun, 10 Nov 2002 17:04:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAB14fce000654; Sun, 10 Nov 2002 17:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB14ckd000647 for ; Sun, 10 Nov 2002 17:04:38 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAB14lMq029801 for ; Sun, 10 Nov 2002 17:04:47 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27693 for ; Sun, 10 Nov 2002 18:04:41 -0700 (MST) Subject: RE: Scoping Scoped Addresses Date: Sun, 10 Nov 2002 17:05:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B04640BD327@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Scoping Scoped Addresses Thread-Index: AcKHhB8dilTV7SwgSRqEQyGDqSziOwA9r9rg From: "Michel Py" To: "Keith Moore" Cc: "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAB14ckd000648 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> This ignores the fact that many people will use site-locals >> because addresses that are not publicly routable are a >> requirement, and this regardless of the fact they have a >> stable global prefix or not. Besides, stable global prefixes >> do not exist today for end-sites. > Keith Moore wrote: > sites that think they have this requirement are not stating > it correctly. Very Good. The next time there is a $50 M government contract, you can go see these guys and tell them their requirements are full of it. It won't change anything and *I* will get the $50 M contract. Thank you very much. Ladies and gentlemen, if you are among my competitors please do listen to Keith carefully. 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 Nov 10 17:14:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB1Elkd000755; Sun, 10 Nov 2002 17:14:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAB1ElWv000754; Sun, 10 Nov 2002 17:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB1Ehkd000747 for ; Sun, 10 Nov 2002 17:14:43 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAB1ErbB000794 for ; Sun, 10 Nov 2002 17:14:53 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19750 for ; Sun, 10 Nov 2002 17:14:47 -0800 (PST) Subject: RE: Naming and site-local addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Sun, 10 Nov 2002 17:15:16 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E437@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Naming and site-local addresses Thread-Index: AcKIwAF3fqOSHOO/T6qSta3TbrX4VQAXtkaQ 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 gAB1Eikd000748 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Harald, Harald Tveit Alvestrand > This seems to lead me to one of two conclusions: > - Address lookup is significantly more complex in the > presence of site-local than if only global-scoped > addresses are used > - I missed something. I think you missed the fact the dual-headed DNS you mentioned is in use in many organizations even the ones that have only global-scoped addresses. One of the main reasons is that networks administrators don't want their DNS servers to resolve the entire network if the request comes from the outside. In other words, if foo.example.com is a secure host, it makes a lot of sense to configure the DNS servers to resolve it if the request comes from within the administrative boundaries of the site, and *not* resolve it if the request comes from the outside. Therefore, the complexity of administering the dual-headed DNS is not a by-product of the use of site locals, but a desire of the administrator to limit lookups. 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 Nov 10 17:22:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB1M7kd000857; Sun, 10 Nov 2002 17:22:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAB1M7Vc000856; Sun, 10 Nov 2002 17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB1M3kd000849 for ; Sun, 10 Nov 2002 17:22:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAB1MCbB001680 for ; Sun, 10 Nov 2002 17:22:12 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23090 for ; Sun, 10 Nov 2002 18:22:06 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAB1M2l15448; Sun, 10 Nov 2002 20:22:02 -0500 (EST) Message-Id: <200211110122.gAB1M2l15448@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "IPng" Subject: Re: Scoping Scoped Addresses In-reply-to: (Your message of "Sun, 10 Nov 2002 17:05:10 PST.") <2B81403386729140A3A899A8B39B04640BD327@server2000> Date: Sun, 10 Nov 2002 20:22:02 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Very Good. The next time there is a $50 M government contract, you can > go see these guys and tell them their requirements are full of it. *of course* the government is full of it. this is news? but IETF's job is to design sound protocols and recommend sound practices, not to do whatever some government bureaucrats think is a good idea. and if you want to take their money, that's your business. but don't expect IETF to endorse your business practices. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 10 17:28:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB1SFkd000943; Sun, 10 Nov 2002 17:28:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAB1SFaJ000942; Sun, 10 Nov 2002 17:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB1SBkd000935 for ; Sun, 10 Nov 2002 17:28:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAB1SKbB002282 for ; Sun, 10 Nov 2002 17:28:20 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24726 for ; Sun, 10 Nov 2002 18:28:15 -0700 (MST) Subject: RE: Scoping Scoped Addresses Date: Sun, 10 Nov 2002 17:28:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E439@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Scoping Scoped Addresses Thread-Index: AcKJIPMTHtNFo+jsSeW66Kw64zGjaQAACSvw From: "Michel Py" To: "Keith Moore" Cc: "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAB1SCkd000936 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore wrote: > *of course* the government is full of it. this is news? I'm sure it's so full of it that they will be happy to remove the part of your salary that comes from government funds. I will make a pleasure to forward your opinions to the appropriate persons. 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 Nov 10 17:49:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB1nMkd001060; Sun, 10 Nov 2002 17:49:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAB1nMsG001059; Sun, 10 Nov 2002 17:49: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB1nHkd001052 for ; Sun, 10 Nov 2002 17:49:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAB1nQbB004318 for ; Sun, 10 Nov 2002 17:49:27 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08887 for ; Sun, 10 Nov 2002 18:49:21 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAB1nGl15558; Sun, 10 Nov 2002 20:49:16 -0500 (EST) Message-Id: <200211110149.gAB1nGl15558@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "IPng" Subject: Re: Scoping Scoped Addresses In-reply-to: (Your message of "Sun, 10 Nov 2002 17:28:43 PST.") <2B81403386729140A3A899A8B39B046405E439@server2000> Date: Sun, 10 Nov 2002 20:49:16 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Keith Moore wrote: > > *of course* the government is full of it. this is news? > > I'm sure it's so full of it that they will be happy to remove the part > of your salary that comes from government funds. I will make a pleasure > to forward your opinions to the appropriate persons. Our responsibility as IETF participants is to give our technical opinions as individual engineers as to what is best for the Internet as a whole. I take that responsibility seriously. Your threats (including the threat of bodily harm that you just sent to me in private mail) will not change my technical opinions, nor my postings. 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 Sun Nov 10 18:41:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB2fUkd001465; Sun, 10 Nov 2002 18:41:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAB2fUdL001464; Sun, 10 Nov 2002 18:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB2fRkd001457 for ; Sun, 10 Nov 2002 18:41:27 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAB2fabB009571 for ; Sun, 10 Nov 2002 18:41:36 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14971 for ; Sun, 10 Nov 2002 18:41:31 -0800 (PST) Subject: RE: A few comments on Site-Local Useage Date: Sun, 10 Nov 2002 18:41:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E43F@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: A few comments on Site-Local Useage Thread-Index: AcKFbEVx2uBpSgKgSxiSsOJaKhbC9ADvtxHg From: "Michel Py" To: "Mark Smith" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAB2fRkd001458 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mark Smith wrote: > Could it be argued that if there was a need for confederations > in BGP to handle iBGP scaling, then there would a reason for > site-locals to be carried by BGP, presuming a single instance > of site-local addressing across the organisation ? I don't think so. Although it is true that large organizations will be concerned by the scalability of their IGP and more specifically by convergence speed, the path to this is internal aggregation. Site-locals can be aggregated internally like any other address. 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 Nov 10 19:41:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB3fKkd001614; Sun, 10 Nov 2002 19:41:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAB3fKj8001613; Sun, 10 Nov 2002 19:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB3fHkd001606 for ; Sun, 10 Nov 2002 19:41:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAB3fQbB015680 for ; Sun, 10 Nov 2002 19:41:26 -0800 (PST) Received: from mail.nosense.org (234.cust2.nsw.dsl.ozemail.com.au [203.103.157.234]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA09469 for ; Sun, 10 Nov 2002 20:41:20 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 9BFF63B368; Mon, 11 Nov 2002 14:41:18 +1100 (EST) Subject: RE: A few comments on Site-Local Useage From: Mark Smith To: Michel Py Cc: ipng@sunroof.eng.sun.com In-Reply-To: <2B81403386729140A3A899A8B39B046405E43F@server2000> References: <2B81403386729140A3A899A8B39B046405E43F@server2000> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 11 Nov 2002 14:41:18 +1100 Message-Id: <1036986078.6493.83.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have no experience with BGP confederations, so I could easily be wrong, however I was under the impression that the idea that BGP confederations was to reduce the number of iBGP sessions (ie avoid the full mesh iBGP problem), not so much address aggregation itself. If this is the case, I think there is a need for BGP, or at least the pseudo EBGP connections between the pseudo ASs in your confederation, to carry site-local addressing. Mark. On Mon, 2002-11-11 at 13:41, Michel Py wrote: > > Mark Smith wrote: > > Could it be argued that if there was a need for confederations > > in BGP to handle iBGP scaling, then there would a reason for > > site-locals to be carried by BGP, presuming a single instance > > of site-local addressing across the organisation ? > > I don't think so. Although it is true that large organizations will be > concerned by the scalability of their IGP and more specifically by > convergence speed, the path to this is internal aggregation. Site-locals > can be aggregated internally like any other address. > > 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 Nov 10 23:00:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB70Ikd002061; Sun, 10 Nov 2002 23:00:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAB70IWG002060; Sun, 10 Nov 2002 23:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB70Fkd002053 for ; Sun, 10 Nov 2002 23:00:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAB70OMq023847 for ; Sun, 10 Nov 2002 23:00:24 -0800 (PST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05893 for ; Mon, 11 Nov 2002 00:00:18 -0700 (MST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6843362206; Mon, 11 Nov 2002 08:00:13 +0100 (CET) Date: Mon, 11 Nov 2002 08:00:13 +0100 From: Harald Tveit Alvestrand To: Michel Py , ipng@sunroof.eng.sun.com Subject: RE: Naming and site-local addresses Message-ID: <2111910000.1036998013@askvoll.hjemme.alvestrand.no> In-Reply-To: <2B81403386729140A3A899A8B39B046405E437@server2000> References: <2B81403386729140A3A899A8B39B046405E437@server2000> 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 gAB70Fkd002054 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --On søndag, november 10, 2002 17:15:16 -0800 Michel Py wrote: > Harald, > > Harald Tveit Alvestrand >> This seems to lead me to one of two conclusions: >> - Address lookup is significantly more complex in the >> presence of site-local than if only global-scoped >> addresses are used >> - I missed something. > > I think you missed the fact the dual-headed DNS you mentioned is in use > in many organizations even the ones that have only global-scoped > addresses. One of the main reasons is that networks administrators don't > want their DNS servers to resolve the entire network if the request > comes from the outside. > > In other words, if foo.example.com is a secure host, it makes a lot of > sense to configure the DNS servers to resolve it if the request comes > from within the administrative boundaries of the site, and *not* resolve > it if the request comes from the outside. That is well known. It's also a pain to configure, and the names leak all over the place (check out the Received: headers of this message - there should be at least one leaked "internal" name in it, with a corresponding 192.168.x.x IP address). I run two different DNS servers on a 7-machine home LAN in order to support this configuration; I can't get redundant DNS servers for the local clients because I don't have a third machine (and don't want to configure Bind 9 with zone support - too much work to learn). > Therefore, the complexity of administering the dual-headed DNS is not a > by-product of the use of site locals, but a desire of the administrator > to limit lookups. My question to you is whether: - the use of site-local FORCES you to use split DNS, even if you otherwise don't need to - the use of site-local and split-DNS FORCES you to let the boundaries of the site follow the boundaries of your security perimeter, or suffer the N*2 problem of having to manage four categories of names rather than two (btw, IMNSHO, the security argument for split DNS is security through obscurity - it only protects you against the stupid bad guys....) 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 Sun Nov 10 23:06:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB76Kkd002121; Sun, 10 Nov 2002 23:06:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAB76KbE002120; Sun, 10 Nov 2002 23:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB76Hkd002113 for ; Sun, 10 Nov 2002 23:06:17 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAB76QMq024776 for ; Sun, 10 Nov 2002 23:06:26 -0800 (PST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA10324 for ; Sun, 10 Nov 2002 23:06:20 -0800 (PST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF96362206; Mon, 11 Nov 2002 08:06:18 +0100 (CET) Date: Mon, 11 Nov 2002 08:06:18 +0100 From: Harald Tveit Alvestrand To: Dan Lanciani , ipng@sunroof.eng.sun.com Subject: Address allocation schemes (Re: Naming and site-local) Message-ID: <2112390000.1036998378@askvoll.hjemme.alvestrand.no> In-Reply-To: <200211102025.PAA16950@ss10.danlan.com> References: <200211102025.PAA16950@ss10.danlan.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 gAB76Hkd002114 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --On søndag, november 10, 2002 15:25:56 -0500 Dan Lanciani wrote: > As long as we are stuck with a totally non-scalable address allocation > system (remember, provider-based aggregated addressing consumes address > space *exponentially* in the number of providers in the service chain) > end users need some way to provision local systems with stable addresses. > So far, nobody has proposed a viable alternative to scoped addresses. metro addressing? btw, my current naive prediction of the way the Internet will evolve is that unless new invention occurs, the default-free zone will eventually be flat-routing on the number of ISPs in the world, and that this number will have 5 digits. stable addresses for the lifetime of your ISP service contract seems like a not too terrible deal, if renumbering is easy. for IPv6 address allocation schemes, check out http://www.ripe.net/ripe/docs/ipv6-sparse.html for some recent thoughts. 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 Nov 11 00:32:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB8WNkd002420; Mon, 11 Nov 2002 00:32:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAB8WN4q002419; Mon, 11 Nov 2002 00:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAB8WKkd002412 for ; Mon, 11 Nov 2002 00:32:20 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAB8WSMq008404 for ; Mon, 11 Nov 2002 00:32:29 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09659 for ; Mon, 11 Nov 2002 01:32:23 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA19423 for ; Mon, 11 Nov 2002 08:32:21 GMT Received: from login.ecs.soton.ac.uk (IDENT:9RHZlQPi23HeZRf81IYgedgCajgKxifj@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAB8WCWX015919 for ; Mon, 11 Nov 2002 08:32:13 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gAB8WC123473 for ipng@sunroof.eng.sun.com; Mon, 11 Nov 2002 08:32:12 GMT Date: Mon, 11 Nov 2002 08:32:12 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Naming and site-local addresses Message-ID: <20021111083212.GD23167@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <2B81403386729140A3A899A8B39B046405E437@server2000> <2111910000.1036998013@askvoll.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2111910000.1036998013@askvoll.hjemme.alvestrand.no> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Nov 11, 2002 at 08:00:13AM +0100, Harald Tveit Alvestrand wrote: > > My question to you is whether: > > - the use of site-local FORCES you to use split DNS, even if you otherwise > don't need to > > - the use of site-local and split-DNS FORCES you to let the boundaries of > the site follow the boundaries of your security perimeter, or suffer the > N*2 problem of having to manage four categories of names rather than two Well, it's not uncommon that hosts in DNS domains do not always fall into what would be one site, thus hosts pointed to by aaa.foo.com, bbb.foo.com and ccc.foo.com can be in entirely different administrative and physical sites. This would cause some site-local headaches. I agree with Keith that the logical conclusion is that whenever a site-local and global address are returned the only non-ambiguous decision to take is to prefer the global address. But that means we lose the nice property of prefering site-locals intra-site to help maintain long-standing connections (e.g. NFS) through external renumbering or connectivity events that alter global prefixes seen within the site. It seems the only way around that is to either use a special unique "site-local global" prefix internally (plucked from some method as yet undefined, Keith's ideas to date there are "woolly" at best :) or to use a parallel/split DNS naming structure internally (be it foo.site or otherwise, indeed in my own NATed v4 home network I use .home in the scope of my home network for that purpose on Net10, not pretty but it works), or to use only site-local literals. Are there other solutions? There seems no easy answer either way, but the dangers of site-local addresses leaking or causing problems (the mobility question seems particularly nasty) means the sane solution surely has to be preference for globals? > (btw, IMNSHO, the security argument for split DNS is security through > obscurity - it only protects you against the stupid bad guys....) Little different to NAT :) 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 Nov 11 05:46:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABDkvkd003274; Mon, 11 Nov 2002 05:46:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABDkv55003273; Mon, 11 Nov 2002 05:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABDkskd003266 for ; Mon, 11 Nov 2002 05:46:54 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABDl3Mq013285 for ; Mon, 11 Nov 2002 05:47:03 -0800 (PST) Received: from laptop2.kurtis.pp.se (tlp1.cobweb.autonomica.se [130.244.10.138]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03348 for ; Mon, 11 Nov 2002 05:46:57 -0800 (PST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gABDlAwc017971; Mon, 11 Nov 2002 14:47:10 +0100 (CET) Date: Mon, 11 Nov 2002 14:47:09 +0100 Subject: Re: question regarding possible use of SLs in renumbering Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Keith Moore" , "IPng" To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <2B81403386729140A3A899A8B39B04640BD313@server2000> Message-Id: <13183959-F57C-11D6-A223-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Since you don't answer the question, I'll answer it myself. Site-locals > without NAT do not break applications. > A comment that might have be said in mail volumes...(I am slowly loosing track..) I can see a condition where site-locals do not break applications. If the source address selection algorithm is set to always use a SL address if one is present and then ignore all globals. - 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 Nov 11 06:44:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABEiXkd003443; Mon, 11 Nov 2002 06:44:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABEiXLE003441; Mon, 11 Nov 2002 06:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABEiQkd003426 for ; Mon, 11 Nov 2002 06:44:27 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABEiZbB000075 for ; Mon, 11 Nov 2002 06:44:35 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13982 for ; Mon, 11 Nov 2002 06:44:30 -0800 (PST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gABEiTsL233136 for ; Mon, 11 Nov 2002 09:44:29 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gABEiQnm120464 for ; Mon, 11 Nov 2002 09:44:27 -0500 To: ipng@sunroof.eng.sun.com Subject: Questions on Configured Tunnel MTU and TOS Byte Settings MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 11/11/2002 09:39:31 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 11/11/2002 09:39:31 AM, Serialize complete at 11/11/2002 09:39:31 AM, S/MIME Sign failed at 11/11/2002 09:39:31 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|October 31, 2002) at 11/11/2002 07:44:28, Serialize complete at 11/11/2002 07:44:28 Message-ID: Date: Mon, 11 Nov 2002 09:44:27 -0500 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've got a few of questions on configured tunnels, as described in draft-ietf-ngtrans-mech-v2-01.txt. - Section 3.2 discusses how to set the tunnel MTU. It covers the case where the tunnel MTU size is manually configured, with a default of 1280. While it discusses capping the tunnel MTU at 4400 when IPv4 path MTU discovery is used, it doesn't discuss a maximum configured value for the tunnel. Does this mean there is no cap when manually configuring the tunnel MTU (i.e., the configured tunnel MTU may be as large as 65515, or even larger if jumbograms are used?) - The same section does not discuss what a host should do if it receives a Router Advertisement with an MTU option. Should the MTU value received be used? If so, is there a cap associated with this MTU value? In other words, if it exceeds 4400 bytes should the value be used? - In section 3.5, the TOS byte is defined as being set to 0 unless otherwise specified. What exactly does this mean? That, if RFC 2893 is followed the DSCP in the TOS byte may be set to a non-zero value? Or that RFC 2893 and RFC 3168 should explicitly NOT be implemented for configured tunnels? If the latter, I think some discussion on exactly WHY these two RFCs are not to be implemented would be helpful. - In section 3.6, the TOS byte of the inner packet is left unmodified at the tunnel egress. This seems to contradict some of the referenced. For instance, RFC 3168 defines both limited-functionality and full-functionality support for ECN support over tunnels. For limited-functionality, which seems to most closely match what is described in this draft, it discusses what to do at the tunnel egress if the CE option is set in the outer packet header but not the inner packet header. This processing does not seem to match what is described in this draft. Is this intentional? Roy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 06:44:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABEiXkd003442; Mon, 11 Nov 2002 06:44:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABEiXRa003440; Mon, 11 Nov 2002 06:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABEiRkd003427 for ; Mon, 11 Nov 2002 06:44:27 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABEiZbB000077 for ; Mon, 11 Nov 2002 06:44:35 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02684 for ; Mon, 11 Nov 2002 06:44:30 -0800 (PST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gABEiT4Z215342 for ; Mon, 11 Nov 2002 09:44:29 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gABEiQnn120464 for ; Mon, 11 Nov 2002 09:44:28 -0500 In-Reply-To: To: ipng@sunroof.eng.sun.com Subject: Re: Questions on Configured Tunnel MTU and TOS Byte Settings MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 11/11/2002 09:41:34 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 11/11/2002 09:41:34 AM, Serialize complete at 11/11/2002 09:41:34 AM, S/MIME Sign failed at 11/11/2002 09:41:34 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|October 31, 2002) at 11/11/2002 07:44:28, Serialize complete at 11/11/2002 07:44:28 Message-ID: Date: Mon, 11 Nov 2002 09:44:27 -0500 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Oops - I meant for this to go to NGTRANS and V6OPS. Roy > I've got a few of questions on configured tunnels, as described in > draft-ietf-ngtrans-mech-v2-01.txt. > > - Section 3.2 discusses how to set the tunnel MTU. It covers the case > where the tunnel MTU size is manually configured, with a default of > 1280. While it discusses capping the tunnel MTU at 4400 when IPv4 > path MTU discovery is used, it doesn't discuss a maximum configured > value for the tunnel. Does this mean there is no cap when manually > configuring the tunnel MTU (i.e., the configured tunnel MTU may be as > large as 65515, or even larger if jumbograms are used?) > > - The same section does not discuss what a host should do if it receives a > Router Advertisement with an MTU option. Should the MTU value received > be used? If so, is there a cap associated with this MTU value? In > other words, if it exceeds 4400 bytes should the value be used? > > - In section 3.5, the TOS byte is defined as being set to 0 unless > otherwise specified. What exactly does this mean? That, if RFC 2893 is > followed the DSCP in the TOS byte may be set to a non-zero value? Or > that RFC 2893 and RFC 3168 should explicitly NOT be implemented for > configured tunnels? If the latter, I think some discussion on exactly > WHY these two RFCs are not to be implemented would be helpful. > > - In section 3.6, the TOS byte of the inner packet is left unmodified at > the tunnel egress. This seems to contradict some of the referenced. > For instance, RFC 3168 defines both limited-functionality and > full-functionality support for ECN support over tunnels. For > limited-functionality, which seems to most closely match what is > described in this draft, it discusses what to do at the tunnel egress if > the CE option is set in the outer packet header but not the inner packet > header. This processing does not seem to match what is described in > this draft. Is this intentional? > > Roy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 09:03:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABH33kd004333; Mon, 11 Nov 2002 09:03:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABH33wX004332; Mon, 11 Nov 2002 09:03:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABH2xkd004319 for ; Mon, 11 Nov 2002 09:02:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABH38Mq021592 for ; Mon, 11 Nov 2002 09:03:08 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27910 for ; Mon, 11 Nov 2002 10:03:03 -0700 (MST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gABH2uIX001977; Mon, 11 Nov 2002 09:02:56 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAO15066; Mon, 11 Nov 2002 08:57:11 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA14952; Mon, 11 Nov 2002 09:02:54 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15823.58046.173678.441428@thomasm-u1.cisco.com> Date: Mon, 11 Nov 2002 09:02:54 -0800 (PST) To: Harald Tveit Alvestrand Cc: Dan Lanciani , ipng@sunroof.eng.sun.com Subject: Address allocation schemes (Re: Naming and site-local) In-Reply-To: <2112390000.1036998378@askvoll.hjemme.alvestrand.no> References: <200211102025.PAA16950@ss10.danlan.com> <2112390000.1036998378@askvoll.hjemme.alvestrand.no> 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 Harald Tveit Alvestrand writes: > btw, my current naive prediction of the way the Internet will evolve is > that unless new invention occurs, the default-free zone will eventually be > flat-routing on the number of ISPs in the world, and that this number will > have 5 digits. > > stable addresses for the lifetime of your ISP service contract seems like a > not too terrible deal, if renumbering is easy. > > for IPv6 address allocation schemes, check out > http://www.ripe.net/ripe/docs/ipv6-sparse.html for some recent thoughts. Harald, I think this probably boils down to something completely non-technical: do people view IP addresses as "addresses" ala street addresses, etc, or do they view them as possessions like (now) phone numbers and email addresses. Though the net was designed for "addresses", I suspect that they are viewed more as possessions which is an obvious problem. The only question that remains is whether we are -- as they say -- pissing up a rope. If we are, we just need to accept reality and move on from there. 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 Nov 11 09:15:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABHFbkd004557; Mon, 11 Nov 2002 09:15:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABHFbqk004556; Mon, 11 Nov 2002 09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABHFYkd004549 for ; Mon, 11 Nov 2002 09:15:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABHFhMq024898 for ; Mon, 11 Nov 2002 09:15:43 -0800 (PST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04514 for ; Mon, 11 Nov 2002 10:15:37 -0700 (MST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F24262206; Mon, 11 Nov 2002 18:15:36 +0100 (CET) Date: Mon, 11 Nov 2002 18:15:36 +0100 From: Harald Tveit Alvestrand To: Michael Thomas Cc: Dan Lanciani , ipng@sunroof.eng.sun.com Subject: Re: Address allocation schemes (Re: Naming and site-local) Message-ID: <89210000.1037034936@askvoll.hjemme.alvestrand.no> In-Reply-To: <15823.58046.173678.441428@thomasm-u1.cisco.com> References: <200211102025.PAA16950@ss10.danlan.com> <2112390000.1036998378@askvoll.hjemme.alvestrand.no> <15823.58046.173678.441428@thomasm-u1.cisco.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 --On mandag, november 11, 2002 09:02:54 -0800 Michael Thomas wrote: > I think this probably boils down to something > completely non-technical: do people view IP > addresses as "addresses" ala street addresses, > etc, or do they view them as possessions like > (now) phone numbers and email addresses. Though > the net was designed for "addresses", I suspect > that they are viewed more as possessions which is > an obvious problem. my personal opinion is that the only people who feel any possessive instinct towards 2002:d90d:1cca:2:210:dcff:fe5a:f1fd are the people who have to reconfigure other stuff when it changes..... unlike domain names or easy-to-remember phone numbers, hanging on to a v6 address is something you do for practical reasons, not emotional ones. of course, I could be 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 Mon Nov 11 09:23:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABHNbkd004640; Mon, 11 Nov 2002 09:23:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABHNatk004639; Mon, 11 Nov 2002 09:23:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABHNXkd004632 for ; Mon, 11 Nov 2002 09:23:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABHNfbB001829 for ; Mon, 11 Nov 2002 09:23:41 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13253 for ; Mon, 11 Nov 2002 10:23:36 -0700 (MST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gABHNZ4Z070248 for ; Mon, 11 Nov 2002 12:23:35 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gABHNXv3158896 for ; Mon, 11 Nov 2002 12:23:33 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gABHJJa29778 for ; Mon, 11 Nov 2002 12:19:19 -0500 Message-Id: <200211111719.gABHJJa29778@rotala.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: MIPv6 and site local addresses Date: Mon, 11 Nov 2002 12:19:19 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One more apparent headache: a mobile node running mobile IP for IPv6 (MIPv6) will often be in 2 different domains simultaneously. It's home domain (where it continues to have a Home Address and the domain that it is currently visiting). How does one handle site-locals in this case? Consider the comparatively easy configuration where MIP is using global addresses for everything, but both sites happen to use SLs for some of their own internal stuff. When the MN needs to send an IP packet to a particular address, and it is a SL address, where does it send it? should it: - tunnel it back through the Home Agent? (I.e., assume the address is for a node at its home site) - send the packet locally (i.e, assume the packet is for a node on the local site) Problem is, neither answer is right in all cases, and it seems like there are no easy rules for making the right thing happen in all cases. This leads me to conclude that using both SLs and MIP together will lead to scenarios where communication will fail, when the typical user will expect them to succeed. This does not seem good like a good situation. Note that a fundamental assumption (at least in my mind) is that when one uses MIPv6, everything should "just work". SLs seem to introduce some problems here. Note that the situation is a whole lot messier still, if the MN's Home Address is SL, or if the HAs it is using are SL. But one can at least say "don't do that". But it still leaves the above issue unresolved. 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 Nov 11 10:05:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABI5skd004954; Mon, 11 Nov 2002 10:05:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABI5sno004953; Mon, 11 Nov 2002 10:05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABI5okd004946 for ; Mon, 11 Nov 2002 10:05:51 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABI60Mq010042 for ; Mon, 11 Nov 2002 10:06:00 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10963 for ; Mon, 11 Nov 2002 10:05:54 -0800 (PST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gABI5WWR059074; Mon, 11 Nov 2002 13:05:32 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gABI5VUu069860; Mon, 11 Nov 2002 11:05:32 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gABI1GL30099; Mon, 11 Nov 2002 13:01:16 -0500 Message-Id: <200211111801.gABI1GL30099@rotala.raleigh.ibm.com> To: Keith Moore cc: IPng Subject: Re: question regarding possible use of SLs in renumbering In-Reply-To: Message from Keith Moore of "Thu, 07 Nov 2002 12:10:05 EST." <200211071710.gA7HA5l10275@astro.cs.utk.edu> Date: Mon, 11 Nov 2002 13:01:16 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > is it reasonable to assume that if a network is advertising one or more > global prefixes via ND/RD, that the scope of a 'site' for SL addresses > corresponds to the scope in which those global prefixes are > advertised? I think this would be an incorrect assumption. The question comes down to "what is a site", and opinions vary. Some have argued that a site is small area, like a building or campus. Others assume a site is as large as the entire organization. Checking various documents, addr-arch doesn't say what a site is, but draft-ietf-ipngwg-scoping-arch-04.txt says: o Site-local scope, for uniquely identifying interfaces within a single site only. A "site" is, by intent, not rigorously defined, but is typically expected to cover a region of topology that belongs to a single organization and is located within a single geographic location, such as an office, an office complex, or a campus. A personal residence may be treated as a site (for example, when the residence obtains Internet access via a public Internet service provider), or as a part of a site (for example, when the residence obtains Internet access via an employer's or school's site). > in other words, would it really be reasonable to assume that one could > use SL addresses in some renumbering protocol and have them be able to > reach all of the hosts/routers/apps that were affected by a prefix > change? I think one can imagine SLs being useful to avoid some of the potential problems that renumbering lead to (e.g., like the need to update config files). But the details of this have not really be fleshed out (e.g., can this be done with SLs being also being in the DNS? MUST they be?). So I don't think one can say definitively, that SLs *don't* or *can't* help. But I also don't believe one can say they *do* help either, because the details have not been fleshed out, AFAIK. 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 Nov 11 11:01:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABJ1lkd005290; Mon, 11 Nov 2002 11:01:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABJ1k2q005289; Mon, 11 Nov 2002 11:01: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABJ1hkd005282 for ; Mon, 11 Nov 2002 11:01:43 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABJ1qMq026955 for ; Mon, 11 Nov 2002 11:01:52 -0800 (PST) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19034 for ; Mon, 11 Nov 2002 12:01:47 -0700 (MST) Received: from [128.177.194.134] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id B52BA137F04; Mon, 11 Nov 2002 11:01:46 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 11 Nov 2002 11:04:08 -0800 Subject: Re: Address allocation schemes (Re: Naming and site-local) From: David Conrad To: Harald Tveit Alvestrand , Michael Thomas Cc: Dan Lanciani , IPng Message-ID: In-Reply-To: <89210000.1037034936@askvoll.hjemme.alvestrand.no> 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, On 11/11/02 9:15 AM, "Harald Tveit Alvestrand" wrote: > my personal opinion is that the only people who feel any possessive > instinct towards 2002:d90d:1cca:2:210:dcff:fe5a:f1fd are the people who > have to reconfigure other stuff when it changes..... Or the people who are affected when reconfiguration occurs. Welcome to NATv6. 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 Mon Nov 11 11:15:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABJF3kd005401; Mon, 11 Nov 2002 11:15:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABJF21R005400; Mon, 11 Nov 2002 11:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABJExkd005393 for ; Mon, 11 Nov 2002 11:14:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABJF8bB008259 for ; Mon, 11 Nov 2002 11:15:08 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17921 for ; Mon, 11 Nov 2002 12:15:00 -0700 (MST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 11 Nov 2002 11:14:57 -0800 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Nov 2002 11:14:59 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 11 Nov 2002 11:14:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: question regarding possible use of SLs in renumbering Date: Mon, 11 Nov 2002 11:14:49 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question regarding possible use of SLs in renumbering thread-index: AcKHfrkEVl7XZyxzQLSsBRvElczQtACNl0JA From: "Richard Draves" To: "Margaret Wasserman" Cc: "IPng" X-OriginalArrivalTime: 11 Nov 2002 19:14:32.0915 (UTC) FILETIME=[90F9FA30:01C289B6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gABJExkd005394 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Wind River has multiple sites with Internet connectivity that > are connected via linked lines. If you think of two of them, > you can picture a dumbbell shaped network. Our ISP is > routing different parts of the Wind River network space to > different locations. So in IPv6 terms, your ISP understands the internal structure of your /48 - for example you might have some /56s routed one way and some another in your ISPs network? > However, if the leased line goes down (or one of the routers > to it goes down, etc.), global traffic will fall-back to > being routed over the global Internet... This is great > because it lets me reach non-secure parts of the other Wind > River site, even when my secure link is down. And, I can run > a client VPN solution to get behind the firewall, if I need to. Hmm, I wonder how prevalent this desire is. I think Microsoft's network admins would be very upset if my traffic to our Cambridge England lab (for example) were to end up on the public internet. They try hard to prevent this. >From my perspective, the Wind River network plan sounds fairly atypical of enterprise networks. Have you considered using multiple /48s (perhaps one for the insecure parts of your network and one for the secure parts, where the routing the secure portion of your network would be convex)? Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 11:32:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABJWFkd005568; Mon, 11 Nov 2002 11:32:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABJWEt6005567; Mon, 11 Nov 2002 11:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABJWBkd005560 for ; Mon, 11 Nov 2002 11:32:11 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABJWJbB013927 for ; Mon, 11 Nov 2002 11:32:20 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09972 for ; Mon, 11 Nov 2002 11:32:14 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 11 Nov 2002 11:31:53 -0800 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Nov 2002 11:32:07 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 11 Nov 2002 11:31:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Naming and site-local addresses Date: Mon, 11 Nov 2002 11:32:06 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Naming and site-local addresses thread-index: AcKIv3MpW66Jg3GjSZy1HOwDQEON/AA90Kng From: "Richard Draves" To: "Harald Tveit Alvestrand" Cc: X-OriginalArrivalTime: 11 Nov 2002 19:31:53.0723 (UTC) FILETIME=[FD58ACB0:01C289B8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gABJWBkd005561 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At the moment I believe we are stuck relying on two-faced DNS for resolving names to site-local addresses. Luckily(?) two-faced DNS is widely deployed. There are other approaches. For example draft-ietf-ipngwg-site-prefixes-05 was nice - among other things it generalized easily to other name translation systems or more generally to distributed apps that pass around addresses. But it has the problem of not being backwards-compatible with existing implementations. More recently (see the list archives around Oct 29) Mark Andrews has proposed another way to put site-locals (and link-locals) in the DNS. I agree that in practice to reduce complexity, site-local boundaries should align with security boundaries. Rich > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Sunday, November 10, 2002 5:38 AM > To: ipng@sunroof.eng.sun.com > Subject: Naming and site-local addresses > > > Forgive me if I am treading well-trodden paths here, but I am > trying to > understand.... > > It seems to me that using site-local addresses in > applications means that > applications have to get hold of these addresses somehow; very few > applications are fed addresses directly by their users. > > 99% of applications do some kind of name-to-address lookup > *before* they > start getting into what kind of addresses to use. (And I'm not just > thinking about DNS - SDP is an example of a non-DNS > name-to-address lookup > - find the session using name/description, and pick the IP from the > description fields). > > If a name-to-address lookup mechanism (ANY such mechanism) returns an > off-site site-local to the application, without the info that > this is an > off-site site-local, the application will not behave as > expected. (it will either connect to the address and fail, or > it will (worse) connect > to the address and succeed, but not to the point it wanted to go). > > That seems to me to mean that the name lookup mechanism has > to not only > return globals and local-site site-locals, but has to > *suppress* off-site > site-locals. > > Which again means that the lookup mechanism has to know the > scope identity > of BOTH the requester and the target resource, or choose to > return *no* > site-locals. > > now, a lot of DNS is two-faced, meaning that the DNS servers > have to be > aware of scopes around them; mainly, two-faced DNS > distinguishes between > "within the security boundary" and "not within the security > boundary". But a lot of the DNS is not. > > So using site-local with the DNS seems to require capturing > all DNS traffic > within the site, in case it tries to query for local resources, and > *keeping* it to DNS servers that know about the site of the > requester; this > would seem to mandate two-faced DNS, even when it's not necessary for > security, and, if security by firewall is in use, make it *extremely* > complex to configure site boundaries at any other place than > at security > boundaries. > > This seems to me to be actually harder than configuring the > site border > routers for routing........ not nicely behaved wrt DNS at > all, and maybe > even less nicely behaved with other naming schemes... > > This seems to lead me to one of two conclusions: > > - Address lookup is significantly more complex in the presence of > site-local than if only global-scoped addresses are used > > - I missed something. > > Comments? > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 11:34:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABJYskd005657; Mon, 11 Nov 2002 11:34:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABJYsoT005656; Mon, 11 Nov 2002 11:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABJYokd005639 for ; Mon, 11 Nov 2002 11:34:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABJYxMq006986 for ; Mon, 11 Nov 2002 11:34:59 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11150 for ; Mon, 11 Nov 2002 12:34:54 -0700 (MST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 11 Nov 2002 11:34:52 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Nov 2002 11:34:44 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 11 Nov 2002 11:34:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: MIPv6 and site local addresses Date: Mon, 11 Nov 2002 11:34:44 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv6 and site local addresses thread-index: AcKJp/poGg1Ce78uSV2g2SAUamIDGgAERxTA From: "Richard Draves" To: "Thomas Narten" Cc: X-OriginalArrivalTime: 11 Nov 2002 19:34:32.0681 (UTC) FILETIME=[5C17BD90:01C289B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gABJYpkd005642 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > One more apparent headache: a mobile node running mobile IP for IPv6 > (MIPv6) will often be in 2 different domains simultaneously. > It's home domain (where it continues to have a Home Address > and the domain that it is currently visiting). How does one > handle site-locals in this case? The mobile node is effectively multi-sited in this situation. Here's one way to implement this. Some (most?) MIPv6 implementations assign the home address to a virtual interface. Then the virtual interface belongs to the home site, and the physical interface (which has the care-of address) belongs to the foreign site. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 11:43:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABJhekd006114; Mon, 11 Nov 2002 11:43:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABJhVfq006107; Mon, 11 Nov 2002 11:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABJhSkd006098 for ; Mon, 11 Nov 2002 11:43:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABJhaMq010020 for ; Mon, 11 Nov 2002 11:43:37 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15611 for ; Mon, 11 Nov 2002 12:43:31 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gABJhPKV022782; Mon, 11 Nov 2002 20:43:25 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 11 Nov 2002 20:43:25 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0CD8@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Richard Draves'" , Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: RE: MIPv6 and site local addresses Date: Mon, 11 Nov 2002 20:43:25 +0100 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 > > One more apparent headache: a mobile node running mobile > IP for IPv6 > > (MIPv6) will often be in 2 different domains simultaneously. > > It's home domain (where it continues to have a Home Address > > and the domain that it is currently visiting). How does one > > handle site-locals in this case? > > The mobile node is effectively multi-sited in this > situation. Here's one > way to implement this. Some (most?) => All the ones I know of do that (virtual interface). MIPv6 implementations assign the > home address to a virtual interface. Then the virtual > interface belongs > to the home site, and the physical interface (which has the care-of > address) belongs to the foreign site. => I'm not sure this solves the problem though. It all depends on where the SL address came from. Is it in the visited site or the home site? src address selection should by default provide the HoA to the app, but if the SL is in the visited site, it won't work. So do we need some coupling between src address selection and the resolver? If the CoA is given to the app, then MIPv6 won't work unless you use something link HMIPv6 which provides a local HA. But this will only provide session continuity while the MN is moving within the MAP domain. Have I missed something? 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 Mon Nov 11 12:26:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABKQYkd007115; Mon, 11 Nov 2002 12:26:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABKQYOU007114; Mon, 11 Nov 2002 12: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABKQUkd007098 for ; Mon, 11 Nov 2002 12:26:30 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABKQOMq028499 for ; Mon, 11 Nov 2002 12:26:39 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20179 for ; Mon, 11 Nov 2002 13:26:18 -0700 (MST) 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 MAA25056; Mon, 11 Nov 2002 12:26:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gABKQIW13933; Mon, 11 Nov 2002 12:26:18 -0800 X-mProtect: <200211112026> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.209, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9EqCVr; Mon, 11 Nov 2002 12:26:13 PST Message-ID: <3DD012B5.81D5D692@iprg.nokia.com> Date: Mon, 11 Nov 2002 12:27:33 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and site local addresses References: <200211111719.gABHJJa29778@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Thomas, > Consider the comparatively easy configuration where MIP is using > global addresses for everything, but both sites happen to use SLs for > some of their own internal stuff. When the MN needs to send an IP > packet to a particular address, and it is a SL address, where does it > send it? should it: > > - tunnel it back through the Home Agent? (I.e., assume the address is > for a node at its home site) > > - send the packet locally (i.e, assume the packet is for a node on the > local site) What if the rule is that the mobile node tunnels when it is away from home, and sends the packet locally when it is deregistered and attached to its home network? I don't see the case where that isn't a reasonable thing to do. Our current restriction is that a mobile node that uses a site-local home address also must have a site-local care-of address when using that address. I think this eliminates the problem entirely. > Note that a fundamental assumption (at least in my mind) is that when > one uses MIPv6, everything should "just work". SLs seem to introduce > some problems here. So far, when we have had problems, we have made restrictions (as just noted) so that indeed Mobile IPv6 just works. Sometimes the restrictions could be lifted by specifying additional protocol, but at this point the amount of additional protocol is to be reduced, even at the cost of some restriction. I hope this resolves the issue. 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 Nov 11 12:31:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABKVekd007342; Mon, 11 Nov 2002 12:31:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABKVdea007341; Mon, 11 Nov 2002 12:31: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABKVakd007334 for ; Mon, 11 Nov 2002 12:31:36 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABKVjbB002445 for ; Mon, 11 Nov 2002 12:31:45 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13711 for ; Mon, 11 Nov 2002 13:31:40 -0700 (MST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gABKVbWR042054; Mon, 11 Nov 2002 15:31:37 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gABKVaUu032936; Mon, 11 Nov 2002 13:31:36 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gABKRLV31326; Mon, 11 Nov 2002 15:27:21 -0500 Message-Id: <200211112027.gABKRLV31326@rotala.raleigh.ibm.com> To: "Richard Draves" cc: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and site local addresses In-Reply-To: Message from "Richard Draves" of "Mon, 11 Nov 2002 11:34:44 PST." Date: Mon, 11 Nov 2002 15:27:20 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The mobile node is effectively multi-sited in this situation. Here's one > way to implement this. Some (most?) MIPv6 implementations assign the > home address to a virtual interface. Then the virtual interface belongs > to the home site, and the physical interface (which has the care-of > address) belongs to the foreign site. I take it that the implication here is that all MNs need to be multi-sited and support the site scoping document (or equivalent). In other words, it will need to be widely supported in practice. Is this really the implication? There is a hope/expectation that very many nodes will implement MIPv6. It would be nice of MNs wouldn't be required to implement the scoping document in order to make things work. 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 Nov 11 12:39:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABKd4kd007689; Mon, 11 Nov 2002 12:39:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABKd3pt007688; Mon, 11 Nov 2002 12:39: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABKd0kd007678 for ; Mon, 11 Nov 2002 12:39:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABKd8bB004388 for ; Mon, 11 Nov 2002 12:39:09 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17856 for ; Mon, 11 Nov 2002 13:39:03 -0700 (MST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gABKcp4s090920; Mon, 11 Nov 2002 15:38:51 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gABKcmv3140086; Mon, 11 Nov 2002 15:38:49 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gABKYZo31374; Mon, 11 Nov 2002 15:34:35 -0500 Message-Id: <200211112034.gABKYZo31374@rotala.raleigh.ibm.com> To: Charlie Perkins cc: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and site local addresses In-Reply-To: Message from Charlie Perkins of "Mon, 11 Nov 2002 12:27:33 PST." <3DD012B5.81D5D692@iprg.nokia.com> Date: Mon, 11 Nov 2002 15:34:35 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie Perkins writes: > Hello Thomas, > > Consider the comparatively easy configuration where MIP is using > > global addresses for everything, but both sites happen to use SLs for > > some of their own internal stuff. When the MN needs to send an IP > > packet to a particular address, and it is a SL address, where does it > > send it? should it: > > > > - tunnel it back through the Home Agent? (I.e., assume the address is > > for a node at its home site) > > > > - send the packet locally (i.e, assume the packet is for a node on the > > local site) > What if the rule is that the mobile node tunnels when it is away > from home, and sends the packet locally when it is deregistered > and attached to its home network? I don't see the case where > that isn't a reasonable thing to do. The problem is that this doesn't seem to work in all cases. If the visited site is using SL addresses, the above rule means that the MN can't use them (for conversing with local nodes, at least not while using its Home Address). In other words, things that work one way for a regular node at the visited cite, won't work for the MN. That doesn't seem like a desireable property. > Our current restriction is that a mobile node that uses a site-local > home address also must have a site-local care-of address when > using that address. I think this eliminates the problem entirely. The issue I cite also occurs when neither the Home Address or COA is a SL, so I don't understand the above comment. > > Note that a fundamental assumption (at least in my mind) is that when > > one uses MIPv6, everything should "just work". SLs seem to introduce > > some problems here. > So far, when we have had problems, we have made restrictions > (as just noted) so that indeed Mobile IPv6 just works. Sometimes > the restrictions could be lifted by specifying additional protocol, but > at this point the amount of additional protocol is to be reduced, > even at the cost of some restriction. My comments were prompted by my reading of the MIPv6 spec. IMO, the SL wording there has problems. In a few places, it says things like "if you are visiting a network with the same site as your home, then ...". But, AFAIK, we have know of no way of determining what site a node is connected to when it visits some arbitrary link. 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 Nov 11 12:56:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABKu3kd008351; Mon, 11 Nov 2002 12:56:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABKu2ZK008347; Mon, 11 Nov 2002 12:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABKttkd008337 for ; Mon, 11 Nov 2002 12:55:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABKu4Mq006883 for ; Mon, 11 Nov 2002 12:56:04 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27499 for ; Mon, 11 Nov 2002 13:55:59 -0700 (MST) 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 MAA26606; Mon, 11 Nov 2002 12:55:58 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gABKtw422309; Mon, 11 Nov 2002 12:55:58 -0800 X-mProtect: <200211112055> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.209, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5Jlkya; Mon, 11 Nov 2002 12:55:54 PST Message-ID: <3DD019AB.828FC0AF@iprg.nokia.com> Date: Mon, 11 Nov 2002 12:57:15 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and site local addresses References: <200211112034.gABKYZo31374@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello again Thomas, Thomas Narten wrote: > The problem is that this doesn't seem to work in all cases. If the > visited site is using SL addresses, the above rule means that the MN > can't use them (for conversing with local nodes, at least not while > using its Home Address). In other words, things that work one way for > a regular node at the visited cite, won't work for the MN. That > doesn't seem like a desireable property. I guess the Mobile IPv6 specification is not supposed to cover cases where the mobile node is not using Mobile IPv6. Then, if a mobile node wants to use visited site-local addresses for communication within the visited site, that should be O.K. If the mobile node IS using Mobile IPv6 with a global care-of address, then ...? should it use that global care-of address for other communications (e.g., very short term) for which the home address is not involved? > > So far, when we have had problems, we have made restrictions > > (as just noted) so that indeed Mobile IPv6 just works. Sometimes > > the restrictions could be lifted by specifying additional protocol, but > > at this point the amount of additional protocol is to be reduced, > > even at the cost of some restriction. > > My comments were prompted by my reading of the MIPv6 spec. IMO, the SL > wording there has problems. In a few places, it says things like "if > you are visiting a network with the same site as your home, then > ...". But, AFAIK, we have know of no way of determining what site a > node is connected to when it visits some arbitrary link. > That is true, and it was discussed. The conclusion we came up with is that a mobile node might erroneously use a visited site-local address as a care-of address, but that its home agent would never see the Binding Update, so the mobile node would not be able to establish communications with its home site using the visited site-local address. This is the same, effectively, as the case where the node is not using Mobile IP at all. 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 Nov 11 14:06:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABM6Zkd011478; Mon, 11 Nov 2002 14:06:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABM6Yvg011475; Mon, 11 Nov 2002 14:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABM6Vkd011466 for ; Mon, 11 Nov 2002 14:06:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABM6ebB000588 for ; Mon, 11 Nov 2002 14:06:40 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25003 for ; Mon, 11 Nov 2002 15:06:34 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.41]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA23332; Mon, 11 Nov 2002 14:06:10 -0800 (PST) Message-Id: <5.1.0.14.2.20021111163240.02a6e330@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Nov 2002 17:02:39 -0500 To: "Richard Draves" From: Margaret Wasserman Subject: RE: Naming and site-local addresses Cc: "Harald Tveit Alvestrand" , 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 that in practice to reduce complexity, site-local boundaries >should align with security boundaries. To retain the "convexity" property needed for sites, the site boundaries also have to align with routing protocol area boundaries. So, in order to make the use of site-local addressing less complex, we will need to force site boundaries, security boundaries, "two faced" DNS boundaries and routing protocol area boundaries to coincide. And, these boundaries have to be in the middle of nodes, not on links. Is this acceptable? I realized that this may be common for simple leaf networks, but would it even work in a complex network? The inter-node boundary doesn't really work for some routing protocols that have their area boundaries on links (IS-IS and BGP), so we will be forced to use unnumbered "dummy sites" to make those protocols work properly across site boundaries. Will this be compatible with the security and "two faced" DNS boundaries? How would a site-border node (which exists in multiple sites), that has no knowledge of which site a particular domain name belongs to, decide which interface to use to send a DNS request? Does it need to try more than one and somehow combine or choose between the results? If a site-border node sends a DNS request and receives a site-local address in return, how does it know in which of its attached sites the site-local adddress is valid? Some people have stated that it can use the zone ID of the interface on which the DNS response is returned, but I think that this would only work if the "two faced" DNS server is topologically located inside the site. Is that a reasonable restriction? I am personally somewhat uncomfortable with the idea of all of these boundaries being tied together like this. In particularly, I thought that the DNS hierarchy was intentionally supposed to be independent of routing topology... 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 Nov 11 14:06:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABM6dkd011487; Mon, 11 Nov 2002 14:06:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABM6d3e011486; Mon, 11 Nov 2002 14:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABM6Ykd011473 for ; Mon, 11 Nov 2002 14:06:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABM6hMq028477 for ; Mon, 11 Nov 2002 14:06:43 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25035 for ; Mon, 11 Nov 2002 15:06:37 -0700 (MST) Subject: RE: Naming and site-local addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 11 Nov 2002 14:07:08 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E444@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Naming and site-local addresses Thread-Index: AcKJUC8sZrpQHP50QG+aKYet0+f5cgAabSmw 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 gABM6Ykd011474 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Harald, > Harald Tveit Alvestrand wrote: > [Dual-headed DNS] > That is well known. > It's also a pain to configure, No argument here; and still lots of people are doing it. > My question to you is whether: > - the use of site-local FORCES you to use split DNS, even > if you otherwise don't need to Not at all: - If the host has a site-local only address (which I recommend, although this is not consensual) all is needed is the existing one-headed DNS, no change. - If the host has both a site-local and a global address, this issue has nothing to do with site-locals and everything to do with multihoming / multiaddressing the host. In other words, the need for dual-headed DNS and the issues pertaining to source and destination address selection would be the same if the host had two global addresses instead of a site-local and a global. This is a network design issue. > - the use of site-local and split-DNS FORCES you to let the > boundaries of the site follow the boundaries of your security > perimeter, or suffer the N*2 problem of having to manage four > categories of names rather than two Probably. It appears though that postings by different people seem to converge about the idea that the boundaries of the site (as in site-local) match the administrative boundaries of the organization. There is an issue with semantics but not with the concept itself. > (btw, IMNSHO, the security argument for split DNS is security > through obscurity - it only protects you against the stupid > bad guys....) True enough, although it is better to protect against the stupid bad guys than not to; and the wide spread of IPv4 dual-headed DNS today that has nothing to do with site-locals is likely a good prediction of the spread of IPv6 dual-headed DNS for the same reason. This is the same issue with site-locals themselves: A little reality check shows that they will be used no matter what. Which brings me to the point I was trying to make in the first place: People that will use site-locals for the "security-by-not-routable-addresses" will already have dual-headed DNS for the "security-by-obscurity", no extra work here. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 14:14:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABMEnkd012010; Mon, 11 Nov 2002 14:14:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABMEnIF012007; Mon, 11 Nov 2002 14:14:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABMEjkd011996 for ; Mon, 11 Nov 2002 14:14:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABMErbB003150 for ; Mon, 11 Nov 2002 14:14:54 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15326 for ; Mon, 11 Nov 2002 15:14:48 -0700 (MST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 11 Nov 2002 14:14:46 -0800 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Nov 2002 14:14:45 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 11 Nov 2002 14:14:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: MIPv6 and site local addresses Date: Mon, 11 Nov 2002 14:14:47 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv6 and site local addresses thread-index: AcKJwVrFEASlki95RJKFHcIqV2E+MwACzihQ From: "Richard Draves" To: "Thomas Narten" , "Hesham Soliman (EAB)" Cc: X-OriginalArrivalTime: 11 Nov 2002 22:14:50.0696 (UTC) FILETIME=[C0E05C80:01C289CF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gABMEjkd011997 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I take it that the implication here is that all MNs need to > be multi-sited and support the site scoping document (or > equivalent). In other words, it will need to be widely > supported in practice. > > Is this really the implication? There is a hope/expectation > that very many nodes will implement MIPv6. It would be nice > of MNs wouldn't be required to implement the scoping document > in order to make things work. If a mobile node wants to have a site-local home address in addition to a global home address, then it needs to be multi-sited with all that entails. If it just wants to support global home addresses, then that's not necessary. Let me mention scoped care-of addresses. At least in our implementation, care-of address selection is governed by the normal address selection rules for choosing a source address for the correspondent (destination) address. The home agent's address should be global. So you should choose a global care-of address to register with the home agent. >From Hesham: > => I'm not sure this solves the problem though. It all > depends on where the SL address came from. Is it in the > visited site or the home site? I don't think I understand the problem to which you are referring. I think the best way to conceptualize this is, the MIPv6 virtual interface (which has the home address) is just like a VPN back to the home site. So the multi-site issues are the same as for any multi-sited host. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 14:21:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABMLAkd012322; Mon, 11 Nov 2002 14:21:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABML9R5012321; Mon, 11 Nov 2002 14:21: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABML6kd012314 for ; Mon, 11 Nov 2002 14:21:06 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABMLGMq003102 for ; Mon, 11 Nov 2002 14:21:16 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24970 for ; Mon, 11 Nov 2002 14:21:10 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.41]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA03227; Mon, 11 Nov 2002 14:20:49 -0800 (PST) Message-Id: <5.1.0.14.2.20021111172051.02a83030@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Nov 2002 17:22:28 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Naming and site-local addresses Cc: "Harald Tveit Alvestrand" , In-Reply-To: <2B81403386729140A3A899A8B39B046405E444@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Michel, >Probably. It appears though that postings by different people seem to >converge about the idea that the boundaries of the site (as in >site-local) match the administrative boundaries of the organization. >There is an issue with semantics but not with the concept itself. I don't think, though, that security boundaries and administrative boundaries always coincide. Don't some sites have a DMZ where they put outward-facing servers that is actually outside their main security boundary? So, would you put that DMZ outside the site, routing area and "two-faced" DNS boundaries, as well? 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 Nov 11 14:25:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABMPZkd012447; Mon, 11 Nov 2002 14:25:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABMPYPR012446; Mon, 11 Nov 2002 14:25: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABMPVkd012439 for ; Mon, 11 Nov 2002 14:25:31 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABMPebB006295 for ; Mon, 11 Nov 2002 14:25:40 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04997 for ; Mon, 11 Nov 2002 14:25:34 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gABMPVl21600; Mon, 11 Nov 2002 17:25:31 -0500 (EST) Message-Id: <200211112225.gABMPVl21600@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tim Chown cc: ipng@sunroof.eng.sun.com Subject: Re: Naming and site-local addresses In-reply-to: (Your message of "Mon, 11 Nov 2002 08:32:12 GMT.") <20021111083212.GD23167@login.ecs.soton.ac.uk> Date: Mon, 11 Nov 2002 17:25:31 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I agree with Keith that the logical conclusion is that whenever a site-local > and global address are returned the only non-ambiguous decision to take is > to prefer the global address. But that means we lose the nice property of > prefering site-locals intra-site to help maintain long-standing connections > (e.g. NFS) through external renumbering or connectivity events that alter > global prefixes seen within the site. > > It seems the only way around that is to either use a special unique > "site-local global" prefix internally (plucked from some method as yet > undefined, Keith's ideas to date there are "woolly" at best :) or to use a > parallel/split DNS naming structure internally (be it foo.site or otherwise, > indeed in my own NATed v4 home network I use .home in the scope of my home > network for that purpose on Net10, not pretty but it works), or to use only > site-local literals. Are there other solutions? I actually think that all applications that expect to keep associations around more than some well-known (and explicitly chosen) lifetime need to have mechanisms for surviving renumbering. And unless/until we introduce renumbering support into TCP, UDP, and SCTP, this means providing that support in layer 7. I also think there needs to be a minimum overlap time during renumbering (during which both prefixes are valid), which is greater than or equal to the max reliable association lifetime above. That way, if an application gets a valid prefix when it starts, that prefix will remain valid for at least the max reliable association lifetime. In other words, I'd rather make a distinction between applications with long associations and applications which don't need long associations than between site-local applications and applications that might need to cross site boundaries. In practice I don't think there are many inherently site-local applications. Keith p.s. offhand I suggest that that lifetime should be 10 days. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 14:35:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABMZ4kd012655; Mon, 11 Nov 2002 14:35:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABMZ3QT012654; Mon, 11 Nov 2002 14:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABMYwkd012647 for ; Mon, 11 Nov 2002 14:34:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABMZ7Mq007120 for ; Mon, 11 Nov 2002 14:35:07 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04805 for ; Mon, 11 Nov 2002 15:34:59 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 136366A90E; Tue, 12 Nov 2002 00:34:50 +0200 (EET) Message-ID: <3DD03071.9090405@piuha.net> Date: Tue, 12 Nov 2002 00:34:25 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Perkins Cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and site local addresses References: <200211112034.gABKYZo31374@rotala.raleigh.ibm.com> <3DD019AB.828FC0AF@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 Charlie Perkins wrote: > I guess the Mobile IPv6 specification is not supposed to cover > cases where the mobile node is not using Mobile IPv6. Then, > if a mobile node wants to use visited site-local addresses for > communication within the visited site, that should be O.K. > > If the mobile node IS using Mobile IPv6 with a global care-of > address, then ...? should it use that global care-of address for > other communications (e.g., very short term) for which the > home address is not involved? The issue was simultaneous use of site-local addresses both at the home site and at the visited site. I think the problem is that when we see a site local address in the stack and expect to do, say, a TCP connect to it, we don't know where that address came from. If it came from home-site DNS then we should somehow get to the home site. If it came from visited network http link, then we should use it locally. I don't think solving the problem by picking the right source address is quite enough. This is because we may not have enough information to do this selection. On the other hand the problem also appears more general than just MIPv6 specific, because other types of tunnels have similar problems. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 14:51:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABMpdkd013530; Mon, 11 Nov 2002 14:51:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABMpckD013529; Mon, 11 Nov 2002 14:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABMpZkd013519 for ; Mon, 11 Nov 2002 14:51:35 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABMpibB014650 for ; Mon, 11 Nov 2002 14:51:44 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16353 for ; Mon, 11 Nov 2002 14:51:38 -0800 (PST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gABMpYQ1021951; Mon, 11 Nov 2002 23:51:34 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 11 Nov 2002 23:51:34 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0CE0@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Richard Draves'" , Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: RE: MIPv6 and site local addresses Date: Mon, 11 Nov 2002 23:51:32 +0100 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 > From Hesham: > > => I'm not sure this solves the problem though. It all > > depends on where the SL address came from. Is it in the > > visited site or the home site? > > I don't think I understand the problem to which you are referring. > > I think the best way to conceptualize this is, the MIPv6 virtual > interface (which has the home address) is just like a VPN > back to the > home site. So the multi-site issues are the same as for any > multi-sited > host. => I agree with this. My comment was essentially that the applications will need to indicate which site they should communicate to. Therefore, they would need to know if the SL address belong to the "home" site or the visited site. Nothing new is needed though as you mention above, I inconveniently didn't consider the API extensions for scoped addresses :( 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 Mon Nov 11 14:52:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABMqMkd013572; Mon, 11 Nov 2002 14:52:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABMqMQ1013570; Mon, 11 Nov 2002 14:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABMqHkd013560 for ; Mon, 11 Nov 2002 14:52:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABMqQbB014860 for ; Mon, 11 Nov 2002 14:52:26 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07528 for ; Mon, 11 Nov 2002 15:52:20 -0700 (MST) Subject: RE: Naming and site-local addresses MIME-Version: 1.0 Date: Mon, 11 Nov 2002 14:52:51 -0800 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E445@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Naming and site-local addresses Thread-Index: AcKJ0Mah6u4syzwHTQa3EzdwoMksyQAAB6Fg From: "Michel Py" To: "Margaret Wasserman" Cc: "Harald Tveit Alvestrand" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gABMqHkd013561 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, >> Michel Py wrote: >> It appears though that postings by different >> people seem to converge about the idea that the boundaries >> of the site (as in site-local) match the administrative >> boundaries of the organization. There is an issue with >> semantics but not with the concept itself. > Margaret Wasserman wrote: > Don't some sites have a DMZ where they put outward-facing > servers that is actually outside their main security > boundary? I don't think so, see below. > I don't think, though, that security boundaries and > administrative boundaries always coincide. Most of the time there is no such thing as a single "security boundary" but multiple ones (I have seen six successive DMZs designs). Security is _layered_, and I can't remember any network where one of the security layers would not match the administrative boundary. Most of the time, this would be the outer layer. > So, would you put that DMZ outside the site, routing > area and "two-faced" DNS boundaries, as well? Not typically. The routing area and the security area will likely include the DMZ as well as the site does. It is well understood that DMZ hosts are sitting ducks, but it does not mean they should not be protected by a firewall in order to prevent some attacks such as SYN/ACK and ping of death. Therefore, they are within the security perimeter, on the outside of it obviously. Back to the diagram below, there is a security boundary that matches the site boundary, another one in the outside firewall, another one in the inside firewall, and finally one in router B. -------------------- Global Addresses ------------------><- SL addr -> +-----+ | ISP | | +--+--+ | : : : ! | : : : +--+---------+ +----------+ +----------+ +----------+ | Router A | +--+ Firewall +--+--+ Firewall +--+--+ Router B +---+ +------------+ +----------+ | +----------+ | +----------+ | | : | : | : | | : +---+--+ : +--+---+ : +----+----+ | : | DMZ | : | Host | : | Control | | : | Host | : +------+ : | Device | | : +------+ : : +---------+ ---Site -->|<-------------------------- Site -------------------------> | : : : | A good security policy splits the administration of the different layers because then one single person sleeping with the enemy can not compromise the entire network. In the diagram above, if the administrator responsible for router B wants to configure a tunnel in router B in order to leak the site-locals, the tunneling protocol would be blocked in the firewalls. Also, if the firewall administrator opens a hole in the firewalls to get to the control devices, he can't because he needs to reconfigure router B also. Hope this helps, Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 15:47:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABNlrkd015046; Mon, 11 Nov 2002 15:47:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABNlrxZ015045; Mon, 11 Nov 2002 15:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABNlgkd015038 for ; Mon, 11 Nov 2002 15:47:50 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABNlpbB001048 for ; Mon, 11 Nov 2002 15:47:51 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29438 for ; Mon, 11 Nov 2002 15:47:46 -0800 (PST) Subject: RE: Address allocation schemes (Re: Naming and site-local) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 11 Nov 2002 15:48:17 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E447@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Address allocation schemes (Re: Naming and site-local) Thread-Index: AcKJUl58LDRh0jo5TR2o5IMiuw5m5wAiV3kQ 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 gABNlokd015039 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Harald Tveit Alvestrand wrote: > metro addressing? You can have a quick look at this, WIP. http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt > btw, my current naive prediction of the way the > Internet will evolve is that unless new invention > occurs, the default-free zone will eventually be > flat-routing on the number of ISPs in the world, > and that this number will have 5 digits. What would be the difference between this and the good old "8K DFZ", except one more digit and that ISPs could get a block matching their size instead of what used to be called a TLA? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 15:57:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABNv9kd015139; Mon, 11 Nov 2002 15:57:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gABNv8JW015138; Mon, 11 Nov 2002 15:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gABNv5kd015131 for ; Mon, 11 Nov 2002 15:57:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gABNvEbB003797 for ; Mon, 11 Nov 2002 15:57:14 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01771 for ; Mon, 11 Nov 2002 16:57:09 -0700 (MST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 11 Nov 2002 15:56:53 -0800 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Nov 2002 15:57:02 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 11 Nov 2002 15:57:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: MIPv6 and site local addresses Date: Mon, 11 Nov 2002 15:57:07 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv6 and site local addresses thread-index: AcKJ0yC+dCzmbr7JQ7CtGJw+dCYZpAACraeQ From: "Richard Draves" To: Cc: X-OriginalArrivalTime: 11 Nov 2002 23:57:03.0226 (UTC) FILETIME=[08262DA0:01C289DE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gABNv6kd015132 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The issue was simultaneous use of site-local addresses both > at the home site and at the visited site. I think the problem > is that when we see a site local address in the stack and > expect to do, say, a TCP connect to it, we don't know where > that address came from. The scope id will tell you what site the address belongs to, in other words, which of your interfaces you can use to reach the address. Yes, this is a multi-sited issue, not specific to MIPv6. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 16:37:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC0bQkd015705; Mon, 11 Nov 2002 16:37:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC0bQsI015704; Mon, 11 Nov 2002 16:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC0bMkd015697 for ; Mon, 11 Nov 2002 16:37:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC0bVMq012420 for ; Mon, 11 Nov 2002 16:37:31 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00624 for ; Mon, 11 Nov 2002 17:37:25 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAC0bEl26019; Mon, 11 Nov 2002 19:37:14 -0500 (EST) Message-Id: <200211120037.gAC0bEl26019@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: jari.arkko@piuha.net cc: Charlie Perkins , Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and site local addresses In-reply-to: (Your message of "Tue, 12 Nov 2002 00:34:25 +0200.") <3DD03071.9090405@piuha.net> Date: Mon, 11 Nov 2002 19:37:14 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think the problem > is that when we see a site local address in the stack and > expect to do, say, a TCP connect to it, we don't know where > that address came from. If it came from home-site DNS then > we should somehow get to the home site. If it came from visited > network http link, then we should use it locally. I don't > think solving the problem by picking the right source address > is quite enough. This is because we may not have enough > information to do this selection. On the other hand the problem > also appears more general than just MIPv6 specific, because > other types of tunnels have similar problems. indeed, it's much the same problem regardless of whether you're triyng to 'connect' via a MIPv6 tunnel, another kind of tunnel, or some layer 7 protocol that uses IP addresses as endpoint identifiers. in all of these cases the fact that SLs are ambiguous makes them very difficult to use. 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 Nov 11 16:38:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC0c3kd015724; Mon, 11 Nov 2002 16:38:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC0c37N015723; Mon, 11 Nov 2002 16:38:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC0bxkd015709 for ; Mon, 11 Nov 2002 16:37:59 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC0c8bB014793 for ; Mon, 11 Nov 2002 16:38:08 -0800 (PST) Received: from mail.nosense.org (234.cust2.nsw.dsl.ozemail.com.au [203.103.157.234]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24554 for ; Mon, 11 Nov 2002 16:38:02 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 9DDA23B367; Tue, 12 Nov 2002 11:38:00 +1100 (EST) Subject: Re: Naming and site-local addresses From: Mark Smith To: Keith Moore Cc: Tim Chown , ipng@sunroof.eng.sun.com In-Reply-To: <200211112225.gABMPVl21600@astro.cs.utk.edu> References: <200211112225.gABMPVl21600@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 12 Nov 2002 11:38:00 +1100 Message-Id: <1037061481.10423.80.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, On Tue, 2002-11-12 at 09:25, Keith Moore wrote: > I actually think that all applications that expect to keep associations > around more than some well-known (and explicitly chosen) lifetime need > to have mechanisms for surviving renumbering. And unless/until > we introduce renumbering support into TCP, UDP, and SCTP, this means > providing that support in layer 7. > Isn't this really the End-to-End argument, which I think pretty much summarises to "if you want something done properly, you've got to do it yourself". We are focusing on renumbering being an event that will disrupt TCP sessions, which obviously it will. But what about the interface failing that the operating system chose to use as the local end-point IP address for the TCP session ? Renumbering is a planned, managed and controlled event, interface failures obviously isn't. If the operating system makes an unfortunate choice of source IP address, by using an interface that is going to fail in the near future, the application's TCP sessions will fail. If that is unacceptable to the application, the application has the most interest in implementing mechanisms to reduce or avoid the impact of that failure. Are we trying to solve a problem at the network layer, which impacts the transport layer, which really is best and most appropriately solved at the application layer ? In the context of the End-to-End argument, could TCP/SCTP be seen to be a performance enhancement for the application, rather than trying to provide "perfect" reliability ? Should it really be "dumb network, smart hosts, wise applications" ? Regards, 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 17:07:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC17ukd016174; Mon, 11 Nov 2002 17:07:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC17u3s016173; Mon, 11 Nov 2002 17:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC17qkd016166 for ; Mon, 11 Nov 2002 17:07:52 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC17uMq021079 for ; Mon, 11 Nov 2002 17:07:56 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA18977 for ; Mon, 11 Nov 2002 18:07:50 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAC17el26109; Mon, 11 Nov 2002 20:07:41 -0500 (EST) Message-Id: <200211120107.gAC17el26109@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Smith cc: Keith Moore , Tim Chown , ipng@sunroof.eng.sun.com Subject: Re: Naming and site-local addresses In-reply-to: (Your message of "12 Nov 2002 11:38:00 +1100.") <1037061481.10423.80.camel@dupy> Date: Mon, 11 Nov 2002 20:07:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I actually think that all applications that expect to keep associations > > around more than some well-known (and explicitly chosen) lifetime need > > to have mechanisms for surviving renumbering. And unless/until > > we introduce renumbering support into TCP, UDP, and SCTP, this means > > providing that support in layer 7. > > > > Isn't this really the End-to-End argument, which I think pretty much > summarises to "if you want something done properly, you've got to do it > yourself". There is a similarity between my argument about association liftimes and the end-to-end argument, but I think you're mis-characterizing both of those arguments :) I see the end-to-end argument as being about separation of function. Let the network do what it can do best, but don't try to make it do things (like provide reliable and in-order delivery of messages between hosts) that it can never do well. A similar but less-often-stated argument can be applied to hosts: let hosts do what they can do well (like ordering messages and recovering from dropped messages), but don't try to make them do things (like routing) that they can never do well. It doesn't scale to expect the network to keep track of every connection between hosts. Neither does it scale to expect all hosts to maintain enough information to let them do routing. My argument about association lifetimes is also a separation-of-function argument. The idea here is that it's perfectly reasonable to expect the network to maintain addresses for some well-chosen period of time; applications that don't need addresses to be stable for longer than that shouldn't have to worry about renumbering. On the other hand it's clearly unreasonable to expect the network to make addresses stable indefinitely - first because it's too much overhead and second because there are too many other factors that would cause associations to break anyway. But by providing a certain level of address-to-host binding stability, most applications would be spared the complexity and security risks (etc.) of recovering from renumberings. > We are focusing on renumbering being an event that will disrupt TCP > sessions, which obviously it will. But what about the interface failing > that the operating system chose to use as the local end-point IP address > for the TCP session ? Well that gets back to the 'other factors' that I mentioned above. one of the things that should inform the choice of that max reliable lifetime constant is a survey of other sources of failure and an estimate of how likely they are to fail within that chosen lifetime. However regardless of whether we pick a max reliable address lifetime constant or not OS designers and users clearly want to their systems to avoid picking an interface that is likely to fail. For instance, this argues for things like not having multiple interfaces configured to talk to large networks. (isn't it interesting how adding multiple interfaces can degrade reliability?) (there are other ways to solve that problem also. if interface A goes down, have B register A's address with A's home agent via mobile IP) > Are we trying to solve a problem at the network layer, which impacts the > transport layer, which really is best and most appropriately solved at > the application layer ? The overhead of recovering from renumbering is close to requiring each application to implement TCP at layer 7. (for instance, if a connection fails due to an address change, and you don't get a clean close, the app has no idea whether the data it has sent to its peer really got there. So the app needs explicit acks and to explicitly buffer all un-ack'd data in case it needs to retransmit). Do you really think that it is is optimal to burden all apps with this? > In the context of the End-to-End argument, could TCP/SCTP be seen to be > a performance enhancement for the application, rather than trying to > provide "perfect" reliability ? > > Should it really be "dumb network, smart hosts, wise applications" ? Why not have each layer doing its job without trying to outsmart the others? Keith p.s. another option would be to create extensions to TCP and UDP and SCTP to securely handle renumbering. I don't claim that this isn't doable, and it might even be the best solution overall. But offhand it looks like a fair amount of hair, and IMHO it would be an even more drastic departure from the current architecture than trying to get the network to provide some assurance of address stability. (the latter requires few protocol changes and mostly affects operations) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 17:49:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC1nIkd016712; Mon, 11 Nov 2002 17:49:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC1nIe2016711; Mon, 11 Nov 2002 17:49: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC1nEkd016704 for ; Mon, 11 Nov 2002 17:49:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC1nNbB003108 for ; Mon, 11 Nov 2002 17:49:23 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06919 for ; Mon, 11 Nov 2002 18:49:16 -0700 (MST) 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 RAA13044 for ; Mon, 11 Nov 2002 17:48:58 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAC1mvL05817 for ; Mon, 11 Nov 2002 17:48:57 -0800 X-mProtect: <200211120148> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhkarcj; Mon, 11 Nov 2002 17:48:54 PST Message-ID: <3DD05F1A.40109@iprg.nokia.com> Date: Mon, 11 Nov 2002 17:53:30 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: New mailing list for MTU discussions Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI, This seems relevant to IPNG interests also (cross-posting from v6ops/ngtrans): Fred Templin ftemplin@iprg.nokia.com Fred L. Templin wrote: > FYI, > > Below is a message from Matt Mathis (fwd'd with his permission) announcing > a new mailing list for MTU discussions. Matt has also posted an interesting > new document titled: "Path MSS Discovery". See: > > http://www.psc.edu/~mathis/MTU/draft-mathis-MSS-discovery.txt > > Fred Templin > ftemplin@iprg.nokia.com > > > Date: Thu, 7 Nov 2002 15:49:05 -0500 (EST) > > From: Matt Mathis > > Subject: Please subscribe to a new MTU mailling list (fwd) > > Message-ID: > > MIME-Version: 1.0 > > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Content-Length: 666 > > > > For all *technical* and *public policy* issues pertaining to pushing > up the > > Internet MTU. This is an open list, so please be careful. You > must be > > subscribed to post. > > > > See http://www.psc.edu/~mathis/MTU for more information > > > > If you are interested, please subscribe YOURSELF by sending a note to > > majordomo@psc.edu with: > > subscribe mtu > > or > > subscribe mtu > > in the body. Please forward this message to anybody else who may be > > interested. > > > > Thanks, > > --MM-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 18:28:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC2SUkd017600; Mon, 11 Nov 2002 18:28:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC2SU74017599; Mon, 11 Nov 2002 18:28:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC2SQkd017592 for ; Mon, 11 Nov 2002 18:28:26 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC2SYbB012406 for ; Mon, 11 Nov 2002 18:28:34 -0800 (PST) Received: from starfruit.itojun.org (fbca.west.iij-america.com [216.98.98.238]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09131 for ; Mon, 11 Nov 2002 18:28:29 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 8C4BF7AF; Tue, 12 Nov 2002 11:28:15 +0900 (JST) To: "Richard Draves" Cc: jari.arkko@piuha.net, ipng@sunroof.eng.sun.com In-reply-to: richdr's message of Mon, 11 Nov 2002 15:57:07 PST. 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: MIPv6 and site local addresses From: Jun-ichiro itojun Hagino Date: Tue, 12 Nov 2002 11:28:15 +0900 Message-Id: <20021112022815.8C4BF7AF@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> The issue was simultaneous use of site-local addresses both >> at the home site and at the visited site. I think the problem >> is that when we see a site local address in the stack and >> expect to do, say, a TCP connect to it, we don't know where >> that address came from. >The scope id will tell you what site the address belongs to, in other >words, which of your interfaces you can use to reach the address. Yes, >this is a multi-sited issue, not specific to MIPv6. in mobile-ip case, mobile node would receive packets with site-local address on the same interface for both cases. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 19:03:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC33okd017792; Mon, 11 Nov 2002 19:03:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC33one017791; Mon, 11 Nov 2002 19:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC33kkd017784 for ; Mon, 11 Nov 2002 19:03:47 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC33tbB018910 for ; Mon, 11 Nov 2002 19:03:55 -0800 (PST) Received: from mail.nosense.org (234.cust2.nsw.dsl.ozemail.com.au [203.103.157.234]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA01291 for ; Mon, 11 Nov 2002 20:03:48 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 5C6803B367; Tue, 12 Nov 2002 14:03:43 +1100 (EST) Subject: Re: Naming and site-local addresses From: Mark Smith To: Keith Moore Cc: Tim Chown , ipng@sunroof.eng.sun.com In-Reply-To: <200211120107.gAC17el26109@astro.cs.utk.edu> References: <200211120107.gAC17el26109@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 12 Nov 2002 14:03:43 +1100 Message-Id: <1037070223.10423.155.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2002-11-12 at 12:07, Keith Moore wrote: > > > Are we trying to solve a problem at the network layer, which impacts the > > transport layer, which really is best and most appropriately solved at > > the application layer ? > > The overhead of recovering from renumbering is close to requiring each > application to implement TCP at layer 7. (for instance, if a connection > fails due to an address change, and you don't get a clean close, the app > has no idea whether the data it has sent to its peer really got there. > So the app needs explicit acks and to explicitly buffer all un-ack'd > data in case it needs to retransmit). > That's a good point, one I had overlooked. > Do you really think that it is is optimal to burden all apps with this? > No I don't, although I'm probably only suggesting that applications that don't want to be impacted by a TCP session failure (caused by renumbering, interface failure etc) do need to implement this in some way. All the rest of the applications that don't have such a high availability requirement should be able to accept very occasional TCP failures due to renumbering events, interface failures etc, as long as they didn't occur very regularly, which is and would be the case. > > In the context of the End-to-End argument, could TCP/SCTP be seen to be > > a performance enhancement for the application, rather than trying to > > provide "perfect" reliability ? > > > > Should it really be "dumb network, smart hosts, wise applications" ? > I suppose what I'm really trying saying here is that for most applications, the "dumb network, smart hosts" is enough. On the other hand, for the smaller number of very high availability applications, the smart hosts are smart enough nearly all the time, though not quite enough to be acceptable. In that case, an application will need take some ownership of the reliability it requires. A "wise application" (or rather developer) would weigh up its reliability and availability requirements, and if TCP can't deliver them, due to occasional interface failures, or occasional renumbering events, then it will have to take measures of its own - with the associated costs of implementing basic reliability mechanisms. Hmm, even I thought it was just re-implementing TCP when writing the last paragraph. Do any mission critical applications today use TCP (retorical question)? If so, how do they cope with interface failure tearing down TCP sessions, other than just failing.There are ways of using networking tricks like virtual interfaces inside a host etc to increase interface and therefore IP address availability, but are there applications out there today that take ownership of some level of their own reliability requirements ? > Why not have each layer doing its job without trying to outsmart the others? True. The issue we seem to be having is that by moving from pseudo-permanent addressing to semi-dynamic addressing, we are reducing or taking away one of the properties TCP has relied on. site-locals addressing is trying to restore that property, but the consequential complexity to many other areas (DNS, routers, security etc) scares people. Accepting that TCP sessions aren't going to live as long as they used to when using global addressing, and giving the applications that have such high TCP availability requirements some of that responsibility may be a way of moving forward. However, I can't see a typical organisation changing its global prefix more than once every thirty days. If you do, maybe Mobile IPv6 is the thing for you (I could be speaking out of turn here, I don't know much about Mobile IPv6). If you are running mission critical applications that require very long lived TCP connections you are far more conservative in making network infrastructure changes, addressing being one of them. You probably only review your ISP contracts once every 12 months, and make it a contractual decision that your globally assigned prefix will not change during that period. If you wish to change ISPs, one of the associated costs is mission critical down time, which you would weigh into the costs-benefit of changing ISPs. 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 11 20:57:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC4vqkd018318; Mon, 11 Nov 2002 20:57:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC4vqRM018317; Mon, 11 Nov 2002 20:57:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC4vmkd018310 for ; Mon, 11 Nov 2002 20:57:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC4vvbB004614 for ; Mon, 11 Nov 2002 20:57:57 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08150 for ; Mon, 11 Nov 2002 21:57:51 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAC4vfl26784; Mon, 11 Nov 2002 23:57:41 -0500 (EST) Message-Id: <200211120457.gAC4vfl26784@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Smith cc: Keith Moore , Tim Chown , ipng@sunroof.eng.sun.com Subject: Re: Naming and site-local addresses In-reply-to: (Your message of "12 Nov 2002 14:03:43 +1100.") <1037070223.10423.155.camel@dupy> Date: Mon, 11 Nov 2002 23:57:41 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Do any mission critical applications today use TCP (retorical question)? > If so, how do they cope with interface failure tearing down TCP > sessions, other than just failing. well, it depends on the application. for instance, SMTP can just detect that the connection was broken and retry sending the entire message. but SMTP by its very nature buffers messages and has explicit acks, so having SMTP cope with interface failures requires little or no extra effort. for that matter, most SMTP sessions are fairly brief. apps that use only brief connections won't experience many errors due to interface failures. other sources of failure are often more significant. interactive apps cope with interface failures quite naturally by allowing the human user to retry the operation when it fails. 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 Nov 11 21:17:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC5HSkd018456; Mon, 11 Nov 2002 21:17:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC5HSsq018455; Mon, 11 Nov 2002 21:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC5HKkd018448 for ; Mon, 11 Nov 2002 21:17:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC5HUMq008496 for ; Mon, 11 Nov 2002 21:17:30 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA18551 for ; Mon, 11 Nov 2002 22:17:24 -0700 (MST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gAC5HNGE009186 for ; Mon, 11 Nov 2002 22:17:24 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id WAA22971 for ; Mon, 11 Nov 2002 22:17:22 -0700 (MST)] Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gAC5HK7C020672 for ; Tue, 12 Nov 2002 16:17:20 +1100 (EST) Message-ID: <3DD08EE0.C0B2C504@motorola.com> Date: Tue, 12 Nov 2002 16:17:20 +1100 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: Naming and site-local addresses References: <5.1.0.14.2.20021111163240.02a6e330@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > If a site-border node sends a DNS request and receives a site-local > address in return, how does it know in which of its attached sites > the site-local adddress is valid? Some people have stated that it > can use the zone ID of the interface on which the DNS response is > returned, but I think that this would only work if the "two faced" > DNS server is topologically located inside the site. Is that a > reasonable restriction? As far as I can see, the safe way to do "two-faced" DNS with site locals is to make the site-scoped DNS itself be addressable only by a site-scoped address. Otherwise, you breach the principle that a site local address MUST NOT exist outside the site. >From this, it follows that the DNS is topologically located inside the site. -- 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 Nov 11 21:31:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC5V0kd018605; Mon, 11 Nov 2002 21:31:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC5Uxbb018602; Mon, 11 Nov 2002 21:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC5Ukkd018594 for ; Mon, 11 Nov 2002 21:30:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC5UtMq010206 for ; Mon, 11 Nov 2002 21:30:55 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19422 for ; Mon, 11 Nov 2002 22:30:49 -0700 (MST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gAC5Um0j024325 for ; Mon, 11 Nov 2002 22:30:49 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id WAA24280 for ; Mon, 11 Nov 2002 22:26:46 -0700 (MST)] Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gAC5Uj7C022028 for ; Tue, 12 Nov 2002 16:30:45 +1100 (EST) Message-ID: <3DD09205.25C643A@motorola.com> Date: Tue, 12 Nov 2002 16:30:45 +1100 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: Address selection and site local addresses References: <200211120457.gAC4vfl26784@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Was: Re: Naming and site-local addresses Keith Moore wrote: > > > If so, how do they cope with interface failure tearing down TCP > > sessions, other than just failing. > > well, it depends on the application. for instance, SMTP can just > detect that the connection was broken and retry sending the entire > message. but SMTP by its very nature buffers messages and has > explicit acks, so having SMTP cope with interface failures > requires little or no extra effort. > > for that matter, most SMTP sessions are fairly brief. apps that > use only brief connections won't experience many errors due to > interface failures. other sources of failure are often more > significant. Again we consider the problem of address selection for long-running apps... Here are three models for address selection when both site-local and global addresses are available. Which (if any) is preferred: * Leave it up to application, but recommend preferring global addresses: Pros: Pick the address with global scope. Cons: If we are using site-locals because global addresses are unreliable, then we are picking the less robust address. * Leave it up to application, but recommend preferring local addresses: Pros: Site local addresses may persist where global addresses come and go. Cons: Default selection is not globally scoped. * Provide addresses to application 'in order', defaulting to global first. Networks that consider their global addresses 'transient' may change priorities to favour site local addresses. Pros: Doesn't require smart applications, but applications can override if they want. Cons: Need mechanism to propagate address selection preferences to hosts. Note that short-running apps (say 10 minutes or less, to pull a number out of the air) don't really care which address they use as long as it is valid, which means these apps can reasonably prefer globals in multi-homed situations (as long as the address is still within it's 'preferred' lifetime. Though there is the problem of how long to cache an address for. -- 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 Nov 11 23:36:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC7aOkd019438; Mon, 11 Nov 2002 23:36:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC7aOMQ019437; Mon, 11 Nov 2002 23:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC7aLkd019430 for ; Mon, 11 Nov 2002 23:36:21 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC7aUMq027908 for ; Mon, 11 Nov 2002 23:36:30 -0800 (PST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04523 for ; Mon, 11 Nov 2002 23:36:24 -0800 (PST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A2D862206; Tue, 12 Nov 2002 08:36:19 +0100 (CET) Date: Tue, 12 Nov 2002 08:36:19 +0100 From: Harald Tveit Alvestrand To: Michel Py , ipng@sunroof.eng.sun.com Subject: RE: Address allocation schemes (Re: Naming and site-local) Message-ID: <2830000.1037086579@askvoll.hjemme.alvestrand.no> In-Reply-To: <2B81403386729140A3A899A8B39B046405E447@server2000> References: <2B81403386729140A3A899A8B39B046405E447@server2000> 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 mandag, november 11, 2002 15:48:17 -0800 Michel Py wrote: >> Harald Tveit Alvestrand wrote: >> metro addressing? > > You can have a quick look at this, WIP. > http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt hey - if Bergen gets a /32, Trondheim should get one too :-) but this really belongs on multi6, I think. >> btw, my current naive prediction of the way the >> Internet will evolve is that unless new invention >> occurs, the default-free zone will eventually be >> flat-routing on the number of ISPs in the world, >> and that this number will have 5 digits. > > What would be the difference between this and the good old "8K DFZ", > except one more digit and that ISPs could get a block matching their > size instead of what used to be called a TLA? Apart from not having any administratively fixed boundaries, I haven't seen any need for a difference until someone comes along with a genuinely better idea. but as I said, I am naive in those matters. 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 Tue Nov 12 00:49:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC8nOkd020008; Tue, 12 Nov 2002 00:49:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC8nOV1020007; Tue, 12 Nov 2002 00:49: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC8nLkd020000 for ; Tue, 12 Nov 2002 00:49:21 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC8nUMq012766 for ; Tue, 12 Nov 2002 00:49:30 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA04569 for ; Tue, 12 Nov 2002 00:49:24 -0800 (PST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA00435 for ; Tue, 12 Nov 2002 08:49:23 GMT Received: from starling.ecs.soton.ac.uk (starling.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAC8n7WX006158 for ; Tue, 12 Nov 2002 08:49:07 GMT Received: (from tjc@localhost) by starling.ecs.soton.ac.uk (8.11.6/8.11.6) id gAC8n7r17246 for ipng@sunroof.eng.sun.com; Tue, 12 Nov 2002 08:49:07 GMT Date: Tue, 12 Nov 2002 08:49:07 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Naming and site-local addresses Message-ID: <20021112084907.GE17211@starling.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <200211120107.gAC17el26109@astro.cs.utk.edu> <1037070223.10423.155.camel@dupy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1037070223.10423.155.camel@dupy> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Nov 12, 2002 at 02:03:43PM +1100, Mark Smith wrote: > > However, I can't see a typical organisation changing its global prefix > more than once every thirty days. If you do, maybe Mobile IPv6 is the > thing for you (I could be speaking out of turn here, I don't know much > about Mobile IPv6). > > If you are running mission critical applications that require very long > lived TCP connections you are far more conservative in making network > infrastructure changes, addressing being one of them. You probably only > review your ISP contracts once every 12 months, and make it a > contractual decision that your globally assigned prefix will not change > during that period. If you wish to change ISPs, one of the associated > costs is mission critical down time, which you would weigh into the > costs-benefit of changing ISPs. I think this is one aspect of the problem, that it's hard to predict what the renumbering requirements will be. I recall this was one of the reasons back last summer that A6 bit the dust, that the requirements, and likely future frequency of, renumbering wasn't yet understood. I agree at present for many organisations it's an annual price review issue. Note though that site-locals are not just about avoiding pain in renumbering, the same arguments apply for intermittent connectivity, or sites who connect and receive a different prefix each time, e.g. if future IPv6 DSL providers allocate dynamic /48's in the way that dynamic IPv4 addresses are allocated now. That might be a daily event. 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 Nov 12 00:53:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC8r5kd020084; Tue, 12 Nov 2002 00:53:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC8r5mB020083; Tue, 12 Nov 2002 00:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC8r2kd020073 for ; Tue, 12 Nov 2002 00:53:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC8rBMq013336 for ; Tue, 12 Nov 2002 00:53:11 -0800 (PST) Received: from laptop2.kurtis.pp.se (tlp1.cobweb.autonomica.se [130.244.10.138]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06519 for ; Tue, 12 Nov 2002 00:53:05 -0800 (PST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gAC8rRwc018264; Tue, 12 Nov 2002 09:53:28 +0100 (CET) Date: Tue, 12 Nov 2002 09:53:27 +0100 Subject: Re: Naming and site-local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: ipng@sunroof.eng.sun.com To: Harald Tveit Alvestrand From: Kurt Erik Lindqvist In-Reply-To: <2082830000.1036935491@askvoll.hjemme.alvestrand.no> Message-Id: <35A30B36-F61C-11D6-A223-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > - Address lookup is significantly more complex in the presence of > site-local than if only global-scoped addresses are used > > I agree with this conclusion. But I think that site-locals comes with a lot more problems than that. I think it will drag us into the "RFC1918 swamp" of problems we have today with NAT and PT problems for new protocols and applications. Best regards, - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 00:53:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC8rFkd020097; Tue, 12 Nov 2002 00:53:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC8rFsa020096; Tue, 12 Nov 2002 00:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC8rAkd020086 for ; Tue, 12 Nov 2002 00:53:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC8rJbB007619 for ; Tue, 12 Nov 2002 00:53:19 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA01696 for ; Tue, 12 Nov 2002 01:53:11 -0700 (MST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAC8qw5v063932; Tue, 12 Nov 2002 09:53:00 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAC8qt69043822; Tue, 12 Nov 2002 09:52:56 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47714 from ; Tue, 12 Nov 2002 09:52:53 +0100 Message-Id: <3DD0C155.DA18122C@hursley.ibm.com> Date: Tue, 12 Nov 2002 09:52:37 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: David Conrad Cc: IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David Conrad wrote: > > Hi, > > On 11/11/02 9:15 AM, "Harald Tveit Alvestrand" wrote: > > my personal opinion is that the only people who feel any possessive > > instinct towards 2002:d90d:1cca:2:210:dcff:fe5a:f1fd are the people who > > have to reconfigure other stuff when it changes..... > > Or the people who are affected when reconfiguration occurs. > > Welcome to NATv6. It's our job to stop that happening. Also, the vast majority of Internet users are not in the least possessive about their IP address; it's different every time they connect. Those who are possessive are those who run services of one kind or another. It's our job to make that possible without forcing them down the NAThole. 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 Nov 12 01:15:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC9Fdkd020390; Tue, 12 Nov 2002 01:15:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAC9FdgW020389; Tue, 12 Nov 2002 01:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAC9Fakd020382 for ; Tue, 12 Nov 2002 01:15:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAC9FibB010674 for ; Tue, 12 Nov 2002 01:15:45 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA12074 for ; Tue, 12 Nov 2002 02:15:38 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA00697 for ; Tue, 12 Nov 2002 09:15:31 GMT Received: from starling.ecs.soton.ac.uk (starling.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAC9FOWX010717 for ; Tue, 12 Nov 2002 09:15:24 GMT Received: (from tjc@localhost) by starling.ecs.soton.ac.uk (8.11.6/8.11.6) id gAC9FOT17280 for ipng@sunroof.eng.sun.com; Tue, 12 Nov 2002 09:15:24 GMT Date: Tue, 12 Nov 2002 09:15:24 +0000 From: Tim Chown To: IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) Message-ID: <20021112091524.GF17211@starling.ecs.soton.ac.uk> Mail-Followup-To: IPng References: <3DD0C155.DA18122C@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD0C155.DA18122C@hursley.ibm.com> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Nov 12, 2002 at 09:52:37AM +0100, Brian E Carpenter wrote: > David Conrad wrote: > > > > Welcome to NATv6. > > It's our job to stop that happening. > > Also, the vast majority of Internet users are not in the least > possessive about their IP address; it's different every time they > connect. Those who are possessive are those who run services of one > kind or another. It's our job to make that possible without forcing > them down the NAThole. And of course the ones who run services of one kind or another would be in the vast majority in an IPv6 world, rather than the vast minority. I think NATv6 is inevitable, because some site policy makers will demand it. Our "job" is to provide a well-engineered alternative that the market will demand. If enough ISP's provide v6 services the right way, the market demand for those services will mean NATv6 will be naturally stunted in adoption. If ISP X enables me to control and view three IPv6 enabled webcams, a secure home filestore, program my tivo/vcr, monitor home appliances, etc, all in a relatively plug-and-play way, and ISP Y does not, because it uses NATv6, then it's highly likely ISP X will flourish and ISP Y will fail... Likewise ISP's offering static /48's will probably flourish over those that do not (and certainly over those that offer only /64'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 Tue Nov 12 02:43:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACAhikd020832; Tue, 12 Nov 2002 02:43:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACAhh8d020831; Tue, 12 Nov 2002 02:43:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACAhekd020824 for ; Tue, 12 Nov 2002 02:43:40 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACAhnbB021370 for ; Tue, 12 Nov 2002 02:43:49 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27876 for ; Tue, 12 Nov 2002 02:43:44 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id CAA00212; Tue, 12 Nov 2002 02:43:27 -0800 (PST) Message-Id: <5.1.0.14.2.20021112052054.07434b80@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Nov 2002 05:45:17 -0500 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: Address allocation schemes (Re: Naming and site-local) Cc: IPng In-Reply-To: <3DD0C155.DA18122C@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, > > Welcome to NATv6. > >It's our job to stop that happening. I agree, and I actually consider our job to be even bigger than this... We need to create the technologies and policies that will enable a globally-addressable, "flat" IPv6 Internet. We need to understand and document how a flat IPv6 Internet can be deployed in parallel with the existing IPv4 Internet without introducing serious operational or security problems. We need to provide enough education regarding the advantages of a globally-addressable, flat Internet that we can change the way that large numbers of people think about network architecture. Remember there are more Internet administrators who were spawned and trained during a time of widespread NAT use than there are those of us who remember the flat IPv4 Internet. AND, in the meantime, we need to avoid advocating NAT or NAT-like solutions to problems that can be solved without destroying the global-addressability or "flatness" of the IPv6 Internet. >Also, the vast majority of Internet users are not in the least >possessive about their IP address; it's different every time they >connect. Those who are possessive are those who run services of one >kind or another. It's our job to make that possible without forcing >them down the NAThole. I completely agree. But, what I don't understand is how the use of overlapping site-local addresses on globally-attached networks is any better than 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 Tue Nov 12 02:55:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACAtFkd020968; Tue, 12 Nov 2002 02:55:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACAtE9t020967; Tue, 12 Nov 2002 02:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACAtBkd020960 for ; Tue, 12 Nov 2002 02:55:11 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACAtKMq029007 for ; Tue, 12 Nov 2002 02:55:20 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29577 for ; Tue, 12 Nov 2002 03:55:15 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id CAA03854; Tue, 12 Nov 2002 02:54:27 -0800 (PST) Message-Id: <5.1.0.14.2.20021112055424.02a9e080@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Nov 2002 05:55:28 -0500 To: Tim Chown From: Margaret Wasserman Subject: Re: Address allocation schemes (Re: Naming and site-local) Cc: IPng In-Reply-To: <20021112091524.GF17211@starling.ecs.soton.ac.uk> References: <3DD0C155.DA18122C@hursley.ibm.com> <3DD0C155.DA18122C@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 Tim, >Our "job" is to provide a well-engineered alternative that the >market will demand. Excellent point, and well put. 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 Nov 12 03:07:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACB7Zkd021031; Tue, 12 Nov 2002 03:07:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACB7Ybw021030; Tue, 12 Nov 2002 03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACB7Vkd021023 for ; Tue, 12 Nov 2002 03:07:31 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACB7eMq000589 for ; Tue, 12 Nov 2002 03:07:40 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11158 for ; Tue, 12 Nov 2002 03:07:34 -0800 (PST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gACB7Sis005456; Tue, 12 Nov 2002 12:07:30 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gACB7L69071832; Tue, 12 Nov 2002 12:07:21 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA65182 from ; Tue, 12 Nov 2002 12:07:19 +0100 Message-Id: <3DD0E0D7.4E210B84@hursley.ibm.com> Date: Tue, 12 Nov 2002 12:07:03 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Margaret Wasserman Cc: IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) References: <5.1.0.14.2.20021112052054.07434b80@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk below... Margaret Wasserman wrote: > > Hi Brian, > > > > Welcome to NATv6. > > > >It's our job to stop that happening. > > I agree, and I actually consider our job to be even bigger > than this... > > We need to create the technologies and policies that will enable a > globally-addressable, "flat" IPv6 Internet. > > We need to understand and document how a flat IPv6 Internet can be > deployed in parallel with the existing IPv4 Internet without > introducing serious operational or security problems. > > We need to provide enough education regarding the advantages of > a globally-addressable, flat Internet that we can change the way > that large numbers of people think about network architecture. > Remember there are more Internet administrators who were spawned > and trained during a time of widespread NAT use than there are > those of us who remember the flat IPv4 Internet. > > AND, in the meantime, we need to avoid advocating NAT or NAT-like > solutions to problems that can be solved without destroying the > global-addressability or "flatness" of the IPv6 Internet. > > >Also, the vast majority of Internet users are not in the least > >possessive about their IP address; it's different every time they > >connect. Those who are possessive are those who run services of one > >kind or another. It's our job to make that possible without forcing > >them down the NAThole. > > I completely agree. > > But, what I don't understand is how the use of overlapping site-local > addresses on globally-attached networks is any better than NAT. My recollection is that site-local entered the architecture to cover the somewhat theoretical case of a multi-subnet site that for whatever reason wasn't connected, and so didn't have a global prefix. And our problems with SL come from trying to use it outside that limited scenario. If we keep it inside that scenario, it seems easy enough to deal with. So, why not simply deprecate SL for sites that have at least one global prefix? Or am I too simple minded? That would then leave us with a couple of real problems to avoid NAT: multihoming, and easy renumbering. 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 Nov 12 03:22:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACBMUkd021214; Tue, 12 Nov 2002 03:22:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACBMTA8021213; Tue, 12 Nov 2002 03:22:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACBMQkd021206 for ; Tue, 12 Nov 2002 03:22:26 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACBMZMq002515 for ; Tue, 12 Nov 2002 03:22:35 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17465 for ; Tue, 12 Nov 2002 03:22:30 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id DAA12695; Tue, 12 Nov 2002 03:22:14 -0800 (PST) Message-Id: <5.1.0.14.2.20021112061749.02aa43a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Nov 2002 06:23:56 -0500 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: Address allocation schemes (Re: Naming and site-local) Cc: IPng In-Reply-To: <3DD0E0D7.4E210B84@hursley.ibm.com> References: <5.1.0.14.2.20021112052054.07434b80@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 Brian, >So, why not simply deprecate SL for sites that have at least one >global prefix? Or am I too simple minded? If you are too simple minded, then I am right there with you. My making this exact suggestion is what started the 500+ message mail storm two weeks ago that has received so much attention on other lists... >That would then leave us with a couple of real problems to avoid NAT: >multihoming, and easy renumbering. Yes, exactly. And, it may be easier to determine ways to solve these problems in a flat address space than it will be to solve the myriad problems created by the global use of site-locals. Also, please note that although it has been suggested as an element of some solutions, the global use of site-locals doesn't actually solve either of these problems. 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 Nov 12 03:43:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACBhOkd021389; Tue, 12 Nov 2002 03:43:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACBhOZ7021388; Tue, 12 Nov 2002 03:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACBhLkd021381 for ; Tue, 12 Nov 2002 03:43:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACBhPbB028218 for ; Tue, 12 Nov 2002 03:43:25 -0800 (PST) Received: from mx-relay21.treas.gov (mx-relay21.treas.gov [199.196.132.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA18738 for ; Tue, 12 Nov 2002 04:43:19 -0700 (MST) From: William_G_Allmond@notes.tcs.treas.gov Received: from TIAS24.net.treas.gov (tias24.treas.gov [199.196.132.24]) by mx-relay21.treas.gov (8.12.5/8.12.5) with SMTP id gACBVxrC029884; Tue, 12 Nov 2002 06:31:59 -0500 (EST) Received: from no.name.available by TIAS24.net.treas.gov via smtpd (for [199.196.132.5]) with SMTP; 12 Nov 2002 11:43:18 UT Received: from notes.tcs.treas.gov (localhost [127.0.0.1]) by mailhub-21.net.treas.gov (8.12.3/8.12.3) with ESMTP id gACBhCom021093; Tue, 12 Nov 2002 06:43:12 -0500 (EST) Sensitivity: Subject: Re: Address allocation schemes (Re: Naming and site-local) To: Margaret Wasserman Cc: IPng Date: Tue, 12 Nov 2002 06:43:11 -0500 Message-ID: X-MIMETrack: Serialize by Router on TCSHUB_LN/TCS/TREAS/GOV(Release 5.0.9 |November 16, 2001) at 11/12/2002 06:43:13 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My biggest concern is that there is the assumption that there will ALWAYS be more than enough IP numbers in IPv6. Wasn't that the thought when IPv4 was started? Is NAT or a "NAT-like" option the best thing to use? No, but it WILL be used. Whether it is due to some network engineer that doesn't understand IPv6, a security bureacrat that "mandates" it in the name of security, or a greedy ISP that sees a quick money for charging outlandish prices for extra IPv6 numbers. Or worse yet, we realize that we need more numbers! Though it isn't the best option, we can't remove or even prevent people from using it. We need to give an option of how to use it effectively and not breaking other things. So, with that being said, I recommend that we have a couple of blocks of varying sizes set aside for site-local. Gary Margaret Wasserman @sunroof.eng.sun.com on 11/12/2002 06:23:56 AM Sent by: owner-ipng@sunroof.eng.sun.com To: Brian E Carpenter cc: IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) Hi Brian, >So, why not simply deprecate SL for sites that have at least one >global prefix? Or am I too simple minded? If you are too simple minded, then I am right there with you. My making this exact suggestion is what started the 500+ message mail storm two weeks ago that has received so much attention on other lists... >That would then leave us with a couple of real problems to avoid NAT: >multihoming, and easy renumbering. Yes, exactly. And, it may be easier to determine ways to solve these problems in a flat address space than it will be to solve the myriad problems created by the global use of site-locals. Also, please note that although it has been suggested as an element of some solutions, the global use of site-locals doesn't actually solve either of these problems. 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 Nov 12 04:07:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACC7Ckd021591; Tue, 12 Nov 2002 04:07:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACC7Cad021590; Tue, 12 Nov 2002 04:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACC78kd021583 for ; Tue, 12 Nov 2002 04:07:08 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACC7HbB001059 for ; Tue, 12 Nov 2002 04:07:17 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29367 for ; Tue, 12 Nov 2002 05:07:12 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id BA8849F1B; Tue, 12 Nov 2002 07:07:11 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Nov 2002 07:07:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Address allocation schemes (Re: Naming and site-local) Date: Tue, 12 Nov 2002 07:07:11 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9A2D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Address allocation schemes (Re: Naming and site-local) Thread-Index: AcKKOM+GJ4l3ZKrcSmSolsr3zmD5xwACuQHw From: "Bound, Jim" To: "Margaret Wasserman" , "Brian E Carpenter" Cc: "IPng" X-OriginalArrivalTime: 12 Nov 2002 12:07:11.0617 (UTC) FILETIME=[07FC2710:01C28A44] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gACC79kd021584 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But, what I don't understand is how the use of overlapping > site-local addresses on globally-attached networks is any > better than NAT. It is not. Same problems that NAT has. And loss of e2e: apps, security, and mobility for those who only have those SLs. Not good. As a note industry will have a lot to say if this is deployed too. The education of NAT vs NO NAT is happening as we speak. Regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 04:08:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACC86kd021611; Tue, 12 Nov 2002 04:08:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACC86VQ021610; Tue, 12 Nov 2002 04:08:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACC83kd021603 for ; Tue, 12 Nov 2002 04:08:03 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACC8CMq007819 for ; Tue, 12 Nov 2002 04:08:12 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29704 for ; Tue, 12 Nov 2002 05:08:06 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 35CD96457; Tue, 12 Nov 2002 07:08:06 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Nov 2002 07:08:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Address allocation schemes (Re: Naming and site-local) Date: Tue, 12 Nov 2002 07:08:05 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9A2E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Address allocation schemes (Re: Naming and site-local) Thread-Index: AcKKPh3+cf63biidSeiPTPCNx5dVuwABftZg From: "Bound, Jim" To: "Margaret Wasserman" , "Brian E Carpenter" Cc: "IPng" X-OriginalArrivalTime: 12 Nov 2002 12:08:06.0085 (UTC) FILETIME=[28734F50:01C28A44] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gACC83kd021604 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am also of this simple mind. /jim [In matters of style, swim with the currents....in matters of principle, stand like a rock. - Thomas Jefferson] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 04:25:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACCPikd021943; Tue, 12 Nov 2002 04:25:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACCPiRi021942; Tue, 12 Nov 2002 04:25: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACCPfkd021935 for ; Tue, 12 Nov 2002 04:25:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACCPnMq010075 for ; Tue, 12 Nov 2002 04:25:49 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [210.254.137.98]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA09583 for ; Tue, 12 Nov 2002 05:25:43 -0700 (MST) Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1:10c1::2687]) by guri.nttv6.jp (Postfix) with ESMTP id 4B2C7B162F; Tue, 12 Nov 2002 21:25:41 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (Postfix) with ESMTP id 8DF9D125CF8; Tue, 12 Nov 2002 21:25:39 +0900 (JST) Date: Tue, 12 Nov 2002 21:25:39 +0900 (JST) Message-Id: <20021112.212539.45475719.miyakawa@nttv6.jp> To: luc.beloeil@rd.francetelecom.com Cc: ipng@sunroof.eng.sun.com, miyakawa@nttv6.jp Subject: Re: I-D ACTION:draft-ietf-ipv6-prefix-delegation-requirement-00.txt From: Shin Miyakawa In-Reply-To: References: Organizaton: NTT Communications X-Mailer: Mew version 2.2 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 > Does anyone think that a validity lifetime should be associated to the > prefix during prefix delegation? that's a good point. > Indeed RAs sent on a link associate a valid lifetime and a preferred > lifetime to the advertised prefixes. I would like to take this idea to the next draft. thanks. Shin Miyakawa -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 04:31:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACCVZkd022033; Tue, 12 Nov 2002 04:31:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACCVYoC022032; Tue, 12 Nov 2002 04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACCVVkd022025 for ; Tue, 12 Nov 2002 04:31:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACCVebB004212 for ; Tue, 12 Nov 2002 04:31:40 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10090 for ; Tue, 12 Nov 2002 05:31:34 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gACCVIis007812; Tue, 12 Nov 2002 13:31:19 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gACCVGcT036986; Tue, 12 Nov 2002 13:31:17 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47496 from ; Tue, 12 Nov 2002 13:31:12 +0100 Message-Id: <3DD0F480.70BFA890@hursley.ibm.com> Date: Tue, 12 Nov 2002 13:30:56 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: William_G_Allmond@notes.tcs.treas.gov Cc: Margaret Wasserman , IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gary, That is the slippery slope that got RFCs 1597 and 1631 published, and led us to a sea of troubles. Let's do better this time: just say no. Keep site locals for their intended purpose, i.e. isolated sites. Brian William_G_Allmond@notes.tcs.treas.gov wrote: > > My biggest concern is that there is the assumption that there will ALWAYS > be more than enough IP numbers in IPv6. Wasn't that the thought when IPv4 > was started? > > Is NAT or a "NAT-like" option the best thing to use? No, but it WILL be > used. Whether it is due to some network engineer that doesn't understand > IPv6, a security bureacrat that "mandates" it in the name of security, or a > greedy ISP that sees a quick money for charging outlandish prices for extra > IPv6 numbers. Or worse yet, we realize that we need more numbers! > > Though it isn't the best option, we can't remove or even prevent people > from using it. We need to give an option of how to use it effectively and > not breaking other things. > > So, with that being said, I recommend that we have a couple of blocks of > varying sizes set aside for site-local. > > Gary > > Margaret Wasserman @sunroof.eng.sun.com on 11/12/2002 > 06:23:56 AM > > Sent by: owner-ipng@sunroof.eng.sun.com > > To: Brian E Carpenter > cc: IPng > > Subject: Re: Address allocation schemes (Re: Naming and site-local) > > Hi Brian, > > >So, why not simply deprecate SL for sites that have at least one > >global prefix? Or am I too simple minded? > > If you are too simple minded, then I am right there with you. > > My making this exact suggestion is what started the 500+ message > mail storm two weeks ago that has received so much attention on > other lists... > > >That would then leave us with a couple of real problems to avoid NAT: > >multihoming, and easy renumbering. > > Yes, exactly. And, it may be easier to determine ways to solve > these problems in a flat address space than it will be to solve the > myriad problems created by the global use of site-locals. > > Also, please note that although it has been suggested as an element > of some solutions, the global use of site-locals doesn't actually > solve either of these problems. > > 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 Nov 12 04:53:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACCrOkd022367; Tue, 12 Nov 2002 04:53:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACCrODA022366; Tue, 12 Nov 2002 04:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACCrLkd022359 for ; Tue, 12 Nov 2002 04:53:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACCrTMq013581 for ; Tue, 12 Nov 2002 04:53:30 -0800 (PST) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07907 for ; Tue, 12 Nov 2002 05:53:24 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gACCrJ6Q033818 for ; Tue, 12 Nov 2002 13:53:20 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gACCrIcT111092 for ; Tue, 12 Nov 2002 13:53:18 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55902 from ; Tue, 12 Nov 2002 13:53:16 +0100 Message-Id: <3DD0F9AC.FF821AAA@hursley.ibm.com> Date: Tue, 12 Nov 2002 13:53:00 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Proposal for site-local clean-up Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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, in order to change the following paragraph in section 2.5.6: Current text: > Site-local addresses are designed to be used for addressing inside of > a site without the need for a global prefix. Although a subnet ID > may be up to 54-bits long, it is expected that globally-connected > sites will use the same subnet IDs for site-local and global > prefixes. Proposed new text: Site-local addresses are designed to be used for addressing inside of a site which is not connected to the Internet and therefore does not need a global prefix. They must not be used for a site that is connected to the Internet. Using site-local addresses, a subnet ID may be up to 54-bits long, but it is recommended to use at most 16-bit subnet IDs, for convenience if the site is later connected to the Internet using a global prefix. Otherwise, we will need a whole new RFC just for this paragraph. Alternatively, we could spend the next 5 years discussing the unnecessary complexities of using site-locals on connected sites. 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 Nov 12 05:09:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACD98kd022499; Tue, 12 Nov 2002 05:09:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACD982h022498; Tue, 12 Nov 2002 05:09:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACD95kd022491 for ; Tue, 12 Nov 2002 05:09:05 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACD9EMq015517 for ; Tue, 12 Nov 2002 05:09:14 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27107 for ; Tue, 12 Nov 2002 06:09:08 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA22740; Tue, 12 Nov 2002 05:08:52 -0800 (PST) Message-Id: <5.1.0.14.2.20021112080656.0747eec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Nov 2002 08:10:43 -0500 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: Proposal for site-local clean-up Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3DD0F9AC.FF821AAA@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 > >Current text: Hi Brian, > > Site-local addresses are designed to be used for addressing inside of > > a site without the need for a global prefix. Although a subnet ID > > may be up to 54-bits long, it is expected that globally-connected > > sites will use the same subnet IDs for site-local and global > > prefixes. > >Proposed new text: > > Site-local addresses are designed to be used for addressing inside of > a site which is not connected to the Internet and therefore does not > need a global prefix. They must not be used for a site that is connected > to the Internet. Using site-local addresses, a subnet ID may be up to > 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > for convenience if the site is later connected to the Internet using a > global prefix. I would support this change. However, I doubt that we will get consensus to make this change before the addressing architecture is issued as an RFC. I guess we'll see how things develop in Atlanta. >Alternatively, we could spend the next 5 years discussing the >unnecessary complexities of using site-locals on connected sites. This is _exactly_ what I am hoping to avoid. Let's limit site-locals to the well-understood case, and focus on solving the real problems: - Getting IPv6 finalized and ready for wide-scale deployment - Multi-homing - Renumbering - Security model for shared IPv4/IPv6 networks 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 Nov 12 06:08:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACE85kd023049; Tue, 12 Nov 2002 06:08:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACE81Wb023048; Tue, 12 Nov 2002 06:08:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACE7vkd023040 for ; Tue, 12 Nov 2002 06:07:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACE86bB016817 for ; Tue, 12 Nov 2002 06:08:06 -0800 (PST) Received: from ncsmtp03.ogw.rr.com (ncsmtp03.ogw.rr.com [24.93.67.84]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18508 for ; Tue, 12 Nov 2002 07:08:01 -0700 (MST) Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id gACE7ZiZ002092; Tue, 12 Nov 2002 09:07:35 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 12 Nov 2002 09:08:04 -0500 Message-ID: <3DD10C3F.5050009@nc.rr.com> Date: Tue, 12 Nov 2002 09:12:15 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up References: <5.1.0.14.2.20021112080656.0747eec0@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: > >> >> Current text: > > > Hi Brian, > >> > Site-local addresses are designed to be used for addressing >> inside of >> > a site without the need for a global prefix. Although a subnet ID >> > may be up to 54-bits long, it is expected that globally-connected >> > sites will use the same subnet IDs for site-local and global >> > prefixes. >> >> Proposed new text: >> >> Site-local addresses are designed to be used for addressing inside of >> a site which is not connected to the Internet and therefore does not >> need a global prefix. They must not be used for a site that is >> connected >> to the Internet. Using site-local addresses, a subnet ID may be up to >> 54-bits long, but it is recommended to use at most 16-bit subnet IDs, >> for convenience if the site is later connected to the Internet using a >> global prefix. > > > I would support this change. However, I doubt that we will get > consensus to make this change before the addressing architecture > is issued as an RFC. I guess we'll see how things develop in > Atlanta. > >> Alternatively, we could spend the next 5 years discussing the >> unnecessary complexities of using site-locals on connected sites. > > > This is _exactly_ what I am hoping to avoid. > > Let's limit site-locals to the well-understood case, and focus on > solving the real problems: > > - Getting IPv6 finalized and ready for wide-scale deployment > - Multi-homing > - Renumbering > - Security model for shared IPv4/IPv6 networks I agree with Brian and Margaret. 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 Nov 12 06:25:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACEPqkd023155; Tue, 12 Nov 2002 06:25:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACEPlkP023154; Tue, 12 Nov 2002 06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACEPhkd023147 for ; Tue, 12 Nov 2002 06:25:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACEPpMq029690 for ; Tue, 12 Nov 2002 06:25:52 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28921 for ; Tue, 12 Nov 2002 07:25:46 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA06089 for ; Tue, 12 Nov 2002 14:25:44 GMT Received: from starling.ecs.soton.ac.uk (starling.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gACEPbWX007282 for ; Tue, 12 Nov 2002 14:25:37 GMT Received: (from tjc@localhost) by starling.ecs.soton.ac.uk (8.11.6/8.11.6) id gACEPbr17637 for ipng@sunroof.eng.sun.com; Tue, 12 Nov 2002 14:25:37 GMT Date: Tue, 12 Nov 2002 14:25:37 +0000 From: Tim Chown To: IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) Message-ID: <20021112142537.GR17453@starling.ecs.soton.ac.uk> Mail-Followup-To: IPng References: <5.1.0.14.2.20021112052054.07434b80@mail.windriver.com> <3DD0E0D7.4E210B84@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD0E0D7.4E210B84@hursley.ibm.com> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Nov 12, 2002 at 12:07:03PM +0100, Brian E Carpenter wrote: > > So, why not simply deprecate SL for sites that have at least one > global prefix? Or am I too simple minded? I think a site getting global connectivity would find it hard to migrate instantly from site-locals to globals. The suggestion to prefer globals over site locals in the default address selection spec, along with Brian's suggested text a couple of mails back, seems good. A question is how does a 100, 10,000 or 1,000,000 node network using site-locals most efficiently migrate to globals, with minimum disruption, when gaining external connectivity? How long would the process take? > That would then leave us with a couple of real problems to avoid NAT: > multihoming, and easy renumbering. Maybe we should promote deployment scenarios that reduce the required frequency of renumbering, like using static rather than dynamic /48's for broadband customers. Perhaps that is an issue for the RIR's as it would require significantly more than a /32 for an ISP to do static /48's to a few million customers at an 80%-85% host density ratio. Should Christian's renumbering scenario draft be revisited? http://www.join.uni-muenster.de/drafts/draft-huitema-ipv6-renumber-00.txt I don't believe it is still current? Is this a v6ops or an ipv6 WG issue? 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 Nov 12 06:31:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACEVckd023198; Tue, 12 Nov 2002 06:31:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACEVaY8023197; Tue, 12 Nov 2002 06:31: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACEVWkd023190 for ; Tue, 12 Nov 2002 06:31:33 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACEVcbB020205 for ; Tue, 12 Nov 2002 06:31:38 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18922 for ; Tue, 12 Nov 2002 06:31:32 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gACEVK614058; Tue, 12 Nov 2002 16:31:20 +0200 Date: Tue, 12 Nov 2002 16:31:20 +0200 (EET) From: Pekka Savola To: Brian Haberman cc: Margaret Wasserman , Brian E Carpenter , Subject: Re: Proposal for site-local clean-up In-Reply-To: <3DD10C3F.5050009@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 12 Nov 2002, Brian Haberman wrote: > Margaret Wasserman wrote: > > > >> > >> Current text: > > > > > > Hi Brian, > > > >> > Site-local addresses are designed to be used for addressing > >> inside of > >> > a site without the need for a global prefix. Although a subnet ID > >> > may be up to 54-bits long, it is expected that globally-connected > >> > sites will use the same subnet IDs for site-local and global > >> > prefixes. > >> > >> Proposed new text: > >> > >> Site-local addresses are designed to be used for addressing inside of > >> a site which is not connected to the Internet and therefore does not > >> need a global prefix. They must not be used for a site that is > >> connected > >> to the Internet. Using site-local addresses, a subnet ID may be up to > >> 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > >> for convenience if the site is later connected to the Internet using a > >> global prefix. > > > > > > I would support this change. However, I doubt that we will get > > consensus to make this change before the addressing architecture > > is issued as an RFC. I guess we'll see how things develop in > > Atlanta. > > > >> Alternatively, we could spend the next 5 years discussing the > >> unnecessary complexities of using site-locals on connected sites. > > > > > > This is _exactly_ what I am hoping to avoid. > > > > Let's limit site-locals to the well-understood case, and focus on > > solving the real problems: > > > > - Getting IPv6 finalized and ready for wide-scale deployment > > - Multi-homing > > - Renumbering > > - Security model for shared IPv4/IPv6 networks > > I agree with Brian and Margaret. Also totally agree. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 07:03:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACF3wkd023428; Tue, 12 Nov 2002 07:03:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACF3w4q023427; Tue, 12 Nov 2002 07:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACF3kkd023417 for ; Tue, 12 Nov 2002 07:03:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACF3tMq006165 for ; Tue, 12 Nov 2002 07:03:55 -0800 (PST) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06860 for ; Tue, 12 Nov 2002 08:03:49 -0700 (MST) 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 gACF3l6Q047592 for ; Tue, 12 Nov 2002 16:03:48 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gACF3l69061234 for ; Tue, 12 Nov 2002 16:03:48 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA30742 from ; Tue, 12 Nov 2002 16:03:46 +0100 Message-Id: <3DD11841.58E3C445@hursley.ibm.com> Date: Tue, 12 Nov 2002 16:03:29 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng Subject: If site-local makes your head hurt,... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ... look at draft-chelius-adhoc-ipv6-00.txt > In this document, a new > addressable object is defined: the ad hoc connector. It virtualizes > several ad hoc network interfaces into a single addressable object. > To locally address ad hoc connectors, a third IPv6 local-use unicast > address (adhoc-local address) and the correlated use of the subnet > multicast scope are defined. 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 Nov 12 07:12:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACFCTkd023634; Tue, 12 Nov 2002 07:12:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACFCTQJ023633; Tue, 12 Nov 2002 07:12: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACFCPkd023620 for ; Tue, 12 Nov 2002 07:12:25 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACFCYMq007974 for ; Tue, 12 Nov 2002 07:12:34 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12706 for ; Tue, 12 Nov 2002 08:12:27 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA04211; Tue, 12 Nov 2002 17:12:22 +0200 Date: Tue, 12 Nov 2002 17:12:22 +0200 Message-Id: <200211121512.RAA04211@burp.tkv.asdf.org> From: Markku Savela To: tjc@ecs.soton.ac.uk CC: ipng@sunroof.eng.sun.com In-reply-to: <20021112142537.GR17453@starling.ecs.soton.ac.uk> (message from Tim Chown on Tue, 12 Nov 2002 14:25:37 +0000) Subject: Re: Address allocation schemes (Re: Naming and site-local) References: <5.1.0.14.2.20021112052054.07434b80@mail.windriver.com> <3DD0E0D7.4E210B84@hursley.ibm.com> <20021112142537.GR17453@starling.ecs.soton.ac.uk> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Tim Chown > I think a site getting global connectivity would find it hard to migrate > instantly from site-locals to globals. The suggestion to prefer globals > over site locals in the default address selection spec, along with Brian's > suggested text a couple of mails back, seems good. Why should it be a problem? - existing connections can continue to use the site locals, presense of global connectivity should not touch them in any way. - as far as I know, source address selection prefers site local if destination is site local, and global if destination is global. So, if your application gets site local address from your "two-faced DNS", it works; if your application gets global address due to current global connectivity, global address is used as a source too. - when global connection goes down, all applications using the global addresses will fail, but those using site locals continue to work. - it seems that it would be advantageous for nodes within the site to use sitelocals whenever possible, especially if your global connection is via flaky connection. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 07:14:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACFEUkd023687; Tue, 12 Nov 2002 07:14:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACFEU7s023686; Tue, 12 Nov 2002 07:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACFERkd023679 for ; Tue, 12 Nov 2002 07:14:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACFEabB027354 for ; Tue, 12 Nov 2002 07:14:36 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02053 for ; Tue, 12 Nov 2002 08:14:30 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gACFERm14402; Tue, 12 Nov 2002 17:14:27 +0200 Date: Tue, 12 Nov 2002 17:14:26 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-Reply-To: <3DD0F9AC.FF821AAA@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 12 Nov 2002, Brian E Carpenter wrote: [...] > Otherwise, we will need a whole new RFC just for this paragraph. > > Alternatively, we could spend the next 5 years discussing the > unnecessary complexities of using site-locals on connected sites. Note that we will need at least one more RFC anyway, because we really have to try to nail this down with solid reasoning -- else, no matter what it says in the addrarch -- this thread keeps popping up again and again. (I think this "reasoning draft" was already in progress -- good.) But as the addrarch is an RFC which will be frequently cited and read, it's good to have a statement there. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 07:26:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACFQEkd023902; Tue, 12 Nov 2002 07:26:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACFQETL023901; Tue, 12 Nov 2002 07:26: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACFQBkd023893 for ; Tue, 12 Nov 2002 07:26:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACFQKbB029466 for ; Tue, 12 Nov 2002 07:26:20 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21503 for ; Tue, 12 Nov 2002 08:26:14 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA23441; Tue, 12 Nov 2002 07:25:27 -0800 (PST) Message-Id: <5.1.0.14.2.20021112102404.07493280@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Nov 2002 10:26:48 -0500 To: Tim Chown From: Margaret Wasserman Subject: Re: Address allocation schemes (Re: Naming and site-local) Cc: IPng In-Reply-To: <20021112142537.GR17453@starling.ecs.soton.ac.uk> References: <3DD0E0D7.4E210B84@hursley.ibm.com> <5.1.0.14.2.20021112052054.07434b80@mail.windriver.com> <3DD0E0D7.4E210B84@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 I understand the theoretical issue, but is this a real-life issue? How many huge non-globally-connected IP networks will ever need to join the Internet? Margaret At 09:25 AM 11/12/02, Tim Chown wrote: >On Tue, Nov 12, 2002 at 12:07:03PM +0100, Brian E Carpenter wrote: > > > > So, why not simply deprecate SL for sites that have at least one > > global prefix? Or am I too simple minded? > >I think a site getting global connectivity would find it hard to migrate >instantly from site-locals to globals. The suggestion to prefer globals >over site locals in the default address selection spec, along with Brian's >suggested text a couple of mails back, seems good. A question is how >does a 100, 10,000 or 1,000,000 node network using site-locals most >efficiently migrate to globals, with minimum disruption, when gaining >external connectivity? How long would the process take? > > > That would then leave us with a couple of real problems to avoid NAT: > > multihoming, and easy renumbering. > >Maybe we should promote deployment scenarios that reduce the required >frequency of renumbering, like using static rather than dynamic /48's for >broadband customers. Perhaps that is an issue for the RIR's as it would >require significantly more than a /32 for an ISP to do static /48's to >a few million customers at an 80%-85% host density ratio. > >Should Christian's renumbering scenario draft be revisited? >http://www.join.uni-muenster.de/drafts/draft-huitema-ipv6-renumber-00.txt >I don't believe it is still current? >Is this a v6ops or an ipv6 WG issue? > >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 07:28:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACFShkd023935; Tue, 12 Nov 2002 07:28:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACFSh7U023934; Tue, 12 Nov 2002 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACFSekd023927 for ; Tue, 12 Nov 2002 07:28:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACFSmMq011352 for ; Tue, 12 Nov 2002 07:28:48 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17583 for ; Tue, 12 Nov 2002 08:28:42 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 938619E03; Tue, 12 Nov 2002 10:28:40 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Nov 2002 10:28:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for site-local clean-up Date: Tue, 12 Nov 2002 10:28:40 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9A43@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKKWH8v7e7rmOr/Sk656dHe/gXYBgAB6Yug From: "Bound, Jim" To: "Pekka Savola" , "Brian Haberman" Cc: "Margaret Wasserman" , "Brian E Carpenter" , X-OriginalArrivalTime: 12 Nov 2002 15:28:40.0399 (UTC) FILETIME=[2D75E5F0:01C28A60] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gACFSekd023928 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I also totally agree. /jim [In matters of style, swim with the currents....in matters of principle, stand like a rock. - Thomas Jefferson] > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, November 12, 2002 9:31 AM > To: Brian Haberman > Cc: Margaret Wasserman; Brian E Carpenter; ipng@sunroof.eng.sun.com > Subject: Re: Proposal for site-local clean-up > > > On Tue, 12 Nov 2002, Brian Haberman wrote: > > Margaret Wasserman wrote: > > > > > >> > > >> Current text: > > > > > > > > > Hi Brian, > > > > > >> > Site-local addresses are designed to be used for addressing > > >> inside of > > >> > a site without the need for a global prefix. > Although a subnet ID > > >> > may be up to 54-bits long, it is expected that > globally-connected > > >> > sites will use the same subnet IDs for site-local and global > > >> > prefixes. > > >> > > >> Proposed new text: > > >> > > >> Site-local addresses are designed to be used for > addressing inside of > > >> a site which is not connected to the Internet and > therefore does not > > >> need a global prefix. They must not be used for a > site that is > > >> connected > > >> to the Internet. Using site-local addresses, a subnet > ID may be up to > > >> 54-bits long, but it is recommended to use at most > 16-bit subnet IDs, > > >> for convenience if the site is later connected to the > Internet using a > > >> global prefix. > > > > > > > > > I would support this change. However, I doubt that we will get > > > consensus to make this change before the addressing > architecture is > > > issued as an RFC. I guess we'll see how things develop > in Atlanta. > > > > > >> Alternatively, we could spend the next 5 years discussing the > > >> unnecessary complexities of using site-locals on connected sites. > > > > > > > > > This is _exactly_ what I am hoping to avoid. > > > > > > Let's limit site-locals to the well-understood case, and focus on > > > solving the real problems: > > > > > > - Getting IPv6 finalized and ready for wide-scale > deployment > > > - Multi-homing > > > - Renumbering > > > - Security model for shared IPv4/IPv6 networks > > > > I agree with Brian and Margaret. > > Also totally agree. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 12 07:32:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACFW4kd023982; Tue, 12 Nov 2002 07:32:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACFW4nV023981; Tue, 12 Nov 2002 07:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACFW0kd023974 for ; Tue, 12 Nov 2002 07:32:00 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACFW9Mq012177 for ; Tue, 12 Nov 2002 07:32:09 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28975 for ; Tue, 12 Nov 2002 07:32:04 -0800 (PST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gACFVqaE023646; Tue, 12 Nov 2002 07:31:52 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAO42656; Tue, 12 Nov 2002 07:26:18 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA15221; Tue, 12 Nov 2002 07:32:01 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15825.7921.86828.623376@thomasm-u1.cisco.com> Date: Tue, 12 Nov 2002 07:32:01 -0800 (PST) To: Brian E Carpenter Cc: David Conrad , IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) In-Reply-To: <3DD0C155.DA18122C@hursley.ibm.com> References: <3DD0C155.DA18122C@hursley.ibm.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 Brian E Carpenter writes: > David Conrad wrote: > > > my personal opinion is that the only people who feel any possessive > > > instinct towards 2002:d90d:1cca:2:210:dcff:fe5a:f1fd are the people who > > > have to reconfigure other stuff when it changes..... > > > > Or the people who are affected when reconfiguration occurs. > > > > Welcome to NATv6. > > It's our job to stop that happening. > > Also, the vast majority of Internet users are not in the least > possessive about their IP address; it's different every time they > connect. Those who are possessive are those who run services of one > kind or another. It's our job to make that possible without forcing > them down the NAThole. Internet users, or people who make decisions for those internet users? I think the "possessiveness" is directly related to the desire for stability, so Joe Webpack probably doesn't care too much about this, but his employer's IT department cares a whole lot. Also: we haven't seen the fully impact of Joe Peerpack (esp VoIP), so it's a bit premature to guess, I'd think. 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 Nov 12 07:38:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACFcPkd024139; Tue, 12 Nov 2002 07:38:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACFcOoM024137; Tue, 12 Nov 2002 07:38:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACFcLkd024130 for ; Tue, 12 Nov 2002 07:38:21 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACFcUMq013292 for ; Tue, 12 Nov 2002 07:38:30 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03128 for ; Tue, 12 Nov 2002 07:38:24 -0800 (PST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA06920 for ; Tue, 12 Nov 2002 15:38:23 GMT Received: from starling.ecs.soton.ac.uk (starling.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gACFcDWX022919 for ; Tue, 12 Nov 2002 15:38:13 GMT Received: (from tjc@localhost) by starling.ecs.soton.ac.uk (8.11.6/8.11.6) id gACFcCF17730 for ipng@sunroof.eng.sun.com; Tue, 12 Nov 2002 15:38:12 GMT Date: Tue, 12 Nov 2002 15:38:12 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Address allocation schemes (Re: Naming and site-local) Message-ID: <20021112153812.GT17453@starling.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <5.1.0.14.2.20021112052054.07434b80@mail.windriver.com> <3DD0E0D7.4E210B84@hursley.ibm.com> <20021112142537.GR17453@starling.ecs.soton.ac.uk> <200211121512.RAA04211@burp.tkv.asdf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211121512.RAA04211@burp.tkv.asdf.org> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Nov 12, 2002 at 05:12:22PM +0200, Markku Savela wrote: > > Why should it be a problem? > > - it seems that it would be advantageous for nodes within the site to > use sitelocals whenever possible, especially if your global > connection is via flaky connection. Indeed, but this is the dilemma between preference for globals to avoid the site-local scoping "headaches" and preference for site-locals for connection persistence during renumbering or (dis)connectivity events. 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 Nov 12 08:01:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACG1Gkd024456; Tue, 12 Nov 2002 08:01:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACG1GAa024455; Tue, 12 Nov 2002 08:01:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACG1Ckd024448 for ; Tue, 12 Nov 2002 08:01:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACG1LbB006972 for ; Tue, 12 Nov 2002 08:01:21 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08106 for ; Tue, 12 Nov 2002 09:01:13 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACG16l01402; Tue, 12 Nov 2002 11:01:06 -0500 (EST) Message-Id: <200211121601.gACG16l01402@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: awhite@arc.corp.mot.com cc: IPng Subject: Re: Naming and site-local addresses In-reply-to: (Your message of "Tue, 12 Nov 2002 16:17:20 +1100.") <3DD08EE0.C0B2C504@motorola.com> Date: Tue, 12 Nov 2002 11:01:06 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As far as I can see, the safe way to do "two-faced" DNS with site locals is there is no safe way to do DNS with site locals, because the DNS server has no idea who is acutally going to use the results of the query. it's not reasonable to assume that the results will be used by the host immediately making that query. this is a problem with two-faced DNS in general, not specific to site locals. the fact that two-faced DNS exists does not mean that it's technically sound for general use. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 08:02:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACG2Jkd024476; Tue, 12 Nov 2002 08:02:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACG2JCi024475; Tue, 12 Nov 2002 08:02:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACG2Fkd024468 for ; Tue, 12 Nov 2002 08:02:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACG2OMq018356 for ; Tue, 12 Nov 2002 08:02:24 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08871 for ; Tue, 12 Nov 2002 09:02:18 -0700 (MST) Subject: RE: Address allocation schemes (Re: Naming and site-local) MIME-Version: 1.0 Date: Tue, 12 Nov 2002 08:02:51 -0800 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E44D@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Address allocation schemes (Re: Naming and site-local) Thread-Index: AcKKObXpfVU6HlH2QWO7zTDWT2ibmwAKGl4g From: "Michel Py" To: "Margaret Wasserman" Cc: "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gACG2Gkd024469 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > But, what I don't understand is how the use of > overlapping site-local addresses on globally-attached > networks is any better than NAT. It's not as bad (does not break apps that embed port numbers in the payload, for example) but this is an irrelevant argument: it still is bad. As I said before, it seems that everyone agrees that a globally unique site-local would be the way to go, but there are two major roadblocks to remove on that path: - Make sure that site-locals are not globally routable (I posted some comments about this earlier) - Solve the multihoming issue. Only when these are solved will we be able to move ahead towards globally unique, not globally routable site-locals. In the meantime, the crusade to remove site-locals is futile and a waste of everyone's time as 1. they have reached previous consensus and 2. will continue to be used until a better mouse trap is available. 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 Nov 12 08:03:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACG3mkd024514; Tue, 12 Nov 2002 08:03:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACG3m0T024513; Tue, 12 Nov 2002 08:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACG3jkd024503 for ; Tue, 12 Nov 2002 08:03:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACG3rMq018679 for ; Tue, 12 Nov 2002 08:03:54 -0800 (PST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18393 for ; Tue, 12 Nov 2002 09:03:48 -0700 (MST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gACG3jvx027184 for ; Tue, 12 Nov 2002 17:03:46 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gACG3j69014260 for ; Tue, 12 Nov 2002 17:03:45 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31214 from ; Tue, 12 Nov 2002 17:03:44 +0100 Message-Id: <3DD1264F.F2A4942B@hursley.ibm.com> Date: Tue, 12 Nov 2002 17:03:27 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Address allocation schemes (Re: Naming and site-local) References: <5.1.0.14.2.20021112052054.07434b80@mail.windriver.com> <3DD0E0D7.4E210B84@hursley.ibm.com> <20021112142537.GR17453@starling.ecs.soton.ac.uk> <200211121512.RAA04211@burp.tkv.asdf.org> <20021112153812.GT17453@starling.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, Nov 12, 2002 at 05:12:22PM +0200, Markku Savela wrote: > > > > Why should it be a problem? > > > > - it seems that it would be advantageous for nodes within the site to > > use sitelocals whenever possible, especially if your global > > connection is via flaky connection. > > Indeed, but this is the dilemma between preference for globals to avoid the > site-local scoping "headaches" and preference for site-locals for connection > persistence during renumbering or (dis)connectivity events. Er, but I use global addresses every day on good ol' IPv4, within my employer's internal network, and they work just fine when external connectivity is broken. I see no advantage in local addresses here. 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 Nov 12 08:06:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACG6qkd024559; Tue, 12 Nov 2002 08:06:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACG6qdb024558; Tue, 12 Nov 2002 08:06:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACG6nkd024551 for ; Tue, 12 Nov 2002 08:06:49 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACG6vMq019462 for ; Tue, 12 Nov 2002 08:06:57 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21961 for ; Tue, 12 Nov 2002 08:06:52 -0800 (PST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gACG6aIX025630; Tue, 12 Nov 2002 08:06:36 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAO43332; Tue, 12 Nov 2002 08:00:53 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA15224; Tue, 12 Nov 2002 08:06:35 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15825.9995.413394.714783@thomasm-u1.cisco.com> Date: Tue, 12 Nov 2002 08:06:35 -0800 (PST) To: Pekka Savola Cc: Brian Haberman , Margaret Wasserman , Brian E Carpenter , Subject: Re: Proposal for site-local clean-up In-Reply-To: References: <3DD10C3F.5050009@nc.rr.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 Count me in on agreeing with Brian too. Mike Pekka Savola writes: > On Tue, 12 Nov 2002, Brian Haberman wrote: > > Margaret Wasserman wrote: > > > > > >> > > >> Current text: > > > > > > > > > Hi Brian, > > > > > >> > Site-local addresses are designed to be used for addressing > > >> inside of > > >> > a site without the need for a global prefix. Although a subnet ID > > >> > may be up to 54-bits long, it is expected that globally-connected > > >> > sites will use the same subnet IDs for site-local and global > > >> > prefixes. > > >> > > >> Proposed new text: > > >> > > >> Site-local addresses are designed to be used for addressing inside of > > >> a site which is not connected to the Internet and therefore does not > > >> need a global prefix. They must not be used for a site that is > > >> connected > > >> to the Internet. Using site-local addresses, a subnet ID may be up to > > >> 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > > >> for convenience if the site is later connected to the Internet using a > > >> global prefix. > > > > > > > > > I would support this change. However, I doubt that we will get > > > consensus to make this change before the addressing architecture > > > is issued as an RFC. I guess we'll see how things develop in > > > Atlanta. > > > > > >> Alternatively, we could spend the next 5 years discussing the > > >> unnecessary complexities of using site-locals on connected sites. > > > > > > > > > This is _exactly_ what I am hoping to avoid. > > > > > > Let's limit site-locals to the well-understood case, and focus on > > > solving the real problems: > > > > > > - Getting IPv6 finalized and ready for wide-scale deployment > > > - Multi-homing > > > - Renumbering > > > - Security model for shared IPv4/IPv6 networks > > > > I agree with Brian and Margaret. > > Also totally agree. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 12 08:07:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACG74kd024569; Tue, 12 Nov 2002 08:07:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACG747v024568; Tue, 12 Nov 2002 08:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACG6wkd024561 for ; Tue, 12 Nov 2002 08:06:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACG76bB008567 for ; Tue, 12 Nov 2002 08:07:06 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16305 for ; Tue, 12 Nov 2002 09:07:01 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACG6vl01419; Tue, 12 Nov 2002 11:06:57 -0500 (EST) Message-Id: <200211121606.gACG6vl01419@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: awhite@arc.corp.mot.com cc: ipng@sunroof.eng.sun.com Subject: Re: Address selection and site local addresses In-reply-to: (Your message of "Tue, 12 Nov 2002 16:30:45 +1100.") <3DD09205.25C643A@motorola.com> Date: Tue, 12 Nov 2002 11:06:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Here are three models for address selection when both site-local and global > addresses are available. Which (if any) is preferred: fourth model: discourage use of site-locals when stable global addresses are available: Pros: drastically reduces complexity of applications that would otherwise have to deal with site-locals doesn't artifically split the problem of apps dealing with renumbering into local vs. non-local applications. Cons: does not permit use of site-locals for avoiding the effects of renumbering for local 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 Tue Nov 12 08:10:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACGAvkd024700; Tue, 12 Nov 2002 08:10:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACGAvZa024699; Tue, 12 Nov 2002 08:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACGArkd024692 for ; Tue, 12 Nov 2002 08:10:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACGB2Mq020382 for ; Tue, 12 Nov 2002 08:11:02 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14475 for ; Tue, 12 Nov 2002 09:10:54 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACGAol01464; Tue, 12 Nov 2002 11:10:50 -0500 (EST) Message-Id: <200211121610.gACGAol01464@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: David Conrad , IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) In-reply-to: (Your message of "Tue, 12 Nov 2002 09:52:37 +0100.") <3DD0C155.DA18122C@hursley.ibm.com> Date: Tue, 12 Nov 2002 11:10:50 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Those who are possessive are those who run services of one > kind or another. I think this is a bit too specific - until we produce a good way of doing renumbering, any site with more than a few hosts has good reason to want its addresses to be stable, whether or not it thinks it is running 'services'. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 08:12:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACGCQkd024776; Tue, 12 Nov 2002 08:12:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACGCQPF024775; Tue, 12 Nov 2002 08:12:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACGCLkd024765 for ; Tue, 12 Nov 2002 08:12:21 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACGCUbB009847 for ; Tue, 12 Nov 2002 08:12:30 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25500 for ; Tue, 12 Nov 2002 08:12:24 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACGCMl01479; Tue, 12 Nov 2002 11:12:22 -0500 (EST) Message-Id: <200211121612.gACGCMl01479@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tim Chown cc: IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) In-reply-to: (Your message of "Tue, 12 Nov 2002 09:15:24 GMT.") <20021112091524.GF17211@starling.ecs.soton.ac.uk> Date: Tue, 12 Nov 2002 11:12:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think NATv6 is inevitable, because some site policy makers will demand > it. which is why we need to make it very clear that NAT is not acceptable 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 Tue Nov 12 08:16:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACGGJkd024946; Tue, 12 Nov 2002 08:16:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACGGJbB024945; Tue, 12 Nov 2002 08:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACGGFkd024938 for ; Tue, 12 Nov 2002 08:16:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACGGOMq021602 for ; Tue, 12 Nov 2002 08:16:24 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17963 for ; Tue, 12 Nov 2002 09:16:18 -0700 (MST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gACGG2IX002103; Tue, 12 Nov 2002 08:16:02 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAO43502; Tue, 12 Nov 2002 08:10:18 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA15227; Tue, 12 Nov 2002 08:16:00 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15825.10560.817225.33559@thomasm-u1.cisco.com> Date: Tue, 12 Nov 2002 08:16:00 -0800 (PST) To: Keith Moore Cc: awhite@arc.corp.mot.com, ipng@sunroof.eng.sun.com Subject: Re: Address selection and site local addresses In-Reply-To: <200211121606.gACG6vl01419@astro.cs.utk.edu> References: <3DD09205.25C643A@motorola.com> <200211121606.gACG6vl01419@astro.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 What I want to know is why the concept "local" in the absense of enforceability (cf strong auth) isn't a thoroughly bogus concept. Site-locals seem to be trying to cling to that discredited bogosity. Mike Keith Moore writes: > > Here are three models for address selection when both site-local and global > > addresses are available. Which (if any) is preferred: > > fourth model: > > discourage use of site-locals when stable global addresses are available: > > Pros: drastically reduces complexity of applications that would otherwise > have to deal with site-locals > > doesn't artifically split the problem of apps dealing with > renumbering into local vs. non-local applications. > > Cons: does not permit use of site-locals for avoiding the effects > of renumbering for local 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 08:20:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACGKkkd025101; Tue, 12 Nov 2002 08:20:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACGKk5u025100; Tue, 12 Nov 2002 08:20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACGKgkd025093 for ; Tue, 12 Nov 2002 08:20:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACGKobB012231 for ; Tue, 12 Nov 2002 08:20:51 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21026 for ; Tue, 12 Nov 2002 09:20:44 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACGJVl01692; Tue, 12 Nov 2002 11:19:31 -0500 (EST) Message-Id: <200211121619.gACGJVl01692@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Thomas cc: Keith Moore , awhite@arc.corp.mot.com, ipng@sunroof.eng.sun.com Subject: Re: Address selection and site local addresses In-reply-to: (Your message of "Tue, 12 Nov 2002 08:16:00 PST.") <15825.10560.817225.33559@thomasm-u1.cisco.com> Date: Tue, 12 Nov 2002 11:19:31 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What I want to know is why the concept "local" in > the absense of enforceability (cf strong auth) > isn't a thoroughly bogus concept. for the purpose of security, in any network of significant size, it certainly is. if site-locals are useful at all it is not because of security. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 08:21:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACGLmkd025140; Tue, 12 Nov 2002 08:21:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACGLl6F025139; Tue, 12 Nov 2002 08:21: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACGLhkd025126 for ; Tue, 12 Nov 2002 08:21:43 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACGLqMq022821 for ; Tue, 12 Nov 2002 08:21:52 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23648 for ; Tue, 12 Nov 2002 09:21:45 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id SAA04362; Tue, 12 Nov 2002 18:21:42 +0200 Date: Tue, 12 Nov 2002 18:21:42 +0200 Message-Id: <200211121621.SAA04362@burp.tkv.asdf.org> From: Markku Savela To: brian@hursley.ibm.com CC: ipng@sunroof.eng.sun.com In-reply-to: <3DD1264F.F2A4942B@hursley.ibm.com> (message from Brian E Carpenter on Tue, 12 Nov 2002 17:03:27 +0100) Subject: Re: Address allocation schemes (Re: Naming and site-local) References: <5.1.0.14.2.20021112052054.07434b80@mail.windriver.com> <3DD0E0D7.4E210B84@hursley.ibm.com> <20021112142537.GR17453@starling.ecs.soton.ac.uk> <200211121512.RAA04211@burp.tkv.asdf.org> <20021112153812.GT17453@starling.ecs.soton.ac.uk> <3DD1264F.F2A4942B@hursley.ibm.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > - it seems that it would be advantageous for nodes within the site to > > > use sitelocals whenever possible, especially if your global > > > connection is via flaky connection. > > > > Indeed, but this is the dilemma between preference for globals to avoid the > > site-local scoping "headaches" and preference for site-locals for connection > > persistence during renumbering or (dis)connectivity events. > > Er, but I use global addresses every day on good ol' IPv4, within my > employer's internal network, and they work just fine when external > connectivity is broken. I see no advantage in local addresses here. Well, but that may change in IPv6: when your global connection disappears, your routers may stop advertising the global prefixes in RA's, thus your connections using global addressess will fail, because there is no route (onlink prefix) for them anymore. Of course, your routers may keep on announcing the global prefixes. However, there may be some confusion, if your new global connection brings up a different prefix (site renumbering), and your old prefix has been assigned to someone else. I think this is just a choice for site to make, if they know they have fixed global prefixes, they don't need to configure their routers to advertise site locals. They just configure the fixed globals. Again, no problem. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 08:37:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACGbUkd025466; Tue, 12 Nov 2002 08:37:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACGbUa3025465; Tue, 12 Nov 2002 08:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACGbRkd025458 for ; Tue, 12 Nov 2002 08:37:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACGbaMq026802 for ; Tue, 12 Nov 2002 08:37:36 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06896 for ; Tue, 12 Nov 2002 09:37:30 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA07671 for ; Tue, 12 Nov 2002 16:37:29 GMT Received: from starling.ecs.soton.ac.uk (starling.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gACGbQWX002179 for ; Tue, 12 Nov 2002 16:37:26 GMT Received: (from tjc@localhost) by starling.ecs.soton.ac.uk (8.11.6/8.11.6) id gACGbQp17794 for ipng@sunroof.eng.sun.com; Tue, 12 Nov 2002 16:37:26 GMT Date: Tue, 12 Nov 2002 16:37:26 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Address allocation schemes (Re: Naming and site-local) Message-ID: <20021112163726.GW17453@starling.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <5.1.0.14.2.20021112052054.07434b80@mail.windriver.com> <3DD0E0D7.4E210B84@hursley.ibm.com> <20021112142537.GR17453@starling.ecs.soton.ac.uk> <200211121512.RAA04211@burp.tkv.asdf.org> <20021112153812.GT17453@starling.ecs.soton.ac.uk> <3DD1264F.F2A4942B@hursley.ibm.com> <200211121621.SAA04362@burp.tkv.asdf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211121621.SAA04362@burp.tkv.asdf.org> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Nov 12, 2002 at 06:21:42PM +0200, Markku Savela wrote: > > > Er, but I use global addresses every day on good ol' IPv4, within my > > employer's internal network, and they work just fine when external > > connectivity is broken. I see no advantage in local addresses here. > > Well, but that may change in IPv6: when your global connection > disappears, your routers may stop advertising the global prefixes in > RA's, thus your connections using global addressess will fail, because > there is no route (onlink prefix) for them anymore. > > Of course, your routers may keep on announcing the global > prefixes. However, there may be some confusion, if your new global > connection brings up a different prefix (site renumbering), and your > old prefix has been assigned to someone else. > > I think this is just a choice for site to make, if they know they have > fixed global prefixes, they don't need to configure their routers to > advertise site locals. They just configure the fixed globals. Again, > no problem. That may be true, but I was also considering the fact that a discontinuity event may be between connections where different prefixes are used. Thus you could still use the global addresses allocated at the last time of connection (if you are isolated you can in theory use what you like...), but this prefix and the addresses may change with the next connection. If you know you'll come back online with the same addresses, you may be able to make different assumptions (but as Keith said earlier, the applications won't be aware of this). 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 Nov 12 09:14:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACHEQkd025878; Tue, 12 Nov 2002 09:14:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACHEQaI025877; Tue, 12 Nov 2002 09:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACHEMkd025870 for ; Tue, 12 Nov 2002 09:14:22 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACHEVMq006740 for ; Tue, 12 Nov 2002 09:14:31 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06536 for ; Tue, 12 Nov 2002 10:14:25 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACGCMl01479; Tue, 12 Nov 2002 11:12:22 -0500 (EST) Message-Id: <200211121612.gACGCMl01479@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tim Chown cc: IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) In-reply-to: (Your message of "Tue, 12 Nov 2002 09:15:24 GMT.") <20021112091524.GF17211@starling.ecs.soton.ac.uk> Date: Tue, 12 Nov 2002 11:12:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think NATv6 is inevitable, because some site policy makers will demand > it. which is why we need to make it very clear that NAT is not acceptable 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 Tue Nov 12 09:29:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACHTHkd026029; Tue, 12 Nov 2002 09:29:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACHTG2V026028; Tue, 12 Nov 2002 09:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACHT7kd026021 for ; Tue, 12 Nov 2002 09:29:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACHTGMq011514 for ; Tue, 12 Nov 2002 09:29:16 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17536 for ; Tue, 12 Nov 2002 10:29:10 -0700 (MST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gACHSxNi028605; Tue, 12 Nov 2002 09:28:59 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAO45266; Tue, 12 Nov 2002 09:23:16 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA15237; Tue, 12 Nov 2002 09:28:59 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15825.14938.905921.353855@thomasm-u1.cisco.com> Date: Tue, 12 Nov 2002 09:28:58 -0800 (PST) To: Keith Moore Cc: Michael Thomas , awhite@arc.corp.mot.com, ipng@sunroof.eng.sun.com Subject: Re: Address selection and site local addresses In-Reply-To: <200211121619.gACGJVl01692@astro.cs.utk.edu> References: <15825.10560.817225.33559@thomasm-u1.cisco.com> <200211121619.gACGJVl01692@astro.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: > > What I want to know is why the concept "local" in > > the absense of enforceability (cf strong auth) > > isn't a thoroughly bogus concept. > > for the purpose of security, in any network of significant size, > it certainly is. > > if site-locals are useful at all it is not because of security. Well then, I guess I'm at a loss about why people would want to use site-locals for local services. If it's not for the possibility of access control, then what else is it? 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 Nov 12 09:34:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACHY2kd026089; Tue, 12 Nov 2002 09:34:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACHY189026088; Tue, 12 Nov 2002 09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACHXvkd026078 for ; Tue, 12 Nov 2002 09:33:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACHY6bB002034 for ; Tue, 12 Nov 2002 09:34:06 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08406 for ; Tue, 12 Nov 2002 10:34:03 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACHXZl02173; Tue, 12 Nov 2002 12:33:35 -0500 (EST) Message-Id: <200211121733.gACHXZl02173@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Thomas cc: Keith Moore , awhite@arc.corp.mot.com, ipng@sunroof.eng.sun.com Subject: Re: Address selection and site local addresses In-reply-to: (Your message of "Tue, 12 Nov 2002 09:28:58 PST.") <15825.14938.905921.353855@thomasm-u1.cisco.com> Date: Tue, 12 Nov 2002 12:33:35 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > What I want to know is why the concept "local" in > > > the absense of enforceability (cf strong auth) > > > isn't a thoroughly bogus concept. > > > > for the purpose of security, in any network of significant size, > > it certainly is. > > > > if site-locals are useful at all it is not because of security. > > Well then, I guess I'm at a loss about why people would > want to use site-locals for local services. If it's not > for the possibility of access control, then what else > is it? valid use cases appear to be: - for use in isolated networks (not connected to _any_ other network) - local addresses that are stable across renumbering - addresses for intermittently-connected networks lacking a stable global prefix Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 09:44:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACHiskd026244; Tue, 12 Nov 2002 09:44:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACHisAv026243; Tue, 12 Nov 2002 09:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACHidkd026236 for ; Tue, 12 Nov 2002 09:44:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACHilMq016456 for ; Tue, 12 Nov 2002 09:44:48 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14949 for ; Tue, 12 Nov 2002 10:44:41 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACHiPl02296; Tue, 12 Nov 2002 12:44:25 -0500 (EST) Message-Id: <200211121744.gACHiPl02296@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Margaret Wasserman" , "IPng" Subject: Re: Address allocation schemes (Re: Naming and site-local) In-reply-to: (Your message of "Tue, 12 Nov 2002 08:02:51 PST.") <2B81403386729140A3A899A8B39B046405E44D@server2000> Date: Tue, 12 Nov 2002 12:44:25 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As I said before, it seems that everyone agrees that a globally unique > site-local would be the way to go, but there are two major roadblocks to > remove on that path: > - Make sure that site-locals are not globally routable (I posted some > comments about this earlier) seems fairly easy. the hard part is the wordsmithing. - addresses with this prefix range MUST NOT be advertised to other networks. - advertisements for addresses with this prefix range that are received from other networks SHOULD be filtered - traffic with source or destination addresses in this prefix range SHOULD be filtered from external connections unless there is an explicit agreement with the peer to accept traffic for a specific range of addresses. > - Solve the multihoming issue. Multihoming is a problem, but the multihoming issue seems orthogonal to site-locals. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 09:53:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACHr9kd026361; Tue, 12 Nov 2002 09:53:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACHr9nL026360; Tue, 12 Nov 2002 09:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACHr6kd026353 for ; Tue, 12 Nov 2002 09:53:06 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACHrFMq019325 for ; Tue, 12 Nov 2002 09:53:15 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07137 for ; Tue, 12 Nov 2002 10:53:09 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA28649; Tue, 12 Nov 2002 09:52:40 -0800 (PST) Message-Id: <5.1.0.14.2.20021112125322.074b8c90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Nov 2002 12:54:27 -0500 To: Keith Moore From: Margaret Wasserman Subject: Re: Address allocation schemes (Re: Naming and site-local) Cc: "Michel Py" , "IPng" In-Reply-To: <200211121744.gACHiPl02296@astro.cs.utk.edu> References: <(Your message of "Tue, 12 Nov 2002 08:02:51 PST.") <2B81403386729140A3A899A8B39B046405E44D@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Do you meant to imply that a separate block of addresses should be set aside for non-globally-routable globally-unique addresses? I'm not sure what we gain by doing that, as opposed to setting aside private address space from any global prefix by filtering it at administrative boundaries... Margaret At 12:44 PM 11/12/02, Keith Moore wrote: > > As I said before, it seems that everyone agrees that a globally unique > > site-local would be the way to go, but there are two major roadblocks to > > remove on that path: > > - Make sure that site-locals are not globally routable (I posted some > > comments about this earlier) > >seems fairly easy. the hard part is the wordsmithing. > >- addresses with this prefix range MUST NOT be advertised to other networks. > >- advertisements for addresses with this prefix range that are received from >other networks SHOULD be filtered > >- traffic with source or destination addresses in this prefix range >SHOULD be filtered from external connections unless there is an explicit >agreement with the peer to accept traffic for a specific range of addresses. > > > - Solve the multihoming issue. > >Multihoming is a problem, but the multihoming issue seems orthogonal >to site-locals. > >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 09:53:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACHrYkd026371; Tue, 12 Nov 2002 09:53:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACHrYHU026370; Tue, 12 Nov 2002 09:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACHrSkd026363 for ; Tue, 12 Nov 2002 09:53:28 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACHrbbB007583 for ; Tue, 12 Nov 2002 09:53:37 -0800 (PST) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06500 for ; Tue, 12 Nov 2002 09:53:31 -0800 (PST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 977B6274C; Tue, 12 Nov 2002 09:53:31 -0800 (PST) Received: from anw.zk3.dec.com (and.zk3.dec.com [16.140.64.3]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id AFDE7AFD; Tue, 12 Nov 2002 09:53:30 -0800 (PST) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id gACHrT90001701796; Tue, 12 Nov 2002 12:53:29 -0500 (EST) Date: Tue, 12 Nov 2002 12:53:29 -0500 (EST) From: Jack McCann Message-Id: <200211121753.gACHrT90001701796@anw.zk3.dec.com> To: brian@hursley.ibm.com Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One more try on sin6_flowinfo for 2553bis, adopting Brian's verbage and laying the foundation for application compatibility with future use of the field: The sin6_flowinfo field is a 32-bit field intended to contain flow-related information. The exact way this field is mapped to or from a packet is not currently specified. Until such time as its use is specified, applications should set this field to zero when constructing a sockaddr_in6, and ignore this field in a sockaddr_in6 structure constructed by the system. I also propose to change the comment next to the sin6_flowinfo field in the sockaddr_in6 structure definition from: uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */ to: uint32_t sin6_flowinfo; /* IPv6 flow information */ Barring further objections, I'll plan to update the spec after tlanta IETF. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 10:03:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACI3dkd026589; Tue, 12 Nov 2002 10:03:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACI3dFM026588; Tue, 12 Nov 2002 10:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACI3Ykd026578 for ; Tue, 12 Nov 2002 10:03:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACI3fMq022687 for ; Tue, 12 Nov 2002 10:03:41 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19137 for ; Tue, 12 Nov 2002 11:03:36 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACI3El02466; Tue, 12 Nov 2002 13:03:14 -0500 (EST) Message-Id: <200211121803.gACI3El02466@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Keith Moore , "Michel Py" , "IPng" Subject: Re: Address allocation schemes (Re: Naming and site-local) In-reply-to: (Your message of "Tue, 12 Nov 2002 12:54:27 EST.") <5.1.0.14.2.20021112125322.074b8c90@mail.windriver.com> Date: Tue, 12 Nov 2002 13:03:14 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Do you meant to imply that a separate block of addresses should be > set aside for non-globally-routable globally-unique addresses? yes. > I'm not sure what we gain by doing that, as opposed to setting aside > private address space from any global prefix by filtering it at > administrative boundaries... we need the ability to assign global prefixes to sites that aren't directly connected to the public Internet, even though they might be connected to large numbers of other networks. Keth -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 10:40:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACIeLkd027478; Tue, 12 Nov 2002 10:40:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACIeKc3027477; Tue, 12 Nov 2002 10:40: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACIeHkd027470 for ; Tue, 12 Nov 2002 10:40:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACIeQMq004464 for ; Tue, 12 Nov 2002 10:40:27 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13882 for ; Tue, 12 Nov 2002 11:40:21 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gACIdnU16147; Tue, 12 Nov 2002 20:39:50 +0200 Date: Tue, 12 Nov 2002 20:39:49 +0200 (EET) From: Pekka Savola To: Keith Moore cc: Margaret Wasserman , Michel Py , IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) In-Reply-To: <200211121803.gACI3El02466@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 12 Nov 2002, Keith Moore wrote: > > I'm not sure what we gain by doing that, as opposed to setting aside > > private address space from any global prefix by filtering it at > > administrative boundaries... > > we need the ability to assign global prefixes to sites that aren't > directly connected to the public Internet, even though they might > be connected to large numbers of other networks. Allocating one /32 and giving these sites a /48 each should last for the first 64k such private networks (which are assumed to be rather rare). Should be pretty easy to accomplish if this is really necessary.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 10:44:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACIiMkd027581; Tue, 12 Nov 2002 10:44:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACIiMe5027580; Tue, 12 Nov 2002 10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACIiIkd027573 for ; Tue, 12 Nov 2002 10:44:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACIiRMq005780 for ; Tue, 12 Nov 2002 10:44:27 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24019 for ; Tue, 12 Nov 2002 11:44:18 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA13050; Tue, 12 Nov 2002 10:43:47 -0800 (PST) Message-Id: <5.1.0.14.2.20021112134248.074bbbf0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Nov 2002 13:45:36 -0500 To: Keith Moore From: Margaret Wasserman Subject: Re: Address allocation schemes (Re: Naming and site-local) Cc: Keith Moore , "Michel Py" , "IPng" In-Reply-To: <200211121803.gACI3El02466@astro.cs.utk.edu> References: <(Your message of "Tue, 12 Nov 2002 12:54:27 EST.") <5.1.0.14.2.20021112125322.074b8c90@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 > > > I'm not sure what we gain by doing that, as opposed to setting aside > > private address space from any global prefix by filtering it at > > administrative boundaries... > >we need the ability to assign global prefixes to sites that aren't >directly connected to the public Internet, even though they might >be connected to large numbers of other networks. Okay. But, why make them inherently private, non-routable addresses? If we come up with a reasonable way to allocate globally-unique, provider-independent addresses, is there a reason to require that they be non-globally-routable? There is some work underway in multi6 regarding mechanisms for provider-independent allocation of globally routable addresses. Wouldn't that be better? Then, if you wanted part of your network to be private, you could make it private via filtering both traffic and routing protocol advertisements. 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 Nov 12 10:45:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACIjQkd027628; Tue, 12 Nov 2002 10:45:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACIjPcE027627; Tue, 12 Nov 2002 10:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACIjLkd027617 for ; Tue, 12 Nov 2002 10:45:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACIjUMq006205 for ; Tue, 12 Nov 2002 10:45:30 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14823 for ; Tue, 12 Nov 2002 11:45:24 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACIhXl02640; Tue, 12 Nov 2002 13:43:33 -0500 (EST) Message-Id: <200211121843.gACIhXl02640@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Keith Moore , Margaret Wasserman , Michel Py , IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) In-reply-to: (Your message of "Tue, 12 Nov 2002 20:39:49 +0200.") Date: Tue, 12 Nov 2002 13:43:33 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > I'm not sure what we gain by doing that, as opposed to setting aside > > > private address space from any global prefix by filtering it at > > > administrative boundaries... > > > > we need the ability to assign global prefixes to sites that aren't > > directly connected to the public Internet, even though they might > > be connected to large numbers of other networks. > > Allocating one /32 and giving these sites a /48 each should last for the > first 64k such private networks (which are assumed to be rather rare). they might be more plentiful than you think. I have no problem with starting out with a /32 but perhaps that /32 should be allocated from the "top end" of (otherwise unallocated) v6 space so that additional allocations could be aggregated with the initial one in a single prefix (for the purpose of filtering) the "hard" part is establishing the mechanism for doling them out. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 10:50:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACIo6kd028045; Tue, 12 Nov 2002 10:50:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACIo6Aq028044; Tue, 12 Nov 2002 10:50: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACInxkd028014 for ; Tue, 12 Nov 2002 10:49:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACIo8bB024912 for ; Tue, 12 Nov 2002 10:50:08 -0800 (PST) Received: from esunmail ([129.147.58.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21542 for ; Tue, 12 Nov 2002 11:50:03 -0700 (MST) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5H00B3G8BD0W@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 12 Nov 2002 11:50:02 -0700 (MST) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H5H00A3U8BCCC@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 12 Nov 2002 11:50:01 -0700 (MST) Date: Tue, 12 Nov 2002 10:49:58 -0800 From: Alain Durand Subject: Re: Proposal for site-local clean-up To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Message-id: <3DD14D56.7040903@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: <3DD0F9AC.FF821AAA@hursley.ibm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: >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, >in order to change the following paragraph in section 2.5.6: > [...] >Alternatively, we could spend the next 5 years discussing the >unnecessary complexities of using site-locals on connected sites. > > Brian > As I would like to see IPv6 deployed in my lifetime, I support proposal like this one that makes life simpler. It's time to move on, unless the volume of discussion/rat holing on this topic will really become a DOS attack on the mailling list, or worse, on IPv6 itself. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 10:51:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACIpkkd028197; Tue, 12 Nov 2002 10:51:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACIpktH028196; Tue, 12 Nov 2002 10:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACIpgkd028189 for ; Tue, 12 Nov 2002 10:51:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACIppMq008537 for ; Tue, 12 Nov 2002 10:51:51 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24630 for ; Tue, 12 Nov 2002 11:51:45 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gACIoqi16280; Tue, 12 Nov 2002 20:50:52 +0200 Date: Tue, 12 Nov 2002 20:50:51 +0200 (EET) From: Pekka Savola To: Keith Moore cc: Margaret Wasserman , Michel Py , IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) In-Reply-To: <200211121843.gACIhXl02640@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 12 Nov 2002, Keith Moore wrote: > > > > I'm not sure what we gain by doing that, as opposed to setting aside > > > > private address space from any global prefix by filtering it at > > > > administrative boundaries... > > > > > > we need the ability to assign global prefixes to sites that aren't > > > directly connected to the public Internet, even though they might > > > be connected to large numbers of other networks. > > > > Allocating one /32 and giving these sites a /48 each should last for the > > first 64k such private networks (which are assumed to be rather rare). > > they might be more plentiful than you think. [...] Well, personally, I can clearly see a few cases (e.g. in the military), but the rest, I could separate to a few cases: 1) have IPv4 connectivity but no IPv6 (or stable IPv6 -- something like 6to4 with dynamic v4 address) 2) have zero 'net connectivity ("clear cases") -- usually by design 3) have full connectivity but want somehow permanent addresses, to be used locally, for renumbering, to be leaked to the internet, etc.etc. Which cases we want to provide addresses for? (btw. I suggested one /32 but one for each RIR + room for expansion would be more adequate, I think.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 11:00:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACJ0Bkd028777; Tue, 12 Nov 2002 11:00:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACJ0BrM028775; Tue, 12 Nov 2002 11:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACJ08kd028768 for ; Tue, 12 Nov 2002 11:00:08 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACJ0HbB028684 for ; Tue, 12 Nov 2002 11:00:17 -0800 (PST) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03996 for ; Tue, 12 Nov 2002 11:00:11 -0800 (PST) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id gACJ0Kvm012204 for ; Tue, 12 Nov 2002 11:00:20 -0800 (PST) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id gACJ0Hjr012202 for ipng@sunroof.eng.sun.com; Tue, 12 Nov 2002 11:00:17 -0800 (PST) Date: Tue, 12 Nov 2002 11:00:17 -0800 From: Shannon -jj Behrens To: ipng@sunroof.eng.sun.com Subject: provider independent addressing (Re: site-locals) Message-ID: <20021112190017.GA11163@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 Summary: a provider independent addressing solution is proposed so that site-locals are not necessary. One of the chief reasons proposed for the use of site-locals is for stable addressing (especially if you need to change ISP's). A nicer solution, that has so far proven unimplementable is provider independent addressing. The problem with provider independent addressing is that, because routing is no longer aggregated, it becomes too difficult for our current hardware limits. I've also heard proposals for allocating prefixes to each geographical point on earth. I propose a modification of this idea. Allocate a /32 (or some suitable number) to each region (where each region is about the size of California, but is based on politics rather than size). Then each ISP in that region could coordinate to delegate prefixes out of that slice of that /32. Hence, we have aggregation on the region level, but within that slice, the routing would be flat (i.e. prefixes are not associated with any ISP). Flat routing on a region level is doable if the region isn't too large. I can see that some people might complain that physically relocating to another region would cause renumbering, yet I propose that physically relocating to another region is more difficult in and of itself than just renumbering. Of course, I haven't done all my reading yet, so forgive me if I'm missing an obvious problem. -jj -- def qsort(l): # Purely functional implementation of QSort in Python. if not len(l): return [] return (qsort([i for i in l[1:] if i < l[0]]) + [l[0]] + qsort([i for i in l[1:] if i >= l[0]])) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 11:12:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACJCMkd029058; Tue, 12 Nov 2002 11:12:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACJCMdH029057; Tue, 12 Nov 2002 11:12: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACJCJkd029050 for ; Tue, 12 Nov 2002 11:12:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACJCSbB002445 for ; Tue, 12 Nov 2002 11:12:28 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11013 for ; Tue, 12 Nov 2002 12:12:22 -0700 (MST) Subject: RE: Address allocation schemes (Re: Naming and site-local) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 12 Nov 2002 11:12:53 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD353@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Address allocation schemes (Re: Naming and site-local) Thread-Index: AcKKHlsSfJRZ8GBvRfCxBRfpWMWzewAYK+0Q 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 gACJCJkd029051 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Harald, >> Michel Py wrote: >> What would be the difference between this and the good >> old "8K DFZ", except one more digit and that ISPs could >> get a block matching their size instead of what used to >> be called a TLA? > Harald Tveit Alvestrand wrote: > Apart from not having any administratively fixed > boundaries, I haven't seen any need for a difference until > someone comes along with a genuinely better idea. > but as I said, I am naive in those matters. Unless this is 2nd degree humor I do not see what is naive about it. This is the current vision and has been for a while, or did I miss something? 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 Nov 12 11:56:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACJuikd029339; Tue, 12 Nov 2002 11:56:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACJuioe029338; Tue, 12 Nov 2002 11:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACJuekd029331 for ; Tue, 12 Nov 2002 11:56:40 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACJunMq000231 for ; Tue, 12 Nov 2002 11:56:49 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03832 for ; Tue, 12 Nov 2002 11:56:44 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id E88B45772; Tue, 12 Nov 2002 14:56:43 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Nov 2002 14:56:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Address allocation schemes (Re: Naming and site-local) Date: Tue, 12 Nov 2002 14:56:43 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B6A6@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Address allocation schemes (Re: Naming and site-local) Thread-Index: AcKKZhqiOTuY50bESUudHNERD1Hu9wAH2ahQ From: "Bound, Jim" To: "Brian E Carpenter" , X-OriginalArrivalTime: 12 Nov 2002 19:56:43.0811 (UTC) FILETIME=[9FEBCF30:01C28A85] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gACJufkd029332 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Er, but I use global addresses every day on good ol' IPv4, > within my employer's internal network, and they work just > fine when external connectivity is broken. I see no advantage > in local addresses here. Same here for me. I see not advantage at all and lots of pain. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 11:57:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACJvAkd029349; Tue, 12 Nov 2002 11:57:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACJv9BJ029348; Tue, 12 Nov 2002 11:57:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACJv4kd029341 for ; Tue, 12 Nov 2002 11:57:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACJvDbB016810 for ; Tue, 12 Nov 2002 11:57:13 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14283 for ; Tue, 12 Nov 2002 12:57:07 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 19524423C; Tue, 12 Nov 2002 14:57:07 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Nov 2002 14:57:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Address allocation schemes (Re: Naming and site-local) Date: Tue, 12 Nov 2002 14:57:06 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9A69@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Address allocation schemes (Re: Naming and site-local) Thread-Index: AcKKZp/apT3VdyvsTDmIAHY0bftLYAAHwVPg From: "Bound, Jim" To: "Keith Moore" , "Tim Chown" Cc: "IPng" X-OriginalArrivalTime: 12 Nov 2002 19:57:06.0915 (UTC) FILETIME=[ADB13330:01C28A85] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gACJv4kd029342 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Totally unacceptable. /jim [In matters of style, swim with the currents....in matters of principle, stand like a rock. - Thomas Jefferson] > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Tuesday, November 12, 2002 11:12 AM > To: Tim Chown > Cc: IPng > Subject: Re: Address allocation schemes (Re: Naming and site-local) > > > > I think NATv6 is inevitable, because some site policy makers will > > demand it. > > which is why we need to make it very clear that NAT is not > acceptable 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 11:58:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACJwhkd029374; Tue, 12 Nov 2002 11:58:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACJwhkv029373; Tue, 12 Nov 2002 11:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACJwdkd029366 for ; Tue, 12 Nov 2002 11:58:39 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACJwmbB017273 for ; Tue, 12 Nov 2002 11:58:48 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05141 for ; Tue, 12 Nov 2002 11:58:43 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id DA4569E7F; Tue, 12 Nov 2002 14:58:42 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Nov 2002 14:58:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for site-local clean-up Date: Tue, 12 Nov 2002 14:58:42 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9A6A@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKKfI/2k3SCFrjxQ02SKbAtfWPS7gACUUXA From: "Bound, Jim" To: "Alain Durand" , "Brian E Carpenter" Cc: X-OriginalArrivalTime: 12 Nov 2002 19:58:42.0837 (UTC) FILETIME=[E6DDBC50:01C28A85] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gACJwekd029367 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK folks I am counting and I see clear majority for margarets proposal? /jim [In matters of style, swim with the currents....in matters of principle, stand like a rock. - Thomas Jefferson] > -----Original Message----- > From: Alain Durand [mailto:Alain.Durand@Sun.COM] > Sent: Tuesday, November 12, 2002 1:50 PM > To: Brian E Carpenter > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Proposal for site-local clean-up > > > > > Brian E Carpenter wrote: > > >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, in order to > >change the following paragraph in section 2.5.6: > > > [...] > > >Alternatively, we could spend the next 5 years discussing the > >unnecessary complexities of using site-locals on connected sites. > > > > Brian > > > > As I would like to see IPv6 deployed in my lifetime, > I support proposal like this one that makes life simpler. > > It's time to move on, unless the volume of discussion/rat > holing on this topic will really become a DOS attack on the > mailling list, or worse, on IPv6 itself. > > - 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 12:04:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACK4Ckd029518; Tue, 12 Nov 2002 12:04:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACK4Cgq029517; Tue, 12 Nov 2002 12:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACK47kd029502 for ; Tue, 12 Nov 2002 12:04:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACK4GbB019158 for ; Tue, 12 Nov 2002 12:04:16 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19447 for ; Tue, 12 Nov 2002 13:04:10 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACK3Ml02719; Tue, 12 Nov 2002 15:03:22 -0500 (EST) Message-Id: <200211122003.gACK3Ml02719@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Keith Moore , "Michel Py" , "IPng" Subject: Re: Address allocation schemes (Re: Naming and site-local) In-reply-to: (Your message of "Tue, 12 Nov 2002 13:45:36 EST.") <5.1.0.14.2.20021112134248.074bbbf0@mail.windriver.com> Date: Tue, 12 Nov 2002 15:03:21 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Okay. > > But, why make them inherently private, non-routable addresses? > If we come up with a reasonable way to allocate globally-unique, > provider-independent addresses, is there a reason to require > that they be non-globally-routable? those would be okay for my purposes. because I see global routing in the public network as a special case of routing between networks, I don't see that having a "non globally routable" attribute embedded in the address is that useful - any more than having a "site local" attribute. if you don't trust your border filters I don't know why you'd trust the rest of the network to do your filtering for 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 Tue Nov 12 12:07:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACK7Ukd029611; Tue, 12 Nov 2002 12:07:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACK7U7b029610; Tue, 12 Nov 2002 12:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACK7Pkd029603 for ; Tue, 12 Nov 2002 12:07:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACK7YMq003611 for ; Tue, 12 Nov 2002 12:07:34 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA15801 for ; Tue, 12 Nov 2002 13:07:25 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACK5ql02748; Tue, 12 Nov 2002 15:05:52 -0500 (EST) Message-Id: <200211122005.gACK5ql02748@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Keith Moore , Margaret Wasserman , Michel Py , IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) In-reply-to: (Your message of "Tue, 12 Nov 2002 20:50:51 +0200.") Date: Tue, 12 Nov 2002 15:05:52 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > > I'm not sure what we gain by doing that, as opposed to setting aside > > > > > private address space from any global prefix by filtering it at > > > > > administrative boundaries... > > > > > > > > we need the ability to assign global prefixes to sites that aren't > > > > directly connected to the public Internet, even though they might > > > > be connected to large numbers of other networks. > > > > > > Allocating one /32 and giving these sites a /48 each should last for the > > > first 64k such private networks (which are assumed to be rather rare). > > > > they might be more plentiful than you think. [...] > > Well, personally, I can clearly see a few cases (e.g. in the military), > but the rest, I could separate to a few cases: > > 1) have IPv4 connectivity but no IPv6 (or stable IPv6 -- something like > 6to4 with dynamic v4 address) > > 2) have zero 'net connectivity ("clear cases") -- usually by design > > 3) have full connectivity but want somehow permanent addresses, to be used > locally, for renumbering, to be leaked to the internet, etc.etc. 4) have zero connectivity to the public internet (by choice) but have interconnections with an arbitrary number of other private networks (which might or might not have connectivity to the public internet). this is actually fairly common. we need to get away from the assumption that the reason that people use IP is to connect to the public Internet. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 12:09:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACK9Ekd029678; Tue, 12 Nov 2002 12:09:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACK9E1D029677; Tue, 12 Nov 2002 12:09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACK9Akd029667 for ; Tue, 12 Nov 2002 12:09:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACK9JMq004091 for ; Tue, 12 Nov 2002 12:09:19 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19919 for ; Tue, 12 Nov 2002 13:09:13 -0700 (MST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA13365 for ; Tue, 12 Nov 2002 15:09:13 -0500 (EST) Message-Id: <4.3.2.7.2.20021112150818.047aef18@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Nov 2002 15:09:09 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: Proposal for site-local clean-up In-Reply-To: <3DD0F9AC.FF821AAA@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 I support this suggested course of action and the proposed new text. - Ralph At 01:53 PM 11/12/2002 +0100, Brian E Carpenter wrote: >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, >in order to change the following paragraph in section 2.5.6: > >Current text: > > > Site-local addresses are designed to be used for addressing inside of > > a site without the need for a global prefix. Although a subnet ID > > may be up to 54-bits long, it is expected that globally-connected > > sites will use the same subnet IDs for site-local and global > > prefixes. > >Proposed new text: > > Site-local addresses are designed to be used for addressing inside of > a site which is not connected to the Internet and therefore does not > need a global prefix. They must not be used for a site that is connected > to the Internet. Using site-local addresses, a subnet ID may be up to > 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > for convenience if the site is later connected to the Internet using a > global prefix. > >Otherwise, we will need a whole new RFC just for this paragraph. > >Alternatively, we could spend the next 5 years discussing the >unnecessary complexities of using site-locals on connected sites. > > Brian >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 12:32:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACKWJkd000180; Tue, 12 Nov 2002 12:32:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACKWJYi000179; Tue, 12 Nov 2002 12:32:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACKWFkd000170 for ; Tue, 12 Nov 2002 12:32:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACKWObB026975 for ; Tue, 12 Nov 2002 12:32:24 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA28973 for ; Tue, 12 Nov 2002 13:32:17 -0700 (MST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 12 Nov 2002 12:32:16 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 12 Nov 2002 12:32:16 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 12 Nov 2002 12:32:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for site-local clean-up Date: Tue, 12 Nov 2002 12:32:08 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKKTV1DGuiF10PIQoydH6wcNfT2tQAMqe1g From: "Brian Zill" To: "Margaret Wasserman" , "Brian E Carpenter" Cc: X-OriginalArrivalTime: 12 Nov 2002 20:32:21.0473 (UTC) FILETIME=[9A112510:01C28A8A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gACKWGkd000171 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I strongly disagree with this suggestion. Site-local addresses (and more generally, scoped addresses) are a fundamental part of the IPv6 architecture. They are an important feature of IPv6, one of the great improvements that makes IPv6 better than IPv4. It would be a serious loss to IPv6 if site-local addresses were only allowed to be used on disconnected networks (not to mention a wholly unenforceable edict - I would rather we engineered things to work when people inevitably mixed global and site-local addresses on the same wire). Let's not throw out the baby with the bathwater. Margaret writes: > I would support this change. However, I doubt that we > will get consensus to make this change before the > addressing architecture is issued as an RFC. I think we just spent the last 500+ emails on this list proving that point. Why restart that argument? Just leave site-locals alone. > >Alternatively, we could spend the next 5 years > >discussing the unnecessary complexities of using > >site-locals on connected sites. Actually, I think most of the issues have already been resolved. How to use site-locals on connected sites (and on hosts connected to multiple sites), has been fairly well understood for several years now. I'm totally mystified as to where this opposition to site-locals is coming from. I understand that the human mind has a tendency to reject new concepts just because they are different (the classic not-invented-here syndrome), but surely this isn't that hard a concept to wrap one's mind around. Another way of looking at this is that site-local addresses have been part of all the standards-track documents for some time. It would seem to me that if there are people who want to change this at this late date, the onus falls on them to provide strong *technical* (not political) arguments as to why they won't work. Otherwise those of us who went to the trouble to create working implementations in good faith will have a hard time understanding the motives of those who now desire this restriction. --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 Nov 12 13:39:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACLdgkd000647; Tue, 12 Nov 2002 13:39:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACLdg8Y000646; Tue, 12 Nov 2002 13: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACLdckd000639 for ; Tue, 12 Nov 2002 13:39:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACLdlMq002115 for ; Tue, 12 Nov 2002 13:39:47 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05859 for ; Tue, 12 Nov 2002 14:39:39 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACLdUl03636; Tue, 12 Nov 2002 16:39:30 -0500 (EST) Message-Id: <200211122139.gACLdUl03636@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ralph Droms cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Tue, 12 Nov 2002 15:09:09 EST.") <4.3.2.7.2.20021112150818.047aef18@funnel.cisco.com> Date: Tue, 12 Nov 2002 16:39:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I support this text. should "must not" be in upper case? >Proposed new text: > > Site-local addresses are designed to be used for addressing inside of > a site which is not connected to the Internet and therefore does not > need a global prefix. They must not be used for a site that is connected > to the Internet. Using site-local addresses, a subnet ID may be up to > 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > for convenience if the site is later connected to the Internet using a > global prefix. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 13:43:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACLhlkd000686; Tue, 12 Nov 2002 13:43:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACLhl65000685; Tue, 12 Nov 2002 13:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACLhhkd000678 for ; Tue, 12 Nov 2002 13:43:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACLhqMq003270 for ; Tue, 12 Nov 2002 13:43:52 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA08413 for ; Tue, 12 Nov 2002 14:43:43 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACLhXl03654; Tue, 12 Nov 2002 16:43:33 -0500 (EST) Message-Id: <200211122143.gACLhXl03654@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Brian Zill" cc: "Margaret Wasserman" , "Brian E Carpenter" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Tue, 12 Nov 2002 12:32:08 PST.") Date: Tue, 12 Nov 2002 16:43:33 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Site-local addresses (and more generally, scoped addresses) are a > fundamental part of the IPv6 architecture. They are an important > feature of IPv6, one of the great improvements that makes IPv6 better > than IPv4. It would be a serious loss to IPv6 if site-local addresses > were only allowed to be used on disconnected networks (not to mention a > wholly unenforceable edict - I would rather we engineered things to work > when people inevitably mixed global and site-local addresses on the same > wire). This discussion has produced no technical justification for statements like the above, and plenty of reason to believe that SLs aren't worth their cost except for isolated networks. > Let's not throw out the baby with the bathwater. Agreed. But I think you're mixed up about which is the baby and which is the bathwater. Site-locals are the bathwater - they once were thought to be useful but now don't seem worth very much. Forcing the baby to stay in the bathwater isn't good for the baby's health. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 14:14:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACMEUkd000854; Tue, 12 Nov 2002 14:14:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACMEUC3000853; Tue, 12 Nov 2002 14:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACMEQkd000846 for ; Tue, 12 Nov 2002 14:14:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACMEZMq012182 for ; Tue, 12 Nov 2002 14:14:35 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16759 for ; Tue, 12 Nov 2002 15:14:29 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gACMEQKV020680; Tue, 12 Nov 2002 23:14:26 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 12 Nov 2002 23:14:26 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0CE8@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Brian Zill'" , Margaret Wasserman , Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: RE: Proposal for site-local clean-up Date: Tue, 12 Nov 2002 23:14:23 +0100 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 I don't really have a strong opinion one way or the other, but I would like to make the following observations: - "MUST NOTs" are there for a reason, saying MUST NOT when it can be done and protocols don't break is not a good idea. - People have shown that there are ways of using site-locals for single and multi-sited hosts today and making sure that apps don't break. We've also seen that this comes at a cost and complexity, but it is possible with today's standards. - Defaults for hosts and routers have been discussed and it looks like we have some pretty straight forward defaults to handle SLs (see Bob hinden's emails among the other thousand emails on this). Personally, I don't have a big problem with the suggestion itself, but I do not agree with it, simply because it's a meaningless restriction. I'd rather see a separate BCP for this, or at least say should not and explain why. Finally, I do hope to see the addrarch RFC in DS in my lifetime. Hesham PS: You know many designs are not perfect the first time around and band aids are often needed later. In this case the problem is not that big. IMHO changing fundamental RFCs when people are shipping products is worse than having a band aid for SLs. Please, let's move on and get a BCP. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 14:49:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACMngkd001052; Tue, 12 Nov 2002 14:49:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACMnguq001051; Tue, 12 Nov 2002 14:49: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACMndkd001044 for ; Tue, 12 Nov 2002 14:49:39 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACMnmMq022180 for ; Tue, 12 Nov 2002 14:49:48 -0800 (PST) Received: from mail.nosense.org (234.cust2.nsw.dsl.ozemail.com.au [203.103.157.234]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00235 for ; Tue, 12 Nov 2002 14:49:42 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 9E7963B368 for ; Wed, 13 Nov 2002 09:49:41 +1100 (EST) Subject: Re: Proposal for site-local clean-up From: Mark Smith To: ipng@sunroof.eng.sun.com In-Reply-To: <4.3.2.7.2.20021112150818.047aef18@funnel.cisco.com> References: <4.3.2.7.2.20021112150818.047aef18@funnel.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 13 Nov 2002 09:49:41 +1100 Message-Id: <1037141381.12933.1.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I support this change and the new text. Mark. > At 01:53 PM 11/12/2002 +0100, Brian E Carpenter wrote: > >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, > >in order to change the following paragraph in section 2.5.6: > > > >Current text: > > > > > Site-local addresses are designed to be used for addressing inside of > > > a site without the need for a global prefix. Although a subnet ID > > > may be up to 54-bits long, it is expected that globally-connected > > > sites will use the same subnet IDs for site-local and global > > > prefixes. > > > >Proposed new text: > > > > Site-local addresses are designed to be used for addressing inside of > > a site which is not connected to the Internet and therefore does not > > need a global prefix. They must not be used for a site that is connected > > to the Internet. Using site-local addresses, a subnet ID may be up to > > 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > > for convenience if the site is later connected to the Internet using a > > global prefix. > > > >Otherwise, we will need a whole new RFC just for this paragraph. > > > >Alternatively, we could spend the next 5 years discussing the > >unnecessary complexities of using site-locals on connected sites. > > > > Brian > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 14:56:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACMuvkd001102; Tue, 12 Nov 2002 14:56:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACMuvKK001101; Tue, 12 Nov 2002 14:56:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACMurkd001094 for ; Tue, 12 Nov 2002 14:56:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACMv2bB008480 for ; Tue, 12 Nov 2002 14:57:02 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20485 for ; Tue, 12 Nov 2002 15:56:55 -0700 (MST) Subject: RE: Address allocation schemes (Re: Naming and site-local) MIME-Version: 1.0 Date: Tue, 12 Nov 2002 14:57:27 -0800 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E454@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Address allocation schemes (Re: Naming and site-local) Thread-Index: AcKKnZJjfisnzNMySgSXFRlFk5NYzQAAB1qQ From: "Michel Py" To: "Margaret Wasserman" Cc: "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gACMuskd001095 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > But, why make them inherently private, non-routable > addresses? If we come up with a reasonable way to > allocate globally-unique, provider-independent > addresses, is there a reason to require that they > be non-globally-routable? Network administrators want private (read: not publicly routable) addresses. Telling them that they are full of it is not going to change this, and if they don't have them what you will get instead of well-known-private is guess-what-I-hijacked private. Take your pick. > There is some work underway in multi6 regarding > mechanisms for provider-independent allocation > of globally routable addresses. Wouldn't that be > better? There is no work currently underway in multi6. Multi6 is not chartered to develop solutions. 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 Nov 12 15:37:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACNbZkd001651; Tue, 12 Nov 2002 15:37:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACNbYkU001650; Tue, 12 Nov 2002 15:37:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACNbRkd001629 for ; Tue, 12 Nov 2002 15:37:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACNbaMq007701 for ; Tue, 12 Nov 2002 15:37:36 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09604 for ; Tue, 12 Nov 2002 16:37:30 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gACNbNl04338; Tue, 12 Nov 2002 18:37:23 -0500 (EST) Message-Id: <200211122337.gACNbNl04338@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (EAB)" cc: "'Brian Zill'" , Margaret Wasserman , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Tue, 12 Nov 2002 23:14:23 +0100.") <4DA6EA82906FD511BE2F00508BCF0538044F0CE8@Esealnt861.al.sw.ericsson.se> Date: Tue, 12 Nov 2002 18:37:23 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't really have a strong opinion one way > or the other, but I would like to make the following > observations: > > - "MUST NOTs" are there for a reason, saying MUST NOT > when it can be done and protocols don't break is not > a good idea. perhaps not, but protocols DO break when we subject them to SLs. changing those protocols is nontrivial, and they will still break after such changes, just not as often. (they'll also be less efficient) > - People have shown that there are ways of using > site-locals for single and multi-sited hosts today and > making sure that apps don't break. actually, no. people have shown that there are ways of using SLs for some apps in such situations. nobody has come up with a general solution that requires less than either: - expecting all non-isolated networks to provide global addresses (and having apps ignore SLs in the presence of globals), or - expecting apps to do their own addressing and routing. > Personally, I don't have a big problem with the suggestion > itself, but I do not agree with it, simply because > it's a meaningless restriction. I have a hard time understanding how a simple restriction that allows apps to work is meaningless. > PS: You know many designs are not perfect the first > time around and band aids are often needed later. > In this case the problem is not that big. Yes, it's a simple problem to fix. The fix is just to discourage use of SLs except in disconnected networks. Any other "fix" places more burden on networks or applications or both, and this does create a "big" problem. > IMHO > changing fundamental RFCs when people are shipping > products is worse than having a band aid for SLs. What you seem to favor seems more like a tourniquet than a band aid. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 15:41:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACNf6kd001707; Tue, 12 Nov 2002 15:41:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACNf6wc001706; Tue, 12 Nov 2002 15:41:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACNf3kd001699 for ; Tue, 12 Nov 2002 15:41:03 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACNfBMq008732 for ; Tue, 12 Nov 2002 15:41:12 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11514 for ; Tue, 12 Nov 2002 16:41:06 -0700 (MST) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18BkeX-000EEj-00; Tue, 12 Nov 2002 15:41:05 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up Message-Id: Date: Tue, 12 Nov 2002 15:41:05 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 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, > in order to change the following paragraph in section 2.5.6: > > Current text: > >> Site-local addresses are designed to be used for addressing inside of >> a site without the need for a global prefix. Although a subnet ID >> may be up to 54-bits long, it is expected that globally-connected >> sites will use the same subnet IDs for site-local and global >> prefixes. > > Proposed new text: > > Site-local addresses are designed to be used for addressing inside of > a site which is not connected to the Internet and therefore does not > need a global prefix. They must not be used for a site that is connected > to the Internet. Using site-local addresses, a subnet ID may be up to > 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > for convenience if the site is later connected to the Internet using a > global prefix. > > Otherwise, we will need a whole new RFC just for this paragraph. > > Alternatively, we could spend the next 5 years discussing the > unnecessary complexities of using site-locals on connected sites. i will not make sarcastic remarks. i will not make sarcastic remarks. i will not make sarcastic remarks. i will not make sarcastic remarks. i will not make sarcastic remarks. i will not make sarcastic remarks. i will not make sarcastic remarks. :-) if there is real consensus on this, processwise it could be done with a note to the rfc editor or in the 48 hour edit call as s/he is doing the final edits. 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 Nov 12 15:43:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACNhbkd001766; Tue, 12 Nov 2002 15:43:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACNhbLc001765; Tue, 12 Nov 2002 15:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACNhYkd001755 for ; Tue, 12 Nov 2002 15:43:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACNhhMq009580 for ; Tue, 12 Nov 2002 15:43:43 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28287 for ; Tue, 12 Nov 2002 16:43:37 -0700 (MST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 262D418E3 for ; Tue, 12 Nov 2002 18:43:36 -0500 (EST) Date: Tue, 12 Nov 2002 18:43:36 -0500 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-Reply-To: <1037141381.12933.1.camel@dupy> References: <4.3.2.7.2.20021112150818.047aef18@funnel.cisco.com> <1037141381.12933.1.camel@dupy> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20021112234336.262D418E3@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What Brian C., Margaret, Brian H., Pekka, Mike, Jim, Alain, Ralph, Keith, and Mark said, but not what Brian Z. said :). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 15:50:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACNoekd001943; Tue, 12 Nov 2002 15:50:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gACNoeKR001942; Tue, 12 Nov 2002 15:50: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gACNobkd001930 for ; Tue, 12 Nov 2002 15:50:37 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gACNojbB024621 for ; Tue, 12 Nov 2002 15:50:45 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04681 for ; Tue, 12 Nov 2002 15:50:40 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Bkno-000EUA-00; Tue, 12 Nov 2002 15:50:40 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Rob Austein Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up References: <4.3.2.7.2.20021112150818.047aef18@funnel.cisco.com> <1037141381.12933.1.camel@dupy> <20021112234336.262D418E3@thrintun.hactrn.net> Message-Id: Date: Tue, 12 Nov 2002 15:50:40 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What Brian C., Margaret, Brian H., Pekka, Mike, Jim, Alain, Ralph, > Keith, and Mark said, but not what Brian Z. said :). what he said -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 16:07:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD070kd002247; Tue, 12 Nov 2002 16:07:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD070CF002246; Tue, 12 Nov 2002 16:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD06ukd002239 for ; Tue, 12 Nov 2002 16:06:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD075Mq017459 for ; Tue, 12 Nov 2002 16:07:05 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA29783 for ; Tue, 12 Nov 2002 17:06:58 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAD06pl04501; Tue, 12 Nov 2002 19:06:51 -0500 (EST) Message-Id: <200211130006.gAD06pl04501@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Margaret Wasserman" , "IPng" Subject: Re: Address allocation schemes (Re: Naming and site-local) In-reply-to: (Your message of "Tue, 12 Nov 2002 14:57:27 PST.") <2B81403386729140A3A899A8B39B046405E454@server2000> Date: Tue, 12 Nov 2002 19:06:51 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Network administrators want private (read: not publicly routable) > addresses. a) they are not the same thing b) I also maintain that this is not really what network administrators want. they may equate what they want to this, but see a. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 16:08:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD08okd002273; Tue, 12 Nov 2002 16:08:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD08o3k002272; Tue, 12 Nov 2002 16:08:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD08kkd002262 for ; Tue, 12 Nov 2002 16:08:46 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD08tbB000520 for ; Tue, 12 Nov 2002 16:08:55 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11677 for ; Tue, 12 Nov 2002 17:08:49 -0700 (MST) Subject: RE: Proposal for site-local clean-up MIME-Version: 1.0 Date: Tue, 12 Nov 2002 16:09:23 -0800 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E456@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKKpdBGwuTxEUS2SV2CjfnM4HxwHAAAlddQ From: "Michel Py" To: "Randy Bush" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAD08kkd002263 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Randy Bush wrote: > processwise it could be done with a note to the rfc > editor or in the 48 hour edit call as s/he is doing > the final edits. Processwise a recall from the RFC editor could also be challenged all the way to the IAB or even the ISOC and lead us to 1000+ more emails up front and 10000 more before all the appeal processes have been exhausted. Is this the road we are taking? 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 Nov 12 16:23:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD0NDkd002488; Tue, 12 Nov 2002 16:23:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD0ND2F002487; Tue, 12 Nov 2002 16:23:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD0NAkd002480 for ; Tue, 12 Nov 2002 16:23:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD0NJMq022416 for ; Tue, 12 Nov 2002 16:23:19 -0800 (PST) Received: from spoon.alink.net (spoon.sv-server1.alink.net [207.135.64.249]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA08359 for ; Tue, 12 Nov 2002 17:23:13 -0700 (MST) Received: from iniche.com (host26.iniche.com [207.135.74.26]) by spoon.alink.net (8.9.3/8.9.3) with ESMTP id QAA19926; Tue, 12 Nov 2002 16:23:02 -0800 (PST) Message-ID: <3DD19D8D.971F28AA@iniche.com> Date: Tue, 12 Nov 2002 16:32:13 -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: Michel Py CC: Margaret Wasserman , IPng Subject: Re: Address allocation schemes (Re: Naming and site-local) References: <2B81403386729140A3A899A8B39B046405E454@server2000> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, Maybe, but I think most Network administrators understand that using guess-what-I-hijacked addresses is risky. Instead I bet you'll see them rolling their own NATv6 solutions. It's lot easier for us v4-ish old-timers to understand than some of what I've read here today :-) -JB- Michel Py wrote: > > Margaret, > > > But, why make them inherently private, non-routable > > addresses? If we come up with a reasonable way to > > allocate globally-unique, provider-independent > > addresses, is there a reason to require that they > > be non-globally-routable? > > Network administrators want private (read: not publicly routable) > addresses. Telling them that they are full of it is not going to change > this, and if they don't have them what you will get instead of > well-known-private is guess-what-I-hijacked private. Take your pick. > > > There is some work underway in multi6 regarding > > mechanisms for provider-independent allocation > > of globally routable addresses. Wouldn't that be > > better? > > There is no work currently underway in multi6. Multi6 is not chartered > to develop solutions. > > 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 > -------------------------------------------------------------------- -- -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 Tue Nov 12 16:39:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD0dAkd002598; Tue, 12 Nov 2002 16:39:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD0d9oi002597; Tue, 12 Nov 2002 16:39:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD0d5kd002587 for ; Tue, 12 Nov 2002 16:39:05 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD0dEbB008993 for ; Tue, 12 Nov 2002 16:39:14 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00878 for ; Tue, 12 Nov 2002 16:39:08 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8E2AC4B23; Wed, 13 Nov 2002 09:39:06 +0900 (JST) To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com In-reply-to: brian's message of Tue, 12 Nov 2002 13:53:00 +0100. <3DD0F9AC.FF821AAA@hursley.ibm.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: Proposal for site-local clean-up From: itojun@iijlab.net Date: Wed, 13 Nov 2002 09:39:06 +0900 Message-Id: <20021113003906.8E2AC4B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >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, >in order to change the following paragraph in section 2.5.6: > >Current text: > >> Site-local addresses are designed to be used for addressing inside of >> a site without the need for a global prefix. Although a subnet ID >> may be up to 54-bits long, it is expected that globally-connected >> sites will use the same subnet IDs for site-local and global >> prefixes. > >Proposed new text: > > Site-local addresses are designed to be used for addressing inside of > a site which is not connected to the Internet and therefore does not > need a global prefix. They must not be used for a site that is connected > to the Internet. Using site-local addresses, a subnet ID may be up to > 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > for convenience if the site is later connected to the Internet using a > global prefix. i'm happy with the change. 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 Nov 12 16:48:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD0mZkd002676; Tue, 12 Nov 2002 16:48:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD0mZUT002675; Tue, 12 Nov 2002 16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD0mWkd002668 for ; Tue, 12 Nov 2002 16:48:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD0meMq029767 for ; Tue, 12 Nov 2002 16:48:41 -0800 (PST) Received: from spoon.alink.net (spoon.sv-server1.alink.net [207.135.64.249]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29175 for ; Tue, 12 Nov 2002 17:48:35 -0700 (MST) Received: from iniche.com (host26.iniche.com [207.135.74.26]) by spoon.alink.net (8.9.3/8.9.3) with ESMTP id QAA27898; Tue, 12 Nov 2002 16:48:31 -0800 (PST) Message-ID: <3DD1A387.F0CDED12@iniche.com> Date: Tue, 12 Nov 2002 16:57:43 -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: Randy Bush CC: Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up References: <4.3.2.7.2.20021112150818.047aef18@funnel.cisco.com> <1037141381.12933.1.camel@dupy> <20021112234336.262D418E3@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, What they said. I mean, I support Brian's wording change in the RFC. Being a newbie on this list I probably shouldn't get a vote, but being a newbie I may have a new perspective. A lot of the networking world sees IPv6 as still thrashing and not ready for prime time. A year ago I read RFC-3056 (good work, Brian), and concluded that it may be be time for my company to devote resources to it. We have, and it's been a learning experience. Personally I'm not thrilled about the idea of SL addresses. They seem to wrap the IPv6 design around "corporate campus" type networks as they existed in the mid 1990s, and thus handicap IPv6's ability to adapt to future hierarchy evolution as well as v4 did. However making a change so severe as to require re-coding IPv6 stacks (which seems to be where some of the proposals could end up) will hurt IPv6's market credibility more than it will help anything. Brian C.'s change would not require recoding our stack (nor I think most others), but it does clear up some of the ambiguity around SL addresses that I had after first reading the RFC. That seems like the best we can hope for. As Brian Z. pointed out, I'd be a bit miffed if the stack we just got done writing (to be RFC compliant) required a change of this sort before we even get it out of Beta. Maybe a good Mantra for this group to get IPv6 accepted widely would be: "If it ain't fatal, don't fix it". -JB- (BTW, Hi Rob!) Randy Bush wrote: > > > What Brian C., Margaret, Brian H., Pekka, Mike, Jim, Alain, Ralph, > > Keith, and Mark said, but not what Brian Z. said :). > > what he said > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Tue Nov 12 16:58:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD0w6kd002781; Tue, 12 Nov 2002 16:58:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD0w6Ev002780; Tue, 12 Nov 2002 16:58:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD0w3kd002773 for ; Tue, 12 Nov 2002 16:58:03 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD0wBbB014010 for ; Tue, 12 Nov 2002 16:58:11 -0800 (PST) Received: from TNEXVS01.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03645 for ; Tue, 12 Nov 2002 17:58:06 -0700 (MST) Received: from TNEXVS02.tahoenetworks.com ([10.10.1.132]) by TNEXVS01.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Nov 2002 16:58:05 -0800 content-class: urn:content-classes:message Subject: RE: Proposal for site-local clean-up MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 12 Nov 2002 16:58:05 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6EAB6E2F@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKKmq3HsJxY2CbfQLCMR6RCOoMLigAFIU2w From: "Mohan Parthasarathy" To: "Hesham Soliman (EAB)" , "Brian Zill" , "Margaret Wasserman" , "Brian E Carpenter" Cc: X-OriginalArrivalTime: 13 Nov 2002 00:58:05.0862 (UTC) FILETIME=[B9A9D460:01C28AAF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAD0w3kd002774 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Personally, I don't have a big problem with the suggestion > itself, but I do not agree with it, simply because it's a > meaningless restriction. I'd rather see a > separate BCP for this, or at least say should not and > explain why. > I agree with Hesham here. Should we not explain why we are taking this stance instead of just saying MUST NOT ? It might prevent another 500+ emails in the future. My 2 cents mohan > Finally, I do hope to see the addrarch RFC in DS in my > lifetime. > > Hesham > > PS: You know many designs are not perfect the first > time around and band aids are often needed later. > In this case the problem is not that big. IMHO > changing fundamental RFCs when people are shipping > products is worse than having a band aid for SLs. > Please, let's move on and get a BCP. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 12 17:04:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD14Ykd002856; Tue, 12 Nov 2002 17:04:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD14YhZ002855; Tue, 12 Nov 2002 17:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD14Vkd002848 for ; Tue, 12 Nov 2002 17:04:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD14dbB015708 for ; Tue, 12 Nov 2002 17:04:40 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA28784 for ; Tue, 12 Nov 2002 18:04:28 -0700 (MST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gAD14EaE010201; Tue, 12 Nov 2002 17:04:14 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAP05266; Tue, 12 Nov 2002 16:58:41 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA15305; Tue, 12 Nov 2002 17:04:24 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15825.42263.878673.253772@thomasm-u1.cisco.com> Date: Tue, 12 Nov 2002 17:04:23 -0800 (PST) To: "Mohan Parthasarathy" Cc: "Hesham Soliman (EAB)" , "Brian Zill" , "Margaret Wasserman" , "Brian E Carpenter" , Subject: RE: Proposal for site-local clean-up In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6EAB6E2F@TNEXVS02.tahoenetworks.com> References: <416B5AF360DED54088DAD3CA8BFBEA6EAB6E2F@TNEXVS02.tahoenetworks.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 Mohan Parthasarathy writes: > > > > > Personally, I don't have a big problem with the suggestion > > itself, but I do not agree with it, simply because it's a > > meaningless restriction. I'd rather see a > > separate BCP for this, or at least say should not and > > explain why. > > > I agree with Hesham here. Should we not explain why we are taking this > stance instead of just saying MUST NOT ? It might prevent another 500+ > emails > in the future. Doubtful. Trying to capture those 500+ emails worth of justificatin sounds doomed to failure. Brian's simple modification leaves everybody convinced that it was their own nuace on the justification that put it over the top. So much the better. 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 Nov 12 17:39:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD1dukd003178; Tue, 12 Nov 2002 17:39:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD1duAd003177; Tue, 12 Nov 2002 17:39: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD1dqkd003170 for ; Tue, 12 Nov 2002 17:39:52 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD1e1bB024199 for ; Tue, 12 Nov 2002 17:40:01 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02772 for ; Tue, 12 Nov 2002 17:39:56 -0800 (PST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 12 Nov 2002 17:39:58 -0800 Reply-To: From: "Tony Hain" To: "'Bound, Jim'" , "'Alain Durand'" , "'Brian E Carpenter'" Cc: Subject: RE: Proposal for site-local clean-up Date: Tue, 12 Nov 2002 17:39:45 -0800 Message-ID: <079d01c28ab5$8c262920$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9A6A@tayexc13.americas.cpqcorp.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAD1drkd003171 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Turn your back to cover day-job issues for a couple of days, and all hell breaks loose.... There is absolutely no reason to restrict SL to disconnected sites. If someone wants to write an RFC on why they increase complexity for multi-party apps, fine. That does not mean we need to significantly change the architecture at the last minute, basically without serious review and commentary. If that happens, expect a process appeal. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Bound, Jim > Sent: Tuesday, November 12, 2002 11:59 AM > To: Alain Durand; Brian E Carpenter > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Proposal for site-local clean-up > > > OK folks I am counting and I see clear majority for margarets > proposal? > > /jim > [In matters of style, swim with the currents....in matters of > principle, stand like a rock. - Thomas Jefferson] > > > > -----Original Message----- > > From: Alain Durand [mailto:Alain.Durand@Sun.COM] > > Sent: Tuesday, November 12, 2002 1:50 PM > > To: Brian E Carpenter > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: Proposal for site-local clean-up > > > > > > > > > > Brian E Carpenter wrote: > > > > >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, in order to > > >change the following paragraph in section 2.5.6: > > > > > [...] > > > > >Alternatively, we could spend the next 5 years discussing the > > >unnecessary complexities of using site-locals on connected sites. > > > > > > Brian > > > > > > > As I would like to see IPv6 deployed in my lifetime, > > I support proposal like this one that makes life simpler. > > > > It's time to move on, unless the volume of discussion/rat > > holing on this topic will really become a DOS attack on the > > mailling list, or worse, on IPv6 itself. > > > > - 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 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 12 17:48:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD1mnkd003254; Tue, 12 Nov 2002 17:48:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD1mneY003253; Tue, 12 Nov 2002 17:48:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD1mjkd003246 for ; Tue, 12 Nov 2002 17:48:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD1msbB026301 for ; Tue, 12 Nov 2002 17:48:54 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19682 for ; Tue, 12 Nov 2002 18:48:47 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAD1mcl05011; Tue, 12 Nov 2002 20:48:40 -0500 (EST) Message-Id: <200211130148.gAD1mcl05011@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Bound, Jim'" , "'Alain Durand'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Tue, 12 Nov 2002 17:39:45 PST.") <079d01c28ab5$8c262920$bd134104@eagleswings> X-SUBJECT-MSG-FROM: "Tony Hain" Date: Tue, 12 Nov 2002 20:48:38 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is absolutely no reason to restrict SL to disconnected sites. Tony, we've been discussing the reasons for weeks now. It's pretty disingeneous to say 'absolutely no reason' in the face of this. Face it, SLs as originally conceived are broken. This is the simplest fix. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 17:55:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD1tkkd003570; Tue, 12 Nov 2002 17:55:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD1tjg8003568; Tue, 12 Nov 2002 17:55:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD1tdkd003534 for ; Tue, 12 Nov 2002 17:55:39 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD1tmMq016507 for ; Tue, 12 Nov 2002 17:55:48 -0800 (PST) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06403; Tue, 12 Nov 2002 17:55:42 -0800 (PST) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id gAD1tivm022601; Tue, 12 Nov 2002 17:55:44 -0800 (PST) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id gAD1ti0P022600; Tue, 12 Nov 2002 17:55:44 -0800 (PST) Date: Tue, 12 Nov 2002 17:55:44 -0800 From: Shannon -jj Behrens To: "Bound, Jim" Cc: Alain Durand , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up Message-ID: <20021113015544.GC21798@alicia.nttmcl.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9A6A@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9A6A@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I haven't caught up with the whole thread (as can well be imagined), but I agree as well. -jj On Tue, Nov 12, 2002 at 02:58:42PM -0500, Bound, Jim wrote: > OK folks I am counting and I see clear majority for margarets proposal? > > /jim > [In matters of style, swim with the currents....in matters of principle, > stand like a rock. - Thomas Jefferson] > > > > -----Original Message----- > > From: Alain Durand [mailto:Alain.Durand@Sun.COM] > > Sent: Tuesday, November 12, 2002 1:50 PM > > To: Brian E Carpenter > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: Proposal for site-local clean-up > > > > > > > > > > Brian E Carpenter wrote: > > > > >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, in order to > > >change the following paragraph in section 2.5.6: > > > > > [...] > > > > >Alternatively, we could spend the next 5 years discussing the > > >unnecessary complexities of using site-locals on connected sites. > > > > > > Brian > > > > > > > As I would like to see IPv6 deployed in my lifetime, > > I support proposal like this one that makes life simpler. > > > > It's time to move on, unless the volume of discussion/rat > > holing on this topic will really become a DOS attack on the > > mailling list, or worse, on IPv6 itself. > > > > - 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 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- def qsort(l): # Purely functional implementation of QSort in Python. if not len(l): return [] return (qsort([i for i in l[1:] if i < l[0]]) + [l[0]] + qsort([i for i in l[1:] if i >= l[0]])) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 18:00:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD20kkd004589; Tue, 12 Nov 2002 18:00:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD20k82004585; Tue, 12 Nov 2002 18:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD20dkd004550 for ; Tue, 12 Nov 2002 18:00:39 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD20mMq018614 for ; Tue, 12 Nov 2002 18:00:48 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12303 for ; Tue, 12 Nov 2002 18:00:43 -0800 (PST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 12 Nov 2002 18:00:46 -0800 Reply-To: From: "Tony Hain" To: "'Michael Thomas'" , "'Keith Moore'" Cc: , Subject: RE: Address selection and site local addresses Date: Tue, 12 Nov 2002 18:00:34 -0800 Message-ID: <079e01c28ab8$7419f930$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <15825.14938.905921.353855@thomasm-u1.cisco.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAD20ekd004551 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > Keith Moore writes: > > > What I want to know is why the concept "local" in > > > the absense of enforceability (cf strong auth) > > > isn't a thoroughly bogus concept. > > > > for the purpose of security, in any network of significant > size, > it certainly is. > > > if site-locals are useful at all it is not because of security. > > Well then, I guess I'm at a loss about why people would > want to use site-locals for local services. If it's not > for the possibility of access control, then what else > is it? > 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. What some on the list are having a hard time with is the concept that it can be challenging to explicitly list every device that is not allowed access from the public Internet when networks get to be large. This problem gets even more complex when the nodes start moving around. For the network manager, having a clean filter for FEC0/16 allows random internal use addressing without concern that those systems will be visible from the public side. One might argue that for router requirements, there should be a MUST NOT propegate the SL prefix into BGP. At a very minimum this should cause an 'are you sure' message. 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 Nov 12 18:11:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD2B5kd005561; Tue, 12 Nov 2002 18:11:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD2B22V005560; Tue, 12 Nov 2002 18:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD2Awkd005553 for ; Tue, 12 Nov 2002 18:10:58 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD2B7bB003218 for ; Tue, 12 Nov 2002 18:11:07 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17472 for ; Tue, 12 Nov 2002 18:11:02 -0800 (PST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 12 Nov 2002 18:11:05 -0800 Reply-To: From: "Tony Hain" To: "'Keith Moore'" Cc: "'Bound, Jim'" , "'Alain Durand'" , "'Brian E Carpenter'" , Subject: RE: Proposal for site-local clean-up Date: Tue, 12 Nov 2002 18:10:51 -0800 Message-ID: <079f01c28ab9$e4d6f230$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211130148.gAD1mcl05011@astro.cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAD2Axkd005554 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > There is absolutely no reason to restrict SL to disconnected sites. > > Tony, we've been discussing the reasons for weeks now. It's > pretty disingeneous to say 'absolutely no reason' in the face of this. > > Face it, SLs as originally conceived are broken. This is the > simplest fix. > No, there has been a refusal to accept that the problems raised are bogus in all but the multi-party app case. This is the only reason the discussion has lasted this long. The fundemental issue here the architecture has been changed to support multiple simultanious scopes. Those that are having a hard time figuring out how to do that are opposed to SL, because that address range exposes the issue. This is a new environment where we will be able to develop apps that were not possible in the single-scope environment of IPv4. Rather than close that off because it is not easy to grasp, document the case of multi-party app issues and lets move on. Again, if the wording is changed to make a significant architectural change during the RFC editor process, expect an appeal. 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 Nov 12 18:13:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD2DWkd005637; Tue, 12 Nov 2002 18:13:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD2DWFW005636; Tue, 12 Nov 2002 18:13: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD2DRkd005629 for ; Tue, 12 Nov 2002 18:13:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD2DZbB003742 for ; Tue, 12 Nov 2002 18:13:36 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07500 for ; Tue, 12 Nov 2002 19:13:30 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAD2DJl05151; Tue, 12 Nov 2002 21:13:19 -0500 (EST) Message-Id: <200211130213.gAD2DJl05151@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Michael Thomas'" , "'Keith Moore'" , awhite@arc.corp.mot.com, ipng@sunroof.eng.sun.com Subject: Re: Address selection and site local addresses In-reply-to: (Your message of "Tue, 12 Nov 2002 18:00:34 PST.") <079e01c28ab8$7419f930$bd134104@eagleswings> Date: Tue, 12 Nov 2002 21:13:19 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Access control is one aspect of what SL provides. SL provides no benefits for access control that is not provided by the ability to filter globals, and you need to do this anyway. > and enterprise > managers can filter without having to go into detail about which > specific devices on a subnet are allowed in or not. SLs don't help you filter on a subnet basis - because they don't give you any granularity beyond a 'site'. If you want to filter on a subnet basis you are back to explicit prefix matching. *Of course* it can be a pain to manage filters for specific devices. But this is every bit as much a pain with SLs as it is with globals. SLs are orthogonal to this issue. (and no, it's not acceptable to hand out globals and SLs to some devices on a network and only SLs to others - both because this breaks apps, and because it has security holes.) > What some on the list are having a hard time with is the concept that it > can be challenging to explicitly list every device that is not allowed > access from the public Internet when networks get to be large. What some on this list are having a hard time figuring out is that SLs don't help you with this problem. > One might argue that for router requirements, there should be a MUST NOT > propegate the SL prefix into BGP. At a very minimum this should cause an > 'are you sure' message. One might argue that for application requirements, there should be a MUST NOT mix SLs and globals on the same network. At the very minimum the application should display a warning message that the network is misconfigured. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 18:27:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD2Rokd007735; Tue, 12 Nov 2002 18:27:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD2RoqK007734; Tue, 12 Nov 2002 18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD2Rjkd007721 for ; Tue, 12 Nov 2002 18:27:45 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD2RsMq001034 for ; Tue, 12 Nov 2002 18:27:54 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25239 for ; Tue, 12 Nov 2002 18:27:49 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAD2Ril05178; Tue, 12 Nov 2002 21:27:44 -0500 (EST) Message-Id: <200211130227.gAD2Ril05178@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Keith Moore'" , "'Bound, Jim'" , "'Alain Durand'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Tue, 12 Nov 2002 18:10:51 PST.") <079f01c28ab9$e4d6f230$bd134104@eagleswings> Date: Tue, 12 Nov 2002 21:27:44 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The fundemental issue here the architecture has been changed to support > multiple simultanious scopes. And it was taken too far before the consequences were understood. Now we're fixing this bug, and it's about time. > Those that are having a hard time figuring > out how to do that are opposed to SL There is no difficulty in figuring out what to do. We've figured it out already. There is a simple fix with few drawbacks and there are unacceptably complex fixes with numerous drawbacks. It's a no-brainer. > This is a new environment where we will be able to develop > apps that were not possible in the single-scope environment of IPv4. No. Scopes reduce the ablity of the network to support apps. They make it harder to produce an app that works independently of network location, and they don't add a single extra capability that wasn't present already. Why in the world you should be trying to promote dysfunction in the network is beyond me. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 19:08:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD38qkd009999; Tue, 12 Nov 2002 19:08:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD38q3L009998; Tue, 12 Nov 2002 19:08: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD38mkd009991 for ; Tue, 12 Nov 2002 19:08:49 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD38vbB018169 for ; Tue, 12 Nov 2002 19:08:58 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13639 for ; Tue, 12 Nov 2002 19:08:52 -0800 (PST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 12 Nov 2002 19:08:55 -0800 Reply-To: From: "Tony Hain" To: Cc: "'Bound, Jim'" , "'Alain Durand'" , "'Brian E Carpenter'" , Subject: RE: Proposal for site-local clean-up Date: Tue, 12 Nov 2002 19:08:41 -0800 Message-ID: <07a001c28ac1$f8d89560$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211130227.gAD2Ril05178@astro.cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAD38nkd009992 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > Why in the world you should be trying to promote dysfunction in the > network is beyond me. I am not promoting dysfunction, that will happen for operational / policy reasons. I am trying to make sure that when it does happen, there is a clearly understood mechanism for identifying 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 Tue Nov 12 19:41:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD3fVkd010981; Tue, 12 Nov 2002 19:41:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD3fVn9010980; Tue, 12 Nov 2002 19:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD3fRkd010973 for ; Tue, 12 Nov 2002 19:41:27 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD3fabB023879 for ; Tue, 12 Nov 2002 19:41:36 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26848 for ; Tue, 12 Nov 2002 19:41:30 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAD3fNl05303; Tue, 12 Nov 2002 22:41:26 -0500 (EST) Message-Id: <200211130341.gAD3fNl05303@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, "'Bound, Jim'" , "'Alain Durand'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Tue, 12 Nov 2002 19:08:41 PST.") <07a001c28ac1$f8d89560$bd134104@eagleswings> Date: Tue, 12 Nov 2002 22:41:23 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Why in the world you should be trying to promote dysfunction in the > > network is beyond me. > > I am not promoting dysfunction, that will happen for operational / > policy reasons. I am trying to make sure that when it does happen, > there is a clearly understood mechanism for identifying it. I don't see how SLs give you that. The existence of SLs will not obviate the need for other filtering in the network, simply because they are too inflexible to serve a significant fraction of filtering needs. There is the risk that they will weaken security by encouraging over-reliance on a mechanism that is too inflexible for real-world use. And SLs cannot reliably tell apps whether traffic can get from point A to point B. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 12 20:28:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD4Spkd011203; Tue, 12 Nov 2002 20:28:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD4SpVK011202; Tue, 12 Nov 2002 20:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD4Smkd011194 for ; Tue, 12 Nov 2002 20:28:48 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD4SvMq023551 for ; Tue, 12 Nov 2002 20:28:57 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14876 for ; Tue, 12 Nov 2002 20:28:51 -0800 (PST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id XAA24301; Tue, 12 Nov 2002 23:28:47 -0500 (EST) Date: Tue, 12 Nov 2002 23:28:47 -0500 (EST) From: Dan Lanciani Message-Id: <200211130428.XAA24301@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Address allocation schemes (Re: Naming and site-local) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Harald Tveit Alvestrand wrote: |--On søndag, november 10, 2002 15:25:56 -0500 Dan Lanciani | wrote: | |> As long as we are stuck with a totally non-scalable address allocation |> system (remember, provider-based aggregated addressing consumes address |> space *exponentially* in the number of providers in the service chain) |> end users need some way to provision local systems with stable addresses. |> So far, nobody has proposed a viable alternative to scoped addresses. | |metro addressing? Perhaps. I'd have to hear the details (in particular the costs). |btw, my current naive prediction of the way the Internet will evolve is |that unless new invention occurs, the default-free zone will eventually be |flat-routing on the number of ISPs in the world, and that this number will |have 5 digits. Sadly, I think that you are correct, at least to a first approximation. There will probably also be a few routes for companies big enough to demand and get true single-prefix multi-homing (though I guess they could just declare that they are ISPs). The rest of us will have to make do without such luxuries. I suspect that arguments similar to those against application support for site-locals will render multi-prefix multi-homing less than wonderful. |stable addresses for the lifetime of your ISP service contract seems like a |not too terrible deal, It's certainly not as good a deal as provider-independent addresses. The extent to which the deal is not too terrible would depend on how much you have to pay for the privilege. |if renumbering is easy. easy for the customer as opposed to easy for the ISP... Michael Thomas wrote: |Harald, | |I think this probably boils down to something |completely non-technical: do people view IP |addresses as "addresses" ala street addresses, |etc, or do they view them as possessions like |(now) phone numbers and email addresses. Though |the net was designed for "addresses", Which net? IP addresses have always been treated as possessions. The big paradigm shift came when they went from being possessions of end users to possessions of ISPs, with ISPs renting them back to end users. Remember, even when the provider-allocated aggregation hack was originally proposed as a temporary work-around for limited memory expandability in certain routers, the promise was that space so allocated would still belong to the end user and be portable. (Supposedly by the time enough people had switched ISPs to expand the tables the hardware would have caught up.) That promise lasted what, two months? It's a little like the promise of site- local addressing. If global/routable IP addresses really worked like street addresses I think you would see a lot less demand for other stable address space. People know that there is a certain overhead associated with a physical move, and switching IP addresses along with phone numbers, street addresses on business cards, etc., would not be a big deal. But IP addresses like that aren't really available. It is unreasonable to claim that an IP address is like a street address in the sense that it tells which ISP you currently "live" at. |I suspect |that they are viewed more as possessions which is |an obvious problem. Why is it 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 Nov 12 21:10:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD5A5kd013737; Tue, 12 Nov 2002 21:10:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD5A57Z013736; Tue, 12 Nov 2002 21:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD59vkd013696 for ; Tue, 12 Nov 2002 21:09:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD5A6Mq001511 for ; Tue, 12 Nov 2002 21:10:06 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA16803 for ; Tue, 12 Nov 2002 22:09:58 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id AAA24376; Wed, 13 Nov 2002 00:09:22 -0500 (EST) Date: Wed, 13 Nov 2002 00:09:22 -0500 (EST) From: Dan Lanciani Message-Id: <200211130509.AAA24376@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Naming and site-local addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: |Neither does it scale to expect all hosts to maintain |enough information to let them do routing. On the contrary, distributed host-based routing is one of the few solutions that does scale well. The availability of resources to deal with the routing grows directly in proportion to the consumers of those resources. It is traditional centralized routing that suffers from issues of scale, though these are variably exaggerated and minimized depending on the case that is being argued. Personally I would have liked to see routing confined to the stack and hidden from applications with portable identifiers or a similar indirection mechanism. Unfortunately, this would have conflicted with the address allocation business model as currently envisioned, so the functionality (or, rather, a subset of the functionality) was percolated up to the application layer. So it goes. 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 Nov 12 22:34:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD6YOkd020883; Tue, 12 Nov 2002 22:34:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD6YFl4020815; Tue, 12 Nov 2002 22:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD6Xnkd020638 for ; Tue, 12 Nov 2002 22:33:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD6XnMq018902 for ; Tue, 12 Nov 2002 22:33:49 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA20347 for ; Tue, 12 Nov 2002 23:33:39 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:9d24:9fbf:1b4a:3967]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id gAD6XUd14350; Wed, 13 Nov 2002 15:33:31 +0900 (JST) Date: Wed, 13 Nov 2002 15:34:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-Reply-To: <3DD0F9AC.FF821AAA@hursley.ibm.com> References: <3DD0F9AC.FF821AAA@hursley.ibm.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 72 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 12 Nov 2002 13:53:00 +0100, >>>>> Brian E Carpenter said: > 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, > in order to change the following paragraph in section 2.5.6: > Current text: >> Site-local addresses are designed to be used for addressing inside of >> a site without the need for a global prefix. Although a subnet ID >> may be up to 54-bits long, it is expected that globally-connected >> sites will use the same subnet IDs for site-local and global >> prefixes. > Proposed new text: > Site-local addresses are designed to be used for addressing inside of > a site which is not connected to the Internet and therefore does not > need a global prefix. They must not be used for a site that is connected > to the Internet. Using site-local addresses, a subnet ID may be up to > 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > for convenience if the site is later connected to the Internet using a > global prefix. I'm personally okay to restrict the use of site-local addresses (though the level of the restriction may need to be discussed). However, the proposed text seems to introduce a big impact on the current usage of SLs in spite of the small change on wording; it restricts the use to non-connected networks. This type of proposal has been raised in this thread several times, and we've seen doubts and objections to the proposal every time (of course, as well as agreement). So, I'm a bit surprised that a majority of this group is going to support the proposed text, even by those who had a doubt such as "I personally would like to deprecate site-local addresses, but I'm not sure if it is effective to impose such a big change on the current usage." I admit I've not read all the messages in this huge thread, but please let me ask: has there been a consensus in the thread to limit the use of site-locals to not-globally-connected networks? If so, I'll follow the consensus, and will just be happy. Otherwise, I'd say we have to be careful because we'll easily go into the same loop of discussion. I'd also like to point out a few things (some of them have been covered by the discussion so far): - the case of multi-sited nodes, which is a major sources of headaches, is not eliminated even if we can restrict the usage to non-globally-connected networks. What should we do on this topic? - though I'm okay to restrict the use of SLs (as I said above), I'm not sure if the proposed limitation is effective. What exactly does the "must not" mean? Does it mean nodes in the global network must drop packets contains SLs? How can we ensure the restriction? How can the nodes detect if they are in the global network? What should we do when our network using SLs connects to the global network? Having considered the points above, my honest feeling is that the proposal is an incomplete compromise. The impact is as big as a stronger change of deprecating SLs *completely*, but there will still remain difficult issues. If we have really reached a consensus on the proposed text, I guess we can even agree on removing SLs completely, with which I'll be much happier. 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 Nov 12 23:42:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD7gJkd001653; Tue, 12 Nov 2002 23:42:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD7gJiD001652; Tue, 12 Nov 2002 23:42: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD7gGkd001645 for ; Tue, 12 Nov 2002 23:42:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD7gPMq008286 for ; Tue, 12 Nov 2002 23:42:25 -0800 (PST) Received: from laptop2.kurtis.pp.se (tlp1.cobweb.autonomica.se [130.244.10.138]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA02143 for ; Wed, 13 Nov 2002 00:42:20 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gAD7geve001527 for ; Wed, 13 Nov 2002 08:42:43 +0100 (CET) Date: Wed, 13 Nov 2002 08:42:39 +0100 Subject: Re: Proposal for site-local clean-up Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) From: Kurt Erik Lindqvist To: Content-Transfer-Encoding: 7bit In-Reply-To: <2B81403386729140A3A899A8B39B046405E456@server2000> Message-Id: <7C665F74-F6DB-11D6-BC97-000393AB1404@kurtis.pp.se> X-Mailer: Apple Mail (2.548) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Processwise a recall from the RFC editor could also be challenged all > the way to the IAB or even the ISOC and lead us to 1000+ more emails up > front and 10000 more before all the appeal processes have been > exhausted. Is this the road we are taking? Without pointing at anyone in particular... Why do I get the feeling that one group on the list is trying to argue for changing the text because it has proven that it is more effort than we get value, another group is trying to push the document through the processes with the argument that "this has taken to long". In my mind it must be better for something to take a longer time if the result is clearer and better defined. There is always a break-off point but I don't feel we are there yet. I fail to see what is so urgent with this. - 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 Nov 13 01:35:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD9ZIkd003073; Wed, 13 Nov 2002 01:35:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD9ZHMf003072; Wed, 13 Nov 2002 01:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD9ZEkd003065 for ; Wed, 13 Nov 2002 01:35:14 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD9ZNbB000448 for ; Wed, 13 Nov 2002 01:35:23 -0800 (PST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27917 for ; Wed, 13 Nov 2002 01:35:17 -0800 (PST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id B888062572; Wed, 13 Nov 2002 10:35:07 +0100 (CET) Date: Wed, 13 Nov 2002 10:35:07 +0100 From: Harald Tveit Alvestrand To: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up Message-ID: <47630000.1037180107@askvoll.hjemme.alvestrand.no> In-Reply-To: <3DD0F9AC.FF821AAA@hursley.ibm.com> References: <3DD0F9AC.FF821AAA@hursley.ibm.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 think Brian's proposal, if adopted, makes my worry about site-locals inducing complexity in naming lookup mechanisms go away (naming mechanisms for disconnected networks have to be different from those for connected networks anyway). So you can count me as supporting the proposal. That said, I also think that writing down (some of) the arguments on the issue in permanent form would be a good idea...... and there are a few devils-in-the-details having to do with the transition between connectedness and disconnectedness, which also could use some words-on-electrons. But this resolution seems basically right to me. Harald --On tirsdag, november 12, 2002 13:53:00 +0100 Brian E Carpenter wrote: > 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, > in order to change the following paragraph in section 2.5.6: > > Current text: > >> Site-local addresses are designed to be used for addressing inside of >> a site without the need for a global prefix. Although a subnet ID >> may be up to 54-bits long, it is expected that globally-connected >> sites will use the same subnet IDs for site-local and global >> prefixes. > > Proposed new text: > > Site-local addresses are designed to be used for addressing inside of > a site which is not connected to the Internet and therefore does not > need a global prefix. They must not be used for a site that is > connected to the Internet. Using site-local addresses, a subnet ID may > be up to 54-bits long, but it is recommended to use at most 16-bit > subnet IDs, for convenience if the site is later connected to the > Internet using a global prefix. > > Otherwise, we will need a whole new RFC just for this paragraph. > > Alternatively, we could spend the next 5 years discussing the > unnecessary complexities of using site-locals on connected sites. > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 01:47:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD9lgkd003263; Wed, 13 Nov 2002 01:47:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAD9lgqS003262; Wed, 13 Nov 2002 01:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAD9ldkd003255 for ; Wed, 13 Nov 2002 01:47:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAD9lmMq000632 for ; Wed, 13 Nov 2002 01:47:48 -0800 (PST) Received: from laptop2.kurtis.pp.se (tlp1.cobweb.autonomica.se [130.244.10.138]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29519 for ; Wed, 13 Nov 2002 02:47:42 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gAD9m2ve002133; Wed, 13 Nov 2002 10:48:02 +0100 (CET) Date: Wed, 13 Nov 2002 10:48:01 +0100 Subject: Re: Proposal for site-local clean-up Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com To: Harald Tveit Alvestrand From: Kurt Erik Lindqvist In-Reply-To: <47630000.1037180107@askvoll.hjemme.alvestrand.no> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If I could sleep assured that site-locals would not be used for any other network than networks not connected to global Internets, I would be all for this. What still have me really worried is that there is no way to enforce this, and it is just inviting NATv6. In that case Brians wording will just help get the document published and end the discussion without anyone having gained anything. Then again, there is no way we can stop people from doing NAT even with global addresses.... I guess I am for this proposal as well then... - kurtis - On onsdag, nov 13, 2002, at 10:35 Europe/Stockholm, Harald Tveit Alvestrand wrote: > I think Brian's proposal, if adopted, makes my worry about site-locals > inducing complexity in naming lookup mechanisms go away (naming > mechanisms for disconnected networks have to be different from those > for connected networks anyway). > > So you can count me as supporting the proposal. > > That said, I also think that writing down (some of) the arguments on > the issue in permanent form would be a good idea...... and there are a > few devils-in-the-details having to do with the transition between > connectedness and disconnectedness, which also could use some > words-on-electrons. > > But this resolution seems basically right to me. > > Harald > > --On tirsdag, november 12, 2002 13:53:00 +0100 Brian E Carpenter > wrote: > >> 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, >> in order to change the following paragraph in section 2.5.6: >> >> Current text: >> >>> Site-local addresses are designed to be used for addressing >>> inside of >>> a site without the need for a global prefix. Although a subnet ID >>> may be up to 54-bits long, it is expected that globally-connected >>> sites will use the same subnet IDs for site-local and global >>> prefixes. >> >> Proposed new text: >> >> Site-local addresses are designed to be used for addressing inside >> of >> a site which is not connected to the Internet and therefore does >> not >> need a global prefix. They must not be used for a site that is >> connected to the Internet. Using site-local addresses, a subnet ID >> may >> be up to 54-bits long, but it is recommended to use at most 16-bit >> subnet IDs, for convenience if the site is later connected to the >> Internet using a global prefix. >> >> Otherwise, we will need a whole new RFC just for this paragraph. >> >> Alternatively, we could spend the next 5 years discussing the >> unnecessary complexities of using site-locals on connected sites. >> >> Brian >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home Page: http://playground.sun.com/ipng >> FTP archive: ftp://playground.sun.com/pub/ipng >> Direct all administrative requests to majordomo@sunroof.eng.sun.com >> -------------------------------------------------------------------- >> > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 02:21:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADALBkd003402; Wed, 13 Nov 2002 02:21:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADALBEs003401; Wed, 13 Nov 2002 02:21:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADAL8kd003394 for ; Wed, 13 Nov 2002 02:21:08 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADALHbB006708 for ; Wed, 13 Nov 2002 02:21:17 -0800 (PST) Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14863 for ; Wed, 13 Nov 2002 03:21:11 -0700 (MST) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Nov 2002 11:21:08 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 11:21:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKKSriuEHVrSoj+Qx6KS102Vn4ZVAAsu/jg From: "NOISETTE Yoann FTRD/DMI/CAE" To: "Brian E Carpenter" , X-OriginalArrivalTime: 13 Nov 2002 10:21:08.0390 (UTC) FILETIME=[619E8460:01C28AFE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADAL8kd003395 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I would possibly agree with this change, but it must be clear that some ongoing work or considered solutions will be restricted or even totally impossible after this new statement becomes effective. For instance, draft-ietf-ipv6-dns-discovery-07.txt gives many examples of a Customer site, using site-local addresses (in particular for DNS discovery), and this Customer site is connected to an ISP (thus certainly I presume to the Internet)... Yoann -----Message d'origine----- De : Brian E Carpenter [mailto:brian@hursley.ibm.com] Envoye : mardi 12 novembre 2002 13:53 A : ipng@sunroof.eng.sun.com Objet : 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, in order to change the following paragraph in section 2.5.6: Current text: > Site-local addresses are designed to be used for addressing inside of > a site without the need for a global prefix. Although a subnet ID > may be up to 54-bits long, it is expected that globally-connected > sites will use the same subnet IDs for site-local and global > prefixes. Proposed new text: Site-local addresses are designed to be used for addressing inside of a site which is not connected to the Internet and therefore does not need a global prefix. They must not be used for a site that is connected to the Internet. Using site-local addresses, a subnet ID may be up to 54-bits long, but it is recommended to use at most 16-bit subnet IDs, for convenience if the site is later connected to the Internet using a global prefix. Otherwise, we will need a whole new RFC just for this paragraph. Alternatively, we could spend the next 5 years discussing the unnecessary complexities of using site-locals on connected sites. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 04:39:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADCdVkd004549; Wed, 13 Nov 2002 04:39:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADCdTjF004548; Wed, 13 Nov 2002 04:39: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADCdPkd004539 for ; Wed, 13 Nov 2002 04:39:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADCdZbB025688 for ; Wed, 13 Nov 2002 04:39:35 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29926 for ; Wed, 13 Nov 2002 05:39:29 -0700 (MST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 13 Nov 2002 04:39:29 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 13 Nov 2002 04:39:18 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 13 Nov 2002 04:39:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 04:39:28 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKKpHfRB4gJ/W5GSc2YTt0HtO72egAaC1lQ From: "Brian Zill" To: X-OriginalArrivalTime: 13 Nov 2002 12:39:27.0974 (UTC) FILETIME=[B48E8860:01C28B11] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADCdQkd004540 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore writes: > Hesham writes: > > - "MUST NOTs" are there for a reason, saying MUST NOT > > when it can be done and protocols don't break is not > > a good idea. I agree with Hesham. We shouldn't be applying "MUST NOT"s to situations where we have workable solutions. Restricting site-locals to isolated networks is not a good idea. > > - People have shown that there are ways of using > > site-locals for single and multi-sited hosts today and > > making sure that apps don't break. > > actually, no. people have shown that there are ways of > using SLs for some apps in such situations. nobody has > come up with a general solution that requires less than > either: > - expecting all non-isolated networks to provide global > addresses (and having apps ignore SLs in the presence > of globals), or > - expecting apps to do their own addressing and routing. Which is just fine! Nobody was arguing that non-isolated networks shouldn't provide global addresses -- they should. If someone want to talk globally, they should use global addresses. I think we could get consensus on that. (I'd make a small argument about your "ignore SLs in the presence of globals", however, since I already showed how using site-locals can work if the site-local is never passed outside of its scope zone). I claim that requiring non-isolated networks to provide global addresses to those entities which desire global connectivity *is* a general solution (and certainly a much better solution than banning site-locals on non-isolated networks). So why don't we standardize on that? --Brian P.S. A couple other posts in the last few hours have shown that people are (finally!) starting to think through the misguided proposal to ban site-locals and realizing the downsides. I'd like to add one more: how are sporadically connected sites (e.g. a small home/office net with a pay-by-the-minute dialup link that gets a different prefix each time it connects) supposed to work if site-locals are banned from connected networks? Person X isn't going to want their intrasite connection to go down because person Y wanted to check their mail on the Internet. We have a workable solution for this today in site-locals. Do we really want to encourage such sites to use link-locals and multi-link subnet routers between all their links? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 05:33:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADDXbkd004867; Wed, 13 Nov 2002 05:33:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADDXbr0004866; Wed, 13 Nov 2002 05: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADDXXkd004859 for ; Wed, 13 Nov 2002 05:33:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADDXgMq000652 for ; Wed, 13 Nov 2002 05:33:42 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21908 for ; Wed, 13 Nov 2002 06:33:37 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADDXXl09313; Wed, 13 Nov 2002 08:33:33 -0500 (EST) Message-Id: <200211131333.gADDXXl09313@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: Naming and site-local addresses In-reply-to: (Your message of "Wed, 13 Nov 2002 00:09:22 EST.") <200211130509.AAA24376@ss10.danlan.com> Date: Wed, 13 Nov 2002 08:33:33 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > |Neither does it scale to expect all hosts to maintain > |enough information to let them do routing. > > On the contrary, distributed host-based routing is one of the few solutions > that does scale well. The availability of resources to deal with the routing > grows directly in proportion to the consumers of those resources. that incorrectly assumes that the only 'resource' in question is cpu time offhand: a. you have to get the information to the hosts to allow them to do routing b. some hosts are mobile and/or intermittently connected and would have a difficult time keeping up with routing updates - also they could consume significant bandwidth to those hosts c. consistency of routing is harder to acheive with so many hosts involved d. routing updates would take longer to propagate e. unless you expect hosts to do source routing, having them do routing doesn't relieve the network of the need to do routing. f. source routes consume bandwidth g. source routes are less resiliant to changes in network configuration (e.g. link failure) near the destination h. you can't expect hosts to adhere to policy for use of other portions of the network -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 05:37:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADDbvkd004948; Wed, 13 Nov 2002 05:37:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADDbvEj004947; Wed, 13 Nov 2002 05:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADDbrkd004940 for ; Wed, 13 Nov 2002 05:37:53 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADDc3bB002979 for ; Wed, 13 Nov 2002 05:38:03 -0800 (PST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11414 for ; Wed, 13 Nov 2002 05:37:57 -0800 (PST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0244C62083; Wed, 13 Nov 2002 14:37:48 +0100 (CET) Date: Wed, 13 Nov 2002 14:37:47 +0100 From: Harald Tveit Alvestrand To: Brian Zill , ipng@sunroof.eng.sun.com Subject: RE: Proposal for site-local clean-up Message-ID: <64980000.1037194667@askvoll.hjemme.alvestrand.no> In-Reply-To: References: 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, november 13, 2002 04:39:28 -0800 Brian Zill wrote: > Which is just fine! Nobody was arguing that non-isolated networks > shouldn't provide global addresses -- they should. If someone want to > talk globally, they should use global addresses. I think we could get > consensus on that. (I'd make a small argument about your "ignore SLs in > the presence of globals", however, since I already showed how using > site-locals can work if the site-local is never passed outside of its > scope zone). > > I claim that requiring non-isolated networks to provide global addresses > to those entities which desire global connectivity *is* a general > solution (and certainly a much better solution than banning site-locals > on non-isolated networks). So why don't we standardize on that? my reading is that "banning" site-locals from connected networks is going to be a simplification mechanism for standardization, not a requirement for configuration of live networks.... every time we come across a case where complexity is increased by considering how to use site-local concurrently with global addresses (my favourite list starts with source address selection and DNS lookup, but does not end there.....), we can safely say "but we don't have to solve that - it's not supposed to be that way", and move on with a simple solution that works for the global case. If people come up with things that work with site-local under those conditions, they will no doubt use them - but they should not expect to get any help from other parts of the infrastructure in sorting them out. The IETF has *never* had an enforcement arm. 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 Nov 13 05:38:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADDcUkd004981; Wed, 13 Nov 2002 05:38:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADDcUTJ004978; Wed, 13 Nov 2002 05:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADDcOkd004962 for ; Wed, 13 Nov 2002 05:38:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADDcXbB003036 for ; Wed, 13 Nov 2002 05:38:34 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28628 for ; Wed, 13 Nov 2002 06:38:28 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADDcMl09335; Wed, 13 Nov 2002 08:38:23 -0500 (EST) Message-Id: <200211131338.gADDcMl09335@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 15:34:40 +0900.") Date: Wed, 13 Nov 2002 08:38:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Having considered the points above, my honest feeling is that the > proposal is an incomplete compromise. The impact is as big as a > stronger change of deprecating SLs *completely*, but there will still > remain difficult issues. I agree that there remain difficult issues even with this restriction in place. SLs are still allowed, for instance, on networks that connect to other networks, and this will still break apps that operate between those networks. And yet I don't see how to deprecate SLs completely until we have a solution in place to allow networks that are not connected to the Internet to get global address space. 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 Nov 13 05:56:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADDulkd005256; Wed, 13 Nov 2002 05:56:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADDukCe005255; Wed, 13 Nov 2002 05:56:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADDugkd005248 for ; Wed, 13 Nov 2002 05:56:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADDuqMq003292 for ; Wed, 13 Nov 2002 05:56:52 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03204 for ; Wed, 13 Nov 2002 06:56:46 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADDuil09464; Wed, 13 Nov 2002 08:56:45 -0500 (EST) Message-Id: <200211131356.gADDuil09464@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Brian Zill" cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 04:39:28 PST.") Date: Wed, 13 Nov 2002 08:56:44 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I agree with Hesham. We shouldn't be applying "MUST NOT"s to situations > where we have workable solutions. the closest thing we have to a workable solution is to find a way to give every site that connects to another network a global prefix (whether it's globally connected or not) and have applications ignore the SLs (at least for purpose of referrals). and if you do that, there is little point in having SLs at all except for isolated networks - they just complicate management and DNS etc. for the networks that use them. > > actually, no. people have shown that there are ways of > > using SLs for some apps in such situations. nobody has > > come up with a general solution that requires less than > > either: > > - expecting all non-isolated networks to provide global > > addresses (and having apps ignore SLs in the presence > > of globals), or > > - expecting apps to do their own addressing and routing. > > Which is just fine! Nobody was arguing that non-isolated networks > shouldn't provide global addresses -- they should. If someone want to > talk globally, they should use global addresses. but this isn't just about sites that want to talk globally - this is about sites that connect to other sites, some of which talk globally. and again, if any of those sites use SL, then apps that communicate across site boundaries are forced to implement their own addressing and routing. > (I'd make a small argument about your "ignore SLs in > the presence of globals", however, since I already showed how using > site-locals can work if the site-local is never passed outside of its > scope zone). yes, but that presumes either that all such sites have global addresses or that there is never a need for an extra-site party to perform a referral between two hosts on the same site. neither seems reasonable. > I claim that requiring non-isolated networks to provide global addresses > to those entities which desire global connectivity *is* a general > solution I disagree. network A isn't necessarily providing global connectivity (transit) to network B even though A as global connectivity and A and B connect to one another. the problem is that applications that communicate between A and B and perhaps with nodes on other networks need a linear address space, and they don't have one if any of those networks use site-locals. also, insisting that A give up a part of its address space to B just in order to connect to B can be problematic - it affects A's existing organization of its address space. (just because so much address space is available does not mean it will be well-utilized!) my guess is that enterprise networks will be reluctant to give up part of their address space to allow other enterprises to connect. and if B wants to connect to several networks, which one gives up part of its address space? 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 Nov 13 06:39:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADEd3kd005452; Wed, 13 Nov 2002 06:39:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADEd2xG005451; Wed, 13 Nov 2002 06:39: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADEcukd005444 for ; Wed, 13 Nov 2002 06:38:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADEd5bB011836 for ; Wed, 13 Nov 2002 06:39:06 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26450 for ; Wed, 13 Nov 2002 07:38:59 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id QAA05853; Wed, 13 Nov 2002 16:38:55 +0200 Date: Wed, 13 Nov 2002 16:38:55 +0200 Message-Id: <200211131438.QAA05853@burp.tkv.asdf.org> From: Markku Savela To: harald@alvestrand.no CC: bzill@microsoft.com, ipng@sunroof.eng.sun.com In-reply-to: <64980000.1037194667@askvoll.hjemme.alvestrand.no> (message from Harald Tveit Alvestrand on Wed, 13 Nov 2002 14:37:47 +0100) Subject: Re: Proposal for site-local clean-up References: <64980000.1037194667@askvoll.hjemme.alvestrand.no> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Harald Tveit Alvestrand > every time we come across a case where complexity is increased by > considering how to use site-local concurrently with global addresses (my > favourite list starts with source address selection and DNS lookup, but > does not end there.....), 1. There is NO PROBLEM with source address selection. - if your destination is site local, your source address is site-local, - if your destination is global, your source is global, If there are any changes in source address selection, I would actually wish that it is always required that source source and destination are always same scope. (Now it is apparently allowed to use higher scope source address). Because IPv6 has link local addresses, the source address selection machinery with scopes must be done anyway, and supporting site locals does not bring in any extra complexities. 2. I accept that DNS-issue needs some discussion and defintion. My view on this is that you need the "scoped DNS" architecture, which can be seens as extension to "two-faced DNS". You can have a. global DNS service (the current) b. site local DNS service c. link local DNS service and you have the normal search order policy inside your resolver, for example 1. look hosts file 2. look global dns service 3. look site local service 4. look link local service (LLMNR) the proces stops when answer is found from any level (e.g. if global service gives positive answer, site and link local are not queried). "Not found" answer is trickier: continue to next level or not? (probably needs to be somewhat configurable). Not all levels need to be present always. --- Stacks have already been implemented and delivered with support for site locals. The support stays in, and it's up to users and site admins to decide whether they are used or not. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 06:54:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADEsbkd005708; Wed, 13 Nov 2002 06:54:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADEsaEM005707; Wed, 13 Nov 2002 06:54: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADEsXkd005700 for ; Wed, 13 Nov 2002 06:54:33 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADEshbB014444 for ; Wed, 13 Nov 2002 06:54:43 -0800 (PST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05763 for ; Wed, 13 Nov 2002 06:54:37 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gADEsYdK060854 for ; Wed, 13 Nov 2002 15:54:35 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gADEsXlO116684 for ; Wed, 13 Nov 2002 15:54:34 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA28556 from ; Wed, 13 Nov 2002 15:54:32 +0100 Message-Id: <3DD26798.E0B165F4@hursley.ibm.com> Date: Wed, 13 Nov 2002 15:54:16 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Summary Re: Proposal for site-local clean-up References: <3DD0F9AC.FF821AAA@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, there are far more people saying yes than no, but let me respond to some of the comments made. 1. Process (Tony Hain). Of course. If we make a substantive change to a draft that's already passed the IESG, a last call is needed IMHO. It would still be cleaner than publishing the RFC and then publishing a change. 2. Rationale. (several people). Yes, it might be good to publish an informational document about this. That might well belong in v6ops. 3. Can't stop NAT's anyway. (several people). That may sadly be true, but we shouldn't publish specs that seem to encourage them. 4. Impact on existing implementations and ongoing work. (several people). I don't really understand what the implementation change would be - surely this is basically a configuration issue? Products will still have to support SL. If we are going to impact ongoing work, however, the sooner the better. 5. Why not just kill SL completely? (JINMEI) That would definitely annoy implementors, and close off our options. 6. We have to handle multiple scopes anyway (Brian Zill, Tony Hain). Right. And by retaining SL, we retain the option of reversing the "disconnected" decision if we ever do figure out how to handle them properly. 7. must not v. MUST NOT (Keith Moore). The document as a whole doesn't use upper case. Brian Brian E Carpenter wrote: > > 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, > in order to change the following paragraph in section 2.5.6: > > Current text: > > > Site-local addresses are designed to be used for addressing inside of > > a site without the need for a global prefix. Although a subnet ID > > may be up to 54-bits long, it is expected that globally-connected > > sites will use the same subnet IDs for site-local and global > > prefixes. > > Proposed new text: > > Site-local addresses are designed to be used for addressing inside of > a site which is not connected to the Internet and therefore does not > need a global prefix. They must not be used for a site that is connected > to the Internet. Using site-local addresses, a subnet ID may be up to > 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > for convenience if the site is later connected to the Internet using a > global prefix. > > Otherwise, we will need a whole new RFC just for this paragraph. > > Alternatively, we could spend the next 5 years discussing the > unnecessary complexities of using site-locals on connected sites. > > Brian -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 06:57:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADEvTkd005776; Wed, 13 Nov 2002 06:57:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADEvTx2005773; Wed, 13 Nov 2002 06:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADEvMkd005762 for ; Wed, 13 Nov 2002 06:57:23 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADEvWMq016821 for ; Wed, 13 Nov 2002 06:57:32 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07494 for ; Wed, 13 Nov 2002 06:57:26 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id gADEvCB4072828; Wed, 13 Nov 2002 15:57:16 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gADEv6lO134496; Wed, 13 Nov 2002 15:57:07 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA64032 from ; Wed, 13 Nov 2002 15:56:58 +0100 Message-Id: <3DD2682A.11EC5773@hursley.ibm.com> Date: Wed, 13 Nov 2002 15:56:42 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Shannon -jj Behrens Cc: ipng Subject: Re: provider independent addressing (Re: site-locals) References: <20021112190017.GA11163@alicia.nttmcl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Join the multi6 list and check the archives. Brian Shannon -jj Behrens wrote: > > Summary: a provider independent addressing solution is proposed so that > site-locals are not necessary. > > One of the chief reasons proposed for the use of site-locals is for stable > addressing (especially if you need to change ISP's). A nicer solution, that > has so far proven unimplementable is provider independent addressing. The > problem with provider independent addressing is that, because routing is no > longer aggregated, it becomes too difficult for our current hardware limits. > I've also heard proposals for allocating prefixes to each geographical point on > earth. I propose a modification of this idea. Allocate a /32 (or some > suitable number) to each region (where each region is about the size of > California, but is based on politics rather than size). Then each ISP in that > region could coordinate to delegate prefixes out of that slice of that /32. > Hence, we have aggregation on the region level, but within that slice, the > routing would be flat (i.e. prefixes are not associated with any ISP). Flat > routing on a region level is doable if the region isn't too large. I can see > that some people might complain that physically relocating to another region > would cause renumbering, yet I propose that physically relocating to another > region is more difficult in and of itself than just renumbering. > > Of course, I haven't done all my reading yet, so forgive me if I'm missing > an obvious problem. > > -jj > > -- > def qsort(l): # Purely functional implementation of QSort in Python. > if not len(l): return [] > return (qsort([i for i in l[1:] if i < l[0]]) + [l[0]] + > qsort([i for i in l[1:] if i >= l[0]])) > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 06:57:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADEvukd005805; Wed, 13 Nov 2002 06:57:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADEvuY8005802; Wed, 13 Nov 2002 06:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADEvokd005788 for ; Wed, 13 Nov 2002 06:57:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADEvxbB015035 for ; Wed, 13 Nov 2002 06:57:59 -0800 (PST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08294 for ; Wed, 13 Nov 2002 07:57:53 -0700 (MST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id AA4BD62083; Wed, 13 Nov 2002 15:57:48 +0100 (CET) Date: Wed, 13 Nov 2002 15:57:48 +0100 From: Harald Tveit Alvestrand To: Markku Savela Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up Message-ID: <1250000.1037199468@askvoll.hjemme.alvestrand.no> In-Reply-To: <200211131438.QAA05853@burp.tkv.asdf.org> References: <64980000.1037194667@askvoll.hjemme.alvestrand.no> <200211131438.QAA05853@burp.tkv.asdf.org> 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, november 13, 2002 16:38:55 +0200 Markku Savela wrote: > (my >> favourite list starts with source address selection and DNS lookup, but >> does not end there.....), > > 1. There is NO PROBLEM with source address selection. > > - if your destination is site local, your source address is > site-local, > > - if your destination is global, your source is global, sorry, I misspoke. the problems I have heard people yelling about are endemic to having multiple addresses of different scopes available, and "source address selection" is just one aspect of picking the "right" source/destination pair. 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 Nov 13 07:44:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADFiOkd007039; Wed, 13 Nov 2002 07:44:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADFiNWf007038; Wed, 13 Nov 2002 07:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADFiKkd007029 for ; Wed, 13 Nov 2002 07:44:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADFiTbB023438 for ; Wed, 13 Nov 2002 07:44:30 -0800 (PST) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16585 for ; Wed, 13 Nov 2002 08:44:24 -0700 (MST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id D996C31C3; Wed, 13 Nov 2002 09:44:23 -0600 (CST) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 41AAF1AD5; Wed, 13 Nov 2002 09:44:23 -0600 (CST) Message-ID: <3DD27352.6070104@hp.com> Date: Wed, 13 Nov 2002 10:44:18 -0500 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: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up References: <3DD0F9AC.FF821AAA@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: > > Proposed new text: > > Site-local addresses are designed to be used for addressing inside of > a site which is not connected to the Internet and therefore does not > need a global prefix. They must not be used for a site that is connected > to the Internet. Using site-local addresses, a subnet ID may be up to > 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > for convenience if the site is later connected to the Internet using a > global prefix. > I have some reservations about this this proposal from the implementors point of of view. The proposal uses the words "must no" (lower case) and that makes it somewhat unclear and brings up the following questions. If the implemenation supports the use of site-locals when a global prefix is availiable and the node is connected to the "global internet", is the implementation compliante with the addr-arch? If the node is configured with both site-locals and globals, is the configuration addr-arch compliant? IMHO, it would almost be easier to remove the "must not be used" sentence from the above paragraph. -vlad -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead 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 Wed Nov 13 07:47:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADFl5kd007128; Wed, 13 Nov 2002 07:47:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADFl5jr007127; Wed, 13 Nov 2002 07:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADFl1kd007120 for ; Wed, 13 Nov 2002 07:47:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADFlAbB024057 for ; Wed, 13 Nov 2002 07:47:10 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00876 for ; Wed, 13 Nov 2002 08:47:04 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADFktl10337; Wed, 13 Nov 2002 10:46:56 -0500 (EST) Message-Id: <200211131546.gADFktl10337@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Markku Savela cc: harald@alvestrand.no, bzill@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 16:38:55 +0200.") <200211131438.QAA05853@burp.tkv.asdf.org> Date: Wed, 13 Nov 2002 10:46:55 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My view on this is that you need the "scoped DNS" architecture, which > can be seens as extension to "two-faced DNS". You can have DNS is only one of many applications that have this problem. you can't solve the DNS problem and ignore those of the other applications. also, scoped DNS will break applications that expect a consistent view of DNS from one site to another, and it will break DNS caching. so for me, standardizing scoped DNS is out of the question. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 08:42:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADGg4kd007842; Wed, 13 Nov 2002 08:42:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADGg4dM007841; Wed, 13 Nov 2002 08:42: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADGg1kd007834 for ; Wed, 13 Nov 2002 08:42:01 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADGgAbB007430 for ; Wed, 13 Nov 2002 08:42:10 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16448 for ; Wed, 13 Nov 2002 09:42:04 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 13 Nov 2002 08:42:08 -0800 Reply-To: From: "Tony Hain" To: "'Keith Moore'" , "'Brian Zill'" Cc: Subject: RE: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 08:41:53 -0800 Message-ID: <07d601c28b33$9296bb20$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211131356.gADDuil09464@astro.cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADGg1kd007835 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > the closest thing we have to a workable solution is to find a > way to give every site that connects to another network a > global prefix > (whether it's globally connected or not) and have applications > ignore the SLs (at least for purpose of referrals). and if you do > that, there is little point in having SLs at all except for > isolated networks - they just complicate management and DNS > etc. for the networks that use them. It doesn't matter how many times you write this, you can not make it become true. Brian keeps pointing out the simple case of an intermittently connected network getting a different prefix on each connect, but you keep ignoring it. STABLE ADDRESS SPACE IS A MAJOR APPLICATION REASON TO HAVE SL. Also, as I have said multiple times, getting rid of SL does not create PI space. When PI space is available, people will most likely recognize that it is easier to deal with than SL, and will naturally migrate. Even when it is available, that does not automatically create a reason to restrict the use of SL. It will always be easier to filter a short /10 than to maintain a long list of access controls at the border. THIS IS A MAJOR OPERATIONAL REASON TO USE SL. It is appropriate that we have a document describing the impact on multi-party apps using literal referrals, and another on guidance on DNS configurations. We have discussed the first many times, and the second is nothing more than formalizing what people have been already doing in the face of 1918 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 Wed Nov 13 08:49:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADGnskd007918; Wed, 13 Nov 2002 08:49:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADGnsvP007917; Wed, 13 Nov 2002 08:49:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADGnpkd007910 for ; Wed, 13 Nov 2002 08:49:51 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADGo0bB009609 for ; Wed, 13 Nov 2002 08:50:00 -0800 (PST) Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21495 for ; Wed, 13 Nov 2002 08:49:55 -0800 (PST) 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 KAA15606; Wed, 13 Nov 2002 10:49:43 -0600 (CST) Message-Id: <5.1.1.5.2.20021113102825.025644c0@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 13 Nov 2002 10:48:52 -0600 To: Keith Moore , alh-ietf@tndh.net From: Richard Carlson Subject: Re: Proposal for site-local clean-up Cc: "'Keith Moore'" , "'Bound, Jim'" , "'Alain Durand'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com In-Reply-To: <200211130227.gAD2Ril05178@astro.cs.utk.edu> References: <(Your message of "Tue, 12 Nov 2002 18:10:51 PST.") <079f01c28ab9$e4d6f230$bd134104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith; At 09:27 PM 11/12/02 -0500, Keith Moore wrote: >[snip snip snip] >No. Scopes reduce the ablity of the network to support apps. >They make it harder to produce an app that works independently >of network location, and they don't add a single extra capability >that wasn't present already. You keep saying that some apps will fail with scoped addresses. My poor brain can't grasp why this is so. Can you give me a detailed example of how an app will fail if it has multiple scoped addresses to choice from? I don't mean that it may be hard to for the app to decide which address to use. Yes that's a hard problem, and we don't have a solution to it yet, but that doesn't seem a good enough reason to kill site locals to me. I also don't mean that an app can get confused and it will fail to connect to the correct proper destination if it uses a scoped address at the wrong time. Yes this can happen, but it's still part of the address selection problem, not a basic problem with an app. I'm looking for something like FTP and NAT. FTP exchanges IP addresses in data messages which fail when NATs cause these addresses to change. There are all kinds of kludges that try to work around this problem, but the basic issue is that the E2E property of IP was lost and the apps suffer for this change. I don't see the same thing happening with site-local's, everyone agrees that they aren't a v6 NAT replacement so apps are not allowed to propagate site locals outside of the site boundary. Yes, hosts need to be aware of the site boundary, but that is still an address selection problem not a problem with the app itself. Site-locals are unique within the site boundaries and look just like a global IPv6 address, so what is a specific example where an app will be broken by using a site-local address? Rich >Why in the world you should be trying to promote dysfunction in the >network is beyond me. > >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 >-------------------------------------------------------------------- ------------------------------------ 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 Wed Nov 13 09:10:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADHAYkd008239; Wed, 13 Nov 2002 09:10:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADHAXjp008237; Wed, 13 Nov 2002 09:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADHARkd008223 for ; Wed, 13 Nov 2002 09:10:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADHAbMq021389 for ; Wed, 13 Nov 2002 09:10:37 -0800 (PST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11449 for ; Wed, 13 Nov 2002 10:10:30 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gADH9Wvx055028; Wed, 13 Nov 2002 18:09:33 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gADH9SlO103346; Wed, 13 Nov 2002 18:09:31 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA69238 from ; Wed, 13 Nov 2002 18:09:26 +0100 Message-Id: <3DD28736.BD7E8D8@hursley.ibm.com> Date: Wed, 13 Nov 2002 18:09:10 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Vladislav Yasevich Cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up References: <3DD0F9AC.FF821AAA@hursley.ibm.com> <3DD27352.6070104@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vladislav Yasevich wrote: > > Brian E Carpenter wrote: > > > > Proposed new text: > > > > Site-local addresses are designed to be used for addressing inside of > > a site which is not connected to the Internet and therefore does not > > need a global prefix. They must not be used for a site that is connected > > to the Internet. Using site-local addresses, a subnet ID may be up to > > 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > > for convenience if the site is later connected to the Internet using a > > global prefix. > > > > I have some reservations about this this proposal from the implementors > point of of view. > > The proposal uses the words "must no" (lower case) and that makes it > somewhat unclear and brings up the following questions. > > If the implemenation supports the use of site-locals when a global prefix > is availiable and the node is connected to the "global internet", is the > implementation compliante with the addr-arch? > > If the node is configured with both site-locals and globals, is the > configuration addr-arch compliant? > > IMHO, it would almost be easier to remove the "must not be used" sentence > from the above paragraph. Yes, I like that suggestion. It's consistent with Harald's comment that we don't have an enforcement department. 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 Nov 13 09:14:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADHE9kd008311; Wed, 13 Nov 2002 09:14:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADHE9Va008310; Wed, 13 Nov 2002 09:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADHE5kd008303 for ; Wed, 13 Nov 2002 09:14:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADHEFMq022535 for ; Wed, 13 Nov 2002 09:14:15 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05014; Wed, 13 Nov 2002 10:14:09 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gADHDpKV013286; Wed, 13 Nov 2002 18:13:51 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 13 Nov 2002 18:13:51 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0CEE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Richard Carlson'" , Keith Moore , alh-ietf@tndh.net Cc: "'Keith Moore'" , "'Bound, Jim'" , "'Alain Durand'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: RE: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 18:13:46 +0100 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 > Keith; > > At 09:27 PM 11/12/02 -0500, Keith Moore wrote: > >[snip snip snip] > >No. Scopes reduce the ablity of the network to support apps. > >They make it harder to produce an app that works independently > >of network location, and they don't add a single extra capability > >that wasn't present already. > > You keep saying that some apps will fail with scoped > addresses. My poor > brain can't grasp why this is so. Can you give me a > detailed example of > how an app will fail if it has multiple scoped addresses to > choice from? => I think he did to some extent, but the point is Brian Z. and Rich already showed how this can be done. Sure there is additional complexity, but didn't we know this 3 years ago ? I think we did. Harald's email is a good example of the complexities introduced in the DNS, but it is solveable, that's why I think a BCP will be much more convincing than changing a couple of lines in the existing RFC. 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 Wed Nov 13 09:30:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADHUhkd008733; Wed, 13 Nov 2002 09:30:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADHUghM008732; Wed, 13 Nov 2002 09:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADHUdkd008725 for ; Wed, 13 Nov 2002 09:30:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADHUnMq028035 for ; Wed, 13 Nov 2002 09:30:49 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17034 for ; Wed, 13 Nov 2002 10:30:43 -0700 (MST) 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 JAA21741; Wed, 13 Nov 2002 09:30:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gADHUhr09710; Wed, 13 Nov 2002 09:30:43 -0800 X-mProtect: <200211131730> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (216.83.56.167, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdirIyS9; Wed, 13 Nov 2002 09:30:40 PST Message-Id: <4.3.2.7.2.20021113092141.0306dea0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Nov 2002 09:30:23 -0800 To: Brian E Carpenter From: Bob Hinden Subject: Re: Summary Re: Proposal for site-local clean-up Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3DD26798.E0B165F4@hursley.ibm.com> References: <3DD0F9AC.FF821AAA@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 Brian, I don't think it is wise to ask the IESG to reconsider the address architecture (this is more than an editorial change to the RFC-editor). I also think the issues regarding the usage of site-local are more complicated that can be expressed in a paragraph. I don't think we will get a consensus on this one way or another. This is IMHO about people making different benefit vs. complexity tradeoffs. Like many other things in the IETF that there is disagreement on, I think it is better to document what it is and why it isn't a good idea and move on. 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 Nov 13 09:46:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADHkUkd008922; Wed, 13 Nov 2002 09:46:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADHkU3g008921; Wed, 13 Nov 2002 09:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADHkRkd008914 for ; Wed, 13 Nov 2002 09:46:27 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADHkaMq003093 for ; Wed, 13 Nov 2002 09:46:36 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01788 for ; Wed, 13 Nov 2002 10:46:31 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 13 Nov 2002 09:46:35 -0800 Reply-To: From: "Tony Hain" To: "'Brian E Carpenter'" , Subject: RE: Summary Re: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 09:46:20 -0800 Message-ID: <07ea01c28b3c$93492c20$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3DD26798.E0B165F4@hursley.ibm.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADHkRkd008915 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > Well, there are far more people saying yes than no, but let > me respond to some of the comments made. > > 1. Process (Tony Hain). Of course. If we make a substantive > change to a draft that's already passed the IESG, a last call > is needed IMHO. It would still be cleaner than publishing the > RFC and then publishing a change. The way I read the thread, the plan was to simply change a few words in the RFC editor queue. In any case, this is more than a few words, it is a major architectural change and would require recycling to the WG & PS. > > 2. Rationale. (several people). Yes, it might be good to > publish an informational document about this. That might well > belong in v6ops. > > 3. Can't stop NAT's anyway. (several people). That may sadly > be true, but we shouldn't publish specs that seem to encourage them. Preventing simultaneous use of SL & Global will in fact encourage NAT. Network managers require that some nodes are invisible to the global network. Most will find it easier to force the systems that need public access to use NAT, rather than try to maintain a lengthy filter list at the border for those that don't. Giving them the tool that allows easy filtering, with simultaneous with global addresses for those nodes that need it, is the only real way to avoid NAT. > > 4. Impact on existing implementations and ongoing work. > (several people). I don't really understand what the > implementation change would be - surely this is basically a > configuration issue? Products will still have to support SL. > If we are going to impact ongoing work, however, the sooner > the better. This is not a simple address format change, it is a major architectural issue. All the implementations that already know how to deal with simultaneous scopes will have to do major surgery strip that out, or ship non-compliant code. > > 5. Why not just kill SL completely? (JINMEI) That would > definitely annoy implementors, and close off our options. > > 6. We have to handle multiple scopes anyway (Brian Zill, Tony > Hain). Right. And by retaining SL, we retain the option of > reversing the "disconnected" decision if we ever do figure > out how to handle them properly. People already know how to deal with 'connected' 1918 space, this is no different in that respect. What is different is the architectural change to support simultaneous use of multiple scopes. This is not rocket science, it just requires working through the engineering of the new edge cases. Tony > > 7. must not v. MUST NOT (Keith Moore). The document as a > whole doesn't use upper case. > > Brian > > Brian E Carpenter wrote: > > > > 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, in order to > > change the following paragraph in section 2.5.6: > > > > Current text: > > > > > Site-local addresses are designed to be used for > addressing inside of > > > a site without the need for a global prefix. Although > a subnet ID > > > may be up to 54-bits long, it is expected that > globally-connected > > > sites will use the same subnet IDs for site-local and global > > > prefixes. > > > > Proposed new text: > > > > Site-local addresses are designed to be used for > addressing inside of > > a site which is not connected to the Internet and > therefore does not > > need a global prefix. They must not be used for a site > that is connected > > to the Internet. Using site-local addresses, a subnet ID > may be up to > > 54-bits long, but it is recommended to use at most > 16-bit subnet IDs, > > for convenience if the site is later connected to the > Internet using a > > global prefix. > > > > Otherwise, we will need a whole new RFC just for this paragraph. > > > > Alternatively, we could spend the next 5 years discussing the > > unnecessary complexities of using site-locals on connected sites. > > > > Brian > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment at the IBM Zurich Laboratory, Switzerland > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 10:05:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADI5rkd009161; Wed, 13 Nov 2002 10:05:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADI5rtR009160; Wed, 13 Nov 2002 10:05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADI5okd009153 for ; Wed, 13 Nov 2002 10:05:50 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADI5xMq009874 for ; Wed, 13 Nov 2002 10:05:59 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17070 for ; Wed, 13 Nov 2002 10:05:54 -0800 (PST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gADI5eaE025840; Wed, 13 Nov 2002 10:05:40 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAP20227; Wed, 13 Nov 2002 10:00:08 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA15478; Wed, 13 Nov 2002 10:05:49 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15826.38013.831018.310008@thomasm-u1.cisco.com> Date: Wed, 13 Nov 2002 10:05:49 -0800 (PST) To: Harald Tveit Alvestrand Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-Reply-To: <47630000.1037180107@askvoll.hjemme.alvestrand.no> References: <3DD0F9AC.FF821AAA@hursley.ibm.com> <47630000.1037180107@askvoll.hjemme.alvestrand.no> 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 So I have a question for those who support connected site locals: what would prevent a new RFC from updating Brian's wording for site locals (if that's the right thing)? I say this because it seems to me that there's a lot of issues being conflated in these arguments and what's sort of frightening to me is that they need to be teased apart. In particular, the desire for provider independent addressing seems to factor in here fairly largely too, and I wonder if the better part of valor might not be to get together a BOF which focuses on the actual real life requirements here. It's possible that site locals in the end might make sense here, but it's also possible that it can be done other ways too (or that the entire problem is totally intractable which is the way it looks to me now). Mike Harald Tveit Alvestrand writes: > I think Brian's proposal, if adopted, makes my worry about site-locals > inducing complexity in naming lookup mechanisms go away (naming mechanisms > for disconnected networks have to be different from those for connected > networks anyway). > > So you can count me as supporting the proposal. > > That said, I also think that writing down (some of) the arguments on the > issue in permanent form would be a good idea...... and there are a few > devils-in-the-details having to do with the transition between > connectedness and disconnectedness, which also could use some > words-on-electrons. > > But this resolution seems basically right to me. > > Harald > > --On tirsdag, november 12, 2002 13:53:00 +0100 Brian E Carpenter > wrote: > > > 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, > > in order to change the following paragraph in section 2.5.6: > > > > Current text: > > > >> Site-local addresses are designed to be used for addressing inside of > >> a site without the need for a global prefix. Although a subnet ID > >> may be up to 54-bits long, it is expected that globally-connected > >> sites will use the same subnet IDs for site-local and global > >> prefixes. > > > > Proposed new text: > > > > Site-local addresses are designed to be used for addressing inside of > > a site which is not connected to the Internet and therefore does not > > need a global prefix. They must not be used for a site that is > > connected to the Internet. Using site-local addresses, a subnet ID may > > be up to 54-bits long, but it is recommended to use at most 16-bit > > subnet IDs, for convenience if the site is later connected to the > > Internet using a global prefix. > > > > Otherwise, we will need a whole new RFC just for this paragraph. > > > > Alternatively, we could spend the next 5 years discussing the > > unnecessary complexities of using site-locals on connected sites. > > > > Brian > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 10:31:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADIVWkd009451; Wed, 13 Nov 2002 10:31:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADIVWGL009450; Wed, 13 Nov 2002 10:31: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADIVSkd009440 for ; Wed, 13 Nov 2002 10:31:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADIVbbB012717 for ; Wed, 13 Nov 2002 10:31:37 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00521 for ; Wed, 13 Nov 2002 11:31:31 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADIVLl11059; Wed, 13 Nov 2002 13:31:25 -0500 (EST) Message-Id: <200211131831.gADIVLl11059@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Keith Moore'" , "'Brian Zill'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 08:41:53 PST.") <07d601c28b33$9296bb20$bd134104@eagleswings> Date: Wed, 13 Nov 2002 13:31:21 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > the closest thing we have to a workable solution is to find a > > way to give every site that connects to another network a > > global prefix > > (whether it's globally connected or not) and have applications > > ignore the SLs (at least for purpose of referrals). and if you do > > that, there is little point in having SLs at all except for > > isolated networks - they just complicate management and DNS > > etc. for the networks that use them. > > It doesn't matter how many times you write this, you can not make it > become true. Brian keeps pointing out the simple case of an > intermittently connected network getting a different prefix on each > connect, but you keep ignoring it. STABLE ADDRESS SPACE IS A MAJOR > APPLICATION REASON TO HAVE SL. I don't disagree that currently the best solution for intermittently connected networks is SLs. That still doesn't make them work well with applications. (and no I haven't ignored this, actually I've explicitly cited this as a valid use case for SLs) > Also, as I have said multiple times, getting rid of SL does not create > PI space. When PI space is available, people will most likely recognize > that it is easier to deal with than SL, and will naturally migrate. We agree that PI space is needed. > Even > when it is available, that does not automatically create a reason to > restrict the use of SL. It will always be easier to filter a short /10 > than to maintain a long list of access controls at the border. THIS IS A > MAJOR OPERATIONAL REASON TO USE SL. NO IT IS NOT. First, you're not comparing the same cases here - you're assuming in one case that a filter will block off an entire network, and in another case you're assuming that the site will need and use a long list of access controls. What you seem to be arguing is that sites don't need the flexibility to block or permit external traffic to individual hosts, nor do they need the flexibility to block or permit traffic within their internal networks. I don't buy it. > It is appropriate that we have a document describing the impact on > multi-party apps using literal referrals, and another on guidance on DNS > configurations. We have discussed the first many times, and the second > is nothing more than formalizing what people have been already doing in > the face of 1918 space. Formalizing that practice is exactly the wrong thing to do - it degrades the value of DNS for use by applications. 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 Nov 13 10:44:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADIiqkd009622; Wed, 13 Nov 2002 10:44:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADIiolx009621; Wed, 13 Nov 2002 10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADIikkd009614 for ; Wed, 13 Nov 2002 10:44:46 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADIiuMq022774 for ; Wed, 13 Nov 2002 10:44:56 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00704 for ; Wed, 13 Nov 2002 10:44:50 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADIhul11093; Wed, 13 Nov 2002 13:43:56 -0500 (EST) Message-Id: <200211131843.gADIhul11093@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Richard Carlson cc: Keith Moore , alh-ietf@tndh.net, "'Bound, Jim'" , "'Alain Durand'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 10:48:52 CST.") <5.1.1.5.2.20021113102825.025644c0@atalanta.ctd.anl.gov> Date: Wed, 13 Nov 2002 13:43:56 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >No. Scopes reduce the ablity of the network to support apps. > >They make it harder to produce an app that works independently > >of network location, and they don't add a single extra capability > >that wasn't present already. > > You keep saying that some apps will fail with scoped addresses. My poor > brain can't grasp why this is so. Can you give me a detailed example of > how an app will fail if it has multiple scoped addresses to choice from? example 1: Process A sends the addresses of process B to process C. Processes B and C are in different scopes. (Either one might or might not share a scope with A.) Process C cannot communicate with process B using SLs that it has received from A. example 2: A sends the addresses of B to C. This time B and C are in the same scope, but A does not have access to that scope. If A sends the SL addresses of B to C, C can talk to B. However A has no way of knowing whether this is the case. If on the other hand A filters SLs in addresses that it sends to C (as some have suggested is appropriate), C may be unable to talk to B for lack of an address that works, even though B and C share an address scope. In either example the problem is solved if B and C have global addresses, and all referrals filter SL addresses. But that's not realistic given current address allocation policies. And if we change the address allocation policies to permit any network to get a global prefix, there's even less reason to have SLs. > I don't mean that it may be hard to for the app to decide which address to > use. Yes that's a hard problem, and we don't have a solution to it yet, > but that doesn't seem a good enough reason to kill site locals to me. Standards-track protocols are supposed to have no known technical omissions with respect to the requirements placed on them, and are supposed to have resolved known issues. An addressing architecture that expects apps to solve an unsolved problem that is acknowledged to be difficult doesn't seem like it meets either of those criteria. > I also don't mean that an app can get confused and it will fail to connect to > the correct proper destination if it uses a scoped address at the wrong > time. Yes this can happen, but it's still part of the address selection > problem, not a basic problem with an app. Address selection doesn't solve this problem. Basically what the app has to do is implement its own addressing (so it can disambiguate hosts using the same address) and routing (so it can operate across site boundaries - because this will be necessary for many apps). > I'm looking for something like FTP and NAT. FTP exchanges IP addresses in > data messages which fail when NATs cause these addresses to change. There > are all kinds of kludges that try to work around this problem, but the > basic issue is that the E2E property of IP was lost and the apps suffer for > this change. > > I don't see the same thing happening with site-local's, everyone agrees > that they aren't a v6 NAT replacement so apps are not allowed to propagate > site locals outside of the site boundary. No, everyone does not agree on that. First because apps aren't aware of topology so they don't know when they're propagating an address outside of a site boundary. Second because expecting apps to be aware of topology imposes too much of a burden on those apps. Third because if those apps don't have alternatives to using SLs they'll be forced to use them. Fourth because if the apps reliably do have alternatives to SLs (for networks that aren't isolated) then there's not much reason to have SLs at all. > Yes, hosts need to be aware of > the site boundary, no, not hosts. hosts aren't making those decisions. apps are. > but that is still an address selection problem not a > problem with the app itself. Site-locals are unique within the site > boundaries and look just like a global IPv6 address, so what is a specific > example where an app will be broken by using a site-local address? see above. 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 Nov 13 10:52:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADIqtkd009798; Wed, 13 Nov 2002 10:52:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADIqsIQ009797; Wed, 13 Nov 2002 10:52:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADIqpkd009790 for ; Wed, 13 Nov 2002 10:52:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADIr1Mq025643 for ; Wed, 13 Nov 2002 10:53:01 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12982 for ; Wed, 13 Nov 2002 11:52:55 -0700 (MST) 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 KAA26655 for ; Wed, 13 Nov 2002 10:52:55 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gADIqsx00586 for ; Wed, 13 Nov 2002 10:52:54 -0800 X-mProtect: <200211131852> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPvh6lO; Wed, 13 Nov 2002 10:52:53 PST Message-ID: <3DD2A0A2.90005@iprg.nokia.com> Date: Wed, 13 Nov 2002 10:57:38 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up References: <07ea01c28b3c$93492c20$bd134104@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So much traffic has flown by on this subject that my head is still spinning. But, let me give one example in which the use of site-locals on globally connected networks might be useful. While at SRI International, I had the privilege of participating in a study of autonomous teams of unmanned vehciles with the Office of Naval Research. Such teams may consist of hundreds/thousands of mobile vehicles that travel together in a more-or-less coordinated fashion. Communications are nicely modeled by Mobile Ad-hoc Networking, as in the IETF MANET WG. Very large teams may be organized into "clusters" based on geography, commonalities of interest, etc. Finally, the team as a whole is only intermittently connected to the global Internet - perhaps with long periods of disconnected operation. When the team is out of contact with the global Internet, site-locals can provide a nice means to facilitate intra-cluster and inter-cluster communcations. When the team comes in contact with an access router(s) to the the global Internet, the global prefixes can be disemminated to team members that need global access. But since the team is mobile, global access may be intermittent, with new global prefixes learned as different access routers are encountered. So it seems tome that site-locals can provide a useful mechanism for large mobile networks with intermittent global connectivity. 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 Nov 13 10:55:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADItqkd009875; Wed, 13 Nov 2002 10:55:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADItq8K009874; Wed, 13 Nov 2002 10:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADItmkd009864 for ; Wed, 13 Nov 2002 10:55:48 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADItvbB020977 for ; Wed, 13 Nov 2002 10:55:58 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08497 for ; Wed, 13 Nov 2002 10:55:52 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADIthl11149; Wed, 13 Nov 2002 13:55:43 -0500 (EST) Message-Id: <200211131855.gADIthl11149@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (EAB)" cc: "'Richard Carlson'" , Keith Moore , alh-ietf@tndh.net, "'Bound, Jim'" , "'Alain Durand'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 18:13:46 +0100.") <4DA6EA82906FD511BE2F00508BCF0538044F0CEE@Esealnt861.al.sw.ericsson.se> Date: Wed, 13 Nov 2002 13:55:43 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => I think he did to some extent, but the point > is Brian Z. and Rich already showed how this can be > done. Sure there is additional complexity, but > didn't we know this 3 years ago ? I think we did. It is simply not acceptable to expect apps to absorb all of this complexity for the sake of the dubious and marginal amount of additional functionality that SLs provide. And the fact that serious mistakes were made in the past is not an excuse for propagating them -- particuarly not when staying with the status quo is far more disruptive than reducing use of SLs. 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 Nov 13 10:57:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADIvQkd009924; Wed, 13 Nov 2002 10:57:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADIvQts009923; Wed, 13 Nov 2002 10:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADIvLkd009909 for ; Wed, 13 Nov 2002 10:57:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADIvVbB021465 for ; Wed, 13 Nov 2002 10:57:31 -0800 (PST) Received: from esunmail ([129.147.58.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16534 for ; Wed, 13 Nov 2002 11:57:25 -0700 (MST) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5J0029G3BO2U@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 13 Nov 2002 11:57:25 -0700 (MST) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H5J00HP13BOYE@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 13 Nov 2002 11:57:24 -0700 (MST) Date: Wed, 13 Nov 2002 10:57:22 -0800 From: Alain Durand Subject: Re: Proposal for site-local clean-up To: NOISETTE Yoann FTRD/DMI/CAE Cc: ipng@sunroof.eng.sun.com Message-id: <3DD2A092.5030907@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 NOISETTE Yoann FTRD/DMI/CAE wrote: >Hi all, > >I would possibly agree with this change, but it must be clear that some >ongoing work or considered solutions will be restricted or even totally >impossible after this new statement becomes effective. >For instance, draft-ietf-ipv6-dns-discovery-07.txt gives many examples >of a Customer site, using site-local addresses (in particular for DNS >discovery), and this Customer site is connected to an ISP (thus >certainly I presume to the Internet)... > That document could be changed to use global addresses instead of site local if Brian's proposal gets adopted. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 11:03:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJ3vkd010096; Wed, 13 Nov 2002 11:03:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADJ3vIx010095; Wed, 13 Nov 2002 11:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJ3skd010088 for ; Wed, 13 Nov 2002 11:03:54 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADJ43bB024135 for ; Wed, 13 Nov 2002 11:04:04 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23824 for ; Wed, 13 Nov 2002 12:03:58 -0700 (MST) 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 LAA27497 for ; Wed, 13 Nov 2002 11:03:58 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gADJ3vu20139 for ; Wed, 13 Nov 2002 11:03:57 -0800 X-mProtect: <200211131903> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7ktwcl; Wed, 13 Nov 2002 11:03:56 PST Message-ID: <3DD2A339.1070700@iprg.nokia.com> Date: Wed, 13 Nov 2002 11:08:41 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up References: <07ea01c28b3c$93492c20$bd134104@eagleswings> <3DD2A0A2.90005@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 FWIW, This study, along with others in the US Army CECOM division, produced the transition mechansim now known as ISATAP. Fred Templin ftemplin@iprg.nokia.com Fred L. Templin wrote: > So much traffic has flown by on this subject that my head is still > spinning. > But, let me give one example in which the use of site-locals on globally > connected networks might be useful. > > While at SRI International, I had the privilege of participating in a > study of > autonomous teams of unmanned vehciles with the Office of Naval Research. > Such > teams may consist of hundreds/thousands of mobile vehicles that travel > together > in a more-or-less coordinated fashion. Communications are nicely modeled by > Mobile Ad-hoc Networking, as in the IETF MANET WG. Very large teams may be > organized into "clusters" based on geography, commonalities of interest, > etc. Finally, the team as a whole is only intermittently connected to the > global Internet - perhaps with long periods of disconnected operation. > > When the team is out of contact with the global Internet, site-locals > can provide > a nice means to facilitate intra-cluster and inter-cluster > communcations. When the > team comes in contact with an access router(s) to the the global > Internet, the global > prefixes can be disemminated to team members that need global access. > But since the > team is mobile, global access may be intermittent, with new global > prefixes learned > as different access routers are encountered. > > So it seems tome that site-locals can provide a useful mechanism for > large mobile > networks with intermittent global connectivity. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 11:29:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJTPkd010545; Wed, 13 Nov 2002 11:29:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADJTPkS010544; Wed, 13 Nov 2002 11:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJTLkd010537 for ; Wed, 13 Nov 2002 11:29:21 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADJTVMq007979 for ; Wed, 13 Nov 2002 11:29:31 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26903 for ; Wed, 13 Nov 2002 11:29:25 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADJTNl11555; Wed, 13 Nov 2002 14:29:23 -0500 (EST) Message-Id: <200211131929.gADJTNl11555@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Vladislav Yasevich , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 18:09:10 +0100.") <3DD28736.BD7E8D8@hursley.ibm.com> Date: Wed, 13 Nov 2002 14:29:23 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > IMHO, it would almost be easier to remove the "must not be used" sentence > > from the above paragraph. > > Yes, I like that suggestion. It's consistent with Harald's comment > that we don't have an enforcement department. Well, I don't think the paragraph is sufficient without it. How about saying that - SLs are known to cause problems for DNS and other applications - the security benefits of SL are dubious and marginal at best - until the issues associated with exposing applications to mixed scopes are better understood, SLs SHOULD NOT be used on networks that also use global 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 Nov 13 11:30:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJUIkd010565; Wed, 13 Nov 2002 11:30:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADJUIpb010564; Wed, 13 Nov 2002 11:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJUEkd010557 for ; Wed, 13 Nov 2002 11:30:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADJUNbB003079 for ; Wed, 13 Nov 2002 11:30:24 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13377 for ; Wed, 13 Nov 2002 12:30:18 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id OAA25937; Wed, 13 Nov 2002 14:30:14 -0500 (EST) Date: Wed, 13 Nov 2002 14:30:14 -0500 (EST) From: Dan Lanciani Message-Id: <200211131930.OAA25937@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Naming and site-local addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: |> |Neither does it scale to expect all hosts to maintain |> |enough information to let them do routing. |> |> On the contrary, distributed host-based routing is one of the few solutions |> that does scale well. The availability of resources to deal with the routing |> grows directly in proportion to the consumers of those resources. | |that incorrectly assumes that the only 'resource' in question is cpu time No. Apart from all the resources provided by the host itself (including not only cpu time but also temporary and long-term storage) the aggregate bandwidth of the network grows as well. 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 Nov 13 11:36:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJaPkd010648; Wed, 13 Nov 2002 11:36:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADJaPr1010647; Wed, 13 Nov 2002 11:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJaLkd010640 for ; Wed, 13 Nov 2002 11:36:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADJaUbB005124 for ; Wed, 13 Nov 2002 11:36:31 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21684 for ; Wed, 13 Nov 2002 12:36:21 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 13 Nov 2002 11:36:25 -0800 Reply-To: From: "Tony Hain" To: Cc: "'Brian Zill'" , Subject: RE: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 11:36:10 -0800 Message-ID: <07f301c28b4b$eb51a640$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211131831.gADIVLl11059@astro.cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADJaLkd010641 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > > Even > > when it is available, that does not automatically create a > reason to > > restrict the use of SL. It will always be easier to filter > a short /10 > > than to maintain a long list of access controls at the > border. THIS IS > > A MAJOR OPERATIONAL REASON TO USE SL. > > NO IT IS NOT. First, you're not comparing the same cases > here - you're > assuming in one case that a filter will block off an entire > network, and in > another case you're assuming that the site will need and use > a long list of access controls. What you seem to be arguing > is that sites don't need the flexibility to block or permit > external traffic to individual hosts, > nor do they need the flexibility to block or permit traffic > within their internal networks. I don't buy it. I don't know how you can get from needing a simple filter to not needing a filter... A simple example would be; as per spec, SL is blocked at the border, globals are allowed without restriction, and hosts that are allowed out have a policy that allows them to configure a global prefix along with the SL one, while those that are not allowed out have a policy that only allows configuring an SL prefix. Address selection says use the smallest scope, so internal communications use SL and are forced to stay internal by the hard filter at the border. This puts the burden of policy application at the address assignment time (very infrequent) rather than parsing every packet for access control. > > > It is appropriate that we have a document describing the impact on > > multi-party apps using literal referrals, and another on > guidance on > > DNS configurations. We have discussed the first many times, and the > > second is nothing more than formalizing what people have > been already > > doing in the face of 1918 space. > > Formalizing that practice is exactly the wrong thing to do - > it degrades > the value of DNS for use by applications. You are trying to legislate against current practice, rather than documenting it so that app developers can understand the real environment. 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 Nov 13 11:50:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJookd011085; Wed, 13 Nov 2002 11:50:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADJooYi011084; Wed, 13 Nov 2002 11:50:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJokkd011074 for ; Wed, 13 Nov 2002 11:50:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADJotMq015530 for ; Wed, 13 Nov 2002 11:50:55 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26352 for ; Wed, 13 Nov 2002 12:50:43 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADJoYl11627; Wed, 13 Nov 2002 14:50:34 -0500 (EST) Message-Id: <200211131950.gADJoYl11627@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: Summary Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 09:46:20 PST.") <07ea01c28b3c$93492c20$bd134104@eagleswings> Date: Wed, 13 Nov 2002 14:50:34 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Well, there are far more people saying yes than no, but let > > me respond to some of the comments made. > > > > 1. Process (Tony Hain). Of course. If we make a substantive > > change to a draft that's already passed the IESG, a last call > > is needed IMHO. It would still be cleaner than publishing the > > RFC and then publishing a change. > > The way I read the thread, the plan was to simply change a few words in > the RFC editor queue. In any case, this is more than a few words, it is > a major architectural change and would require recycling to the WG & PS. We don't normally require recycling to proposed when we fix bugs in a standards-track document while it advances. Indeed, that's the reason we advance documents in grade - so we can revise them in light of mistakes discovered in earlier versions. Nor is there anything in the process that requires documents to be recycled to a WG when bugs are found - in most cases the WG is no longer around. How the document is handled is up to IESG. > > 3. Can't stop NAT's anyway. (several people). That may sadly > > be true, but we shouldn't publish specs that seem to encourage them. > > Preventing simultaneous use of SL & Global will in fact encourage NAT. no, not "in fact". that's just a figure of speech. > Network managers require that some nodes are invisible to the global > network. Most will find it easier to force the systems that need public > access to use NAT, rather than try to maintain a lengthy filter list at > the border for those that don't. Neither SL nor NAT will save those sites from having to maintain a filter list. If some hosts on network are allowed to be exposed to the outside and others aren't, the list of exceptions has to be maintained somewhere. > Giving them the tool that allows easy > filtering, with simultaneous with global addresses for those nodes that > need it, is the only real way to avoid NAT. But the only way to make SLs work on a network that has external connections is to give all nodes global addresses. You can't just assign "global addresses for those nodes that need it" without burdening apps that need to talk to the other hosts with having to do their own addressing and routing. The strategy that you are advocating is precisely what we need to discourage. It's no better than NATs. If it's widely adopted it will destroy the additional utility that IPv6 provides over IPv4. If sites want to use NAT they should stick with IPv4. > > 4. Impact on existing implementations and ongoing work. > > (several people). I don't really understand what the > > implementation change would be - surely this is basically a > > configuration issue? Products will still have to support SL. > > If we are going to impact ongoing work, however, the sooner > > the better. > > This is not a simple address format change, it is a major architectural > issue. All the implementations that already know how to deal with > simultaneous scopes will have to do major surgery strip that out, or > ship non-compliant code. No they won't. It will just be code that isn't exercised. And I disagree that there are implementations that "know how to deal with simultaneous scopes". Those implementations are almost certainly making unwarranted assumptions (or imposing unreasonable constraints, if you prefer) about how people organize their networks. > > 5. Why not just kill SL completely? (JINMEI) That would > > definitely annoy implementors, and close off our options. > > > > 6. We have to handle multiple scopes anyway (Brian Zill, Tony > > Hain). Right. And by retaining SL, we retain the option of > > reversing the "disconnected" decision if we ever do figure > > out how to handle them properly. > > People already know how to deal with 'connected' 1918 space, No they do not. There is no general solution, there are lots of hacks that work only for constrained cases. The closest thing to a general solution is Teredo, but even that will fail if SLs are widely used in IPv6. > this is no > different in that respect. What is different is the architectural change > to support simultaneous use of multiple scopes. This is not rocket > science, it just requires working through the engineering of the new > edge cases. First of all, it's not engineering, since we don't yet know how to solve the problem. Second, there isn't enough benefit to justify the investment in the effort much less the burden on applications. 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 Nov 13 11:56:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJuxkd011168; Wed, 13 Nov 2002 11:56:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADJuxgH011167; Wed, 13 Nov 2002 11:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJutkd011160 for ; Wed, 13 Nov 2002 11:56:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADJv4Mq017479 for ; Wed, 13 Nov 2002 11:57:04 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04664 for ; Wed, 13 Nov 2002 12:56:59 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADJurl11661; Wed, 13 Nov 2002 14:56:53 -0500 (EST) Message-Id: <200211131956.gADJurl11661@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, "'Brian Zill'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 11:36:10 PST.") <07f301c28b4b$eb51a640$bd134104@eagleswings> Date: Wed, 13 Nov 2002 14:56:53 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't know how you can get from needing a simple filter to not needing > a filter... > A simple example would be; as per spec, SL is blocked at the border, > globals are allowed without restriction, and hosts that are allowed out > have a policy that allows them to configure a global prefix along with > the SL one, while those that are not allowed out have a policy that only > allows configuring an SL prefix. Address selection says use the smallest > scope, so internal communications use SL and are forced to stay internal > by the hard filter at the border. This puts the burden of policy > application at the address assignment time (very infrequent) rather than > parsing every packet for access control. this is not workable for several reasons. first, it expects apps to work across site boundaries betwen hosts that use SLs. that's simply unacceptable. second, it's not secure without filtering. third, address selection is not a policy mechanism, it is a default behavior, that applications are free to ignore - and there are many cases where it's highly desirable that they do so. fourth, the idea that address selection for internal communications does not affect external communications is naive. > You are trying to legislate against current practice, rather than > documenting it so that app developers can understand the real > environment. You are trying to force a practice that is known to be broken, and the burden of trying to make apps work in the face of that broken practice, on everyone. There is no way that this can be justified. 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 Nov 13 11:59:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJxFkd011207; Wed, 13 Nov 2002 11:59:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADJxFVg011206; Wed, 13 Nov 2002 11:59: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADJxBkd011199 for ; Wed, 13 Nov 2002 11:59:11 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADJxKbB012655 for ; Wed, 13 Nov 2002 11:59:21 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08277 for ; Wed, 13 Nov 2002 12:59:15 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADJxBl11725; Wed, 13 Nov 2002 14:59:12 -0500 (EST) Message-Id: <200211131959.gADJxBl11725@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Fred L. Templin" cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 10:57:38 PST.") <3DD2A0A2.90005@iprg.nokia.com> Date: Wed, 13 Nov 2002 14:59:11 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Finally, the team as a whole is only intermittently connected to the > global Internet - perhaps with long periods of disconnected operation. yes, intermittent connection is one of the genuinely valid justifications for SLs. however even with intermittent connection it is often possible to use globals rather than SLs. the exception is a nomadic network that connects to the net at different locations at different times, and whose hosts don't have home agent(s) for mobile IP. 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 Nov 13 12:01:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADK1Wkd011274; Wed, 13 Nov 2002 12:01:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADK1W5n011273; Wed, 13 Nov 2002 12: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADK1Skd011266 for ; Wed, 13 Nov 2002 12:01:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADK1bMq019171 for ; Wed, 13 Nov 2002 12:01:37 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10345 for ; Wed, 13 Nov 2002 13:01:32 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADK1Ul11764; Wed, 13 Nov 2002 15:01:30 -0500 (EST) Message-Id: <200211132001.gADK1Ul11764@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: Naming and site-local addresses In-reply-to: (Your message of "Wed, 13 Nov 2002 14:30:14 EST.") <200211131930.OAA25937@ss10.danlan.com> Date: Wed, 13 Nov 2002 15:01:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > |> |Neither does it scale to expect all hosts to maintain > |> |enough information to let them do routing. > |> > |> On the contrary, distributed host-based routing is one of the few solutions > |> that does scale well. The availability of resources to deal with the > |> routing > |> grows directly in proportion to the consumers of those resources. > | > |that incorrectly assumes that the only 'resource' in question is cpu time > > No. Apart from all the resources provided by the host itself (including > not only cpu time but also temporary and long-term storage) the aggregate > bandwidth of the network grows as well. Not the effective bandwidth as seen by applications that are waiting for their hosts to determine a route that works in the absence of reliable, current, and complete information about the network. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 12:24:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADKOUkd011884; Wed, 13 Nov 2002 12:24:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADKOUT1011883; Wed, 13 Nov 2002 12:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADKORkd011876 for ; Wed, 13 Nov 2002 12:24:27 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADKOZbB021099 for ; Wed, 13 Nov 2002 12:24:36 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25918 for ; Wed, 13 Nov 2002 13:24:30 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 13 Nov 2002 12:24:34 -0800 Reply-To: From: "Tony Hain" To: "'Keith Moore'" Cc: "'Brian E Carpenter'" , Subject: RE: Summary Re: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 12:24:19 -0800 Message-ID: <07f601c28b52$a552c780$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211131950.gADJoYl11627@astro.cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADKORkd011877 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > > Well, there are far more people saying yes than no, but let me > > > respond to some of the comments made. > > > > > > 1. Process (Tony Hain). Of course. If we make a > substantive change > > > to a draft that's already passed the IESG, a last call is needed > > > IMHO. It would still be cleaner than publishing the RFC and then > > > publishing a change. > > > > The way I read the thread, the plan was to simply change a > few words > > in the RFC editor queue. In any case, this is more than a > few words, > > it is a major architectural change and would require > recycling to the > > WG & PS. > > We don't normally require recycling to proposed when we fix > bugs in a standards-track document while it advances. > Indeed, that's the > reason we advance documents in grade - so we can revise them > in light of mistakes discovered in earlier versions. > > Nor is there anything in the process that requires documents to be > recycled to a WG when bugs are found - in most cases the WG > is no longer around. How the document is handled is up to IESG. This is not a bug, it is an architectural principle. Those are not changed on a whim after the review process has completed. > > > > 3. Can't stop NAT's anyway. (several people). That may sadly be > > > true, but we shouldn't publish specs that seem to encourage them. > > > > Preventing simultaneous use of SL & Global will in fact > encourage NAT. > > no, not "in fact". that's just a figure of speech. > > > Network managers require that some nodes are invisible to > the global > > network. Most will find it easier to force the systems that need > > public access to use NAT, rather than try to maintain a > lengthy filter > > list at the border for those that don't. > > Neither SL nor NAT will save those sites from having to > maintain a filter list. If some hosts on network are allowed > to be exposed to the outside and others aren't, the list of > exceptions has to be maintained somewhere. Yes, but putting that in the address allocation process scales better than having to scan a 10,000 entry list for each packet. > > > Giving them the tool that allows easy > > filtering, with simultaneous with global addresses for those nodes > > that need it, is the only real way to avoid NAT. > > But the only way to make SLs work on a network that has > external connections is to give all nodes global addresses. > You can't just assign "global addresses for those nodes that > need it" without burdening apps that need to talk to the > other hosts with having to do their own addressing and > routing. Read draft-ietf-ipv6-default-addr-select-09.txt for instructions on sorting that out. > > The strategy that you are advocating is precisely what we > need to discourage. It's no better than NATs. If it's widely > adopted it will destroy the additional utility that IPv6 > provides over IPv4. How does use of unmolested global addresses become what we have today? Nodes that need global access get a global address for that along with a SL for internal use, and those that don't get only a SL. > > If sites want to use NAT they should stick with IPv4. > > > > 4. Impact on existing implementations and ongoing work. (several > > > people). I don't really understand what the implementation change > > > would be - surely this is basically a configuration > issue? Products > > > will still have to support SL. If we are going to impact ongoing > > > work, however, the sooner the better. > > > > This is not a simple address format change, it is a major > > architectural issue. All the implementations that already > know how to > > deal with simultaneous scopes will have to do major surgery > strip that > > out, or ship non-compliant code. > > No they won't. It will just be code that isn't exercised. > > And I disagree that there are implementations that "know how > to deal with simultaneous scopes". Those implementations are > almost certainly making unwarranted assumptions (or imposing > unreasonable constraints, > if you prefer) about how people organize their networks. On the contrary, they are providing the tool that allows people to get maximum value from the networks the way they are currently organized. > > > > 5. Why not just kill SL completely? (JINMEI) That would > definitely > > > annoy implementors, and close off our options. > > > > > > 6. We have to handle multiple scopes anyway (Brian Zill, > Tony Hain). > > > Right. And by retaining SL, we retain the option of reversing the > > > "disconnected" decision if we ever do figure out how to > handle them > > > properly. > > > > People already know how to deal with 'connected' 1918 space, > > No they do not. There is no general solution, there are lots of > hacks that work only for constrained cases. So rather than lots of hacks, we should have formal documentation of the approaches and constraints. > The closest thing to > a general solution is Teredo, but even that will fail if SLs > are widely used in IPv6. Orthogonal & absurd comment since Teredo is about global prefixes. > > > this is no > > different in that respect. What is different is the architectural > > change to support simultaneous use of multiple scopes. This is not > > rocket science, it just requires working through the engineering of > > the new edge cases. > > First of all, it's not engineering, since we don't yet know > how to solve the problem. Second, there isn't enough benefit > to justify the investment in the effort much less the burden > on applications. One opinion that is not supported by current implementations. Tony > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 12:30:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADKUDkd012113; Wed, 13 Nov 2002 12:30:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADKUDDR012112; Wed, 13 Nov 2002 12:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADKUAkd012102 for ; Wed, 13 Nov 2002 12:30:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADKUJMq002245 for ; Wed, 13 Nov 2002 12:30:19 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24938 for ; Wed, 13 Nov 2002 13:30:13 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA28509 for ; Wed, 13 Nov 2002 20:30:12 GMT Received: from login.ecs.soton.ac.uk (IDENT:F2Lpd8aMZhSp3kEnhlwayzyeMcOijrK3@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gADKU3WX031868 for ; Wed, 13 Nov 2002 20:30:04 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gADKU3c32097 for ipng@sunroof.eng.sun.com; Wed, 13 Nov 2002 20:30:03 GMT Date: Wed, 13 Nov 2002 20:30:03 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up Message-ID: <20021113203003.GI31842@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <07ea01c28b3c$93492c20$bd134104@eagleswings> <3DD2A0A2.90005@iprg.nokia.com> <3DD2A339.1070700@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD2A339.1070700@iprg.nokia.com> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Fred, That's interesting. There has been some talk about multiple ISATAP site routers, and scalability. Can you comment on how ISATAP performed in this network of thousands of (mobile) hosts? (I assume you meant hundreds or thousands, not hundreds of thousands) Tim On Wed, Nov 13, 2002 at 11:08:41AM -0800, Fred L. Templin wrote: > FWIW, > > This study, along with others in the US Army CECOM division, > produced the transition mechansim now known as ISATAP. > > Fred Templin > ftemplin@iprg.nokia.com > > Fred L. Templin wrote: > >So much traffic has flown by on this subject that my head is still > >spinning. > >But, let me give one example in which the use of site-locals on globally > >connected networks might be useful. > > > >While at SRI International, I had the privilege of participating in a > >study of > >autonomous teams of unmanned vehciles with the Office of Naval Research. > >Such > >teams may consist of hundreds/thousands of mobile vehicles that travel > >together > >in a more-or-less coordinated fashion. Communications are nicely modeled by > >Mobile Ad-hoc Networking, as in the IETF MANET WG. Very large teams may be > >organized into "clusters" based on geography, commonalities of interest, > >etc. Finally, the team as a whole is only intermittently connected to the > >global Internet - perhaps with long periods of disconnected operation. > > > >When the team is out of contact with the global Internet, site-locals > >can provide > >a nice means to facilitate intra-cluster and inter-cluster > >communcations. When the > >team comes in contact with an access router(s) to the the global > >Internet, the global > >prefixes can be disemminated to team members that need global access. > >But since the > >team is mobile, global access may be intermittent, with new global > >prefixes learned > >as different access routers are encountered. > > > >So it seems tome that site-locals can provide a useful mechanism for > >large mobile > >networks with intermittent global connectivity. > > > >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 > >-------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 13 12:44:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADKi3kd012722; Wed, 13 Nov 2002 12:44:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADKi3on012721; Wed, 13 Nov 2002 12:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADKi0kd012714 for ; Wed, 13 Nov 2002 12:44:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADKi9Mq006736 for ; Wed, 13 Nov 2002 12:44:09 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03236 for ; Wed, 13 Nov 2002 13:44:03 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 13 Nov 2002 12:44:03 -0800 Reply-To: From: "Tony Hain" To: Cc: "'Brian Zill'" , Subject: RE: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 12:43:48 -0800 Message-ID: <07fb01c28b55$6064e060$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211131956.gADJurl11661@astro.cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADKi0kd012715 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > I don't know how you can get from needing a simple filter to not > > needing a filter... A simple example would be; as per spec, SL is > > blocked at the border, globals are allowed without restriction, and > > hosts that are allowed out have a policy that allows them > to configure > > a global prefix along with the SL one, while those that are not > > allowed out have a policy that only allows configuring an > SL prefix. > > Address selection says use the smallest scope, so internal > > communications use SL and are forced to stay internal by the hard > > filter at the border. This puts the burden of policy application at > > the address assignment time (very infrequent) rather than parsing > > every packet for access control. > > this is not workable for several reasons. > > first, it expects apps to work across site boundaries betwen > hosts that > use SLs. that's simply unacceptable. One opinion. You keep saying that, but it is not requiring that the app work using SL across the border. In fact the reason the network manager likes SL is the apps will explicitly not work in that case. Are we really talking about legislating against border filtering? > > second, it's not secure without filtering. Who said anything about security, and the point of SL is that there is a well understood filter that gets applied between the public and private network. Between private networks is a matter of local negotiation, but that would be true in any case. > > third, address selection is not a policy mechanism, it is a default > behavior, that applications are free to ignore - and there are many > cases where it's highly desirable that they do so. If an app chooses to assert a policy that is different from the network manager's filtering rules, it will fail. Having a well defined address space that is known to have filtering applied allows apps to have a hint about potential scope restrictions. That hint may or may not be helpful, but lack of it leaves the app in complete trial & error mode. > > fourth, the idea that address selection for internal > communications does not affect external communications is naive. I can't parse this. The decision about internal / external communications is a filtering decision. The address allocation / selection mechanism for a well defined space makes that process manageable, and reduces the burden on the filter process. > > > You are trying to legislate against current practice, rather than > > documenting it so that app developers can understand the real > > environment. > > You are trying to force a practice that is known to be > broken, and the burden of trying to make apps work in the face of that > broken practice, on everyone. There is no way that this can > be justified. I am not forcing anything. I am arguing that we maintain an architectural principle, that allows current practice to be extended away from the need for header mangling. You can't seem to see that the option of having an address with limited scope does not require an app to use it, while also insisting that apps that might want to run in a limited scope are invalid. No one is requiring the apps you write to use SL addresses. Tony > > Keith > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 12:57:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADKvZkd012975; Wed, 13 Nov 2002 12:57:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADKvZ7G012974; Wed, 13 Nov 2002 12:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADKvWkd012967 for ; Wed, 13 Nov 2002 12:57:32 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADKvebB001313 for ; Wed, 13 Nov 2002 12:57:40 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11775 for ; Wed, 13 Nov 2002 13:57:35 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 13 Nov 2002 12:57:39 -0800 Reply-To: From: "Tony Hain" To: "'Michael Thomas'" , "'Harald Tveit Alvestrand'" Cc: "'Brian E Carpenter'" , Subject: RE: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 12:57:23 -0800 Message-ID: <07fc01c28b57$445d5c60$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <15826.38013.831018.310008@thomasm-u1.cisco.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADKvWkd012968 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > So I have a question for those who support > connected site locals: what would prevent a new > RFC from updating Brian's wording for site locals > (if that's the right thing)? > > I say this because it seems to me that there's a > lot of issues being conflated in these arguments > and what's sort of frightening to me is that they > need to be teased apart. In particular, the desire > for provider independent addressing seems to > factor in here fairly largely too, and I wonder if > the better part of valor might not be to get > together a BOF which focuses on the actual real > life requirements here. It's possible that site > locals in the end might make sense here, but it's > also possible that it can be done other ways too > (or that the entire problem is totally intractable > which is the way it looks to me now). > Some of the uses for SL would be better served by PI addresses, but not all. Take the case of a 20,000 node network where half are allowed global access and half are not. It is much more complex to sort through a 10,000 node list per packet for access filtering than it would be to have two entries, SL deny & PA allow. Yes the list of which 10,000 nodes are allowed the global prefix has to be maintained, but it can be applied according to allocation policy rather than per packet processing. Yes we need a PI format, and there are a few being batted around on multi-6, but even there we are into engineering trade-offs about allocation efficiency vs. routing table exception handling efficiency. My intent was to bring a PI format proposal to this wg after multi-6 established requirements, but that wg seems to have been derailed into the long running saga of overhauling the entire protocol suite. If there is interest in discussing a PI format to get that off the table for the SL discussion, I will ask the chairs to consider it as a WG doc. 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 Nov 13 13:04:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADL44kd013112; Wed, 13 Nov 2002 13:04:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADL43Jq013111; Wed, 13 Nov 2002 13:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADL3xkd013101 for ; Wed, 13 Nov 2002 13:03:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADL48bB003278 for ; Wed, 13 Nov 2002 13:04:08 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15883 for ; Wed, 13 Nov 2002 14:04:02 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADL3vl12126; Wed, 13 Nov 2002 16:03:57 -0500 (EST) Message-Id: <200211132103.gADL3vl12126@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Keith Moore'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: Summary Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 12:24:19 PST.") <07f601c28b52$a552c780$bd134104@eagleswings> Date: Wed, 13 Nov 2002 16:03:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is not a bug, it is an architectural principle. Those are not > changed on a whim after the review process has completed. Come on, Tony. If we have a "principle" that justifies burdening applications with unnecessary complexity for dubious and marginal gain, aren't we better off without it? > > Neither SL nor NAT will save those sites from having to > > maintain a filter list. If some hosts on network are allowed > > to be exposed to the outside and others aren't, the list of > > exceptions has to be maintained somewhere. > > Yes, but putting that in the address allocation process scales better > than having to scan a 10,000 entry list for each packet. No it doesn't. Because if you can allocate SL+global addresses for some hosts and only SLs for others, then you can just as easily allocate different kinds of globals (say type A and B) for each host, and filter out just those that match type A. > > But the only way to make SLs work on a network that has > > external connections is to give all nodes global addresses. > > You can't just assign "global addresses for those nodes that > > need it" without burdening apps that need to talk to the > > other hosts with having to do their own addressing and > > routing. > > Read draft-ietf-ipv6-default-addr-select-09.txt for instructions on > sorting that out. That draft is just WRONG for large numbers of applications. The only way it was justified at all was by calling it a default, saying that apps could take exception to it, and claiming that the need for consistency between implementations required us to to get default behavior defined now, even if it was known to be insufficient. > > The strategy that you are advocating is precisely what we > > need to discourage. It's no better than NATs. If it's widely > > adopted it will destroy the additional utility that IPv6 > > provides over IPv4. > > How does use of unmolested global addresses become what we have today? > Nodes that need global access get a global address for that along with a > SL for internal use, and those that don't get only a SL. Today apps are expected to communicate between nodes even though those nodes don't have global addresses. The people who make the decision to deploy NATs and/or to use RFC 1918 addresses aren't aware of the detailed needs of applications - so they create dysfunctional networks, and the app developers are expected to take up the slack. Why will those people be any wiser with their use of SLs? And why should we not learn from our past experience with RFC 1918 and NATs and discourage practices that we now know to be harmful? > > And I disagree that there are implementations that "know how > > to deal with simultaneous scopes". Those implementations are > > almost certainly making unwarranted assumptions (or imposing > > unreasonable constraints, if you prefer) about how people organize > > their networks. > > On the contrary, they are providing the tool that allows people to get > maximum value from the networks the way they are currently organized. They allow *some* people to get more (not maximum) value from *some* networks. It's not reasonable to burden all users and networks for the long term in order to accomodate those few who have organized their networks poorly in the short term. > > > People already know how to deal with 'connected' 1918 space, > > > > No they do not. There is no general solution, there are lots of > > hacks that work only for constrained cases. > > So rather than lots of hacks, we should have formal documentation of the > approaches and constraints. No, Tony. You can't solve the problem simply by documenting the hacks and when they work, because they're still hacks, they still don't work well, and they still impose a lot of complexity. And if the situation is that difficult to document then there's a good chance that it's too complex to use. > > The closest thing to > > a general solution is Teredo, but even that will fail if SLs > > are widely used in IPv6. > > Orthogonal & absurd comment since Teredo is about global prefixes. No, you're just missing the point. Teredo is pretty much what you have to do if you want to produce a general solution for interoperation between networks with scoped addresses. In other words, you have to define a new set of unambiguous addreseses and tunnel between the networks. You don't necessarily need the mechanisms in Teredo to force the NATs to keep mapping state, but you need the rest. The point is we just got finished figuring out how to use IPv6 to allow IPv4-based networks to escape their dysfunction - and now you're trying to impose most of that same dysfunction on IPv6. > > > this is no > > > different in that respect. What is different is the architectural > > > change to support simultaneous use of multiple scopes. This is not > > > rocket science, it just requires working through the engineering of > > > the new edge cases. > > > > First of all, it's not engineering, since we don't yet know > > how to solve the problem. Second, there isn't enough benefit > > to justify the investment in the effort much less the burden > > on applications. > > One opinion that is not supported by current implementations. Only if you consider only the very few apps that try to deal with SLs in a general fashion and ignore the large numbers of apps that cannot deal with them. And only if you ignore the huge amount of complexity that has gone into solving the problems caused by use of RFC 1918 (even without NAT) without a general solution. Actually, the fact that you're trying so hard to preserve complexity that isn't needed unless SLs are imposed on the net argues strongly for getting rid of SLs. Who benefits from that increased complexity? Certainly not the network administrators or the users. 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 Nov 13 13:11:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLBakd013224; Wed, 13 Nov 2002 13:11:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADLBaJs013223; Wed, 13 Nov 2002 13:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLBXkd013216 for ; Wed, 13 Nov 2002 13:11:33 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADLBgbB005485 for ; Wed, 13 Nov 2002 13:11:42 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19098 for ; Wed, 13 Nov 2002 13:11:37 -0800 (PST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gADLBNep021945; Wed, 13 Nov 2002 13:11:23 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAP27001; Wed, 13 Nov 2002 13:05:47 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA15499; Wed, 13 Nov 2002 13:11:28 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15826.49152.521209.961997@thomasm-u1.cisco.com> Date: Wed, 13 Nov 2002 13:11:28 -0800 (PST) To: Cc: "'Michael Thomas'" , "'Harald Tveit Alvestrand'" , "'Brian E Carpenter'" , Subject: RE: Proposal for site-local clean-up In-Reply-To: <07fc01c28b57$445d5c60$bd134104@eagleswings> References: <15826.38013.831018.310008@thomasm-u1.cisco.com> <07fc01c28b57$445d5c60$bd134104@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: > > So I have a question for those who support > > connected site locals: what would prevent a new > > RFC from updating Brian's wording for site locals > > (if that's the right thing)? > > > > I say this because it seems to me that there's a > > lot of issues being conflated in these arguments > > and what's sort of frightening to me is that they > > need to be teased apart. In particular, the desire > > for provider independent addressing seems to > > factor in here fairly largely too, and I wonder if > > the better part of valor might not be to get > > together a BOF which focuses on the actual real > > life requirements here. It's possible that site > > locals in the end might make sense here, but it's > > also possible that it can be done other ways too > > (or that the entire problem is totally intractable > > which is the way it looks to me now). > > > > Some of the uses for SL would be better served by PI addresses, but not > all. Well, that's sort of my point. The fact these are intertwined in many cases seems like a good reason for prudence. If PI addresses could be made to work, a *lot* of the motivators for SL would go away and we could then consider the remaining cases independently. However, if we allow the current language it's going to be even more tangled up if we ever get PI's with an even bigger mess to sort through, not to mention the spectre of real deployment too. > Take the case of a 20,000 node network where half are allowed global > access and half are not. It is much more complex to sort through a > 10,000 node list per packet for access filtering than it would be to > have two entries, SL deny & PA allow. Yes the list of which 10,000 nodes > are allowed the global prefix has to be maintained, but it can be > applied according to allocation policy rather than per packet > processing. Why couldn't you use a reverse VPN? Ie, an SA is required between you and the inside edge for external access? 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 Nov 13 13:18:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLI8kd013377; Wed, 13 Nov 2002 13:18:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADLI880013376; Wed, 13 Nov 2002 13:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLI5kd013369 for ; Wed, 13 Nov 2002 13:18:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADLIDbB007416 for ; Wed, 13 Nov 2002 13:18:14 -0800 (PST) Received: from TNEXVS01.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA19390 for ; Wed, 13 Nov 2002 14:18:05 -0700 (MST) Received: from TNEXVS02.tahoenetworks.com ([10.10.1.132]) by TNEXVS01.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Nov 2002 13:18:02 -0800 content-class: urn:content-classes:message Subject: RE: Proposal for site-local clean-up MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 13 Nov 2002 13:18:01 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6EAB6E37@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKLWJlftEiNU9V4RPW72R2FliJtbwAAR4JQ From: "Mohan Parthasarathy" To: , "Michael Thomas" , "Harald Tveit Alvestrand" Cc: "Brian E Carpenter" , X-OriginalArrivalTime: 13 Nov 2002 21:18:02.0281 (UTC) FILETIME=[26210190:01C28B5A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADLI5kd013370 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, > > Michael Thomas wrote: > > So I have a question for those who support > > connected site locals: what would prevent a new > > RFC from updating Brian's wording for site locals > > (if that's the right thing)? > > > > I say this because it seems to me that there's a > > lot of issues being conflated in these arguments > > and what's sort of frightening to me is that they > > need to be teased apart. In particular, the desire > > for provider independent addressing seems to > > factor in here fairly largely too, and I wonder if > > the better part of valor might not be to get > > together a BOF which focuses on the actual real > > life requirements here. It's possible that site > > locals in the end might make sense here, but it's > > also possible that it can be done other ways too > > (or that the entire problem is totally intractable > > which is the way it looks to me now). > > > > Some of the uses for SL would be better served by PI > addresses, but not all. > > Take the case of a 20,000 node network where half are allowed > global access and half are not. It is much more complex to > sort through a 10,000 node list per packet for access > filtering than it would be to have two entries, SL deny & PA > allow. Yes the list of which 10,000 nodes are allowed the > global prefix has to be maintained, but it can be applied > according to allocation policy rather than per packet processing. > I miss something here. How do you make sure that nodes configure just site local and not global address on seeing an RA ? Are you keeping them in separate networks i.e not mixing nodes that require globals and site locals ? If so, then I can do the same with globals with appropriate partitioning i.e subnet 1 - 100, is for private use only. Then the check is very simple. Could you clarify ? thanks mohan > Yes we need a PI format, and there are a few being batted > around on multi-6, but even there we are into engineering > trade-offs about allocation efficiency vs. routing table > exception handling efficiency. My intent was to bring a PI > format proposal to this wg after multi-6 established > requirements, but that wg seems to have been derailed into > the long running saga of overhauling the entire protocol > suite. If there is interest in discussing a PI format to get > that off the table for the SL discussion, I will ask the > chairs to consider it as a WG doc. > > 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 Wed Nov 13 13:20:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLKRkd013446; Wed, 13 Nov 2002 13:20:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADLKRmr013444; Wed, 13 Nov 2002 13:20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLKNkd013435 for ; Wed, 13 Nov 2002 13:20:23 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADLKWMq017658 for ; Wed, 13 Nov 2002 13:20:32 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29965 for ; Wed, 13 Nov 2002 14:20:26 -0700 (MST) Received: from kenawang.windriver.com ([128.224.4.202]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA12329; Wed, 13 Nov 2002 13:19:50 -0800 (PST) Message-Id: <5.1.0.14.2.20021113161632.02db0ec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 13 Nov 2002 16:20:33 -0500 To: From: Margaret Wasserman Subject: RE: Proposal for site-local clean-up Cc: "'Michael Thomas'" , "'Harald Tveit Alvestrand'" , "'Brian E Carpenter'" , In-Reply-To: <07fc01c28b57$445d5c60$bd134104@eagleswings> References: <15826.38013.831018.310008@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Take the case of a 20,000 node network where half are allowed global >access and half are not. It is much more complex to sort through a >10,000 node list per packet for access filtering than it would be to >have two entries, SL deny & PA allow. Yes the list of which 10,000 nodes >are allowed the global prefix has to be maintained, but it can be >applied according to allocation policy rather than per packet >processing. How are you planning to configure and organize these 20,000 nodes? If the private nodes are randomly distributed around the network, I certainly think that I'd rather configure an access list with 10,000 addresses and run autoconfiguration, then configure an access list with one prefix and have to support DHCP or manual configuration for all 20,000 nodes, but YMMV. If the private nodes are organized into private and public subnets, so that you could use autoconfiguration with site-local addresses on some networks and global addresses on others, then why would you need site-locals for that? You could just advertise two different global prefixes, and filter one of them... 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 Nov 13 13:21:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLLgkd013508; Wed, 13 Nov 2002 13:21:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADLLgRE013507; Wed, 13 Nov 2002 13:21: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLLbkd013500 for ; Wed, 13 Nov 2002 13:21:38 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADLLlMq018076 for ; Wed, 13 Nov 2002 13:21:47 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27200 for ; Wed, 13 Nov 2002 13:21:41 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADLLal12236; Wed, 13 Nov 2002 16:21:36 -0500 (EST) Message-Id: <200211132121.gADLLal12236@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, "'Brian Zill'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 12:43:48 PST.") <07fb01c28b55$6064e060$bd134104@eagleswings> X-SUBJECT-MSG-FROM: "Tony Hain" Date: Wed, 13 Nov 2002 16:21:36 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > One opinion. You keep saying that, but it is not requiring that the app > work using SL across the border. In fact the reason the network manager > likes SL is the apps will explicitly not work in that case. Actually that's a delusion. In today's networks the apps are still expected to "work" in that case; it's just that they require more complexity to do so, and they don't work as efficiently or as reliably. > Are we really talking about legislating against border filtering? No, we're talking about making border filtering useful. > > second, it's not secure without filtering. > > Who said anything about security, and the point of SL is that there is a > well understood filter that gets applied between the public and private > network. And if the purpose of this filter is not security (or the illusion thereof) then what is it? > > third, address selection is not a policy mechanism, it is a default > > behavior, that applications are free to ignore - and there are many > > cases where it's highly desirable that they do so. > > If an app chooses to assert a policy that is different from the network > manager's filtering rules, it will fail. Yes, though that doesn't mean that the network manager's policy was realistic. But a minute ago you were asserting that address selection prevented the need for such filters, now you're saying that the filters will exist anyway. Which is it? > Having a well defined address > space that is known to have filtering applied allows apps to have a hint > about potential scope restrictions. That hint may or may not be helpful, > but lack of it leaves the app in complete trial & error mode. No, it's just the opposite, at least if use of SLs is widespread. Apps will still be expected to operate across site boundaries, and the fact that an SL address is used forces the app to use trial and error to figure out which addresses work best for referrals. > > fourth, the idea that address selection for internal > > communications does not affect external communications is naive. > > I can't parse this. The decision about internal / external > communications is a filtering decision. You were claiming that it's okay to use SLs for internal communications and globals for external communications. I'm saying that forcing apps to use SLs for internal communications can prevent them from working externally even if some of those nodes have globals. The source address you use to talk to one node may get reused in a referral. This is standard practice today for many apps - it's one way to get around some of the problems imposed by NATs. Don't expect those protocols' paylods to change just to use IPv6. > > > You are trying to legislate against current practice, rather than > > > documenting it so that app developers can understand the real > > > environment. > > > > You are trying to force a practice that is known to be=20 > > broken, and the burden of trying to make apps work in the face of that > > broken practice, on everyone. There is no way that this can > > be justified. > > I am not forcing anything. I am arguing that we maintain an > architectural principle, that allows current practice to be extended > away from the need for header mangling. You are arguing that we maintain a principle that we now know to be misguided, that gets us away from header mangling but imposes most of the same constraints on apps that header mangling does, and that prevents IPv6 from solving the problems that were imposed by NATs. This is not a step forward. > You can't seem to see that the > option of having an address with limited scope does not require an app > to use it, It does if globals are not available, or if the app is using an address in a referral that was obtained from another app within the same site. > while also insisting that apps that might want to run in a > limited scope are invalid. Purely-local apps do exist, but that's a relatively small category of apps. Most app designers and users want apps to be able to work (policy permitting) between any set of nodes. And denying apps access to global addresses is a lousy way to implement this policy. > No one is requiring the apps you write to use > SL addresses. Nobody except misguided network admins, and you. 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 Nov 13 13:32:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLWvkd013949; Wed, 13 Nov 2002 13:32:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADLWuNu013946; Wed, 13 Nov 2002 13:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLWrkd013938 for ; Wed, 13 Nov 2002 13:32:53 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADLX2bB011914 for ; Wed, 13 Nov 2002 13:33:02 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03561 for ; Wed, 13 Nov 2002 14:32:56 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 13 Nov 2002 13:33:01 -0800 Reply-To: From: "Tony Hain" To: Cc: "'Brian E Carpenter'" , Subject: RE: Summary Re: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 13:32:45 -0800 Message-ID: <080301c28b5c$34cb3560$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211132103.gADL3vl12126@astro.cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADLWrkd013939 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > This is not a bug, it is an architectural principle. Those are not > > changed on a whim after the review process has completed. > > Come on, Tony. If we have a "principle" that justifies burdening > applications with unnecessary complexity for dubious and marginal > gain, aren't we better off without it? Unnecessary, dubious, & marginal are one perspective. The point is that the recommendation to preclude simultanious use of SL & global is a serious architectural change. It is not a minor edit. > > > > Neither SL nor NAT will save those sites from having to > maintain a > > > filter list. If some hosts on network are allowed to be > exposed to > > > the outside and others aren't, the list of exceptions has to be > > > maintained somewhere. > > > > Yes, but putting that in the address allocation process > scales better > > than having to scan a 10,000 entry list for each packet. > > No it doesn't. Because if you can allocate SL+global > addresses for some > hosts and only SLs for others, then you can just as easily allocate > different kinds of globals (say type A and B) for each host, > and filter > out just those that match type A. Using what routing technology ??? If there are devices sitting on the same wire, they need to have some coorelation in the address space for current routing protocols to deliver packets. > > > > But the only way to make SLs work on a network that has external > > > connections is to give all nodes global addresses. You can't just > > > assign "global addresses for those nodes that need it" without > > > burdening apps that need to talk to the other hosts with > having to > > > do their own addressing and routing. > > > > Read draft-ietf-ipv6-default-addr-select-09.txt for instructions on > > sorting that out. > > That draft is just WRONG for large numbers of applications. The > only way it was justified at all was by calling it a default, > saying that apps could take exception to it, and claiming that > the need for consistency between implementations required us to > to get default behavior defined now, even if it was known to be > insufficient. For apps that it is insufficient, apply a rule that says SL is not an acceptable choice. That is a local app decision. > > > > The strategy that you are advocating is precisely what we need to > > > discourage. It's no better than NATs. If it's widely adopted it > > > will destroy the additional utility that IPv6 provides over IPv4. > > > > How does use of unmolested global addresses become what we > have today? > > Nodes that need global access get a global address for that > along with > > a SL for internal use, and those that don't get only a SL. > > Today apps are expected to communicate between nodes even > though those > nodes don't have global addresses. The people who make the decision > to deploy NATs and/or to use RFC 1918 addresses aren't aware of the > detailed needs of applications - so they create dysfunctional > networks, and the app developers are expected to take up the > slack. Why will those people be any wiser with their use of SLs? Because with 1918 & nat, they have no choice about the matter. Telling them they can't have a tool that will allow apps to work where required, while breaking those that should be broken, is not getting to where you want to go. They will insist on nat because filtering takes precidence to making apps work for a subset of nodes. > > And why should we not learn from our past experience with RFC > 1918 and NATs and discourage practices that we now know to be > harmful? Preventing the SL space does not discourage the practice, preventing simultaneous use of SL & global does. Filtering will be the priority, and if the filter list is unwieldy, nat will take its place. > > > > And I disagree that there are implementations that "know how > > > to deal with simultaneous scopes". Those implementations are > > > almost certainly making unwarranted assumptions (or imposing > > > unreasonable constraints, if you prefer) about how people > organize > > > their networks. > > > > On the contrary, they are providing the tool that allows > people to get > > maximum value from the networks the way they are currently > organized. > > They allow *some* people to get more (not maximum) value from *some* > networks. It's not reasonable to burden all users and networks > for the long term in order to accomodate those few who have organized > their networks poorly in the short term. No one is requiring that SL be used, so the assertion that everyone has a burden is absurd. > > > > > People already know how to deal with 'connected' 1918 space, > > > > > > No they do not. There is no general solution, there are lots of > > > hacks that work only for constrained cases. > > > > So rather than lots of hacks, we should have formal > documentation of > > the approaches and constraints. > > No, Tony. You can't solve the problem simply by documenting > the hacks and when they work, because they're still hacks, > they still don't work well, and they still impose a lot of > complexity. And if the situation > is that difficult to document then there's a good chance that > it's too > complex to use. Documenting the hacks will expose the goals, which could in turn lead to better engineering. > > > > The closest thing to > > > a general solution is Teredo, but even that will fail if SLs > > > are widely used in IPv6. > > > > Orthogonal & absurd comment since Teredo is about global prefixes. > > No, you're just missing the point. Teredo is pretty much what you > have to do if you want to produce a general solution for > interoperation > between networks with scoped addresses. In other words, you have to > define a new set of unambiguous addreseses and tunnel between the > networks. You don't necessarily need the mechanisms in Teredo to > force the NATs to keep mapping state, but you need the rest. You are arguing that an app needs to work over a global scope, despite the network manager's intention that it not. The point of scoping is to prevent interoperation across the boundary. > > The point is we just got finished figuring out how to use > IPv6 to allow IPv4-based networks to escape their > dysfunction - and now you're trying to impose most of that > same dysfunction on IPv6. The point is that the network manager intends some aspects of the network to be broken. The tool we have provided to allow that to happen without requiring all nodes to be subject to the brokenness is SL. > > > > > this is no > > > > different in that respect. What is different is the > architectural > > > > change to support simultaneous use of multiple scopes. > This is not > > > > rocket science, it just requires working through the > engineering of > > > > the new edge cases. > > > > > > First of all, it's not engineering, since we don't yet know > > > how to solve the problem. Second, there isn't enough benefit > > > to justify the investment in the effort much less the burden > > > on applications. > > > > One opinion that is not supported by current implementations. > > Only if you consider only the very few apps that try to deal > with SLs in a general fashion and ignore the large numbers of > apps that cannot deal with them. And only if you ignore the > huge amount of complexity that has gone into solving the > problems caused by use of RFC 1918 (even without NAT) without > a general solution. > > Actually, the fact that you're trying so hard to preserve complexity > that isn't needed unless SLs are imposed on the net argues strongly > for getting rid of SLs. Who benefits from that increased > complexity? Certainly not the network administrators or the users. It is not increased or decrease complexity. It is simply moving the complexity around so that nodes that should not be subjected to draconian policies have an out. The benefit is for those nodes that need global accessability but have to share infrastructure with devices that should not have public access. Tony > > Keith > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 13:41:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLfAkd014219; Wed, 13 Nov 2002 13:41:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADLfATo014218; Wed, 13 Nov 2002 13:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLf6kd014211 for ; Wed, 13 Nov 2002 13:41:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADLfFMq023843 for ; Wed, 13 Nov 2002 13:41:16 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08734 for ; Wed, 13 Nov 2002 14:41:10 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 13 Nov 2002 13:41:14 -0800 Reply-To: From: "Tony Hain" To: "'Mohan Parthasarathy'" , "'Michael Thomas'" , "'Harald Tveit Alvestrand'" Cc: "'Brian E Carpenter'" , Subject: RE: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 13:40:59 -0800 Message-ID: <080701c28b5d$5b20a280$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6EAB6E37@TNEXVS02.tahoenetworks.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mohan Parthasarathy wrote: > > ... > I miss something here. How do you make sure that nodes > configure just site local and not global address on seeing an > RA ? Are you keeping them in separate networks i.e not mixing > nodes that require globals and site locals ? If so, then I > can do the same with globals with appropriate partitioning > i.e subnet 1 - 100, is for private use only. Then the check > is very simple. Could you clarify ? Same network, hearing RA's, just local policy on the restricted box to only configure based on SL prefixes. 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 Nov 13 13:46:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLkTkd014380; Wed, 13 Nov 2002 13:46:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADLkTo8014379; Wed, 13 Nov 2002 13:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLkOkd014369 for ; Wed, 13 Nov 2002 13:46:24 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADLkXMq025562 for ; Wed, 13 Nov 2002 13:46:34 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11903 for ; Wed, 13 Nov 2002 14:46:28 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 13 Nov 2002 13:46:32 -0800 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" Cc: "'Michael Thomas'" , "'Harald Tveit Alvestrand'" , "'Brian E Carpenter'" , Subject: RE: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 13:46:17 -0800 Message-ID: <080f01c28b5e$18a3a640$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5.1.0.14.2.20021113161632.02db0ec0@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADLkPkd014370 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > ... > How are you planning to configure and organize these 20,000 nodes? The ones that should not have public access would be configured to only listen for the SL prefix in an RA, or could be fed by DHCP. > > If the private nodes are randomly distributed around the > network, I certainly think that I'd rather configure an > access list with 10,000 addresses and run autoconfiguration, > then configure an access list with one prefix and have to > support DHCP or manual configuration for all 20,000 nodes, but YMMV. Depends on the local network and its configuration capabilities. There are environments where it is possible to use autoconfiguration, with a policy constraint on restricted access nodes that says only accept a SL prefix. > > If the private nodes are organized into private and public > subnets, so that you could use autoconfiguration with > site-local addresses on some networks and global addresses on > others, then why would you need site-locals for that? You > could just advertise two different global prefixes, and > filter one of them... I agree, but that requires specific topology constraints that are unreasonable. If my laptop needs to be publicly accessable but my printer does not, why is it reasonable to require separate network drops rather than letting them share a hub? Tony > > 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 Nov 13 13:51:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLpekd014563; Wed, 13 Nov 2002 13:51:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADLpdot014562; Wed, 13 Nov 2002 13:51:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLpakd014555 for ; Wed, 13 Nov 2002 13:51:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADLpjMq027490 for ; Wed, 13 Nov 2002 13:51:45 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA08963 for ; Wed, 13 Nov 2002 14:51:39 -0700 (MST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 13 Nov 2002 13:51:33 -0800 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 13 Nov 2002 13:51:33 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 13 Nov 2002 13:51:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Summary Re: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 13:51:31 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary Re: Proposal for site-local clean-up Thread-Index: AcKLJdF68XwcY+dHRJybeGPL62zfWgANzjvg From: "Brian Zill" To: "Brian E Carpenter" , X-OriginalArrivalTime: 13 Nov 2002 21:51:33.0008 (UTC) FILETIME=[D49D9900:01C28B5E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADLpakd014556 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Carpenter writes: > 3. Can't stop NAT's anyway. (several people). > That may sadly be true, but we shouldn't publish > specs that seem to encourage them. I would argue the opposite -- *preventing* site-locals and globals from co-existing encourages NAT. We're better off today than we would be with that restriction. Case study: A site has a disconnected network happily using site-locals. These addresses get embedded in all sorts of configuration scripts, etc. Then they decide to connect to the Internet and get a global prefix from their ISP. Today: They just advertise the new global prefix alongside the site-local prefix, all their hard-coded addresses continue to work. With restriction on mixing site-local and global addresses: They need to renumber their network and find all the places addresses have been specified in config files and the like. Or they could just use a v6 NAT. Which do you think will happen? --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 13:57:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLvZkd014741; Wed, 13 Nov 2002 13:57:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADLvZwb014740; Wed, 13 Nov 2002 13:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLvVkd014730 for ; Wed, 13 Nov 2002 13:57:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADLvebB019429 for ; Wed, 13 Nov 2002 13:57:40 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05295 for ; Wed, 13 Nov 2002 14:57:35 -0700 (MST) 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 NAA10372 for ; Wed, 13 Nov 2002 13:57:34 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gADLvYN20665 for ; Wed, 13 Nov 2002 13:57:34 -0800 X-mProtect: <200211132157> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4QgJ7Q; Wed, 13 Nov 2002 13:57:32 PST Message-ID: <3DD2CBEA.5010606@iprg.nokia.com> Date: Wed, 13 Nov 2002 14:02:18 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up References: <200211131959.gADJxBl11725@astro.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: >>Finally, the team as a whole is only intermittently connected to the >>global Internet - perhaps with long periods of disconnected operation. > > > yes, intermittent connection is one of the genuinely valid justifications > for SLs. Glad to hear you agree. > however even with intermittent connection it is often possible to use > globals rather than SLs. the exception is a nomadic network that > connects to the net at different locations at different times, and > whose hosts don't have home agent(s) for mobile IP. This is exactly the case my message describe, modulo your point "whose hosts don't have home agent(s) for mobile IP", which I don't see as being relevant. In the case I described, two models are possible: 1) The node's "home" is the MANET itself 2) The node has a distant home and is always a visitor in whichever MANET it is currently in Either way, when associated with a MANET that is currently disconnected from the global Internet, site-locals seem like a nice feature. 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 Nov 13 13:58:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLw2kd014763; Wed, 13 Nov 2002 13:58:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADLw16q014762; Wed, 13 Nov 2002 13:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLvwkd014752 for ; Wed, 13 Nov 2002 13:57:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADLw7Mq029464 for ; Wed, 13 Nov 2002 13:58:07 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23516 for ; Wed, 13 Nov 2002 14:58:01 -0700 (MST) Received: from kenawang.windriver.com ([128.224.4.202]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA14443; Wed, 13 Nov 2002 13:57:39 -0800 (PST) Message-Id: <5.1.0.14.2.20021113164342.02db0bc0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 13 Nov 2002 16:54:52 -0500 To: From: Margaret Wasserman Subject: RE: Summary Re: Proposal for site-local clean-up Cc: , "'Brian E Carpenter'" , In-Reply-To: <080301c28b5c$34cb3560$bd134104@eagleswings> References: <200211132103.gADL3vl12126@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tony, >Unnecessary, dubious, & marginal are one perspective. The point is that >the recommendation to preclude simultanious use of SL & global is a >serious architectural change. It is not a minor edit. I'm not sure where the concern is coming from that we will make a major change to the addressing architecture during the RFC editing phase. Neither Bob nor I have proposed or advocated that course of action. You and I may disagree on whether or not this change is warranted, and we may disagree about whether it is a major architectural change or just a usage restriction, but we do agree on one thing... This _would_ be a substantive change to the addressing architecture. So, I would _not_ support making this change without rough WG consensus and proper WG and IESG review, and I'm sure that Bob wouldn't either. I hope that this addresses your concern in that area. 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 Nov 13 13:59:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLxnkd014808; Wed, 13 Nov 2002 13:59:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADLxnrU014807; Wed, 13 Nov 2002 13:59: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADLxjkd014800 for ; Wed, 13 Nov 2002 13:59:45 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADLxtMq029948 for ; Wed, 13 Nov 2002 13:59:55 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18332 for ; Wed, 13 Nov 2002 13:59:49 -0800 (PST) Received: from kenawang.windriver.com ([128.224.4.202]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA16134; Wed, 13 Nov 2002 13:59:32 -0800 (PST) Message-Id: <5.1.0.14.2.20021113170032.02db6ec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 13 Nov 2002 17:01:25 -0500 To: "Brian Zill" From: Margaret Wasserman Subject: RE: Summary Re: Proposal for site-local clean-up Cc: "Brian E Carpenter" , 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 How often do you think that people really set-up a private, disconnected network and later connect it to the Internet? Do you think this will be a common real-life case, or is this more of a theoretical edge case? Margaret At 04:51 PM 11/13/02, Brian Zill wrote: >Brian Carpenter writes: > > 3. Can't stop NAT's anyway. (several people). > > That may sadly be true, but we shouldn't publish > > specs that seem to encourage them. > >I would argue the opposite -- *preventing* site-locals and globals from >co-existing encourages NAT. We're better off today than we would be >with that restriction. > >Case study: A site has a disconnected network happily using site-locals. >These addresses get embedded in all sorts of configuration scripts, etc. >Then they decide to connect to the Internet and get a global prefix from >their ISP. > >Today: They just advertise the new global prefix alongside the >site-local prefix, all their hard-coded addresses continue to work. > >With restriction on mixing site-local and global addresses: They need to >renumber their network and find all the places addresses have been >specified in config files and the like. Or they could just use a v6 >NAT. Which do you think will happen? > >--Brian > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 14:09:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADM9Ekd015261; Wed, 13 Nov 2002 14:09:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADM9D8U015260; Wed, 13 Nov 2002 14:09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADM9Akd015253 for ; Wed, 13 Nov 2002 14:09:10 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADM9JbB023297 for ; Wed, 13 Nov 2002 14:09:19 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24196 for ; Wed, 13 Nov 2002 14:09:14 -0800 (PST) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gADM99Ne015262; Wed, 13 Nov 2002 17:09:09 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gADMBXZ1145024; Wed, 13 Nov 2002 15:11:33 -0700 In-Reply-To: <080701c28b5d$5b20a280$bd134104@eagleswings> To: Cc: Subject: RE: Proposal for site-local clean-up MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 11/13/2002 05:05:31 PM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 11/13/2002 05:05:31 PM, Serialize complete at 11/13/2002 05:05:31 PM, S/MIME Sign failed at 11/13/2002 05:05:31 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|October 31, 2002) at 11/13/2002 15:09:07, Serialize complete at 11/13/2002 15:09:07 Message-ID: Date: Wed, 13 Nov 2002 17:09:18 -0500 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I miss something here. How do you make sure that nodes > > configure just site local and not global address on seeing an > > RA ? Are you keeping them in separate networks i.e not mixing > > nodes that require globals and site locals ? If so, then I > > can do the same with globals with appropriate partitioning > > i.e subnet 1 - 100, is for private use only. Then the check > > is very simple. Could you clarify ? > > Same network, hearing RA's, just local policy on the restricted box to > only configure based on SL prefixes. So, instead of filtering global addresses at the firewall, you go to each individual box in the network which you want to restricted access to/from and configure it to only use restricted (i.e., site-local) addresses? And, as a bonus, you get to deal with all the complexity and problems which are introduced when using site-locals in a non-isolated environment. How, exactly, does this improve anything? Roy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 14:08:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADM8Pkd015242; Wed, 13 Nov 2002 14:08:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADM8OQI015241; Wed, 13 Nov 2002 14:08:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADM8Hkd015223 for ; Wed, 13 Nov 2002 14:08:18 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADM8NMq003012 for ; Wed, 13 Nov 2002 14:08:23 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23622 for ; Wed, 13 Nov 2002 14:08:17 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADM8Bl12512; Wed, 13 Nov 2002 17:08:13 -0500 (EST) Message-Id: <200211132208.gADM8Bl12512@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: Summary Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 13:32:45 PST.") <080301c28b5c$34cb3560$bd134104@eagleswings> Date: Wed, 13 Nov 2002 17:08:11 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Come on, Tony. If we have a "principle" that justifies burdening > > applications with unnecessary complexity for dubious and marginal > > gain, aren't we better off without it? > > Unnecessary, dubious, & marginal are one perspective. It's a perspective supported by a lot of people and a lot of work. > The point is that > the recommendation to preclude simultanious use of SL & global is a > serious architectural change. It is not a minor edit. It's a minor change to the text, and a serious architectural improvement. It doesn't break much that exists now, and it helps a lot of things to avoid being broken in the future. > > > Yes, but putting that in the address allocation process > > > scales better > > > than having to scan a 10,000 entry list for each packet. > > > > No it doesn't. Because if you can allocate SL+global > > addresses for some hosts and only SLs for others, then you can > > just as easily allocate different kinds of globals (say type A and > > B) for each host, and filter out just those that match type A. > > Using what routing technology ??? If there are devices sitting on the > same wire, they need to have some coorelation in the address space for > current routing protocols to deliver packets. Only in the most significant bits. If an admin wants to assign some bits within a subnet allocation for this purpose, he's free to do so. Once you start having RA respond differently to different hosts on a subnet there are all kinds of games you can play. > > > Read draft-ietf-ipv6-default-addr-select-09.txt for instructions on > > > sorting that out. > > > > That draft is just WRONG for large numbers of applications. The > > only way it was justified at all was by calling it a default, > > saying that apps could take exception to it, and claiming that > > the need for consistency between implementations required us to > > to get default behavior defined now, even if it was known to be > > insufficient. > > For apps that it is insufficient, apply a rule that says SL is not an > acceptable choice. That is a local app decision. That doesn't work for all apps, if SLs are widely used. Some apps would need to use SLs, others would need to avoid SLs. It gets even more complex than that when you consider privacy addresses, link locals, and multiple global prefixes. > > Today apps are expected to communicate between nodes even > > though those nodes don't have global addresses. The people who > > make the decision to deploy NATs and/or to use RFC 1918 addresses > > aren't aware of the detailed needs of applications - so they create > > dysfunctional networks, and the app developers are expected to take > > up the slack. Why will those people be any wiser with their use of SLs? > > Because with 1918 & nat, they have no choice about the matter. Telling > them they can't have a tool that will allow apps to work where required, > while breaking those that should be broken, is not getting to where you > want to go. No, I'm not telling them that. I'm saying that SL is not a good tool for that job, that it does far more harm than good. Because SL doesn't allow those apps to work where required and break those that should be broken. It breaks some apps that shouldn't break and forces other apps to circumvent SL restrictions which make SL even less useful as a mechanism for advertising policy. > > And why should we not learn from our past experience with RFC > > 1918 and NATs and discourage practices that we now know to be > > harmful? > > Preventing the SL space does not discourage the practice, preventing > simultaneous use of SL & global does. Filtering will be the priority, > and if the filter list is unwieldy, nat will take its place. There are ways to keep filtering from being unwieldy without forcing apps to choke down SLs. > > They allow *some* people to get more (not maximum) value from *some* > > networks. It's not reasonable to burden all users and networks > > for the long term in order to accomodate those few who have organized > > their networks poorly in the short term. > > No one is requiring that SL be used, so the assertion that everyone has > a burden is absurd. no one is requiring that NAT be used, so the assertion that everyone has a burden of dealing with NATs would be absurd - if it weren't widely accepted that NATs should be used. if SLs are permitted in networks with globals then people WILL require that they be used - whether or not this provides any useful security and whether or not this allows applications to work reliably. > > > So rather than lots of hacks, we should have formal > > > documentation of > > > the approaches and constraints. > > > > No, Tony. You can't solve the problem simply by documenting > > the hacks and when they work, because they're still hacks, > > they still don't work well, and they still impose a lot of > > complexity. And if the situation > > is that difficult to document then there's a good chance that > > it's too > > complex to use. > > Documenting the hacks will expose the goals, which could in turn lead to > better engineering. We already know how to do better engineering for this (which after all is about providing a sound way to solve the problems with the lowest cost) Discourage use of SLs on networks that have globals. Don't claim that they are a useful security mechanism. Tell apps that do referrals not to use them. Provide as many hosts as possible with globals. > > > > The closest thing to > > > > a general solution is Teredo, but even that will fail if SLs > > > > are widely used in IPv6. > > > > > > Orthogonal & absurd comment since Teredo is about global prefixes. > > > > No, you're just missing the point. Teredo is pretty much what you > > have to do if you want to produce a general solution for > > interoperation > > between networks with scoped addresses. In other words, you have to > > define a new set of unambiguous addreseses and tunnel between the > > networks. You don't necessarily need the mechanisms in Teredo to > > force the NATs to keep mapping state, but you need the rest. > > You are arguing that an app needs to work over a global scope, despite > the network manager's intention that it not. The point of scoping is to > prevent interoperation across the boundary. Existing apps are expected to work over global scope even though they are operating on networks isolated by NATs and using RFC 1918 addresses - often because the network manager *thinks* this provides him some measure of increased security. He's generally wrong about that, for several reasons. So I'd say no, the point of scoping is not to prevent interoperation of apps across that boundary, since for many apps on many hosts interoperation across that boundary is quite often found to be desirable. Scoping is a really poor tool for that kind of access control. The real point of scoping is security through obscurity - trying to pretend that those internal hosts don't exist, by hiding their addresses from the outside world, and by preventing external hosts from doing traffic analysis. And to some extent doing that might be desirable. But we have better mechanisms for solving that problems - mechanisms that aren't imposed for all apps on a host. > > The point is we just got finished figuring out how to use > > IPv6 to allow IPv4-based networks to escape their > > dysfunction - and now you're trying to impose most of that > > same dysfunction on IPv6. > > The point is that the network manager intends some aspects of the > network to be broken. The tool we have provided to allow that to happen > without requiring all nodes to be subject to the brokenness is SL. And what we've found out is that it's a really crude tool. Not only is it too inflexible to serve this purpose, its use does a lot of harm. > > > > First of all, it's not engineering, since we don't yet know > > > > how to solve the problem. Second, there isn't enough benefit > > > > to justify the investment in the effort much less the burden > > > > on applications. > > > > > > One opinion that is not supported by current implementations. > > > > Only if you consider only the very few apps that try to deal > > with SLs in a general fashion and ignore the large numbers of > > apps that cannot deal with them. And only if you ignore the > > huge amount of complexity that has gone into solving the > > problems caused by use of RFC 1918 (even without NAT) without > > a general solution. > > > > Actually, the fact that you're trying so hard to preserve complexity > > that isn't needed unless SLs are imposed on the net argues strongly > > for getting rid of SLs. Who benefits from that increased > > complexity? Certainly not the network administrators or the users. > > It is not increased or decrease complexity. It is simply moving the > complexity around so that nodes that should not be subjected to > draconian policies have an out. No, it's making both apps and network filters more complex by forcing apps to do the job of the network. > The benefit is for those nodes that need > global accessability but have to share infrastructure with devices that > should not have public access. It's not just the nodes that need global accessibility that are affected; those that communicate through intermediaries are also harmed by lack of a uniform address space. 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 Nov 13 14:13:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMDNkd015409; Wed, 13 Nov 2002 14:13:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADMDNh3015408; Wed, 13 Nov 2002 14:13:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMDJkd015401 for ; Wed, 13 Nov 2002 14:13:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADMDSbB024580 for ; Wed, 13 Nov 2002 14:13:29 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02896 for ; Wed, 13 Nov 2002 15:13:22 -0700 (MST) 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 OAA11658 for ; Wed, 13 Nov 2002 14:13:22 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gADMDLJ10141 for ; Wed, 13 Nov 2002 14:13:21 -0800 X-mProtect: <200211132213> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdr6b6ea; Wed, 13 Nov 2002 14:13:20 PST Message-ID: <3DD2CF9D.1080500@iprg.nokia.com> Date: Wed, 13 Nov 2002 14:18:05 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up References: <07ea01c28b3c$93492c20$bd134104@eagleswings> <3DD2A0A2.90005@iprg.nokia.com> <3DD2A339.1070700@iprg.nokia.com> <20021113203003.GI31842@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown wrote: > Hi Fred, > > That's interesting. There has been some talk about multiple ISATAP site > routers, and scalability. Can you comment on how ISATAP performed in this > network of thousands of (mobile) hosts? I don't have any scaling figures from actual experiments, but scaling is bounded by the frequency of the polling interval for router advertisements. The spec currently lists 15min as the recommended minimum, so a density of 900 nodes per ISATAP router would produce 1 RS/RA exchange per second. Additional overhead is incurred for nodes that are actiively using the router to carry traffic vis-a-vis NS/NA exchanges, but that overhead is the same as for peer-peer communications between nodes. If a generalized path MTU discovery mechanism were deployed, there would be still more overhead for the tunnel encapsulator and decapsulator to police the path MTU of the tunnel. But, I strongly believe that generalized path MTU discovery is *not a good thing* for wireless networks. Reason being - large packets on a lossy media (e.g., IEEE 802.11) incur increased exposure to bit error rates, probability of loss, delay variance, etc. So, there is no good reason to incur the extra overhead for generalized path MTU discovery on such media - this also saves state in the routers. (I assume you meant hundreds or thousands, not hundreds of thousands) In a single cluster - hundreds or thousands. In a large MANET with clustering - hundreds OF thousands or more. You also need to get into analysis of the relative density/sparseness of each cluster. For example, having hundreds of thousands of nodes show up in the same cluster at the same point of time might cause trouble! (But, in this case, the wireless media itself would become congested long before the ISATAP routers.) 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 Nov 13 14:16:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMGhkd015550; Wed, 13 Nov 2002 14:16:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADMGhE9015549; Wed, 13 Nov 2002 14:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMGdkd015542 for ; Wed, 13 Nov 2002 14:16:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADMGnMq005867 for ; Wed, 13 Nov 2002 14:16:49 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00995 for ; Wed, 13 Nov 2002 15:16:43 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 13 Nov 2002 14:16:48 -0800 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" Cc: , "'Brian E Carpenter'" , Subject: RE: Summary Re: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 14:16:32 -0800 Message-ID: <081201c28b62$52983d80$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5.1.0.14.2.20021113164342.02db0bc0@mail.windriver.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > Hi Tony, > > >Unnecessary, dubious, & marginal are one perspective. The > point is that > >the recommendation to preclude simultanious use of SL & global is a > >serious architectural change. It is not a minor edit. > > I'm not sure where the concern is coming from that we will > make a major change to the addressing architecture during the > RFC editing phase. Neither Bob nor I have proposed or > advocated that course of action. Brian's original proposal: ... unless we recall it from the RFC Editor and cycle it through the IESG again. But I propose that we do exactly that ... Your response: ... I would support this change. ... Randy's response: ... if there is real consensus on this, processwise it could be done with a note to the rfc editor or in the 48 hour edit call as s/he is doing the final edits. ... IMHO, that looks like a subversion of the wg process for something that is in effect a major architectural change. > > You and I may disagree on whether or not this change is > warranted, and we may disagree about whether it is a major > architectural change or just a usage restriction, but we do > agree on one thing... > > This _would_ be a substantive change to the addressing architecture. Yes. The reason I claim it is architectural is it proscribes against simultaneous support for multiple scopes. > > So, I would _not_ support making this change without rough WG > consensus and proper WG and IESG review, and I'm sure that > Bob wouldn't either. > > I hope that this addresses your concern in that area. I am satisfied, and cautiously optimistic. Tony > > 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 Nov 13 14:20:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMKukd015688; Wed, 13 Nov 2002 14:20:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADMKuBo015687; Wed, 13 Nov 2002 14:20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMKqkd015680 for ; Wed, 13 Nov 2002 14:20:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADML1bB027114 for ; Wed, 13 Nov 2002 14:21:02 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03853 for ; Wed, 13 Nov 2002 15:20:56 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 13 Nov 2002 14:20:58 -0800 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , "'Brian Zill'" Cc: "'Brian E Carpenter'" , Subject: RE: Summary Re: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 14:20:42 -0800 Message-ID: <081301c28b62$e9224bb0$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5.1.0.14.2.20021113170032.02db6ec0@mail.windriver.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADMKrkd015681 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > How often do you think that people really set-up a private, > disconnected network and later connect it to the Internet? > > Do you think this will be a common real-life case, or is this > more of a theoretical edge case? Said real company needed to get IPv6 running internally before their service provider was offering service & therefore address space. This will continue to be the case in NA until the attitude at nanog changes. Tony > > Margaret > > > At 04:51 PM 11/13/02, Brian Zill wrote: > >Brian Carpenter writes: > > > 3. Can't stop NAT's anyway. (several people). > > > That may sadly be true, but we shouldn't publish > > > specs that seem to encourage them. > > > >I would argue the opposite -- *preventing* site-locals and > globals from > >co-existing encourages NAT. We're better off today than we would be > >with that restriction. > > > >Case study: A site has a disconnected network happily using > >site-locals. These addresses get embedded in all sorts of > configuration > >scripts, etc. Then they decide to connect to the Internet and get a > >global prefix from their ISP. > > > >Today: They just advertise the new global prefix alongside the > >site-local prefix, all their hard-coded addresses continue to work. > > > >With restriction on mixing site-local and global addresses: > They need > >to renumber their network and find all the places addresses > have been > >specified in config files and the like. Or they could just use a v6 > >NAT. Which do you think will happen? > > > >--Brian > > > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 13 14:22:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMMnkd015760; Wed, 13 Nov 2002 14:22:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADMMmx8015759; Wed, 13 Nov 2002 14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMMikd015749 for ; Wed, 13 Nov 2002 14:22:44 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADMMrMq008041 for ; Wed, 13 Nov 2002 14:22:53 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04298 for ; Wed, 13 Nov 2002 14:22:50 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gADMMel12814; Wed, 13 Nov 2002 17:22:40 -0500 (EST) Message-Id: <200211132222.gADMMel12814@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Michael Thomas'" , "'Harald Tveit Alvestrand'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 12:57:23 PST.") <07fc01c28b57$445d5c60$bd134104@eagleswings> Date: Wed, 13 Nov 2002 17:22:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Some of the uses for SL would be better served by PI addresses, but not > all. > > Take the case of a 20,000 node network where half are allowed global > access and half are not. yes, let's take that case. but give them all global addresses. assign one bit in the site's portion of the address which means "allowed global access" half of those nodes get globals with that bit set, the other half globals with that bit clear. put that bit anywhere in the site's portion of the address that makes it easy to filter the non-allowed traffic. now apps have a global address space to work with. they don't have to know about network topology. they don't have to keep track of scopes. they don't have to try to facilitate operation between sites. the way the app determines whether it is permitted to send traffic between A and B is to try to send that traffic. this works no matter where the decision to try to get A and B to talk to each other is made. if the network is set up right, an attempts by a host to talk to a host which it's not authorized to talk to results in an ICMP destination unreachable - administratively prohibited response. another nice thing is that there are no wired-in restrictions on where the security boundaries are, how many policies there are, etc. you can extend this kind of policy enforcement to work between multiple sites if you want to work it out with them. you can punch holes in it if you need to, so that under certain conditions certain nodes are permitted to communicate even though one of them has that bit set. perhaps most importantly - it doesn't try to use a single bit to communicate complex and unworkable security policies to apps. 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 Nov 13 14:26:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMQBkd015883; Wed, 13 Nov 2002 14:26:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADMQB3P015882; Wed, 13 Nov 2002 14:26: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMQ8kd015872 for ; Wed, 13 Nov 2002 14:26:08 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADMQHMq009209 for ; Wed, 13 Nov 2002 14:26:17 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11038 for ; Wed, 13 Nov 2002 15:26:12 -0700 (MST) 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 OAA12450 for ; Wed, 13 Nov 2002 14:26:11 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gADMQBM27535 for ; Wed, 13 Nov 2002 14:26:11 -0800 X-mProtect: <200211132226> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfFPFET; Wed, 13 Nov 2002 14:26:09 PST Message-ID: <3DD2D29F.6000200@iprg.nokia.com> Date: Wed, 13 Nov 2002 14:30:55 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Summary Re: Proposal for site-local clean-up References: <5.1.0.14.2.20021113170032.02db6ec0@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: > > How often do you think that people really set-up a private, > disconnected network and later connect it to the Internet? > > Do you think this will be a common real-life case, or is this > more of a theoretical edge case? Here again is the case for mobile ad-hoc networks. By definition, MANETs are designed to operate in infrastructureless environments. One case might be a string of vehicles on a remote highway that still find useful benefit in chit-chatting with one another even though none have access to the global Internet. But, when the string approaches a population center, hot-spot access point, etc. all should be able to share the global Internet access as long as one or more have direct connectivity. IPv6 is about anticipating and designing for *future* use cases as well as the existing paradigms of today, right? I'm *not* suggesting that we drop back into "research-mode" - only that we keep our sights set forward while we address the existing deployment scenarios we have today. 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 Nov 13 14:28:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMSUkd015967; Wed, 13 Nov 2002 14:28:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADMSUXP015966; Wed, 13 Nov 2002 14:28:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMSQkd015959 for ; Wed, 13 Nov 2002 14:28:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADMSabB029538 for ; Wed, 13 Nov 2002 14:28:36 -0800 (PST) Received: from TNEXVS01.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA01057 for ; Wed, 13 Nov 2002 15:28:28 -0700 (MST) Received: from TNEXVS02.tahoenetworks.com ([10.10.1.132]) by TNEXVS01.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Nov 2002 14:28:26 -0800 content-class: urn:content-classes:message Subject: RE: Proposal for site-local clean-up MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 13 Nov 2002 14:28:26 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6EAB6E38@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKLXWJtvjfyKEVHTnme1SS7wYoSfAABiUbg From: "Mohan Parthasarathy" To: , "Michael Thomas" , "Harald Tveit Alvestrand" Cc: "Brian E Carpenter" , X-OriginalArrivalTime: 13 Nov 2002 22:28:26.0343 (UTC) FILETIME=[FBDDB770:01C28B63] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADMSRkd015960 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mohan Parthasarathy wrote: > > > ... > > I miss something here. How do you make sure that nodes > > configure just site local and not global address on seeing an > > RA ? Are you keeping them in separate networks i.e not mixing > > nodes that require globals and site locals ? If so, then I > > can do the same with globals with appropriate partitioning > > i.e subnet 1 - 100, is for private use only. Then the check > > is very simple. Could you clarify ? > > Same network, hearing RA's, just local policy on the > restricted box to only configure based on SL prefixes. > I agree that this is possible. But this is extra configuration and assumption that the restricted box IPv6 implementation has support for such policy knobs. -mohan > 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 Nov 13 14:38:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMchkd016369; Wed, 13 Nov 2002 14:38:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADMchcJ016368; Wed, 13 Nov 2002 14:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMcdkd016358 for ; Wed, 13 Nov 2002 14:38:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADMcnbB002999 for ; Wed, 13 Nov 2002 14:38:49 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15126 for ; Wed, 13 Nov 2002 15:38:43 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 13 Nov 2002 14:38:48 -0800 Reply-To: From: "Tony Hain" To: "'Roy Brabson'" Cc: Subject: RE: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 14:38:32 -0800 Message-ID: <081401c28b65$655e6cc0$bd134104@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.3416 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 gADMcekd016359 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Roy Brabson wrote: > ... > So, instead of filtering global addresses at the firewall, > you go to each > individual box in the network which you want to restricted > access to/from > and configure it to only use restricted (i.e., site-local) > addresses? And, > as a bonus, you get to deal with all the complexity and > problems which are > introduced when using site-locals in a non-isolated > environment. How, > exactly, does this improve anything? It aligns access policy with the device rather than a difficult to manage table at every edge of the network. This is much simpler at scale. The only complexity that SL introduces in the environment is for apps that do literal rather than name based referrals. If they are written to preclude that referral when it involves a SL prefix, the issue becomes one of the network manager deciding if the app should work (thereby assigning a global), or should be broken by the SL filtering. The arguments against SL boil down to not liking the fact that network managers will do 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 Wed Nov 13 14:41:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMfIkd016456; Wed, 13 Nov 2002 14:41:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADMfI6Q016455; Wed, 13 Nov 2002 14:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMfFkd016448 for ; Wed, 13 Nov 2002 14:41:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADMfOMq014766 for ; Wed, 13 Nov 2002 14:41:24 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16629 for ; Wed, 13 Nov 2002 15:41:15 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 13 Nov 2002 14:41:12 -0800 Reply-To: From: "Tony Hain" To: "'Mohan Parthasarathy'" , "'Michael Thomas'" , "'Harald Tveit Alvestrand'" Cc: "'Brian E Carpenter'" , Subject: RE: Proposal for site-local clean-up Date: Wed, 13 Nov 2002 14:40:56 -0800 Message-ID: <081501c28b65$bd0abaf0$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6EAB6E38@TNEXVS02.tahoenetworks.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gADMfFkd016449 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mohan Parthasarathy wrote: > I agree that this is possible. But this is extra > configuration and assumption that the restricted box IPv6 > implementation has support for such policy knobs. Yes. It also aligns the policy implementation with the device that is restricted, rather than trying to track it at every edge of the network. 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 Nov 13 14:49:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMnJkd016674; Wed, 13 Nov 2002 14:49:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADMnJJM016673; Wed, 13 Nov 2002 14:49: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADMnFkd016661 for ; Wed, 13 Nov 2002 14:49:15 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADMnPbB006255 for ; Wed, 13 Nov 2002 14:49:25 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21081 for ; Wed, 13 Nov 2002 14:49:19 -0800 (PST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA29168 for ; Wed, 13 Nov 2002 22:49:18 GMT Received: from login.ecs.soton.ac.uk (IDENT:TydSbFXlnX3n7eAaRQf7VDktoACMccKO@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gADMn9WX018886 for ; Wed, 13 Nov 2002 22:49:09 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gADMn9C00712 for ipng@sunroof.eng.sun.com; Wed, 13 Nov 2002 22:49:09 GMT Date: Wed, 13 Nov 2002 22:49:08 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Summary Re: Proposal for site-local clean-up Message-ID: <20021113224908.GG371@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <5.1.0.14.2.20021113170032.02db6ec0@mail.windriver.com> <3DD2D29F.6000200@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD2D29F.6000200@iprg.nokia.com> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Nov 13, 2002 at 02:30:55PM -0800, Fred L. Templin wrote: > > IPv6 is about anticipating and designing for *future* use cases > as well as the existing paradigms of today, right? I'm *not* > suggesting that we drop back into "research-mode" - only that > we keep our sights set forward while we address the existing > deployment scenarios we have today. So what's the nemo WG view of addressing for mobile networks, for communications within and between such networks, accounting for intermittent connectivity. 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 Nov 13 15:22:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADNMZkd017104; Wed, 13 Nov 2002 15:22:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gADNMZ8e017103; Wed, 13 Nov 2002 15:22: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gADNMVkd017093 for ; Wed, 13 Nov 2002 15:22:31 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gADNMeMq028892 for ; Wed, 13 Nov 2002 15:22:40 -0800 (PST) Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10529; Wed, 13 Nov 2002 15:22:35 -0800 (PST) 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 RAA15231; Wed, 13 Nov 2002 17:22:18 -0600 (CST) Message-Id: <5.1.1.5.2.20021113165510.00a855b0@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 13 Nov 2002 17:21:23 -0600 To: Keith Moore From: Richard Carlson Subject: Re: Proposal for site-local clean-up Cc: Keith Moore , alh-ietf@tndh.net, "'Bound, Jim'" , "'Alain Durand'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com In-Reply-To: <200211131843.gADIhul11093@astro.cs.utk.edu> References: <(Your message of "Wed, 13 Nov 2002 10:48:52 CST.") <5.1.1.5.2.20021113102825.025644c0@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 Keith; At 01:43 PM 11/13/02 -0500, Keith Moore wrote: > > >No. Scopes reduce the ablity of the network to support apps. > > >They make it harder to produce an app that works independently > > >of network location, and they don't add a single extra capability > > >that wasn't present already. > > > > You keep saying that some apps will fail with scoped addresses. My poor > > brain can't grasp why this is so. Can you give me a detailed example of > > how an app will fail if it has multiple scoped addresses to choice from? > >example 1: Process A sends the addresses of process B to process C. >Processes B and C are in different scopes. (Either one might or might >not share a scope with A.) Process C cannot communicate with process >B using SLs that it has received from A. > >example 2: A sends the addresses of B to C. This time B and C are in >the same scope, but A does not have access to that scope. If A sends >the SL addresses of B to C, C can talk to B. However A has no way of >knowing whether this is the case. If on the other hand A filters SLs >in addresses that it sends to C (as some have suggested is appropriate), >C may be unable to talk to B for lack of an address that works, even >though B and C share an address scope. These are generic examples. Please provide me with the name of one of these apps. Also: * why is A sending the B's IP address to C, why not send the FQDN or some other name and let C look up the address? * How is this scenario different from the case where a filter blocks the B to C communications channel? Wouldn't the app 'see' the same failure mode? In this case the use of global addresses doesn't help does it? >In either example the problem is solved if B and C have global addresses, >and all referrals filter SL addresses. But that's not realistic given >current address allocation policies. And if we change the address allocation >policies to permit any network to get a global prefix, there's even less >reason to have SLs. > > > I don't mean that it may be hard to for the app to decide which address to > > use. Yes that's a hard problem, and we don't have a solution to it yet, > > but that doesn't seem a good enough reason to kill site locals to me. > >Standards-track protocols are supposed to have no known technical omissions >with respect to the requirements placed on them, and are supposed to have >resolved known issues. An addressing architecture that expects apps to >solve an unsolved problem that is acknowledged to be difficult doesn't >seem like it meets either of those criteria. Standards track documents are suppose to describe the protocol operation in enough detail that inter-operable implementations can be written. Where are the bake-off results that show that scoped addresses present an unsolvable problem? > > I also don't mean that an app can get confused and it will fail to > connect to > > the correct proper destination if it uses a scoped address at the wrong > > time. Yes this can happen, but it's still part of the address selection > > problem, not a basic problem with an app. > >Address selection doesn't solve this problem. Basically what the app has >to do is implement its own addressing (so it can disambiguate hosts using >the same address) and routing (so it can operate across site boundaries - >because this will be necessary for many apps). I don't grog this answer. Address selection policies is precisely the problem I think you're talking about. If an app gets a list of addresses back from a name lookup query it somehow has to order these addresses and decide which ones to try and in what order. Since a v6 host can have multiple globally unique addresses or a set of scoped addresses, the app must have some way of determining which address to use. I would think that having a know set of scoped prefixes (Global, SL, LL) would make it easier, instead of harder for the app to start the sorting process. > > I'm looking for something like FTP and NAT. FTP exchanges IP addresses in > > data messages which fail when NATs cause these addresses to change. There > > are all kinds of kludges that try to work around this problem, but the > > basic issue is that the E2E property of IP was lost and the apps suffer for > > this change. > > > > I don't see the same thing happening with site-local's, everyone agrees > > that they aren't a v6 NAT replacement so apps are not allowed to propagate > > site locals outside of the site boundary. > >No, everyone does not agree on that. First because apps aren't aware of >topology so they don't know when they're propagating an address outside >of a site boundary. Second because expecting apps to be aware of topology >imposes too much of a burden on those apps. Third because if those apps >don't have alternatives to using SLs they'll be forced to use them. Fourth >because if the apps reliably do have alternatives to SLs (for networks >that aren't isolated) then there's not much reason to have SLs at all. > > > Yes, hosts need to be aware of > > the site boundary, > >no, not hosts. hosts aren't making those decisions. apps are. > > > but that is still an address selection problem not a > > problem with the app itself. Site-locals are unique within the site > > boundaries and look just like a global IPv6 address, so what is a specific > > example where an app will be broken by using a site-local address? > >see above. > >Keith ------------------------------------ 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 Wed Nov 13 16:35:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0Zjkd017763; Wed, 13 Nov 2002 16:35:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE0ZjTx017762; Wed, 13 Nov 2002 16:35:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0Zfkd017755 for ; Wed, 13 Nov 2002 16:35:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE0ZoMq024640 for ; Wed, 13 Nov 2002 16:35:50 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18624 for ; Wed, 13 Nov 2002 17:35:45 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAE0ZWl13475; Wed, 13 Nov 2002 19:35:32 -0500 (EST) Message-Id: <200211140035.gAE0ZWl13475@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Richard Carlson cc: Keith Moore , alh-ietf@tndh.net, "'Bound, Jim'" , "'Alain Durand'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 17:21:23 CST.") <5.1.1.5.2.20021113165510.00a855b0@atalanta.ctd.anl.gov> Date: Wed, 13 Nov 2002 19:35:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >example 1: Process A sends the addresses of process B to process C. > >Processes B and C are in different scopes. (Either one might or might > >not share a scope with A.) Process C cannot communicate with process > >B using SLs that it has received from A. > > > >example 2: A sends the addresses of B to C. This time B and C are in > >the same scope, but A does not have access to that scope. If A sends > >the SL addresses of B to C, C can talk to B. However A has no way of > >knowing whether this is the case. If on the other hand A filters SLs > >in addresses that it sends to C (as some have suggested is appropriate), > >C may be unable to talk to B for lack of an address that works, even > >though B and C share an address scope. > > These are generic examples. Please provide me with the name of one of > these apps. PVM. NetSolve. SNIPE. probably Globus and Legion also. SIP. and for that matter, HTTP if it uses address literals in "moved temporarily" referrals and same-site image loading (which would make page loading *much* faster and more reliable) > * why is A sending the B's IP address to C, why not send the FQDN or some > other name and let C look up the address? because for some cases DNS is inherently too slow, too unreliable, too ambiguous, and/or not widely supported enough to use. DNS query times of several seconds are not unusual, failure rates are much worse than direct use of IP. DNS names are often ambiguous, one name mapping to multiple hosts. DNS names are sometimes scoped so that the same name doesn't have the same meaning everywhere. summary: it's unreasonable to expect all apps to use DNS all of the time. also, pushing the problem to DNS doesn't actually solve the problem, it just defines the solution in terms of another unsolvable problem. > * How is this scenario different from the case where a filter blocks the B > to C communications channel? Wouldn't the app 'see' the same failure > mode? In this case the use of global addresses doesn't help does it? example 2 illustrates why just having nodes refuse to use SLs in referrals does not work in the absence of globals. the app cannot support communication between B and C even though the network permits it, because it has used this filtering rule. > > > I don't mean that it may be hard to for the app to decide which address to > > > use. Yes that's a hard problem, and we don't have a solution to it yet, > > > but that doesn't seem a good enough reason to kill site locals to me. > > > >Standards-track protocols are supposed to have no known technical omissions > >with respect to the requirements placed on them, and are supposed to have > >resolved known issues. An addressing architecture that expects apps to > >solve an unsolved problem that is acknowledged to be difficult doesn't > >seem like it meets either of those criteria. > > Standards track documents are suppose to describe the protocol operation in > enough detail that inter-operable implementations can be written. Where > are the bake-off results that show that scoped addresses present an > unsolvable problem? you've got it wrong. we know there are problems. the burden is on those who think that scoped addresses don't cause problems to demonstrate that they're easily solved. otherwise we don't meet the requirements in 2026. > > > I also don't mean that an app can get confused and it will fail to > > connect to > > > the correct proper destination if it uses a scoped address at the wrong > > > time. Yes this can happen, but it's still part of the address selection > > > problem, not a basic problem with an app. > > > >Address selection doesn't solve this problem. Basically what the app has > >to do is implement its own addressing (so it can disambiguate hosts using > >the same address) and routing (so it can operate across site boundaries - > >because this will be necessary for many apps). > > I don't grog this answer. Address selection policies is precisely the > problem I think you're talking about. no, address selection doesn't solve the problems introduced by SLs. and it can't possibly do so, because the information needed to make the right choice about which address to use is not in general available to the host that is making the selection. > If an app gets a list of addresses > back from a name lookup query it somehow has to order these addresses and > decide which ones to try and in what order. Since a v6 host can have > multiple globally unique addresses or a set of scoped addresses, the app > must have some way of determining which address to use. I would think that > having a know set of scoped prefixes (Global, SL, LL) would make it easier, > instead of harder for the app to start the sorting process. it makes it easier to get incorrect or suboptimal results, yes. it doesn't make it easier to get the right result for that app. 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 Nov 13 16:43:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0hqkd017836; Wed, 13 Nov 2002 16:43:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE0hpq1017835; Wed, 13 Nov 2002 16:43:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0hlkd017828 for ; Wed, 13 Nov 2002 16:43:48 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE0hvbB017394 for ; Wed, 13 Nov 2002 16:43:57 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27113 for ; Wed, 13 Nov 2002 16:43:48 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAE0hfl13634; Wed, 13 Nov 2002 19:43:41 -0500 (EST) Message-Id: <200211140043.gAE0hfl13634@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Fred L. Templin" cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 14:02:18 PST.") <3DD2CBEA.5010606@iprg.nokia.com> Date: Wed, 13 Nov 2002 19:43:41 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Either way, when associated with a MANET that is currently disconnected > from the global Internet, site-locals seem like a nice feature. Right. But I don't know how to get arbitrary apps to work over such networks. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 16:45:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0j2kd017872; Wed, 13 Nov 2002 16:45:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE0j1SJ017871; Wed, 13 Nov 2002 16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0ivkd017864 for ; Wed, 13 Nov 2002 16:44:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE0j6Mq027730 for ; Wed, 13 Nov 2002 16:45:06 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22974 for ; Wed, 13 Nov 2002 17:45:00 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAE0iml13649; Wed, 13 Nov 2002 19:44:48 -0500 (EST) Message-Id: <200211140044.gAE0iml13649@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Margaret Wasserman'" , "'Michael Thomas'" , "'Harald Tveit Alvestrand'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 13:46:17 PST.") <080f01c28b5e$18a3a640$bd134104@eagleswings> Date: Wed, 13 Nov 2002 19:44:48 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > If the private nodes are organized into private and public > > subnets, so that you could use autoconfiguration with > > site-local addresses on some networks and global addresses on > > others, then why would you need site-locals for that? You > > could just advertise two different global prefixes, and > > filter one of them... > > I agree, but that requires specific topology constraints that are > unreasonable. If my laptop needs to be publicly accessable but my > printer does not, why is it reasonable to require separate network drops > rather than letting them share a hub? who said anything about separate pieces of hardware? we've been routing multiple subnets on the same cable for ages now. 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 Nov 13 16:46:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0kpkd017912; Wed, 13 Nov 2002 16:46:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE0kpAN017911; Wed, 13 Nov 2002 16:46:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0klkd017904 for ; Wed, 13 Nov 2002 16:46:47 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE0kvbB018392 for ; Wed, 13 Nov 2002 16:46:57 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28767 for ; Wed, 13 Nov 2002 16:46:51 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAE0kil13688; Wed, 13 Nov 2002 19:46:44 -0500 (EST) Message-Id: <200211140046.gAE0kil13688@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Margaret Wasserman'" , "'Brian Zill'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: Summary Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 14:20:42 PST.") <081301c28b62$e9224bb0$bd134104@eagleswings> Date: Wed, 13 Nov 2002 19:46:44 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > How often do you think that people really set-up a private, > > disconnected network and later connect it to the Internet? > > > > Do you think this will be a common real-life case, or is this > > more of a theoretical edge case? > > Said real company needed to get IPv6 running internally before their > service provider was offering service & therefore address space. This > will continue to be the case in NA until the attitude at nanog changes. have to agree here - this is a realistic case. ideally it would be handled by normal renumbering mechanisms, if we knew what those were. 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 Nov 13 16:48:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0lxkd017947; Wed, 13 Nov 2002 16:48:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE0lx1v017946; Wed, 13 Nov 2002 16:47:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0ltkd017939 for ; Wed, 13 Nov 2002 16:47:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE0m4Mq028797 for ; Wed, 13 Nov 2002 16:48:04 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20438 for ; Wed, 13 Nov 2002 17:47:58 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAE0lgl13709; Wed, 13 Nov 2002 19:47:42 -0500 (EST) Message-Id: <200211140047.gAE0lgl13709@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Mohan Parthasarathy'" , "'Michael Thomas'" , "'Harald Tveit Alvestrand'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 14:40:56 PST.") <081501c28b65$bd0abaf0$bd134104@eagleswings> Date: Wed, 13 Nov 2002 19:47:42 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I agree that this is possible. But this is extra > > configuration and assumption that the restricted box IPv6 > > implementation has support for such policy knobs. > > Yes. It also aligns the policy implementation with the device that is > restricted, rather than trying to track it at every edge of the network. it's also a really inflexible way to communicate policy. 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 Nov 13 16:48:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0mxkd017985; Wed, 13 Nov 2002 16:48:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE0mxSm017984; Wed, 13 Nov 2002 16:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0mskd017973 for ; Wed, 13 Nov 2002 16:48:54 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE0n3bB019182 for ; Wed, 13 Nov 2002 16:49:03 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28938 for ; Wed, 13 Nov 2002 17:48:57 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAE0msl13726; Wed, 13 Nov 2002 19:48:54 -0500 (EST) Message-Id: <200211140048.gAE0msl13726@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Brian Zill" cc: "Brian E Carpenter" , ipng@sunroof.eng.sun.com Subject: Re: Summary Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 13:51:31 PST.") Date: Wed, 13 Nov 2002 19:48:54 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Case study: A site has a disconnected network happily using site-locals. > These addresses get embedded in all sorts of configuration scripts, etc. > Then they decide to connect to the Internet and get a global prefix from > their ISP. > > Today: They just advertise the new global prefix alongside the > site-local prefix, all their hard-coded addresses continue to work. and their apps break because they use globals when they should be using SLs, or vice versa. yes, I've actually seen this happen. 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 Nov 13 16:51:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0pBkd018065; Wed, 13 Nov 2002 16:51:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE0pBq6018064; Wed, 13 Nov 2002 16:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE0p7kd018057 for ; Wed, 13 Nov 2002 16:51:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE0pGbB020029 for ; Wed, 13 Nov 2002 16:51:16 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA15707 for ; Wed, 13 Nov 2002 17:51:10 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAE0p5l13744; Wed, 13 Nov 2002 19:51:05 -0500 (EST) Message-Id: <200211140051.gAE0p5l13744@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Roy Brabson'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 13 Nov 2002 14:38:32 PST.") <081401c28b65$655e6cc0$bd134104@eagleswings> Date: Wed, 13 Nov 2002 19:51:05 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It aligns access policy with the device rather than a difficult to > manage table at every edge of the network. This is much simpler at > scale. neither one scales well, but for many networks (those with only one border router) you'd rather control the edge than the hosts. ideally you want to specify this more-or-less centrally and communicate it to all concerned parties. that way you get security in depth. but SL is not sufficient for this purpose. not by a longshot. and if you develop a mechanism to communicate this policy, then you don't need to use SLs for this anymore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 17:29:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE1Tckd018511; Wed, 13 Nov 2002 17:29:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE1Tc2T018510; Wed, 13 Nov 2002 17:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE1TYkd018503 for ; Wed, 13 Nov 2002 17:29:34 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE1ThMq012673 for ; Wed, 13 Nov 2002 17:29:43 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16748 for ; Wed, 13 Nov 2002 17:29:37 -0800 (PST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gAE1TamX003304 for ; Wed, 13 Nov 2002 18:29:37 -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 SAA26747 for ; Wed, 13 Nov 2002 18:29:34 -0700 (MST)] Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gAE1M37C014141 for ; Thu, 14 Nov 2002 12:22:03 +1100 (EST) Message-ID: <3DD2FABB.819A4CC4@motorola.com> Date: Thu, 14 Nov 2002 12:22:03 +1100 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: Naming and site-local addresses References: <200211121601.gACG16l01402@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > > As far as I can see, the safe way to do "two-faced" DNS with site > > locals is > > there is no safe way to do DNS with site locals, because the DNS server > has no idea who is acutally going to use the results of the query. > it's not reasonable to assume that the results will be used by the > host immediately making that query. Let me add the obvious clarification that this is only as safe as any other site local mechanism. Like site local addresses themselves, the site-local namespace has to be protected against leakage. Again, with multi-homed hosts the problem can be placed squarely in the hands of the application and the user. In a situation where we have some hosts within the "site" using only globals and some hosts using only site locals it becomes much hairier, as we remove the ability for applications to treat global and site local operation as independent. I may be out of step here, but I consider site-locals (and site-local naming) an orthogonal addressing (and naming) scheme to global addresses for sites that don't have 'reliable' global address stability (read 'dial-up' or 'mobile' neworks with changing global prefixes that may or may not exist). And thus why I think the deployment issues ultimately boil down to: (1) filters on routers (2) address selection on hosts I realise #2 is not necessarily trivial. -- 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 Nov 13 19:48:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE3mQkd019231; Wed, 13 Nov 2002 19:48:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE3mPYU019230; Wed, 13 Nov 2002 19:48:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE3mKkd019216 for ; Wed, 13 Nov 2002 19:48:21 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE3mQbB007784 for ; Wed, 13 Nov 2002 19:48:30 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16867 for ; Wed, 13 Nov 2002 19:48:20 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:2c2e:4470:29b3:47d6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id gAE3mBd28093; Thu, 14 Nov 2002 12:48:11 +0900 (JST) Date: Thu, 14 Nov 2002 12:48:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: Re: Summary Re: Proposal for site-local clean-up In-Reply-To: <4.3.2.7.2.20021113092141.0306dea0@mailhost.iprg.nokia.com> References: <3DD0F9AC.FF821AAA@hursley.ibm.com> <3DD26798.E0B165F4@hursley.ibm.com> <4.3.2.7.2.20021113092141.0306dea0@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 29 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 13 Nov 2002 09:30:23 -0800, >>>>> Bob Hinden said: > I don't think it is wise to ask the IESG to reconsider the address > architecture (this is more than an editorial change to the RFC-editor). I > also think the issues regarding the usage of site-local are more > complicated that can be expressed in a paragraph. > I don't think we will get a consensus on this one way or another. This is > IMHO about people making different benefit vs. complexity tradeoffs. Like > many other things in the IETF that there is disagreement on, I think it is > better to document what it is and why it isn't a good idea and move on. I agree. As I was afraid, we're now in the Nth time of the same loop of discussion. I would say, hoping this does not cause another flame, that the issues of site-local are not crucial for the deployment of IPv6. (The situation is different from the case for AAAA vs A6. At that time, we had to pick up a particular one, or we could not go further). We should terminate the discussion, which will not be more constructive, by describing the issues and pitfalls clearly, and should concentrate on other important issues such as the ones Margaret raised the other day. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 13 20:49:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE4n7kd019452; Wed, 13 Nov 2002 20:49:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE4n6u4019451; Wed, 13 Nov 2002 20:49:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE4n2kd019444 for ; Wed, 13 Nov 2002 20:49:02 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE4nCbB018388 for ; Wed, 13 Nov 2002 20:49:12 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17549 for ; Wed, 13 Nov 2002 20:49:06 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAE4msl14952; Wed, 13 Nov 2002 23:48:54 -0500 (EST) Message-Id: <200211140448.gAE4msl14952@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Summary Re: Proposal for site-local clean-up In-reply-to: (Your message of "Thu, 14 Nov 2002 12:48:07 +0900.") Date: Wed, 13 Nov 2002 23:48:54 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would say, hoping this does not cause another flame, that the issues > of site-local are not crucial for the deployment of IPv6. I respectfully disagree. I think it's critical that we solve this issue; otherwise IPv6 will not support more applications than NATted IPv4. We seem to have near-consensus on discouraging site-locals except in a few corner cases. It would be really unfortunate if we missed this opportunity to remove one of IPv6's worst design flaws. 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 Nov 14 00:43:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE8hOkd020170; Thu, 14 Nov 2002 00:43:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE8hNKv020169; Thu, 14 Nov 2002 00:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE8h7kd020162 for ; Thu, 14 Nov 2002 00:43:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE8hGMq017593 for ; Thu, 14 Nov 2002 00:43:17 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA09199 for ; Thu, 14 Nov 2002 01:43:10 -0700 (MST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 14 Nov 2002 00:43:07 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Nov 2002 00:43:03 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 14 Nov 2002 00:43:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for site-local clean-up Date: Thu, 14 Nov 2002 00:43:07 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKLRign+9SUQThXTuWDoCJb7Aa3IAAbD23A From: "Brian Zill" To: X-OriginalArrivalTime: 14 Nov 2002 08:43:07.0926 (UTC) FILETIME=[DB00AB60:01C28BB9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAE8hKkd020163 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore writes: > In either example the problem is solved if B and C > have global addresses, and all referrals filter > SL addresses. Yes, nodes communicating globally should have global addresses, and then there is no problem. (Although again, I think you're being overly draconian with the second bit since referrals only have to filter site-locals from leaving their site as opposed to filtering all site-locals, but that's a nit). It seems what we're arguing about here isn't technical at all. These arguments keep circling around our preconceptions about how we expect IPv6 networks will be set up and used. I believe that applications expecting to communicate globally will have access to global addresses. Without such access, I don't think it is reasonable for an application to expect global connectivity. > But that's not realistic given current address > allocation policies. I don't follow this. Are you saying it is hard to get global IPv6 addresses? > > I also don't mean that an app can get confused and > > it will fail to connect to the correct proper > > destination if it uses a scoped address at the > > wrong time. Yes this can happen, but it's still > > part of the address selection problem, not a basic > > problem with an app. > > Address selection doesn't solve this problem. Basically > what the app has to do is implement its own addressing > (so it can disambiguate hosts using the same address) > and routing (so it can operate across site boundaries - > because this will be necessary for many apps). Not really. Since the scope-id is part of the sockaddr_in6, the full address isn't ambiguous. Apps don't have to "implement their own addressing". Or routing, for that matter. Apps wanting to operate across a site boundary will need to use global addresses (or an application-level proxy on a node connected to both sites). > > I don't see the same thing happening with site-local's, > > everyone agrees that they aren't a v6 NAT replacement > > so apps are not allowed to propagate site locals > > outside of the site boundary. > > No, everyone does not agree on that. First because apps > aren't aware of topology so they don't know when they're > propagating an address outside of a site boundary. Sure they do. I've gone over this before. If you're an app, don't provide a site-local in a referral to anyone who isn't themselves communicating with you via a site-local. And also provide the global (or even just the global, if the app doesn't care about being robust against renumbering or global prefix loss). > Second because expecting apps to be aware of topology > imposes too much of a burden on those apps. They don't need to. See above. > Third because if those apps don't have alternatives to > using SLs they'll be forced to use them. Please explain why they won't have global addresses if they have global connectivity. The only apps that don't have an alternative should be those on disconnected networks, and people seem ok with letting them use site-locals. It's the opposite freedom I want to preserve, to let apps have the alternative to use a site-local instead of a global should they be inclined to do so for communication within their site. > Fourth because if the apps reliably do have alternatives > to SLs (for networks that aren't isolated) then there's > not much reason to have SLs at all. Intermittently connected networks. I believe you agreed to this point in another thread. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 14 01:04:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE94ukd020337; Thu, 14 Nov 2002 01:04:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE94tEb020336; Thu, 14 Nov 2002 01:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE94pkd020329 for ; Thu, 14 Nov 2002 01:04:51 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE950Mq021112 for ; Thu, 14 Nov 2002 01:05:00 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20758 for ; Thu, 14 Nov 2002 01:04:54 -0800 (PST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAE94olK055924 for ; Thu, 14 Nov 2002 10:04:51 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAE94kKm092460 for ; Thu, 14 Nov 2002 10:04:49 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA68610 from ; Thu, 14 Nov 2002 10:04:44 +0100 Message-Id: <3DD3671B.4F4DA6F0@hursley.ibm.com> Date: Thu, 14 Nov 2002 10:04:27 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: My conclusion re site-local clean-up References: <3DD0F9AC.FF821AAA@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, that was fun: send one message and receive a few hundred. Peace. I'm very sensitive to the argument about intermittently connected networks needing a stable prefix. So I would finally prefer the addressing architecture to contain yet another version of the text in question: Site-local addresses are designed to be used for addressing inside of a site which is not permanently connected to the Internet. Using site-local addresses, a subnet ID may be up to 54-bits long, but it is recommended to use at most 16-bit subnet IDs, for convenience of subnet management. Why? Because we don't have consensus, and this text carries less baggage than the others, which seems appropriate for an architecture document. However, it may be that this change is not enough for the WG to recall the draft from the RFC Editor. I think we should hum on that in Atlanta. Brian Brian E Carpenter wrote: > > 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, > in order to change the following paragraph in section 2.5.6: > > Current text: > > > Site-local addresses are designed to be used for addressing inside of > > a site without the need for a global prefix. Although a subnet ID > > may be up to 54-bits long, it is expected that globally-connected > > sites will use the same subnet IDs for site-local and global > > prefixes. > > Proposed new text: > > Site-local addresses are designed to be used for addressing inside of > a site which is not connected to the Internet and therefore does not > need a global prefix. They must not be used for a site that is connected > to the Internet. Using site-local addresses, a subnet ID may be up to > 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > for convenience if the site is later connected to the Internet using a > global prefix. > > Otherwise, we will need a whole new RFC just for this paragraph. > > Alternatively, we could spend the next 5 years discussing the > unnecessary complexities of using site-locals on connected sites. > > 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 Nov 14 01:09:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE99wkd020416; Thu, 14 Nov 2002 01:09:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE99wFU020415; Thu, 14 Nov 2002 01:09:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE99rkd020408 for ; Thu, 14 Nov 2002 01:09:53 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE9A2Mq021811 for ; Thu, 14 Nov 2002 01:10:02 -0800 (PST) Received: from parsmtp2.rd.francetelecom.com (parsmtp2.rd.francetelecom.com [194.167.105.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00132 for ; Thu, 14 Nov 2002 02:09:56 -0700 (MST) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 14 Nov 2002 10:09:54 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: Proposal for site-local clean-up Date: Thu, 14 Nov 2002 10:09:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKLRoIAZay1WhHMRHaPiNZyq6v4IwAdcklA From: "NOISETTE Yoann FTRD/DMI/CAE" To: "Alain Durand" Cc: X-OriginalArrivalTime: 14 Nov 2002 09:09:54.0859 (UTC) FILETIME=[98CF2FB0:01C28BBD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAE99rkd020409 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain, How could we use "well-know global-adresses" in this aim ? Indeed, as I understand the draft, the site-local addresses pointed out in paragraph 7 are reserved for this, and will be the same wherever this mechanism will be deployed... How can global addresses provide the same service ?? Did I miss something ? Yoann -----Message d'origine----- De : Alain Durand [mailto:Alain.Durand@Sun.COM] Envoye : mercredi 13 novembre 2002 19:57 A : NOISETTE Yoann FTRD/DMI/CAE Cc : ipng@sunroof.eng.sun.com Objet : Re: Proposal for site-local clean-up NOISETTE Yoann FTRD/DMI/CAE wrote: >Hi all, > >I would possibly agree with this change, but it must be clear that some >ongoing work or considered solutions will be restricted or even totally >impossible after this new statement becomes effective. >For instance, draft-ietf-ipv6-dns-discovery-07.txt gives many examples >of a Customer site, using site-local addresses (in particular for DNS >discovery), and this Customer site is connected to an ISP (thus >certainly I presume to the Internet)... > That document could be changed to use global addresses instead of site local if Brian's proposal gets adopted. - 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 Nov 14 01:21:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE9LYkd020579; Thu, 14 Nov 2002 01:21:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAE9LYf7020578; Thu, 14 Nov 2002 01:21:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAE9LVkd020571 for ; Thu, 14 Nov 2002 01:21:31 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAE9LebB004474 for ; Thu, 14 Nov 2002 01:21:40 -0800 (PST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28164 for ; Thu, 14 Nov 2002 01:21:34 -0800 (PST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id C6BFD625AD; Thu, 14 Nov 2002 10:21:27 +0100 (CET) Date: Thu, 14 Nov 2002 10:21:27 +0100 From: Harald Tveit Alvestrand To: alh-ietf@tndh.net, "'Margaret Wasserman'" , "'Brian Zill'" Cc: "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: RE: Summary Re: Proposal for site-local clean-up Message-ID: <13700000.1037265687@askvoll.hjemme.alvestrand.no> In-Reply-To: <081301c28b62$e9224bb0$bd134104@eagleswings> References: <081301c28b62$e9224bb0$bd134104@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, november 13, 2002 14:20:42 -0800 Tony Hain wrote: > Margaret Wasserman wrote: > >> How often do you think that people really set-up a private, >> disconnected network and later connect it to the Internet? >> >> Do you think this will be a common real-life case, or is this >> more of a theoretical edge case? > > Said real company needed to get IPv6 running internally before their > service provider was offering service & therefore address space. This > will continue to be the case in NA until the attitude at nanog changes. > My home network runs 6to4. I didn't need to talk to anyone. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 14 03:45:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEBj4kd021385; Thu, 14 Nov 2002 03:45:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEBj4bq021384; Thu, 14 Nov 2002 03:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEBj1kd021377 for ; Thu, 14 Nov 2002 03:45:01 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEBjAMq017724 for ; Thu, 14 Nov 2002 03:45:10 -0800 (PST) Received: from mx-relay2.treas.gov (mx-relay2.treas.gov [199.196.144.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05623 for ; Thu, 14 Nov 2002 04:45:04 -0700 (MST) From: William_G_Allmond@notes.tcs.treas.gov Received: from tias5.treas.gov (tias-gw5.treas.gov [199.196.144.15]) by mx-relay2.treas.gov (8.12.3/8.12.3) with SMTP id gAEBgL4w004805; Thu, 14 Nov 2002 06:42:22 -0500 (EST) Received: from mailhub.net.treas.gov by tias5.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.6]) with SMTP; 14 Nov 2002 11:44:59 UT Received: from notes.tcs.treas.gov (localhost [127.0.0.1]) by mailhub-2.net.treas.gov (8.12.3/8.12.3) with ESMTP id gAEBir1P027900; Thu, 14 Nov 2002 06:44:54 -0500 (EST) Sensitivity: Subject: RE: Summary Re: Proposal for site-local clean-up To: Margaret Wasserman Cc: "Brian Zill" , "Brian E Carpenter" , Date: Thu, 14 Nov 2002 06:44:53 -0500 Message-ID: X-MIMETrack: Serialize by Router on TCSHUB_LN/TCS/TREAS/GOV(Release 5.0.9 |November 16, 2001) at 11/14/2002 06:44:54 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, If this is just a theoretical edge case, then the offices that I support are mostly theory. Without going into specifics, this IS a real-life case. Gary Margaret Wasserman @sunroof.eng.sun.com on 11/13/2002 05:01:25 PM Sent by: owner-ipng@sunroof.eng.sun.com To: "Brian Zill" cc: "Brian E Carpenter" , Subject: RE: Summary Re: Proposal for site-local clean-up How often do you think that people really set-up a private, disconnected network and later connect it to the Internet? Do you think this will be a common real-life case, or is this more of a theoretical edge case? Margaret At 04:51 PM 11/13/02, Brian Zill wrote: >Brian Carpenter writes: > > 3. Can't stop NAT's anyway. (several people). > > That may sadly be true, but we shouldn't publish > > specs that seem to encourage them. > >I would argue the opposite -- *preventing* site-locals and globals from >co-existing encourages NAT. We're better off today than we would be >with that restriction. > >Case study: A site has a disconnected network happily using site-locals. >These addresses get embedded in all sorts of configuration scripts, etc. >Then they decide to connect to the Internet and get a global prefix from >their ISP. > >Today: They just advertise the new global prefix alongside the >site-local prefix, all their hard-coded addresses continue to work. > >With restriction on mixing site-local and global addresses: They need to >renumber their network and find all the places addresses have been >specified in config files and the like. Or they could just use a v6 >NAT. Which do you think will happen? > >--Brian > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Nov 14 05:38:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEDckkd021671; Thu, 14 Nov 2002 05:38:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEDckvt021670; Thu, 14 Nov 2002 05:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEDcgkd021663 for ; Thu, 14 Nov 2002 05:38:42 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEDcpMq005725 for ; Thu, 14 Nov 2002 05:38:52 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25462 for ; Thu, 14 Nov 2002 06:38:46 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAEDcil18402; Thu, 14 Nov 2002 08:38:44 -0500 (EST) Message-Id: <200211141338.gAEDcil18402@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Brian Zill" cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Thu, 14 Nov 2002 00:43:07 PST.") Date: Thu, 14 Nov 2002 08:38:44 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore writes: > > In either example the problem is solved if B and C > > have global addresses, and all referrals filter > > SL addresses. > > Yes, nodes communicating globally should have global addresses, and then > there is no problem. they don't need to be communicating globally, or to have connectivity to the public Internet. all they need is to have *some* node in the app that is communicating off-site. if that is the case then the ambiguity of SLs will still cause problems. > (Although again, I think you're being overly > draconian with the second bit since referrals only have to filter > site-locals from leaving their site as opposed to filtering all > site-locals, but that's a nit). apps aren't aware of site boundaries. > It seems what we're arguing about here isn't technical at all. These > arguments keep circling around our preconceptions about how we expect > IPv6 networks will be set up and used. indeed, that's part of the difference. > I believe that applications > expecting to communicate globally will have access to global addresses. again, it's not communicating globally, it's communicating off-site. and it's not sufficient to just give the nodes with direct off-site connectivity global adddresses - every node in the application, regardless of whether it can directly communicate off-site, needs a global address. > Without such access, I don't think it is reasonable for an application > to expect global connectivity. I think the assumption that a site can get away with just assigning globals to some nodes, and yet expecting other nodes to participate in applications along with those nodes that have off-site connectivity and use globals, is naive and effectively produces onerous requirements for those applications. > > But that's not realistic given current address > > allocation policies. > > I don't follow this. Are you saying it is hard to get global IPv6 > addresses? yes, if you don't connect directly to the Internet. > > > I also don't mean that an app can get confused and > > > it will fail to connect to the correct proper > > > destination if it uses a scoped address at the > > > wrong time. Yes this can happen, but it's still > > > part of the address selection problem, not a basic > > > problem with an app. > > > > Address selection doesn't solve this problem. Basically > > what the app has to do is implement its own addressing > > (so it can disambiguate hosts using the same address) > > and routing (so it can operate across site boundaries - > > because this will be necessary for many apps). > > Not really. Since the scope-id is part of the sockaddr_in6, the full > address isn't ambiguous. scope-ids are not globally scoped. they're only meaningful to the local host. and the scope-id isn't part of the address. so yes, they are ambiguous. > Apps don't have to "implement their own > addressing". Or routing, for that matter. Apps wanting to operate > across a site boundary will need to use global addresses (or an > application-level proxy on a node connected to both sites). and what is the purpose of the proxy if not to route messages? and just what do you think the proxy is going to use for addresses to enable it to refer to a nodes on other side of the proxy? guess it's going to have to implement its own addressing and routing after all. > > > I don't see the same thing happening with site-local's, > > > everyone agrees that they aren't a v6 NAT replacement > > > so apps are not allowed to propagate site locals > > > outside of the site boundary. > > > > No, everyone does not agree on that. First because apps > > aren't aware of topology so they don't know when they're > > propagating an address outside of a site boundary. > > Sure they do. I've gone over this before. If you're an app, don't > provide a site-local in a referral to anyone who isn't themselves > communicating with you via a site-local. and yes, we've been over this before - if the party doing the referrals is off-site (and yes, I work with apps where this can easily happen) then this filtering algorithm prevents the referral to site-local nodes if those nodes don't have globals. > And also provide the global > (or even just the global, if the app doesn't care about being robust > against renumbering or global prefix loss). the app has to deal with renumbering anyway. why should it have to implement different solutions for local-only nodes vs. other nodes? > > Second because expecting apps to be aware of topology > > imposes too much of a burden on those apps. > > They don't need to. See above. false. see above. > > Third because if those apps don't have alternatives to > > using SLs they'll be forced to use them. > > Please explain why they won't have global addresses if they have global > connectivity. they will. but global connectivity is not a necessary condition for needing global addresses. apps need global addresses if any node in the app (present or future, directly connected or not) is off-site. > The only apps that don't have an alternative should be > those on disconnected networks, and people seem ok with letting them use > site-locals. I'd like to belive that, and that would surely simplify things. But we've got someone arguing that it's okay to implement security by assigning globals only to some nodes on a site, and letting the others deal with SLs. > It's the opposite freedom I want to preserve, to let apps > have the alternative to use a site-local instead of a global should they > be inclined to do so for communication within their site. I don't have a huge problem with that - as long as globals are reliably available to any node that isn't on an isolated network, writers of multi-party apps will surely realize that the simplest way to solve their problem is to avoid using SLs. the other apps can use them if they want to. (I think it will still cause problems when they do so, but these mostly affect the local network administration, and the local network admin can always fix it by disabling SLs) > > Fourth because if the apps reliably do have alternatives > > to SLs (for networks that aren't isolated) then there's > > not much reason to have SLs at all. > > Intermittently connected networks. I believe you agreed to this point > in another thread. intermittently connected networks that lack a stable address prefix, and a couple of other corner cases. but more things will work if those networks can somehow manage to use globals. 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 Nov 14 05:54:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEDsZkd021812; Thu, 14 Nov 2002 05:54:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEDsZEV021811; Thu, 14 Nov 2002 05:54: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEDsVkd021804 for ; Thu, 14 Nov 2002 05:54:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEDsebB018351 for ; Thu, 14 Nov 2002 05:54:40 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06919 for ; Thu, 14 Nov 2002 06:54:34 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAEDsWl18440; Thu, 14 Nov 2002 08:54:32 -0500 (EST) Message-Id: <200211141354.gAEDsWl18440@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: My conclusion re site-local clean-up In-reply-to: (Your message of "Thu, 14 Nov 2002 10:04:27 +0100.") <3DD3671B.4F4DA6F0@hursley.ibm.com> Date: Thu, 14 Nov 2002 08:54:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Site-local addresses are designed to be used for addressing inside of > a site which is not permanently connected to the Internet. Using > site-local addresses, a subnet ID may be up to 54-bits long, but it > is recommended to use at most 16-bit subnet IDs, for convenience of > subnet management. I really don't think this is sufficient. First because SLs don't work for a network that has any connection to another network (it doesn't have to be the public Internet), and second because it says nothing at all about the problems with SLs. I suggest Site-local addresses are designed to be used for addressing inside of networks which have no connections to external networks. Other networks need to provide global addresses to their nodes. Use of site-local addresses on networks with external connectivity (especially in the absence of global addresses) is known to cause problems for some applications, and such use is currently not recommended. This recommendation may be changed once the implications of application use of site-locals are better understood. When using site-local addresses, a subnet ID may be up to 54-bits long, but it is recommended to use at most 16-bit subnet IDs, for convenience of subnet management. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 14 06:08:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEE8Tkd021888; Thu, 14 Nov 2002 06:08:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEE8TEh021887; Thu, 14 Nov 2002 06:08: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEE8Qkd021880 for ; Thu, 14 Nov 2002 06:08:26 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEE8abB020633 for ; Thu, 14 Nov 2002 06:08:36 -0800 (PST) Received: from mx-relay1.treas.gov (mx-relay1.treas.gov [199.196.144.5]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11267 for ; Thu, 14 Nov 2002 06:08:30 -0800 (PST) From: William_G_Allmond@notes.tcs.treas.gov Received: from tias5.treas.gov (tias-gw5.treas.gov [199.196.144.15]) by mx-relay1.treas.gov (8.12.3/8.12.3) with SMTP id gAEE8Dt8025296; Thu, 14 Nov 2002 09:08:13 -0500 (EST) Received: from mailhub.net.treas.gov by tias5.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 14 Nov 2002 14:08:13 UT Received: from notes.tcs.treas.gov (localhost [127.0.0.1]) by mailhub-2.net.treas.gov (8.12.3/8.12.3) with ESMTP id gAEE87kX025232; Thu, 14 Nov 2002 09:08:07 -0500 (EST) Sensitivity: Subject: Re: My conclusion re site-local clean-up To: Keith Moore Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Date: Thu, 14 Nov 2002 09:08:06 -0500 Message-ID: X-MIMETrack: Serialize by Router on TCSHUB_LN/TCS/TREAS/GOV(Release 5.0.9 |November 16, 2001) at 11/14/2002 09:08:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How about a compromise on the wording.... Site-local addresses are designed to be used for addressing inside of a site which is not ppermanently connected to the Internet. Use of site-local addresses on networks with external connectivity (especially in the absence of global addresses) is known to cause problems with some applications, and such use is currently not recommended. This recommendation may be changed once the implications of application use of site-local addresses are better understood. When using site local addresses, a subnet ID may be up to 54-bits long, but it is recommended to use at most 16-bit subnet IDs, for convenience of subnet management. I also recommend that a range of IP numbers be reserved for use as site-local addresses. This will prevent the rogue network administrator from picking addresses from the air. This range would be non-routable outside the local site. Keith Moore @sunroof.eng.sun.com on 11/14/2002 08:54:32 AM Sent by: owner-ipng@sunroof.eng.sun.com To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: My conclusion re site-local clean-up > Site-local addresses are designed to be used for addressing inside of > a site which is not permanently connected to the Internet. Using > site-local addresses, a subnet ID may be up to 54-bits long, but it > is recommended to use at most 16-bit subnet IDs, for convenience of > subnet management. I really don't think this is sufficient. First because SLs don't work for a network that has any connection to another network (it doesn't have to be the public Internet), and second because it says nothing at all about the problems with SLs. I suggest Site-local addresses are designed to be used for addressing inside of networks which have no connections to external networks. Other networks need to provide global addresses to their nodes. Use of site-local addresses on networks with external connectivity (especially in the absence of global addresses) is known to cause problems for some applications, and such use is currently not recommended. This recommendation may be changed once the implications of application use of site-locals are better understood. When using site-local addresses, a subnet ID may be up to 54-bits long, but it is recommended to use at most 16-bit subnet IDs, for convenience of subnet management. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Nov 14 06:23:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEENYkd022059; Thu, 14 Nov 2002 06:23:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEENYFE022058; Thu, 14 Nov 2002 06:23: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEENUkd022051 for ; Thu, 14 Nov 2002 06:23:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEENdMq015806 for ; Thu, 14 Nov 2002 06:23:40 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19923 for ; Thu, 14 Nov 2002 07:23:34 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAEENQl18546; Thu, 14 Nov 2002 09:23:26 -0500 (EST) Message-Id: <200211141423.gAEENQl18546@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: William_G_Allmond@notes.tcs.treas.gov cc: Keith Moore , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: My conclusion re site-local clean-up In-reply-to: (Your message of "Thu, 14 Nov 2002 09:08:06 EST.") Date: Thu, 14 Nov 2002 09:23:26 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Site-local addresses are designed to be used for addressing inside of a > site which is not ppermanently connected to the Internet. I still think this is misleading - something like "no stable connection to an external network" might be closer. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 14 06:31:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEEVYkd022114; Thu, 14 Nov 2002 06:31:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEEVYQP022113; Thu, 14 Nov 2002 06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEEVVkd022106 for ; Thu, 14 Nov 2002 06:31:31 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEEVeMq017071 for ; Thu, 14 Nov 2002 06:31:40 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23472 for ; Thu, 14 Nov 2002 06:31:35 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA14219; Thu, 14 Nov 2002 06:30:55 -0800 (PST) Message-Id: <5.1.0.14.2.20021114092623.02ca8ec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Nov 2002 09:32:42 -0500 To: Keith Moore From: Margaret Wasserman Subject: Re: My conclusion re site-local clean-up Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: <200211141354.gAEDsWl18440@astro.cs.utk.edu> References: <(Your message of "Thu, 14 Nov 2002 10:04:27 +0100.") <3DD3671B.4F4DA6F0@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 Keith (and others), It isn't the purpose of the addressing architecture document to define the full _use_ of site-local addresses. The addressing architecture just defines the prefix that has been assigned for this purpose... the full use (along with any restrictions on that use) will be defined in the scoped addressing architecture document. I agree that there is a bit of wording in the addressing architecture that may need to be changed, if we agree to some sort of restricted usage model for site-locals. If necessary, this wording can be changed in the scoped addressing architecture an "update" to the addressing architecture. Or we can go back and change the addressing architecture itself once we understand the nature of the change that we want to make. At this point, I think that it is most important to figure out what limitations (if any) the WG can agree (though rough consensus) to place on the use of site-local addresses. Then, we can figure out the exact wording of any required changes to the addressing architecture. Margaret At 08:54 AM 11/14/02, Keith Moore wrote: > > Site-local addresses are designed to be used for addressing inside of > > a site which is not permanently connected to the Internet. Using > > site-local addresses, a subnet ID may be up to 54-bits long, but it > > is recommended to use at most 16-bit subnet IDs, for convenience of > > subnet management. > >I really don't think this is sufficient. First because SLs don't work >for a network that has any connection to another network (it doesn't >have to be the public Internet), and second because it says nothing >at all about the problems with SLs. > >I suggest > >Site-local addresses are designed to be used for addressing inside of >networks which have no connections to external networks. Other networks >need to provide global addresses to their nodes. Use of site-local >addresses on networks with external connectivity (especially in the >absence of global addresses) is known to cause problems for some >applications, and such use is currently not recommended. This recommendation >may be changed once the implications of application use of site-locals >are better understood. When using site-local addresses, a subnet ID may >be up to 54-bits long, but it is recommended to use at most 16-bit subnet >IDs, for convenience of subnet management. > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Nov 14 06:33:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEEXhkd022159; Thu, 14 Nov 2002 06:33:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEEXgfN022156; Thu, 14 Nov 2002 06:33: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEEXdkd022148 for ; Thu, 14 Nov 2002 06:33:39 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEEXmMq017534 for ; Thu, 14 Nov 2002 06:33:48 -0800 (PST) Received: from mx-relay1.treas.gov (mx-relay1.treas.gov [199.196.144.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18040 for ; Thu, 14 Nov 2002 07:33:43 -0700 (MST) From: William_G_Allmond@notes.tcs.treas.gov Received: from tias5.treas.gov (tias-gw5.treas.gov [199.196.144.15]) by mx-relay1.treas.gov (8.12.3/8.12.3) with SMTP id gAEEXMt8011389; Thu, 14 Nov 2002 09:33:23 -0500 (EST) Received: from mailhub.net.treas.gov by tias5.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 14 Nov 2002 14:33:22 UT Received: from notes.tcs.treas.gov (localhost [127.0.0.1]) by mailhub-2.net.treas.gov (8.12.3/8.12.3) with ESMTP id gAEEXGDD002796; Thu, 14 Nov 2002 09:33:17 -0500 (EST) Sensitivity: Subject: Re: My conclusion re site-local clean-up To: Keith Moore Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Date: Thu, 14 Nov 2002 09:33:15 -0500 Message-ID: X-MIMETrack: Serialize by Router on TCSHUB_LN/TCS/TREAS/GOV(Release 5.0.9 |November 16, 2001) at 11/14/2002 09:33:17 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ok, "no stable connection to an external network" actually does sound better. So, if it is worded: Site-local addresses are designed to be used for addressing inside of a site with no stable connection to the Internet. Use of site-local addresses on networks with external connectivity (especially in the absence of global addresses) is known to cause problems with some applications, and such use is currently not recommended. This recommendation may be changed once the implications of application use of site-local addresses are better understood. When using site local addresses, a subnet ID may be up to 54-bits long, but it is recommended to use at most 16-bit subnet IDs, for convenience of subnet management. How does that sound? Gary Keith Moore @sunroof.eng.sun.com on 11/14/2002 09:23:26 AM Sent by: owner-ipng@sunroof.eng.sun.com To: William_G_Allmond@notes.tcs.treas.gov cc: Keith Moore , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: My conclusion re site-local clean-up > Site-local addresses are designed to be used for addressing inside of a > site which is not ppermanently connected to the Internet. I still think this is misleading - something like "no stable connection to an external network" might be closer. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Nov 14 06:34:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEEYGkd022175; Thu, 14 Nov 2002 06:34:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEEYGqS022174; Thu, 14 Nov 2002 06: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEEYCkd022167 for ; Thu, 14 Nov 2002 06:34:12 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEEYLbB024608 for ; Thu, 14 Nov 2002 06:34:21 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16598 for ; Thu, 14 Nov 2002 06:34:16 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA15442; Thu, 14 Nov 2002 06:33:45 -0800 (PST) Message-Id: <5.1.0.14.2.20021114093459.02caaa00@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Nov 2002 09:35:39 -0500 To: William_G_Allmond@notes.tcs.treas.gov From: Margaret Wasserman Subject: Re: My conclusion re site-local clean-up Cc: Keith Moore , Brian E Carpenter , 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 >I also recommend that a range of IP numbers be reserved for use as >site-local addresses. This will prevent the rogue network administrator >from picking addresses from the air. This range would be non-routable >outside the local site. Are you talking about a range other than FECO::/10? 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 Nov 14 07:01:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEF1Pkd022548; Thu, 14 Nov 2002 07:01:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEF1PI5022547; Thu, 14 Nov 2002 07:01: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEF1Lkd022540 for ; Thu, 14 Nov 2002 07:01:21 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEF1UMq021956 for ; Thu, 14 Nov 2002 07:01:30 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02195 for ; Thu, 14 Nov 2002 07:01:24 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAEF18l19025; Thu, 14 Nov 2002 10:01:09 -0500 (EST) Message-Id: <200211141501.gAEF18l19025@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Keith Moore , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: My conclusion re site-local clean-up In-reply-to: (Your message of "Thu, 14 Nov 2002 09:32:42 EST.") <5.1.0.14.2.20021114092623.02ca8ec0@mail.windriver.com> Date: Thu, 14 Nov 2002 10:01:08 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It isn't the purpose of the addressing architecture document to > define the full _use_ of site-local addresses. yes I understand that. trying to outline the full extent to which use of SL addresses might be reasonable (if that's even useful or feasible) would certainly require a separate (and probably quite lengthy) document. > At this point, I think that it is most important to figure out > what limitations (if any) the WG can agree (though rough consensus) > to place on the use of site-local addresses. I expect we'll have to remain fairly imprecise about this because it's very hard to outline the exact set of conditions for which SLs don't cause much harm. It's much easier to outline a somewhat narrower set of conditions for which SLs don't cause much harm. Maybe it would help if we could first get consensus on what SLs are good for, since there's little point in relaxing rules for use of SLs for situations where there are not valid use cases. I think we can agree that SLs are useful in isolated networks and networks with intermittent connectivity and lacking stable prefixes. are there any other valid use cases? (no, security/filtering is not a valid use case - since this is as easily and more flexibly accomplished with globals.) 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 Nov 14 07:03:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEF3Xkd022577; Thu, 14 Nov 2002 07:03:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEF3XNv022576; Thu, 14 Nov 2002 07:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEF3Skd022569 for ; Thu, 14 Nov 2002 07:03:28 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEF3cMq022389 for ; Thu, 14 Nov 2002 07:03:38 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11428 for ; Thu, 14 Nov 2002 07:03:32 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAEF3Jl19058; Thu, 14 Nov 2002 10:03:19 -0500 (EST) Message-Id: <200211141503.gAEF3Jl19058@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: William_G_Allmond@notes.tcs.treas.gov cc: Keith Moore , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: My conclusion re site-local clean-up In-reply-to: (Your message of "Thu, 14 Nov 2002 09:33:15 EST.") Date: Thu, 14 Nov 2002 10:03:19 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ok, "no stable connection to an external network" actually does sound > better. > > So, if it is worded: > > Site-local addresses are designed to be used for addressing inside of a > site with no stable connection to the Internet. no that's wrong. it needs to say ANY external network. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 14 07:54:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEFsqkd022849; Thu, 14 Nov 2002 07:54:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEFsqZ5022848; Thu, 14 Nov 2002 07: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEFsmkd022841 for ; Thu, 14 Nov 2002 07:54:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEFswbB008467 for ; Thu, 14 Nov 2002 07:54:58 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18963 for ; Thu, 14 Nov 2002 08:54:52 -0700 (MST) Subject: RE: Scoping Scoped Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 14 Nov 2002 07:55:30 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E463@server2000> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Scoping Scoped Addresses Thread-Index: AcKETaZJftOiJ156Thysqe8ywz9akQHpwdRQ From: "Michel Py" To: "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAEFsnkd022842 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ipv6 folk, I think there are some of you that need to re-read what Bob Hinden post here ten days and several hundreds email ago. I support Bob in the statement he made as chair and I will continue to work within the framework outlined below. Michel > Bob Hinden wrote: [Working group chair hat on] I have been trying to make some sense of this discussion. The only obvious conclusion is that there is not a consensus in the working group on how site-local addresses should be used. Some people think that site-local is an important feature with many uses, others think they are bad and should not be used. Some think they provide security, some do not. Some thing they help with renumbering, some do not. Some thing they help avoid IPv6 NAT's, some think they encourage IPv6 NAT's. Etc., etc. The only thing that is clear is there are a significant number of people who have different views on this topic. It's doubtful that one group will convince the other group. One positive result of the discussion was that the issues and benefits are better understood. The real question for the working group is what to do next. Now that the IPv6 Address Architecture was approved as a Draft Standard and the Default Address Selection document was previously approved, we have site-local addresses in IPv6 and a set of default rules for how an implementation selects them. What we don't have is how they should be used or not-used. Even though there is no consensus on how site-local addresses should be used, I think there is enough people who want to use site-local that it is reasonable that the w.g. should continue trying to flesh out site-local usage as well as pitfalls of usage. Here is a proposal for how to proceed from here that tries to take into account both sides of the discussion. 1) Node Requirements should not require any multi-site implementations. The only site-local requirement should be limited to what is currently in the address selection rules and for routers to configure site-locals just like any other unicast prefix. Vendors are free to go beyond this in their products, but the IETF won't require it. 2) People who think the usage of site-local is harmful should write a draft titled something like "Use of Site-local Addresses Considered Harmful". The people in the other camp can comment to make sure the arguments are accurate. 3) People who want to use site-local addresses should work on completing the "IPv6 Scoped Address Architecture" document (and other docs if needed). I think a good focus for this would be to focus on the simplest cases. Topics to cover need to include site border routers, adding site-local addresses in the DNS, routing protocols, the use of firewalls to enforce site boundaries, and guidelines on how applications might want to select between global and site-local addresses. The people in the other camp can review this work and make sure the technical content is accurate. I believe this approach should help provide the larger community (e.g., vendors, ISP's, enterprise operators, etc.) the information they need to make an informed decision on the usage of site-locals. Bob p.s. I will also send out a few personal comments on site-locals in a separate email. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Nov 14 08:46:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEGk9kd023042; Thu, 14 Nov 2002 08:46:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEGk8ID023041; Thu, 14 Nov 2002 08:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEGk5kd023034 for ; Thu, 14 Nov 2002 08:46:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEGkFMq013908 for ; Thu, 14 Nov 2002 08:46:15 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19663 for ; Thu, 14 Nov 2002 09:46:09 -0700 (MST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA23293 for ; Thu, 14 Nov 2002 08:45:53 -0800 (PST) Message-Id: <5.1.0.14.2.20021114114226.027b9ec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Nov 2002 11:47:11 -0500 To: IPng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Draft Agenda for Atlanta Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, Here is a draft of our agenda for next week. Please let me and Bob Hinden know if you have any comments or suggestions, or if we seem to have omitted anything. Thanks, Margaret IPv6 WG (ipv6) Monday, November 18, 2002, 1930-2200 Thursday, November 21, 2002, 0900-1130 ====================================== CHAIRS: Bob Hinden Margaret Wasserman AGENDA: Monday: Intro and Agenda Bashing -- Bob Hinden (5 min) Document Status and Priorities -- Bob Hinden (5 min) Proposed Charter Update -- Bob Hinden (15 min) MIB Updates -- Margaret Wasserman (5 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-01.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-01.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2013-update-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-02.txt Prefix Delegation: Prefix Delegation Requirements -- Shin Miyakawa (15 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-00.txt DHCP Option for Prefix Delegation -- Ralph Droms (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-03.txt Flow Label -- Jarno Rajahalme (20 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-03.txt Node Requirements -- John Loughney (30 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-02.txt Thursday: Site-Local Usage / Scoped Address Architecture -- Bob Hinden & TBD (1-1/2 hour) http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-04.txt DNS Resolver Autoconfiguration -- Alain Durand (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-dns-discovery-07.txt Issues with DHCPv6 -- Ralph Droms (10 min) http://www.ietf.org/internet-drafts/draft-droms-dhcpv6-issues-00.txt IPv6 over Fibre Channel -- Claudio DeSanti (10 min) http://www.ietf.org/internet-drafts/draft-desanti-ipv6-over-fibre-channel-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 Thu Nov 14 09:24:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEHObkd023218; Thu, 14 Nov 2002 09:24:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEHOaUn023217; Thu, 14 Nov 2002 09:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEHOWkd023210 for ; Thu, 14 Nov 2002 09:24:32 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEHOfbB002964 for ; Thu, 14 Nov 2002 09:24:42 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06940 for ; Thu, 14 Nov 2002 09:24:36 -0800 (PST) Received: from localhost ([3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id gAEHONd35263; Fri, 15 Nov 2002 02:24:24 +0900 (JST) Date: Fri, 15 Nov 2002 02:24:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Keith Moore Cc: ipng@sunroof.eng.sun.com Subject: Re: Summary Re: Proposal for site-local clean-up In-Reply-To: <200211140448.gAE4msl14952@astro.cs.utk.edu> References: <200211140448.gAE4msl14952@astro.cs.utk.edu> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 13 Nov 2002 23:48:54 -0500, >>>>> Keith Moore said: >> I would say, hoping this does not cause another flame, that the issues >> of site-local are not crucial for the deployment of IPv6. > I respectfully disagree. I think it's critical that we solve this > issue; otherwise IPv6 will not support more applications than > NATted IPv4. I don't think so, but I don't think I can convince you on this point. In order to avoid additional confusion, I'll stop here. (And you don't have to convince me on this. I don't stick to the view as long as we can really make a consensus on the site-local usage without wasting time.) > We seem to have near-consensus on discouraging site-locals except > in a few corner cases. I cannot be that optimistic according to the divergent discussion we're seeing, but if we can really make a consensus, it would of course be the best. 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 Nov 14 09:39:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEHdMkd023395; Thu, 14 Nov 2002 09:39:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEHdMom023394; Thu, 14 Nov 2002 09:39: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEHdJkd023387 for ; Thu, 14 Nov 2002 09:39:19 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEHdSbB007267 for ; Thu, 14 Nov 2002 09:39:28 -0800 (PST) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16813 for ; Thu, 14 Nov 2002 10:39:22 -0700 (MST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 4565F43C1; Thu, 14 Nov 2002 11:39:21 -0600 (CST) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 0336B1391; Thu, 14 Nov 2002 12:39:20 -0500 (EST) Message-ID: <3DD3DFC7.4090302@hp.com> Date: Thu, 14 Nov 2002 12:39:19 -0500 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: ipng@sunroof.eng.sun.com Cc: Keith Moore , Brian E Carpenter Subject: Re: My conclusion re site-local clean-up References: <200211141354.gAEDsWl18440@astro.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 I agree that site-locals are a headache and should be carefully considered. However, for the purposes of the address architecture document the new paragraph is sufficient. It states the fundamental design assumptions behind site-locals and that should be enough to caution people to their use. Stating that "more experience is needed" leads me to compare this with flowlabel definition and really don't want to go there. I also agree with Margarett that we shouldn't try to define the usage of this address here. -vlad Keith Moore wrote: > > I suggest > > Site-local addresses are designed to be used for addressing inside of > networks which have no connections to external networks. Other networks > need to provide global addresses to their nodes. Use of site-local > addresses on networks with external connectivity (especially in the > absence of global addresses) is known to cause problems for some > applications, and such use is currently not recommended. This recommendation > may be changed once the implications of application use of site-locals > are better understood. When using site-local addresses, a subnet ID may > be up to 54-bits long, but it is recommended to use at most 16-bit subnet > IDs, for convenience of subnet management. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead 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 Thu Nov 14 10:51:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEIppkd023887; Thu, 14 Nov 2002 10:51:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEIppE8023886; Thu, 14 Nov 2002 10:51:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEIplkd023879 for ; Thu, 14 Nov 2002 10:51:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEIpubB029238 for ; Thu, 14 Nov 2002 10:51:56 -0800 (PST) Received: from howler.tri.sbc.com (howler.tri.sbc.com [205.173.58.4]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17408 for ; Thu, 14 Nov 2002 11:51:51 -0700 (MST) Received: from sbctri.tri.sbc.com (mayhem-web-dmz.tri.sbc.com [144.60.9.137]) by howler.tri.sbc.com (8.12.5/8.12.5) with ESMTP id gAEIph8W021832; Thu, 14 Nov 2002 12:51:44 -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 gAEIpgB05217; Thu, 14 Nov 2002 12:51:42 -0600 (CST) Received: by trimail2 with Internet Mail Service (5.5.2653.19) id <40VRK772>; Thu, 14 Nov 2002 12:51:42 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6322702@trimail2> From: "Chen, Weijing" To: "'Margaret Wasserman'" , "'Bob Hinden'" Cc: IPng@sunroof.eng.sun.com Subject: RE: Draft Agenda for Atlanta Date: Thu, 14 Nov 2002 12:51:41 -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 Bob, Margaret, We have been studying the benefits that IPv6 could bring to a large carrier like SBC, in addition to large IP address, plug-play host connection. You might be interested in an Internet-Draft that we recently submitted as http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt. In it, we make a case for why companies like ours should be turning towards IPv6, and also suggest some new capabilities for IPv6, such as broadband Internet access, L3VPN, L2VPN. We would like to have time slot, preferred on later part of Monday or Thursday, to present our position and to advance it forward. Thank you. -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 wchen@tri.sbc.com -----Original Message----- From: Margaret Wasserman [mailto:mrw@windriver.com] Sent: Thursday, November 14, 2002 10:47 AM To: IPng@sunroof.eng.sun.com Subject: Draft Agenda for Atlanta Hi All, Here is a draft of our agenda for next week. Please let me and Bob Hinden know if you have any comments or suggestions, or if we seem to have omitted anything. Thanks, Margaret IPv6 WG (ipv6) Monday, November 18, 2002, 1930-2200 Thursday, November 21, 2002, 0900-1130 ====================================== CHAIRS: Bob Hinden Margaret Wasserman AGENDA: Monday: Intro and Agenda Bashing -- Bob Hinden (5 min) Document Status and Priorities -- Bob Hinden (5 min) Proposed Charter Update -- Bob Hinden (15 min) MIB Updates -- Margaret Wasserman (5 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-01.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-01.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2013-update-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-02.txt Prefix Delegation: Prefix Delegation Requirements -- Shin Miyakawa (15 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requir ement-00.txt DHCP Option for Prefix Delegation -- Ralph Droms (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-03.txt Flow Label -- Jarno Rajahalme (20 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-03.txt Node Requirements -- John Loughney (30 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-02.txt Thursday: Site-Local Usage / Scoped Address Architecture -- Bob Hinden & TBD (1-1/2 hour) http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-04.txt DNS Resolver Autoconfiguration -- Alain Durand (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-dns-discovery-07.txt Issues with DHCPv6 -- Ralph Droms (10 min) http://www.ietf.org/internet-drafts/draft-droms-dhcpv6-issues-00.txt IPv6 over Fibre Channel -- Claudio DeSanti (10 min) http://www.ietf.org/internet-drafts/draft-desanti-ipv6-over-fibre-channel-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 Thu Nov 14 11:11:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEJBLkd024036; Thu, 14 Nov 2002 11:11:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEJBKol024035; Thu, 14 Nov 2002 11:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEJBIkd024028 for ; Thu, 14 Nov 2002 11:11:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEJBRbB005723 for ; Thu, 14 Nov 2002 11:11:27 -0800 (PST) Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22233 for ; Thu, 14 Nov 2002 11:11:21 -0800 (PST) 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 NAA06577 for ; Thu, 14 Nov 2002 13:11:21 -0600 (CST) Message-Id: <5.1.1.5.2.20021114113445.02559da0@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 14 Nov 2002 12:52:24 -0600 To: ipng@sunroof.eng.sun.com From: Richard Carlson Subject: Re: My conclusion re site-local clean-up In-Reply-To: <3DD3671B.4F4DA6F0@hursley.ibm.com> References: <3DD0F9AC.FF821AAA@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 I wouldn't at Atlanta, so I'll hum on-line. I can accept this compromise. It recommends that SL's be user in some cases, but doesn't prohibit future uses. Rich At 10:04 AM 11/14/02 +0100, Brian E Carpenter wrote: >Well, that was fun: send one message and receive a few hundred. Peace. > >I'm very sensitive to the argument about intermittently connected >networks needing a stable prefix. So I would finally prefer the >addressing architecture to contain yet another version of the >text in question: > > Site-local addresses are designed to be used for addressing inside of > a site which is not permanently connected to the Internet. Using > site-local addresses, a subnet ID may be up to 54-bits long, but it > is recommended to use at most 16-bit subnet IDs, for convenience of > subnet management. > >Why? Because we don't have consensus, and this text carries less baggage >than the others, which seems appropriate for an architecture document. > >However, it may be that this change is not enough for the WG to recall >the draft from the RFC Editor. I think we should hum on that in Atlanta. > > Brian > >Brian E Carpenter wrote: > > > > 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, > > in order to change the following paragraph in section 2.5.6: > > > > Current text: > > > > > Site-local addresses are designed to be used for addressing inside of > > > a site without the need for a global prefix. Although a subnet ID > > > may be up to 54-bits long, it is expected that globally-connected > > > sites will use the same subnet IDs for site-local and global > > > prefixes. > > > > Proposed new text: > > > > Site-local addresses are designed to be used for addressing inside of > > a site which is not connected to the Internet and therefore does not > > need a global prefix. They must not be used for a site that is > connected > > to the Internet. Using site-local addresses, a subnet ID may be up to > > 54-bits long, but it is recommended to use at most 16-bit subnet IDs, > > for convenience if the site is later connected to the Internet using a > > global prefix. > > > > Otherwise, we will need a whole new RFC just for this paragraph. > > > > Alternatively, we could spend the next 5 years discussing the > > unnecessary complexities of using site-locals on connected sites. > > > > 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 >-------------------------------------------------------------------- ------------------------------------ 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 Nov 14 11:15:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEJFdkd024121; Thu, 14 Nov 2002 11:15:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEJFd7C024120; Thu, 14 Nov 2002 11:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEJFakd024113 for ; Thu, 14 Nov 2002 11:15:36 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEJFjMq029189 for ; Thu, 14 Nov 2002 11:15:45 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22073 for ; Thu, 14 Nov 2002 11:15:40 -0800 (PST) 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 LAA05191 for ; Thu, 14 Nov 2002 11:15:40 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAEJFdb23091 for ; Thu, 14 Nov 2002 11:15:39 -0800 X-mProtect: <200211141915> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPixXhl; Thu, 14 Nov 2002 11:15:38 PST Message-ID: <3DD3F77D.7070503@iprg.nokia.com> Date: Thu, 14 Nov 2002 11:20:29 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ipng@sunroof.eng.sun.com Subject: Re: My conclusion re site-local clean-up References: <5.1.0.14.2.20021114093459.02caaa00@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: > > >> I also recommend that a range of IP numbers be reserved for use as >> site-local addresses. This will prevent the rogue network administrator >> from picking addresses from the air. This range would be non-routable >> outside the local site. > > > Are you talking about a range other than FECO::/10? I'd like to propose F000:/4 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 Nov 14 11:38:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEJcckd024647; Thu, 14 Nov 2002 11:38:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEJccLt024646; Thu, 14 Nov 2002 11:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEJcYkd024639 for ; Thu, 14 Nov 2002 11:38:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEJchMq006367 for ; Thu, 14 Nov 2002 11:38:43 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19039 for ; Thu, 14 Nov 2002 12:38:38 -0700 (MST) Subject: RE: My conclusion re site-local clean-up MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 14 Nov 2002 11:39:18 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E46D@server2000> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: Thread-Topic: My conclusion re site-local clean-up Thread-Index: AcKME/WN//3FL2ErRz2ltRhSBx6PtAAABi8g 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 gAEJcZkd024640 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, >>> Fred L. Templin wrote >>> I also recommend that a range of IP numbers be reserved >>> for use as site-local addresses. This will prevent the >>> rogue network administrator from picking addresses from >>> the air. Since that 2002:0A00::/24 and consorts are already available for that kind of picking, I agree that it would be better to have a known range instead of random pickings. >> Are you talking about a range other than FECO::/10? > I'd like to propose F000:/4 Wow this is big. Not to mention the difficulties of obtaining a prefix that short, I think this size would be a good fit for global PI addresses such as Tony Hain's proposal, but why would site-locals need that much? 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 Nov 14 11:46:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEJkkkd024743; Thu, 14 Nov 2002 11:46:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEJkkAr024742; Thu, 14 Nov 2002 11:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEJkgkd024735 for ; Thu, 14 Nov 2002 11:46:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEJkpbB017822 for ; Thu, 14 Nov 2002 11:46:51 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26237 for ; Thu, 14 Nov 2002 12:46:46 -0700 (MST) 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 LAA06966 for ; Thu, 14 Nov 2002 11:46:45 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAEJkjZ07448; Thu, 14 Nov 2002 11:46:45 -0800 X-mProtect: <200211141946> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd488H8c; Thu, 14 Nov 2002 11:46:44 PST Message-ID: <3DD3FEC7.5070908@iprg.nokia.com> Date: Thu, 14 Nov 2002 11:51:35 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: My conclusion re site-local clean-up References: <3DD0F9AC.FF821AAA@hursley.ibm.com> <3DD3671B.4F4DA6F0@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 There have been some alternate wording suggestions since Brian's original message, but I like his text the best of all I've seen and vote to adopt it as it stands. We still have the use case of large networks that may have only intermittent connectivity to the global Internet that will need a stable prefix, as Brian says. But due to scaling limitations, a flat addressing space simply won't suffice - there needs to be some intra-site routing based on the stable prefixes. Finally, we have to account for cases that can occur due to mobility: 1) A large mobile network travels together from one attachment point to the internet to another 2) individual nodes or clusters in a non-attached network travel to a different location within the same non-attached network 3) individual nodes or clusters from one non-attached network travel to a differenet non-attached network The mobile ad-hoc network case (at least) is going to require routing based on stable prefixes on networks with only intermittent attachment. If there are problems with the apps, as Keith suggests, we're just going to have to fix them. I'm willing to help in any way I can. Fred Templin ftemplin@iprg.nokia.com Brian E Carpenter wrote: > Well, that was fun: send one message and receive a few hundred. Peace. > > I'm very sensitive to the argument about intermittently connected > networks needing a stable prefix. So I would finally prefer the > addressing architecture to contain yet another version of the > text in question: > > Site-local addresses are designed to be used for addressing inside of > a site which is not permanently connected to the Internet. Using > site-local addresses, a subnet ID may be up to 54-bits long, but it > is recommended to use at most 16-bit subnet IDs, for convenience of > subnet management. > > Why? Because we don't have consensus, and this text carries less baggage > than the others, which seems appropriate for an architecture document. > > However, it may be that this change is not enough for the WG to recall > the draft from the RFC Editor. I think we should hum on that in Atlanta. > > 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 Nov 14 12:31:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEKVckd025498; Thu, 14 Nov 2002 12:31:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAEKVbIU025497; Thu, 14 Nov 2002 12:31:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAEKVYkd025490 for ; Thu, 14 Nov 2002 12:31:34 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAEKViMq026173 for ; Thu, 14 Nov 2002 12:31:44 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09361 for ; Thu, 14 Nov 2002 12:31:38 -0800 (PST) Received: from kenawang.windriver.com ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA06871; Thu, 14 Nov 2002 12:31:20 -0800 (PST) Message-Id: <5.1.0.14.2.20021114124126.02beb440@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Nov 2002 15:33:11 -0500 To: agenda@ietf.org From: Margaret Wasserman Subject: IPv6 WG Agenda for Atlanta Cc: IPng@sunroof.eng.sun.com, Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here is the IPv6 WG agenda for Atlanta. Thanks, Margaret IPv6 WG (ipv6) Monday, November 18, 2002, 1930-2200 Thursday, November 21, 2002, 0900-1130 ====================================== CHAIRS: Bob Hinden Margaret Wasserman AGENDA: Monday: Intro and Agenda Bashing -- Bob Hinden (5 min) Document Status and Priorities -- Margaret Wasserman (5 min) Proposed Charter Update -- Margaret Wasserman (15 min) MIB Updates -- Margaret Wasserman (5 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-01.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-01.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2013-update-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-02.txt Prefix Delegation: Prefix Delegation Requirements -- Shin Miyakawa (15 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-00.txt DHCP Option for Prefix Delegation -- Ralph Droms (10 min) http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt Flow Label -- Jarno Rajahalme (20 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-03.txt Node Requirements -- John Loughney (30 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-02.txt Thursday: Site-Local Usage / Scoped Address Architecture -- Bob Hinden & TBD (1-1/2 hour) http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-04.txt DNS Resolver Autoconfiguration -- Alain Durand (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-dns-discovery-07.txt Issues with DHCPv6 -- Ralph Droms (10 min) http://www.ietf.org/internet-drafts/draft-droms-dhcpv6-issues-00.txt IPv6 over Fibre Channel -- Claudio DeSanti (10 min) http://www.ietf.org/internet-drafts/draft-desanti-ipv6-over-fibre-channel-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 Thu Nov 14 13:12:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAELCWkd025874; Thu, 14 Nov 2002 13:12:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAELCW2H025873; Thu, 14 Nov 2002 13:12: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAELCSkd025866 for ; Thu, 14 Nov 2002 13:12:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAELCabB015603 for ; Thu, 14 Nov 2002 13:12:37 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23857 for ; Thu, 14 Nov 2002 14:12:30 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAELCMl21154; Thu, 14 Nov 2002 16:12:22 -0500 (EST) Message-Id: <200211142112.gAELCMl21154@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Fred L. Templin" cc: ipng@sunroof.eng.sun.com Subject: Re: My conclusion re site-local clean-up In-reply-to: (Your message of "Thu, 14 Nov 2002 11:51:35 PST.") <3DD3FEC7.5070908@iprg.nokia.com> Date: Thu, 14 Nov 2002 16:12:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If there are problems with the apps, as Keith suggests, we're just > going to have to fix them. I'll remind you that the purpose of the network is to support applications. If the network doesn't do that job, there's only so much the app writers can do to fix it. Pretending that it's somebody else's problem won't fly. 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 Nov 14 16:15:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAF0FHkd027938; Thu, 14 Nov 2002 16:15:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAF0FHvJ027937; Thu, 14 Nov 2002 16:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAF0FEkd027930 for ; Thu, 14 Nov 2002 16:15:14 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAF0FMbB012198 for ; Thu, 14 Nov 2002 16:15:22 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02858 for ; Thu, 14 Nov 2002 17:15:17 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 14 Nov 2002 16:15:22 -0800 Reply-To: From: "Tony Hain" To: "'Brian E Carpenter'" , Subject: RE: My conclusion re site-local clean-up Date: Thu, 14 Nov 2002 16:15:03 -0800 Message-ID: <08b101c28c3c$0b462cf0$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3DD3671B.4F4DA6F0@hursley.ibm.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAF0FEkd027931 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > Well, that was fun: send one message and receive a few hundred. Peace. > > I'm very sensitive to the argument about intermittently > connected networks needing a stable prefix. So I would > finally prefer the > addressing architecture to contain yet another version of the > text in question: > > Site-local addresses are designed to be used for > addressing inside of > a site which is not permanently connected to the Internet. Using > site-local addresses, a subnet ID may be up to 54-bits > long, but it > is recommended to use at most 16-bit subnet IDs, for convenience of > subnet management. > > Why? Because we don't have consensus, and this text carries > less baggage than the others, which seems appropriate for an > architecture document. > > However, it may be that this change is not enough for the WG > to recall the draft from the RFC Editor. I think we should > hum on that in Atlanta. I still believe this is a fundemental change in the architecture. In an attempt to provide a constructive alternative, leave the architecture document alone, then in the 'scoped' document change the definition text to: Site-local scope, for uniquely identifying interfaces within a single site only. Site-local addresses are designed to provide stable addresses for use inside a site. A "site" is, by intent, not rigorously defined (just as Areas are not rigorously defined in an IGP), but is typically expected to cover a region of topology that belongs to a single organization and is located within a single geographic location, such as an office, an office complex, or a campus. As such, one common use instance of a site border might be the boundary between the IGP and EGP. Use of site-local addresses for connections external to a site is strongly discouraged, because they will usually be ambiguous values outside their domain of reference. When applications are expected to work across the site boundary, care should be taken to ensure all participating nodes have global scope addresses available. Tony > > Brian > > Brian E Carpenter wrote: > > > > 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, in order to > > change the following paragraph in section 2.5.6: > > > > Current text: > > > > > Site-local addresses are designed to be used for > addressing inside of > > > a site without the need for a global prefix. Although > a subnet ID > > > may be up to 54-bits long, it is expected that > globally-connected > > > sites will use the same subnet IDs for site-local and global > > > prefixes. > > > > Proposed new text: > > > > Site-local addresses are designed to be used for > addressing inside of > > a site which is not connected to the Internet and > therefore does not > > need a global prefix. They must not be used for a site > that is connected > > to the Internet. Using site-local addresses, a subnet ID > may be up to > > 54-bits long, but it is recommended to use at most > 16-bit subnet IDs, > > for convenience if the site is later connected to the > Internet using a > > global prefix. > > > > Otherwise, we will need a whole new RFC just for this paragraph. > > > > Alternatively, we could spend the next 5 years discussing the > > unnecessary complexities of using site-locals on connected sites. > > > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 14 16:55:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAF0tlkd028256; Thu, 14 Nov 2002 16:55:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAF0tl8d028255; Thu, 14 Nov 2002 16:55:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAF0thkd028248 for ; Thu, 14 Nov 2002 16:55:43 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAF0tpbB024332 for ; Thu, 14 Nov 2002 16:55:52 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03471 for ; Thu, 14 Nov 2002 16:55:46 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAF0tgl22283; Thu, 14 Nov 2002 19:55:43 -0500 (EST) Message-Id: <200211150055.gAF0tgl22283@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: My conclusion re site-local clean-up In-reply-to: (Your message of "Thu, 14 Nov 2002 16:15:03 PST.") <08b101c28c3c$0b462cf0$bd134104@eagleswings> Date: Thu, 14 Nov 2002 19:55:42 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I still believe this is a fundemental change in the architecture. It's just clearing up an earlier misunderstanding about the architecture - the idea that site-locals are suitable for general-purpose use. As such, it belongs at least in the addrarch document. Of course, clarifications in other documents are of course desirable. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 14 21:28:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAF5Srkd029144; Thu, 14 Nov 2002 21:28:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAF5SrDZ029143; Thu, 14 Nov 2002 21:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAF5Snkd029136 for ; Thu, 14 Nov 2002 21:28:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAF5SwMq005448 for ; Thu, 14 Nov 2002 21:28:58 -0800 (PST) Received: from roll.mentat.com ([192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA16052 for ; Thu, 14 Nov 2002 22:28:50 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id VAA21168; Thu, 14 Nov 2002 21:28:26 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id VAA13166; Thu, 14 Nov 2002 21:28:27 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id VAA01613; Thu, 14 Nov 2002 21:31:11 -0800 (PST) Date: Thu, 14 Nov 2002 21:31:11 -0800 (PST) From: Tim Hartrick Message-Id: <200211150531.VAA01613@feller.mentat.com> To: brian@hursley.ibm.com, hinden@iprg.nokia.com Subject: Re: Summary Re: Proposal for site-local clean-up Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Bob, > > I don't think it is wise to ask the IESG to reconsider the address > architecture (this is more than an editorial change to the RFC-editor). I > also think the issues regarding the usage of site-local are more > complicated that can be expressed in a paragraph. > > I don't think we will get a consensus on this one way or another. This is > IMHO about people making different benefit vs. complexity tradeoffs. Like > many other things in the IETF that there is disagreement on, I think it is > better to document what it is and why it isn't a good idea and move on. > I agree with Bob. His previous post regarding a path forward was, I believe the only path forward. There is no compromise position between the two points of view here. Or at least there is no compromise to be had from the individuals holding those points of view. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 15 06:08:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFE8nkd001063; Fri, 15 Nov 2002 06:08:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFE8n5l001062; Fri, 15 Nov 2002 06: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFE8dkd001054 for ; Fri, 15 Nov 2002 06:08:42 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFE8mbB025624 for ; Fri, 15 Nov 2002 06:08:48 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07225 for ; Fri, 15 Nov 2002 06:08:43 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAFE8Zl27126; Fri, 15 Nov 2002 09:08:35 -0500 (EST) Message-Id: <200211151408.gAFE8Zl27126@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tim Hartrick cc: brian@hursley.ibm.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Summary Re: Proposal for site-local clean-up In-reply-to: (Your message of "Thu, 14 Nov 2002 21:31:11 PST.") <200211150531.VAA01613@feller.mentat.com> Date: Fri, 15 Nov 2002 09:08:35 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is no compromise position between the two points of view here. Personally I'm hopeful that the opportunity for some us to talk about this face-to-face in Atlanta will give us a chance to resolve these differences. I do see some convergence happening, even over email. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 08:33:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFGXYkd001412; Fri, 15 Nov 2002 08:33:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFGXYLY001411; Fri, 15 Nov 2002 08:33:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFGXUkd001404 for ; Fri, 15 Nov 2002 08:33:30 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFGXcbB025525 for ; Fri, 15 Nov 2002 08:33:38 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20165 for ; Fri, 15 Nov 2002 09:33:33 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAFGXMl28021; Fri, 15 Nov 2002 11:33:22 -0500 (EST) Message-Id: <200211151633.gAFGXMl28021@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "BAUDOT Alain FTRD/DMI/CAE" cc: "Keith Moore" , William_G_Allmond@notes.tcs.treas.gov, "Brian E Carpenter" , ipng@sunroof.eng.sun.com Subject: Re: My conclusion re site-local clean-up In-reply-to: (Your message of "Fri, 15 Nov 2002 17:12:27 +0100.") Date: Fri, 15 Nov 2002 11:33:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think restricting site-local addresses to sites without ANY external > connection is wrong. I think expecting applications to cope with a mixture of site-local and global addresses is not only wrong, but unworkable, unless all nodes are also guaranteed to have globals and the site-local addresses can safely be ignored. > It results in excluding many large network with > permanent external connection, that currently have deployed > "site-local-like" addresses and aim at continuing doing so, because of > the "advantages" it provides. no, it just results in those networks having to use slightly different security measures for IPv6 than they used for IPv4. 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 Nov 15 10:09:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFI9Jkd001653; Fri, 15 Nov 2002 10:09:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFI9Ia7001652; Fri, 15 Nov 2002 10:09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFI9Fkd001645 for ; Fri, 15 Nov 2002 10:09:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFI9OMq014407 for ; Fri, 15 Nov 2002 10:09:24 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29835 for ; Fri, 15 Nov 2002 11:09:18 -0700 (MST) 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 KAA02222 for ; Fri, 15 Nov 2002 10:09:18 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAFI9H305648 for ; Fri, 15 Nov 2002 10:09:17 -0800 X-mProtect: <200211151809> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3Z1RGI; Fri, 15 Nov 2002 10:09:16 PST Message-ID: <3DD53974.60509@iprg.nokia.com> Date: Fri, 15 Nov 2002 10:14:12 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: My conclusion re site-local clean-up References: <2B81403386729140A3A899A8B39B046405E46D@server2000> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: >>Fred L. Templin wrote >>I'd like to propose F000:/4 > > Wow this is big. Not to mention the difficulties of obtaining a prefix > that short, I think this size would be a good fit for global PI > addresses such as Tony Hain's proposal, but why would site-locals need > that much? Michael, I've reflected very deeply on this and yes - I really would like to see such a short prefix set aside for other-than unicast/multicast purposes (notice I'm not saying site-locals exclusively here). As can be told from my earlier messages, I am keenly interested in large network operations in disconnected and/or intermittently connected situations. When connected to the Internet, global prefixes provide a topological frame of reference. When disconnected, no topological reference is available, but a geographical one is - it is called the Global Positioning System (GPS). To be honest, I have not read Tony's global PI proposal yet, but the DARPA mobile networking research community has been looking for ways to make geographic routing and addressing work for years. The DARPA GloMo program did some interesting work with georouting, and the ONR unmanned aerial vehicle program (along with others) have been working on a flexibile addressing scheme with geographical addressing as a core element. A limiting factor up to now has been getting enough bits for fine-grained geographic referenceing. If enough bits were available, geo-referenced prefixes would provide a nice means for supporting geographically-centered communications *with or without* the presence of global prefixes. Examples: - community networks - find the nearest Starbucks coffee by queriyng a geo-centered network - have your vehicle talk to other vehicles in the nearby vicinity w/o needing an internet access point - etc. So, I'd ask for a ::/3 or even a ::/2 if I thought there was any chance of getting it. Fred Templin ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 15 10:22:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFIMVkd001753; Fri, 15 Nov 2002 10:22:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFIMV2e001752; Fri, 15 Nov 2002 10:22: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFIMRkd001745 for ; Fri, 15 Nov 2002 10:22:28 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFIMabB025429 for ; Fri, 15 Nov 2002 10:22:36 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02579 for ; Fri, 15 Nov 2002 10:22:30 -0800 (PST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 15 Nov 2002 10:22:32 -0800 Reply-To: From: "Tony Hain" To: "'Keith Moore'" , "'BAUDOT Alain FTRD/DMI/CAE'" Cc: , "'Brian E Carpenter'" , Subject: RE: My conclusion re site-local clean-up Date: Fri, 15 Nov 2002 10:22:22 -0800 Message-ID: <08d801c28cd3$f14ae280$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211151633.gAFGXMl28021@astro.cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAFIMSkd001746 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > I think restricting site-local addresses to sites without > ANY external > > connection is wrong. > > I think expecting applications to cope with a mixture of > site-local and global addresses is not only wrong, but > unworkable, unless all nodes are also guaranteed to have > globals and the site-local > addresses can safely be ignored. It is clear that some application developers will have to decide if they want to bother with the new capabilities provided by simultaneous support for multiple scopes. That does not mean it is wrong for anyone to use them. As an example (yes hypothetical, but could easily describe the requirements or goals of the vast majority of the fortune 1000); Company X has 125,000 employees globally, with regular reorganizations causing constant office shuffles between regions. Each employee has a laptop, which will have global access, and a network connected printer which will not have global access (we won't bother with the rest of the network connected devices here). There are 100 touch-points to the Internet, with the 3 primary ones running multiple OC-48 access loops. The 'explicit filter lists at the border' model requires keeping 100 tables in sync in the face of constant change, and parsing a 125,000 entry list at OC-48 rates for every packet at 3 of the borders (while this creates demand for very expensive routers, it is not a scalable approach). The 'well-known SL filter at the border' model requires the organization to tell their printer manufacturer to preconfigure all the devices they buy to only accept and auto-configure SL prefixes from the RA (likely a widely demanded item), and put in a 2 entry list that remains static at every border. In addition, it is reasonable and expected that the peer across the border will maintain a matching version of the filter list. The compromise model of 'using 2 public prefixes per segment' allows for a 2 entry static list at every border, which may or may not be considered reasonable to match by the border peer. It does not provide the printer manufacturer a preconfiguration option that matches other customers, and even if it was done, as soon as Company X changes providers, they have to manually touch every printer for the new configuration. It also consumes 2x the public prefix space, to support nodes that will never be accessible from the public network. To make the name service simple in these 3 cases, we will run back-to-back normal dns servers. The primary set facing internally to accommodate dynamic updates, with a slave set facing externally. A periodic process will replicate the information from the source-of-truth internal facing servers to the external ones, but the security team requires it to scrub out all records for internal-only nodes. For model 1, the scrubbing process would have to contact the border filter list (after deciding which was the current source of truth), the parse through it for all 250,000 entries to decide which are replicated. For model 2, the scrubbing process simply has to look for records with the SL prefix and replicate all others. For model 3, the scrubbing process has to look for the bit flag that identifies the private-use public prefix, and replicate all others. Once any one of these processes completes, all nodes are accessable by name in the internal scope, and all nodes that should be accessed from the outside are accessable by name in the global scope. Applications that are expected to *work* across the border will have global scope addresses to use. Multi-party apps that use name-string referals will work across the border, but those that use SL literals will fail by design (note: use of SL == expected to fail across border). Use of filtered global scope addresses makes it impossible for the application to know why it failed to connect. This scenario only addresses 2 devices per employee, so the numbers could easily be 5x this large. Approaches that work in the small, rarely scale well to large distributed environments with constant churn. Another side-effect of choosing SL over global scope prefixes is the simplification of diagnostic efforts for communications within the site. It makes little sense to use RFC 3041 IID's within the boundaries of a site, and avoiding them makes it easier for the support team to correlate network traces. It is reasonable to expect OS vendors to prevent binding a 3041 IID to the SL prefix without explicit configuration. In turn, it would require explicit configuration of every device to recognize the 'private' nodes (either private-use public prefix, or the entire border filter list) to avoid use of a 3041 IID when talking to those nodes. > > > It results in excluding many large network with > > permanent external connection, that currently have deployed > > "site-local-like" addresses and aim at continuing doing so, > because of > > the "advantages" it provides. > > no, it just results in those networks having to use slightly > different security measures for IPv6 than they used for IPv4. The tone of that statement makes it a non-starter as far as the security teams are concerned. The point has to be that the security measures start from exactly the same point they are in IPv4, but with simultaneous use of SL & global prefixes we have the opportunity to expand the functionality of the network by allowing some nodes to avoid the need for nat. The absolute requirement for filtering will trump any complaints about broken applications, which means there will be site-scope address space. If we don't provide an opportunity to move beyond the current model where all nodes are required to live in the single scope of filtered space, by providing simultaneous support for site/global space, we will be stuck with nat forever. Tony > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 10:39:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFIdHkd001861; Fri, 15 Nov 2002 10:39:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFIdHcr001860; Fri, 15 Nov 2002 10:39: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFIdEkd001853 for ; Fri, 15 Nov 2002 10:39:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFIdMbB000494 for ; Fri, 15 Nov 2002 10:39:22 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14371 for ; Fri, 15 Nov 2002 11:39:16 -0700 (MST) Subject: RE: My conclusion re site-local clean-up MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 15 Nov 2002 10:40:00 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E47E@server2000> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: My conclusion re site-local clean-up Thread-Index: AcKM01ALry47oGDgQmuLYeWLGmS+PgAAUKuw From: "Michel Py" To: "Fred L. Templin" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAFIdEkd001854 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > To be honest, I have not read Tony's global PI proposal yet You should, it's based on GPS, both documents are excellent IMHO. The reason I have developed a competing system is the difficulty of obtaining a ::/4 (we use a /16 for our geo thing), not disagreement with Tony's text. 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 Nov 15 10:55:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFIt7kd001972; Fri, 15 Nov 2002 10:55:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFIt7e2001971; Fri, 15 Nov 2002 10:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFIt3kd001964 for ; Fri, 15 Nov 2002 10:55:03 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFIt8Mq028192 for ; Fri, 15 Nov 2002 10:55:08 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22565 for ; Fri, 15 Nov 2002 10:55:02 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAFIsll28433; Fri, 15 Nov 2002 13:54:47 -0500 (EST) Message-Id: <200211151854.gAFIsll28433@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Keith Moore'" , "'BAUDOT Alain FTRD/DMI/CAE'" , William_G_Allmond@notes.tcs.treas.gov, "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: My conclusion re site-local clean-up In-reply-to: (Your message of "Fri, 15 Nov 2002 10:22:22 PST.") <08d801c28cd3$f14ae280$bd134104@eagleswings> Date: Fri, 15 Nov 2002 13:54:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It is clear that some application developers will have to decide if they > want to bother with the new capabilities provided by simultaneous > support for multiple scopes. that's simple for applications developers to decide, since multiple scopes provide no new capabilities to applications. unfortunately it's not applications developers who are making the decision about whether to impose scoped addresses on networks. your hypothetical example is misleading. any filters that can be implemented with SLs can as easily be implemented with globals - and using globals provides additional flexibility (at the cost of a longer filter list) for when it is needed, that simply is not available with SL. furthermore if the company isn't just being re-organized internally but (as is common these days) is also subject to mergers and/or intensive collaboration with other organizations, SL has to be abandoned anyway. > The compromise model of 'using 2 public prefixes per segment' allows for > a 2 entry static list at every border, which may or may not be > considered reasonable to match by the border peer. there are other ways to do this than having separate prefixes. you can use any bit after the initial /48. > It does not provide > the printer manufacturer a preconfiguration option that matches other > customers, and even if it was done, as soon as Company X changes > providers, they have to manually touch every printer for the new > configuration. if printer vendors are being told that they can provide security or their devices by using site-local addresses, we need to publically shoot that idea immediately. it is completely unreasonable to assume that a site boundary is trusted or that hostile traffic cannot leak in from offsite - even if site local addresses are used. > It also consumes 2x the public prefix space, to support > nodes that will never be accessible from the public network. no it does not. > Use of filtered global scope addresses makes it impossible for the > application to know why it failed to connect. that's blatently false, as has been explained multiple times. first, there is an ICMP messages that exists for this very purpose. second, there's no way that SLs can provide a general mechanism for applications to know why a destination was unreachable anyway, because SLs are nowhere nearly flexible enough for general filtering purposes. so having applications have to deal with SL just increases the burden on applications for no gain in functionality. third, applications will be expected to communicate between nodes that use SLs - that's exactly what proxies do, for instance - and use of SLs will unnecessarily increase the complexity of almost any application that involves more than two parties. > Another side-effect of choosing SL over global scope prefixes is the > simplification of diagnostic efforts for communications within the site. no, it makes diagnostics more difficult (for both the network and for applications) because SL addresses are ambiguous. > > no, it just results in those networks having to use slightly=20 > > different security measures for IPv6 than they used for IPv4. > > The tone of that statement makes it a non-starter as far as the security > teams are concerned. The point has to be that the security measures > start from exactly the same point they are in IPv4, folks who believe that should stay with IPv4 and NAT. if you deploy a v6 network only to impair that network in such a way that v6 provides no benefit, what's the point? > but with > simultaneous use of SL & global prefixes we have the opportunity to > expand the functionality of the network by allowing some nodes to avoid > the need for nat. SL can avoid the need for NAT but still impose the same constraints on applications. what's the point, particulary when you can avoid the need for NAT without using SL? > The absolute requirement for filtering will trump any complaints about > broken applications, which means there will be site-scope address space. NO IT DOES NOT. Filtering is a given, but it does not imply scoped address space. This has been explained over and over. SLs may have some marginal utility, but filtering is not part of that. > If we don't provide an opportunity to move beyond the current model > where all nodes are required to live in the single scope of filtered > space, by providing simultaneous support for site/global space, we will > be stuck with nat forever. You have said nothing which supports such a statement. 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 Nov 15 11:43:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFJhYkd002186; Fri, 15 Nov 2002 11:43:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFJhYUK002185; Fri, 15 Nov 2002 11:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFJhUkd002178 for ; Fri, 15 Nov 2002 11:43:30 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFJhdbB021145 for ; Fri, 15 Nov 2002 11:43:39 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22878 for ; Fri, 15 Nov 2002 11:43:33 -0800 (PST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 15 Nov 2002 11:43:40 -0800 Reply-To: From: "Tony Hain" To: Cc: "'BAUDOT Alain FTRD/DMI/CAE'" , , "'Brian E Carpenter'" , Subject: RE: My conclusion re site-local clean-up Date: Fri, 15 Nov 2002 11:43:31 -0800 Message-ID: <08db01c28cdf$470068c0$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211151854.gAFIsll28433@astro.cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAFJhVkd002179 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > > The compromise model of 'using 2 public prefixes per > segment' allows > > for a 2 entry static list at every border, which may or may not be > > considered reasonable to match by the border peer. > > there are other ways to do this than having separate > prefixes. you can use any bit after the initial /48. The point is that the organization on the other side of the border may not consider a matching filter to be reasonable if it is more specific than the /48, or a well-known value. > > > It does not provide > > the printer manufacturer a preconfiguration option that > matches other > > customers, and even if it was done, as soon as Company X changes > > providers, they have to manually touch every printer for the new > > configuration. > > if printer vendors are being told that they can provide > security or their devices by using site-local addresses, we > need to publically shoot that idea immediately. it is > completely unreasonable to > assume that a site boundary is trusted or that hostile > traffic cannot leak in from offsite - even if site local > addresses are used. I did not say security, you did. I said that printers preconfigured for SL-only would comply with simplified filter policies. > > > It also consumes 2x the public prefix space, to support > > nodes that will never be accessible from the public network. > > no it does not. In the small you are correct. For an organization like Cisco with well over 50,000 registered subnets, doubling the number of public prefixes assigned to each segment will require a larger allocation from public space. > ... > > Another side-effect of choosing SL over global scope > prefixes is the > > simplification of diagnostic efforts for communications within the > > site. > > no, it makes diagnostics more difficult (for both the network and for > applications) because SL addresses are ambiguous. Not within the context of the routing domain, and filtering is explicitly intended to preclude crossing routing domains. > > > > no, it just results in those networks having to use slightly=20 > > > different security measures for IPv6 than they used for IPv4. > > > > The tone of that statement makes it a non-starter as far as the > > security teams are concerned. The point has to be that the security > > measures start from exactly the same point they are in IPv4, > > folks who believe that should stay with IPv4 and NAT. if you > deploy a v6 network only to impair that network in such a way > that v6 provides no benefit, what's the point? I listed several, but they seem to be falling on deaf ears. > > > but with > > simultaneous use of SL & global prefixes we have the opportunity to > > expand the functionality of the network by allowing some nodes to > > avoid the need for nat. > > SL can avoid the need for NAT but still impose the same > constraints on applications. what's the point, particulary > when you can avoid the need for NAT without using SL? As I said, force the network manager to choose between complex filtering or nat, and nat will win. Provide the option for multiple simultaneous use of scopes, and there is a path forward to allow apps to work where they should, and be broken where they shouldn't work. > > > The absolute requirement for filtering will trump any > complaints about > > broken applications, which means there will be site-scope address > > space. > > NO IT DOES NOT. Filtering is a given, but it does not imply > scoped address space. This has been explained over and over. Filtering == scoped address space, no matter where the bits come from. The point is that some addresses are only valid within the scope of the filter. > > SLs may have some marginal utility, but filtering is not part of that. >From the perspective of toy networks, there is little utility in simplified filtering. From the perspective of global enterprise networks, complexity is expensive, and prone to errors. > > > If we don't provide an opportunity to move beyond the current model > > where all nodes are required to live in the single scope of > filtered > > space, by providing simultaneous support for site/global space, we > > will be stuck with nat forever. > > You have said nothing which supports such a statement. Or you have refused to accept all the statements that support it... I have made the case that several have supported in private mail (but they refuse to do so on the public list to avoid being "subjected to the wrath of a rabid attack dog"), so I will not add anything further to this thread. Tony > > Keith > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 15 11:44:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFJiLkd002203; Fri, 15 Nov 2002 11:44:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFJiLnP002202; Fri, 15 Nov 2002 11:44:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFJiIkd002195 for ; Fri, 15 Nov 2002 11:44:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFJiRMq012948 for ; Fri, 15 Nov 2002 11:44:27 -0800 (PST) Received: from machine.sinus.cz (pasky.ji.cz [62.44.12.54]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA26121 for ; Fri, 15 Nov 2002 11:44:20 -0800 (PST) Received: (qmail 28253 invoked by uid 2001); 15 Nov 2002 19:44:14 -0000 Date: Fri, 15 Nov 2002 20:44:14 +0100 From: Petr Baudis To: ipng@sunroof.eng.sun.com Subject: Possible usage of site-local Message-ID: <20021115194414.GR2644@pasky.ji.cz> 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 Hello, Dear diary, on Mon, Nov 04, 2002 at 10:43:32PM CET, I got a letter, where Bob Hinden told me, that... > Even though there is no consensus on how site-local addresses should be > used, I think there is enough people who want to use site-local that it is > reasonable that the w.g. should continue trying to flesh out site-local > usage as well as pitfalls of usage. ..snip.. > I believe this approach should help provide the larger community (e.g., > vendors, ISP's, enterprise operators, etc.) the information they need to > make an informed decision on the usage of site-locals. I would like to present here one possible scenario of site-local usage, which I believe wasn't mentioned here yet. It's not a real-world usage example yet, but it may not be so far from that point. First, let me introduce you to the environment briefly. We're trying to design a possible IPv6 network addressing architecture for a non-commercial metropolitan (Prague, CZ) network based on wireless connections between nodes. One of the driving ideas was to provide a connection to that network for anyone without any charge, only for the price of the equipment (given that you'll be able to come along with the admin of the node you want to connect to). Also, connectivity to the internet should be provided by the network in some way - but the basic principle here is to give anyone a free choice, which provider he will use. Thus, various members of the network could be connected to the internet by various providers (over the network itself, as the providers are represented by own nodes in the network). Also, the network's internal topology is totally independent on points' choice of provider. Note that this is a running setup already - it's around 37 to 48 working nodes now (the current status is at http://czfree.net/monitor/), and one to three internet providers having own nodes in the network. It's running on IPv4 now, though. Now, the internal addressing is done just by giving out addresses from the 10.0.0.0/8 range, and NATing it on the provider nodes. For IPv6, you could: * Request own IPv6 space from a LIR - but that won't work out. The addresses which matter to the global internet are those which are being used by the providers. And none of the providers is going to advertise the whole network, since it would donate bandwidth even to people who aren't its clients. * Just use directly the addresses your provider will give you - but that won't work out as well. It would cause total mess in the topology, since the nodes inside of the network wouldn't be numbered consistently. Also, a lot of the nodes are probably not going to have any internet connectivity at all, thus they would have no address. * Use some global private address block; then assign the internet connected nodes also provider addresses (and let the underlying routing protocol handle the routes propagation etc). However, we are not aware of any such a prefix being available these days. * Use site-local addressing; then assign the internet connected nodes also provider addresses (and let the underlying routing protocol handle the routes propagation etc). This comes out as a natural choice, as it probably fully fulfills our requirements and it is relatively elegant solution. We think that this use of site-local addressing is fully legitimate here. What do you think? Or what alternative solutions would you suggest to this problem? Kind regards, -- Petr "Pasky" Baudis . weapon, n.: An index of the lack of development of a culture. . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 13:43:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFLhPkd003227; Fri, 15 Nov 2002 13:43:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFLhPgt003226; Fri, 15 Nov 2002 13:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFLhLkd003219 for ; Fri, 15 Nov 2002 13:43:21 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFLhUbB023478 for ; Fri, 15 Nov 2002 13:43:30 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03567 for ; Fri, 15 Nov 2002 14:43:23 -0700 (MST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 15 Nov 2002 13:43:26 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 15 Nov 2002 13:43:22 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 15 Nov 2002 13:42:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-ipv6-default-addr-select-09.txt Date: Fri, 15 Nov 2002 13:42:36 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-default-addr-select-09.txt Thread-Index: AcKM29WYU6CkLgY9S7G2m0VQNRuvrAAErAKQ From: "Richard Draves" To: "IPng List (IPng List)" Cc: "Jari Arkko" , "Bob Hinden" , "Margaret Wasserman" , "Erik Nordmark" , "Thomas Narten" X-OriginalArrivalTime: 15 Nov 2002 21:42:38.0373 (UTC) FILETIME=[EAC64550:01C28CEF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAFLhMkd003220 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, As you might know draft-ietf-ipv6-default-addr-select-09.txt passed IESG review and is with the RFC Editor. While reviewing the references we noticed that the reference to Mobile IPv6 is probably normative, because the address selection rules refer to home addresses and care-of addresses. To break this dependency, we plan to add the following subsection (this is the only change): 3.5. Mobility Addresses Some nodes may support mobility using the concepts of a home address and a care-of address (for example see [5]). Conceptually, a home address is an IP address assigned to a mobile node and used as the permanent address of the mobile node. A care-of address is an IP address associated with a mobile node while visiting a foreign link. When a mobile node is on its home link, it may have an address that is simultaneously a home address and a care-of address. For the purposes of this document, it is sufficient to know whether or not an address is designated a home address or care-of address. Whether or not an address should be designated a home address or care-of address is outside the scope of this document. Please speak up if you object to this change. I know some folks object to other aspects of draft-ietf-ipv6-default-addr-select-09 but for this discussion thread please restrict your comments to this specific change. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 13:44:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFLiqkd003283; Fri, 15 Nov 2002 13:44:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFLiqYi003282; Fri, 15 Nov 2002 13:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFLilkd003275 for ; Fri, 15 Nov 2002 13:44:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFLirMq019391 for ; Fri, 15 Nov 2002 13:44:53 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23000 for ; Fri, 15 Nov 2002 14:44:47 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAFLiil28989; Fri, 15 Nov 2002 16:44:44 -0500 (EST) Message-Id: <200211152144.gAFLiil28989@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com Subject: use of site-locals as an indication of policy? Subject-was: Re: My conclusion re site-local clean-up In-reply-to: (Your message of "Fri, 15 Nov 2002 11:43:31 PST.") <08db01c28cdf$470068c0$bd134104@eagleswings> Date: Fri, 15 Nov 2002 16:44:44 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I had written another lengthy reply to Tony's last message, but I'm not going to send it right now - maybe I'll wait, or maybe I'll send it in private mail. I'm sending a briefer reply because I want to focus attention on a question which seems fairly important to Tony's position: One of the assertions that Tony seems to be making is that SLs can be used to communicate to applications when policy forbids them from talking to one another. (Tony, if I'm mistating this, please restate it) So for instance if a process resides on a host which only has an SL address, and it wants to communicate with a peer for which it only has a global address, then the process can infer that it is forbidden as a matter of policy from communicating with that peer. Or perhaps if process A lives on a host with both global and SL addresses, and it has only a SL address for the host on which process B resides, then A can infer that B is forbidden from communicating off-site. (Offhand I haven't thought of other inferences that could be made - certainly if both hosts have both SL and global addresses then you can't assume that the hosts are allowed to connect.) Is there a widespread idea that it's reasonable for apps to make these kind of inferences? Personally, I don't think either of those inferences are reasonable - there are too many situations where a host can be temporarily without a global address (but not forbidden to communicate externally as a matter of policy), and too many situations where a process might know some but not all of the addresses at which a potential peer might be reached (so the lack of knowledge of a global for that peer doesn't imply anything about policy). 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 Nov 15 14:06:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFM6Ekd003614; Fri, 15 Nov 2002 14:06:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFM6DR4003613; Fri, 15 Nov 2002 14: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFM69kd003606 for ; Fri, 15 Nov 2002 14:06:10 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFM6IMq025184 for ; Fri, 15 Nov 2002 14:06:19 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26986 for ; Fri, 15 Nov 2002 15:06:13 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAFM4ol29165; Fri, 15 Nov 2002 17:04:50 -0500 (EST) Message-Id: <200211152204.gAFM4ol29165@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Petr Baudis cc: ipng@sunroof.eng.sun.com Subject: Re: Possible usage of site-local In-reply-to: (Your message of "Fri, 15 Nov 2002 20:44:14 +0100.") <20021115194414.GR2644@pasky.ji.cz> Date: Fri, 15 Nov 2002 17:04:50 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > We think that this use of site-local addressing is fully legitimate here. I think it's an interesting and possibly valid case. However, I haven't seen yet why it wouldn't also work to have a global prefix for use by that wireless network and another global prefix to be provided by the external service provider. Indeed, this is very similar to the scenario I've been describing where a private network isn't directly connected to the public network by itself, but does have connections to other networks that are connected to the public network. I do see is that if you use SLs then the "right" prefix is much more likely to be used whenever a node is talking to an external host. But this also assumes that you don't have many applications that use both local-to-local communications (presumably using SL addresses) and local-to-external communications (using globals). Metro area addressing would appear to be an even better solution. 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 Nov 15 14:35:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFMZxkd003880; Fri, 15 Nov 2002 14:35:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFMZxLe003879; Fri, 15 Nov 2002 14:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFMZukd003872 for ; Fri, 15 Nov 2002 14:35:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFMa4bB007519 for ; Fri, 15 Nov 2002 14:36:04 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01707 for ; Fri, 15 Nov 2002 15:35:59 -0700 (MST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 15 Nov 2002 14:35:58 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 15 Nov 2002 14:35:58 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 15 Nov 2002 14:35:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: use of site-locals as an indication of policy? Date: Fri, 15 Nov 2002 14:35:58 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: use of site-locals as an indication of policy? Thread-Index: AcKM8p89cGg71M+CTLu11qFWCHcpzgABCVFg From: "Richard Draves" To: "Keith Moore" Cc: X-OriginalArrivalTime: 15 Nov 2002 22:35:57.0624 (UTC) FILETIME=[5DAD3B80:01C28CF7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAFMZukd003873 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think the answer is yes, it is reasonable to use site-locals as an indication of policy. The kind of examples I have in mind are 1) A default configuration for some applications (eg database, file, and print servers) might be to only accept connections from site-local addresses. These applications would be running on hosts with both global and site-local addresses. 2) A default configuration for some IP appliances (eg printers) might be to only configure link-local and site-local addresses. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 14:50:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFMo6kd004136; Fri, 15 Nov 2002 14:50:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFMo6pO004135; Fri, 15 Nov 2002 14:50:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFMo1kd004119 for ; Fri, 15 Nov 2002 14:50:01 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFMoAMq006486 for ; Fri, 15 Nov 2002 14:50:10 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14360 for ; Fri, 15 Nov 2002 15:50:04 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAFMo2l29828; Fri, 15 Nov 2002 17:50:02 -0500 (EST) Message-Id: <200211152250.gAFMo2l29828@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , ipng@sunroof.eng.sun.com Subject: Re: use of site-locals as an indication of policy? In-reply-to: (Your message of "Fri, 15 Nov 2002 14:35:58 PST.") Date: Fri, 15 Nov 2002 17:50:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think the answer is yes, it is reasonable to use site-locals as an > indication of policy. The kind of examples I have in mind are > > 1) A default configuration for some applications (eg database, file, and > print servers) might be to only accept connections from site-local > addresses. These applications would be running on hosts with both global > and site-local addresses. would it be reasonable for applications to assume this rather than having a particular kind of site policy be assumed by default? my view is that security policy should always be explicit, never assumed. in general, the application writer has no idea what degree of trust is invested in "local" hosts. > 2) A default configuration for some IP appliances (eg printers) might be > to only configure link-local and site-local addresses. I can see doing this to allow initial configuration of hardware devices without keyboards and displays (though use of link-local would be even better). but again, I don't see it as reasonable for the device vendor to make assumptions about a customer's security policy. 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 Nov 15 14:53:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFMrQkd004333; Fri, 15 Nov 2002 14:53:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFMrQ8G004332; Fri, 15 Nov 2002 14:53:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFMrMkd004319 for ; Fri, 15 Nov 2002 14:53:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFMrVMq007546 for ; Fri, 15 Nov 2002 14:53:31 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10523 for ; Fri, 15 Nov 2002 15:53:25 -0700 (MST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 15 Nov 2002 14:53:25 -0800 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 15 Nov 2002 14:53:25 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 15 Nov 2002 14:53:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Scoping Scoped Addresses Date: Fri, 15 Nov 2002 14:53:25 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Scoping Scoped Addresses Thread-Index: AcKETaZJftOiJ156Thysqe8ywz9akQHpwdRQAECv5PA= From: "Richard Draves" To: "Bob Hinden" , X-OriginalArrivalTime: 15 Nov 2002 22:53:24.0865 (UTC) FILETIME=[CDE18710:01C28CF9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAFMrMkd004320 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I support Bob Hinden's email, quoted below. I don't understand why we are spending so much time on this issue. I get this impression that the folks who haven't yet implemented support for site-local addresses are worried that they will suddenly be stuck implementing and testing a bunch of code they don't want. That's really not the case. I do not advocate requiring every host and router implementation to have multi-site support. I think all that's required for host implementations is the default address selection rules, and all that's required for router implementations is to have two modes (either all interfaces are in the same site so site-locals are treated like globals, or all interfaces are in different sites so site-locals are filtered). This is really very little burden for host and router implementations. I do not advocate requiring applications to work well on multi-sited hosts. Some developers will want to support this, some will not and that's OK. For distributed applications that do referrals, a simple policy is to run in either "global mode" (only using global addresses) or "site mode" (only using site-local addresses). This takes very little code to implement. Anything more sophisticated should be at the discretion of the developer. Rich > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Thursday, November 14, 2002 7:56 AM > To: Bob Hinden; ipng@sunroof.eng.sun.com > Subject: RE: Scoping Scoped Addresses > > > Ipv6 folk, > > I think there are some of you that need to re-read what Bob > Hinden post here ten days and several hundreds email ago. > > I support Bob in the statement he made as chair and I will > continue to work within the framework outlined below. > > Michel > > > Bob Hinden wrote: > [Working group chair hat on] > > I have been trying to make some sense of this discussion. > The only obvious > conclusion is that there is not a consensus in the working > group on how > site-local addresses should be used. > > Some people think that site-local is an important feature > with many uses, > others think they are bad and should not be used. Some think > they provide > security, some do not. Some thing they help with > renumbering, some do > not. Some thing they help avoid IPv6 NAT's, some think they > encourage IPv6 > NAT's. Etc., etc. The only thing that is clear is there are > a significant > number of people who have different views on this topic. > It's doubtful > that one group will convince the other group. One positive > result of the > discussion was that the issues and benefits are better > understood. The > real question for the working group is what to do next. > > Now that the IPv6 Address Architecture was approved as a > Draft Standard and > the Default Address Selection document was previously > approved, we have > site-local addresses in IPv6 and a set of default rules for how an > implementation selects them. What we don't have is how they > should be used > or not-used. > > Even though there is no consensus on how site-local addresses > should be > used, I think there is enough people who want to use > site-local that it is > reasonable that the w.g. should continue trying to flesh out > site-local > usage as well as pitfalls of usage. > > Here is a proposal for how to proceed from here that tries to > take into > account both sides of the discussion. > > 1) Node Requirements should not require any multi-site > implementations. The only site-local requirement should be > limited to what > is currently in the address selection rules and for routers > to configure > > site-locals just like any other unicast prefix. Vendors are > free to go > beyond this in their products, but the IETF won't require it. > > 2) People who think the usage of site-local is harmful should > write a draft > titled something like "Use of Site-local Addresses Considered > Harmful". The people in the other camp can comment to make sure the > arguments are accurate. > > 3) People who want to use site-local addresses should work on > completing > > the "IPv6 Scoped Address Architecture" document (and other docs if > needed). I think a good focus for this would be to focus on > the simplest > cases. Topics to cover need to include site border routers, adding > site-local addresses in the DNS, routing protocols, the use > of firewalls to > enforce site boundaries, and guidelines on how applications > might want to > select between global and site-local addresses. The people > in the other > > camp can review this work and make sure the technical content > is accurate. > > I believe this approach should help provide the larger > community (e.g., > vendors, ISP's, enterprise operators, etc.) the information > they need to > > make an informed decision on the usage of site-locals. > > Bob > > p.s. I will also send out a few personal comments on site-locals in a > separate email. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 15 15:22:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFNMmkd004749; Fri, 15 Nov 2002 15:22:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFNMmVO004748; Fri, 15 Nov 2002 15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFNMekd004741 for ; Fri, 15 Nov 2002 15:22:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFNMnMq015114 for ; Fri, 15 Nov 2002 15:22:49 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09074 for ; Fri, 15 Nov 2002 16:22:43 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAFNMTl00219; Fri, 15 Nov 2002 18:22:29 -0500 (EST) Message-Id: <200211152322.gAFNMTl00219@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Bob Hinden" , ipng@sunroof.eng.sun.com Subject: Re: Scoping Scoped Addresses In-reply-to: (Your message of "Fri, 15 Nov 2002 14:53:25 PST.") Date: Fri, 15 Nov 2002 18:22:29 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My view is that in the absence of strong discouragement of SL addresses (with a few clearly valid use cases as exceptions), applications will be expected to work well with a mixture of SL and global addresses - even if IETF doesn't expect that. So I don't think it's sufficient to simply say "folks can use SLs if they want to", or even "site mode apps don't have to talk to global mode apps" - the former will create a support burden for apps and the latter won't match with user expectations. I doubt there are many inherently "site mode" apps. I'm sure there are some, but offhand I can't think of any. The trick is to provide recommendations that make it simple to do the right thing. A general discouragment of SLs would accomplish this. Trying to outline all (and have applications detect and handle) of the specific cases where SLs *could* be used is very difficult. Keith > I don't understand why we are spending so much time on this issue. I get > this impression that the folks who haven't yet implemented support for > site-local addresses are worried that they will suddenly be stuck > implementing and testing a bunch of code they don't want. That's really > not the case. > > I do not advocate requiring every host and router implementation to have > multi-site support. I think all that's required for host implementations > is the default address selection rules, and all that's required for > router implementations is to have two modes (either all interfaces are > in the same site so site-locals are treated like globals, or all > interfaces are in different sites so site-locals are filtered). This is > really very little burden for host and router implementations. > > I do not advocate requiring applications to work well on multi-sited > hosts. Some developers will want to support this, some will not and > that's OK. > > For distributed applications that do referrals, a simple policy is to > run in either "global mode" (only using global addresses) or "site mode" > (only using site-local addresses). This takes very little code to > implement. Anything more sophisticated should be at the discretion of > the developer. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 15:25:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFNPNkd004781; Fri, 15 Nov 2002 15:25:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFNPNSq004780; Fri, 15 Nov 2002 15:25: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFNPKkd004773 for ; Fri, 15 Nov 2002 15:25:20 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFNPSMq015895 for ; Fri, 15 Nov 2002 15:25:28 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25811 for ; Fri, 15 Nov 2002 16:25:23 -0700 (MST) 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 PAA24478 for ; Fri, 15 Nov 2002 15:25:22 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAFNPL816211 for ; Fri, 15 Nov 2002 15:25:21 -0800 X-mProtect: <200211152325> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgX1iCh; Fri, 15 Nov 2002 15:25:19 PST Message-ID: <3DD5838A.6080205@iprg.nokia.com> Date: Fri, 15 Nov 2002 15:30:18 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Scoping Scoped Addresses Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, > I do not advocate requiring every host and router implementation to have > multi-site support. I think all that's required for host implementations > is the default address selection rules, and all that's required for > router implementations is to have two modes (either all interfaces are > in the same site so site-locals are treated like globals, or all > interfaces are in different sites so site-locals are filtered). This is > really very little burden for host and router implementations. Sounds like you're referring here to the case of multilink subnets, as in Dave and Christian's draft. Having multiple interfaces attached to the same site vs. one interface per site is a design consideration we were investigating for MANET applications at SRI shortly prior to my departure 6mos ago, but we didn't come to any firm conclusions. I have been unable to find time to review that draft recently (let's just say I've been off chasing wild geese), but I'm planning to take a look at it today with two design points in mind: - does it scale to 10,000+ nodes? 100,000+ nodes? etc? - does it truly make life easier than multi-homing? Thanks, Fred Templin ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 15 15:44:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFNiskd005239; Fri, 15 Nov 2002 15:44:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAFNis39005238; Fri, 15 Nov 2002 15:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAFNipkd005231 for ; Fri, 15 Nov 2002 15:44:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAFNj0Mq021133 for ; Fri, 15 Nov 2002 15:45:00 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04831 for ; Fri, 15 Nov 2002 16:44:54 -0700 (MST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 15 Nov 2002 15:44:49 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 15 Nov 2002 15:44:49 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 15 Nov 2002 15:44:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Scoping Scoped Addresses Date: Fri, 15 Nov 2002 15:44:51 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Scoping Scoped Addresses Thread-Index: AcKNAKCiG3d9+BHoQYq9mOM0mzTCtAAAD8gQ From: "Richard Draves" To: "Fred L. Templin" Cc: X-OriginalArrivalTime: 15 Nov 2002 23:44:50.0060 (UTC) FILETIME=[FCCCECC0:01C28D00] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAFNipkd005232 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I do not advocate requiring every host and router > implementation to have > multi-site support. I think all > that's required for host implementations > is the default > address selection rules, and all that's required for > > router implementations is to have two modes (either all > interfaces are > in the same site so site-locals are treated > like globals, or all > interfaces are in different sites so > site-locals are filtered). This is > really very little > burden for host and router implementations. > > Sounds like you're referring here to the case of multilink > subnets, as in Dave and Christian's draft. Having multiple > interfaces attached to the same site vs. one interface per > site is a design consideration we were investigating for > MANET applications at SRI shortly prior to my departure 6mos > ago, but we didn't come to any firm conclusions. Actually no, I was not referring to multilink subnets. I think they are entirely unrelated. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 16:01:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAG01Ckd005685; Fri, 15 Nov 2002 16:01:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAG01C54005684; Fri, 15 Nov 2002 16:01: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAG019kd005677 for ; Fri, 15 Nov 2002 16:01:09 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAG01IMq025764 for ; Fri, 15 Nov 2002 16:01:18 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27851 for ; Fri, 15 Nov 2002 17:01:12 -0700 (MST) Received: from alasilvretta (ala-silvretta [147.11.48.37]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id QAA23819 for ; Fri, 15 Nov 2002 16:00:56 -0800 (PST) From: "Neeraj Bhatia" To: Subject: interface admin status affect on routing and protocol state Date: Fri, 15 Nov 2002 16:15:50 -0800 Message-ID: <005c01c28d05$52506ab0$25300b93@alasilvretta> 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have few questions on admin control.RFC 2465 defines ipv6IfAdminStatus" also draft-ietf-ipv6-rfc2011-update-01.txt defines ipv4IfAdminStatus and ipv6InterfaceAdminStatus. 1) RFC 1812 type behavior for IPv6 When IPv6 interface admin status is brought down(2) by explicit management action ,what is the treatment for routes through that interface.Is it expected to be same as specified in RFC 1812 section 5.3.12.3 when an interface Fails or is disabled? Since the stack is not doing IPv6 traffic the routing protocols cannot send their packets through that interface too. Would the router be required to remove and stop advertising such routes? Is there any difference in the way going down of "ipv6IfAdminStatus" OR "ifAdminStatus". effects the routing table? 2)Admin Status affect on Protocols IMHO state changes to down(2) should produce the effects as below: a)ipv6InterfaceAdminStatus 1.effects v6 routes 2.effects v6 protocol states(ie informs TCP etc.) b)ipv4IfAdminStatus 1.affects v4 routes 2.affects v4 protocol states c)ifAdminStatus ? Section 3.2.2. in draft-ietf-ipv6-rfc2011-update-01.txt states, "Setting ifAdminStatus to "down" should not affect the protocol specific status objects." Shouldn't all the routes (v4 and v6) be affected and protocols be informed of the link state change? Thx. Neeraj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 16:19:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAG0Jnkd005897; Fri, 15 Nov 2002 16:19:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAG0JnUa005896; Fri, 15 Nov 2002 16: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAG0Jkkd005889 for ; Fri, 15 Nov 2002 16:19:46 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAG0JsbB007516 for ; Fri, 15 Nov 2002 16:19:55 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23227 for ; Fri, 15 Nov 2002 16:19:48 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id CAA09397; Sat, 16 Nov 2002 02:19:27 +0200 Date: Sat, 16 Nov 2002 02:19:27 +0200 Message-Id: <200211160019.CAA09397@burp.tkv.asdf.org> From: Markku Savela To: moore@cs.utk.edu CC: richdr@microsoft.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com In-reply-to: <200211152322.gAFNMTl00219@astro.cs.utk.edu> (message from Keith Moore on Fri, 15 Nov 2002 18:22:29 -0500) Subject: Re: Scoping Scoped Addresses References: <200211152322.gAFNMTl00219@astro.cs.utk.edu> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Keith Moore > Trying to outline all (and have applications detect and handle) of the > specific cases where SLs *could* be used is very difficult. I cannot figure out where this comes from. Most applications don't need to do anything different for SL than they are doing for globals. If your node belongs to only one site, SL's behave exactly like global addresses inside the node. A client application establishing a connection would just get the address from DNS (or whatever source), and use it as is, wether SL or not. The only cases, that might require additional work, are applications that pass own address inside the protocol. I can think one example of such: IRC and activating client-to-client connection. When doing so, an IRC client sends an IRC private message containing it's own address and port over the IRC network. A careful client, which is prepared to work in multihomed host, would extract own address from the connection that is being used for the server. - however, the server might be on SL address, but connected to outside world. Then this strategy would fail. The minor additional work in this case in IPv6 world, would be to ask highest scope address that is available (although things get a bit fuzzy, if node is truly multihomed with multiple global addresses on different interfaces..) - above is no way different situation that currently exists, if your IRC server is on 10.x.x.x address. If you have both 10.x.x.x and some global address, client should send the global address, and not the address used to talk with the IRC server. - if you don't have global address (either IPv6 global or IPv4 global), you are hosed any way (unless the other client is also same site, in which case all works just fine 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 Sat Nov 16 14:52:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAGMqNkd009887; Sat, 16 Nov 2002 14:52:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAGMqNaK009886; Sat, 16 Nov 2002 14:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAGMqKkd009879 for ; Sat, 16 Nov 2002 14:52:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAGMqRbB027974 for ; Sat, 16 Nov 2002 14:52:28 -0800 (PST) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA23681 for ; Sat, 16 Nov 2002 15:52:20 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAGMpn6Q046496; Sat, 16 Nov 2002 23:51:50 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAGMpk6U050872; Sat, 16 Nov 2002 23:51:47 +0100 Received: from [9.29.3.174] by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA71428 from ; Sat, 16 Nov 2002 23:51:38 +0100 Message-Id: <3DD6CBE4.3534359F@hursley.ibm.com> Date: Sat, 16 Nov 2002 23:51:16 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Richard Draves Cc: "IPng List (IPng List)" , Jari Arkko , Bob Hinden , Margaret Wasserman , Erik Nordmark , Thomas Narten Subject: Re: draft-ietf-ipv6-default-addr-select-09.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have no problem with this change, and I think it is editorial rather than substantive. Brian Richard Draves wrote: > > Folks, > > As you might know draft-ietf-ipv6-default-addr-select-09.txt passed IESG > review and is with the RFC Editor. While reviewing the references we > noticed that the reference to Mobile IPv6 is probably normative, because > the address selection rules refer to home addresses and care-of > addresses. To break this dependency, we plan to add the following > subsection (this is the only change): > > 3.5. Mobility Addresses > > Some nodes may support mobility using the concepts of a home address > and a care-of address (for example see [5]). Conceptually, a home > address is an IP address assigned to a mobile node and used as the > permanent address of the mobile node. A care-of address is an IP > address associated with a mobile node while visiting a foreign link. > When a mobile node is on its home link, it may have an address that > is simultaneously a home address and a care-of address. > > For the purposes of this document, it is sufficient to know whether > or not an address is designated a home address or care-of address. > Whether or not an address should be designated a home address or > care-of address is outside the scope of this document. > > Please speak up if you object to this change. I know some folks object > to other aspects of draft-ietf-ipv6-default-addr-select-09 but for this > discussion thread please restrict your comments to this specific change. > > Thanks, > Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 12:13:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAHKDUkd011592; Sun, 17 Nov 2002 12:13:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAHKDUHT011591; Sun, 17 Nov 2002 12:13: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAHKDRkd011584 for ; Sun, 17 Nov 2002 12:13:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAHKDaMq022043 for ; Sun, 17 Nov 2002 12:13:36 -0800 (PST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16395 for ; Sun, 17 Nov 2002 13:13:30 -0700 (MST) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 00D59621B4; Sun, 17 Nov 2002 21:13:26 +0100 (CET) Date: Sun, 17 Nov 2002 15:08:11 -0500 From: Harald Tveit Alvestrand To: Richard Draves , Keith Moore Cc: ipng@sunroof.eng.sun.com Subject: RE: use of site-locals as an indication of policy? Message-ID: <201116099.1037545691@localhost> 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 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk do you mean that it's appropriate policy for equipment/application manufacturers to ship products that will only work out of the box if site-locals are configured on the network? I'd like to preserve the ability to run a network without configuring site-locals without too much impact....... Harald --On 15. november 2002 14:35 -0800 Richard Draves wrote: > I think the answer is yes, it is reasonable to use site-locals as an > indication of policy. The kind of examples I have in mind are > > 1) A default configuration for some applications (eg database, file, and > print servers) might be to only accept connections from site-local > addresses. These applications would be running on hosts with both global > and site-local addresses. > > 2) A default configuration for some IP appliances (eg printers) might be > to only configure link-local and site-local addresses. > > Rich > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 17 12:51:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAHKpYkd011823; Sun, 17 Nov 2002 12:51:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAHKpY7L011822; Sun, 17 Nov 2002 12: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAHKpTkd011815 for ; Sun, 17 Nov 2002 12:51:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAHKpcbB024296 for ; Sun, 17 Nov 2002 12:51:38 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25628 for ; Sun, 17 Nov 2002 13:51:29 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Sun, 17 Nov 2002 12:51:29 -0800 Reply-To: From: "Tony Hain" To: Cc: Subject: RE: use of site-locals as an indication of policy? Date: Sun, 17 Nov 2002 15:51:24 -0500 Message-ID: <097201c28e7b$18256260$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211152144.gAFLiil28989@astro.cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAHKpUkd011816 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > ... > One of the assertions that Tony seems to be making is that > SLs can be used to communicate to applications when policy > forbids them from talking > to one another. (Tony, if I'm mistating this, please restate it) I was suggesting that SL is an indication that a filtering policy has been applied to this network. This does not by itself indicate where the boundaries are. > > So for instance if a process resides on a host which only has an SL > address, and it wants to communicate with a peer for which it > only has > a global address, then the process can infer that it is forbidden as > a matter of policy from communicating with that peer. Based on its SL address, it can infer that there is an explicit filter somewhere in the network. That filter may or may not be between it and the application peer. > > Or perhaps if process A lives on a host with both global and > SL addresses, and it has only a SL address for the host on > which process B resides, then A can infer that B is forbidden > from communicating off-site. This is the case that seemed to apply to the referral type apps. If A only knows a SL for B, and a global prefix for C that does not match its own, it can assume that the likelihood of C being able to see B is low. Or at the very least when it fails there is an indication that someone probably wants it to. > > (Offhand I haven't thought of other inferences that could be made - > certainly if both hosts have both SL and global addresses then > you can't assume that the hosts are allowed to connect.) > > Is there a widespread idea that it's reasonable for apps to > make these kind of inferences? > > > > Personally, I don't think either of those inferences are reasonable - > there are too many situations where a host can be temporarily > without a global address (but not forbidden to communicate > externally as a > matter of policy), Lack of an external address means that the external nodes will be unable to communicate with that device from outside the site. Why the node is without a global address is irrelevant to the ability to use it in a referral. > and too many situations where a process > might know some but not all of the addresses at which a > potential peer might be reached (so the lack of knowledge of > a global for that peer doesn't > imply anything about policy). It implies that the ablity to actually connect to it is explicitly impaired. Other than the case of the private network connected behind a globally attached network, I see no reason for permiting SL/global connectivity. If we can get PI prefixes for the private network, we should simply put a hard stop in SL working with anything except another SL. Tony > > Keith > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 17 13:06:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAHL6ekd011877; Sun, 17 Nov 2002 13:06:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAHL6emF011876; Sun, 17 Nov 2002 13:06:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAHL6bkd011869 for ; Sun, 17 Nov 2002 13:06:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAHL6kbB025777 for ; Sun, 17 Nov 2002 13:06:46 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29313 for ; Sun, 17 Nov 2002 14:06:39 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAHL6cw11179; Sun, 17 Nov 2002 23:06:38 +0200 Date: Sun, 17 Nov 2002 23:06:37 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com cc: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt In-Reply-To: <200210311113.GAA12830@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 31 Oct 2002 Internet-Drafts@ietf.org wrote: > Title : Requirements for Plug and Play IPsec for IPv6 > applications > Author(s) : T. Kobayakawa, S. Miyakawa > Filename : draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt > Pages : 5 > Date : 2002-10-30 > > This document describes requirements about how IPsec is supplemented > for IPv6 Plug and Play applications. Comments. Substantial: There is another reason for Internet users to choose IPv6. IPv6 is believed to be equipped with IPsec as default, and many users choose IPv6 because of IPsec. However, IPsec is independent from version numbers of IP, and IPv6 does not have special advantages for IPsec. We have two options to cope with this myth: ==> "no special advantages" is not true. Well, directly, there seem to be no special advantages. But increased address space and e2e addressing make e2e IPSEC much easier -- NAT boxes severely hinder IPSEC usability. However, we should not mandate the existence of this outside server because there are many situations in which such servers are not available, and IP layer authentication and Man-in-the-Middle protection are not important. ==> I don't understand this at all. Please elaborate a bit. I fail to see cases when MITM protection is irrelevant. After the establishment of this security level of IPsec SAs, authentication, authorization, accounting, and Man-in-the-Middle prevention are added on to those SAs. ==> how are these added there? I fail to see how establishing possibly MITM'ed "authenticated" IPSEC SA's helps _any_ with this. ==> You forgot Security Considerations section. I believe using IPSEC when it's known to be possibly wrong is not good -- no security is better than false sense of security. Editorial: ==> many places s/configurations/configuration/ abundant (IPv4 global addresses are not, especially in Asia.) Such peer-to-peer applications often require authentication and secrecy mechanisms, which are provided by IPsec. ==> s/are provided/can be provided/ Many IPv6 applications assume embedded devices without keyboard and display. For embedded devices, maintaining X.509 certificate, such as Certificate Update and Certificate Revocation Handling, is too heavy and often diminishes the usability. ==> reword this, the latter part isn't clearly related to _maintaining_ certificates. but it's not practical to apply to IP communications.) Assuming no ==> s/.)/)./ Just "key-exchange-before-all-the-communication" does not work because it forces delay on all the communications regardless of this kind of IPsec supports. ==> reword the last part, e.g. "support for PnP IPSEC". -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 13:08:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAHL8ikd011909; Sun, 17 Nov 2002 13:08:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAHL8hir011908; Sun, 17 Nov 2002 13:08:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAHL8ekd011901 for ; Sun, 17 Nov 2002 13:08:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAHL8nMq001359 for ; Sun, 17 Nov 2002 13:08:49 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29597 for ; Sun, 17 Nov 2002 14:08:43 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Sun, 17 Nov 2002 13:08:42 -0800 Reply-To: From: "Tony Hain" To: "'Harald Tveit Alvestrand'" , "'Richard Draves'" , "'Keith Moore'" Cc: Subject: RE: use of site-locals as an indication of policy? Date: Sun, 17 Nov 2002 16:08:36 -0500 Message-ID: <097901c28e7d$80d69d40$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <201116099.1037545691@localhost> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAHL8ekd011902 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Harald Tveit Alvestrand wrote: > do you mean that it's appropriate policy for equipment/application > manufacturers to ship products that will only work out of the box if > site-locals are configured on the network? > > I'd like to preserve the ability to run a network without configuring > site-locals without too much impact....... I think the point was that for some applications (like printers), it is unreasonable to assume that everyone (or even anything close to a majority) will want them globally accessible out of the box. At the same time the majority do want them to work locally out of the box. Without explicit configuration, how would the application distinguish global vs. local accessibility if it only had a global prefix to work with? The alternative is that before you can connect the shiny new printer you bought, you have to wait for the network administrator to install the appropriate filter at the border, or you have to wait for the DHCP administrator to add you printer so that it will be allocated an address that is in the range of an existing filter. There is nothing requiring that you run the network with SL. Just that if you choose to do so, there will be some devices and applications that will require less work. Personally if I were building an auto-configuring device that is most often intended for local-use, I would have it configure only the SL if one existed in the RA, but if there was no SL, configure all global prefixes. This would allow you to run without SL, but allow those that run with it to not worry about those devices being reached without explicit effort to change the default. Tony > > Harald > > --On 15. november 2002 14:35 -0800 Richard Draves > > wrote: > > > I think the answer is yes, it is reasonable to use > site-locals as an > > indication of policy. The kind of examples I have in mind are > > > > 1) A default configuration for some applications (eg > database, file, > > and print servers) might be to only accept connections from > site-local > > addresses. These applications would be running on hosts with both > > global and site-local addresses. > > > > 2) A default configuration for some IP appliances (eg > printers) might > > be to only configure link-local and site-local addresses. > > > > Rich > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Sun Nov 17 13:23:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAHLNEkd012171; Sun, 17 Nov 2002 13:23:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAHLNEwp012170; Sun, 17 Nov 2002 13: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAHLNBkd012163 for ; Sun, 17 Nov 2002 13:23:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAHLNKbB027642 for ; Sun, 17 Nov 2002 13:23:20 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03349 for ; Sun, 17 Nov 2002 14:23:14 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAHLNA211338; Sun, 17 Nov 2002 23:23:10 +0200 Date: Sun, 17 Nov 2002 23:23:09 +0200 (EET) From: Pekka Savola To: "Chen, Weijing" cc: "'ipng@sunroof.eng.sun.com'" , Subject: Re: FW: I-D ACTION:draft-allen-lap-ipv6-00.txt In-Reply-To: <905A1C4ABF353F4C8CC16FA9F53DD0D63226BE@trimail2> 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 Comments on lap-ipv6. You seem to make an assumption that it would be ok for routers on the path to just add headers to IPv6 datagrams (like routing header). That is not so. This is a fundamental problem with the proposal. Security for VPN solution you present is weak. There was no text (I think) discussing the possibility that some outsider would forge packets with some VPN header and VPN ID from the Internet, and those would be delivered to the VPN network. The problem is that unless ISP polices this with filters everywhere, when the PE device has no way of knowing whether the packets with the correct VPN ID happened to come from the Internet or some legal VPN site. (Of course, VPN without encryption against the ISP is IMO nonsense anyway but that's what the "competing" MPLS/BGP VPN solution has too.) In 3.1.3, a new feature of IPv6 would be access provider's possibility to ping the subscriber's interface. I fail to see how this could not be done today. On Mon, 14 Oct 2002, Chen, Weijing wrote: > We would like to bring the attention to this ID announcement. This draft > saw the same "connection-oriented" problem laid out by > http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-cl-tunneling-vpn-00.txt > . However, the proposal lay out by > http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt dealt more > than PPVPN. It dealt with broadband Internet access too. We would like to > seek the interest of ipng group, ppvpn group, and other interesting party to > advance this work. Thanks. > > > > -- > Weijing Chen > > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, October 14, 2002 6:25 AM > Cc: ipng@sunroof.eng.sun.com > Subject: I-D ACTION:draft-allen-lap-ipv6-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IPv6 for Large Access Providers > Author(s) : K. Allen, W. Chen > Filename : draft-allen-lap-ipv6-00.txt > Pages : 12 > Date : 2002-10-11 > > This document discusses how Large Access Providers (LAP) could use > IPv6 to solve current technical challenges. In particular, IPv6Æs > large address space and optional header mechanism can be used to > provide scalable and manageable broadband Internet access and > Virtual Private Network (VPN) services. A new optional header to > support forwarding-plane based VPNs is proposed. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.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-allen-lap-ipv6-00.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-allen-lap-ipv6-00.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. > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 17 13:29:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAHLTOkd012237; Sun, 17 Nov 2002 13:29:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAHLTOtN012236; Sun, 17 Nov 2002 13:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAHLTLkd012229 for ; Sun, 17 Nov 2002 13:29:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAHLTUbB028125 for ; Sun, 17 Nov 2002 13:29:30 -0800 (PST) Received: from eikenes.alvestrand.no (nat.alvestrand.no [217.13.28.204]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05783 for ; Sun, 17 Nov 2002 14:29:24 -0700 (MST) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 24FFE621B4; Sun, 17 Nov 2002 22:29:20 +0100 (CET) Date: Sun, 17 Nov 2002 16:17:40 -0500 From: Harald Tveit Alvestrand To: alh-ietf@tndh.net, "'Richard Draves'" , "'Keith Moore'" Cc: ipng@sunroof.eng.sun.com Subject: RE: use of site-locals as an indication of policy? Message-ID: <205285204.1037549860@localhost> In-Reply-To: <097901c28e7d$80d69d40$bd134104@eagleswings> References: <097901c28e7d$80d69d40$bd134104@eagleswings> 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 --On 17. november 2002 16:08 -0500 Tony Hain wrote: > There is nothing requiring that you run the network with SL. Just that > if you choose to do so, there will be some devices and applications that > will require less work. Personally if I were building an > auto-configuring device that is most often intended for local-use, I > would have it configure only the SL if one existed in the RA, but if > there was no SL, configure all global prefixes. This would allow you to > run without SL, but allow those that run with it to not worry about > those devices being reached without explicit effort to change the > default. since I normally print on my office printer through an SSH tunnel running through my VPN to Amsterdam (don't ask me to explain the security guidelines that led me to start doing this, please....), I certainly can see reasons why you would want to allow a printer to be globally accessible...... but I see your point. 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 Sun Nov 17 23:46:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAI7kmkd013314; Sun, 17 Nov 2002 23:46:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAI7kmWt013313; Sun, 17 Nov 2002 23:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAI7kjkd013306 for ; Sun, 17 Nov 2002 23:46:45 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAI7ksbB009140 for ; Sun, 17 Nov 2002 23:46:54 -0800 (PST) Received: from mail.iwavesystems.com (iwave-54-144-ban.iwavesystems.com [203.196.144.54] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA29117 for ; Sun, 17 Nov 2002 23:46:45 -0800 (PST) Received: from iwave120 (ns1.iwave.net [203.196.144.50]) by mail.iwavesystems.com (8.12.4/) with SMTP id gAI7g9x8017551 for ; Mon, 18 Nov 2002 13:12:11 +0530 Message-ID: <007601c28ed7$2338e800$b202a8c0@iwave120> From: "Anurag Uxa" To: Subject: NUD over tunnel Date: Mon, 18 Nov 2002 13:20:11 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01C28F05.38E67130" 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-Virus-Scanned: Message: ok X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.14 (www dot roaringpenguin dot com slash mimedefang) X-Filter-Version: 1.4.5 (mail.iwavesystems.com) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0073_01C28F05.38E67130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All I wanted to know about scenario of "Neighbor Discovery over Tunnels"for = bi directional configured tunnel? In which circumstances router will send NS packect (Required or not )and = wait for Ack to come again in Reachable state? Bcoz ipv4 router should not send any NS packet..... Thanks Anurag Uxa IWave Embedded systems Bangalore ph.6786243/5 extn :205 DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. ------=_NextPart_000_0073_01C28F05.38E67130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All
 

I wanted to know about scenario of = "Neighbor=20 Discovery over Tunnels"for bi directional configured tunnel?

In which circumstances router will send = NS packect=20 (Required or not )and wait for Ack to come again in Reachable = state?

Bcoz ipv4 router should not send any NS=20 packet.....

 

Thanks

 

Anurag Uxa
IWave Embedded=20 systems
Bangalore
ph.6786243/5 extn = :205

DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation.

------=_NextPart_000_0073_01C28F05.38E67130-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 06:49:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIEnxkd014315; Mon, 18 Nov 2002 06:49:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIEnxL4014314; Mon, 18 Nov 2002 06:49:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIEnskd014304 for ; Mon, 18 Nov 2002 06:49:54 -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 gAIEntL01008; Mon, 18 Nov 2002 15:49:56 +0100 (MET) Date: Mon, 18 Nov 2002 15:46:41 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: SUMMARY: RE: Limiting the Use of Site-Local To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <5.1.0.14.2.20021102075349.0a566140@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 > > Posting only as an interested individual: Me to. > - What level of impact, if any, will the widespread > use of site-local addresses have on: > - Applications (current and future) > - Transport Protocols > - Security Protocols > - Network Management Protocols Add mobile-ip to the above list. Having once thought that site-local addresses in sites that have global prefixes was reasonable idea, I did go down the path of trying to figure out what it would take to allow mobile nodes to use site-local addresses. Since mobile nodes typically don't know the "range" of their mobility up front, this seems to lead to a desire to have a mobile node use site-local addresses when in its home site and not have that communication fail when the node moves outside its home site. (If this isn't provided the result would probably be that all mobile nodes will only be configured with global addresses.) An outline of what it takes to do this was in previous versions of the long expired draft-ietf-ipngwg-site-prefixes draft. It seemed like by adding explicit support for this in correspondent nodes, home agents, and mobile nodes it could be made to work. But, just like applying thrust to make pigs fly, it might not be a good idea. At some WG meeting a long time ago there was rough consensus to not have this complexity (which was the right answer in my opinion). But a result of this is that nodes that might be mobile and use mobile ipv6 should not be configured with a site-local address (unless it is somehow known that they will not move outside of their home site). Thus any claimed benefits of site local addresses don't apply to mobile nodes AFAI understand. For instance, the claimed security benefits when configuring nodes to only accept packets from site-local addresses would cause a problem for mobile nodes, 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 Nov 18 07:18:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIFINkd014598; Mon, 18 Nov 2002 07:18:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIFINxP014597; Mon, 18 Nov 2002 07:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIFIJkd014590 for ; Mon, 18 Nov 2002 07:18:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIFISbB008170 for ; Mon, 18 Nov 2002 07:18:28 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07429; Mon, 18 Nov 2002 08:18:22 -0700 (MST) 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 HAA10602; Mon, 18 Nov 2002 07:18:21 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAIFILe17830; Mon, 18 Nov 2002 07:18:21 -0800 X-mProtect: <200211181518> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.101, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQfmuHR; Mon, 18 Nov 2002 07:18:18 PST Message-ID: <3DD90477.8584F0A7@iprg.nokia.com> Date: Mon, 18 Nov 2002 07:17:11 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: SUMMARY: RE: Limiting the Use of Site-Local References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Erik, I have a minor comment on your note, without taking away from its main thrust. Erik Nordmark wrote: > Since mobile nodes typically don't know the "range" of their mobility > up front, this seems to lead to a desire to have a mobile node use site-local > addresses when in its home site and not have that communication fail when > the node moves outside its home site. (If this isn't provided the result > would probably be that all mobile nodes will only be configured with global > addresses.) It should be possible for a mobile node to use a site-local prefix as long as it only ever roams within the site. This seems to go along with the proposal that site-local prefixes should only be used in domains that are disconnected from the Internet. If a mobile node has a global home address, it should use that global address all the time, I reckon. Otherwise, if it only has a site-local address, then by definition it is only addressable at that site. Users of such equipment should be made aware of that limitation. 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 Nov 18 07:17:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIFHqkd014580; Mon, 18 Nov 2002 07:17:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIFHqMD014579; Mon, 18 Nov 2002 07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIFHkkd014572 for ; Mon, 18 Nov 2002 07:17:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIFHqbB008098 for ; Mon, 18 Nov 2002 07:17:52 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00063 for ; Mon, 18 Nov 2002 08:17:46 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAIFHal18400; Mon, 18 Nov 2002 10:17:38 -0500 (EST) Message-Id: <200211181517.gAIFHal18400@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com Subject: Re: use of site-locals as an indication of policy? In-reply-to: (Your message of "Sun, 17 Nov 2002 15:51:24 EST.") <097201c28e7b$18256260$bd134104@eagleswings> Date: Mon, 18 Nov 2002 10:17:36 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I was suggesting that SL is an indication that a filtering policy has > been applied to this network. seems like a *huge* stretch - several of the ideas for using SL have nothing to do with filtering. also, SL strikes me as an extremely poor mechanism for communicating filtering policy. in general an application must assume that there is a filtering policy may be in place regardless of whether or not it sees SL addresses. after all, filtering that can affect an application can exist anywhere in the network, and SL could at best provide a crude indication of filtering on the local network. the way you determine whether filtering is imposed is by trying to communicate and having that attempt fail due to an ICMP 'communication prohibited' message. so no, I don't think this flies at all. 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 Nov 18 07:19:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIFJBkd014608; Mon, 18 Nov 2002 07:19:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIFJAxv014607; Mon, 18 Nov 2002 07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIFJ6kd014600 for ; Mon, 18 Nov 2002 07:19:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIFJFMq021719 for ; Mon, 18 Nov 2002 07:19:15 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17565 for ; Mon, 18 Nov 2002 08:19:09 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAIFJ3l18436; Mon, 18 Nov 2002 10:19:03 -0500 (EST) Message-Id: <200211181519.gAIFJ3l18436@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Harald Tveit Alvestrand'" , "'Richard Draves'" , "'Keith Moore'" , ipng@sunroof.eng.sun.com Subject: Re: use of site-locals as an indication of policy? In-reply-to: (Your message of "Sun, 17 Nov 2002 16:08:36 EST.") <097901c28e7d$80d69d40$bd134104@eagleswings> X-SUBJECT-MSG-FROM: "Tony Hain" Date: Mon, 18 Nov 2002 10:19:03 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk to me it seems completely unreasonable for any device to make any assuumptions about the trust level placed in "site-local" addresses. this should be a MUST NOT. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 07:42:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIFgbkd015277; Mon, 18 Nov 2002 07:42:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIFgbsB015276; Mon, 18 Nov 2002 07:42:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIFgXkd015269 for ; Mon, 18 Nov 2002 07:42:33 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAIFgTL07580; Mon, 18 Nov 2002 16:42:30 +0100 (MET) Date: Mon, 18 Nov 2002 16:39:20 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: SUMMARY: RE: Limiting the Use of Site-Local To: Charlie Perkins Cc: Erik Nordmark , Margaret Wasserman , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3DD90477.8584F0A7@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 > It should be possible for a mobile node to use a site-local prefix as long > as it only ever roams within the site. This seems to go along with the > proposal that site-local prefixes should only be used in domains that are > disconnected from the Internet. If a mobile node has a global home address, > it should use that global address all the time, I reckon. Otherwise, if it > only has a site-local address, then by definition it is only addressable at > that site. Users of such equipment should be made aware of that limitation. Agreed when either site-locals or global addresses are used in the site. But unless site-locals are restricted there is a case when both global and site-locals are used at the same time and then presumably it would be possible to configure a mobile node with both a global and site-local address. In that case it is less clear what makes sense I think. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 09:08:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIH8skd016003; Mon, 18 Nov 2002 09:08:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIH8sKQ016002; Mon, 18 Nov 2002 09:08: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIH8okd015993 for ; Mon, 18 Nov 2002 09:08:50 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIH8xbB003892 for ; Mon, 18 Nov 2002 09:08:59 -0800 (PST) Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00602; Mon, 18 Nov 2002 10:08:53 -0700 (MST) Received: from dhcp-204-42-68-213.ietf55.ops.ietf.org ([204.42.68.213] helo=eng.monash.edu.au) by srv0.ops.ietf.org with esmtp (Exim 4.10) id 18DpOG-000LV3-00; Mon, 18 Nov 2002 17:08:52 +0000 Message-ID: <3DD9AB19.74B0115B@eng.monash.edu.au> Date: Tue, 19 Nov 2002 03:08:09 +0000 From: Greg Daley X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Charlie Perkins , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: SUMMARY: RE: Limiting the Use of Site-Local References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, there's a set of cases where the MN uses Localized mobility management such as HMIPv6 and can use only site locals within a set of access networks. The MN is reachable through a regional care-of-address which is globally scoped. In this case, communication within the access network uses the site-local address for communication, and global communication relies upon tunnelling to the HMIPv6 LMM Agent. Similarly, site-locals from the home-network are tunnelled over the global Internet. Simple classification based on received/transmit interface (virtual tunnel or phy interface) could be used to distinguish between site-local zones. As far as normal non LMM managed MIPv6 goes, it's pretty clear that using site-locals for a care-of-address is only valid if you're not connected to the Internet. Home network site-locals once again are tunnelled, and may be distinguished from more mundane traffic. I'm not sure if this is complete, but I don't see it's that problematic. Greg Daley Erik Nordmark wrote: > > > It should be possible for a mobile node to use a site-local prefix as long > > as it only ever roams within the site. This seems to go along with the > > proposal that site-local prefixes should only be used in domains that are > > disconnected from the Internet. If a mobile node has a global home address, > > it should use that global address all the time, I reckon. Otherwise, if it > > only has a site-local address, then by definition it is only addressable at > > that site. Users of such equipment should be made aware of that limitation. > > Agreed when either site-locals or global addresses are used in the site. > > But unless site-locals are restricted there is a case when both global > and site-locals are used at the same time and then presumably it would be > possible to configure a mobile node with both a global and site-local > address. In that case it is less clear what makes sense I think. > > Erik > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 10:05:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAII5Mkd016689; Mon, 18 Nov 2002 10:05:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAII5MlQ016688; Mon, 18 Nov 2002 10:05:22 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAII5Ikd016681 for ; Mon, 18 Nov 2002 10:05:18 -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 gAII5EL24137; Mon, 18 Nov 2002 19:05:15 +0100 (MET) Date: Mon, 18 Nov 2002 19:02:05 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: SUMMARY: RE: Limiting the Use of Site-Local To: Greg Daley Cc: Erik Nordmark , Charlie Perkins , Margaret Wasserman , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3DD9AB19.74B0115B@eng.monash.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > there's a set of cases where the MN uses Localized mobility management > such as HMIPv6 and can use only site locals within a set of access > networks. > I'm not sure if this is complete, but I don't see it's that > problematic. Which problem are you trying to solve here to which the solution is to use site local addresses? I don't see why using site local addresses in the context of local mobility has any benefits, but perhaps I'm missing something. The cases when site-local addresses don't offer any benefits and they don't cause any additional complexity or problems are not interesting to discuss since it doesn't help folks understand the tradeoffs between different levels of support for site-locals. 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 Nov 18 10:30:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIIUdkd016805; Mon, 18 Nov 2002 10:30:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIIUd9B016804; Mon, 18 Nov 2002 10:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIIUZkd016797 for ; Mon, 18 Nov 2002 10:30:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIIUiMq009779 for ; Mon, 18 Nov 2002 10:30:45 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23782 for ; Mon, 18 Nov 2002 11:30:38 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 18 Nov 2002 10:30:37 -0800 Reply-To: From: "Tony Hain" To: Cc: Subject: RE: use of site-locals as an indication of policy? Date: Mon, 18 Nov 2002 13:30:29 -0500 Message-ID: <09ab01c28f30$94af6500$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211181517.gAIFHal18400@astro.cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAIIUakd016798 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > I was suggesting that SL is an indication that a filtering > policy has > > been applied to this network. > > seems like a *huge* stretch - several of the ideas for using > SL have nothing to do with filtering. also, SL strikes me as > an extremely poor mechanism for communicating filtering policy. This is demonstrably untrue. SL is not routable between autonomous administrations without explicit coordination to remove ambiguity. With coordination, the regions are no longer completely autonomous, and since there is no ambiguity, applications have no problems using them. Your concern about applications having to work across SL boundaries is fundamentally flawed, because routing will not support it without nat. This is not an argument for nat, and again the only way to avoid nat is to allow simultaneous use of multiple scopes. > > in general an application must assume that there is a > filtering policy may be in place regardless of whether or not > it sees SL addresses. after all, filtering that can affect an > application can exist anywhere in the network, and SL could > at best provide a crude indication of > filtering on the local network. > > the way you determine whether filtering is imposed is by trying to > communicate and having that attempt fail due to an ICMP > 'communication prohibited' message. > > so no, I don't think this flies at all. This perspective assumes all control/feedback is based on outbound traffic. Think 'inbound traffic'. 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 Nov 18 10:31:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIIV6kd016815; Mon, 18 Nov 2002 10:31:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIIV5bd016814; Mon, 18 Nov 2002 10:31: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIIV0kd016807 for ; Mon, 18 Nov 2002 10:31:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIIV9Mq009918 for ; Mon, 18 Nov 2002 10:31:09 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23997 for ; Mon, 18 Nov 2002 11:31:03 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 18 Nov 2002 10:30:51 -0800 Reply-To: From: "Tony Hain" To: Cc: "'Harald Tveit Alvestrand'" , "'Richard Draves'" , Subject: RE: use of site-locals as an indication of policy? Date: Mon, 18 Nov 2002 13:30:29 -0500 Message-ID: <09ac01c28f30$a3aad800$bd134104@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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200211181519.gAIFJ3l18436@astro.cs.utk.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kieth Moore wrote: > to me it seems completely unreasonable for any device to make > any assuumptions about the trust level placed in "site-local" > addresses. this should be a MUST NOT. Why do you keep insisting that lack of public accessability implies anything about trust? 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 Nov 18 10:31:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIIVGkd016828; Mon, 18 Nov 2002 10:31:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIIVGB0016827; Mon, 18 Nov 2002 10:31: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIIV9kd016820 for ; Mon, 18 Nov 2002 10:31:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIIVIMq009958 for ; Mon, 18 Nov 2002 10:31:18 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net [4.65.20.139]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24109 for ; Mon, 18 Nov 2002 11:31:11 -0700 (MST) Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 18 Nov 2002 10:31:08 -0800 Reply-To: From: "Tony Hain" To: "'Erik Nordmark'" , "'Charlie Perkins'" Cc: "'Margaret Wasserman'" , Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local Date: Mon, 18 Nov 2002 13:30:29 -0500 Message-ID: <09b101c28f30$a7953190$bd134104@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.3416 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 gAIIV9kd016821 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > > It should be possible for a mobile node to use a site-local > prefix as > > long as it only ever roams within the site. This seems to go along > > with the proposal that site-local prefixes should only be used in > > domains that are disconnected from the Internet. If a > mobile node has > > a global home address, it should use that global address > all the time, > > I reckon. Otherwise, if it only has a site-local address, then by > > definition it is only addressable at that site. Users of such > > equipment should be made aware of that limitation. > > Agreed when either site-locals or global addresses are used > in the site. > > But unless site-locals are restricted there is a case when > both global and site-locals are used at the same time and > then presumably it would be possible to configure a mobile > node with both a global and site-local address. In that case > it is less clear what makes sense I think. In terms of packet format, and registration with the HA, I see no reason for SL to create any confusion. It is just one of the addresses that could map to the current care-of address. The point the might be confusing is the ability of the mobile node to detect that it is no longer in the site. This should not be particularly difficult in the case where the RA no longer contains a SL or global prefix for the HA, because this is a good indication that the node is 'no longer in Kansas'. The problem case is where the RA contains only SL. Is this the home site where the global prefix went away or not? Since there is no global prefix for the care-of, it would be hard to establish a mip-v6 ha/coa mapping. This does not mean SL fails in the case of the mobile node, only that nodes that move between SL-enabled networks might need to look for other hints to decide when they are no longer 'home'. 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 Nov 18 11:33:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIJX3kd017475; Mon, 18 Nov 2002 11:33:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIJX3KU017473; Mon, 18 Nov 2002 11:33:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIJWwkd017466 for ; Mon, 18 Nov 2002 11:32:59 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAIJX2L13237; Mon, 18 Nov 2002 20:33:03 +0100 (MET) Date: Mon, 18 Nov 2002 20:29:50 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Proposal for site-local clean-up To: alh-ietf@tndh.net Cc: "'Keith Moore'" , "'Brian Zill'" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <07d601c28b33$9296bb20$bd134104@eagleswings> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It doesn't matter how many times you write this, you can not make it > become true. Brian keeps pointing out the simple case of an > intermittently connected network getting a different prefix on each > connect, but you keep ignoring it. STABLE ADDRESS SPACE IS A MAJOR > APPLICATION REASON TO HAVE SL. Being the probable guilty party for introducing this thought back in draft-*-site-prefixes-00.txt I can offer a slightly expanded perspective. I don't think stable addresses per se is the key thing - it is the robustness of the communication that is important. This robustness has at least two factors that are relevant in this discussion: the stability of the addresses, and the leakage of non-global scope addresses. I think the question is how to weigh those together. In terms of the stability of the addresses one has to take into account both stability as it relates to local communication and stability for global communication. If you assume that the value/importance of local communication is much higher than the value/importance of global communication then site-locals make sense to explore. (FWIW that was my assumption way back). Such an assumption might make sense we say that a site is an administrative concept (such as a company), but it makes less sense if a site is a geographic concept and as I understand the original thoughts a site was intended to be a geographic concept like a building or a campus. In any case, for a home user I suspect that the value/importance of local communication would typically be less than the value/importance of global communication. Thus the ISP offering a service with unstable global addresses I don't think it would be that satisfactory for the peer-to-peer communication that we wish to enable with IPv6, even if there are stable site-local addresses so that the user can communicate inside their home without a glitch. Additionally, folks might want to use mobile-ipv6 and still get a quality service. Since MIPv6 MNs are likely to use global addresses (presumably they wish to be capable to move outside the home/site) their robust communication require reasonably stable global addresses. Finally, an enemy to robustness is complexity. Site-locals add complexity in many places; applications, two-faced DNS configuration, etc. So let's not loose sight of the fact that the goal is a robust network. 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 Nov 18 11:37:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIJbmkd017561; Mon, 18 Nov 2002 11:37:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIJbiwp017560; Mon, 18 Nov 2002 11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIJbfkd017550 for ; Mon, 18 Nov 2002 11:37:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIJboMq001289 for ; Mon, 18 Nov 2002 11:37:50 -0800 (PST) Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08502; Mon, 18 Nov 2002 12:37:43 -0700 (MST) Received: from dhcp-204-42-68-213.ietf55.ops.ietf.org ([204.42.68.213] helo=eng.monash.edu.au) by srv0.ops.ietf.org with esmtp (Exim 4.10) id 18DriI-000N6G-00; Mon, 18 Nov 2002 19:37:42 +0000 Message-ID: <3DD9CDFB.6ADE04D@eng.monash.edu.au> Date: Tue, 19 Nov 2002 05:36:59 +0000 From: Greg Daley X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Charlie Perkins , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: SUMMARY: RE: Limiting the Use of Site-Local References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, Mobileip and NEMO scenarios may benefit from using only site locals, if global addresses in the access networks are unavailable or invalid/off-topology. In this case, e-to-e global connectivity is available through the mobility management agent, which provides a global address or addresses at the edge of the local mobility domain. It can also be used to enforce localized management policy. (all packets are reverse tunnelled to the mobility management agent). Still, these may not be sufficiently good reasons to place these ideas into discussion. I didn't intend to cloud the waters, but I can't see many other uses for site-local in the mipv6 access network. Greg Erik Nordmark wrote: > > > there's a set of cases where the MN uses Localized mobility management > > such as HMIPv6 and can use only site locals within a set of access > > networks. > > > I'm not sure if this is complete, but I don't see it's that > > problematic. > > Which problem are you trying to solve here to which the solution > is to use site local addresses? > > I don't see why using site local addresses in the context of local mobility > has any benefits, but perhaps I'm missing something. > > The cases when site-local addresses don't offer any benefits and they > don't cause any additional complexity or problems are not interesting to > discuss since it doesn't help folks understand the tradeoffs between > different levels of support for site-locals. > > 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 Nov 18 11:59:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIJx6kd017853; Mon, 18 Nov 2002 11:59:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIJx6o6017852; Mon, 18 Nov 2002 11:59:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIJx1kd017845 for ; Mon, 18 Nov 2002 11:59:02 -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 gAIJx3L24038; Mon, 18 Nov 2002 20:59:03 +0100 (MET) Date: Mon, 18 Nov 2002 20:55:54 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: SUMMARY: RE: Limiting the Use of Site-Local To: alh-ietf@tndh.net Cc: "'Erik Nordmark'" , "'Charlie Perkins'" , "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <09b101c28f30$a7953190$bd134104@eagleswings> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In terms of packet format, and registration with the HA, I see no reason > for SL to create any confusion. It is just one of the addresses that > could map to the current care-of address. The point the might be > confusing is the ability of the mobile node to detect that it is no > longer in the site. This should not be particularly difficult in the > case where the RA no longer contains a SL or global prefix for the HA, > because this is a good indication that the node is 'no longer in > Kansas'. What prefix length are you advocating to use when comparing? There is no reliably way a MN can know what global prefixes (with lengths) are used in its site. But even if you solve that, you need think think about Route Optimization issues when the CN, HA, and MN can be in any set of sites. > The problem case is where the RA contains only SL. Is this the > home site where the global prefix went away or not? Since there is no > global prefix for the care-of, it would be hard to establish a mip-v6 > ha/coa mapping. This does not mean SL fails in the case of the mobile > node, only that nodes that move between SL-enabled networks might need > to look for other hints to decide when they are no longer 'home'. That is a problem I hadn't thought about. Seems like we are finding new problems in this space ... 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 Nov 18 13:13:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAILDakd019236; Mon, 18 Nov 2002 13:13:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAILDZJG019235; Mon, 18 Nov 2002 13:13:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAILDWkd019228 for ; Mon, 18 Nov 2002 13:13:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAILDfMq004404 for ; Mon, 18 Nov 2002 13:13:41 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00545 for ; Mon, 18 Nov 2002 14:13:35 -0700 (MST) 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 NAA27637; Mon, 18 Nov 2002 13:13:30 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAILDUO13706; Mon, 18 Nov 2002 13:13:30 -0800 X-mProtect: <200211182113> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (204.42.71.253, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdzexrAA; Mon, 18 Nov 2002 13:13:25 PST Message-Id: <4.3.2.7.2.20021118130752.03e14a08@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Nov 2002 13:12:58 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Proposed IPv6 W.G. Charter Update Cc: Margaret Wasserman Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_105515833==_" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=====================_105515833==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Attached is a proposed update to the IPv6 working group charter. This will be discussed at the IPv6 session tonight at IETF55 and on the mailing list. Please comment on the list and at tonights session. Bob Hinden and Margaret Wasserman IPv6 chairs --=====================_105515833==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="ipv6-wg-charter-07.txt" Internet Protocol Version 6 (IPv6) Working Group Charter -- DRAFT Chairs: Bob Hinden Margaret Wasserman Chair Emeritus: Steve Deering Document Editor: Bob Hinden Description of the Working Group: The IPv6 working group is responsible for the specification and standardization of the Internet Protocol version 6 (IPv6). IPv6 provides a much larger global addresses space than it predecessor IPv4. This enables global end-to-end communication and restores valuable properties of the IP architecture that have been lost in the IPv4 Internet. The core IPv6 standards are widely implemented and are in the early stages of global deployment. The IPv6 working group was originally chartered by the IESG as the IP Next Generation (IPng) working group to implement the recommendations of the IPng Area Directors as outlined at the July 1994 IETF meeting and in "The Recommendation for the IP Next Generation Protocol," RFC1752, January 1995. The primary focus of the IPv6 w.g. is to complete the standardization of the IPv6 protocols. The working group's responsibilities are: - Complete work on the IPv6 working group documents as described below. - Reviewing and updating IPv6 specifications based on implementation and deployment experience, and advancing them on the standardization track as appropriate. The IPv6 working group's standardization responsibilities are divided into two areas: Urgent for Deployment, and Completing Current Work. Priority will be given to the first area. The work items in each priority area are as follows: Urgent For Deployment - Complete work on DNS Resolver Address Auto-configuration and publish. - Complete Prefix Delegation requirements and publish. Related work is: o Work with DHCPv6 working group to write DHCPv6 option for IPv6 prefix delegation. o Develop Proxy Router Advertisement solution for prefix delegation and publish. This enable a simple site border router to re-advertise downstream a prefix it hears on it's upstream link. - Complete revision of IPv6 MIBs (combined IPv4/IPv6 versions) and publish. Current Work - Revise Aggregatable Unicast Addresses (RFC2374) to remove TLA/NLA/SLA terminology. - Revise Basic Sockets Extensions (RFC2553) and publish. - Revise Advanced Sockets API (RFC2292) and publish. - Complete Default Router Preferences, More-Specific Routes, and Load Sharing and publish. - Update to ICMPv6 (RFC2463) and publish. - Complete Node Information Queries and publish. - Update Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) and publish. - Update Privacy Extensions for Stateless Autoconfiguration document (RFC3041) and publish. - Complete work on IPv6 Node Requirements and publish. - Complete work on Flow Label and publish. - Complete work on Scoped Addressing Architecture and publish. - Update IPv6 over PPP (RFC2023) and publish (may be done in PPP Extension w.g.). - Review Point-to-point link support in IPv6 and decide if any IPv6 specifications need to be updated. All new work items not listed above require the approval of the working group and IESG before they will be taken on by the working group. Goals & Milestones Nov 02 Submit DNS Resolver Address Auto-configuration draft to IESG for Proposed Standard Nov 02 Submit Prefix Delegation requirements and submit to IESG for Informational Dec 02 Submit update to ICMPv6 (RFC2463) to be republished at Draft Standard. Mar 03 Resubmit Node Information Queries to IESG for Proposed Standard. Jan 03 Submit DHCPv6 option for IPv6 prefix delegation to the IESG for Proposed standard. Note this milestone may be done by DHC working group. Jan 03 Draft on Proxy RA solution Jan 03 Submit Flow Label specification to IESG for Proposed Standard. Mar 03 Submit Proxy RA draft and submit to IESG for Proposed Standard. Mar 03 Submit revision of IPv6 MIBs (combined IPv4/IPv6 versions) to IESG for Proposed Standard. Mar 03 Revise Aggregatable Unicast Addresses (RFC2374) to remove TLA/NLA/SLA terminology. Apr 03 Submit IPv6 Node Requirements to IESG for Informational. Jun 03 Submit Router Preferences, More-Specific Routes, and Load Sharing to IESG for Proposed Standard Jun 03 Submit updates to Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) to be republished at Draft Standard. Jun 03 Submit Update to Privacy Extensions for Stateless Autoconfiguration document (RFC3041) to the IESG for Draft Standard. Aug 03 Submit IPv6 Scoped Addressing Architecture to IESG for Proposed Standard Aug 03 Submit update to IPv6 over PPP (RFC2023) to IESG for Draft Standard. --=====================_105515833==_-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 13:26:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAILQXkd019533; Mon, 18 Nov 2002 13:26:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAILQXZH019532; Mon, 18 Nov 2002 13:26:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAILQUkd019525 for ; Mon, 18 Nov 2002 13:26:30 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAILQcbB021481 for ; Mon, 18 Nov 2002 13:26:39 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04511 for ; Mon, 18 Nov 2002 14:26:33 -0700 (MST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAILQ1O27300 for ; Mon, 18 Nov 2002 23:26:01 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 18 Nov 2002 23:26:31 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 23:26:31 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 18 Nov 2002 23:26:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Proposed IPv6 W.G. Charter Update Date: Mon, 18 Nov 2002 23:26:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed IPv6 W.G. Charter Update Thread-Index: AcKPR+l8mwnJJ19CRZWfD6Qr6gjC9gAARLkw To: Cc: , X-OriginalArrivalTime: 18 Nov 2002 21:26:31.0156 (UTC) FILETIME=[2981EB40:01C28F49] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAILQUkd019526 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bob, > Attached is a proposed update to the IPv6 working group > charter. This will > be discussed at the IPv6 session tonight at IETF55 and on the > mailing list. >From the charter: Apr 03 Submit IPv6 Node Requirements to IESG for Informational. The Host Requirements document is standards track, so I guess the IPv6 Note Requirements should be standards track. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 13:55:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAILtbkd020175; Mon, 18 Nov 2002 13:55:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAILtb7x020174; Mon, 18 Nov 2002 13:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAILtTkd020159; Mon, 18 Nov 2002 13:55:29 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAILtcMq017895; Mon, 18 Nov 2002 13:55:38 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23399; Mon, 18 Nov 2002 14:55:33 -0700 (MST) 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 NAA29746; Mon, 18 Nov 2002 13:55:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAILtWO01137; Mon, 18 Nov 2002 13:55:32 -0800 X-mProtect: <200211182155> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpYd2DP; Mon, 18 Nov 2002 13:55:30 PST Message-ID: <3DD961D2.77D7DE8B@iprg.nokia.com> Date: Mon, 18 Nov 2002 13:55:30 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: MIPv6 Home Agent at IETF 55 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, There is a Mobile IPv6 Home Agent available at IETF 55. Those who want to experience the true mobile Internet, please see the following URL for details http://srv0.ietf55.ops.ietf.org/ietf55/NetworkTerminal#MIP6 Vijay (on behalf of Nokia Research, Mt. View) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 14:06:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIM6Skd020848; Mon, 18 Nov 2002 14:06:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIM6SHc020847; Mon, 18 Nov 2002 14:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIM6Okd020837 for ; Mon, 18 Nov 2002 14:06:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIM6WbB003706 for ; Mon, 18 Nov 2002 14:06:33 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00539 for ; Mon, 18 Nov 2002 15:06:27 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAIM6Gl22031; Mon, 18 Nov 2002 17:06:20 -0500 (EST) Message-Id: <200211182206.gAIM6Gl22031@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com Subject: Re: use of site-locals as an indication of policy? In-reply-to: (Your message of "Mon, 18 Nov 2002 13:30:29 EST.") <09ab01c28f30$94af6500$bd134104@eagleswings> Date: Mon, 18 Nov 2002 17:06:16 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > I was suggesting that SL is an indication that a filtering > > policy has > > > been applied to this network. > > > > seems like a *huge* stretch - several of the ideas for using > > SL have nothing to do with filtering. also, SL strikes me as > > an extremely poor mechanism for communicating filtering policy. > > This is demonstrably untrue. SL is not routable between autonomous > administrations without explicit coordination to remove ambiguity. so what? the app cannot make ANY reasonable assumptions about the intent of the site based merely on the fact that it gets an SL address. it cannot reasonably assume that SL addresses are more stable, because intrasite renumbering may be more common than intersite renumbering. it cannot assume that SL addresses have narrower scope, because it might not actually be connected to the global internet even if it has a global prefix. it cannot assume that SL addresses are trustworthy, because the distribution of threats varies from one site to another and internal threats are often more dangerous than external threats. all of your arguments about security benefits of SLs are ridiculous and entirely without merit. 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 Nov 18 14:07:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIM7Ikd020909; Mon, 18 Nov 2002 14:07:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIM7HcS020908; Mon, 18 Nov 2002 14:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIM7Bkd020895 for ; Mon, 18 Nov 2002 14:07:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIM7FbB003938 for ; Mon, 18 Nov 2002 14:07:16 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA03263 for ; Mon, 18 Nov 2002 15:07:05 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAIM6rl22046; Mon, 18 Nov 2002 17:06:53 -0500 (EST) Message-Id: <200211182206.gAIM6rl22046@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: moore@cs.utk.edu, "'Harald Tveit Alvestrand'" , "'Richard Draves'" , ipng@sunroof.eng.sun.com Subject: Re: use of site-locals as an indication of policy? In-reply-to: (Your message of "Mon, 18 Nov 2002 13:30:29 EST.") <09ac01c28f30$a3aad800$bd134104@eagleswings> X-SUBJECT-MSG-FROM: "Tony Hain" Date: Mon, 18 Nov 2002 17:06:53 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Why do you keep insisting that lack of public accessability implies > anything about trust? you are the one making such assertions. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 14:09:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIM96kd021060; Mon, 18 Nov 2002 14:09:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIM95Uo021057; Mon, 18 Nov 2002 14:09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIM91kd021049 for ; Mon, 18 Nov 2002 14:09:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIM90bB004637 for ; Mon, 18 Nov 2002 14:09:00 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04300 for ; Mon, 18 Nov 2002 15:08:54 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAIM8el22165; Mon, 18 Nov 2002 17:08:40 -0500 (EST) Message-Id: <200211182208.gAIM8el22165@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: alh-ietf@tndh.net, "'Keith Moore'" , "'Brian Zill'" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Mon, 18 Nov 2002 20:29:50 +0100.") X-SUBJECT-MSG-FROM: Erik Nordmark Date: Mon, 18 Nov 2002 17:08:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So let's not loose sight of the fact that the goal is a robust network. well said. and offhand I don't see any reason to assume that SL addresses are more stable/robust than globals. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 14:50:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIMomkd021716; Mon, 18 Nov 2002 14:50:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAIMomEN021715; Mon, 18 Nov 2002 14:50: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIMoikd021708 for ; Mon, 18 Nov 2002 14:50:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAIMorbB019114 for ; Mon, 18 Nov 2002 14:50:53 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25481 for ; Mon, 18 Nov 2002 15:50:47 -0700 (MST) Received: from localhost ([2001:240:5ff:0:5088:502b:97ad:aff2]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id gAIMocd82208; Tue, 19 Nov 2002 07:50:39 +0900 (JST) Date: Tue, 19 Nov 2002 07:50:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: narten@us.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: Resend: Re: rfc2553bis-07 to rfc2553bis-08 changes References: <200211051903.gA5J3wx0001145948@anw.zk3.dec.com> <200211061844.gA6Iina17496@rotala.raleigh.ibm.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Tue_Nov_19_07:50:41_2002-1" X-Dispatcher: imput version 20000228(IM140) Lines: 151 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Tue_Nov_19_07:50:41_2002-1 Content-Type: text/plain; charset=US-ASCII Unless I've missed something, I've not received any responses to the attached message. I interpreted the silence as a sign that there is no need to update 2292bis wrt the issues in this thread. Otherwise, please let me know. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Tue_Nov_19_07:50:41_2002-1 Content-Type: message/rfc822 Delivered-To: jinmei@kame.net X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Fri, 08 Nov 2002 20:51:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes In-Reply-To: <200211061844.gA6Iina17496@rotala.raleigh.ibm.com> References: <200211051903.gA5J3wx0001145948@anw.zk3.dec.com> <200211061844.gA6Iina17496@rotala.raleigh.ibm.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 98 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-Spam-Status: No, hits=-9.0 required=5.0 tests=AWL,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,X_AUTH_WARNING version=2.41 X-Spam-Level: >>>>> On Wed, 06 Nov 2002 13:44:49 -0500, >>>>> Thomas Narten said: > With regards to the basic API: > - Will we want the basic API to ever allow a way to specify the > Traffic Class? If so, will it be better to define a new extension or > to overload the Flow Label? > - Should we point out that some previous versions of the basic API > copied both traffic class and flow label info into packets and that > this is now beleived to be wrong and should be fixed? > I'm OK with either saying setting the Traffic Class through the basic > API won't be done in the future, or saying it can be added but in a > way that is completely backwards compatable and will work smoothly > with 2292bis (assuming we need two ways of setting the bits). I personally prefer to deprecate the access to Traffic Class by the sin6_flowinfo field (i.e. by the basic API), because - it (of course) makes the (future) API simple. - as far as I know, there should be very few (or even no) applications that rely on the feature. so the backward compatibility issue should be not so serious. I know opinions on the compatibility often varies, and I'm open to others' opinions. > Then there is the Advanced API. Again, from Bill: > Bill Fenner writes: >> I am still concerned about the interaction between 2292bis's IPV6_TCLASS >> and these implementations, but perhaps we should let 2553bis go with the >> "not currently specified" wording and make the interaction clear in >> 2292bis? (Has the WG as a whole had a chance to see the suggesiton of >> leaving sin6_flowinfo simply unspecified?) > 2292 doesn't address the flow label. But it does have a way of setting > the Traffic Class. But it doesn't mention how it interacts with > Traffic Class settings via the (old) basic APIs. If the intention is > that the old ways are invalid, and that one only sets traffic class > through the advanced API, I think the current approach is fine. Is > that what folks are thinking here? Excuse me, what do you mean by "the current approach"? Do you mean that "2292bis has a way of setting the traffic class but it doesn't mention the interaction with the (old) basic API"? If so, and assuming we agree on deprecating this part of the basic API, I agree. However, if our consensus is that some backward compatibility should be provided, I guess 2292bis needs to talk about the interaction. > Finally, 2292bis seems to assume the Traffic Class is 8 bits in > size. It's not any more. It's 6 bits, with the ECN bits explicitly a > separate field. So perhaps 2292bis should be updated to reflect the > new size and have separate way of setting the ECN bits? Or at least, > the text should make it clear how one sets one and not the other, etc. (this was discussed before at least partly, but) I believe 2292bis clearly separates the notion of (6-bit) traffic class and 2-bit ECN. For example, section 6.5 contains the following sentences: Returning the received traffic class is useful for programs such as a diffserv debugging tool and for user level ECN (explicit congestion notification) implementation. An example is an implementation of ECN in the kernel, setting 2 bits of the traffic class value. The confusing part would be wording such as "traffic class" (assuming 8 bits) or the socket option name IPV6_TCLASS. In this sense, the comment for the ip6_un1_flow field of the ip6_hdr structure would also be confusing: uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC, 20 bits flow-ID */ As I responded before, I personally think the current wording is okay. However, if there's a strong demand to clarify this much more, I'd propose to add a note like this: [RFC-3260] separates an 8-bit field of the IPv6 header, which was originally called a single "traffic class" field, into a 6-bit DS field and a 2-bit ECN field. However, since this API only provides a single way to get access to the whole 8 bits, the previous terminology "traffic class" will be used to specify the whole bits within this document. Does this make sense? 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 -------------------------------------------------------------------- --Multipart_Tue_Nov_19_07:50:41_2002-1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 16:23:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ0NAkd029043; Mon, 18 Nov 2002 16:23:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ0NAib029042; Mon, 18 Nov 2002 16:23: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ0N7kd029035 for ; Mon, 18 Nov 2002 16:23:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ0NFMq010435 for ; Mon, 18 Nov 2002 16:23:16 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20364 for ; Mon, 18 Nov 2002 17:23:10 -0700 (MST) Subject: RE: Proposed IPv6 W.G. Charter Update Date: Mon, 18 Nov 2002 16:23:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B04640BD3C2@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Proposed IPv6 W.G. Charter Update thread-index: AcKPSDMuo1VlYhn0TKeSoXF7n9wSBwAGTceg From: "Michel Py" To: "Bob Hinden" , Cc: "Margaret Wasserman" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJ0N7kd029036 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I could have missed something, but looks good to me. Michel. > From: Bob Hinden > Subject: Proposed IPv6 W.G. Charter Update > Attached is a proposed update to the IPv6 working > group charter. This will be discussed at the IPv6 > session tonight at IETF55 and on the mailing list. > Please comment on the list and at tonights session. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 17:41:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ1f4kd000693; Mon, 18 Nov 2002 17:41:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ1f4DI000692; Mon, 18 Nov 2002 17:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ1f1kd000685 for ; Mon, 18 Nov 2002 17:41:01 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ1f9bB014279 for ; Mon, 18 Nov 2002 17:41:10 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21861 for ; Mon, 18 Nov 2002 17:41:04 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAJ1f1425518 for ; Tue, 19 Nov 2002 03:41:01 +0200 Date: Tue, 19 Nov 2002 03:40:59 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: MIPv6 and ND value changes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, FWIW, I fully support Thomas Narten on his view that MIPv6 should not be making all of these assumptions to e.g. Neighbor Discovery timer values. These should be in a separate document, either: - by mobileip, reviewed by ipv6 wg - by ipv6 wg (- waiting for the ND spec revising is probably not an option) Such a document could be quite short, and probably could be pushed quick through the IETF process. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 17:51:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ1p1kd000789; Mon, 18 Nov 2002 17:51:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ1p1ks000788; Mon, 18 Nov 2002 17:51:01 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ1ovkd000781 for ; Mon, 18 Nov 2002 17:50:57 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAJ1owL19763; Tue, 19 Nov 2002 02:50:59 +0100 (MET) Date: Tue, 19 Nov 2002 02:46:24 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Comments on prefix delegation requirements To: miyakawa@nttv6.jp Cc: ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think these are just editorial nits. The draft talks about "commercial" but I think the same issues are present if there is a non-commercial ISP that wants to offer non-commercial IPv6 service. So in terms of describing the need for the technology it is probably best to drop the "commercial" designation. Similarely, the statement about "boost IPv6 business quick as possible." might also distract from the technical content of the document. The document talks about "RA (Router Avertisement)". It would be good to add a reference to the proxy RA document (as "work in progress") to make the reference explicit. I see some spelling errors like "signle. 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 Nov 18 17:54:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ1s3kd000813; Mon, 18 Nov 2002 17:54:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ1s3Cb000812; Mon, 18 Nov 2002 17: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ1rxkd000805 for ; Mon, 18 Nov 2002 17:54:00 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ1s9bB017377 for ; Mon, 18 Nov 2002 17:54:09 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [210.254.137.98]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27961 for ; Mon, 18 Nov 2002 17:54:03 -0800 (PST) Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1:10c1::2687]) by guri.nttv6.jp (Postfix) with ESMTP id 08AD2B1630; Tue, 19 Nov 2002 10:54:02 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (Postfix) with ESMTP id BAF09125F17; Tue, 19 Nov 2002 10:54:01 +0900 (JST) Date: Tue, 19 Nov 2002 10:54:01 +0900 (JST) Message-Id: <20021119.105401.41639973.miyakawa@nttv6.jp> To: Erik.Nordmark@Sun.COM Cc: ipng@sunroof.eng.sun.com, miyakawa@nttv6.jp Subject: Re: Comments on prefix delegation requirements From: Shin Miyakawa In-Reply-To: References: Organizaton: NTT Communications X-Mailer: Mew version 2.2 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 From: Erik Nordmark Subject: Comments on prefix delegation requirements Date: Tue, 19 Nov 2002 02:46:24 +0100 (CET) > > I think these are just editorial nits. > > The draft talks about "commercial" but I think the same issues are present > if there is a non-commercial ISP that wants to offer non-commercial IPv6 > service. So in terms of describing the need for the technology it is probably > best to drop the "commercial" designation. > > Similarely, the statement about "boost IPv6 business quick as possible." > might also distract from the technical content of the document. > > The document talks about "RA (Router Avertisement)". It would be good to > add a reference to the proxy RA document (as "work in progress") > to make the reference explicit. > > I see some spelling errors like "signle. thanks! I will take those comments to update. Shin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 18:05:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ255kd000980; Mon, 18 Nov 2002 18:05:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ255Su000979; Mon, 18 Nov 2002 18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ252kd000972 for ; Mon, 18 Nov 2002 18:05:02 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ25BMq006624 for ; Mon, 18 Nov 2002 18:05:11 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02719 for ; Mon, 18 Nov 2002 18:05:05 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAJ253i25960 for ; Tue, 19 Nov 2002 04:05:03 +0200 Date: Tue, 19 Nov 2002 04:05:03 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes 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, 19 Nov 2002, Pekka Savola wrote: > Hello, > > FWIW, I fully support Thomas Narten on his view that MIPv6 should not be > making all of these assumptions to e.g. Neighbor Discovery timer values. s/assumptions/arbitrary changes/ shouldn't be writing quickly under sporadic network connectivity :-( > These should be in a separate document, either: > - by mobileip, reviewed by ipv6 wg > - by ipv6 wg > (- waiting for the ND spec revising is probably not an option) > > Such a document could be quite short, and probably could be pushed quick > through the IETF process. > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 18:07:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ27xkd001041; Mon, 18 Nov 2002 18:07:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ27wOM001040; Mon, 18 Nov 2002 18:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ27tkd001033 for ; Mon, 18 Nov 2002 18:07:55 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ284Mq007172 for ; Mon, 18 Nov 2002 18:08:04 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04384 for ; Mon, 18 Nov 2002 18:07:58 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAJ27r825974; Tue, 19 Nov 2002 04:07:53 +0200 Date: Tue, 19 Nov 2002 04:07:52 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: miyakawa@nttv6.jp, Subject: Re: Comments on prefix delegation requirements 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, 19 Nov 2002, Erik Nordmark wrote: > The draft talks about "commercial" but I think the same issues are present > if there is a non-commercial ISP that wants to offer non-commercial IPv6 > service. So in terms of describing the need for the technology it is probably > best to drop the "commercial" designation. Speaking of which, and the comment on security in the IETF meeting, I believe it is a perfectly fine usage scenario to run prefix delegation over shared ethernet (think of e.g. student dorm networks, usually based on switched, shared ethernet). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 18:39:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ2dkkd001357; Mon, 18 Nov 2002 18:39:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ2dk4H001356; Mon, 18 Nov 2002 18:39:46 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ2ddkd001338 for ; Mon, 18 Nov 2002 18:39:40 -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 gAJ2dhL23275; Tue, 19 Nov 2002 03:39:44 +0100 (MET) Date: Tue, 19 Nov 2002 03:35:05 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: MIPv6 and ND value changes To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > FWIW, I fully support Thomas Narten on his view that MIPv6 should not be > making all of these assumptions to e.g. Neighbor Discovery timer values. I think this makes sense as well. Let me try to state my reasons. Even though I think the current ND changes in the MIPv6 spec make sense, I'm concerned that implementors for IPv6 routers, which don't otherwise implement MIPv6, will find these pieces deep inside the MIPv6 specification. I think these things are more likely to be widely implemented if they live in a separate and shorter RFC. Also, we are likely to discover additional optimizations that might help with mobility and having a set of small specific extensions and/or modifications around ND or other protocols seems like a quicker way to make progress on these things. So while I don't want to slow down the MIPv6 specification or the implementation and deployment, I think breaking out these pieces will help with specification and protocol modularity, which makes it easier and quicker to revise the specifications along the standards track etc. 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 Nov 18 18:41:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ2fbkd001400; Mon, 18 Nov 2002 18:41:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ2fbH2001399; Mon, 18 Nov 2002 18:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ2fWkd001392 for ; Mon, 18 Nov 2002 18:41:32 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ2ffbB027569 for ; Mon, 18 Nov 2002 18:41:41 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28185 for ; Mon, 18 Nov 2002 19:41:35 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1A34A4B25 for ; Tue, 19 Nov 2002 11:41:34 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: RFC3041 privacy extension in nodereq From: itojun@iijlab.net Date: Tue, 19 Nov 2002 11:41:33 +0900 Message-Id: <20021119024134.1A34A4B25@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i think "MAY" is fine. conditions where the spec is appropriate are spelled out enough in RFC3041. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 18:45:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ2jYkd001564; Mon, 18 Nov 2002 18:45:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ2jYPT001563; Mon, 18 Nov 2002 18:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ2jUkd001550 for ; Mon, 18 Nov 2002 18:45:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ2jdbB028415 for ; Mon, 18 Nov 2002 18:45:39 -0800 (PST) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28507 for ; Mon, 18 Nov 2002 19:45:34 -0700 (MST) 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 gAJ2jX639693 for ; Mon, 18 Nov 2002 21:45:33 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id gAJ2jXc06748; Mon, 18 Nov 2002 21:45:33 -0500 (EST) Received: from newcastle.torrentnet.com (localhost [127.0.0.1]) by newcastle.torrentnet.com (8.12.6/8.11.6) with ESMTP id gAJ2jWhZ032789; Mon, 18 Nov 2002 21:45:32 -0500 (EST) (envelope-from slblake@newcastle.torrentnet.com) Received: (from slblake@localhost) by newcastle.torrentnet.com (8.12.6/8.12.6/Submit) id gAJ2jWNq032788; Mon, 18 Nov 2002 21:45:32 -0500 (EST) Date: Mon, 18 Nov 2002 21:45:32 -0500 From: Steven Blake To: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipv6-flow-label-03.txt Message-ID: <20021119024532.GA32767@newcastle.torrentnet.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 Please remove the following paragraph from page 5: With [RSVP] or [SDP] either the source or the destination of the flow could have a preference for the Flow Label value to be used. For example, a destination with multiple sources sending packets to it could require all the sources to use the same Flow Label value in order to collapse the classifier state to a single flow state entry, instead of having separate classifier state for each source (ref. the Wildcard-Filter reservation style in [RSVP]). Therefore the source SHOULD honor the destination's request to mark the packets with the Flow Label value specified. This is not safe operationally, because there is no way to guarantee that an unrelated source will not choose the same flow label value for another flow sent to that same destination. If we assume that there may be multiple flow labeling "applications" operating in a router, or between a source/ destination host pair, the consequences of this mis-classification cannot be predicted. Otherwise I am satisfied with the draft. 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 Mon Nov 18 18:49:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ2nfkd001744; Mon, 18 Nov 2002 18:49:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ2nfbd001743; Mon, 18 Nov 2002 18:49: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ2nbkd001733 for ; Mon, 18 Nov 2002 18:49:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ2nkbB029307 for ; Mon, 18 Nov 2002 18:49:46 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA25923 for ; Mon, 18 Nov 2002 19:49:40 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 94A1F4FF5; Mon, 18 Nov 2002 21:49:39 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Nov 2002 21:49:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: MIPv6 and ND value changes Date: Mon, 18 Nov 2002 21:48:17 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9B95@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv6 and ND value changes Thread-Index: AcKPbVFT2d5aiO74TjW3eeUEMqbDGAACKCOw From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 19 Nov 2002 02:49:34.0785 (UTC) FILETIME=[4B0CFB10:01C28F76] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJ2nckd001734 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The engineers who implemented MIPv6 and there are a few and in the MIPv6 working group are same engineers that do ND in most cases today. The issue is not one of expertise. This is MIPv6 work not IPv6 work. /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, November 18, 2002 8:41 PM > To: ipng@sunroof.eng.sun.com > Subject: MIPv6 and ND value changes > > > Hello, > > FWIW, I fully support Thomas Narten on his view that MIPv6 > should not be > making all of these assumptions to e.g. Neighbor Discovery > timer values. > > These should be in a separate document, either: > - by mobileip, reviewed by ipv6 wg > - by ipv6 wg > (- waiting for the ND spec revising is probably not an option) > > Such a document could be quite short, and probably could be > pushed quick > through the IETF process. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 18 18:51:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ2pYkd001818; Mon, 18 Nov 2002 18:51:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ2pXPH001817; Mon, 18 Nov 2002 18:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ2pUkd001810 for ; Mon, 18 Nov 2002 18:51:30 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ2pdbB029666 for ; Mon, 18 Nov 2002 18:51:39 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27266 for ; Mon, 18 Nov 2002 19:51:33 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 14D3E9F05; Mon, 18 Nov 2002 21:51:33 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Nov 2002 21:51:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: MIPv6 and ND value changes Date: Mon, 18 Nov 2002 21:51:30 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9B96@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv6 and ND value changes Thread-Index: AcKPdWnnuWDEQ8LYQP6uZpE+DE8YEgAANOjA From: "Bound, Jim" To: "Erik Nordmark" , "Pekka Savola" Cc: X-OriginalArrivalTime: 19 Nov 2002 02:51:32.0128 (UTC) FILETIME=[90FE1A00:01C28F76] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJ2pUkd001811 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Come on. You can't implement or understand MIPv6 if you don't have ND down. It is not even possible. The engineers in MIPv6 are clearly qualified to work to enhance ND. I don't believe moving it to separate spec will make it more implementable at all. MIPv6 is no longer a MUST. All your doiung with this support is holding up MIPv6 again. That's all. Adding no value. /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@Sun.COM] > Sent: Monday, November 18, 2002 9:35 PM > To: Pekka Savola > Cc: ipng@sunroof.eng.sun.com > Subject: Re: MIPv6 and ND value changes > > > > FWIW, I fully support Thomas Narten on his view that MIPv6 > should not > > be > > making all of these assumptions to e.g. Neighbor Discovery > timer values. > > I think this makes sense as well. Let me try to state my reasons. > > Even though I think the current ND changes in the MIPv6 spec > make sense, I'm concerned that implementors for IPv6 routers, > which don't otherwise implement MIPv6, will find these pieces > deep inside the MIPv6 specification. I think these things are > more likely to be widely implemented if they live in a > separate and shorter RFC. Also, we are likely to discover > additional optimizations that might help with mobility and > having a set of small specific extensions and/or > modifications around ND or other protocols seems like a > quicker way to make progress on these things. > > So while I don't want to slow down the MIPv6 specification or > the implementation and deployment, I think breaking out these > pieces will help with specification and protocol modularity, > which makes it easier and quicker to revise the > specifications along the standards track etc. > > Erik > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 18:57:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ2vXkd002014; Mon, 18 Nov 2002 18:57:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ2vXoh002013; Mon, 18 Nov 2002 18: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ2vTkd002006 for ; Mon, 18 Nov 2002 18:57:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ2vcbB000885 for ; Mon, 18 Nov 2002 18:57:38 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA29236 for ; Mon, 18 Nov 2002 19:57:30 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAJ2vQA26380; Tue, 19 Nov 2002 04:57:26 +0200 Date: Tue, 19 Nov 2002 04:57:25 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: RFC3041 privacy extension in nodereq In-Reply-To: <20021119024134.1A34A4B25@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 19 Nov 2002 itojun@iijlab.net wrote: > i think "MAY" is fine. Agree. > conditions where the spec is appropriate > are spelled out enough in RFC3041. Actually, they definitely *aren't* (or rather, they give a wrong impression), see draft-dupont-ipv6-rfc3041harmful-01.txt -- new security considerations / applicability consideration is needed. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 19:04:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ34Ckd002310; Mon, 18 Nov 2002 19:04:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ34CsJ002309; Mon, 18 Nov 2002 19:04:12 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ347kd002299 for ; Mon, 18 Nov 2002 19:04:08 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAJ33nL25368; Tue, 19 Nov 2002 04:03:50 +0100 (MET) Date: Tue, 19 Nov 2002 04:00:40 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: MIPv6 and ND value changes To: "Bound, Jim" Cc: Erik Nordmark , Pekka Savola , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <9C422444DE99BC46B3AD3C6EAFC9711B02BE9B96@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Come on. You can't implement or understand MIPv6 if you don't have ND down. > It is not even possible. > The engineers in MIPv6 are clearly qualified to work to enhance ND. I think I can implement MIPv6 just fine without section 7.5, 7.6, and 7.7 in the MIPv6 draft. After all, I'll have 149-3 pages to implement. Having those sections separate makes it easier to add more ND optimizations for Mobile IPv6 as we learn more. I don't want people that work out e.g. an optimistic DAD scheme to have to stick that into the MIPv6 document just because the MIPv6 document talks about DAD. > I don't believe moving it to separate spec will make it more implementable > at all. MIPv6 is no longer a MUST. I don't understand your point. This issue is not about implementing the 146 pages in routers; the issue is to get routers to implement the 3 pages of ND changes that improve the performance of movement detection. 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 Nov 18 19:16:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ3Gqkd002527; Mon, 18 Nov 2002 19:16:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ3GqwZ002526; Mon, 18 Nov 2002 19:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ3Gmkd002516 for ; Mon, 18 Nov 2002 19:16:48 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ3GvMq024755 for ; Mon, 18 Nov 2002 19:16:58 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01188 for ; Mon, 18 Nov 2002 19:16:52 -0800 (PST) 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 TAA16232; Mon, 18 Nov 2002 19:16:52 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAJ3Gpk14090; Mon, 18 Nov 2002 19:16:51 -0800 X-mProtect: <200211190316> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdv7kTqa; Mon, 18 Nov 2002 19:16:49 PST Message-ID: <3DD9AD22.FBF2AFC1@iprg.nokia.com> Date: Mon, 18 Nov 2002 19:16:50 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > > > FWIW, I fully support Thomas Narten on his view that MIPv6 should not be > > making all of these assumptions to e.g. Neighbor Discovery timer values. > > s/assumptions/arbitrary changes/ on the contrary, they have been well thought out and discussed on the MIPv6 mailing list. take a look at the changes first. for example RFC 2462 says if DAD fails, the node SHOULD disable the interface. MIPv6 says if DAD fails, generate a random interface ID and try again. take a look at the following URL for the discussion. http://www.piuha.net/~jarkko/publications/mipv6/issues/issue79.txt can you give me one good reason why this change that MIPv6 recommends is arbitrary? come on..... Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 19:32:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ3WDkd002761; Mon, 18 Nov 2002 19:32:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ3WDG0002760; Mon, 18 Nov 2002 19:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ3WAkd002753 for ; Mon, 18 Nov 2002 19:32:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ3WIbB007279 for ; Mon, 18 Nov 2002 19:32:19 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA13048 for ; Mon, 18 Nov 2002 20:32:11 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAJ3W3T26665; Tue, 19 Nov 2002 05:32:03 +0200 Date: Tue, 19 Nov 2002 05:32:02 +0200 (EET) From: Pekka Savola To: Vijay Devarapalli cc: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes In-Reply-To: <3DD9AD22.FBF2AFC1@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 18 Nov 2002, Vijay Devarapalli wrote: > > > FWIW, I fully support Thomas Narten on his view that MIPv6 should not be > > > making all of these assumptions to e.g. Neighbor Discovery timer values. > > > > s/assumptions/arbitrary changes/ > > on the contrary, they have been well thought out and discussed > on the MIPv6 mailing list. take a look at the changes first. > > for example RFC 2462 says if DAD fails, the node SHOULD disable > the interface. MIPv6 says if DAD fails, generate a random > interface ID and try again. take a look at the following URL > for the discussion. > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue79.txt > > can you give me one good reason why this change that MIPv6 > recommends is arbitrary? come on..... This isn't MIPv6 specific. One could say this case if only relevant if you use manually configured care-of addresses (that is, clashes are not so rare that you need to, in practise, care about them). Oh you don't assign them manually? Forget about it then. It's a good enhancement, but doen't belong in the MIPv6 spec. btw. "arbitrary" was a bit strong word; I should have said "substantial". -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 19:48:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ3mWkd002946; Mon, 18 Nov 2002 19:48:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ3mV5x002945; Mon, 18 Nov 2002 19:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ3mSkd002938 for ; Mon, 18 Nov 2002 19:48:28 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ3mbMq000007 for ; Mon, 18 Nov 2002 19:48:37 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13484 for ; Mon, 18 Nov 2002 19:48:31 -0800 (PST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJ3lxO16394 for ; Tue, 19 Nov 2002 05:47:59 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Nov 2002 05:48:30 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 05:48:30 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 05:48:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MIPv6 and ND value changes Date: Tue, 19 Nov 2002 05:48:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv6 and ND value changes Thread-Index: AcKPdX4CAEarswyzTyyhtU7KrmJpHwACFhmw To: , Cc: X-OriginalArrivalTime: 19 Nov 2002 03:48:29.0841 (UTC) FILETIME=[861BB810:01C28F7E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJ3mSkd002939 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, > So while I don't want to slow down the MIPv6 specification or the > implementation and deployment, I think breaking out these pieces will help > with specification and protocol modularity, which makes it easier and quicker > to revise the specifications along the standards track etc. So, perhaps my comment is a bit naive, but as the changes have been discussed in the MIP WG and many people think the changes are sane in the IPv6 WG ... I wonder what would be accomplished by breaking them out in a seperate document. Since the IPv6 WG will be working updating ND, could not the MIPv6 draft make the recommendations and then these recomentations be taken as the starting point for the ND discussions in the IETF? John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 19:49:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ3nqkd002972; Mon, 18 Nov 2002 19:49:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ3noVN002971; Mon, 18 Nov 2002 19:49: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ3nlkd002964 for ; Mon, 18 Nov 2002 19:49:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ3nuMq000201 for ; Mon, 18 Nov 2002 19:49:56 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA20715 for ; Mon, 18 Nov 2002 20:49:47 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id WAA10024; Mon, 18 Nov 2002 22:49:42 -0500 (EST) Date: Mon, 18 Nov 2002 22:49:42 -0500 (EST) From: Dan Lanciani Message-Id: <200211190349.WAA10024@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: Proposal for site-local clean-up Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: |Being the probable guilty party for introducing this thought back in |draft-*-site-prefixes-00.txt I can offer a slightly expanded perspective. | |I don't think stable addresses per se is the key thing - it is |the robustness of the communication that is important. Given that nobody seems to know how to make communication (as many applications currently understand/use it) robust in the face of _unstable_ addresses it isn't obvious that this distinction is of much utility. |This robustness has at least two factors that are relevant in this |discussion: the stability of the addresses, and the leakage of |non-global scope addresses. I think the question is how to weigh those |together. Ok, but it isn't clear that these two factors are of even remotely similar weight. Leakage is a problem that can be addressed, but there are a lot of things that simply will not work without stable addresses (at least not without a complete overhaul of many higher-level protocols). |In terms of the stability of the addresses one has to take into account |both stability as it relates to local communication and stability for |global communication. We have always been told that stable global v6 addresses will not be available to end users, or at least will not be available to end users at a low cost. Unless you are proposing to revise the whole address allocation architecture *and* have a way to force ISPs to change their business models I think we must accept this as a given. |If you assume that the value/importance of local |communication is much higher than the value/importance of global communication |then site-locals make sense to explore. I think you have made an unreasonable leap by dropping the "stable" qualifier. The value/importance of _stable_ local communication is almost certainly much higher than the value/importance of _stable_ global communication. We already accept that sometimes when we click a link in a browser things go wrong and we have to try again. Protocols like SMTP that drive global email assume that almost anything can go wrong and have the capability to queue messages for days if necessary. But my NFS client is simply not prepared to have its server's address renumbered out from under it. My multi-hour build will fail unless I notice the problem and fire up adb on the kernel in a hurry. Similarly my print job will fail if the printer and/or client is/are renumbered in the middle of a tcp session. My distributed home automation system, while quite tolerant of temporary lost connections and machine reboots, can not deal with addresses changing out from under it. This is hardly unreasonable because the tools to deal gracefully with such situations have not yet been invented. To make such things work now each application would have to implement its own procedures to deal with unstable addresses. This is obviously not acceptable to application writers. |(FWIW that was my assumption |way back). |Such an assumption might make sense we say that a site is an |administrative concept (such as a company), but it makes less sense |if a site is a geographic concept and as I understand the original |thoughts a site was intended to be a geographic concept like a building |or a campus. We understand that sites are administrative. |In any case, for a home user I suspect that the value/importance of |local communication would typically be less than the value/importance |of global communication. Again assuming we are talking about _stable_ communication, I believe that you are incorrect. Granted those of us who depend on our home networks for automation and such are currently on the bleeding edge, but what about the future when every stereo and tv is on the net? It's one thing to have to re-click that remote link in the browser, but quite another to have your stereo refuse to change channels. Consumers are not going to pay their ISP a premium to keep their stereos working. I know it sounds nice in theory, but look what happened to Divx. If you take away scoped addressing we _will_ use NAT. |Thus the ISP offering a service with unstable |global addresses I don't think it would be that satisfactory |for the peer-to-peer communication that we wish to enable with IPv6, |even if there are stable site-local addresses so that the user can |communicate inside their home without a glitch. I'm having trouble parsing the above. ISPs currently offer unstable v4 addresses (unless you pay extra) and they aren't satisfactory for the peer-to-peer communication we used to have back when address space was portable. People have worked around this with various application-level kludges. You obviously recognize that stable addresses have value, so I don't understand why you expect that ISPs will suddenly stop charging for that value. Depriving users of the tools necessary to make productive use of their networks without paying for stable globals for all internal nodes will just encourage yet another round of kludges. |So let's not loose sight of the fact that the goal is a robust network. I think that the goal is a useful network--useful not only for ISPs and application vendors but for consumers. 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 Nov 18 20:02:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ42Akd003203; Mon, 18 Nov 2002 20:02:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ42ARF003202; Mon, 18 Nov 2002 20:02:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ425kd003195 for ; Mon, 18 Nov 2002 20:02:06 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ42EbB011738 for ; Mon, 18 Nov 2002 20:02:14 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18220; Mon, 18 Nov 2002 20:02:09 -0800 (PST) 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 UAA17485; Mon, 18 Nov 2002 20:02:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAJ427d11961; Mon, 18 Nov 2002 20:02:07 -0800 X-mProtect: <200211190402> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.29.39, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdK6qmwV; Mon, 18 Nov 2002 20:02:05 PST Message-ID: <3DD9B77C.1380EE4@iprg.nokia.com> Date: Mon, 18 Nov 2002 20:01:00 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Erik, I am particularly concerned that we have a Mobile IPv6 specification that, when implemented, gives sensible results. Eliminating the possibility for having faster router advertisements does not give sensible results. However, the stated reasons for wanting to change the existing Mobile IPv6 specification in this particular way are not logically valid. I will try to make this clear in what follows. Erik Nordmark wrote: > Even though I think the current ND changes in the MIPv6 spec make sense, Thank you. > I'm concerned that implementors for IPv6 routers, which don't otherwise > implement MIPv6, will find these pieces deep inside the MIPv6 specification. I'm concerned for implementers of systems that want to support Mobile IPv6. When the specifications are rewritten for all routers, then at that time the revised specificatoin needs to take the Mobile IPv6 specification into account. This would completely resolve your fear. It could be that the new specification would make some parameter settings conditional on whether or not the routers are expected to provide support for the attachment of mobile nodes. > I think these things are more likely to be widely implemented if > they live in a separate and shorter RFC. That is trying to predict the future in a very dangerous way. Your statement would only be true if no one tried to put any other features in there. The discussion about optimistic DAD, for instance, might take months. I have no faith that such a document would progress rapidly. Look at the flow-lable specification for example... > Also, we are likely to discover additional optimizations that might help > with mobility and having a set of small specific extensions and/or > modifications around ND or other protocols seems like a quicker way to make > progress on these things. That has no bearing on the immediate problem. In fact, I would suggest that the attempt, while praiseworthy, would have exactly the effect of slowing down this one crucial piece of parameter specification., > So while I don't want to slow down the MIPv6 specification or the > implementation and deployment, I think breaking out these pieces will help > with specification and protocol modularity, which makes it easier and quicker > to revise the specifications along the standards track etc. Most of the things suggested do not break the specification. Eliminating the possibility for faster advertisements does. This has been shown, and work with faster advertisements has been done many times. The discussion has already been made in the IPng working group from years ago, and nothing has happened to warrant this particular change. There is no justification for it. Anything that has to be done in a more general setting would still be quite well able to be done in the more general setting, regardless of what goes into the Mobile IPv6 specification. 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 Nov 18 20:13:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ4DNkd003432; Mon, 18 Nov 2002 20:13:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ4DNF9003431; Mon, 18 Nov 2002 20:13:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ4DKkd003424 for ; Mon, 18 Nov 2002 20:13:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ4DTbB013399 for ; Mon, 18 Nov 2002 20:13:29 -0800 (PST) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA29985 for ; Mon, 18 Nov 2002 21:13:20 -0700 (MST) Received: from consulintel02 ([204.42.71.231]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Tue, 19 Nov 2002 05:18:19 +0100 Message-ID: <013f01c28f82$af3e6ea0$e7472acc@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20021119.105401.41639973.miyakawa@nttv6.jp> Subject: Re: Comments on prefix delegation requirements Date: Tue, 19 Nov 2002 05:18:14 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 204.42.71.231 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Shin, As we just discussed, I believe that this work will be very useful for the deployment of IPv6 on power line technology (see www.6power.org). But I feel that your document should be more clear regarding these requirements are not just for ADSL (Motivation section). I know you say "examples", but, for instance, we know that it work already with Ethernet links instead of point-to-point, as in fact is indicated in "layer 2 consideration". Hope it helps ;-) Regards, Jordi ----- Original Message ----- From: "Shin Miyakawa" To: Cc: ; Sent: Tuesday, November 19, 2002 2:54 AM Subject: Re: Comments on prefix delegation requirements > From: Erik Nordmark > Subject: Comments on prefix delegation requirements > Date: Tue, 19 Nov 2002 02:46:24 +0100 (CET) > > > > > I think these are just editorial nits. > > > > The draft talks about "commercial" but I think the same issues are present > > if there is a non-commercial ISP that wants to offer non-commercial IPv6 > > service. So in terms of describing the need for the technology it is probably > > best to drop the "commercial" designation. > > > > Similarely, the statement about "boost IPv6 business quick as possible." > > might also distract from the technical content of the document. > > > > The document talks about "RA (Router Avertisement)". It would be good to > > add a reference to the proxy RA document (as "work in progress") > > to make the reference explicit. > > > > I see some spelling errors like "signle. > > thanks! I will take those comments to update. > > Shin > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > *********************************** Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Soon on line at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 20:25:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ4Pvkd003545; Mon, 18 Nov 2002 20:25:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ4PvlE003544; Mon, 18 Nov 2002 20:25: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ4Pskd003537 for ; Mon, 18 Nov 2002 20:25:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ4Q3Mq005562 for ; Mon, 18 Nov 2002 20:26:03 -0800 (PST) Received: from mail.iwavesystems.com (iwave-54-144-ban.iwavesystems.com [203.196.144.54] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA09929 for ; Mon, 18 Nov 2002 21:25:55 -0700 (MST) Received: from iwave120 (ns1.iwave.net [203.196.144.50]) by mail.iwavesystems.com (8.12.4/) with SMTP id gAJ4L1w8020736; Tue, 19 Nov 2002 09:51:03 +0530 Message-ID: <002801c28f84$397948a0$b202a8c0@iwave120> From: "Anurag Uxa" To: "Keith Moore" , Cc: , References: <200211181517.gAIFHal18400@astro.cs.utk.edu> Subject: Tunnel NUD Date: Tue, 19 Nov 2002 09:59:05 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C28FB2.4BD38820" 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-Virus-Scanned: Message: ok X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.14 (www dot roaringpenguin dot com slash mimedefang) X-Filter-Version: 1.4.5 (mail.iwavesystems.com) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C28FB2.4BD38820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Keith n all=20 Please clear my doubt. How these following lines of RFC's are possible? If an implementation provides bidirectional configured tunnels it MUST = at least accept and respond to the probe packets used by Neighbor = Unreachability Detection. Such implementations SHOULD also send NUD = probe packets to detect when the configured tunnel fails at which point = the implementation can use an alternate path to reach the destination. Anurag Uxa IWave Embedded systems Bangalore-76 ph.6786243/5 extn :205 www.iwavesystems.com DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. ------=_NextPart_000_0025_01C28FB2.4BD38820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Keith n all=20

Please clear my doubt. = How these=20 following lines of RFC's are possible?

If an = implementation provides=20 bidirectional configured tunnels it MUST at least=20 accept and respond to the probe packets used by Neighbor Unreachability Detection. Such implementations SHOULD=20 also send NUD probe packets to detect = when the=20 configured tunnel fails at which = point the=20 implementation can use an alternate path to reach=20 the destination.

 

 

 

Anurag Uxa
IWave Embedded=20 systems
Bangalore-76
ph.6786243/5 extn :205

www.iwavesystems.com

 


DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation.

------=_NextPart_000_0025_01C28FB2.4BD38820-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 20:51:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ4pYkd003722; Mon, 18 Nov 2002 20:51:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ4pYRR003721; Mon, 18 Nov 2002 20: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ4pVkd003714 for ; Mon, 18 Nov 2002 20:51:31 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ4pebB019339 for ; Mon, 18 Nov 2002 20:51:40 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA06767 for ; Mon, 18 Nov 2002 20:51:34 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2903B2938; Mon, 18 Nov 2002 23:51:34 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Nov 2002 23:51:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: MIPv6 and ND value changes Date: Mon, 18 Nov 2002 23:51:33 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9B9C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv6 and ND value changes Thread-Index: AcKPeF4a6lkwTdbvQUKuZPw1EnVf0wADeWnQ From: "Bound, Jim" To: "Erik Nordmark" Cc: "Pekka Savola" , X-OriginalArrivalTime: 19 Nov 2002 04:51:34.0051 (UTC) FILETIME=[55AC5730:01C28F87] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJ4pVkd003715 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > Come on. You can't implement or understand MIPv6 if you > don't have ND > > down. It is not even possible. The engineers in MIPv6 are clearly > > qualified to work to enhance ND. > > I think I can implement MIPv6 just fine without section 7.5, > 7.6, and 7.7 in the MIPv6 draft. After all, I'll have 149-3 > pages to implement. Missed my point. You can't implement part of ND for a feature like MIPv6. You have to understand ND as a software engineer. > > Having those sections separate makes it easier to add more > ND optimizations for Mobile IPv6 as we learn more. > I don't want people that work out e.g. an optimistic DAD > scheme to have to stick that into the MIPv6 document just > because the MIPv6 document talks about DAD. I don't think they should put it in MIPv6 either. It will be another draft and PANA could be another one etc etc etc. Each working group or each engineer will suggest what they need within ND architecture. That's how we build ND and why we moved it to IP layer in the first place. But I agree we need to watch it at the IESG layer. But MIPv6 has been thoroughly understood and unless clear technical problems can be stated in the interest of time-to-market in this IETF it should be let go for this effort. But building an ND Technical Directorate to assist the IESG Layer could be done for DAD, PANA, and other ND fruits to verify they are not insane. This approach gets MIPv6 to PS. The ND Directorate is formed and if MIPv6 is truly bogus then it is only PS we just fix it or change how we do it. I think it is prudent in our community to demonstrate as a standards body we still understand why we are here and that is to produce good specs and ship them. MIPv6 Draft 19 is in fact that and we should move on. > > > I don't believe moving it to separate spec will make it more > > implementable at all. MIPv6 is no longer a MUST. > > I don't understand your point. This issue is not about > implementing the 146 pages in routers; the issue is to get > routers to implement the 3 pages of ND changes that improve > the performance of movement detection. My point was that there were MUSTs taken out in Draft 19 but not these I understand. Any router or host or client that wants or sees a need to do MIPv6 is fine with Draft 19 and if they are not building Mobile IPv6 products they should not care. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 20:56:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ4uOkd003799; Mon, 18 Nov 2002 20:56:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ4uOeQ003798; Mon, 18 Nov 2002 20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ4uKkd003785 for ; Mon, 18 Nov 2002 20:56:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ4uTMq009817 for ; Mon, 18 Nov 2002 20:56:29 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21632 for ; Mon, 18 Nov 2002 21:56:24 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 95C702EFF; Mon, 18 Nov 2002 23:56:23 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Nov 2002 23:56:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: MIPv6 and ND value changes Date: Mon, 18 Nov 2002 23:56:22 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9B9D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv6 and ND value changes Thread-Index: AcKPfQP41h1OpTmETrGF0EXW8r/pUAACpdcA From: "Bound, Jim" To: "Pekka Savola" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 19 Nov 2002 04:56:23.0407 (UTC) FILETIME=[02248FF0:01C28F88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJ4uLkd003786 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue79.txt I just want to point out that Francis and Vlad in the above both are implemetors not rubber neckers and both work in IPv6 WG and MIPv6 WG so the expertise is in both groups (Thomas this is one example why I think IPv6 WG is covered). Same for Brian Haley, Carl Williams, Alper Yegin....etc etc. So lets not at least be under the illusion that MIPv6 does not have IPv6 WG expertise that is simply bogus. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 18 22:38:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ6cdkd004521; Mon, 18 Nov 2002 22:38:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJ6cdce004520; Mon, 18 Nov 2002 22:38:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJ6cZkd004513 for ; Mon, 18 Nov 2002 22:38:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJ6ciMq025802 for ; Mon, 18 Nov 2002 22:38:44 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA04364 for ; Mon, 18 Nov 2002 23:37:44 -0700 (MST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 18 Nov 2002 22:37:09 -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); Mon, 18 Nov 2002 22:37:09 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Nov 2002 22:37:08 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 18 Nov 2002 22:37:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for site-local clean-up Date: Mon, 18 Nov 2002 22:37:05 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKPOV1uWI1X8a80TwSutOLnFMXE8gAVGxaw From: "Brian Zill" To: X-OriginalArrivalTime: 19 Nov 2002 06:37:08.0267 (UTC) FILETIME=[1528FFB0:01C28F96] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJ6cakd004514 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark writes: > I don't think stable addresses per se is the key > thing - it is the robustness of the communication > that is important. I agree with this. However, the minimal degree of robustness is working at all - something which requires some address of some sort. There needs to be a way to get an address when you don't have a provider. This means either scoped addresses as we have defined them already (and in multi-link locations, this means either site-local or multi-link subnet routers and link-local), or some sort of provider-independent address (note there are various types of these as well, depending upon whether we believe they should be explicity non-routable, or privately routable between multiple non-connected 'sites'). > This robustness has at least two factors that are > relevant in this discussion: the stability of the > addresses, and the leakage of non-global scope > addresses. I think the question is how to > weigh those together. Regarding leakage of non-global scope addresses, I don't see this as a major problem given the way our current scoped addresses are defined. Having an explicit prefix makes it straight-forward for border routers to filter them. The scope-id in the sockaddr field makes it easy for applications to know on which interfaces an address is usable and to whom it is legit to pass (something that isn't true for the 169.254.x.x "link-local" addresses in v4 today). I'd be more worried about leakage of provider-independent addresses which don't share an explicitly non-routable prefix. > In any case, for a home user I suspect that the > value/importance of local communication would > typically be less than the value/importance of > global communication. As I mentioned in my last message on this topic, I believe a lot of the argument around site-locals is really about expected usage models. Personally, I would expect the opposite of what you say above. Home users watching a movie on their IPv6-enabled television screen in the living room (which is streaming in from the media server in their basement) won't be happy if their movie quits because their kid just dialed into the Internet and the resulting global address advertisment required all site-local communication to stop. More generally, I don't want IPv6 to be just for the Internet. If we've done it right, IPv6 will be used for all sorts of communication between lots of devices which typically don't have network connectivity today. I'm worried that this working group too often sees things in terms of only traditional computers as the hosts, and the routers all belonging to organizations which have administrators to run them. We shouldn't try to dumb down IPv6 so that it only works well in the environment IPv4 was conceived in. > Finally, an enemy to robustness is complexity. > Site-locals add complexity in many places; > applications, two-faced DNS configuration, etc. Yes, needless complexity is bad. But site-locals don't add any significant complexity to applications (which I think I've demonstated enough in too many emails already). Many existing IPv4-only sites run two-faced DNS today, so there clearly are people out there who think it is worth it for reasons that have nothing to do with IPv6. If we think that's not optimal, we should be thinking about figuring out why they run their IPv4 networks that way today and come up with a better solution for them using IPv6. > So let's not loose sight of the fact that the > goal is a robust network. Sure. And scoped addresses have the potential to make the network more robust (I'd say that link-locals have already proved their worth in this regard). --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 Nov 19 04:03:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJC3dkd006570; Tue, 19 Nov 2002 04:03:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJC3doY006569; Tue, 19 Nov 2002 04:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJC3Xkd006562 for ; Tue, 19 Nov 2002 04:03:36 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJC3gbB020330 for ; Tue, 19 Nov 2002 04:03:42 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07379 for ; Tue, 19 Nov 2002 05:03:36 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id E576841F9 for ; Tue, 19 Nov 2002 07:03:35 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Nov 2002 07:03:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for site-local clean-up Date: Tue, 19 Nov 2002 07:03:35 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240C3B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKPOV1uWI1X8a80TwSutOLnFMXE8gAVGxawAA0EYSA= From: "Bound, Jim" To: "Brian Zill" , X-OriginalArrivalTime: 19 Nov 2002 12:03:35.0815 (UTC) FILETIME=[B03FA170:01C28FC3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJC3akd006563 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Erik Nordmark writes: > > I don't think stable addresses per se is the key > > thing - it is the robustness of the communication > > that is important. > > I agree with this. However, the minimal degree of robustness > is working at all - something which requires some address of > some sort. There needs to be a way to get an address when > you don't have a provider. This means either scoped addresses > as we have defined them already (and in multi-link locations, > this means either site-local or multi-link subnet routers and > link-local), or some sort of provider-independent address > (note there are various types of these as well, depending > upon whether we believe they should be explicity > non-routable, or privately routable between multiple > non-connected 'sites'). I cannot see anyway to route site-locals across multiple sites? Your not saying to do this are you? Now if a site is split geographically but the same site that theoretically could happen but have we thought of all the deprecated cases and that which breaks to provide routing between them? I don't think we have or had that discussion. Or do we care about the above case here in the standards group? I think we should. Part of the issue for all this mail is not to kill SLs but to make sure we understand them and how to use them and how to manage them and what their affect to users will be. > > > This robustness has at least two factors that are > > relevant in this discussion: the stability of the > > addresses, and the leakage of non-global scope > > addresses. I think the question is how to > > weigh those together. > > Regarding leakage of non-global scope addresses, I don't see > this as a major problem given the way our current scoped > addresses are defined. Having an explicit prefix makes it > straight-forward for border routers to filter them. The > scope-id in the sockaddr field makes it easy for applications > to know on which interfaces an address is usable and to whom > it is legit to pass (something that isn't true for the > 169.254.x.x "link-local" addresses in v4 today). I'd be more > worried about leakage of provider-independent addresses which > don't share an explicitly non-routable prefix. I too am more worried about PI addresses for sure. SLs are much wiser to support what I believe some want from SLs. As far as leaking the problem is also if they are tunneled too? But we need a spec that we all buy into that states they are not to forwarded beyond a router site interface until we all agree on that spec how can we ask the general public to use them. That is not wise. Until we figure that out we have to say don't use them with globally connected networks. Sure some vendor may filter them and do the right thing but I for one want a spec that says don't do that and see us all hum to that and agree. We need a spec that just does this for SLs and nothing else about scoping. > > > In any case, for a home user I suspect that the > > value/importance of local communication would > > typically be less than the value/importance of > > global communication. > > As I mentioned in my last message on this topic, I believe a > lot of the argument around site-locals is really about > expected usage models. Personally, I would expect the > opposite of what you say above. Home users watching a movie > on their IPv6-enabled television screen in the living room > (which is streaming in from the media server in their > basement) won't be happy if their movie quits because their > kid just dialed into the Internet and the resulting global > address advertisment required all site-local communication to stop. With a spec that defines the boundaries this would not happen to this user. > > More generally, I don't want IPv6 to be just for the > Internet. If we've done it right, IPv6 will be used for all > sorts of communication between lots of devices which > typically don't have network connectivity today. I'm worried > that this working group too often sees things in terms of > only traditional computers as the hosts, and the routers all > belonging to organizations which have administrators to run > them. We shouldn't try to dumb down IPv6 so that it only > works well in the environment IPv4 was conceived in. I agree 100% with this view. Good luck here. > > > Finally, an enemy to robustness is complexity. > > Site-locals add complexity in many places; > > applications, two-faced DNS configuration, etc. > > Yes, needless complexity is bad. But site-locals don't add > any significant complexity to applications (which I think > I've demonstated enough in too many emails already). Many > existing IPv4-only sites run two-faced DNS today, so there > clearly are people out there who think it is worth it for > reasons that have nothing to do with IPv6. If we think > that's not optimal, we should be thinking about figuring out > why they run their IPv4 networks that way today and come up > with a better solution for them using IPv6. I think they do add complexity but that is not the issue and no one will win that debate. Two faced-dns is complex. The issue is we have not defined the boundaries of their use and the pain they can cause well enough for them to be used without health warnings currently. > > > So let's not loose sight of the fact that the > > goal is a robust network. > > Sure. And scoped addresses have the potential to make the > network more robust (I'd say that link-locals have already > proved their worth in this regard). I agree and we understand clearly the use of LLs and their limitations, but we do not for SLs. /jim > > --Brian > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 04:38:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJCcwkd006762; Tue, 19 Nov 2002 04:38:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJCcwiC006761; Tue, 19 Nov 2002 04:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJCctkd006754 for ; Tue, 19 Nov 2002 04:38:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJCd4Mq017465 for ; Tue, 19 Nov 2002 04:39:04 -0800 (PST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05172 for ; Tue, 19 Nov 2002 05:38:59 -0700 (MST) Message-ID: <003f01c28fc8$63d6ae00$8f6015ac@T23KEMPF> From: "James Kempf" To: "Vijay Devarapalli" , "Pekka Savola" Cc: References: <3DD9AD22.FBF2AFC1@iprg.nokia.com> Subject: Re: MIPv6 and ND value changes Date: Tue, 19 Nov 2002 04:37:11 -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 Vijay, I think the issue isn't whether this particular optimization is important or not. The issue is whether we should leave it in the base spec or put it into a spec with all the other ND optimization bits. jak ----- Original Message ----- From: "Vijay Devarapalli" To: "Pekka Savola" Cc: Sent: Monday, November 18, 2002 7:16 PM Subject: Re: MIPv6 and ND value changes > Pekka Savola wrote: > > > > > > > > FWIW, I fully support Thomas Narten on his view that MIPv6 should not be > > > making all of these assumptions to e.g. Neighbor Discovery timer values. > > > > s/assumptions/arbitrary changes/ > > on the contrary, they have been well thought out and discussed > on the MIPv6 mailing list. take a look at the changes first. > > for example RFC 2462 says if DAD fails, the node SHOULD disable > the interface. MIPv6 says if DAD fails, generate a random > interface ID and try again. take a look at the following URL > for the discussion. > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue79.txt > > can you give me one good reason why this change that MIPv6 > recommends is arbitrary? come on..... > > Vijay > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 19 04:47:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJCl6kd006829; Tue, 19 Nov 2002 04:47:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJCl5Y9006828; Tue, 19 Nov 2002 04:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJCl2kd006821 for ; Tue, 19 Nov 2002 04:47:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJClCMq018802 for ; Tue, 19 Nov 2002 04:47:12 -0800 (PST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06376 for ; Tue, 19 Nov 2002 04:47:07 -0800 (PST) Message-ID: <004d01c28fc9$8751aaf0$8f6015ac@T23KEMPF> From: "James Kempf" To: , , Cc: References: Subject: Re: MIPv6 and ND value changes Date: Tue, 19 Nov 2002 04:45:13 -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 John, The primary issue is whether the ND spec itself should benefit. The behavior of DAD failure is an example. RFC 2461 currently has a built-in DoS hole in that it specifies the host should shut down the interface if there is a DAD failure. This is a perfect opportunity for propagating a successful DoS attack, and is not restricted to MIP. By burying the solution for this into the MIP spec, it removes the possibility that wider IPv6 nodes can benefit. However, there are other proposed ND optimizations that are purely mobile specific. Some of these are in the MIP spec, some aren't. I think it makes some sense to group these into a seperate spec in the MIP group. jak ----- Original Message ----- From: To: ; Cc: Sent: Monday, November 18, 2002 7:48 PM Subject: RE: MIPv6 and ND value changes > Hi Erik, > > > So while I don't want to slow down the MIPv6 specification or the > > implementation and deployment, I think breaking out these pieces will help > > with specification and protocol modularity, which makes it easier and quicker > > to revise the specifications along the standards track etc. > > So, perhaps my comment is a bit naive, but as the changes have been > discussed in the MIP WG and many people think the changes are > sane in the IPv6 WG ... I wonder what would be accomplished by > breaking them out in a seperate document. Since the IPv6 > WG will be working updating ND, could not the MIPv6 draft > make the recommendations and then these recomentations be taken > as the starting point for the ND discussions in the IETF? > > 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 Tue Nov 19 05:11:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDBtkd007006; Tue, 19 Nov 2002 05:11:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJDBtnK007005; Tue, 19 Nov 2002 05:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDBpkd006998 for ; Tue, 19 Nov 2002 05:11:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJDC0bB029164 for ; Tue, 19 Nov 2002 05:12:00 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21107 for ; Tue, 19 Nov 2002 06:11:50 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA18572 for ; Tue, 19 Nov 2002 13:11:49 GMT Received: from login.ecs.soton.ac.uk (IDENT:LKpRDT2j803spKO0JILZSCCiLlXN9+bi@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAJDBgWX001093 for ; Tue, 19 Nov 2002 13:11:42 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gAJDBgR07230 for ipng@sunroof.eng.sun.com; Tue, 19 Nov 2002 13:11:42 GMT Date: Tue, 19 Nov 2002 13:11:42 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: RFC3041 privacy extension in nodereq Message-ID: <20021119131142.GA7154@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <20021119024134.1A34A4B25@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Nov 19, 2002 at 04:57:25AM +0200, Pekka Savola wrote: > On Tue, 19 Nov 2002 itojun@iijlab.net wrote: > > i think "MAY" is fine. > > Agree. > > > conditions where the spec is appropriate > > are spelled out enough in RFC3041. > > Actually, they definitely *aren't* (or rather, they give a wrong > impression), see draft-dupont-ipv6-rfc3041harmful-01.txt -- new security > considerations / applicability consideration is needed. I agree with Pekka. Regarding the node requirements themselves, I feel the main use of the draft is a collection of pointers to guide implementors to the rfcs they should refer to when developing ipv6 nodes. Thus I don't think any policies/etc should be made here, but pointed to in the relevant rfcs. (For example the suggestion of "cutting and pasting" policy from rfc3041 into this doc doesn't weem right to me - keep the original docs authoritative, and, as Pekka suggests, review these where necessary in light of experience). 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 Nov 19 05:15:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDFVkd007059; Tue, 19 Nov 2002 05:15:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJDFVii007058; Tue, 19 Nov 2002 05:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDFSkd007051 for ; Tue, 19 Nov 2002 05:15:28 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJDFbMq022365 for ; Tue, 19 Nov 2002 05:15:37 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19939 for ; Tue, 19 Nov 2002 05:15:31 -0800 (PST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA18619 for ; Tue, 19 Nov 2002 13:15:30 GMT Received: from login.ecs.soton.ac.uk (IDENT:lFswwCrkntp9nn/yH1BV9v42NbeAKGlW@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAJDFOWX001878 for ; Tue, 19 Nov 2002 13:15:24 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gAJDFOG07253 for ipng@sunroof.eng.sun.com; Tue, 19 Nov 2002 13:15:24 GMT Date: Tue, 19 Nov 2002 13:15:24 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up Message-ID: <20021119131524.GB7154@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <200211190349.WAA10024@ss10.danlan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211190349.WAA10024@ss10.danlan.com> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Nov 18, 2002 at 10:49:42PM -0500, Dan Lanciani wrote: > > We have always been told that stable global v6 addresses will not be available > to end users, or at least will not be available to end users at a low cost. Told by who? I can see ISPs wanting to charge for extra services where they can, and thus for a static /48 as they do now for a static single IPv4 address. But I would hope that enough ISPs would offer free static /48's to take custom from those who charge. The only "snag" is that such ISPs with 10M customers would need a lot more than a /32, esp. taking into account the HD-ratio. 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 Nov 19 05:16:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDGMkd007092; Tue, 19 Nov 2002 05:16:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJDGMIG007091; Tue, 19 Nov 2002 05:16:22 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDGIkd007083 for ; Tue, 19 Nov 2002 05:16:18 -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 gAJDGJH03869; Tue, 19 Nov 2002 14:16:20 +0100 (MET) Date: Tue, 19 Nov 2002 14:05:32 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: MIPv6 and ND value changes To: john.loughney@nokia.com Cc: Erik.Nordmark@Sun.COM, pekkas@netcore.fi, 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, perhaps my comment is a bit naive, but as the changes have been > discussed in the MIP WG and many people think the changes are > sane in the IPv6 WG ... I wonder what would be accomplished by > breaking them out in a seperate document. Since the IPv6 > WG will be working updating ND, could not the MIPv6 draft > make the recommendations and then these recomentations be taken > as the starting point for the ND discussions in the IETF? I can see a focused technical discussion on a small problem statement and a short document can actually result in better technical solutions. For instance, instead of changing the fixed rate limit for solicited RAs it make be a lot better to rate limit RAs using a token bucket filter. That can handle the rate limiting when a bunch of machines that boot after a power failure while still being very responsive to MNs that send RSs to detect movement. Also, it makes sense to point out that in the case where all the MNs can get a link up/down indication there isn't a need to waste the bandwidth of the frequent unsolicited RAs but instead rely on the MN sending an RS then the link up indication shows up. The point is that we could discuss the above agaist the MIPv6 spec, but that would delay the spec. If it was a separate 3 page spec we could do the technically right thing without worrying about MIPv6 spec delays. 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 Nov 19 05:16:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDGSkd007101; Tue, 19 Nov 2002 05:16:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJDGR39007100; Tue, 19 Nov 2002 05:16:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDGLkd007090 for ; Tue, 19 Nov 2002 05:16:22 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAJDGOH03873; Tue, 19 Nov 2002 14:16:25 +0100 (MET) Date: Tue, 19 Nov 2002 14:07:14 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: MIPv6 and ND value changes To: Charlie Perkins Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3DD9B77C.1380EE4@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 > I am particularly concerned that we have a Mobile IPv6 specification > that, when implemented, gives sensible results. Eliminating the possibility > for having faster router advertisements does not give sensible results. I don't want to eliminate it - I want to make it better. But the fear of trying to make it better will further delay the MIPv6 specification makes me not want to bring up those issues. 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 Nov 19 05:22:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDMmkd007339; Tue, 19 Nov 2002 05:22:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJDMmAK007338; Tue, 19 Nov 2002 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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDMjkd007331 for ; Tue, 19 Nov 2002 05:22:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJDMsMq023506 for ; Tue, 19 Nov 2002 05:22:54 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA12709 for ; Tue, 19 Nov 2002 06:22:48 -0700 (MST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gAJDMi4s083778; Tue, 19 Nov 2002 08:22:44 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-207-180.mts.ibm.com [9.65.207.180]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAJDMg6N111280; Tue, 19 Nov 2002 08:22:42 -0500 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id gAJDM8j06723; Tue, 19 Nov 2002 08:22:08 -0500 Message-Id: <200211191322.gAJDM8j06723@cichlid.adsl.duke.edu> To: Charlie Perkins cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes In-Reply-To: Message from Charlie Perkins of "Mon, 18 Nov 2002 20:01:00 PST." <3DD9B77C.1380EE4@iprg.nokia.com> Date: Tue, 19 Nov 2002 08:22:08 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, > I am particularly concerned that we have a Mobile IPv6 specification > that, when implemented, gives sensible results. Eliminating the possibility > for having faster router advertisements does not give sensible > results. Noone is arguing that the possibility for having faster RA should be eliminated, at least as far as I know. It is not, IMO, critical that these changes be in the same document as the base MIPv6 spec. What is important that these ND changes become an RFC within a reasonable amount of time, so that those that implement MIPv6 also pick up the ND changes in the same general time frame. I see no reason why this can't happen within 6 months. 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 Tue Nov 19 05:28:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDSKkd007465; Tue, 19 Nov 2002 05:28:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJDSKWP007464; Tue, 19 Nov 2002 05:28:20 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDSFkd007457 for ; Tue, 19 Nov 2002 05:28:16 -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 gAJDSIH04997; Tue, 19 Nov 2002 14:28:18 +0100 (MET) Date: Tue, 19 Nov 2002 14:25:08 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: MIPv6 and ND value changes To: "Bound, Jim" Cc: Erik Nordmark , Pekka Savola , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <9C422444DE99BC46B3AD3C6EAFC9711B02BE9B9C@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Missed my point. You can't implement part of ND for a feature like MIPv6. > You have to understand ND as a software engineer. Understood. But there are different boxes that need to implement different things. Home agents need to implement the 'H' bit in the RA and the 'R' bit in the prefix info option in order to support HA discovery, etc. And MNs need the RS changes for faster movement detection, etc. And the key thing in my opinion is that the (access) routers need to implement the faster RA and the advertisement interval option. Thus the folks that implement routers need to implement all of ND (as software engineers) but they probably don't need all of the MIPv6 extensions to ND. 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 Nov 19 05:31:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDVNkd007556; Tue, 19 Nov 2002 05:31:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJDVNm7007555; Tue, 19 Nov 2002 05:31: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDVJkd007545 for ; Tue, 19 Nov 2002 05:31:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJDVRbB002384 for ; Tue, 19 Nov 2002 05:31:28 -0800 (PST) Received: from starfruit.itojun.org (dhcp-204-42-71-254.ietf55.ops.ietf.org [204.42.71.254]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00496 for ; Tue, 19 Nov 2002 06:31:18 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 058947AF; Tue, 19 Nov 2002 22:30:59 +0900 (JST) To: Tim Chown Cc: ipng@sunroof.eng.sun.com In-reply-to: tjc's message of Tue, 19 Nov 2002 13:11:42 GMT. <20021119131142.GA7154@login.ecs.soton.ac.uk> 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: RFC3041 privacy extension in nodereq From: Jun-ichiro itojun Hagino Date: Tue, 19 Nov 2002 22:30:59 +0900 Message-Id: <20021119133100.058947AF@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> > conditions where the spec is appropriate >> > are spelled out enough in RFC3041. >> Actually, they definitely *aren't* (or rather, they give a wrong >> impression), see draft-dupont-ipv6-rfc3041harmful-01.txt -- new security >> considerations / applicability consideration is needed. >I agree with Pekka. ok, then (1) we need 3041bis, and (2) node requirement may want to refer dupont-3041harmful too. 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 Nov 19 05:40:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDemkd007713; Tue, 19 Nov 2002 05:40:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJDemKr007712; Tue, 19 Nov 2002 05:40: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJDejkd007705 for ; Tue, 19 Nov 2002 05:40:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJDesbB003807 for ; Tue, 19 Nov 2002 05:40:54 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05136 for ; Tue, 19 Nov 2002 06:40:48 -0700 (MST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJDeGO28853 for ; Tue, 19 Nov 2002 15:40:16 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Nov 2002 15:40:47 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 15:40:47 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 19 Nov 2002 15:40:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MIPv6 and ND value changes Date: Tue, 19 Nov 2002 15:40:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv6 and ND value changes Thread-Index: AcKPycILY+M5d9+pQ52O5qZog8TlNwAByvDw To: Cc: X-OriginalArrivalTime: 19 Nov 2002 13:40:46.0991 (UTC) FILETIME=[43E679F0:01C28FD1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJDejkd007706 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi James, > The primary issue is whether the ND spec itself should benefit. I agree. I think it should. My suggestion is that MIPv6 discusses what is needed for MIPv6 (maybe even moved into an appendix) and this data is taken as a starting point for updating 2461. > The behavior of DAD failure is an example. RFC 2461 currently has a built-in DoS > hole in that it specifies the host should shut down the interface if there is a > DAD failure. This is a perfect opportunity for propagating a successful DoS > attack, and is not restricted to MIP. I agree. > By burying the solution for this into the MIP spec, it > removes the possibility that wider IPv6 nodes can benefit. I don't think we should bury it in the MIP spec, but first address it in the MIPv6 spec then take that & move it into a 2461-bis draft. > However, there are other proposed ND optimizations that are purely mobile > specific. Some of these are in the MIP spec, some aren't. I think it makes some > sense to group these into a seperate spec in the MIP group. Why can't it be in MIPv6 & then moved in the 2461-bis? 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 Nov 19 06:17:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJEHdkd007947; Tue, 19 Nov 2002 06:17:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJEHcxN007943; Tue, 19 Nov 2002 06:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJEHYkd007932 for ; Tue, 19 Nov 2002 06:17:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJEHhbB009348 for ; Tue, 19 Nov 2002 06:17:44 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02941; Tue, 19 Nov 2002 07:17:37 -0700 (MST) 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 GAA07753; Tue, 19 Nov 2002 06:17:37 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAJEHae11080; Tue, 19 Nov 2002 06:17:36 -0800 X-mProtect: <200211191417> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.181, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpqfqEL; Tue, 19 Nov 2002 06:17:33 PST Message-ID: <3DDA47B9.F1C4E2BC@iprg.nokia.com> Date: Tue, 19 Nov 2002 06:16:25 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Erik, No one should fear making the technology better. However, having a specification that gives sensible results does not in any way impede that effort. If Mobile IPv6 specifies something, that something can be taken in to account in any future specification. I can't see how it would possibly take away anything from the future to have things working sensibly in the present time. Regards, Charlie P. Erik Nordmark wrote: > > I am particularly concerned that we have a Mobile IPv6 specification > > that, when implemented, gives sensible results. Eliminating the possibility > > for having faster router advertisements does not give sensible results. > > I don't want to eliminate it - I want to make it better. > But the fear of trying to make it better will further delay the MIPv6 > specification makes me not want to bring up those issues. > > 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 Nov 19 06:24:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJEOvkd008011; Tue, 19 Nov 2002 06:24:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJEOvbY008010; Tue, 19 Nov 2002 06:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJEOqkd008003 for ; Tue, 19 Nov 2002 06:24:52 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJEP2Mq006879 for ; Tue, 19 Nov 2002 06:25:02 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26089 for ; Tue, 19 Nov 2002 06:24:57 -0800 (PST) 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 GAA07899; Tue, 19 Nov 2002 06:24:56 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAJEOu214671; Tue, 19 Nov 2002 06:24:56 -0800 X-mProtect: <200211191424> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.181, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdx3d0jb; Tue, 19 Nov 2002 06:24:52 PST Message-ID: <3DDA4971.C03B37DE@iprg.nokia.com> Date: Tue, 19 Nov 2002 06:23:45 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: ipng@sunroof.eng.sun.com Subject: Specifically about frequencey of router advertisements References: <200211191322.gAJDM8j06723@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Thomas, You seem to be concerned that if we change this value in the base Mobile IPv6 specification, then suddenly it won't make as much sense to change it or otherwise specify it in a future ND document. I think that it patently untrue. So, I strongly believe that we can have a good base Mobile IPv6 specification that works, without impeding future progress on more general ND solutions. Why not? Thomas Narten wrote: > Charlie, > > > I am particularly concerned that we have a Mobile IPv6 specification > > that, when implemented, gives sensible results. Eliminating the possibility > > for having faster router advertisements does not give sensible > > results. > > Noone is arguing that the possibility for having faster RA should be > eliminated, at least as far as I know. Then let's keep a sentence in the specification that makes this plain. It would not impede progress on ND. > It is not, IMO, critical that these changes be in the same document as > the base MIPv6 spec. It is critical for the one change for frequency of router advertisement. > What is important that these ND changes become an > RFC within a reasonable amount of time, so that those that implement > MIPv6 also pick up the ND changes in the same general time frame. I > see no reason why this can't happen within 6 months. I think 6 days would be better for the particular point about router advertisement. I'm classifying that differently, because it is required for sensible implementations. If you want that one in a separate document, then I can have it for you on Saturday. I'm concerned, though, that the document would be viewed as a place to put other things that aren't so plainly required. 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 Nov 19 06:37:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJEb9kd008199; Tue, 19 Nov 2002 06:37:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJEb96o008198; Tue, 19 Nov 2002 06:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJEb5kd008191 for ; Tue, 19 Nov 2002 06:37:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJEbEMq008996 for ; Tue, 19 Nov 2002 06:37:14 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03015 for ; Tue, 19 Nov 2002 07:37:09 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 1F0078E91; Tue, 19 Nov 2002 09:37:06 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Nov 2002 09:37:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: MIPv6 and ND value changes Date: Tue, 19 Nov 2002 09:37:05 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9BA7@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv6 and ND value changes Thread-Index: AcKPznLrd2tKKP1LS0i77YG5Hj/cegAClPFQ From: "Bound, Jim" To: "Erik Nordmark" , "Charlie Perkins" Cc: X-OriginalArrivalTime: 19 Nov 2002 14:37:05.0990 (UTC) FILETIME=[21F0CE60:01C28FD9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJEb6kd008192 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, What you bring up hard rate limit vs token bucket filter and the like are optimizations not brokeness in MIPv6 and so is the idea of a separate spec. We can always optimize and continue to optimize etc. Leaving it in the current spec does not remove the potential for optimization. Taking it out may cause MIPv6 to not ship. I am for shipping unless there is a well known interoeperable problem. Lets be consistent on the rules and not make them up all the time as we go it is impossible to expect us the worker bees to keep up with moving targets. Ship the spec. /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@Sun.COM] > Sent: Tuesday, November 19, 2002 8:07 AM > To: Charlie Perkins > Cc: Erik Nordmark; ipng@sunroof.eng.sun.com > Subject: Re: MIPv6 and ND value changes > > > > I am particularly concerned that we have a Mobile IPv6 > specification > > that, when implemented, gives sensible results. Eliminating the > > possibility for having faster router advertisements does not give > > sensible results. > > I don't want to eliminate it - I want to make it better. > But the fear of trying to make it better will further delay the MIPv6 > specification makes me not want to bring up those issues. > > 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 Tue Nov 19 06:41:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJEfXkd008248; Tue, 19 Nov 2002 06:41:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJEfXVa008247; Tue, 19 Nov 2002 06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJEfRkd008240 for ; Tue, 19 Nov 2002 06:41:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJEfabB013522 for ; Tue, 19 Nov 2002 06:41:36 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05508 for ; Tue, 19 Nov 2002 07:41:30 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 2AE79B4D; Tue, 19 Nov 2002 09:41:30 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Nov 2002 09:41:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: MIPv6 and ND value changes Date: Tue, 19 Nov 2002 09:41:29 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240C3C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv6 and ND value changes Thread-Index: AcKPz5zTasIoyFxxQF+DAE8bDvaJbgACZODQ From: "Bound, Jim" To: "Erik Nordmark" Cc: "Pekka Savola" , X-OriginalArrivalTime: 19 Nov 2002 14:41:29.0871 (UTC) FILETIME=[BF39D9F0:01C28FD9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJEfUkd008241 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > And the key thing in my opinion is that the (access) routers > need to implement the faster RA and the advertisement > interval option. Thus the folks that implement routers need > to implement all of ND (as software engineers) but they > probably don't need all of the MIPv6 extensions to ND. I agree but why do we have to fix this right now. I would argue it can be resolved later and this is something we all knew before now. If we ship the spec and then update it into parts with multiple drafts to PS that will work. But the market needs a PS now and so does technolgy sector in industry. We appease that need and work to make it better or to optimize. That IMO is what PS is all about. What am I missing. P.s. I know you're an implementor and I understand that OK. I agree with you but think about the time when a manager had to tell someone on the team in engineering "look I know we can fine tune this but we got to ship this to the release pool on Monday". That is where I am coming from not disagreeing with your optimizations. Thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 07:08:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJF8Kkd008459; Tue, 19 Nov 2002 07:08:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJF8JpZ008458; Tue, 19 Nov 2002 07: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJF8Gkd008451 for ; Tue, 19 Nov 2002 07:08:16 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJF8PMq014895 for ; Tue, 19 Nov 2002 07:08:25 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22900 for ; Tue, 19 Nov 2002 08:08:18 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAJF8C331752; Tue, 19 Nov 2002 17:08:12 +0200 Date: Tue, 19 Nov 2002 17:08:12 +0200 (EET) From: Pekka Savola To: john.loughney@nokia.com cc: kempf@docomolabs-usa.com, Subject: RE: MIPv6 and ND value changes 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, 19 Nov 2002 john.loughney@nokia.com wrote: > > By burying the solution for this into the MIP spec, it > > removes the possibility that wider IPv6 nodes can benefit. > > I don't think we should bury it in the MIP spec, but first > address it in the MIPv6 spec then take that & move it into a > 2461-bis draft. I don't think waiting for 2461-bis is the right approach, rather a draft pushed through in mobileip wg. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 07:09:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJF9xkd008474; Tue, 19 Nov 2002 07:09:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJF9xhf008473; Tue, 19 Nov 2002 07:09:59 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJF9skd008466 for ; Tue, 19 Nov 2002 07:09:54 -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 gAJF9sH14764; Tue, 19 Nov 2002 16:09:54 +0100 (MET) Date: Tue, 19 Nov 2002 15:28:16 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Proposal for site-local clean-up To: Brian Zill Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I agree with this. However, the minimal degree of robustness is working > at all - something which requires some address of some sort. There > needs to be a way to get an address when you don't have a provider. > This means either scoped addresses as we have defined them already (and > in multi-link locations, this means either site-local or multi-link > subnet routers and link-local), or some sort of provider-independent > address (note there are various types of these as well, depending upon > whether we believe they should be explicity non-routable, or privately > routable between multiple non-connected 'sites'). For the disconnected site I think the site-locals work just fine, and I haven't seen any strong arguments against using site-locals for a disconnected site. As many others have pointed out the complexity is not associated with the case of the disconnected site. > Regarding leakage of non-global scope addresses, I don't see this as a > major problem given the way our current scoped addresses are defined. > Having an explicit prefix makes it straight-forward for border routers > to filter them. True for IP packets which is not my concern; the leakage is likely to happen in higher-level protocols. We don't want the router to filter or modify those. > The scope-id in the sockaddr field makes it easy for > applications to know on which interfaces an address is usable and to > whom it is legit to pass (something that isn't true for the 169.254.x.x > "link-local" addresses in v4 today). I'd be more worried about leakage > of provider-independent addresses which don't share an explicitly > non-routable prefix. The scope-id makes it possible, which is very good, but it doesn't make it easy IMHO. As an example of what every application needs to do you can talk to the folks that did the work for SCTP (not that SCTP is an application, but it does pass IP addresses around when establishing connections to be able to use alternate paths). My understand is that understanding what needs to be done with limited scope IPv6 addresses was a major complicating factor in this work. We can get such things to be done well for work done in the IETF even if it is extra work. But for applications developped all over the planet I'm far from convinced that they will provide robust solutions when there is a combination of site-local and global addresses. > As I mentioned in my last message on this topic, I believe a lot of the > argument around site-locals is really about expected usage models. > Personally, I would expect the opposite of what you say above. Home > users watching a movie on their IPv6-enabled television screen in the > living room (which is streaming in from the media server in their > basement) won't be happy if their movie quits because their kid just > dialed into the Internet and the resulting global address advertisment > required all site-local communication to stop. Nor will they be happy is the download of the move in the afternoon didn't happen because the L2 link dropped and got restablished with different IPv6 addresses. If the ISP provide the disservice of unstable IP addresses I think we have a large class of problems. The fact that site-local addresses might ameliorate some of those problems doesn't magically make such ISP disservice useful. > More generally, I don't want IPv6 to be just for the Internet. If we've > done it right, IPv6 will be used for all sorts of communication between > lots of devices which typically don't have network connectivity today. > I'm worried that this working group too often sees things in terms of > only traditional computers as the hosts, and the routers all belonging > to organizations which have administrators to run them. We shouldn't > try to dumb down IPv6 so that it only works well in the environment IPv4 > was conceived in. I think it is fine to use IP technology outside the global Internet. It might even be fine to subset the IP technology to do this. But what doesn't make sense in my mind is to have the desire to use IP technology outside of the global Internet cause significant additional complexity in the technology. > Yes, needless complexity is bad. But site-locals don't add any > significant complexity to applications (which I think I've demonstated > enough in too many emails already). Time to agree that we disagree on this point. (Unless you are talking about site-locals being restricted to the disconnected site case.) > Many existing IPv4-only sites run > two-faced DNS today, so there clearly are people out there who think it > is worth it for reasons that have nothing to do with IPv6. If we think > that's not optimal, we should be thinking about figuring out why they > run their IPv4 networks that way today and come up with a better > solution for them using IPv6. I think, but I'm not certain, that most of the large sites that do this have completely different DNS content in the two-faces i.e. it is more like two separate DNS services than two-faces of the same DNS database. That is, the DNS outside the firewall contain a subset of the RRs and names, and there isn't necessarily a dynamic update path between the two DNSes. Do you have examples of folks that have small setups of two-faced DNS where e.g. dynamic DNS update works while still keeping site-locals on the inside and global addresses visible through both faces? > > So let's not loose sight of the fact that the > > goal is a robust network. > > Sure. And scoped addresses have the potential to make the network more > robust (I'd say that link-locals have already proved their worth in this > regard). I must have missed the proof. Do you have a pointer to something which captures normal users, dynamic DNS update, application development handling multiple concurrent scopes, etc? 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 Nov 19 07:46:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJFkukd008894; Tue, 19 Nov 2002 07:46:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJFkufC008893; Tue, 19 Nov 2002 07:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJFkqkd008886 for ; Tue, 19 Nov 2002 07:46:53 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJFl1Mq023575 for ; Tue, 19 Nov 2002 07:47:01 -0800 (PST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20673 for ; Tue, 19 Nov 2002 08:46:55 -0700 (MST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAJFkhC3079140; Tue, 19 Nov 2002 16:46:47 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAJFkgnb029418; Tue, 19 Nov 2002 16:46:42 +0100 Received: from [9.29.3.173] by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA67812 from ; Tue, 19 Nov 2002 16:46:37 +0100 Message-Id: <3DDA5CC9.94BADD97@hursley.ibm.com> Date: Tue, 19 Nov 2002 16:46:17 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp Cc: narten@us.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Resend: Re: rfc2553bis-07 to rfc2553bis-08 changes References: <200211051903.gA5J3wx0001145948@anw.zk3.dec.com> <200211061844.gA6Iina17496@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm reluctant to reach any conclusion about this until we have complete clarity about the flow label, which as we concluded yesterday still needs more work. So I think that the current (ambiguous) text is probably OK for now. I'm afraid it will need revisiting at some time in the future. Brian JINMEI Tatuya / $B?@L@C#:H(B wrote: > > Unless I've missed something, I've not received any responses to the > attached message. I interpreted the silence as a sign that there is > no need to update 2292bis wrt the issues in this thread. Otherwise, > please let me know. > > Thanks, > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > -------------------------------------------------------------------------------------------------------------------------------- > > Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes > Date: Fri, 08 Nov 2002 20:51:38 +0900 > From: JINMEI Tatuya / $B?@L@C#:H(B > Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. > To: Thomas Narten > CC: ipng@sunroof.eng.sun.com > References: > <200211051903.gA5J3wx0001145948@anw.zk3.dec.com> > <200211061844.gA6Iina17496@rotala.raleigh.ibm.com> > > >>>>> On Wed, 06 Nov 2002 13:44:49 -0500, > >>>>> Thomas Narten said: > > > With regards to the basic API: > > > - Will we want the basic API to ever allow a way to specify the > > Traffic Class? If so, will it be better to define a new extension or > > to overload the Flow Label? > > > - Should we point out that some previous versions of the basic API > > copied both traffic class and flow label info into packets and that > > this is now beleived to be wrong and should be fixed? > > > I'm OK with either saying setting the Traffic Class through the basic > > API won't be done in the future, or saying it can be added but in a > > way that is completely backwards compatable and will work smoothly > > with 2292bis (assuming we need two ways of setting the bits). > > I personally prefer to deprecate the access to Traffic Class by the > sin6_flowinfo field (i.e. by the basic API), because > > - it (of course) makes the (future) API simple. > - as far as I know, there should be very few (or even no) applications > that rely on the feature. so the backward compatibility issue > should be not so serious. > > I know opinions on the compatibility often varies, and I'm open to > others' opinions. > > > Then there is the Advanced API. Again, from Bill: > > > Bill Fenner writes: > > >> I am still concerned about the interaction between 2292bis's IPV6_TCLASS > >> and these implementations, but perhaps we should let 2553bis go with the > >> "not currently specified" wording and make the interaction clear in > >> 2292bis? (Has the WG as a whole had a chance to see the suggesiton of > >> leaving sin6_flowinfo simply unspecified?) > > > 2292 doesn't address the flow label. But it does have a way of setting > > the Traffic Class. But it doesn't mention how it interacts with > > Traffic Class settings via the (old) basic APIs. If the intention is > > that the old ways are invalid, and that one only sets traffic class > > through the advanced API, I think the current approach is fine. Is > > that what folks are thinking here? > > Excuse me, what do you mean by "the current approach"? Do you mean > that "2292bis has a way of setting the traffic class but it doesn't > mention the interaction with the (old) basic API"? > > If so, and assuming we agree on deprecating this part of the basic > API, I agree. > > However, if our consensus is that some backward compatibility should > be provided, I guess 2292bis needs to talk about the interaction. > > > Finally, 2292bis seems to assume the Traffic Class is 8 bits in > > size. It's not any more. It's 6 bits, with the ECN bits explicitly a > > separate field. So perhaps 2292bis should be updated to reflect the > > new size and have separate way of setting the ECN bits? Or at least, > > the text should make it clear how one sets one and not the other, etc. > > (this was discussed before at least partly, but) > I believe 2292bis clearly separates the notion of (6-bit) traffic > class and 2-bit ECN. For example, section 6.5 contains the following > sentences: > > Returning the received traffic class is useful for > programs such as a diffserv debugging tool and for user level ECN > (explicit congestion notification) implementation. > > An example is an implementation of ECN in the kernel, > setting 2 bits of the traffic class value. > > The confusing part would be wording such as "traffic class" (assuming > 8 bits) or the socket option name IPV6_TCLASS. In this sense, the > comment for the ip6_un1_flow field of the ip6_hdr structure would also > be confusing: > > uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC, 20 bits flow-ID */ > > As I responded before, I personally think the current wording is > okay. However, if there's a strong demand to clarify this much more, > I'd propose to add a note like this: > > [RFC-3260] separates an 8-bit field of the IPv6 header, which was > originally called a single "traffic class" field, into a 6-bit DS > field and a 2-bit ECN field. However, since this API only provides a > single way to get access to the whole 8 bits, the previous terminology > "traffic class" will be used to specify the whole bits within this > document. > > Does this make sense? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate X-Mozilla-Status: 0009rp. > 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 Nov 19 08:06:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJG6ikd009271; Tue, 19 Nov 2002 08:06:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJG6hdS009270; Tue, 19 Nov 2002 08:06:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJG6dkd009263 for ; Tue, 19 Nov 2002 08:06:40 -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 gAJG6XH21124; Tue, 19 Nov 2002 17:06:33 +0100 (MET) Date: Tue, 19 Nov 2002 16:33:22 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: MIPv6 and ND value changes To: "Bound, Jim" Cc: Erik Nordmark , Charlie Perkins , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <9C422444DE99BC46B3AD3C6EAFC9711B02BE9BA7@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Leaving it in the current spec does not remove the potential for > optimization. Doing local optimizations to a specification which is 150 pages might be possible yet it is painful. > Taking it out may cause MIPv6 to not ship. Making the RFC not ship? Or making something else not ship? The spec would not have a problem shipping without the 2-3 pages we are talking about. And getting better ND support (or other movement detection/handover tweaks) is something that I think makes sense to do relatively quickly (as in the next few months). Having it be in the gigantic spec makes this utterly hard. 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 Nov 19 08:21:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJGL7kd009446; Tue, 19 Nov 2002 08:21:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJGL7Te009445; Tue, 19 Nov 2002 08:21: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJGL3kd009438 for ; Tue, 19 Nov 2002 08:21:03 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJGLCbB004749 for ; Tue, 19 Nov 2002 08:21:12 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23155 for ; Tue, 19 Nov 2002 09:21:04 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAJGKul29607; Tue, 19 Nov 2002 11:20:56 -0500 (EST) Message-Id: <200211191620.gAJGKul29607@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Mon, 18 Nov 2002 22:49:42 EST.") <200211190349.WAA10024@ss10.danlan.com> Date: Tue, 19 Nov 2002 11:20:56 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Erik Nordmark wrote: > > |Being the probable guilty party for introducing this thought back in > |draft-*-site-prefixes-00.txt I can offer a slightly expanded perspective. > | > |I don't think stable addresses per se is the key thing - it is > |the robustness of the communication that is important. > > |This robustness has at least two factors that are relevant in this > |discussion: the stability of the addresses, and the leakage of > |non-global scope addresses. I think the question is how to weigh those > |together. > > Ok, but it isn't clear that these two factors are of even remotely similar > weight. Leakage is a problem that can be addressed, but there are a lot of > things that simply will not work without stable addresses (at least not > without a complete overhaul of many higher-level protocols). Agreed that stable addresses are necessary, but experience suggests that it is very difficult to 'address' leakage of addresses. Every application is another path by which addresses can be leaked. For that matter, so is every mobile host. > |In terms of the stability of the addresses one has to take into account > |both stability as it relates to local communication and stability for > |global communication. > > We have always been told that stable global v6 addresses will not be available > to end users, or at least will not be available to end users at a low cost. I think this depends on what you mean by "stable". For some reason the community has been reluctant to specify a number here, and the result is that people have widely varying ideas about what we can expect in practice. I don't think we want to let the reliable operation of applications be an accident, nor do I think we want to trust market forces to sort this out. > Unless you are proposing to revise the whole address allocation architecture > *and* have a way to force ISPs to change their business models I think we must > accept this as a given. I don't think it's necessary to "force" anything, and casting things in these terms makes them seem more difficult than they really are. > I think you have made an unreasonable leap by dropping the "stable" qualifier. > The value/importance of _stable_ local communication is almost certainly much > higher than the value/importance of _stable_ global communication. No. You erroneously assume that different applications are used for local and global communications, and you are over-generalizing the case for stable global communications from two very specific cases. Too many people think that the Internet only needs to support web and email. If that were the case we wouldn't need IPv6 at all. The 'local' versus 'global' distinction is a false one. I run NFS over TCP over IPv6 over long distances, and it works. And yes, I'm screwed if my ISP changes my IP address (fortunately they have agreed to not do that). I also regularly send print jobs over the same connection. > |In any case, for a home user I suspect that the value/importance of > |local communication would typically be less than the value/importance > |of global communication. > > Again assuming we are talking about _stable_ communication, I believe that > you are incorrect. Granted those of us who depend on our home networks for > automation and such are currently on the bleeding edge, but what about the > future when every stereo and tv is on the net? It's one thing to have to > re-click that remote link in the browser, but quite another to have your > stereo refuse to change channels. Consumers are not going to pay their ISP > a premium to keep their stereos working. I know it sounds nice in theory, > but look what happened to Divx. If you take away scoped addressing we _will_ > use NAT. Threatening to destroy the utility of IPv6 if you don't get your way won't get you much support here. Perhaps you should take another tack. > I'm having trouble parsing the above. ISPs currently offer unstable v4 > addresses (unless you pay extra) and they aren't satisfactory for the > peer-to-peer communication we used to have back when address space was > portable. People have worked around this with various application-level > kludges. You obviously recognize that stable addresses have value, so > I don't understand why you expect that ISPs will suddenly stop charging for > that value. I don't understand why you expect that ISPs will treat v6 exactly the same as v4, when if they do it this way there is no reason for their customers to pay for this additional service. perhaps ISPs will charge more for v6 than for v4, and they'l claim that they're doing so because v6 addresses are stable. > Depriving users of the tools necessary to make productive use > of their networks without paying for stable globals for all internal nodes > will just encourage yet another round of kludges. Bottom line is that we need addresses to be (reasonably) stable at both the local and the global level. It's not sufficient to just have stable local addresses - especially given the problems that SLs cause. > |So let's not loose sight of the fact that the goal is a robust network. > > I think that the goal is a useful network--useful not only for ISPs and > application vendors but for consumers. I don't think anyone would disagree with that - but that doesn't mean that a network with SLs is more reliable/useful than one without. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 08:26:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJGQ2kd009505; Tue, 19 Nov 2002 08:26:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJGQ2C8009504; Tue, 19 Nov 2002 08:26: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJGPwkd009497 for ; Tue, 19 Nov 2002 08:25:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJGQ7Mq003372 for ; Tue, 19 Nov 2002 08:26:07 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27045 for ; Tue, 19 Nov 2002 09:26:02 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAJGQ0l29641; Tue, 19 Nov 2002 11:26:00 -0500 (EST) Message-Id: <200211191626.gAJGQ0l29641@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Brian Zill" cc: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Mon, 18 Nov 2002 22:37:05 PST.") Date: Tue, 19 Nov 2002 11:26:00 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes, needless complexity is bad. But site-locals don't add any > significant complexity to applications (which I think I've demonstated > enough in too many emails already). this is only true if globals are always available to any node that potentially participates in an application that communicates off-site - which essentially means any node in any network which has an external connection. in other words, it's not that the problems with SLs can't be minimized by imposing a discipline on their use - it's that too many people want to use SLs in too many different ways to allow that to happen in 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 Tue Nov 19 08:36:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJGaNkd009626; Tue, 19 Nov 2002 08:36:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJGaNLF009625; Tue, 19 Nov 2002 08:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJGaKkd009618 for ; Tue, 19 Nov 2002 08:36:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJGaTMq005828 for ; Tue, 19 Nov 2002 08:36:29 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01749 for ; Tue, 19 Nov 2002 09:36:17 -0700 (MST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D5E60AE4 for ; Tue, 19 Nov 2002 11:36:15 -0500 (EST) Received: from hp.com (whitestar.zk3.dec.com [16.140.64.49]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 9F2FF1083; Tue, 19 Nov 2002 11:36:15 -0500 (EST) Message-ID: <3DDA687F.7030805@hp.com> Date: Tue, 19 Nov 2002 11:36:15 -0500 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: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello I belive that some ND changes have to remain in the MIPv6 spec. The ND changes without which the base MIPv6 spec is incomplete and can not be made to work well should remain in the spec. An example of this is RA timers. Without faster RAs, the movement detection algorithm takes way to much time to be effective. Yes, there are better ways to do this and once they are specified, they can be implemented and deployed. However, without decent movement detection, the base spec is incomplete. On the other hand, other changes (such as what to do on DAD collision) apply to more the just mobility cases and would provide greater benefit as separete specs. Just my $0.02 -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead 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 Tue Nov 19 08:52:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJGqGkd009780; Tue, 19 Nov 2002 08:52:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJGqF3n009779; Tue, 19 Nov 2002 08:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJGqCkd009772 for ; Tue, 19 Nov 2002 08:52:12 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJGqMMq009564 for ; Tue, 19 Nov 2002 08:52:22 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14361 for ; Tue, 19 Nov 2002 08:52:16 -0800 (PST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAJGqFKV027425 for ; Tue, 19 Nov 2002 17:52:15 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 19 Nov 2002 17:52:15 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0D1A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: ipng@sunroof.eng.sun.com Subject: RE: MIPv6 and ND value changes Date: Tue, 19 Nov 2002 17:52:13 +0100 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 I'm getting very confused when reading this discussion. Some people are focusing on the RA intervals, others about DAD (2462) and others talk generally about ND. Please divide the issues... AFAIK we have the following (independent) issues: - RA intervals were reduced by MIPv6 (changing 2461) - When DAD fails we configure a new address and try again (2462) - Elimination of DAD delays (optimistic DAD) - Eliminsation of the random delay before sending an RA (fast RA) The last two bullets are addressed in separate drafts. The first 2 bullets are in the MIPv6 spec, and the second bullet has nothing to do with 2461. There are different value for each point, they're all important, but let's not lump them all in one discussion. 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 Tue Nov 19 09:14:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJHEekd009985; Tue, 19 Nov 2002 09:14:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJHEeht009984; Tue, 19 Nov 2002 09:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJHEbkd009977 for ; Tue, 19 Nov 2002 09:14:37 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJHEkbB020073 for ; Tue, 19 Nov 2002 09:14:46 -0800 (PST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25148 for ; Tue, 19 Nov 2002 10:14:40 -0700 (MST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gAJHEam27362; Tue, 19 Nov 2002 18:14:36 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gAJHEate031549; Tue, 19 Nov 2002 18:14:36 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211191714.gAJHEate031549@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Bound, Jim" cc: "Pekka Savola" , "Vijay Devarapalli" , ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes In-reply-to: Your message of Mon, 18 Nov 2002 23:56:22 EST. <9C422444DE99BC46B3AD3C6EAFC9711B02BE9B9D@tayexc13.americas.cpqcorp.net> Date: Tue, 19 Nov 2002 18:14:36 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue79.txt I just want to point out that Francis and Vlad in the above both are implemetors ... => as my name occurs in this thread where my opinion is nicely represented by Erik, I often asked that the ND discussion was moved from the MIP list to the IPng/IPv6 list. About some points, IMHO the fast RA is not a good idea because its impact on a regular network can be very high. I can summarize this in RAs are not good beacons. But for instance the R bit (i.e., put the router address in place of the prefix) is a good thing, and not only in the MIPv6 context. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 09:36:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJHaVkd010106; Tue, 19 Nov 2002 09:36:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJHaVeG010105; Tue, 19 Nov 2002 09:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJHaSkd010098 for ; Tue, 19 Nov 2002 09:36:28 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJHabMq024206 for ; Tue, 19 Nov 2002 09:36:37 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16400 for ; Tue, 19 Nov 2002 09:36:32 -0800 (PST) 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 JAA16252; Tue, 19 Nov 2002 09:36:31 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAJHaT824195; Tue, 19 Nov 2002 09:36:29 -0800 X-mProtect: <200211191736> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrnYqOg; Tue, 19 Nov 2002 09:36:27 PST Message-ID: <3DDA769C.266DBE5@iprg.nokia.com> Date: Tue, 19 Nov 2002 09:36:28 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes References: <3DD9AD22.FBF2AFC1@iprg.nokia.com> <003f01c28fc8$63d6ae00$8f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, if you read my mail again, it was specifically a reply to Pekka. he called the changes arbitrary. that was really wrong. Vijay James Kempf wrote: > > Vijay, > > I think the issue isn't whether this particular optimization is important or > not. The issue is whether we should leave it in the base spec or put it into a > spec with all the other ND optimization bits. > > jak > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: "Pekka Savola" > Cc: > Sent: Monday, November 18, 2002 7:16 PM > Subject: Re: MIPv6 and ND value changes > > > Pekka Savola wrote: > > > > > > > > > > > > FWIW, I fully support Thomas Narten on his view that MIPv6 should not be > > > > making all of these assumptions to e.g. Neighbor Discovery timer values. > > > > > > s/assumptions/arbitrary changes/ > > > > on the contrary, they have been well thought out and discussed > > on the MIPv6 mailing list. take a look at the changes first. > > > > for example RFC 2462 says if DAD fails, the node SHOULD disable > > the interface. MIPv6 says if DAD fails, generate a random > > interface ID and try again. take a look at the following URL > > for the discussion. > > > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue79.txt > > > > can you give me one good reason why this change that MIPv6 > > recommends is arbitrary? come on..... > > > > Vijay > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Nov 19 09:47:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJHlNkd010258; Tue, 19 Nov 2002 09:47:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJHlN22010257; Tue, 19 Nov 2002 09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJHlKkd010250 for ; Tue, 19 Nov 2002 09:47:20 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJHlTMq027871 for ; Tue, 19 Nov 2002 09:47:29 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15135 for ; Tue, 19 Nov 2002 09:47:24 -0800 (PST) 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 JAA16672; Tue, 19 Nov 2002 09:47:23 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAJHlMH05422; Tue, 19 Nov 2002 09:47:22 -0800 X-mProtect: <200211191747> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPDrRxq; Tue, 19 Nov 2002 09:47:21 PST Message-ID: <3DDA7929.ADB66B44@iprg.nokia.com> Date: Tue, 19 Nov 2002 09:47:21 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: "Bound, Jim" , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes References: <200211191714.gAJHEate031549@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, Francis Dupont wrote: > > In your previous mail you wrote: > > > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue79.txt > > I just want to point out that Francis and Vlad in the above both are > implemetors ... > > => as my name occurs in this thread where my opinion is nicely represented > by Erik, I often asked that the ND discussion was moved from the MIP list > to the IPng/IPv6 list. > About some points, IMHO the fast RA is not a good idea because its impact > on a regular network can be very high. I can summarize this in RAs are MIPv6 does not say router should send RAs more frequently. it just says access routers SHOULD be configurable to send RAs more frequently. this is to be used in the absense of any L2 help. Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 10:03:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJI34kd010439; Tue, 19 Nov 2002 10:03:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJI3466010438; Tue, 19 Nov 2002 10:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJI31kd010431 for ; Tue, 19 Nov 2002 10:03:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJI3AMq003771 for ; Tue, 19 Nov 2002 10:03:10 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06741 for ; Tue, 19 Nov 2002 11:03:05 -0700 (MST) 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 JAA16944; Tue, 19 Nov 2002 09:53:04 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAJHr4e14339; Tue, 19 Nov 2002 09:53:04 -0800 X-mProtect: <200211191753> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGSvJUC; Tue, 19 Nov 2002 09:53:02 PST Message-ID: <3DDA7A7E.3AEB34BC@iprg.nokia.com> Date: Tue, 19 Nov 2002 09:53:02 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes References: <4DA6EA82906FD511BE2F00508BCF0538044F0D1A@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (EAB)" wrote: > > I'm getting very confused when reading this > discussion. Some people are focusing on the > RA intervals, others about DAD (2462) and > others talk generally about ND. > > Please divide the issues... > AFAIK we have the following (independent) issues: > > - RA intervals were reduced by MIPv6 (changing 2461) > - When DAD fails we configure a new address and try again (2462) > - Elimination of DAD delays (optimistic DAD) > - Eliminsation of the random delay before sending an RA (fast RA) > > The last two bullets are addressed in separate drafts. > The first 2 bullets are in the MIPv6 spec, and the > second bullet has nothing to do with 2461. I agree with Hesham. we should treat them as separate issues instead of lumping them all as ND changes. atleast bullets 1 and 2 should definitely be in the MIPv6 spec. Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 10:04:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJI4Okd010462; Tue, 19 Nov 2002 10:04:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJI4OYd010461; Tue, 19 Nov 2002 10:04:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJI4Lkd010454 for ; Tue, 19 Nov 2002 10:04:21 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJI4UbB005708 for ; Tue, 19 Nov 2002 10:04:30 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28909 for ; Tue, 19 Nov 2002 10:04:24 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1F5456A904 for ; Tue, 19 Nov 2002 20:04:22 +0200 (EET) Message-ID: <3DDA610D.9060001@kolumbus.fi> Date: Tue, 19 Nov 2002 18:04:29 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm trying to summarize the discussion about the constants. First I'd like to agree with Hesham: We need to treat the constants, optimistic DAD, collision detection all as separate items. What I see is that on most of the issues we are close to consensus, e.g. I don't think anyone is against moving all optimistic DAD ideas to a separate work item. For the constants: It seems like there's agreement that optimizations are needed. There is some disagreement about the type of most efficient optimizations. There's a big disagreement about where the optimizations should be done and when. The practical effect of these constants is that they affect the efficiency of movements. In particular: - If there are no indications from lower layers, it becomes slower to detect movement; from few tenths of a second to a second or several seconds. This has an impact to user perception, as well as TCP behaviour etc. - When there is an indication from lower layers, RA rate limitation may prevent sending RAs to all-nodes multicast address for many simultaneously moving mobiles. The net effect of this is slower establishment of communications for the mobile on the new link. As a result, most folks feel that we need new constant values that support mobility better. So: the issue isn't really about doing the optimizations or not, but where it is done. We have the following alternatives for moving forward on this issue: 1. Specify new constant values in Mipv6 spec. End of story. This is the approach taken in draft-mobileip-ipv6-19.txt. 2. Specify new constant values in Mipv6 spec, but start also an activity to come up with a separate constant adjustement document (either in MIP or IPv6 WGs). The document could specify just new constants, or it could also be a more general RA optimizations document, including other speed-up mechanisms. 3. Remove constant modifications from Mipv6 specification, and start an activity to come up with a separate constant adjustment document. This is the suggestion from the ADs. The following issues should be taken in account when deciding which alternative to pick: - Agreeing on the constant changes in draft 19 might delay Mipv6 specification. This includes the need to agree with the ADs that the constants belong to this document. - The creation of a separate document will take in account additional viewpoints and may thus consume some amount of time. - Some implementers have announced that they want solutions now for their products. - It is possible to use indications from lower layer to speed up movements, and this is in general more efficient than IP layer frequent multicast messages. - On the other hand, not all link layers and driver firmware support indications from lower layers. - Also, lower-layer information does not help the effect of the RA rate limitation rules. - The constant modifications are really needed for all routers, not just MNs and HAs. A separate document may speed up adoption of these changes. - A separate specification makes it easier to update the constants as we learn new optimizations. - There are existing concerns about the suggested constants (such as token-bucket proposal) which would be easier to discuss if it wouldn't be holding up the Mipv6 specification. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 10:10:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJIA7kd010559; Tue, 19 Nov 2002 10:10:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJIA7AU010558; Tue, 19 Nov 2002 10:10:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJIA3kd010548 for ; Tue, 19 Nov 2002 10:10:03 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJIADbB007426 for ; Tue, 19 Nov 2002 10:10:13 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02597 for ; Tue, 19 Nov 2002 10:10:06 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAJIA1l01005; Tue, 19 Nov 2002 20:10:01 +0200 Date: Tue, 19 Nov 2002 20:10:01 +0200 (EET) From: Pekka Savola To: Vijay Devarapalli cc: "Hesham Soliman (EAB)" , Subject: Re: MIPv6 and ND value changes In-Reply-To: <3DDA7A7E.3AEB34BC@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 19 Nov 2002, Vijay Devarapalli wrote: > > - RA intervals were reduced by MIPv6 (changing 2461) > > - When DAD fails we configure a new address and try again (2462) > > - Elimination of DAD delays (optimistic DAD) > > - Eliminsation of the random delay before sending an RA (fast RA) > > > > The last two bullets are addressed in separate drafts. > > The first 2 bullets are in the MIPv6 spec, and the > > second bullet has nothing to do with 2461. > > I agree with Hesham. we should treat them as separate issues > instead of lumping them all as ND changes. atleast bullets > 1 and 2 should definitely be in the MIPv6 spec. Disagree on 1. and _definitely on 2. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 10:29:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJITkkd010794; Tue, 19 Nov 2002 10:29:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJITkhp010793; Tue, 19 Nov 2002 10:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJIThkd010786 for ; Tue, 19 Nov 2002 10:29:43 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJITqMq012739 for ; Tue, 19 Nov 2002 10:29:52 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15588 for ; Tue, 19 Nov 2002 10:29:47 -0800 (PST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 10:29:47 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 10:29:18 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Nov 2002 10:29:18 -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.3710.0); Tue, 19 Nov 2002 10:29:18 -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); Tue, 19 Nov 2002 10:29:20 -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.3710.0); Tue, 19 Nov 2002 10:29:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Proposal for site-local clean-up Date: Tue, 19 Nov 2002 10:29:18 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKP6fUn8l0HZwaRS2yBcFrhNeOI2QADRnZS From: "Christian Huitema" To: "Keith Moore" , "Dan Lanciani" Cc: X-OriginalArrivalTime: 19 Nov 2002 18:29:12.0357 (UTC) FILETIME=[8EB3C550:01C28FF9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJIThkd010787 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Ok, but it isn't clear that these two factors are of even remotely similar >> weight. Leakage is a problem that can be addressed, but there are a lot of >> things that simply will not work without stable addresses (at least not >> without a complete overhaul of many higher-level protocols). > > Agreed that stable addresses are necessary, but experience suggests that > it is very difficult to 'address' leakage of addresses. Every application > is another path by which addresses can be leaked. For that matter, so > is every mobile host. During the transition phase, a number of hosts will be using IPv6 addresses that are derived from IPv4 addresses, and will thus be just as stable as IPv4 addresses. Even if we close our eyes very hard and wish for stable addresses very strongly, global IPv6 addresses will not be all that stable, at least not during the transition phase. We need some form of provider independent addresses for the local applications, and site local are what we have. Clearly, site local are not perfect. As Keith points out, we can minimize address leakage, but we can certainly not guarantee a leakproof use of site local addresses. We can all observe that RFC 1918 do leak. I would argue that we are in a better position with IPv6 site local than with RFC 1918 IPv4 addresses. There is a standard API to determine the scope of an address, which makes the application's writer job somewhat simpler; indeed, these application writers has already to be concerned with not leaking link local addresses, so site local don't make their task much more complex. Also, IPv6 site local address include a mostly unique 64 bit node ID, which means that the consequences of leakage are not quite as bad as for IPv4: you will mostly get a failed conection, not a connection to some other random host on the remote site. The right solution could be to have provider independent non routable addresses. They would effectively be global, which would make programming simpler and would make leaks mostly harmless. However, we don't have such addresses today, so this is mostly a rhetorical argument. Also, such global addresses would require much more management. I guess we are stuck with site local for now. -- 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 Tue Nov 19 10:38:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJIc7kd010947; Tue, 19 Nov 2002 10:38:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJIc6Gi010946; Tue, 19 Nov 2002 10:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJIc3kd010937 for ; Tue, 19 Nov 2002 10:38:03 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJIcCbB016663 for ; Tue, 19 Nov 2002 10:38:13 -0800 (PST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00514 for ; Tue, 19 Nov 2002 10:38:07 -0800 (PST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gAJIc3m30997; Tue, 19 Nov 2002 19:38:03 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gAJIc3te031874; Tue, 19 Nov 2002 19:38:03 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211191838.gAJIc3te031874@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: "Bound, Jim" , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes In-reply-to: Your message of Tue, 19 Nov 2002 09:47:21 PST. <3DDA7929.ADB66B44@iprg.nokia.com> Date: Tue, 19 Nov 2002 19:38:03 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: MIPv6 does not say router should send RAs more frequently. it just says access routers SHOULD be configurable to send RAs more frequently. => We know this is translated in many minds in the first statement... And this doesn't change the argument that RAs are poor beacons. this is to be used in the absense of any L2 help. => this shows the function is to beacon. Regards Francis.Dupont@enst-bretagne.fr PS: my purpose is not to contribute to this thread! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 10:41:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJIfEkd011015; Tue, 19 Nov 2002 10:41:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJIfDJA011014; Tue, 19 Nov 2002 10:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJIfAkd011007 for ; Tue, 19 Nov 2002 10:41:10 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJIfJMq016498 for ; Tue, 19 Nov 2002 10:41:19 -0800 (PST) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06719 for ; Tue, 19 Nov 2002 11:41:14 -0700 (MST) Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KP2VTLNF0894FRR0@vaxh.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Wed, 20 Nov 2002 05:37:33 +1100 Received: from splat.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 46B10130074 for ; Wed, 20 Nov 2002 05:37:33 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by splat.its.monash.edu.au (Postfix) with ESMTP id 2FCC5130062 for ; Wed, 20 Nov 2002 05:37:33 +1100 (EST) Date: Tue, 19 Nov 2002 10:37:33 -0800 From: Richard Nelson Subject: Re: RE: MIPv6 and ND value changes To: ipng@sunroof.eng.sun.com Message-id: <491718492904.492904491718@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Hesham. I think there is a lot of difference between RA interval changes that have been in the MIPv6 draft a long time and Fast RAs that has known failure modes that need to be experimented with to determine their significance. I'd add the minor points that section 11.5.2 contains a basic version of optimistic DAD (its been there since draft 12) and that there AP cached RAs are an alternative to fast RAs in yet another separate draft. Richard. ----- Original Message ----- From: "Hesham Soliman (EAB)" Date: Tuesday, November 19, 2002 8:52 am Subject: RE: MIPv6 and ND value changes > I'm getting very confused when reading this > discussion. Some people are focusing on the > RA intervals, others about DAD (2462) and > others talk generally about ND. > > Please divide the issues... > AFAIK we have the following (independent) issues: > > - RA intervals were reduced by MIPv6 (changing 2461) > - When DAD fails we configure a new address and try again (2462) > - Elimination of DAD delays (optimistic DAD) > - Eliminsation of the random delay before sending an RA (fast RA) > > The last two bullets are addressed in separate drafts. > The first 2 bullets are in the MIPv6 spec, and the > second bullet has nothing to do with 2461. > > There are different value for each point, they're all > important, but let's not lump them all in one discussion. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 10:41:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJIfwkd011037; Tue, 19 Nov 2002 10:41:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJIfw1C011036; Tue, 19 Nov 2002 10:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJIfrkd011029 for ; Tue, 19 Nov 2002 10:41:53 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJIg2Mq016760 for ; Tue, 19 Nov 2002 10:42:03 -0800 (PST) Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29755; Tue, 19 Nov 2002 11:41:56 -0700 (MST) Received: from dhcp-204-42-67-42.ietf55.ops.ietf.org ([204.42.67.42] helo=eng.monash.edu.au) by srv0.ops.ietf.org with esmtp (Exim 4.10) id 18EDJr-0007m2-00; Tue, 19 Nov 2002 18:41:55 +0000 Message-ID: <3DDB125D.27731337@eng.monash.edu.au> Date: Wed, 20 Nov 2002 04:41:01 +0000 From: Greg Daley X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.19hilc i686) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: john.loughney@nokia.com, pekkas@netcore.fi, ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, Sorry to reply so late on this, The token bucket support indicated in your email is already specified (and implemented) in FastRA. In fact, there's not much more than that to the spec (It is 3 pages). I don't think that putting FastRA in MIPv6 was an option proposed by anyone, but I do think that the location of the RA Advertisement Interval modification *is* important, if yourself and Tom both believe it shouldn't be in MIPv6. I guess we'll be discussing it tonight. Greg Erik Nordmark wrote: > > > So, perhaps my comment is a bit naive, but as the changes have been > > discussed in the MIP WG and many people think the changes are > > sane in the IPv6 WG ... I wonder what would be accomplished by > > breaking them out in a seperate document. Since the IPv6 > > WG will be working updating ND, could not the MIPv6 draft > > make the recommendations and then these recomentations be taken > > as the starting point for the ND discussions in the IETF? > > I can see a focused technical discussion on a small problem statement > and a short document can actually result in better technical solutions. > > For instance, instead of changing the fixed rate limit for solicited RAs > it make be a lot better to rate limit RAs using a token bucket filter. > That can handle the rate limiting when a bunch of machines that boot > after a power failure while still being very responsive to MNs that send > RSs to detect movement. > > Also, it makes sense to point out that in the case where all the MNs can > get a link up/down indication there isn't a need to waste the bandwidth > of the frequent unsolicited RAs but instead rely on the MN sending an RS > then the link up indication shows up. > > The point is that we could discuss the above agaist the MIPv6 spec, but > that would delay the spec. > If it was a separate 3 page spec we could do the technically right thing > without worrying about MIPv6 spec delays. > > 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 Tue Nov 19 11:43:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJJhEkd011960; Tue, 19 Nov 2002 11:43:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJJhEXQ011959; Tue, 19 Nov 2002 11: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJJhBkd011952 for ; Tue, 19 Nov 2002 11:43:11 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJJhKMq007225 for ; Tue, 19 Nov 2002 11:43:20 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25036 for ; Tue, 19 Nov 2002 12:43:15 -0700 (MST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 11:43:10 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Nov 2002 11:43:13 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 11:43:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for site-local clean-up Date: Tue, 19 Nov 2002 11:43:13 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKP3vGhdWmBNPmRRf66UHY0NGmSBgAJC0bw From: "Richard Draves" To: "Erik Nordmark" , "Brian Zill" Cc: X-OriginalArrivalTime: 19 Nov 2002 19:43:01.0786 (UTC) FILETIME=[DED8FFA0:01C29003] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJJhBkd011953 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think, but I'm not certain, that most of the large sites > that do this have completely different DNS content in the > two-faces i.e. it is more like two separate DNS services than > two-faces of the same DNS database. That is, the DNS outside > the firewall contain a subset of the RRs and > names, and there isn't necessarily a dynamic update path > between the two DNSes. > > Do you have examples of folks that have small setups of > two-faced DNS where e.g. dynamic DNS update works while still > keeping site-locals on the inside and global addresses > visible through both faces? This is a good point. I think you are right - usually the internal & external DNS services have separate databases. My expectation is that when the internal DNS service resolves a name to an RR set that includes site-local addresses, then the external DNS service fails to resolve the name. This reduces the chance for confusion if you query the "wrong" DNS service or query them in the wrong order. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 12:13:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJKDIkd012473; Tue, 19 Nov 2002 12:13:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJKDIVL012472; Tue, 19 Nov 2002 12:13: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJKDEkd012462 for ; Tue, 19 Nov 2002 12:13:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJKDNMq016058 for ; Tue, 19 Nov 2002 12:13:23 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA24569 for ; Tue, 19 Nov 2002 13:13:13 -0700 (MST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 12:13:01 -0800 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Nov 2002 12:12:42 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 12:12:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for site-local clean-up Date: Tue, 19 Nov 2002 12:12:41 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKP6Ss1iAdtQGMzTBu5xOc6s8tzJQAHQSLw From: "Richard Draves" To: "Keith Moore" , "Brian Zill" Cc: X-OriginalArrivalTime: 19 Nov 2002 20:12:41.0520 (UTC) FILETIME=[03A6DB00:01C29008] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJKDEkd012463 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Yes, needless complexity is bad. But site-locals don't add any > > significant complexity to applications (which I think I've > demonstated > > enough in too many emails already). > > this is only true if globals are always available to any node > that potentially participates in an application that > communicates off-site - > which essentially means any node in any network which has an > external connection. So to restate - Keith, it sounds like you now agree, that with a reasonably small amount of additional complexity, apps can function in a network environment that has both globals & site-locals - subject to your condition about globals being available for apps that communicate off-site? Certainly - if a node is going to run an application that communicates off-site then it needs a global address. I mostly agree with the second part - I would say any general-purpose node in any network which has an external connection should have a global address. However I think we will have limited-function nodes, which run a fixed set of applications, and if those applications do not need globals then the node does not need a global address. I think the vendor of one of these devices should have the freedom to determine the device's "out of the box" configuration, based on expected usage patterns. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 12:29:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJKTIkd012828; Tue, 19 Nov 2002 12:29:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJKTIWA012827; Tue, 19 Nov 2002 12:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJKTEkd012820 for ; Tue, 19 Nov 2002 12:29:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJKTOMq025115 for ; Tue, 19 Nov 2002 12:29:24 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16406 for ; Tue, 19 Nov 2002 13:29:18 -0700 (MST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAJKTF5V008679; Tue, 19 Nov 2002 12:29:15 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAQ57363; Tue, 19 Nov 2002 12:23:35 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA17123; Tue, 19 Nov 2002 12:29:12 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15834.40728.403037.920070@thomasm-u1.cisco.com> Date: Tue, 19 Nov 2002 12:29:12 -0800 (PST) To: "Richard Draves" Cc: "Keith Moore" , "Brian Zill" , Subject: RE: Proposal for site-local clean-up In-Reply-To: References: 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 Richard Draves writes: > > > Yes, needless complexity is bad. But site-locals don't add any > > > significant complexity to applications (which I think I've > > demonstated > > > enough in too many emails already). > > > > this is only true if globals are always available to any node > > that potentially participates in an application that > > communicates off-site - > > which essentially means any node in any network which has an > > external connection. > > So to restate - Keith, it sounds like you now agree, that with a > reasonably small amount of additional complexity, apps can function in a > network environment that has both globals & site-locals - subject to > your condition about globals being available for apps that communicate > off-site? > > Certainly - if a node is going to run an application that communicates > off-site then it needs a global address. I mostly agree with the second > part - I would say any general-purpose node in any network which has an > external connection should have a global address. > > However I think we will have limited-function nodes, which run a fixed > set of applications, and if those applications do not need globals then > the node does not need a global address. I think the vendor of one of > these devices should have the freedom to determine the device's "out of > the box" configuration, based on expected usage patterns. I find this kind of thinking rather suspect. The question in my mind shouldn't be "why global", but "why not global". There seems to an underlying assumption that site locals would give better security properties due to their global inaccessibility. I find that rather uncompelling and misguided as this is just carrying forth the broken assumption that barriers (firewalls, etc) can do an adequate job of protecting things. Anything which propogates that sort of thinking is, IMO (and almost certainly not in my employer's) bogus and needs to checked. We need keep beating the strong auth/authz drum here. So, let's just take that off the table for this discussion. 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 Nov 19 13:13:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJLD2kd013592; Tue, 19 Nov 2002 13:13:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJLD2JZ013591; Tue, 19 Nov 2002 13:13: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJLCvkd013581 for ; Tue, 19 Nov 2002 13:12:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJLD6Mq007524 for ; Tue, 19 Nov 2002 13:13:06 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14120 for ; Tue, 19 Nov 2002 14:13:01 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAJLCvl00338; Tue, 19 Nov 2002 16:12:57 -0500 (EST) Message-Id: <200211192112.gAJLCvl00338@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Christian Huitema" cc: "Keith Moore" , "Dan Lanciani" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Tue, 19 Nov 2002 10:29:18 PST.") Date: Tue, 19 Nov 2002 16:12:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I guess we are stuck with site local for now. As long as we don't have a willingness to either solve the problems with site-locals (by imposing limits on their use ) or to solve those problems in other ways (e.g. by providing provider-independent addresses) I think we are stuck in general. But I don't find the argument that we must have site-locals (even though we know they are broken) because we aren't willing to solve the problems in a better way, very persuasive. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 13:19:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJLJukd013854; Tue, 19 Nov 2002 13:19:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJLJukI013853; Tue, 19 Nov 2002 13:19: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJLJpkd013842 for ; Tue, 19 Nov 2002 13:19:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJLK0Mq009564 for ; Tue, 19 Nov 2002 13:20:00 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08603 for ; Tue, 19 Nov 2002 14:19:54 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAJLJpl00400; Tue, 19 Nov 2002 16:19:51 -0500 (EST) Message-Id: <200211192119.gAJLJpl00400@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , "Brian Zill" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Tue, 19 Nov 2002 12:12:41 PST.") Date: Tue, 19 Nov 2002 16:19:51 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So to restate - Keith, it sounds like you now agree, that with a > reasonably small amount of additional complexity, apps can function in a > network environment that has both globals & site-locals - subject to > your condition about globals being available for apps that communicate > off-site? yes. the trick is making that condition stick in practice. I have my doubts. > Certainly - if a node is going to run an application that communicates > off-site then it needs a global address. I mostly agree with the second > part - I would say any general-purpose node in any network which has an > external connection should have a global address. > > However I think we will have limited-function nodes, which run a fixed > set of applications, and if those applications do not need globals then > the node does not need a global address. I'm with you this far. > I think the vendor of one of > these devices should have the freedom to determine the device's "out of > the box" configuration, based on expected usage patterns. Here I strongly disagree. It's simply not reasonable in general for a vendor to make assumptions about the distribution of threats in a customer's network. For the very limited case of home networks, it might be reasonable, but I have stong doubts that either it's reasonable to define a 'home network' or to have 'home network devices' as a special class that for which it's declared okay to be insecure out of the box. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 13:21:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJLL0kd013900; Tue, 19 Nov 2002 13:21:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJLL0wo013899; Tue, 19 Nov 2002 13:21:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJLKrkd013892 for ; Tue, 19 Nov 2002 13:20:54 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJLL3Mq009836 for ; Tue, 19 Nov 2002 13:21:03 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18753 for ; Tue, 19 Nov 2002 13:20:57 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAJLKol00419; Tue, 19 Nov 2002 16:20:50 -0500 (EST) Message-Id: <200211192120.gAJLKol00419@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Thomas cc: "Richard Draves" , "Keith Moore" , "Brian Zill" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Tue, 19 Nov 2002 12:29:12 PST.") <15834.40728.403037.920070@thomasm-u1.cisco.com> Date: Tue, 19 Nov 2002 16:20:50 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I find this kind of thinking rather suspect. The > question in my mind shouldn't be "why global", but > "why not global". There seems to an underlying > assumption that site locals would give better > security properties due to their global > inaccessibility. I find that rather uncompelling > and misguided as this is just carrying forth the > broken assumption that barriers (firewalls, etc) > can do an adequate job of protecting > things. Anything which propogates that sort of > thinking is, IMO (and almost certainly not in my > employer's) bogus and needs to checked. We need > keep beating the strong auth/authz drum here. I'm very much in agreement with this sentiment. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 13:28:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJLSikd014350; Tue, 19 Nov 2002 13:28:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJLSi3B014349; Tue, 19 Nov 2002 13:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJLSekd014336 for ; Tue, 19 Nov 2002 13:28:40 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJLSnbB013444 for ; Tue, 19 Nov 2002 13:28:49 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12564 for ; Tue, 19 Nov 2002 13:28:43 -0800 (PST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAJLSeKV004061; Tue, 19 Nov 2002 22:28:40 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 19 Nov 2002 22:28:40 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0D1E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Pekka Savola'" , Vijay Devarapalli Cc: ipng@sunroof.eng.sun.com Subject: RE: MIPv6 and ND value changes Date: Tue, 19 Nov 2002 22:28:39 +0100 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 > > - RA intervals were reduced by MIPv6 (changing 2461) > > > - When DAD fails we configure a new address and try again (2462) > > > - Elimination of DAD delays (optimistic DAD) > > > - Eliminsation of the random delay before sending an RA > (fast RA) > > > > > > The last two bullets are addressed in separate drafts. > > > The first 2 bullets are in the MIPv6 spec, and the > > > second bullet has nothing to do with 2461. > > > > I agree with Hesham. we should treat them as separate issues > > instead of lumping them all as ND changes. atleast bullets > > 1 and 2 should definitely be in the MIPv6 spec. > > Disagree on 1. and _definitely on 2. => Why do you disagree with 2? Do you think a MN should disable an interface when DAD fails the first time? Sounds disastrous Hesham > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 13:33:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJLWxkd014565; Tue, 19 Nov 2002 13:32:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJLWxQK014564; Tue, 19 Nov 2002 13:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJLWukd014557 for ; Tue, 19 Nov 2002 13:32:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJLX5bB015018 for ; Tue, 19 Nov 2002 13:33:05 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06794 for ; Tue, 19 Nov 2002 14:32:59 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAJLWtJ03068; Tue, 19 Nov 2002 23:32:55 +0200 Date: Tue, 19 Nov 2002 23:32:54 +0200 (EET) From: Pekka Savola To: "Hesham Soliman (EAB)" cc: Vijay Devarapalli , Subject: RE: MIPv6 and ND value changes In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0D1E@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 19 Nov 2002, Hesham Soliman (EAB) wrote: > => Why do you disagree with 2? Do you think a MN > should disable an interface when DAD fails the > first time? > Sounds disastrous I don't disagree with the problem (but perhaps with how you treat it), but let me say it again: *THERE'S NOTHING MIPV6-SPECIFIC IN THAT* -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 13:51:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJLpQkd014915; Tue, 19 Nov 2002 13:51:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJLpQls014914; Tue, 19 Nov 2002 13:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJLpMkd014904 for ; Tue, 19 Nov 2002 13:51:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJLpWMq019154 for ; Tue, 19 Nov 2002 13:51:32 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08164 for ; Tue, 19 Nov 2002 14:51:26 -0700 (MST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAJLpNKV006088; Tue, 19 Nov 2002 22:51:23 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 19 Nov 2002 22:51:23 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0D1F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Pekka Savola'" , "Hesham Soliman (EAB)" Cc: Vijay Devarapalli , ipng@sunroof.eng.sun.com Subject: RE: MIPv6 and ND value changes Date: Tue, 19 Nov 2002 22:51:22 +0100 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 > I don't disagree with the problem (but perhaps with how you > treat it), but > let me say it again: > > *THERE'S NOTHING MIPV6-SPECIFIC IN THAT* => Mobility will increase the minute probability of collision. Anyway, that's not the point, you're saying that you disagree with the solution, what's your alternative? Please don't say "solve it in IPv6 WG" because that's not a solution. Hesham > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 14:30:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJMUhkd015170; Tue, 19 Nov 2002 14:30:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJMUhWM015169; Tue, 19 Nov 2002 14:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJMUekd015162 for ; Tue, 19 Nov 2002 14:30:40 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJMUnMq000180 for ; Tue, 19 Nov 2002 14:30:49 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01582 for ; Tue, 19 Nov 2002 14:30:44 -0800 (PST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 14:30:41 -0800 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Nov 2002 14:30:43 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Tue, 19 Nov 2002 14:30:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for site-local clean-up Date: Tue, 19 Nov 2002 14:30:42 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKQEWaub3pPxrdmQZecxIvhCMDmRQAB7+Tg From: "Richard Draves" To: "Keith Moore" , "Michael Thomas" Cc: "Brian Zill" , X-OriginalArrivalTime: 19 Nov 2002 22:30:43.0216 (UTC) FILETIME=[4BED6100:01C2901B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJMUekd015163 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I think the vendor of one of > > these devices should have the freedom to determine the > device's "out > > of the box" configuration, based on expected usage patterns. > > Here I strongly disagree. It's simply not reasonable in > general for a vendor to make assumptions about the > distribution of threats in > a customer's network. For the very limited case of home > networks, it might be reasonable, but I have stong doubts > that either it's reasonable to define a 'home network' or to > have 'home network devices' as a special class that for which > it's declared okay to be insecure out of the box. Not surprisingly, this reminds me of our discussion of "Default Address Selection". :-) Obviously, an application or device must have *some* "out of the box" configuration. Unfortunately there is a trade-off between security & usability. One can imagine several possible "out of the box" configurations. The first would be no security, the app/device is accessible by all. From past history & human nature we know that far too many users will fail to configure the app/device. So this is not a good default configuration. Another possibility is complete security - in other words, the app/device is not functional until it is configured. The problem here is that the annoyed user is most likely to "fix" the problem by disabling security. Finally, an "out of box" configuration that relies on site-locals offers some security with reasonable utility - not perfect on either dimension but pretty good for most environments. > I find this kind of thinking rather suspect. The > question in my mind shouldn't be "why global", but > "why not global". There seems to an underlying > assumption that site locals would give better > security properties due to their global > inaccessibility. I find that rather uncompelling > and misguided as this is just carrying forth the > broken assumption that barriers (firewalls, etc) > can do an adequate job of protecting > things. Anything which propogates that sort of > thinking is, IMO (and almost certainly not in my > employer's) bogus and needs to checked. We need > keep beating the strong auth/authz drum here. First, site-locals offer better security than a single firewall, because typically there will be multiple routers on the path between an attacker and a customer site, all filtering site-locals. Second, I agree that strong security is great and we should work towards it. But "defense in depth" argues for having multiple security mechanisms, so even with strong security I think site-locals and firewalls have a place. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 14:50:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJMoekd015361; Tue, 19 Nov 2002 14:50:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJMoeWc015360; Tue, 19 Nov 2002 14:50: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJMoakd015353 for ; Tue, 19 Nov 2002 14:50:37 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJMokbB007545 for ; Tue, 19 Nov 2002 14:50:46 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13401 for ; Tue, 19 Nov 2002 14:50:36 -0800 (PST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 14:50:28 -0800 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Nov 2002 14:50:32 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 19 Nov 2002 14:50:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for site-local clean-up Date: Tue, 19 Nov 2002 14:50:20 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKPOV1uWI1X8a80TwSutOLnFMXE8gAVGxawAA0EYSAAFpOagA== From: "Brian Zill" To: "Bound, Jim" , X-OriginalArrivalTime: 19 Nov 2002 22:50:21.0169 (UTC) FILETIME=[0A0ABE10:01C2901E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAJMobkd015354 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, > > There needs to be a way to get an address when you don't > > have a provider. This means either scoped addresses as we > > have defined them already (and in multi-link locations, this > > means either site-local or multi-link subnet routers and > > link-local), or some sort of provider-independent address > > (note there are various types of these as well, depending > > upon whether we believe they should be explicitly > > non-routable, or privately routable between multiple > > non-connected 'sites'). > > I cannot see anyway to route site-locals across multiple > sites? Your not saying to do this are you? No, I'm not. Site-locals should not be routed across sites. I was addressing the suggestion others have made which was to use some sort of yet-to-be-defined provider-independent addresses instead of site-locals in some situations. My point on that topic is that there are a range of different properties such addresses could have (one of which is that they may or may not be routable across sites). I believe at least some of the arguments people were having were the result of different unstated assumptions about what the properties of such addresses would be. > Part of the issue for all this mail is not to kill SLs but > to make sure we understand them and how to use them and how > to manage them and what their affect to users will be. That would be my preference as well. --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 Nov 19 15:04:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJN4Ekd015523; Tue, 19 Nov 2002 15:04:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJN4EI5015522; Tue, 19 Nov 2002 15:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJN4Bkd015515 for ; Tue, 19 Nov 2002 15:04:11 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJN4KMq009675 for ; Tue, 19 Nov 2002 15:04:20 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01528 for ; Tue, 19 Nov 2002 16:04:14 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAJN4AR03824; Wed, 20 Nov 2002 01:04:10 +0200 Date: Wed, 20 Nov 2002 01:04:10 +0200 (EET) From: Pekka Savola To: "Hesham Soliman (EAB)" cc: Vijay Devarapalli , Subject: RE: MIPv6 and ND value changes In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0D1F@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 19 Nov 2002, Hesham Soliman (EAB) wrote: > > I don't disagree with the problem (but perhaps with how you > > treat it), but > > let me say it again: > > > > *THERE'S NOTHING MIPV6-SPECIFIC IN THAT* > > => Mobility will increase the minute probability of > collision. Maybe, but so does WLAN roaming without MIPv6. > Anyway, that's not the point, you're saying > that you disagree with the solution, what's your alternative? > Please don't say "solve it in IPv6 WG" because that's > not a solution. The solution seems O.K. to me. However, I'm not so sure this is a problem that needs fixing. First, collisions with EUI64/RFC3041 addresses are so rare, you should not need to care too much about them -- setting the interface down might be an ok approach (that might alert the sysadmin to look what's wrong). And with statically assigned addresses, you don't want to generate a new address, of course. So the thing to worry about is someone performing a DoS in the link. But nothing prevents that local attacker from spoofing responses to *all* the DAD attempts, not just the first one. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 15:46:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJNkZkd015672; Tue, 19 Nov 2002 15:46:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAJNkZD5015671; Tue, 19 Nov 2002 15:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJNkWkd015664 for ; Tue, 19 Nov 2002 15:46:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAJNkfbB023464 for ; Tue, 19 Nov 2002 15:46:41 -0800 (PST) Received: from leapster.dwerryhouse.com.au (leapster.zoic.org [203.30.75.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25411 for ; Tue, 19 Nov 2002 16:46:35 -0700 (MST) Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id DF3D8146D2; Wed, 20 Nov 2002 10:46:25 +1100 (EST) Date: Wed, 20 Nov 2002 10:46:24 +1100 From: "Nick 'Sharkey' Moore" To: ipng@sunroof.eng.sun.com Cc: Richard Nelson Subject: Re: RE: MIPv6 and ND value changes Message-ID: <20021120104622.A10984@dwerryhouse.com.au> References: <491718492904.492904491718@mail1.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <491718492904.492904491718@mail1.monash.edu.au>; from Richard.Nelson@eng.monash.edu.au on Tue, Nov 19, 2002 at 10:37:33AM -0800 X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Nov 19, 2002 at 10:37:33AM -0800, Richard Nelson wrote: > > I'd add the minor points that section 11.5.2 contains > a basic version of optimistic > DAD (its been there since draft 12) [...] Basic? ... Very Basic! "Furthermore, the mobile node MAY continue using the address without performing Duplicate Address Detection, although it SHOULD in most cases. begin Duplicate Address Detection asynchronously when it begins use of the address." By the way, an updated version of my Optimistic DAD draft is now available: Which addresses many of the technical concerns raised in the discussion on this list. I didn't get it submitted in time for this IETF, but I figure those of you stranded in the terminal room might enjoy some light reading ... also, there's a Linux implementation well under way. -----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 Nov 19 16:10:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK0AHkd015814; Tue, 19 Nov 2002 16:10:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAK0AGMt015813; Tue, 19 Nov 2002 16:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK0ADkd015806 for ; Tue, 19 Nov 2002 16:10:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAK0AMMq027922 for ; Tue, 19 Nov 2002 16:10:23 -0800 (PST) Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26205 for ; Tue, 19 Nov 2002 17:10:17 -0700 (MST) Received: from yhhan2.ietf55.ops.ietf.org ([204.42.70.203] helo=yhhan2) by srv0.ops.ietf.org with smtp (Exim 4.10) id 18EIRc-000AGi-00 for ipng@sunroof.eng.sun.com; Wed, 20 Nov 2002 00:10:16 +0000 Message-ID: <00c401c29028$8dcf9b80$cb462acc@yhhan2> From: "Youn-Hee Han" To: Subject: Fw: RE: MIPv6 and ND value changes Date: Wed, 20 Nov 2002 09:05:36 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id gAK0AEkd015807 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard wrote : > I'd add the minor points that section 11.5.2 contains a basic version of optimistic > DAD (its been there since draft 12) and that there AP cached RAs are an > alternative to fast RAs in yet another separate draft. I agree with Richard. The AP cahed RAs can be esaily implemented and an alternative to fast RAs. IMHO, The AP which cache RAs and sends them to an MN at its association with the AP, is more deployable approach than router supporting fast RA. The change of AP is easier than the change of router. Youn-Hee Han -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 19 16:58:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK0wQkd016129; Tue, 19 Nov 2002 16:58:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAK0wQWG016128; Tue, 19 Nov 2002 16:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK0wNkd016121 for ; Tue, 19 Nov 2002 16:58:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAK0wWMq010686 for ; Tue, 19 Nov 2002 16:58:32 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23470 for ; Tue, 19 Nov 2002 17:58:26 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 32DD745CC; Tue, 19 Nov 2002 19:58:26 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Nov 2002 19:58:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Resend: Re: rfc2553bis-07 to rfc2553bis-08 changes Date: Tue, 19 Nov 2002 19:58:25 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9BBD@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resend: Re: rfc2553bis-07 to rfc2553bis-08 changes Thread-Index: AcKP44ZGNYM6I91hQNihiuv2s657KQATFTlA From: "Bound, Jim" To: "Brian E Carpenter" , Cc: , X-OriginalArrivalTime: 20 Nov 2002 00:58:26.0035 (UTC) FILETIME=[EE943C30:01C2902F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAK0wNkd016122 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree. We can have an addendum API spec specifically for this later. /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, November 19, 2002 10:46 AM > To: jinmei@isl.rdc.toshiba.co.jp > Cc: narten@us.ibm.com; ipng@sunroof.eng.sun.com > Subject: Re: Resend: Re: rfc2553bis-07 to rfc2553bis-08 changes > > > I'm reluctant to reach any conclusion about this until > we have complete clarity about the flow label, which as > we concluded yesterday still needs more work. So I think > that the current (ambiguous) text is probably OK for now. > I'm afraid it will need revisiting at some time in the future. > > Brian > > JINMEI Tatuya / $B?@L@C#:H(B wrote: > > > > Unless I've missed something, I've not received any > responses to the > > attached message. I interpreted the silence as a sign that > there is > > no need to update 2292bis wrt the issues in this thread. > Otherwise, > > please let me know. > > > > Thanks, > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D > Center, Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > > > > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------- > > > > Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes > > Date: Fri, 08 Nov 2002 20:51:38 +0900 > > From: JINMEI Tatuya / $B?@L@C#:H(B > > Organization: Research & Development Center, Toshiba Corp., > Kawasaki, > > Japan. > > To: Thomas Narten > > CC: ipng@sunroof.eng.sun.com > > References: > > <200211051903.gA5J3wx0001145948@anw.zk3.dec.com> > > <200211061844.gA6Iina17496@rotala.raleigh.ibm.com> > > > > >>>>> On Wed, 06 Nov 2002 13:44:49 -0500, > > >>>>> Thomas Narten said: > > > > > With regards to the basic API: > > > > > - Will we want the basic API to ever allow a way to specify the > > > Traffic Class? If so, will it be better to define a new > extension or > > > to overload the Flow Label? > > > > > - Should we point out that some previous versions of the basic API > > > copied both traffic class and flow label info into > packets and that > > > this is now beleived to be wrong and should be fixed? > > > > > I'm OK with either saying setting the Traffic Class through the > > > basic API won't be done in the future, or saying it can > be added but > > > in a way that is completely backwards compatable and will work > > > smoothly with 2292bis (assuming we need two ways of setting the > > > bits). > > > > I personally prefer to deprecate the access to Traffic Class by the > > sin6_flowinfo field (i.e. by the basic API), because > > > > - it (of course) makes the (future) API simple. > > - as far as I know, there should be very few (or even no) > applications > > that rely on the feature. so the backward compatibility issue > > should be not so serious. > > > > I know opinions on the compatibility often varies, and I'm open to > > others' opinions. > > > > > Then there is the Advanced API. Again, from Bill: > > > > > Bill Fenner writes: > > > > >> I am still concerned about the interaction between 2292bis's > > >> IPV6_TCLASS and these implementations, but perhaps we should let > > >> 2553bis go with the "not currently specified" wording > and make the > > >> interaction clear in 2292bis? (Has the WG as a whole > had a chance > > >> to see the suggesiton of leaving sin6_flowinfo simply > unspecified?) > > > > > 2292 doesn't address the flow label. But it does have a way of > > > setting the Traffic Class. But it doesn't mention how it > interacts > > > with Traffic Class settings via the (old) basic APIs. If the > > > intention is that the old ways are invalid, and that one > only sets > > > traffic class through the advanced API, I think the > current approach > > > is fine. Is that what folks are thinking here? > > > > Excuse me, what do you mean by "the current approach"? Do you mean > > that "2292bis has a way of setting the traffic class but it doesn't > > mention the interaction with the (old) basic API"? > > > > If so, and assuming we agree on deprecating this part of the basic > > API, I agree. > > > > However, if our consensus is that some backward > compatibility should > > be provided, I guess 2292bis needs to talk about the interaction. > > > > > Finally, 2292bis seems to assume the Traffic Class is 8 bits in > > > size. It's not any more. It's 6 bits, with the ECN bits > explicitly a > > > separate field. So perhaps 2292bis should be updated to > reflect the > > > new size and have separate way of setting the ECN bits? > Or at least, > > > the text should make it clear how one sets one and not the other, > > > etc. > > > > (this was discussed before at least partly, but) > > I believe 2292bis clearly separates the notion of (6-bit) traffic > > class and 2-bit ECN. For example, section 6.5 contains the > following > > sentences: > > > > Returning the received traffic class is useful for > > programs such as a diffserv debugging tool and for user level ECN > > (explicit congestion notification) implementation. > > > > An example is an implementation of ECN in the kernel, > > setting 2 bits of the traffic class value. > > > > The confusing part would be wording such as "traffic class" > (assuming > > 8 bits) or the socket option name IPV6_TCLASS. In this sense, the > > comment for the ip6_un1_flow field of the ip6_hdr structure > would also > > be confusing: > > > > uint32_t ip6_un1_flow; /* 4 bits version, 8 > bits TC, 20 > > bits flow-ID */ > > > > As I responded before, I personally think the current > wording is okay. > > However, if there's a strong demand to clarify this much more, I'd > > propose to add a note like this: > > > > [RFC-3260] separates an 8-bit field of the IPv6 header, which was > > originally called a single "traffic class" field, into a 6-bit DS > > field and a 2-bit ECN field. However, since this API > only provides a > > single way to get access to the whole 8 bits, the > previous terminology > > "traffic class" will be used to specify the whole bits within this > > document. > > > > Does this make sense? > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate > X-Mozilla-Status: 0009rp. > > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 14:48:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK0wQkd016129; Tue, 19 Nov 2002 16:58:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAK0wQWG016128; Tue, 19 Nov 2002 16:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK0wNkd016121 for ; Tue, 19 Nov 2002 16:58:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAK0wWMq010686 for ; Tue, 19 Nov 2002 16:58:32 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23470 for ; Tue, 19 Nov 2002 17:58:26 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 32DD745CC; Tue, 19 Nov 2002 19:58:26 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Nov 2002 19:58:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Resend: Re: rfc2553bis-07 to rfc2553bis-08 changes Date: Tue, 19 Nov 2002 19:58:25 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9BBD@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resend: Re: rfc2553bis-07 to rfc2553bis-08 changes Thread-Index: AcKP44ZGNYM6I91hQNihiuv2s657KQATFTlA From: "Bound, Jim" To: "Brian E Carpenter" , Cc: , X-OriginalArrivalTime: 20 Nov 2002 00:58:26.0035 (UTC) FILETIME=[EE943C30:01C2902F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAK0wNkd016122 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree. We can have an addendum API spec specifically for this later. /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, November 19, 2002 10:46 AM > To: jinmei@isl.rdc.toshiba.co.jp > Cc: narten@us.ibm.com; ipng@sunroof.eng.sun.com > Subject: Re: Resend: Re: rfc2553bis-07 to rfc2553bis-08 changes > > > I'm reluctant to reach any conclusion about this until > we have complete clarity about the flow label, which as > we concluded yesterday still needs more work. So I think > that the current (ambiguous) text is probably OK for now. > I'm afraid it will need revisiting at some time in the future. > > Brian > > JINMEI Tatuya / $B?@L@C#:H(B wrote: > > > > Unless I've missed something, I've not received any > responses to the > > attached message. I interpreted the silence as a sign that > there is > > no need to update 2292bis wrt the issues in this thread. > Otherwise, > > please let me know. > > > > Thanks, > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D > Center, Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > > > > > > > ---------------------------------------------------------------------- > > ---------------------------------------------------------- > > > > Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes > > Date: Fri, 08 Nov 2002 20:51:38 +0900 > > From: JINMEI Tatuya / $B?@L@C#:H(B > > Organization: Research & Development Center, Toshiba Corp., > Kawasaki, > > Japan. > > To: Thomas Narten > > CC: ipng@sunroof.eng.sun.com > > References: > > <200211051903.gA5J3wx0001145948@anw.zk3.dec.com> > > <200211061844.gA6Iina17496@rotala.raleigh.ibm.com> > > > > >>>>> On Wed, 06 Nov 2002 13:44:49 -0500, > > >>>>> Thomas Narten said: > > > > > With regards to the basic API: > > > > > - Will we want the basic API to ever allow a way to specify the > > > Traffic Class? If so, will it be better to define a new > extension or > > > to overload the Flow Label? > > > > > - Should we point out that some previous versions of the basic API > > > copied both traffic class and flow label info into > packets and that > > > this is now beleived to be wrong and should be fixed? > > > > > I'm OK with either saying setting the Traffic Class through the > > > basic API won't be done in the future, or saying it can > be added but > > > in a way that is completely backwards compatable and will work > > > smoothly with 2292bis (assuming we need two ways of setting the > > > bits). > > > > I personally prefer to deprecate the access to Traffic Class by the > > sin6_flowinfo field (i.e. by the basic API), because > > > > - it (of course) makes the (future) API simple. > > - as far as I know, there should be very few (or even no) > applications > > that rely on the feature. so the backward compatibility issue > > should be not so serious. > > > > I know opinions on the compatibility often varies, and I'm open to > > others' opinions. > > > > > Then there is the Advanced API. Again, from Bill: > > > > > Bill Fenner writes: > > > > >> I am still concerned about the interaction between 2292bis's > > >> IPV6_TCLASS and these implementations, but perhaps we should let > > >> 2553bis go with the "not currently specified" wording > and make the > > >> interaction clear in 2292bis? (Has the WG as a whole > had a chance > > >> to see the suggesiton of leaving sin6_flowinfo simply > unspecified?) > > > > > 2292 doesn't address the flow label. But it does have a way of > > > setting the Traffic Class. But it doesn't mention how it > interacts > > > with Traffic Class settings via the (old) basic APIs. If the > > > intention is that the old ways are invalid, and that one > only sets > > > traffic class through the advanced API, I think the > current approach > > > is fine. Is that what folks are thinking here? > > > > Excuse me, what do you mean by "the current approach"? Do you mean > > that "2292bis has a way of setting the traffic class but it doesn't > > mention the interaction with the (old) basic API"? > > > > If so, and assuming we agree on deprecating this part of the basic > > API, I agree. > > > > However, if our consensus is that some backward > compatibility should > > be provided, I guess 2292bis needs to talk about the interaction. > > > > > Finally, 2292bis seems to assume the Traffic Class is 8 bits in > > > size. It's not any more. It's 6 bits, with the ECN bits > explicitly a > > > separate field. So perhaps 2292bis should be updated to > reflect the > > > new size and have separate way of setting the ECN bits? > Or at least, > > > the text should make it clear how one sets one and not the other, > > > etc. > > > > (this was discussed before at least partly, but) > > I believe 2292bis clearly separates the notion of (6-bit) traffic > > class and 2-bit ECN. For example, section 6.5 contains the > following > > sentences: > > > > Returning the received traffic class is useful for > > programs such as a diffserv debugging tool and for user level ECN > > (explicit congestion notification) implementation. > > > > An example is an implementation of ECN in the kernel, > > setting 2 bits of the traffic class value. > > > > The confusing part would be wording such as "traffic class" > (assuming > > 8 bits) or the socket option name IPV6_TCLASS. In this sense, the > > comment for the ip6_un1_flow field of the ip6_hdr structure > would also > > be confusing: > > > > uint32_t ip6_un1_flow; /* 4 bits version, 8 > bits TC, 20 > > bits flow-ID */ > > > > As I responded before, I personally think the current > wording is okay. > > However, if there's a strong demand to clarify this much more, I'd > > propose to add a note like this: > > > > [RFC-3260] separates an 8-bit field of the IPv6 header, which was > > originally called a single "traffic class" field, into a 6-bit DS > > field and a 2-bit ECN field. However, since this API > only provides a > > single way to get access to the whole 8 bits, the > previous terminology > > "traffic class" will be used to specify the whole bits within this > > document. > > > > Does this make sense? > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate > X-Mozilla-Status: 0009rp. > > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 15:11:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKMFP1O017421 for ; Wed, 20 Nov 2002 14:16:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAKM2mDN017269; Wed, 20 Nov 2002 14:02:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKM011O017169 for ; Wed, 20 Nov 2002 14:01:24 -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 gAKK9FH18846; Wed, 20 Nov 2002 21:09:15 +0100 (MET) Date: Wed, 20 Nov 2002 21:05:58 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Proposal for site-local clean-up To: Dan Lanciani Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200211190349.WAA10024@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 Sorry for the delayed response - didn't see me in the to: or cc: fields. > |In terms of the stability of the addresses one has to take into account > |both stability as it relates to local communication and stability for > |global communication. > > We have always been told that stable global v6 addresses will not be > available to end users, or at least will not be available to end users at a > low cost. Unless you are proposing to revise the whole address allocation > architecture *and* have a way to force ISPs to change their business models > I think we must accept this as a given. The temporal stability of addresses have a temporary component - it isn't black and white. Crystal ball: I wouldn't be surprised if small sites renumber the IPv6 addresses once a year with an overlap (both new and old working for a week perhaps). I see no reason why one would ever want to change them once a day. Taking together globally things means that there will be lots of renumbering in progress at any given time (given millions of sites and a reasonably long overlap). Thus I'm not too worried about e.g. my home site changing IPv6 prefixes all the time. Of course, there is a concern for applications which keep a connection open for a long time (weeks), but I suspect that such applications are, or need to be, capable of reconnecting since they need to be able to deal with peer failure. > I think you have made an unreasonable leap by dropping the "stable" > qualifier. The value/importance of _stable_ local communication is almost > certainly much higher than the value/importance of _stable_ global > communication. Even with the "stable" qualifier my opinion is the same. You are welcome to disagree. > But my NFS client is simply not prepared to have its server's > address renumbered out from under it. My multi-hour build will fail unless > I notice the problem and fire up adb on the kernel in a hurry. Similarly my > print job will fail if the printer and/or client is/are renumbered in the > middle of a tcp session. You seem to be assuming flash renumbering without overlap. With a one week overlap when a site gets renumbered by its ISP your two week long build might require a umount -f for NFS, and your petabyte print job (that takes > 1 week to send to the printer) might fail. > My distributed home automation system, while quite tolerant > of temporary lost connections and machine reboots, can not deal with > addresses changing out from under it. This is hardly unreasonable because > the tools to deal gracefully with such situations have not yet been > invented. To make such things work now each application would have to > implement its own procedures to deal with unstable addresses. This is > obviously not acceptable to application writers. And the tools to deal in a robust manner with multiple-scopes of addresses have not been applied to your home automation system either. To be it makes more sense to get applications to - not cache DNS answers forever - be prepared to restart connections after redoing a DNS lookup if the connections are open for a long time (days or more). I think this is less work, since many applications can get away with doing nothing, than having all applications handle different scope addresses. > We understand that sites are administrative. Section 4 in draft-ietf-ipngwg-scoping-arch seems to say something differnet. A site doesn't span multiple administrations, but it is limited to a single geographic location, such as an office, an office complex, or a campus. > |So let's not loose sight of the fact that the goal is a robust network. > > I think that the goal is a useful network--useful not only for ISPs and > application vendors but for consumers. Agreed. I don't think I was saying anything different. 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 Nov 20 15:11:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNBBVQ018315; Wed, 20 Nov 2002 15:11:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAKMo896017842; Wed, 20 Nov 2002 14:50: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKMfv1m017692 for ; Wed, 20 Nov 2002 14:47:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAKJBubB006658 for ; Wed, 20 Nov 2002 11:11:57 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06616 for ; Wed, 20 Nov 2002 12:11:51 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAKJBSl09567; Wed, 20 Nov 2002 14:11:28 -0500 (EST) Message-Id: <200211201911.gAKJBSl09567@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Richard Draves" cc: "Keith Moore" , "Michael Thomas" , "Brian Zill" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Tue, 19 Nov 2002 14:30:42 PST.") Date: Wed, 20 Nov 2002 14:11:28 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Not surprisingly, this reminds me of our discussion of "Default Address > Selection". :-) Obviously, an application or device must have *some* > "out of the box" configuration. > > Unfortunately there is a trade-off between security & usability. One can > imagine several possible "out of the box" configurations. The first > would be no security, the app/device is accessible by all. From past > history & human nature we know that far too many users will fail to > configure the app/device. So this is not a good default configuration. > Another possibility is complete security - in other words, the > app/device is not functional until it is configured. The problem here is > that the annoyed user is most likely to "fix" the problem by disabling > security. I don't buy this argument, for several reasons. I don't buy that having the vendor guess what works for the user and the user's network will be more secure overall than asking the user what the security policy should be. Perhaps more importantly, I don't buy the argument that *any* set of addresses should be considered trustworthy, by default or otherwise. Addresses are simply not sufficient as an authentication mechanism. This is not a practice that IETF standards should endorse or encourage. The only exception that I can see is a device that has no keyboard or display, and which must be configured over the net. In those cases I think it makes sense to allow the device to be configured from another host on the same link - so the device would accept connections to its linklocal or maybe site-local address until it was configured. But it should still require explicit configuration before allowing normal use if it has valuable resources to protect. So if you are asking the question about which set of addresses should be trusted by default, I claim you are asking the wrong question. > First, site-locals offer better security than a single firewall, because > typically there will be multiple routers on the path between an attacker > and a customer site, all filtering site-locals. it doesn't follow, because you are only considering one kind of threat, and you aren't considering other arguably more important aspects of security - such as the ability to detect breakins and attacks. > Second, I agree that > strong security is great and we should work towards it. But "defense in > depth" argues for having multiple security mechanisms, so even with > strong security I think site-locals and firewalls have a place. actually, site-locals seem to make defense in depth more difficult. 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 Nov 20 15:21:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK160kd016162 for ; Tue, 19 Nov 2002 17:06:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAK14d1V016161; Tue, 19 Nov 2002 17:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK11skd016151 for ; Tue, 19 Nov 2002 17:03:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAK123Mq011681 for ; Tue, 19 Nov 2002 17:02:03 -0800 (PST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA03581 for ; Tue, 19 Nov 2002 18:01:50 -0700 (MST) Message-ID: <023a01c2902f$df098180$8f6015ac@T23KEMPF> From: "James Kempf" To: "Youn-Hee Han" , References: <00c401c29028$8dcf9b80$cb462acc@yhhan2> Subject: Cached RA v.s. Fast RA (was Re: RE: MIPv6 and ND value changes) Date: Tue, 19 Nov 2002 16:57:56 -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 The problem with this proposal is that the AP doesn't exist as far as IETF is concerned. An AP is not an IP device, and it is not on the map as far as the Internet architecture is concerned.. Routers do exist and therefore the fast RA could be standardized in the IETF. That said, I think the proposal is a good one and it should be taken to IEEE 802.11. Somehow, we need to figure out a way to get 802.11 to pay more attention to MIP. jak ----- Original Message ----- From: "Youn-Hee Han" To: Sent: Tuesday, November 19, 2002 4:05 PM Subject: Fw: RE: MIPv6 and ND value changes > Richard wrote : > > > I'd add the minor points that section 11.5.2 contains a basic version of optimistic > > DAD (its been there since draft 12) and that there AP cached RAs are an > > alternative to fast RAs in yet another separate draft. > > I agree with Richard. > The AP cahed RAs can be esaily implemented and an alternative to fast RAs. > IMHO, The AP which cache RAs and sends them to an MN at its association with the AP, > is more deployable approach than router supporting fast RA. > The change of AP is easier than the change of router. > > Youn-Hee Han > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 20 15:25:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK1Clkd016191 for ; Tue, 19 Nov 2002 17:12:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAK1BQhF016180; Tue, 19 Nov 2002 17: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK18fkd016168 for ; Tue, 19 Nov 2002 17:10:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAK18oMq013413 for ; Tue, 19 Nov 2002 17:08:50 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12294 for ; Tue, 19 Nov 2002 17:08:45 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 147A85B06 for ; Tue, 19 Nov 2002 20:08:45 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Nov 2002 20:08:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for site-local clean-up Date: Tue, 19 Nov 2002 20:08:44 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9BBE@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKPOV1uWI1X8a80TwSutOLnFMXE8gAVGxawAA0EYSAAFpOagAAFSPaA From: "Bound, Jim" To: "Brian Zill" , X-OriginalArrivalTime: 20 Nov 2002 01:08:44.0973 (UTC) FILETIME=[5F7EADD0:01C29031] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAK1A2kd016173 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, ACK. I get it now and agree with your point. thanks /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Brian Zill [mailto:bzill@microsoft.com] > Sent: Tuesday, November 19, 2002 5:50 PM > To: Bound, Jim; ipng@sunroof.eng.sun.com > Subject: RE: Proposal for site-local clean-up > > > Hi Jim, > > > > There needs to be a way to get an address when you don't have a > > > provider. This means either scoped addresses as we have > defined them > > > already (and in multi-link locations, this means either > site-local > > > or multi-link subnet routers and link-local), or some sort of > > > provider-independent address (note there are various > types of these > > > as well, depending upon whether we believe they should be > explicitly > > > non-routable, or privately routable between multiple > > > non-connected 'sites'). > > > > I cannot see anyway to route site-locals across multiple > > sites? Your not saying to do this are you? > > No, I'm not. Site-locals should not be routed across sites. > I was addressing the suggestion others have made which was to > use some sort of yet-to-be-defined provider-independent > addresses instead of site-locals in some situations. My > point on that topic is that there are a range of different > properties such addresses could have (one of which is that > they may or may not be routable across sites). I believe at > least some of the arguments people were having were the > result of different unstated assumptions about what the > properties of such addresses would be. > > > Part of the issue for all this mail is not to kill SLs but > > to make sure we understand them and how to use them and how > to manage > > them and what their affect to users will be. > > That would be my preference as well. > > --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 Nov 20 15:26:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNQIUu019489; Wed, 20 Nov 2002 15:26:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAKNQI9J019486; Wed, 20 Nov 2002 15: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNCeWm018462; Wed, 20 Nov 2002 15:14:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAKDuMbB020645; Wed, 20 Nov 2002 05:56:22 -0800 (PST) Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16162; Wed, 20 Nov 2002 06:56:16 -0700 (MST) Received: from yhhan2.ietf55.ops.ietf.org ([204.42.70.203] helo=yhhan2) by srv0.ops.ietf.org with smtp (Exim 4.10) id 18EVKx-000Fw3-00; Wed, 20 Nov 2002 13:56:15 +0000 Message-ID: <001f01c2909d$3040e620$cb462acc@yhhan2> From: "Youn-Hee Han" To: "James Kempf" Cc: , Subject: Fw: Cached RA v.s. Fast RA Date: Wed, 20 Nov 2002 23:00:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id gAKNQAUw019448 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James Kempf" wrote : > The problem with this proposal is that the AP doesn't exist as far as IETF is > concerned. An AP is not an IP device, and it is not on the map as far as the > Internet architecture is concerned.. Routers do exist and therefore the fast RA > could be standardized in the IETF. Ok. An AP is not an IP device. However, I want to include the AP in the *Mobile IP device* Although the AP is not on the map of IETF, the performance and operability of moble IP will become better if we consider L2 & L3 combination for fast handoff. "draft-mccann-mobileip-80211fh-00.txt" is a 802.11-related draft , and it is runring for being a standardization in IETF. I think that *The AP cahed RAs* can be a standardization in IETF, too. > > That said, I think the proposal is a good one and it should be taken to IEEE > 802.11. Somehow, we need to figure out a way to get 802.11 to pay more attention > to MIP. I agree with you. Currently, we have three 802.11-related works in Mobile IP. 1) Fast-Handover MIPv6 over 802.11 2) AP with the cached RA. 3) L2 trigger API (this may be used in Fast-Handover MIP over 802.11) Maybe, more 802-11 related works will be appeared in the future. Youn-Hee Han > ----- Original Message ----- > From: "Youn-Hee Han" > To: > Sent: Tuesday, November 19, 2002 4:05 PM > Subject: Fw: RE: MIPv6 and ND value changes > > > > Richard wrote : > > > > > I'd add the minor points that section 11.5.2 contains a basic version of > optimistic > > > DAD (its been there since draft 12) and that there AP cached RAs are an > > > alternative to fast RAs in yet another separate draft. > > > > I agree with Richard. > > The AP cahed RAs can be esaily implemented and an alternative to fast RAs. > > IMHO, The AP which cache RAs and sends them to an MN at its association with > > the AP, > > is more deployable approach than router supporting fast RA. > > The change of AP is easier than the change of router. > > > > Youn-Hee Han > > > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Nov 20 15:26:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKMFP1Q017421 for ; Wed, 20 Nov 2002 14:19:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAKM6odi017350; Wed, 20 Nov 2002 14:06:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKM011M017169 for ; Wed, 20 Nov 2002 14:01:22 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAKKpCH22541; Wed, 20 Nov 2002 21:51:13 +0100 (MET) Date: Wed, 20 Nov 2002 21:48:00 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: MIPv6 and ND value changes To: Vijay Devarapalli Cc: Francis Dupont , "Bound, Jim" , Pekka Savola , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3DDA7929.ADB66B44@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 > MIPv6 does not say router should send RAs more frequently. it > just says access routers SHOULD be configurable to send RAs > more frequently. this is to be used in the absense of any L2 > help. Vijay, One part of the problem I see is that your last sentence above doesn't appear in the draft. Getting the applicability of the frequent unsolicited RAs stated is important. Doing this in a short separate draft doesn't have to delay the mipv6 spec, but working out the text before the mipv6 spec get last called will add delay as far as I can tell. 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 Nov 20 15:26:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNQBWw019450; Wed, 20 Nov 2002 15:26:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAKNDpBG018780; Wed, 20 Nov 2002 15:13: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNCTW4018395 for ; Wed, 20 Nov 2002 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.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAKKWJMq024914 for ; Wed, 20 Nov 2002 12:32:19 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00141 for ; Wed, 20 Nov 2002 13:32:13 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id CA43438E8 for ; Wed, 20 Nov 2002 15:32:09 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Nov 2002 15:32:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: draft-ietf-ipv6-node-requirements-01.txt Date: Wed, 20 Nov 2002 15:32:07 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9BEA@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-node-requirements-01.txt Thread-Index: AcKP9uEVt1fGy9tMS4OnF6XTDO8JdAA3I5og From: "Bound, Jim" To: X-OriginalArrivalTime: 20 Nov 2002 20:32:08.0279 (UTC) FILETIME=[E581E670:01C290D3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAKNCmUu018516 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Today in v6ops I think I heard that compliance to the ND M bit being set is optional. That I think is wrong. But the node reqs doc states that dhcpv6 is unconditionally optional which is probably correct because stateful may not imply dhcpv6 today. But if the M bit is set the host node (non router) must look for a stateful node. We need to get this right. P.S. John - I will have all my input on this to you in the next few weeks. But it looks real good. I like the terminology too. Regards. /jim [Honor, Commitment, Integrity] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 15:26:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNQBWq019450; Wed, 20 Nov 2002 15:26:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAKNExX1018960; Wed, 20 Nov 2002 15:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNCeWY018462 for ; Wed, 20 Nov 2002 15:13:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAKEqQbB029913 for ; Wed, 20 Nov 2002 06:52:26 -0800 (PST) Received: from laptop2.kurtis.pp.se (laptop2.ietf55.ops.ietf.org [204.42.72.221]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25249 for ; Wed, 20 Nov 2002 07:52:15 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gAKEouve017085; Wed, 20 Nov 2002 15:51:06 +0100 (CET) Date: Wed, 20 Nov 2002 15:50:55 +0100 Subject: Re: Proposal for site-local clean-up Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "Brian Zill" , To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03240C3B@tayexc13.americas.cpqcorp.net> Message-Id: <791D3C59-FC97-11D6-BC97-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I too am more worried about PI addresses for sure. SLs are much wiser > to support what I believe some want from SLs. > I think these issues are not related. To go or not to go with SL is an address architecture issue. Implications of this decision will affect applications. Not to go might lead us to conclude that we would need PI space but PI or not PI is more of a question for the a routing model than an addressing model. Going for PI space will give us problems in the current routing model but those should be solved there and not with the addressing architecture. - 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 Nov 20 15:26:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNQBX0019450; Wed, 20 Nov 2002 15:26:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAKNFPG8019027; Wed, 20 Nov 2002 15:15:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNCeWu018462 for ; Wed, 20 Nov 2002 15:14:16 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAKDF3bB015400 for ; Wed, 20 Nov 2002 05:15:03 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15409 for ; Wed, 20 Nov 2002 05:14:57 -0800 (PST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKDEOO11122 for ; Wed, 20 Nov 2002 15:14:24 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 20 Nov 2002 14:05:54 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Nov 2002 14:05:54 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Nov 2002 14:05:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Proposed IPv6 W.G. Charter Update Date: Wed, 20 Nov 2002 14:05:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed IPv6 W.G. Charter Update Thread-Index: AcKQiM29CEp3SCbJSyyB8y6X1S5AWwABD95A To: Cc: , , X-OriginalArrivalTime: 20 Nov 2002 12:05:53.0841 (UTC) FILETIME=[2CEE7A10:01C2908D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAKNEGUu018861 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Thomas, > > The Host Requirements document is standards track, so I guess the > > IPv6 Note Requirements should be standards track. > > Info/BCP would seem more appropriate. BCP might be OK and would > provide the stronger label. As discussed at the meeting Monday, BCP seemed acceptable to most everyone, so I assume that is what we should try for. thanks, 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 Nov 20 15:26:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNQBWu019450; Wed, 20 Nov 2002 15:26:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAKNFuaK019105; Wed, 20 Nov 2002 15:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNCTXs018395 for ; Wed, 20 Nov 2002 15:14:36 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAKBYZMq017176 for ; Wed, 20 Nov 2002 03:34:35 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA07832 for ; Wed, 20 Nov 2002 03:34:30 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gAKBYKsL049724; Wed, 20 Nov 2002 06:34:20 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-253-105.mts.ibm.com [9.65.253.105]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAKBYH6N093616; Wed, 20 Nov 2002 06:34:18 -0500 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id gAKBXhp06898; Wed, 20 Nov 2002 06:33:44 -0500 Message-Id: <200211201133.gAKBXhp06898@cichlid.adsl.duke.edu> To: john.loughney@nokia.com cc: hinden@iprg.nokia.com, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Proposed IPv6 W.G. Charter Update In-Reply-To: Message from john.loughney@nokia.com of "Mon, 18 Nov 2002 23:26:30 +0200." Date: Wed, 20 Nov 2002 06:33:43 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The Host Requirements document is standards track, so I guess the > IPv6 Note Requirements should be standards track. Not sure the logic works in this case. The HR doc includes changes/updates to individual specs. I.e., it fixes things within various specs that need fixing. In the case of this document, it's not updating any of the the specs. Another factor. What would it mean for the node requirements document to advance on the standards track? What would the interoperability report contain? Info/BCP would seem more appropriate. BCP might be OK and would provide the stronger label. 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 Nov 20 15:26:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNQBWs019450; Wed, 20 Nov 2002 15:26:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAKNGP3k019173; Wed, 20 Nov 2002 15:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNCTYq018395 for ; Wed, 20 Nov 2002 15:15:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAK6XDMq006210 for ; Tue, 19 Nov 2002 22:33:13 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA21916 for ; Tue, 19 Nov 2002 23:33:07 -0700 (MST) Received: from heavygear ([147.11.233.27]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id WAA26101 for ; Tue, 19 Nov 2002 22:32:47 -0800 (PST) From: "Qing Li" To: "IPng" Subject: draft-ietf-ipv6-rfc2096-update-01.txt Date: Tue, 19 Nov 2002 22:31:58 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <5.1.0.14.2.20021119220040.026447f0@mail.wrs.com> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The ipForward table included "ipForwardProto" as part of the index in RFC1354. Why was the protocol field dropped from the index in RFC2096? In the new draft "inetCidrRouteProto" is not part of the index for the "inetCidrRouteTable". Different routing protocols can insert multiple entries with the same inetCidrRouteDestType, inetCidrRouteDest, inetCidrRoutePfxLen, inetCidrRouteDscp, inetCidrRouteNextHopType, inetCidrRouteNextHop but differnt route age, cost (metric1-5), and even different ifIndex. So IMO the inetCidrRouteProto should be part of the table index in order to uniquely identify an entry. -- Qing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 15:28:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK25akd016259 for ; Tue, 19 Nov 2002 18:05:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAK24FRT016257; Tue, 19 Nov 2002 18:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK21Ukd016250; Tue, 19 Nov 2002 18:02:51 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAK21dbB029871; Tue, 19 Nov 2002 18:01:39 -0800 (PST) Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06931; Tue, 19 Nov 2002 18:01:34 -0800 (PST) Received: from yhhan2.ietf55.ops.ietf.org ([204.42.70.203] helo=yhhan2) by srv0.ops.ietf.org with smtp (Exim 4.10) id 18EKBJ-000B5L-00; Wed, 20 Nov 2002 02:01:33 +0000 Message-ID: <010801c29038$192a5c10$cb462acc@yhhan2> From: "Youn-Hee Han" To: "James Kempf" Cc: , References: <00c401c29028$8dcf9b80$cb462acc@yhhan2> <023a01c2902f$df098180$8f6015ac@T23KEMPF> Subject: Re: Cached RA v.s. Fast RA Date: Wed, 20 Nov 2002 10:56:51 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id gAK22pke016251 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James Kempf" wrote : > The problem with this proposal is that the AP doesn't exist as far as IETF is > concerned. An AP is not an IP device, and it is not on the map as far as the > Internet architecture is concerned.. Routers do exist and therefore the fast RA > could be standardized in the IETF. Ok. An AP is not an IP device. However, I want to include the AP in the *Mobile IP device* Although the AP is not on the map of IETF, the performance and operability of moble IP will become better if we consider L2 & L3 combination for fast handoff. "draft-mccann-mobileip-80211fh-00.txt" is a 802.11-related draft , and it is runring for being a standardization in IETF. I think that *The AP cahed RAs* can be a standardization in IETF, too. > > That said, I think the proposal is a good one and it should be taken to IEEE > 802.11. Somehow, we need to figure out a way to get 802.11 to pay more attention > to MIP. I agree with you. Currently, we have three 802.11-related works in Mobile IP. 1) Fast-Handover MIPv6 over 802.11 2) AP with the cached RA. 3) L2 trigger API (this may be used in Fast-Handover MIP over 802.11) Maybe, more 802-11 related works will be appeared in the future. Youn-Hee Han > ----- Original Message ----- > From: "Youn-Hee Han" > To: > Sent: Tuesday, November 19, 2002 4:05 PM > Subject: Fw: RE: MIPv6 and ND value changes > > > > Richard wrote : > > > > > I'd add the minor points that section 11.5.2 contains a basic version of > optimistic > > > DAD (its been there since draft 12) and that there AP cached RAs are an > > > alternative to fast RAs in yet another separate draft. > > > > I agree with Richard. > > The AP cahed RAs can be esaily implemented and an alternative to fast RAs. > > IMHO, The AP which cache RAs and sends them to an MN at its association with > the AP, > > is more deployable approach than router supporting fast RA. > > The change of AP is easier than the change of router. > > > > Youn-Hee Han > > > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Nov 20 15:28:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNSMUu019673; Wed, 20 Nov 2002 15:28:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAKNSLoa019672; Wed, 20 Nov 2002 15:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNRvUu019644 for ; Wed, 20 Nov 2002 15:27:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAKNS7bB026426 for ; Wed, 20 Nov 2002 15:28:07 -0800 (PST) Received: from realname ([203.254.224.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22281 for ; Wed, 20 Nov 2002 16:28:01 -0700 (MST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0H5W00204ER5UU@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 21 Nov 2002 08:33:05 +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 <0H5W00CKHER52P@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 21 Nov 2002 08:33:05 +0900 (KST) Received: from kps2000 ([168.219.203.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0H5W0051HESNYE@mmp1.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 21 Nov 2002 08:34:00 +0900 (KST) Date: Thu, 21 Nov 2002 08:28:58 +0900 From: Pyungsoo Kim Subject: Re: MIPv6 and ND value changes To: Youn-Hee Han Cc: ipng@sunroof.eng.sun.com Message-id: <002101c290ec$99e1aa20$99cbdba8@PDA.sec.co.kr> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00c401c29028$8dcf9b80$cb462acc@yhhan2> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Han wrote: > I agree with Richard. > The AP cahed RAs can be esaily implemented and an alternative to fast RAs. > IMHO, The AP which cache RAs and sends them to an MN at its association with the AP, > is more deployable approach than router supporting fast RA. > The change of AP is easier than the change of router. > As i know, APs are acting as link-layer relays, which means that they transport Ethernet-layer frames between the wireless medium and the subnet. In other words, APs don't provide the IP functionality. Do you mean that APs should provide the IPv6 functionality to "cache RAs"? Rgds, -pyungsoo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 15:29:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKMT41S017561 for ; Wed, 20 Nov 2002 14:37:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAKMRJ0l017551; Wed, 20 Nov 2002 14:27: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKMND1O017492 for ; Wed, 20 Nov 2002 14:25:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAKMBRMq024453 for ; Wed, 20 Nov 2002 14:11:28 -0800 (PST) Received: from laptop2.kurtis.pp.se (laptop2.ietf55.ops.ietf.org [204.42.72.221]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25227; Wed, 20 Nov 2002 15:11:06 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gAKMBAve015651; Wed, 20 Nov 2002 23:11:22 +0100 (CET) Date: Wed, 20 Nov 2002 16:56:46 +0100 Subject: Re: Proposal for site-local clean-up Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: ipng@sunroof.eng.sun.com To: Erik Nordmark From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > For the disconnected site I think the site-locals work just fine, and > I haven't seen any strong arguments against using site-locals for > a disconnected site. > As many others have pointed out the complexity is not associated > with the case of the disconnected site. > Agreed, however my problem with this is that there is no way to enforce this and people will run away and connect anyway. I think that we also need to address this in whatever solution we decide on... - 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 Nov 20 15:31:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK6P1kf016694 for ; Tue, 19 Nov 2002 22:26:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAK63Q5p016688; Tue, 19 Nov 2002 22:03:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAK60fkd016681 for ; Tue, 19 Nov 2002 22:02:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAK5jqMq029554 for ; Tue, 19 Nov 2002 21:45:52 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA28959 for ; Tue, 19 Nov 2002 22:45:46 -0700 (MST) Received: from heavygear ([147.11.233.27]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id VAA07721; Tue, 19 Nov 2002 21:35:48 -0800 (PST) From: "Qing Li" To: "Thomas Narten" Cc: Subject: RE: question on next-hop determination Date: Tue, 19 Nov 2002 21:34:58 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am still not clear on this because I didn't receive any more replies ... What do you do in the case where the host is multihomed? Which interface do you use to send the packets? I think it introduces more issues than what I think it tries to resolve. Please help me clarify this. -- Qing > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Qing Li > Sent: Thursday, October 10, 2002 7:05 PM > To: Thomas Narten > Cc: ipng@sunroof.eng.sun.com > Subject: RE: question on next-hop determination > > > > > > > > In RFC2461, section 5.2, paragraph 2, the last > > > sentence is "If the Default Router List is empty, > > > the sender assumes that the destination is on-link." > > > > > Why should the destination be considered on-link ?? > > > > Its a last resort. I.e., assuming on-link may be a better as the final > > last step compared with just giving up. > > > > I think the sending host should just drop the packet when the > destination is not covered in its prefix list and there is > no default route installed. Otherwise IMHO this last attempt > would lead to erroneous packet generation, and allows > misconfigured host or host running a buggy implementation to > continue with bad behavior. > > Also the code put in to supporting this looks and feels > like hacks. > > Could you please describe a scenario in which such a situation > might occur, and it makes sense to make this final attempt ?? > > > -- Qing > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 20 15:34:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKMbB1M017662; Wed, 20 Nov 2002 14:38:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAKMbBRE017661; Wed, 20 Nov 2002 14: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKMJU1c017475 for ; Wed, 20 Nov 2002 14:30:23 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAKLVAbB020237 for ; Wed, 20 Nov 2002 13:31:10 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04599 for ; Wed, 20 Nov 2002 13:31:04 -0800 (PST) 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 NAA25050; Wed, 20 Nov 2002 13:31:02 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAKLV1U17363; Wed, 20 Nov 2002 13:31:01 -0800 X-mProtect: <200211202131> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdp9C8z1; Wed, 20 Nov 2002 13:30:59 PST Message-ID: <3DDBFF14.4CBB7769@iprg.nokia.com> Date: Wed, 20 Nov 2002 13:31:00 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Francis Dupont , "Bound, Jim" , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > > One part of the problem I see is that your last sentence above doesn't > appear in the draft. Getting the applicability of the frequent unsolicited > RAs stated is important. > Doing this in a short separate draft doesn't have to delay the mipv6 > spec, but working out the text before the mipv6 spec get last called > will add delay as far as I can tell. Hi Erik, the applicability of frequent RAs can be specified in 1 sentence. "if you have a bandwidth constrained link, dont depend on frequent RAs for movement detection". do we need a separate spec for this? Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 15:46:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNkXUu021678; Wed, 20 Nov 2002 15:46:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAKNkWow021677; Wed, 20 Nov 2002 15:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKNkTUu021668 for ; Wed, 20 Nov 2002 15:46:29 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAKNkeMq024090 for ; Wed, 20 Nov 2002 15:46:40 -0800 (PST) Received: from realname ([203.254.224.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA13396 for ; Wed, 20 Nov 2002 16:46:34 -0700 (MST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0H5W00307FM8WO@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 21 Nov 2002 08:51:44 +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 <0H5W00C6DFM72P@mailout2.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 21 Nov 2002 08:51:44 +0900 (KST) Received: from kps2000 ([168.219.203.153]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0H5W008N6FNQJG@mmp1.samsung.com> for ipng@sunroof.eng.sun.com; Thu, 21 Nov 2002 08:52:38 +0900 (KST) Date: Thu, 21 Nov 2002 08:47:37 +0900 From: Pyungsoo Kim Subject: Re: Cached RA v.s. Fast RA (was Re: RE: MIPv6 and ND value changes) To: James Kempf Cc: Youn-Hee Han , ipng@sunroof.eng.sun.com Message-id: <006301c290ef$348fad90$99cbdba8@PDA.sec.co.kr> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00c401c29028$8dcf9b80$cb462acc@yhhan2> <023a01c2902f$df098180$8f6015ac@T23KEMPF> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James Kempf worte: > The problem with this proposal is that the AP doesn't exist as far as IETF is > concerned. An AP is not an IP device, and it is not on the map as far as the > Internet architecture is concerned.. Routers do exist and therefore the fast RA > could be standardized in the IETF. > > That said, I think the proposal is a good one and it should be taken to IEEE > 802.11. Somehow, we need to figure out a way to get 802.11 to pay more attention > to MIP. > > jak as i know, there are two 802.11 deployments : with relays APs and with integrated AP/AR. thus, i think this proposal(APs cache RAs) can be considered in IETF if 802.11 deployments with "integrated AP/AR" is considered. what do you think? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 16:16:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL0GwUu022160; Wed, 20 Nov 2002 16:16:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL0GwgJ022159; Wed, 20 Nov 2002 16:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL0GsUu022152 for ; Wed, 20 Nov 2002 16:16:54 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAL0H5bB012301 for ; Wed, 20 Nov 2002 16:17:05 -0800 (PST) Received: from starfruit.itojun.org (dhcp-204-42-71-254.ietf55.ops.ietf.org [204.42.71.254]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01505 for ; Wed, 20 Nov 2002 16:16:59 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id B06037AF; Thu, 21 Nov 2002 09:16:55 +0900 (JST) To: "Qing Li" Cc: "Thomas Narten" , ipng@sunroof.eng.sun.com In-reply-to: Qing.Li's message of Tue, 19 Nov 2002 21:34:58 PST. 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: question on next-hop determination From: Jun-ichiro itojun Hagino Date: Thu, 21 Nov 2002 09:16:55 +0900 Message-Id: <20021121001655.B06037AF@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> > > In RFC2461, section 5.2, paragraph 2, the last >> > > sentence is "If the Default Router List is empty, >> > > the sender assumes that the destination is on-link." >> > >> > > Why should the destination be considered on-link ?? >> > >> > Its a last resort. I.e., assuming on-link may be a better as the final >> > last step compared with just giving up. > I am still not clear on this because I didn't receive > any more replies ... > > What do you do in the case where the host is multihomed? > Which interface do you use to send the packets? > > I think it introduces more issues than what I think it tries > to resolve. i also find this part of specification very weird. in what kind of situation does this behavior help nodes? also, as Qing pointed out a node cannot decide which interface it should send out the packet. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 16:36:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL0a4Uu022314; Wed, 20 Nov 2002 16:36:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL0a3ee022313; Wed, 20 Nov 2002 16:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL0a0Uu022306 for ; Wed, 20 Nov 2002 16:36:00 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAL0aBMq008711 for ; Wed, 20 Nov 2002 16:36:11 -0800 (PST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07825 for ; Wed, 20 Nov 2002 17:36:06 -0700 (MST) Message-ID: <00a401c290f5$bd1a4d40$ab6015ac@T23KEMPF> From: "James Kempf" To: "Pyungsoo Kim" Cc: "Youn-Hee Han" , References: <00c401c29028$8dcf9b80$cb462acc@yhhan2> <023a01c2902f$df098180$8f6015ac@T23KEMPF> <006301c290ef$348fad90$99cbdba8@PDA.sec.co.kr> Subject: Re: Cached RA v.s. Fast RA (was Re: RE: MIPv6 and ND value changes) Date: Wed, 20 Nov 2002 16:33:52 -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 > > The problem with this proposal is that the AP doesn't exist as far as IETF is > > concerned. An AP is not an IP device, and it is not on the map as far as the > > Internet architecture is concerned.. Routers do exist and therefore the fast RA > > could be standardized in the IETF. > > > > That said, I think the proposal is a good one and it should be taken to IEEE > > 802.11. Somehow, we need to figure out a way to get 802.11 to pay more attention > > to MIP. > > > > jak > > as i know, there are two 802.11 deployments : with relays APs and with integrated AP/AR. > thus, i think this proposal(APs cache RAs) can be considered in IETF if 802.11 deployments with "integrated AP/AR" is considered. what do you think? > If the AP and AR are integrated, then this proposal is no different than having the router send the RA after the MN has done the reassociate and 802.1x, if any. Again, a good idea in any case. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 16:52:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL0q9Uu022455; Wed, 20 Nov 2002 16:52:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL0q9NN022454; Wed, 20 Nov 2002 16:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL0q5Uu022443 for ; Wed, 20 Nov 2002 16:52:05 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAL0qFMq012742 for ; Wed, 20 Nov 2002 16:52:16 -0800 (PST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03152 for ; Wed, 20 Nov 2002 16:52:10 -0800 (PST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAL0qwR05498 for ; Thu, 21 Nov 2002 02:52:58 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Nov 2002 02:52:08 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 02:52:08 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 02:52:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft-ietf-ipv6-node-requirements-01.txt Date: Thu, 21 Nov 2002 02:52:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-node-requirements-01.txt Thread-Index: AcKP9uEVt1fGy9tMS4OnF6XTDO8JdAA3I5ogAAkg0yA= To: , X-OriginalArrivalTime: 21 Nov 2002 00:52:08.0075 (UTC) FILETIME=[37B5DDB0:01C290F8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAL0q5Uu022444 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, > Today in v6ops I think I heard that compliance to the ND M bit being set > is optional. That I think is wrong. But the node reqs doc states that > dhcpv6 is unconditionally optional which is probably correct because > stateful may not imply dhcpv6 today. But if the M bit is set the host > node (non router) must look for a stateful node. We need to get this > right. > > P.S. John - I will have all my input on this to you in the next few > weeks. But it looks real good. I like the terminology too. Glad you think that the document looks good. Review it & let me know what you think - especially suggest what text you think is needed for the M bit. 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 Nov 20 17:33:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL1XFUu022675; Wed, 20 Nov 2002 17:33:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL1XFUh022674; Wed, 20 Nov 2002 17:33: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL1XCUu022667 for ; Wed, 20 Nov 2002 17:33:12 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAL1XMbB004424 for ; Wed, 20 Nov 2002 17:33:22 -0800 (PST) Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03811 for ; Wed, 20 Nov 2002 18:33:17 -0700 (MST) Received: from dhcp-204-42-68-213.ietf55.ops.ietf.org ([204.42.68.213] helo=eng.monash.edu.au) by srv0.ops.ietf.org with esmtp (Exim 4.10) id 18EgDR-000KMF-00; Thu, 21 Nov 2002 01:33:13 +0000 Message-ID: <3DDCC441.3F553D7F@eng.monash.edu.au> Date: Thu, 21 Nov 2002 11:32:17 +0000 From: Richard Nelson X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.19hilc i686) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Pyungsoo Kim , Youn-Hee Han , ipng@sunroof.eng.sun.com Subject: Re: Cached RA v.s. Fast RA (was Re: RE: MIPv6 and ND value changes) References: <00c401c29028$8dcf9b80$cb462acc@yhhan2> <023a01c2902f$df098180$8f6015ac@T23KEMPF> <006301c290ef$348fad90$99cbdba8@PDA.sec.co.kr> <00a401c290f5$bd1a4d40$ab6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James Kempf wrote: > > > > as i know, there are two 802.11 deployments : with relays APs and with > integrated AP/AR. > > thus, i think this proposal(APs cache RAs) can be considered in IETF if > 802.11 deployments with "integrated AP/AR" is considered. what do you think? > > > > If the AP and AR are integrated, then this proposal is no different than having > the router send the RA after the MN has done the reassociate and 802.1x, if any. > Again, a good idea in any case. > > Yes, L2 triggers at the AR is a good idea, but it doesn't solve the separate AR AP case. Would it help to call the AR an RA proxy ;-) jak > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 20 17:43:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL1hXUu022757; Wed, 20 Nov 2002 17:43:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL1hXXa022756; Wed, 20 Nov 2002 17:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL1hUUu022749 for ; Wed, 20 Nov 2002 17:43:30 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAL1hfbB006711 for ; Wed, 20 Nov 2002 17:43:41 -0800 (PST) Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27484; Wed, 20 Nov 2002 17:43:35 -0800 (PST) Received: from dhcp-204-42-68-213.ietf55.ops.ietf.org ([204.42.68.213] helo=eng.monash.edu.au) by srv0.ops.ietf.org with esmtp (Exim 4.10) id 18EgNO-000KRF-00; Thu, 21 Nov 2002 01:43:30 +0000 Message-ID: <3DDCC6A6.3710B69C@eng.monash.edu.au> Date: Thu, 21 Nov 2002 11:42:30 +0000 From: Richard Nelson X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.19hilc i686) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Vijay Devarapalli , Francis Dupont , "Bound, Jim" , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft covers this quite well near the end of section 7.5. It talks specifically about low bandwidth networks which maybe could be expanded to include any network where L2 support is available, but I think the intent is pretty clear. Richard. Erik Nordmark wrote: > > > MIPv6 does not say router should send RAs more frequently. it > > just says access routers SHOULD be configurable to send RAs > > more frequently. this is to be used in the absense of any L2 > > help. > > Vijay, > > One part of the problem I see is that your last sentence above doesn't > appear in the draft. Getting the applicability of the frequent unsolicited > RAs stated is important. > Doing this in a short separate draft doesn't have to delay the mipv6 > spec, but working out the text before the mipv6 spec get last called > will add delay as far as I can tell. > > Erik > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 18:02:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL22jUu022913; Wed, 20 Nov 2002 18:02:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL22iVx022912; Wed, 20 Nov 2002 18:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL22fUu022905 for ; Wed, 20 Nov 2002 18:02:41 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAL22qbB011041 for ; Wed, 20 Nov 2002 18:02:52 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16172 for ; Wed, 20 Nov 2002 19:02:46 -0700 (MST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gAL226sA001660; Wed, 20 Nov 2002 18:02:06 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAQ98258; Wed, 20 Nov 2002 17:56:42 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA17365; Wed, 20 Nov 2002 18:02:19 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15836.16043.137216.970336@thomasm-u1.cisco.com> Date: Wed, 20 Nov 2002 18:02:19 -0800 (PST) To: Erik Nordmark Cc: Vijay Devarapalli , Francis Dupont , "Bound, Jim" , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes In-Reply-To: References: <3DDA7929.ADB66B44@iprg.nokia.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 So I listened to this argument for a very long time (too long) yesterday wondering what on earth the big deal was. I still don't get it. If people want to dial up the ND rate, it only hurts their link. There's no greater internet impact that I can see. If it's taking up too much bandwidth, a sniffer would show it pretty quickly and you turn the knob down, so wo cares? That said, I do think this is a pretty poor substitute for L2 information which probably should be making its way up the driver. Mike Erik Nordmark writes: > > MIPv6 does not say router should send RAs more frequently. it > > just says access routers SHOULD be configurable to send RAs > > more frequently. this is to be used in the absense of any L2 > > help. > > Vijay, > > One part of the problem I see is that your last sentence above doesn't > appear in the draft. Getting the applicability of the frequent unsolicited > RAs stated is important. > Doing this in a short separate draft doesn't have to delay the mipv6 > spec, but working out the text before the mipv6 spec get last called > will add delay as far as I can tell. > > Erik > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 18:10:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL2AvUu023044; Wed, 20 Nov 2002 18:10:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL2AvUA023043; Wed, 20 Nov 2002 18:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL2ArUu023033 for ; Wed, 20 Nov 2002 18:10:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAL2B4Mq002004 for ; Wed, 20 Nov 2002 18:11:04 -0800 (PST) Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA10786 for ; Wed, 20 Nov 2002 19:10:58 -0700 (MST) Received: from dhcp-204-42-68-213.ietf55.ops.ietf.org ([204.42.68.213] helo=eng.monash.edu.au) by srv0.ops.ietf.org with esmtp (Exim 4.10) id 18Egnt-000Kdq-00; Thu, 21 Nov 2002 02:10:57 +0000 Message-ID: <3DDCCD07.41FF057D@eng.monash.edu.au> Date: Thu, 21 Nov 2002 12:09:43 +0000 From: Greg Daley X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.19hilc i686) X-Accept-Language: en MIME-Version: 1.0 To: "Bound, Jim" CC: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipv6-node-requirements-01.txt References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9BEA@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, I find it hard to tell if you mean it is wrong (incorrect) or wrong (not the right way to go). about the current status though, section 5.4.5 of RFC 2462 mentions that a node which receives the M flag goes should undertake stateful address configuration. there is no MUST requirement in that section, though section 5.5 does say "the processing described below MUST be enabled by default" If the intention was that nodes which have DHCP/managed capability support this when the M flag is set, it's unclear. At the moment, it looks optional to implementors. Does it require update? Comments? Greg "Bound, Jim" wrote: > > Today in v6ops I think I heard that compliance to the ND M bit being set > is optional. That I think is wrong. But the node reqs doc states that > dhcpv6 is unconditionally optional which is probably correct because > stateful may not imply dhcpv6 today. But if the M bit is set the host > node (non router) must look for a stateful node. We need to get this > right. > > P.S. John - I will have all my input on this to you in the next few > weeks. But it looks real good. I like the terminology too. > > Regards. > > /jim > [Honor, Commitment, Integrity] > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 20 18:14:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL2EnUu023188; Wed, 20 Nov 2002 18:14:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL2EnM2023187; Wed, 20 Nov 2002 18:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL2EkUu023180; Wed, 20 Nov 2002 18:14:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAL2EvMq002959; Wed, 20 Nov 2002 18:14:57 -0800 (PST) Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21682; Wed, 20 Nov 2002 19:14:51 -0700 (MST) Received: from yhhan2.ietf55.ops.ietf.org ([204.42.70.203] helo=yhhan2) by srv0.ops.ietf.org with smtp (Exim 4.10) id 18Egri-000KfJ-00; Thu, 21 Nov 2002 02:14:50 +0000 Message-ID: <02f701c29104$5f2cbf60$cb462acc@yhhan2> From: "Youn-Hee Han" To: "Pyungsoo Kim" Cc: , References: <00c401c29028$8dcf9b80$cb462acc@yhhan2> <002101c290ec$99e1aa20$99cbdba8@PDA.sec.co.kr> Subject: Re: Cached RA v.s. Fast RA (was Re: RE: MIPv6 and ND value changes) Date: Thu, 21 Nov 2002 11:19:04 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id gAL2EkUv023181 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk pyungsoo wrote : > As i know, APs are acting as link-layer relays, which means that they transport > Ethernet-layer frames between the wireless medium and the subnet. > In other words, APs don't provide the IP functionality. Ok. I see. > Do you mean that APs should provide the IPv6 functionality to "cache RAs"? I am telling about an advanced MIPv6 issue "Eliminsation of the random delay before sending an RA." Brett Pentland said that the followings are a number of MIPv6-optimization discussed on the mailing list. Optimistic DAD - Fast router advertisements - Fast router discovery with AP notification - Duplicate Address Detection Optimization using IPv6 Multicast Listener Discovery - I think that the above documents are worth discussing in the next step of mobileip WG. The second document is related to *Fast RA*, and the third document is related to *Cached RA*. In my opinion, the Kempf's *Fast RA* is a good idea because it only requires the change of router, IP device. However, I don't want to combine the idea with the current MIPv6 spec , since many MIPv6 guys urge MIPv6 to be a standization. As a seperate draft, we had better discuss the idea. The third document is a good idea, too. 'AP cached RA' is a simple and easy-deployable method which can reduce the L3 handover time of mobile nodes. Yes. The idea is to insert the small part of IPv6 functionality into APs. As far as I understand, the idea can be an alternative to fast RAs in another separate draft. > as i know, there are two 802.11 deployments : with relays APs and with integrated AP/AR. > thus, i think this proposal(APs cache RAs) can be considered in IETF if 802.11 > deployments with "integrated AP/AR" is considered. what do you think? I agree with James Kempf. In an integrated AP/AR, 'AP cached RA' is no different than having the router send the RA after the MN has done the reassociation. Youn-Hee Han. ----- Original Message ----- From: "Pyungsoo Kim" To: "Youn-Hee Han" Cc: Sent: Thursday, November 21, 2002 8:28 AM Subject: Re: MIPv6 and ND value changes > Han wrote: > > > I agree with Richard. > > The AP cahed RAs can be esaily implemented and an alternative to fast RAs. > > IMHO, The AP which cache RAs and sends them to an MN at its association with the AP, > > is more deployable approach than router supporting fast RA. > > The change of AP is easier than the change of router. > > > > As i know, APs are acting as link-layer relays, which means that they transport > Ethernet-layer frames between the wireless medium and the subnet. > In other words, APs don't provide the IP functionality. > Do you mean that APs should provide the IPv6 functionality to "cache RAs"? > > Rgds, > -pyungsoo > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 20 19:04:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL34lUu023684; Wed, 20 Nov 2002 19:04:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL34kTp023683; Wed, 20 Nov 2002 19:04:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL34eUu023665 for ; Wed, 20 Nov 2002 19:04:41 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAL34jH20898; Thu, 21 Nov 2002 04:04:45 +0100 (MET) Date: Thu, 21 Nov 2002 04:01:32 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Proposal for site-local clean-up To: Richard Draves Cc: Keith Moore , Michael Thomas , Brian Zill , 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 > First, site-locals offer better security than a single firewall, because > typically there will be multiple routers on the path between an attacker > and a customer site, all filtering site-locals. Second, I agree that > strong security is great and we should work towards it. But "defense in > depth" argues for having multiple security mechanisms, so even with > strong security I think site-locals and firewalls have a place. This assumes that ISPs will use site-locals. So far I haven't seen any claims of benefits for ISPs to configure site boundaries and use site-local addresses in their network. If the ISPs don't use it the only boundaries would be at the attacker (which might be able to control its site boundary) and at the attacked site, thus no additional depth. Any ISPs care to comment on this? 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 Nov 20 19:15:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL3FeUu023809; Wed, 20 Nov 2002 19:15:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL3Fdt9023808; Wed, 20 Nov 2002 19:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL3FaUu023801 for ; Wed, 20 Nov 2002 19:15:36 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAL3FlbB026569 for ; Wed, 20 Nov 2002 19:15:47 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05055 for ; Wed, 20 Nov 2002 19:15:42 -0800 (PST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 20 Nov 2002 19:15:16 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 20 Nov 2002 19:15:25 -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.3710.0); Wed, 20 Nov 2002 19:15:26 -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); Wed, 20 Nov 2002 19:15:24 -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.3710.0); Wed, 20 Nov 2002 19:15:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Proposal for site-local clean-up Date: Wed, 20 Nov 2002 19:15:23 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up Thread-Index: AcKQ6r2F7X7KyCIrS+uPzJpNKqW1egAH+CHR From: "Christian Huitema" To: "Keith Moore" Cc: X-OriginalArrivalTime: 21 Nov 2002 03:15:24.0996 (UTC) FILETIME=[3BDFE840:01C2910C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAL3FaUu023802 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Perhaps more importantly, I don't buy the argument that *any* set of > addresses should be considered trustworthy, by default or otherwise. > Addresses are simply not sufficient as an authentication mechanism. > This is not a practice that IETF standards should endorse or encourage. I certainly agree with your first point: considering a block of addresses trustworthy is silly. What site locals give you is a component of "defense in depth": if an application listen only to a local scope addresses, it will not receive any packet that come directly from the Internet. Like it or not, that is a sizeable risk reduction, even if it is indeed possible to receive packets from a compromised local host, or from a clandestine attachment to the local network. But clearly, that is not sufficient: applications shall indeed check the credentials of their remote users, not just the addresses. -- 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 Nov 20 19:23:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL3NfUu023944; Wed, 20 Nov 2002 19:23:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL3NfGx023943; Wed, 20 Nov 2002 19:23: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL3NcUu023936 for ; Wed, 20 Nov 2002 19:23:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAL3NmMq020380 for ; Wed, 20 Nov 2002 19:23:49 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17554; Wed, 20 Nov 2002 20:23:42 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAL3Nep17559; Thu, 21 Nov 2002 05:23:41 +0200 Date: Thu, 21 Nov 2002 05:23:40 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Richard Draves , Keith Moore , Michael Thomas , Brian Zill , Subject: RE: Proposal for site-local clean-up 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, 21 Nov 2002, Erik Nordmark wrote: > This assumes that ISPs will use site-locals. So far I haven't seen any > claims of benefits for ISPs to configure site boundaries and use site-local > addresses in their network. > If the ISPs don't use it the only boundaries would be at the attacker (which > might be able to control its site boundary) and at the attacked site, thus > no additional depth. > > Any ISPs care to comment on this? We surely don't use site-locals, never intend to, or never intend to block them in any way (except for standard ingress filtering). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 19:38:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL3cpUu024068; Wed, 20 Nov 2002 19:38:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL3copE024067; Wed, 20 Nov 2002 19:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL3clUu024060 for ; Wed, 20 Nov 2002 19:38:47 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAL3cwbB000688 for ; Wed, 20 Nov 2002 19:38:58 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14325 for ; Wed, 20 Nov 2002 19:38:53 -0800 (PST) Subject: RE: Proposal for site-local clean-up Date: Wed, 20 Nov 2002 19:38:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B04640BD400@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up thread-index: AcKRC2wdoy6kRagYQDu8j5KnYca+7AAAtSdQ From: "Michel Py" To: "Erik Nordmark" , "Richard Draves" Cc: "Keith Moore" , "Michael Thomas" , "Brian Zill" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAL3cmUu024061 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, >> Richard Draves wrote: >> First, site-locals offer better security than a >> single firewall, because typically there will be >> multiple routers on the path between an attacker >> and a customer site, all filtering site-locals. >> Second, I agree that strong security is great >> and we should work towards it. But "defense in >> depth" argues for having multiple security >> mechanisms, so even with strong security I think >> site-locals and firewalls have a place. > Erik Nordmark wrote: > This assumes that ISPs will use site-locals. Where does this come from? There is nothing in Richard's text that implies anything about the ISPs _using_ site locals. It talks about _filtering_ 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 Wed Nov 20 20:08:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL48CUu024216; Wed, 20 Nov 2002 20:08:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL48CNG024215; Wed, 20 Nov 2002 20:08: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL489Uu024208 for ; Wed, 20 Nov 2002 20:08:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAL48KMq026900 for ; Wed, 20 Nov 2002 20:08:20 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03711 for ; Wed, 20 Nov 2002 21:08:14 -0700 (MST) Received: from heavygear ([147.11.233.28]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id UAA25318 for ; Wed, 20 Nov 2002 20:07:55 -0800 (PST) From: "Qing Li" To: "IPng" Subject: clarification needed on draft-ietf-ipv6-rfc2011-update-01.txt Date: Wed, 20 Nov 2002 20:07:07 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please help me clarify the consequences of a SET operation on the "ipv6InterfaceAdminStatus" specified in this draft, and its relation to RFC2461 and RFC2462. In RFC2462 section 5.3 , "A node forms a link-local address whenever an interface becomes enabled. An interface may become enabled after any of the following events: ... The interface becomes enabled by system management after having been administratively disabled." So my reading on this is that when "ipv6InterfaceAdminstatus" is SET to down (2) then up (1), stateless autoconfig is restarted and DAD is performed again. In RFC2461 section 7.2.6, however, it states "In some cases a node may be able to determine that its link-layer address has changed (e.g. hot-swap of an interface card) and may wish to inform its neighbors of the new link-layer address quickly. ..." I think these 2 paragraphs are somewhat in conflict with each other. The time it takes for the host to detect the change in LLAddr is indeterminate. During this period some other host might have claimed the addresses that are in use. So I think DAD should be restarted when the host detects a change in LLAddr. If the interface is shutdown through ipv6InterfaceAdminstatus, or if the host detects a downed interface, my questions are: 1. What happens to the prefixes learned over that interface? If I were to toss the prefixes immediately then consequently I will be invaliding my assigned addresses. This will invalidate all of my TCP connections, too. So I probably would want to keep these around until the lifetime expires. On the other hand I would need to do something so that new connection would not use any address configured out of those prefixes. 2. Should the prefix routes be removed or marked as unusable? I think the prefix routes should be marked as unusable instead removal because of the lifetimes associated with them. 3. Should the neighbor cache be flushed? -- Qing -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 20:49:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL4n2Uu024359; Wed, 20 Nov 2002 20:49:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL4n2bY024358; Wed, 20 Nov 2002 20:49:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL4mwUu024348; Wed, 20 Nov 2002 20:48:58 -0800 (PST) Received: from eng.sun.com (vpn-129-147-152-133.Central.Sun.COM [129.147.152.133]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL4n7bS961667; Wed, 20 Nov 2002 20:49:08 -0800 (PST) Message-ID: <3DDC66DB.94ACBF97@eng.sun.com> Date: Wed, 20 Nov 2002 20:53:47 -0800 From: Samita Chakrabarti X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com CC: samita.chakrabarti@Sun.COM Subject: Proposal for MIPv6 APIs to switch default source address selection Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API document. The following requirements in MIPv6 spec indicates that there is a need for Socket API which will allow the MIPv6 applications to choose COA as mobile node's source address (in a visited network), while default address selection draft prefers home address as the default source address (section 5 and 6 rule 4). The MIPV6 API should also take care of choosing temporary address and non-temporary address from the application level. Also, there is a need to choose link-local or site-local address as source address (depending on the scope) for the MN while visiting (see below). My question is, if anybody in IPv6 working group is currently working on such API for default address selection draft ? If not, I propose to add these APIs to the MIPv6 Advanced API document, as they are quite Mobile IP specific in usage. -Samita -------------------------------------------------------------------- Mobile IPv6 draft 19 Section 11.3.1 states, The mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, not requiring the use of a Home Address option in the packet. This is particularly useful for short-term communication that may easily be retried if it fails. An example of this type of communication might be DNS queries sent by the mobile node [27, 28]. Using the mobile node's care-of address as the source for such queries will generally have a lower overhead than using the mobile node's home address, since no extra options need be used in either the query or its reply. Such packets can be routed normally, directly between their source and destination without relying on Mobile IPv6. If application running on the mobile node has no particular knowledge that the communication being sent fits within this general type of communication, however, the mobile node SHOULD NOT use its care-of address as the source of the packet in this way. : : : While not at its home link, the mobile node MUST NOT use its home address (or the home address destination option) in Neighbor Discovery messages on the visited link. The mobile node also MUST NOT use its home address when communicating with link-local or site-local peers on the visited link, if the scope of the home address is larger than the scope of the peer's address. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 20:58:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL4wgUu024449; Wed, 20 Nov 2002 20:58:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL4wgiN024448; Wed, 20 Nov 2002 20:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL4wcUu024441; Wed, 20 Nov 2002 20:58:39 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAL4wnMq003529; Wed, 20 Nov 2002 20:58:49 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21073; Wed, 20 Nov 2002 21:58:43 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian -4) with ESMTP id gAL4xCGR017517; Thu, 21 Nov 2002 13:59:13 +0900 Date: Wed, 20 Nov 2002 23:59:12 -0500 (EST) Message-Id: <20021120.235912.47995659.yoshfuji@linux-ipv6.org> To: samita@eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, samita.chakrabarti@Sun.COM Subject: Re: Proposal for MIPv6 APIs to switch default source address selection From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <3DDC66DB.94ACBF97@eng.sun.com> References: <3DDC66DB.94ACBF97@eng.sun.com> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 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 In article <3DDC66DB.94ACBF97@eng.sun.com> (at Wed, 20 Nov 2002 20:53:47 -0800), Samita Chakrabarti says: > My question is, if anybody in IPv6 working group is currently working on > such > API for default address selection draft ? > > If not, I propose to add these APIs to the MIPv6 Advanced API document, > as they are quite Mobile IP specific in usage. I believe they should be handled by ipv6wg if the document contains temporary address vs public address and/or scope preferences. --yoshfuji -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 20 21:11:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL5BLUu024712; Wed, 20 Nov 2002 21:11:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAL5BLei024711; Wed, 20 Nov 2002 21:11:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL5BIUu024704; Wed, 20 Nov 2002 21:11:18 -0800 (PST) Received: from eng.sun.com (vpn-129-147-152-133.Central.Sun.COM [129.147.152.133]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAL5BQbS963601; Wed, 20 Nov 2002 21:11:27 -0800 (PST) Message-ID: <3DDC6C16.AFF286F1@eng.sun.com> Date: Wed, 20 Nov 2002 21:16:06 -0800 From: Samita Chakrabarti X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: YOSHIFUJI@eng.sun.com, Hideaki@eng.sun.com, yoshfuji@linux-ipv6.org CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Proposal for MIPv6 APIs to switch default source addressselection References: <3DDC66DB.94ACBF97@eng.sun.com> <20021120.235912.47995659.yoshfuji@linux-ipv6.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > > In article <3DDC66DB.94ACBF97@eng.sun.com> (at Wed, 20 Nov 2002 20:53:47 -0800), Samita Chakrabarti says: > > > My question is, if anybody in IPv6 working group is currently working on > > such > > API for default address selection draft ? > > > > If not, I propose to add these APIs to the MIPv6 Advanced API document, > > as they are quite Mobile IP specific in usage. > > I believe they should be handled by ipv6wg if the document contains > temporary address vs public address and/or scope preferences. > One alternative has been suggested that initially they could be written into the MIPv6 Adv-API document which perhaps can be folded into future IPv6 ADV-API RFC. I agree that the APIs to switch source address selection would be useful for non-MIPv6 cases as well. Thanks for your input. -Samita -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 04:55:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALCtuUu025772; Thu, 21 Nov 2002 04:55:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALCtuHm025771; Thu, 21 Nov 2002 04:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALCtrUu025764 for ; Thu, 21 Nov 2002 04:55:53 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALCu3bB013364 for ; Thu, 21 Nov 2002 04:56:03 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14197 for ; Thu, 21 Nov 2002 04:55:57 -0800 (PST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-427.cisco.com [10.82.241.171]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA18598; Thu, 21 Nov 2002 07:55:43 -0500 (EST) Message-Id: <4.3.2.7.2.20021121075421.03d2bb38@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Nov 2002 07:55:38 -0500 To: Greg Daley , john.loughney@nokia.com From: Ralph Droms Subject: Re: draft-ietf-ipv6-node-requirements-01.txt Cc: "Bound, Jim" , ipng@sunroof.eng.sun.com In-Reply-To: <3DDCCD07.41FF057D@eng.monash.edu.au> References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9BEA@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There may be some additional discussion about the 'M' and 'O' bits during my slot in the ipv6 WG meeting Thu AM. - Ralph At 12:09 PM 11/21/2002 +0000, Greg Daley wrote: >Hi Jim, > >I find it hard to tell if you mean it is wrong (incorrect) or >wrong (not the right way to go). > >about the current status though, > >section 5.4.5 of RFC 2462 mentions that a node which receives the >M flag goes should undertake stateful address configuration. >there is no MUST requirement in that section, though section 5.5 >does say > >"the processing described below MUST be enabled by default" > >If the intention was that nodes which have DHCP/managed capability >support this when the M flag is set, it's unclear. At the moment, >it looks optional to implementors. > >Does it require update? Comments? > >Greg > > >"Bound, Jim" wrote: > > > > Today in v6ops I think I heard that compliance to the ND M bit being set > > is optional. That I think is wrong. But the node reqs doc states that > > dhcpv6 is unconditionally optional which is probably correct because > > stateful may not imply dhcpv6 today. But if the M bit is set the host > > node (non router) must look for a stateful node. We need to get this > > right. > > > > P.S. John - I will have all my input on this to you in the next few > > weeks. But it looks real good. I like the terminology too. > > > > Regards. > > > > /jim > > [Honor, Commitment, Integrity] > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Nov 21 05:36:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALDaYUu025899; Thu, 21 Nov 2002 05:36:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALDaYGe025898; Thu, 21 Nov 2002 05:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALDaUUu025891 for ; Thu, 21 Nov 2002 05:36:30 -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 gALDaPH10854; Thu, 21 Nov 2002 14:36:25 +0100 (MET) Date: Thu, 21 Nov 2002 14:33:12 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Proposal for site-local clean-up To: Michel Py Cc: Erik Nordmark , Richard Draves , Keith Moore , Michael Thomas , Brian Zill , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <2B81403386729140A3A899A8B39B04640BD400@server2000> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > This assumes that ISPs will use site-locals. > > Where does this come from? There is nothing in Richard's text that > implies anything about the ISPs _using_ site locals. It talks about > _filtering_ them. Sorry, I meant to say "using them by configuring site boundaries" but I agree that it is sufficient to filter them. 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 Nov 21 05:44:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALDiuUu026009; Thu, 21 Nov 2002 05:44:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALDitxX026008; Thu, 21 Nov 2002 05:44:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALDipUu026001 for ; Thu, 21 Nov 2002 05:44:52 -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 gALDivH11503; Thu, 21 Nov 2002 14:44:57 +0100 (MET) Date: Thu, 21 Nov 2002 14:41:42 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Proposal for site-local clean-up To: Christian Huitema Cc: Keith Moore , 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 > I certainly agree with your first point: considering a block of addresses > trustworthy is silly. What site locals give you is a component of "defense > in depth": if an application listen only to a local scope addresses, it will > not receive any packet that come directly from the Internet. Like it or not, > that is a sizeable risk reduction, even if it is indeed possible to receive > packets from a compromised local host, or from a clandestine attachment to > the local network. But clearly, that is not sufficient: applications shall > indeed check the credentials of their remote users, not just the addresses. The actual benefit of this is a function of what messages folks deliver to users and application writers. If folks say that site-locals provide a security benefit the users and app writers might be less careful, potentially removing any benefit. Thus I would argue that one should get users and programmers to *think* about site-locals as globals from a security perspective. I think that would be hard. 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 Nov 21 06:10:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALEAkUu026149; Thu, 21 Nov 2002 06:10:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALEAkxZ026148; Thu, 21 Nov 2002 06:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALEAgUu026141 for ; Thu, 21 Nov 2002 06:10:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALEApbB023226 for ; Thu, 21 Nov 2002 06:10:52 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08157 for ; Thu, 21 Nov 2002 07:10:46 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gALEAal15067; Thu, 21 Nov 2002 09:10:36 -0500 (EST) Message-Id: <200211211410.gALEAal15067@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Christian Huitema" cc: "Keith Moore" , ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up In-reply-to: (Your message of "Wed, 20 Nov 2002 19:15:23 PST.") Date: Thu, 21 Nov 2002 09:10:36 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Perhaps more importantly, I don't buy the argument that *any* set of > > addresses should be considered trustworthy, by default or otherwise. > > Addresses are simply not sufficient as an authentication mechanism. > > This is not a practice that IETF standards should endorse or encourage. > > I certainly agree with your first point: considering a block of addresses > trustworthy is silly. What site locals give you is a component of "defense in > depth": if an application listen only to a local scope addresses, it will not > receive any packet that come directly from the Internet. Like it or not, that > is a sizeable risk reduction, even if it is indeed possible to receive packets > from a compromised local host, or from a clandestine attachment to the local > network. you have not demonstrated that this is a sizable risk reduction. another problem with this argument is that it doesn't consider the increase in risk that comes with using site locals, due to the impaired ability to detect external traffic. essentially if you are trusting site locals then you are trusting the filters on the border router with no way to verify whether they are working. > But clearly, that is not sufficient: applications shall indeed check > the credentials of their remote users, not just the addresses. applications need to check the credentials of *all* users. trusting any address is a security hole. it prevents the very "defense in depth" you are claiming is an advantage of site locals. 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 Nov 21 06:18:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALEIeUu026210; Thu, 21 Nov 2002 06:18:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALEIema026209; Thu, 21 Nov 2002 06:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALEIaUu026202 for ; Thu, 21 Nov 2002 06:18:36 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALEIjbB024343 for ; Thu, 21 Nov 2002 06:18:46 -0800 (PST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11445 for ; Thu, 21 Nov 2002 07:18:36 -0700 (MST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gALEIWm00949; Thu, 21 Nov 2002 15:18:32 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gALEIVte038662; Thu, 21 Nov 2002 15:18:31 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211211418.gALEIVte038662@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Erik Nordmark , Vijay Devarapalli , "Bound, Jim" , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes In-reply-to: Your message of Wed, 20 Nov 2002 18:02:19 PST. <15836.16043.137216.970336@thomasm-u1.cisco.com> Date: Thu, 21 Nov 2002 15:18:31 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: So I listened to this argument for a very long time (too long) yesterday wondering what on earth the big deal was. I still don't get it. If people want to dial up the ND rate, it only hurts their link. There's no greater internet impact that I can see. If it's taking up too much bandwidth, a sniffer would show it pretty quickly and you turn the knob down, so wo cares? => I agree but I have a concern to get this in an unclear spec, i.e., as a network manager, I'd not like to get request to put silly RA timing because it is written somewhere. That said, I do think this is a pretty poor substitute for L2 information which probably should be making its way up the driver. => 100% agree Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 06:40:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALEeTUu026347; Thu, 21 Nov 2002 06:40:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALEeTUC026346; Thu, 21 Nov 2002 06:40: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALEeJUu026331; Thu, 21 Nov 2002 06:40:19 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALEeSbB027749; Thu, 21 Nov 2002 06:40:29 -0800 (PST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21452; Thu, 21 Nov 2002 07:40:20 -0700 (MST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gALEeHm01746; Thu, 21 Nov 2002 15:40:17 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gALEeGte038735; Thu, 21 Nov 2002 15:40:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211211440.gALEeGte038735@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Samita Chakrabarti cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, samita.chakrabarti@Sun.COM Subject: Re: Proposal for MIPv6 APIs to switch default source address selection In-reply-to: Your message of Wed, 20 Nov 2002 20:53:47 PST. <3DDC66DB.94ACBF97@eng.sun.com> Date: Thu, 21 Nov 2002 15:40:16 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API document. The following requirements in MIPv6 spec indicates that there is a need for Socket API which will allow the MIPv6 applications to choose COA as mobile node's source address... => the problem of this API is that it is not useful because nobody wants to change all applications to use it. So we need also a way to change the choice (or better, to choose in a clever way, for instance using the "distance" between the CoA prefix and the destination address) from the context of applications. I suggest this many times but it was rejected by address selection document author as out of the scope of the document... (this is one of the reasons I still believe to put the document on the standard track is an error). Thanks Francis.Dupont@enst-bretagne.fr PS: we have to do the same thing for every rules not using the preference table. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 06:57:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALEvXUu026596; Thu, 21 Nov 2002 06:57:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALEvXvs026595; Thu, 21 Nov 2002 06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALEvUUu026588; Thu, 21 Nov 2002 06:57:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALEveMq026978; Thu, 21 Nov 2002 06:57:40 -0800 (PST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29561; Thu, 21 Nov 2002 07:57:34 -0700 (MST) Message-ID: <003d01c2916e$1e709540$bd412acc@AlperVAIO> From: "Alper E. YEGIN" To: "Samita Chakrabarti" , , Cc: References: <3DDC66DB.94ACBF97@eng.sun.com> Subject: Re: Proposal for MIPv6 APIs to switch default source address selection Date: Thu, 21 Nov 2002 06:56:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API > document. The following requirements in MIPv6 spec indicates that there > is a need for Socket API which will allow the MIPv6 applications to > choose > COA as mobile node's source address (in a visited network), while > default > address selection draft prefers home address as the default source > address > (section 5 and 6 rule 4). The MIPV6 API should also take care of > choosing > temporary address and non-temporary address from the application level. Hi Samita, Please see our Mobile IP API draft: http://www.ietf.org/internet-drafts/draft-yokote-mobileip-api-01.txt It allows the user of the API to determine home addresses and the corresponding care-of addresses used on the host. Than, it's the application's choice to pick one of them. It can make an appropriate decision by using this knowledge. I think this selection logic should reside in the application, not below. So, I'm not sure if this really relates to draft-ietf-ipv6-default-addr-select draft. alper > Also, there is a need to choose link-local or site-local address as > source > address (depending on the scope) for the MN while visiting (see below). > > My question is, if anybody in IPv6 working group is currently working on > such > API for default address selection draft ? > > If not, I propose to add these APIs to the MIPv6 Advanced API document, > as they are quite Mobile IP specific in usage. > > -Samita > > -------------------------------------------------------------------- > > > > Mobile IPv6 draft 19 Section 11.3.1 states, > > The mobile node MAY choose to directly use one of its care-of > addresses as the source of the packet, not requiring the use > of a Home Address option in the packet. This is particularly > useful for short-term communication that may easily be retried > if it fails. An example of this type of communication might > be DNS queries sent by the mobile node [27, 28]. Using the > mobile node's care-of address as the source for such queries will > generally have a lower overhead than using the mobile node's > home address, since no extra options need be used in either > the query or its reply. Such packets can be routed normally, > directly between their source and destination without relying > on Mobile IPv6. If application running on the mobile node has > no particular knowledge that the communication being sent fits > within this general type of communication, however, the mobile > node SHOULD NOT use its care-of address as the source of the > packet in this way. > > : : : > > While not at its home link, the mobile node MUST NOT use its home > address (or the home address destination option) in Neighbor > Discovery messages on the visited link. The mobile node also > MUST NOT use its home address when communicating with link-local > or site-local peers on the visited link, if the scope of the home > address is larger than the scope of the peer's address. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 07:26:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALFQqUu026917; Thu, 21 Nov 2002 07:26:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALFQqqG026916; Thu, 21 Nov 2002 07:26: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALFQnUu026909 for ; Thu, 21 Nov 2002 07:26:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALFQxMq002464 for ; Thu, 21 Nov 2002 07:26:59 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18425 for ; Thu, 21 Nov 2002 08:26:53 -0700 (MST) 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 HAA04959; Thu, 21 Nov 2002 07:26:49 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gALFQmr18189; Thu, 21 Nov 2002 07:26:48 -0800 X-mProtect: <200211211526> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.143, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8LWkNd; Thu, 21 Nov 2002 07:26:43 PST Message-ID: <3DDCFAE7.4BE72578@iprg.nokia.com> Date: Thu, 21 Nov 2002 07:25:27 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes References: <200211211418.gALEIVte038662@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Francis, Francis Dupont wrote: > I agree but I have a concern to get this in an unclear spec, > i.e., as a network manager, I'd not like to get request to put > silly RA timing because it is written somewhere. We certainly don't want an unclear specification. And, if a network manager needs to support mobile nodes on any local domains, that network manager needs in many circumstances to have the information that running more frequent advertisements is advisable. Can you suggest a way to make the specification more clear? > That said, I do think this is a pretty poor > substitute for L2 information which probably > should be making its way up the driver. > > => 100% agree It is well known for many years that using layer-2 information makes for better movement detection. However, when that option is not available, our experience and that of many others shows that the faster beaconing is effective and can be applied without any surprises. There have been numerous papers published about this, which led to the appropriate specification for Mobile IPv4. The situation for Mobile IPv6 is not any different. 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 Nov 21 07:45:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALFjiUu027075; Thu, 21 Nov 2002 07:45:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALFjinH027074; Thu, 21 Nov 2002 07:45:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALFjfUu027067 for ; Thu, 21 Nov 2002 07:45:41 -0800 (PST) Received: from eng.sun.com (vpn-129-147-153-230.Central.Sun.COM [129.147.153.230]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALFjkbS226569; Thu, 21 Nov 2002 07:45:46 -0800 (PST) Message-ID: <3DDD00C2.B2EABF68@eng.sun.com> Date: Thu, 21 Nov 2002 07:50:26 -0800 From: Samita Chakrabarti X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.sun.com Subject: Re: Proposal for MIPv6 APIs to switch default source address selection References: <200211211440.gALEeGte038735@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > > In your previous mail you wrote: > > I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API > document. The following requirements in MIPv6 spec indicates that there > is a need for Socket API which will allow the MIPv6 applications to > choose COA as mobile node's source address... > > => the problem of this API is that it is not useful because nobody wants > to change all applications to use it. So we need also a way to change I am not sure why you are saying that all applications needs to change for this. In general applications may not need to change as by default they will use the default address selection mechanism set by the IPv6 kernel. But for MobileIP situation it is necessary for apps to use homeaddr in most situations, but they need to use COA for local cases in the visited link. I don't think those specific apps for MIPv6 exist today and some existing apps would have to be modified or written for MIPv6 anyway. > PS: we have to do the same thing for every rules not using the preference > table. Yes, it's a generic IPv6 socket advanced socket API for which mobileip has obvious usage. -Samita -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 08:03:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALG3NUu027187; Thu, 21 Nov 2002 08:03:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALG3MaF027186; Thu, 21 Nov 2002 08:03:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALG3FUu027170; Thu, 21 Nov 2002 08:03:15 -0800 (PST) Received: from eng.sun.com (vpn-129-147-153-230.Central.Sun.COM [129.147.153.230]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALG3ObS229569; Thu, 21 Nov 2002 08:03:24 -0800 (PST) Message-ID: <3DDD04E4.646C2901@eng.sun.com> Date: Thu, 21 Nov 2002 08:08:04 -0800 From: Samita Chakrabarti X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: alper@docomolabs-usa.com CC: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: Proposal for MIPv6 APIs to switch default source address selection References: <3DDC66DB.94ACBF97@eng.sun.com> <003d01c2916e$1e709540$bd412acc@AlperVAIO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Alper, "Alper E. YEGIN" wrote: > > > I am looking into possible MIPv6 APIs as an extension to IPv6 Adv-API > > document. The following requirements in MIPv6 spec indicates that there > > is a need for Socket API which will allow the MIPv6 applications to > > choose > > COA as mobile node's source address (in a visited network), while > > default > > address selection draft prefers home address as the default source > > address > > (section 5 and 6 rule 4). The MIPV6 API should also take care of > > choosing > > temporary address and non-temporary address from the application level. > > Hi Samita, > > Please see our Mobile IP API draft: > > http://www.ietf.org/internet-drafts/draft-yokote-mobileip-api-01.txt > I did take a look at the draft that you folks have for mobile IP applications. That draft gives a general overview of mobile application usage, but I am addressing a different scope (which is more equivalent to having an extension to IPv6 advanced Socket API document for Mobile IP). The mobileip socket applications will use those Advanced socket APIs(which I am proposing) to change to default behavior in the kernel. Moreover, a socket api to switch the default source address selection would be useful in general(I am happy to see that in Bob Hinden's slides in the ipng meeting today as well). draft-yokote-mobileip-api-01.txt, IMO, provides guideline for the generic MobileIP specific application level APIs, which is in a different scope than Advanced socket APIs that are perceived from the current rfc2292bis. -Samita > > Also, there is a need to choose link-local or site-local address as > > source > > address (depending on the scope) for the MN while visiting (see below). > > > > My question is, if anybody in IPv6 working group is currently working on > > such > > API for default address selection draft ? > > > > If not, I propose to add these APIs to the MIPv6 Advanced API document, > > as they are quite Mobile IP specific in usage. > > > > -Samita > > > > -------------------------------------------------------------------- > > > > > > > > Mobile IPv6 draft 19 Section 11.3.1 states, > > > > The mobile node MAY choose to directly use one of its care-of > > addresses as the source of the packet, not requiring the use > > of a Home Address option in the packet. This is particularly > > useful for short-term communication that may easily be retried > > if it fails. An example of this type of communication might > > be DNS queries sent by the mobile node [27, 28]. Using the > > mobile node's care-of address as the source for such queries will > > generally have a lower overhead than using the mobile node's > > home address, since no extra options need be used in either > > the query or its reply. Such packets can be routed normally, > > directly between their source and destination without relying > > on Mobile IPv6. If application running on the mobile node has > > no particular knowledge that the communication being sent fits > > within this general type of communication, however, the mobile > > node SHOULD NOT use its care-of address as the source of the > > packet in this way. > > > > : : : > > > > While not at its home link, the mobile node MUST NOT use its home > > address (or the home address destination option) in Neighbor > > Discovery messages on the visited link. The mobile node also > > MUST NOT use its home address when communicating with link-local > > or site-local peers on the visited link, if the scope of the home > > address is larger than the scope of the peer's address. > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 08:39:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALGdOUu027369; Thu, 21 Nov 2002 08:39:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALGdOUE027368; Thu, 21 Nov 2002 08:39:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALGdLUu027361 for ; Thu, 21 Nov 2002 08:39:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALGdUMq019030 for ; Thu, 21 Nov 2002 08:39:30 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25850 for ; Thu, 21 Nov 2002 09:39:21 -0700 (MST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 21 Nov 2002 08:38:38 -0800 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 21 Nov 2002 08:38:42 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Thu, 21 Nov 2002 08:38:36 -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, 21 Nov 2002 08:38:42 -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.3710.0); Thu, 21 Nov 2002 08:38:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: globally unique site local addresses Date: Thu, 21 Nov 2002 08:38:41 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses Thread-Index: AcKRfHM3C4HWY6ZpTYqPSkM6hzZupA== From: "Christian Huitema" To: X-OriginalArrivalTime: 21 Nov 2002 16:38:42.0273 (UTC) FILETIME=[73B0BD10:01C2917C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gALGdLUu027362 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk During the WG meeting, we agreed to work on the definition of a globally unqiue site local addressing architecture, so that we can eventually deprecate site local addresses. I am listing here so far a couple of points that were made by different speakers, as an introduction to the debate: * we want to remove ambiguity, which is the root cause of many problems occuring when scoped addresses leak. * we may or may not want to prevent routing of these addresses between sites. I guess we should certainly prevent routing between non-consenting sites. * we definitely want the addresses to be provider independent, so they can survive renumbering or intermittent connectivity. * indeed, it would be desirable that the addresses be usable in sites that are not connected. * and we would definitely want the addresses to be free. One of the main point of contention regarded routing. I guess that the consensus is, "just like site local addresses." We don't want to prevent usage in connected sites, but we expect that in these sites the hosts will also have provider based addresses, and that traffic routed out of the site will use the provider addresses. Now, I guess we have to work from there. -- 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 Nov 21 09:04:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALH4eUu027610; Thu, 21 Nov 2002 09:04:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALH4e2H027609; Thu, 21 Nov 2002 09:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALH4aUu027602 for ; Thu, 21 Nov 2002 09:04:37 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALH4kbB028025 for ; Thu, 21 Nov 2002 09:04:47 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26772 for ; Thu, 21 Nov 2002 09:04:45 -0800 (PST) Subject: RE: Proposal for site-local clean-up Date: Thu, 21 Nov 2002 09:04:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B04640BD401@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Proposal for site-local clean-up thread-index: AcKRYy0j9QXvfp8qT6uPWe54v7IF1AAHHceA From: "Michel Py" To: "Erik Nordmark" Cc: "Richard Draves" , "Keith Moore" , "Michael Thomas" , "Brian Zill" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gALH4bUu027603 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, >> Michel Py wrote: >> Where does this come from? There is nothing in Richard's >> text that implies anything about the ISPs _using_ site >> locals. It talks about _filtering_ them. > Erik Nordmark wrote: > Sorry, I meant to say "using them by configuring site > boundaries" but I agree that it is sufficient to filter > them. In other words: put them in the bogon list. Which they already should be doing, so what is the issue here? There is no automatic relation between the site boundary and the address range. 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 Nov 21 09:07:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALH7TUu027640; Thu, 21 Nov 2002 09:07:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALH7Tj2027639; Thu, 21 Nov 2002 09:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALH7PUu027632 for ; Thu, 21 Nov 2002 09:07:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALH7ZbB028632 for ; Thu, 21 Nov 2002 09:07:35 -0800 (PST) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11829 for ; Thu, 21 Nov 2002 10:07:12 -0700 (MST) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KP5L8P6JV290ALFB@vaxh.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 22 Nov 2002 04:06:45 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F05B612C02D; Fri, 22 Nov 2002 04:06:44 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by blammo.its.monash.edu.au (Postfix) with ESMTP id D22EF12C008; Fri, 22 Nov 2002 04:06:36 +1100 (EST) Date: Thu, 21 Nov 2002 12:06:36 -0500 From: Richard Nelson Subject: Re: globally unique site local addresses To: Christian Huitema Cc: ipng@sunroof.eng.sun.com Message-id: <5b3c095b8b9c.5b8b9c5b3c09@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Add to free - easy to obtain for non connected sites. 1918 addresses are easy to obtain. Richard ----- Original Message ----- From: Christian Huitema Date: Thursday, November 21, 2002 11:38 am Subject: globally unique site local addresses > During the WG meeting, we agreed to work on the definition of a > globally unqiue site local addressing architecture, so that we can > eventually deprecate site local addresses. I am listing here so far > a couple of points that were made by different speakers, as an > introduction to the debate: > > * we want to remove ambiguity, which is the root cause of many > problems occuring when scoped addresses leak. > > * we may or may not want to prevent routing of these addresses > between sites. I guess we should certainly prevent routing between > non-consenting sites. > > * we definitely want the addresses to be provider independent, so > they can survive renumbering or intermittent connectivity. > > * indeed, it would be desirable that the addresses be usable in > sites that are not connected. > > * and we would definitely want the addresses to be free. > > One of the main point of contention regarded routing. I guess that > the consensus is, "just like site local addresses." We don't want > to prevent usage in connected sites, but we expect that in these > sites the hosts will also have provider based addresses, and that > traffic routed out of the site will use the provider addresses. > > Now, I guess we have to work from there. > > -- 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 09:35:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALHZQUu027955; Thu, 21 Nov 2002 09:35:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALHZQ3b027954; Thu, 21 Nov 2002 09:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALHZMUu027947 for ; Thu, 21 Nov 2002 09:35:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALHZWMq005606 for ; Thu, 21 Nov 2002 09:35:32 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14022 for ; Thu, 21 Nov 2002 10:35:26 -0700 (MST) Subject: RE: globally unique site local addresses MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 2002 09:35:25 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4A1@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses thread-index: AcKRfHM3C4HWY6ZpTYqPSkM6hzZupAABGtGA From: "Michel Py" To: "Christian Huitema" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gALHZNUu027948 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, > Christian Huitema wrote: > we want to remove ambiguity, which is the root cause > of many problems occuring when scoped addresses leak. If we want these addresses to be used, there are two things we need to do: 1. Make these addresses globally unique, which is effectively removing ambiguity. As of today, I don't see how we could achieve this without a uniqueness database. It probably means some kind of a registration and possibly a fee. We absolutely need to make the registration easy and the fee low if there is one. I invite people to have a look at: http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt and its (temporary) results: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt This scheme would use 1/64th of the FEC0::/10 space (replace 2346::/16 with FEFE::/16) 2. Make these addresses not globally routable, not only by decree but by requiring them being blocked by default and also BGP routes for this range being rejected by default. Ambiguity is somehow a guarantee that these addresses are not publicly routable. If we remove ambiguity, we need to provide something instead to address this. Bob Hinden and I have contributed some interesting suggestions about this earlier, but they were lost in the email volume. If my memory is correct, Bill Manning was the only one to pick it; Bill, I would like more of your comments. > we may or may not want to prevent routing of these > addresses between sites. I guess we should certainly > prevent routing between non-consenting sites. See above. > we definitely want the addresses to be provider > independent, so they can survive renumbering or > intermittent connectivity. Definitely. > indeed, it would be desirable that the addresses > be usable in sites that are not connected. Yes. >and we would definitely want the addresses to be free. I think we have to accept the compromise of a low fee, as the uniqueness database would likely be handled by the RIRs and we don't want to bankrupt them. > I guess that the consensus is, "just like site local > addresses." We don't want to prevent usage in connected > sites, but we expect that in these sites the hosts will > also have provider based addresses, and that traffic > routed out of the site will use the provider addresses. Agreed. 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 Nov 21 10:06:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALI6XUu028082; Thu, 21 Nov 2002 10:06:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALI6XN1028081; Thu, 21 Nov 2002 10:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALI6UUu028074 for ; Thu, 21 Nov 2002 10:06:30 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALI6eMq015651 for ; Thu, 21 Nov 2002 10:06:40 -0800 (PST) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09073 for ; Thu, 21 Nov 2002 10:06:34 -0800 (PST) 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 gALI6XB72725; Thu, 21 Nov 2002 13:06:33 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id gALI6Wi68405; Thu, 21 Nov 2002 13:06:32 -0500 (EST) Received: from newcastle.torrentnet.com (localhost [127.0.0.1]) by newcastle.torrentnet.com (8.12.6/8.11.6) with ESMTP id gALI6WhZ039449; Thu, 21 Nov 2002 13:06:32 -0500 (EST) (envelope-from slblake@newcastle.torrentnet.com) Received: (from slblake@localhost) by newcastle.torrentnet.com (8.12.6/8.12.6/Submit) id gALI6VF1039448; Thu, 21 Nov 2002 13:06:31 -0500 (EST) Date: Thu, 21 Nov 2002 13:06:31 -0500 From: Steven Blake To: Michel Py Cc: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses Message-ID: <20021121180631.GB39419@newcastle.torrentnet.com> References: <2B81403386729140A3A899A8B39B046405E4A1@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046405E4A1@server2000> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Nov 21, 2002 at 09:35:25AM -0800, Michel Py wrote: > 2. Make these addresses not globally routable, not only by decree but by > requiring them being blocked by default and also BGP routes for this > range being rejected by default. Ambiguity is somehow a guarantee that > these addresses are not publicly routable. If we remove ambiguity, we > need to provide something instead to address this. This is a business issue between customers and ISPs and is none of the IETF's business IMHO. 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 Nov 21 10:15:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIFYUu028226; Thu, 21 Nov 2002 10:15:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALIFYlb028225; Thu, 21 Nov 2002 10:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIFVUu028218 for ; Thu, 21 Nov 2002 10:15:31 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALIFeMq018393 for ; Thu, 21 Nov 2002 10:15:40 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19128 for ; Thu, 21 Nov 2002 10:15:34 -0800 (PST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gALIF0920129 for ; Thu, 21 Nov 2002 20:15:00 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Nov 2002 20:14:06 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 20:14:06 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Nov 2002 20:14:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: globally unique site local addresses Date: Thu, 21 Nov 2002 20:14:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses Thread-Index: AcKRfHM3C4HWY6ZpTYqPSkM6hzZupAADPM2Q To: , X-OriginalArrivalTime: 21 Nov 2002 18:14:05.0903 (UTC) FILETIME=[C73D5DF0:01C29189] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gALIFVUu028219 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, I am not disagreeing with you on this, but I do have a comment on one point: > * we may or may not want to prevent routing of these > addresses between sites. I guess we should certainly prevent > routing between non-consenting sites. Either we should do or the other. If we create any ambiguity on making these addresses routable between sites then we are creating for a mess - as endpoints would not be able to know if their packets would be routed or not. best regards, 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 Nov 21 10:27:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIRHUu028383; Thu, 21 Nov 2002 10:27:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALIRHgo028382; Thu, 21 Nov 2002 10:27: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIRDUu028375 for ; Thu, 21 Nov 2002 10:27:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALIRNbB023297 for ; Thu, 21 Nov 2002 10:27:23 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20620 for ; Thu, 21 Nov 2002 11:27:17 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gALIQxc24701; Thu, 21 Nov 2002 20:26:59 +0200 Date: Thu, 21 Nov 2002 20:26:59 +0200 (EET) From: Pekka Savola To: Michel Py cc: Christian Huitema , Subject: "unique enough" [RE: globally unique site local addresses] In-Reply-To: <2B81403386729140A3A899A8B39B046405E4A1@server2000> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 21 Nov 2002, Michel Py wrote: > > Christian Huitema wrote: > > we want to remove ambiguity, which is the root cause > > of many problems occuring when scoped addresses leak. > > If we want these addresses to be used, there are two things we need to > do: > > 1. Make these addresses globally unique, which is effectively removing > ambiguity. As of today, I don't see how we could achieve this without a > uniqueness database. [...] One idea IMO is that we don't even want to be aim for total, provable, complete uniqueness. Looking at some requirements, I believe "unique enough" is good enough. Especially if we focus on the -real- case, non-globally routable addresses. FEC0::/10 has about 38 usable bits there. That's enough for "unique enough". No need for even that. Let's assume /16 - /40 -- 24 bits would be enough too. By birthday paradox, even in that case, collisions should only be probable if you communicate thousands of different sites simultaneously and there are referrals and third party interconnections. Take your name, address, phonenumber or whatever (it must be long enough, though), apply a hash function and BAM -- there you have "unique enough" site-id identifier. No need for any registrations etc. As long as the site-id identifier is created with a clear conscience, based on enough material (what you use is really irrelevant, but several options could be listed) so the hash function provides values random enough to be useful, you're done. If you want globally routable addresses, this is of course a non-starter. There, a geographical addressing, based on e.g. GPS readings like Tony has suggested, is probably the easiest. But I don't think we should be providing _globally routable_ addresses in the first place. They answer some other problems than the one that's an argument in the site-local discussion. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 10:31:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIVtUu028474; Thu, 21 Nov 2002 10:31:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALIVtiQ028471; Thu, 21 Nov 2002 10:31: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIVpUu028463 for ; Thu, 21 Nov 2002 10:31:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALIW1bB024915 for ; Thu, 21 Nov 2002 10:32:01 -0800 (PST) Received: from laptop2.kurtis.pp.se (laptop2.ietf55.ops.ietf.org [204.42.72.221]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23792; Thu, 21 Nov 2002 11:31:55 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gALIWJve025208; Thu, 21 Nov 2002 19:32:20 +0100 (CET) Date: Thu, 21 Nov 2002 19:32:18 +0100 Subject: Re: Proposal for site-local clean-up Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: ipng@sunroof.eng.sun.com To: Erik Nordmark From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <91005015-FD7F-11D6-B83C-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On torsdag, nov 21, 2002, at 04:01 Europe/Stockholm, Erik Nordmark wrote: > This assumes that ISPs will use site-locals. So far I haven't seen any > claims of benefits for ISPs to configure site boundaries and use > site-local > addresses in their network. > If the ISPs don't use it the only boundaries would be at the attacker > (which > might be able to control its site boundary) and at the attacked site, > thus > no additional depth. > > Any ISPs care to comment on this? As ex-ISP I agree. Just as basically noone is installing RFC1918 space today. Border will be at the ISP aggregation router or ISP controlled CPE. - 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 Thu Nov 21 10:34:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIYkUu028536; Thu, 21 Nov 2002 10:34:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALIYkfs028535; Thu, 21 Nov 2002 10:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIYbUu028520; Thu, 21 Nov 2002 10:34:37 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALIYlMq024738; Thu, 21 Nov 2002 10:34:47 -0800 (PST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02227; Thu, 21 Nov 2002 10:34:41 -0800 (PST) Message-ID: <001a01c2918c$73904980$bd412acc@AlperVAIO> From: "Alper E. YEGIN" To: "Samita Chakrabarti" Cc: , References: <3DDC66DB.94ACBF97@eng.sun.com> <003d01c2916e$1e709540$bd412acc@AlperVAIO> <3DDD04E4.646C2901@eng.sun.com> Subject: Re: Proposal for MIPv6 APIs to switch default source address selection Date: Thu, 21 Nov 2002 10:32:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Samita, > I did take a look at the draft that you folks have for mobile IP > applications. > > That draft gives a general overview of mobile application usage, but I > am > addressing a different scope (which is more equivalent to having an > extension > to IPv6 advanced Socket API document for Mobile IP). The mobileip socket > applications > will use those Advanced socket APIs(which I am proposing) to change to > default behavior in the kernel. An alternative approach could be: If the application cares about the source address, it can use the Mobile IP API to figure out which ones are home address, which ones are care-of address, and than explicitly "bind" the socket to the desired address. IMO, this would also satisfy the needs of the Mobile IPv6 mobile node. alper > Moreover, a socket api to switch the default source address selection > would be > useful in general(I am happy to see that in Bob Hinden's slides in the > ipng > meeting today as well). > > draft-yokote-mobileip-api-01.txt, IMO, provides guideline for the > generic MobileIP > specific application level APIs, which is in a different scope than > Advanced socket APIs > that are perceived from the current rfc2292bis. > > > -Samita > > > > Also, there is a need to choose link-local or site-local address as > > > source > > > address (depending on the scope) for the MN while visiting (see below). > > > > > > My question is, if anybody in IPv6 working group is currently working on > > > such > > > API for default address selection draft ? > > > > > > If not, I propose to add these APIs to the MIPv6 Advanced API document, > > > as they are quite Mobile IP specific in usage. > > > > > > -Samita > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > Mobile IPv6 draft 19 Section 11.3.1 states, > > > > > > The mobile node MAY choose to directly use one of its care-of > > > addresses as the source of the packet, not requiring the use > > > of a Home Address option in the packet. This is particularly > > > useful for short-term communication that may easily be retried > > > if it fails. An example of this type of communication might > > > be DNS queries sent by the mobile node [27, 28]. Using the > > > mobile node's care-of address as the source for such queries will > > > generally have a lower overhead than using the mobile node's > > > home address, since no extra options need be used in either > > > the query or its reply. Such packets can be routed normally, > > > directly between their source and destination without relying > > > on Mobile IPv6. If application running on the mobile node has > > > no particular knowledge that the communication being sent fits > > > within this general type of communication, however, the mobile > > > node SHOULD NOT use its care-of address as the source of the > > > packet in this way. > > > > > > : : : > > > > > > While not at its home link, the mobile node MUST NOT use its home > > > address (or the home address destination option) in Neighbor > > > Discovery messages on the visited link. The mobile node also > > > MUST NOT use its home address when communicating with link-local > > > or site-local peers on the visited link, if the scope of the home > > > address is larger than the scope of the peer's address. > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 21 10:38:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIcMUu028627; Thu, 21 Nov 2002 10:38:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALIcMUF028626; Thu, 21 Nov 2002 10:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIcIUu028617 for ; Thu, 21 Nov 2002 10:38:18 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALIcSMq025821 for ; Thu, 21 Nov 2002 10:38:28 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29487 for ; Thu, 21 Nov 2002 11:38:24 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA19033 for ; Thu, 21 Nov 2002 18:38:23 GMT Received: from login.ecs.soton.ac.uk (IDENT:2H/Y+23XFnZaCklctJr81Ij62LahSJNg@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gALIcKWX029876 for ; Thu, 21 Nov 2002 18:38:20 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gALIcKU05622 for ipng@sunroof.eng.sun.com; Thu, 21 Nov 2002 18:38:20 GMT Date: Thu, 21 Nov 2002 18:38:20 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses Message-ID: <20021121183819.GE5241@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <5b3c095b8b9c.5b8b9c5b3c09@mail1.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5b3c095b8b9c.5b8b9c5b3c09@mail1.monash.edu.au> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Nov 21, 2002 at 12:06:36PM -0500, Richard Nelson wrote: > Add to free - easy to obtain for non connected sites. 1918 addresses > are easy to obtain. I have reservations here. I don't see how such prefixes, with the associated administration/registry work, will be offered for free. There may also be a few orders of magnitude more such prefixes requested than there are SubTLAs. Or do people feel such requests will be very limited? Who can manage this for no cost? So people will just pick their own prefixes at random, or use addresses in the site local space (which in a small network will be easier to remember and use for configs). Are there advantages to uniqueness (to the user) beyond some guarantee of avoiding clashes when merging sites? I doubt this is something I would care about in my home network, if it had intermittent connectivity and/or dynamic ISP-assigned /48's, and I wanted some kind of persistent address space to use internally). Whatever we offer has to be more attractive, as Christian said today, and if it's not free, it won't be. If DSL providers offer static /48's, we can reduce requirements for such independent address space in home networks, so the above may be moot. Tim > > Richard > > ----- Original Message ----- > From: Christian Huitema > Date: Thursday, November 21, 2002 11:38 am > Subject: globally unique site local addresses > > > During the WG meeting, we agreed to work on the definition of a > > globally unqiue site local addressing architecture, so that we can > > eventually deprecate site local addresses. I am listing here so far > > a couple of points that were made by different speakers, as an > > introduction to the debate: > > > > * we want to remove ambiguity, which is the root cause of many > > problems occuring when scoped addresses leak. > > > > * we may or may not want to prevent routing of these addresses > > between sites. I guess we should certainly prevent routing between > > non-consenting sites. > > > > * we definitely want the addresses to be provider independent, so > > they can survive renumbering or intermittent connectivity. > > > > * indeed, it would be desirable that the addresses be usable in > > sites that are not connected. > > > > * and we would definitely want the addresses to be free. > > > > One of the main point of contention regarded routing. I guess that > > the consensus is, "just like site local addresses." We don't want > > to prevent usage in connected sites, but we expect that in these > > sites the hosts will also have provider based addresses, and that > > traffic routed out of the site will use the provider addresses. > > > > Now, I guess we have to work from there. > > > > -- 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 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 21 10:45:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIjkUu028932; Thu, 21 Nov 2002 10:45:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALIjk3Z028931; Thu, 21 Nov 2002 10:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIjhUu028924 for ; Thu, 21 Nov 2002 10:45:43 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALIjrbB029432 for ; Thu, 21 Nov 2002 10:45:53 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08963 for ; Thu, 21 Nov 2002 10:45:47 -0800 (PST) Subject: RE: globally unique site local addresses Date: Thu, 21 Nov 2002 10:45:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E4A3@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses thread-index: AcKRiM9HqTlbUkb2SmmJcKROj4UdoQABB67w From: "Michel Py" To: "Steven Blake" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gALIjhUu028925 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven, >> Michel Py wrote: >> 2. Make these addresses not globally routable, not >> only by decree but by requiring them being blocked >> by default and also BGP routes for this range being >> rejected by default. Ambiguity is somehow a guarantee >> that these addresses are not publicly routable. If we >> remove ambiguity, we need to provide something instead >> to address this. > Steven Blake wrote: > This is a business issue between customers and ISPs > and is none of the IETF's business IMHO. I don't think so. First, there is no business relation between the customer and the carrier in the middle of the cloud. Second, history has proven that sometimes ISPs don't filter routes; if they did we would not see a route for 10.0.0.0/8 in the DFZ. Ambiguity is a fail-safe for routes that leak into the DFZ, even though they were not supposed to, and for ISPs that don't filter traffic, even though they were supposed to. In order to remove ambiguity, we must replace the fail-safe it provides by something else, and that something else is IMHO a requirement that router vendors implement the necessary filters as being default configuration. 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 Nov 21 10:53:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIrVUu029127; Thu, 21 Nov 2002 10:53:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALIrVPc029126; Thu, 21 Nov 2002 10:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIrRUu029119 for ; Thu, 21 Nov 2002 10:53:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALIrbMq000851 for ; Thu, 21 Nov 2002 10:53:37 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03584 for ; Thu, 21 Nov 2002 11:53:29 -0700 (MST) Subject: RE: "unique enough" [RE: globally unique site local addresses] Date: Thu, 21 Nov 2002 10:52:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405E4A4@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: "unique enough" [RE: globally unique site local addresses] thread-index: AcKRi7cQK+OZ0XFVSr6uT3MAMWnRcAAAsiNg From: "Michel Py" To: "Pekka Savola" Cc: "Christian Huitema" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gALIrSUu029120 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > Pekka Savola wrote: > One idea IMO is that we don't even want to be aim for > total, provable, complete uniqueness. > Looking at some requirements, I believe "unique enough" > is good enough. > Take your name, address, phonenumber or whatever (it > must be long enough, though), apply a hash function > and BAM -- there you have "unique enough" site-id > identifier. No need for any registrations etc. This is a valid approach also. However, one might argue that it would be nice to do it the right way and make them truly unique if it is not too much of a hassle. > But I don't think we should be providing _globally > routable_ addresses in the first place. They answer > some other problems than the one that's an argument in > the site-local discussion. Strongly agree. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 10:54:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIsLUu029166; Thu, 21 Nov 2002 10:54:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALIsL9n029165; Thu, 21 Nov 2002 10:54: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIsGUu029155 for ; Thu, 21 Nov 2002 10:54:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALIsPbB002203 for ; Thu, 21 Nov 2002 10:54:26 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04200 for ; Thu, 21 Nov 2002 11:54:18 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1CD886A901; Thu, 21 Nov 2002 20:54:15 +0200 (EET) Message-ID: <3DDD0FC0.5070002@piuha.net> Date: Thu, 21 Nov 2002 18:54:24 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: Christian Huitema , ipng@sunroof.eng.sun.com Subject: Re: "unique enough" [RE: globally unique site local addresses] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > Take your name, address, phonenumber or whatever (it must be long enough, > though), apply a hash function and BAM -- there you have "unique enough" > site-id identifier. No need for any registrations etc. We still need to avoid user input for self-configuring home networks etc. How about a hash of the IEEE MAC address of the node that created the site? Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 10:56:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIuaUu029218; Thu, 21 Nov 2002 10:56:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALIua99029216; Thu, 21 Nov 2002 10:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIuWUu029206 for ; Thu, 21 Nov 2002 10:56:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALIugbB002995 for ; Thu, 21 Nov 2002 10:56:42 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05289 for ; Thu, 21 Nov 2002 11:56:30 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gALIu4V24979; Thu, 21 Nov 2002 20:56:04 +0200 Date: Thu, 21 Nov 2002 20:56:03 +0200 (EET) From: Pekka Savola To: Jari Arkko cc: Christian Huitema , Subject: Re: "unique enough" [RE: globally unique site local addresses] In-Reply-To: <3DDD0FC0.5070002@piuha.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 21 Nov 2002, Jari Arkko wrote: > > Take your name, address, phonenumber or whatever (it must be long enough, > > though), apply a hash function and BAM -- there you have "unique enough" > > site-id identifier. No need for any registrations etc. > > We still need to avoid user input for self-configuring home networks etc. > How about a hash of the IEEE MAC address of the node that created the > site? Sure -- and take some other things in consideration. (I don't know whether MAC address in itself will provide enough material for a reliable hash, but I could see a possibility of it working.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 10:57:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIv2Uu029248; Thu, 21 Nov 2002 10:57:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALIv2qG029247; Thu, 21 Nov 2002 10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALIuxUu029240 for ; Thu, 21 Nov 2002 10:56:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALIv8bB003124 for ; Thu, 21 Nov 2002 10:57:08 -0800 (PST) Received: from panoramix.noc.ams-ix.net (panoramix.noc.ams-ix.net [193.194.136.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02564 for ; Thu, 21 Nov 2002 11:57:02 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by panoramix.noc.ams-ix.net (Postfix) with ESMTP id 954FD91E8; Thu, 21 Nov 2002 19:56:32 +0100 (MET) Received: from [204.42.69.184] (unknown [204.42.69.184]) by panoramix.noc.ams-ix.net (Postfix) with ESMTP id 8A78391E2; Thu, 21 Nov 2002 19:56:31 +0100 (MET) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 21 Nov 2002 13:56:31 -0500 Subject: Re: globally unique site local addresses From: Arien Vijn To: Michel Py , Christian Huitema , ipng Message-ID: In-Reply-To: <2B81403386729140A3A899A8B39B046405E4A1@server2000> 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 What is the use of eliminating ambiguity *and* make sure these addresses are not globally routable? I can only see one usage, namely: site-to-site connections. On which there was consensus that this was not the way to go. But perhaps there are more reasons? In theory you are absolutely right. But it practice this won't work. The charm of RFC1918 and site locals is that one not have to go to any registry. Which is a barrier no matter what. Provided that this is the way to go. We need to come up with a way to automate/self-assign "likely to be globally unique site local addresses". The *only* use for this is to inter-connect globally disconnected sites. For globally connected sites we either have to stick with the PA space architecture or come up with something new to ensure address stability. Arien On 21-11-2002 12:35AM, "Michel Py" wrote: > If we want these addresses to be used, there are two things we need to > do: > > 1. Make these addresses globally unique, which is effectively removing > ambiguity. As of today, I don't see how we could achieve this without a > uniqueness database. It probably means some kind of a registration and > possibly a fee. We absolutely need to make the registration easy and the > fee low if there is one. > > I invite people to have a look at: > http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt > and its (temporary) results: > http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt > This scheme would use 1/64th of the FEC0::/10 space (replace 2346::/16 > with FEFE::/16) > > 2. Make these addresses not globally routable, not only by decree but by > requiring them being blocked by default and also BGP routes for this > range being rejected by default. Ambiguity is somehow a guarantee that > these addresses are not publicly routable. If we remove ambiguity, we > need to provide something instead to address this. > > Bob Hinden and I have contributed some interesting suggestions about > this earlier, but they were lost in the email volume. If my memory is > correct, Bill Manning was the only one to pick it; Bill, I would like > more of your comments. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 11:09:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJ98Uu029721; Thu, 21 Nov 2002 11:09:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALJ98q6029720; Thu, 21 Nov 2002 11:09:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJ94Uu029710 for ; Thu, 21 Nov 2002 11:09:04 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALJ9EMq005975 for ; Thu, 21 Nov 2002 11:09:14 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20643 for ; Thu, 21 Nov 2002 12:09:09 -0700 (MST) 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 LAA16434; Thu, 21 Nov 2002 11:09:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gALJ97B15209; Thu, 21 Nov 2002 11:09:07 -0800 X-mProtect: <200211211909> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.29.21, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmEqW6h; Thu, 21 Nov 2002 11:09:05 PST Message-ID: <3DDD2F0F.618B341@iprg.nokia.com> Date: Thu, 21 Nov 2002 11:08:00 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Chown CC: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <5b3c095b8b9c.5b8b9c5b3c09@mail1.monash.edu.au> <20021121183819.GE5241@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 Hello Tim, Maybe it could be done almost for free. Maybe there could be a web page under the IANA web page where a network administrator could get the "next" site-local prefix. This would be rate-limited so that only a few prefixes would be given out per second, and so on. It seems like it would work, at least well-enough to be given a try. It would not require very much administration on the part of IANA (or whoever agreed to host the web page). Of course, this only solves the one problem of guaranteeing global uniqueness for the site-local prefixes, and the other problems remain. Regards, Charlie P. Tim Chown wrote: > On Thu, Nov 21, 2002 at 12:06:36PM -0500, Richard Nelson wrote: > > Add to free - easy to obtain for non connected sites. 1918 addresses > > are easy to obtain. > > I have reservations here. I don't see how such prefixes, with the > associated administration/registry work, will be offered for free. > There may also be a few orders of magnitude more such prefixes requested > than there are SubTLAs. Or do people feel such requests will be very > limited? Who can manage this for no cost? > > So people will just pick their own prefixes at random, or use addresses > in the site local space (which in a small network will be easier to > remember and use for configs). Are there advantages to uniqueness > (to the user) beyond some guarantee of avoiding clashes when merging > sites? I doubt this is something I would care about in my home network, > if it had intermittent connectivity and/or dynamic ISP-assigned /48's, > and I wanted some kind of persistent address space to use internally). > > Whatever we offer has to be more attractive, as Christian said today, > and if it's not free, it won't be. > > If DSL providers offer static /48's, we can reduce requirements for > such independent address space in home networks, so the above may be moot. > > Tim > > > > > Richard > > > > ----- Original Message ----- > > From: Christian Huitema > > Date: Thursday, November 21, 2002 11:38 am > > Subject: globally unique site local addresses > > > > > During the WG meeting, we agreed to work on the definition of a > > > globally unqiue site local addressing architecture, so that we can > > > eventually deprecate site local addresses. I am listing here so far > > > a couple of points that were made by different speakers, as an > > > introduction to the debate: > > > > > > * we want to remove ambiguity, which is the root cause of many > > > problems occuring when scoped addresses leak. > > > > > > * we may or may not want to prevent routing of these addresses > > > between sites. I guess we should certainly prevent routing between > > > non-consenting sites. > > > > > > * we definitely want the addresses to be provider independent, so > > > they can survive renumbering or intermittent connectivity. > > > > > > * indeed, it would be desirable that the addresses be usable in > > > sites that are not connected. > > > > > > * and we would definitely want the addresses to be free. > > > > > > One of the main point of contention regarded routing. I guess that > > > the consensus is, "just like site local addresses." We don't want > > > to prevent usage in connected sites, but we expect that in these > > > sites the hosts will also have provider based addresses, and that > > > traffic routed out of the site will use the provider addresses. > > > > > > Now, I guess we have to work from there. > > > > > > -- 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 > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Nov 21 11:11:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJBiUu029797; Thu, 21 Nov 2002 11:11:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALJBiSZ029796; Thu, 21 Nov 2002 11:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJBfUu029789 for ; Thu, 21 Nov 2002 11:11:41 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALJBpMq006833 for ; Thu, 21 Nov 2002 11:11:51 -0800 (PST) Received: from panoramix.noc.ams-ix.net (panoramix.noc.ams-ix.net [193.194.136.132]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26658 for ; Thu, 21 Nov 2002 11:11:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by panoramix.noc.ams-ix.net (Postfix) with ESMTP id BF32991E8; Thu, 21 Nov 2002 20:11:44 +0100 (MET) Received: from [204.42.69.184] (unknown [204.42.69.184]) by panoramix.noc.ams-ix.net (Postfix) with ESMTP id 84A1C91E2; Thu, 21 Nov 2002 20:11:43 +0100 (MET) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 21 Nov 2002 14:11:43 -0500 Subject: Re: "unique enough" [RE: globally unique site local addresses] From: Arien Vijn To: Pekka Savola , Jari Arkko Cc: Christian Huitema , ipng Message-ID: In-Reply-To: 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 Missed your mail, Pekka otherwise I wouldn't try make the same point. On 21-11-2002 13:56PM, "Pekka Savola" wrote: > On Thu, 21 Nov 2002, Jari Arkko wrote: >>> Take your name, address, phonenumber or whatever (it must be long enough, >>> though), apply a hash function and BAM -- there you have "unique enough" >>> site-id identifier. No need for any registrations etc. >> >> We still need to avoid user input for self-configuring home networks etc. >> How about a hash of the IEEE MAC address of the node that created the >> site? > > Sure -- and take some other things in consideration. > > (I don't know whether MAC address in itself will provide enough material > for a reliable hash, but I could see a possibility of it working.) 48 bits MAC is not globally unique (found that out the hard way). But hashing several MACs on the links of a disconnected sites toghere with a timestamp will do I guess. 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 Thu Nov 21 11:17:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJHGUu029956; Thu, 21 Nov 2002 11:17:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALJHGAp029954; Thu, 21 Nov 2002 11:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJHCUu029946 for ; Thu, 21 Nov 2002 11:17:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALJHMMq008531 for ; Thu, 21 Nov 2002 11:17:22 -0800 (PST) Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19977 for ; Thu, 21 Nov 2002 12:17:17 -0700 (MST) Received: from dhcp-204-42-68-213.ietf55.ops.ietf.org ([204.42.68.213] helo=eng.monash.edu.au) by srv0.ops.ietf.org with esmtp (Exim 4.10) id 18EwpA-0001nU-00; Thu, 21 Nov 2002 19:17:16 +0000 Message-ID: <3DDDBDA3.2982FA84@eng.monash.edu.au> Date: Fri, 22 Nov 2002 05:16:19 +0000 From: Richard Nelson X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.19hilc i686) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: Tim Chown Subject: Re: globally unique site local addresses References: <5b3c095b8b9c.5b8b9c5b3c09@mail1.monash.edu.au> <20021121183819.GE5241@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, Nov 21, 2002 at 12:06:36PM -0500, Richard Nelson wrote: > > Add to free - easy to obtain for non connected sites. 1918 addresses > > are easy to obtain. > > I have reservations here. I don't see how such prefixes, with the > associated administration/registry work, will be offered for free. > There may also be a few orders of magnitude more such prefixes requested > than there are SubTLAs. Or do people feel such requests will be very > limited? Who can manage this for no cost? > > So people will just pick their own prefixes at random, or use addresses > in the site local space (which in a small network will be easier to > remember and use for configs). Are there advantages to uniqueness > (to the user) beyond some guarantee of avoiding clashes when merging > sites? I doubt this is something I would care about in my home network, > if it had intermittent connectivity and/or dynamic ISP-assigned /48's, > and I wanted some kind of persistent address space to use internally). > > Whatever we offer has to be more attractive, as Christian said today, > and if it's not free, it won't be. > I'm not quite sure what your conclusion is as this sentance appears to contradict your opening statement. Despite that, I agree with you, it should be free to be attractive and it can't be free because of the uniqueness requirments. The real problem comes with connected sites so perhaps we have to ensure that all users get an allocation whenever they get an ISP sites. For non-connected sites I think that cheap enough that the cost is not generally a concern will be the best we can really hope for. Richard. > If DSL providers offer static /48's, we can reduce requirements for > such independent address space in home networks, so the above may be moot. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 11:32:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJWDUu000170; Thu, 21 Nov 2002 11:32:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALJWDBl000169; Thu, 21 Nov 2002 11:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJW9Uu000162 for ; Thu, 21 Nov 2002 11:32:10 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALJWJMq013206 for ; Thu, 21 Nov 2002 11:32:19 -0800 (PST) Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01565 for ; Thu, 21 Nov 2002 12:32:14 -0700 (MST) Received: from dhcp-204-42-68-213.ietf55.ops.ietf.org ([204.42.68.213] helo=eng.monash.edu.au) by srv0.ops.ietf.org with esmtp (Exim 4.10) id 18Ex3b-0001uK-00; Thu, 21 Nov 2002 19:32:12 +0000 Message-ID: <3DDDC11D.E8BB0DED@eng.monash.edu.au> Date: Fri, 22 Nov 2002 05:31:09 +0000 From: Richard Nelson X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.19hilc i686) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: Michel Py Subject: Re: globally unique site local addresses References: <2B81403386729140A3A899A8B39B046405E4A1@server2000> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: > > > 2. Make these addresses not globally routable, not only by decree but by > requiring them being blocked by default and also BGP routes for this > range being rejected by default. Ambiguity is somehow a guarantee that > these addresses are not publicly routable. If we remove ambiguity, we > need to provide something instead to address this. It would be really nice if the "not globally routable" property was by some mechanism stronger than blocked by decree. AFter all we no that RFC1918 addresses do get routed sometimes by mistake, but you can't route back to them because of the ambiguity. This may be too difficult but it could be worth thinking about for a little bit. One idea I had (with lots of problems) would be to allocate them with prefixes too large to be handled by EGPs. > > Bob Hinden and I have contributed some interesting suggestions about > this earlier, but they were lost in the email volume. If my memory is > correct, Bill Manning was the only one to pick it; Bill, I would like > more of your comments. > Yes they got lost in the volume. Please repeat them on this thread. Richard. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 11:37:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJbuUu000315; Thu, 21 Nov 2002 11:37:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALJbtp7000314; Thu, 21 Nov 2002 11:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJbqUu000295 for ; Thu, 21 Nov 2002 11:37:52 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALJc2Mq014878 for ; Thu, 21 Nov 2002 11:38:02 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10673 for ; Thu, 21 Nov 2002 11:37:56 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DA1046A901; Thu, 21 Nov 2002 21:37:47 +0200 (EET) Message-ID: <3DDD19F4.6040907@kolumbus.fi> Date: Thu, 21 Nov 2002 19:37:56 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Perkins Cc: Tim Chown , ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <5b3c095b8b9c.5b8b9c5b3c09@mail1.monash.edu.au> <20021121183819.GE5241@login.ecs.soton.ac.uk> <3DDD2F0F.618B341@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 Charlie Perkins wrote: > Maybe it could be done almost for free. > > Maybe there could be a web page under the IANA web > page where a network administrator could get the "next" > site-local prefix. This would be rate-limited so that only > a few prefixes would be given out per second, and so on. > > It seems like it would work, at least well-enough to be > given a try. It would not require very much administration > on the part of IANA (or whoever agreed to host the > web page). I also thought about this. An automatic protocol to go get a new site-local prefix... in my approach there was some kind of a "key" however that the requesting entity had to provide. This key could be a physical address, global IP address, MAC address, or something like that. A new request from the same "key" would give you back the same site-local prefix. This would prevent a trivial depletion attack on the pool of prefixes. Yeah, rate-limitation helps but I don't think it solves the problem. But then I started to think about this in more detail. Remember that our requirement was to be able to deal with disconnected sites. I don't see how a disconnected site is going to the IANA web for a prefix ;-) Or do we have to assume a human who helps the site to get a prefix? In my opinion, that would prevent many useful scenarios... Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 11:44:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJigUu000467; Thu, 21 Nov 2002 11:44:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALJif9f000466; Thu, 21 Nov 2002 11:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJicUu000459 for ; Thu, 21 Nov 2002 11:44:38 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALJimbB018761 for ; Thu, 21 Nov 2002 11:44:48 -0800 (PST) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13335 for ; Thu, 21 Nov 2002 12:44:42 -0700 (MST) 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 gALJigO73903; Thu, 21 Nov 2002 14:44:42 -0500 (EST) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id gALJif275686; Thu, 21 Nov 2002 14:44:41 -0500 (EST) Received: from newcastle.torrentnet.com (localhost [127.0.0.1]) by newcastle.torrentnet.com (8.12.6/8.11.6) with ESMTP id gALJifhZ039633; Thu, 21 Nov 2002 14:44:41 -0500 (EST) (envelope-from slblake@newcastle.torrentnet.com) Received: (from slblake@localhost) by newcastle.torrentnet.com (8.12.6/8.12.6/Submit) id gALJifLH039632; Thu, 21 Nov 2002 14:44:41 -0500 (EST) Date: Thu, 21 Nov 2002 14:44:40 -0500 From: Steven Blake To: Michel Py Cc: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses Message-ID: <20021121194440.GA39617@newcastle.torrentnet.com> References: <2B81403386729140A3A899A8B39B046405E4A3@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046405E4A3@server2000> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Nov 21, 2002 at 10:45:47AM -0800, Michel Py wrote: > > Steven Blake wrote: > > This is a business issue between customers and ISPs > > and is none of the IETF's business IMHO. > > I don't think so. > > First, there is no business relation between the customer and the > carrier in the middle of the cloud. > > Second, history has proven that sometimes ISPs don't filter routes; if > they did we would not see a route for 10.0.0.0/8 in the DFZ. > > Ambiguity is a fail-safe for routes that leak into the DFZ, even though > they were not supposed to, and for ISPs that don't filter traffic, even > though they were supposed to. In order to remove ambiguity, we must > replace the fail-safe it provides by something else, and that something > else is IMHO a requirement that router vendors implement the necessary > filters as being default configuration. What technical problem are you trying to solve? Are you trying to prevent inadvertent leakage of prefixes? Or are you trying to impose aggregatible prefixes on institutions that may be able to afford other arrangements? 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 Nov 21 11:45:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJjDUu000484; Thu, 21 Nov 2002 11:45:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALJjD7d000483; Thu, 21 Nov 2002 11:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJjAUu000476 for ; Thu, 21 Nov 2002 11:45:10 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALJjKbB018932 for ; Thu, 21 Nov 2002 11:45:20 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15112 for ; Thu, 21 Nov 2002 11:45:15 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 21 Nov 2002 11:45:14 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 21 Nov 2002 11:45:15 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Thu, 21 Nov 2002 11:45:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: globally unique site local addresses Date: Thu, 21 Nov 2002 11:45:13 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses Thread-Index: AcKRkeEJAiKkecKAQP+RKmJeTtDNXAAAQZoA From: "Brian Zill" To: X-OriginalArrivalTime: 21 Nov 2002 19:45:06.0486 (UTC) FILETIME=[7E003560:01C29196] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gALJjAUu000477 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We need to be careful here. In our rush to eliminate the bad effects of the ambiguity present in site-local addresses today, let's not forget that there are some major plusses to existing site-local addresses that are the result of this ambiguity: 1. They're free. 2. They can be (auto)configured without having to co-ordinate with some outside entity. 3. They cannot be externally routed (Some would consider this to be a minus as well). I believe 1 and 2 can be solved (fairly) easily by other means. The big problem is number 3. The ambiguity is essential to preventing them from ever being routed. An IETF edict not to route some new form of non-ambiguous addresses will be ignored by those who wish to route them. This will likely lead to pressure to turn these new addresses into yet-another type of global address with all the associated routing table explosion inherent to non-aggregatable address space. Another way to look at it is that the current ambiguity in site-locals is a means for protecting the global routing space. If we do away with the ambiguity, we need another method for keeping the global routing tables sane. The only class of solution which I think will truly make everyone happy is to come up with an *aggregatable* globally unique address space that still has properties 1 and 2. In other words, some sort of provider-independent global address space. Properties 1 and 2 are much easier when the aggregatable property is not required. The reason we're in the state we are today is because this is a hard problem. --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 Nov 21 11:46:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJkHUu000529; Thu, 21 Nov 2002 11:46:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALJkG8H000528; Thu, 21 Nov 2002 11:46:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJkDUu000515 for ; Thu, 21 Nov 2002 11:46:13 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALJkNbB019230 for ; Thu, 21 Nov 2002 11:46:23 -0800 (PST) Received: from laptop2.kurtis.pp.se (laptop2.ietf55.ops.ietf.org [204.42.72.221]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15833 for ; Thu, 21 Nov 2002 11:46:17 -0800 (PST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gALJkave025246; Thu, 21 Nov 2002 20:46:37 +0100 (CET) Date: Thu, 21 Nov 2002 20:46:36 +0100 Subject: Re: "unique enough" [RE: globally unique site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "Pekka Savola" , "Christian Huitema" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <2B81403386729140A3A899A8B39B046405E4A4@server2000> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is a valid approach also. However, one might argue that it would > be > nice to do it the right way and make them truly unique if it is not too > much of a hassle. > Uhm, if they are truely unique, the only difference to global addresses is that they won't be routed - right? Now, what is the difference between that and using global unicast address space that you do not announce? - 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 Thu Nov 21 11:53:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJr7Uu000803; Thu, 21 Nov 2002 11:53:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALJr70q000802; Thu, 21 Nov 2002 11:53:07 -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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALJr3Uu000795 for ; Thu, 21 Nov 2002 11:53:04 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALJpv9x020092; Thu, 21 Nov 2002 14:51:57 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id gALJpvfR000595; Thu, 21 Nov 2002 14:51:57 -0500 (EST) Message-Id: <200211211951.gALJpvfR000595@thunk.east.sun.com> From: Bill Sommerfeld To: "Brian Zill" cc: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses In-Reply-To: Your message of "Thu, 21 Nov 2002 11:45:13 PST." Reply-to: sommerfeld@east.sun.com Date: Thu, 21 Nov 2002 14:51:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 3. They cannot be externally routed (Some would > consider this to be a minus as well). > I believe 1 and 2 can be solved (fairly) easily by other means. The big > problem is number 3. The ambiguity is essential to preventing them from > ever being routed. so, i'm not conviced that we have this third property adequately written down in the existing site-local case. The ambiguity means that you can't count on them working, but because of the likelihood of configuration error plus the likelihood that many/most routers will forward site-locals by default, you can't count on them reliably not working, either! - 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 Thu Nov 21 12:07:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALK78Uu001039; Thu, 21 Nov 2002 12:07:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALK78eK001038; Thu, 21 Nov 2002 12: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALK75Uu001031 for ; Thu, 21 Nov 2002 12:07:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALK7FMq023808 for ; Thu, 21 Nov 2002 12:07:15 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28343 for ; Thu, 21 Nov 2002 13:07:07 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id PAA19015; Thu, 21 Nov 2002 15:07:01 -0500 (EST) Date: Thu, 21 Nov 2002 15:07:01 -0500 (EST) From: Dan Lanciani Message-Id: <200211212007.PAA19015@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: Proposal for site-local clean-up Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown wrote: |On Mon, Nov 18, 2002 at 10:49:42PM -0500, Dan Lanciani wrote: |> |> We have always been told that stable global v6 addresses will not be available |> to end users, or at least will not be available to end users at a low cost. | |Told by who? Folks on this list every time provider-independent global addresses or stable identifiers are brought up... |I can see ISPs wanting to charge for extra services where they |can, and thus for a static /48 as they do now for a static single IPv4 |address. But I would hope that enough ISPs would offer free static /48's |to take custom from those who charge. Given that this is not happening now for single static v4 addresses, your analogy would seen to suggest the opposite. |The only "snag" is that such ISPs |with 10M customers would need a lot more than a /32, esp. taking into |account the HD-ratio. This isn't just a "snag." The hierarchical addressing architecture consumes address space exponential in the number of providers in the chain. This makes it very difficult to break away from the limited business models currently contemplated. In order to be the kind of provider you suggest the ISP probably has to move "up" a level in the chain. Suddenly that huge address space is looking a lot smaller... Erik Nordmark wrote: |If the ISP provide the disservice of unstable IP addresses I think we have |a large class of problems. The fact that site-local addresses might ameliorate |some of those problems doesn't magically make such ISP disservice useful. No, but the existence of an alternative may help to avoid the disservice in the first place. By taking away the alternative you give the ISPs a huge lever to charge whatever the market will bear, at least until NAT is available. By reducing the need for (and thus the perceived value of) stable addresses you may be able to reduce their cost. Keith Moore wrote: |> We have always been told that stable global v6 addresses will not be available |> to end users, or at least will not be available to end users at a low cost. | |I think this depends on what you mean by "stable". For some reason the |community has been reluctant to specify a number here, and the result |is that people have widely varying ideas about what we can expect in practice. The community has been reluctant to specify a number because it isn't clear that stability is other than a binary attribute. The worst part of keeping this whole stability issue in limbo is that it's always possible to argue that things will be "stable enough" that we don't have to solve the renumbering problem. This in turn means that lack of stability will always be an encumbrance and thus stability will command a premium. |I don't think we want to let the reliable operation of applications be |an accident, nor do I think we want to trust market forces to sort this |out. I agree. This is exactly why we desperately need scoped addressing or a comparable mechanism that allows users to control the stability of their networks. |> Unless you are proposing to revise the whole address allocation architecture |> *and* have a way to force ISPs to change their business models I think we must |> accept this as a given. | |I don't think it's necessary to "force" anything, and casting things in these |terms makes them seem more difficult than they really are. I am merely observing current business practices and projecting a reasonable continuation of those practices. You on the other hand keep implying that there will be a significant change in the business models, but you decline to provide any plausible justification for your expectations. Repeatedly asserting that everything is going to be copacetic will not make it so. |> I think you have made an unreasonable leap by dropping the "stable" qualifier. |> The value/importance of _stable_ local communication is almost certainly much |> higher than the value/importance of _stable_ global communication. | |No. You erroneously assume that different applications are used for local |and global communications, No. The assumption is that people have different expectations and needs for local versus global connectivity. This is not my assumption but the assumption of the v6 addressing architecture. This assumption, while aesthetically unappealing, is clearly correct for many users. This assumption is behind the compromise of giving up portable globals in exchange for a local solution that is better integrated than NAT. |and you are over-generalizing the case for |stable global communications from two very specific cases. Too many people |think that the Internet only needs to support web and email. If that were |the case we wouldn't need IPv6 at all. | |The 'local' versus 'global' distinction is a false one. These would be great points if you were arguing for (and I were arguing against) a return to user-owned portable global/stable addresses. But I've never seen you arguing for such a return while I in fact have tried to make the case for portable globals. The v6 addressing architecture has already taken away the ability to have stable global addressing without the (presumably paid) cooperation of your ISP. You are not proposing to fix this. You are proposing to also take away the ability to have stable local addressing. Your argument that we should give up stable local communication because it would be nice if global communication were stable is specious. If you would like to campaign for a return to user-owned global/routable/stable addresses I'll support you 100%. If that battle were won, the need for scoped addressing would be significantly reduced. But win that battle before you try to take away stable locals. |I run NFS over TCP |over IPv6 over long distances, and it works. I ran RVD over the ARPANet before NFS ever existed. Unfortunately, we are in the minority of users. The v6 architecture was designed to mimic (perhaps even to the point of caricature) what the v4 internet has become: predominantly a big cloud of ephemeral, dynamically-addressed clients talking to a smaller cloud of static servers. The v6 address architecture does not lend itself to the peer-to-peer applications that were possible in the flat, pre-aggregation v4 internet. That doesn't mean that there won't be peer-to-peer applications in v6, but they will end up using the same kinds of kludgy rendezvous protocols that dynamically addressed v4 nodes now use. |And yes, I'm screwed if |my ISP changes my IP address (fortunately they have agreed to not do that). |I also regularly send print jobs over the same connection. I'm happy for you if you have a relationship with an ISP that will allow you to keep stable address space when/if v6 gets beyond its experimental stage. But don't you think you are being a bit shortsighted to try to take away the only kinds of stable addresses that will be available to people who do not have such relationships? |> |In any case, for a home user I suspect that the value/importance of |> |local communication would typically be less than the value/importance |> |of global communication. |> |> Again assuming we are talking about _stable_ communication, I believe that |> you are incorrect. Granted those of us who depend on our home networks for |> automation and such are currently on the bleeding edge, but what about the |> future when every stereo and tv is on the net? It's one thing to have to |> re-click that remote link in the browser, but quite another to have your |> stereo refuse to change channels. Consumers are not going to pay their ISP |> a premium to keep their stereos working. I know it sounds nice in theory, |> but look what happened to Divx. If you take away scoped addressing we _will_ |> use NAT. | |Threatening to destroy the utility of IPv6 if you don't get your way |won't get you much support here. Perhaps you should take another tack. So in other words you don't have a solution for the problem without using NAT or site locals? |I don't understand why you expect that ISPs will treat v6 exactly the |same as v4, I've explained this several times already, but I'll explain it again. ISPs use addresses as a surrogate measure of bandwidth. They use the number of addresses to control the number of machines using bandwidth. They use the (lack of) stability of addresses to control server usage because servers are perceived to consume more bandwidth (and in any case are a "premium" usage). Nothing in the change from v4 to v6 in any way affects these considerations. Now, as I've asked several times before, can you please explain why you think things will change? |when if they do it this way there is no reason for their |customers to pay for this additional service. Are you talking about v6 as an additional service over v4 or about stable addresses as an additional service? If the latter then the answer is that they will pay for the same reason they pay now plus (if you have you way) they will pay to keep their stereo and tv going smoothly right up until v6 NAT is implemented in all the consumer/retail router appliances. If the former then I think the answer is that most typical end users will not seek out v6 as an additional service at all since it offers virtually no benefit to the them while provoking significant upgrade costs. They may be forced to accept v6 first by claims that there are no more v4 addresses and (much) later by owning widgets that use v6 exclusively. In any case, I thought you said above that you did want to trust market forces to sort things out. You seem to now be falling back on an (IMHO) extremely naive analysis of how market forces will sort things out... |perhaps ISPs will charge |more for v6 than for v4, and they'l claim that they're doing so because |v6 addresses are stable. Perhaps. I'm not sure what difference it makes. |> Depriving users of the tools necessary to make productive use |> of their networks without paying for stable globals for all internal nodes |> will just encourage yet another round of kludges. | |Bottom line is that we need addresses to be (reasonably) stable at both |the local and the global level. We would like global addresses to be stable, but clearly we have a current existence proof that we do not need this. The world is getting on just fine with unstable v4 addresses for lowly end users. Even if we did need stable global addresses the _need_ for stable global addresses would not obviate the need for stable local addresses. Perhaps the ready _availability_ of stable global addresses would obviate the need for separate stable local addresses (or perhaps not) but we are a far cry from being able to guarantee such availability. |It's not sufficient to just have stable |local addresses It may not be sufficient to have stable locals, but clearly it is necessary. |- especially given the problems that SLs cause. The difficulty of implementing a solution has nothing to do with its sufficiency. Erik Nordmark wrote: |Sorry for the delayed response - didn't see me in the to: or cc: fields. I try to keep all the mail to the list just to the list... |> |In terms of the stability of the addresses one has to take into account |> |both stability as it relates to local communication and stability for |> |global communication. |> |> We have always been told that stable global v6 addresses will not be |> available to end users, or at least will not be available to end users at a |> low cost. Unless you are proposing to revise the whole address allocation |> architecture *and* have a way to force ISPs to change their business models |> I think we must accept this as a given. | |The temporal stability of addresses have a temporary component - it isn't |black and white. That is at best unclear. Ultimately I think many users will find that stability is a binary property. Either some outside party can change the address out from under you or they can't. |Crystal ball: |I wouldn't be surprised if small sites renumber the IPv6 addresses once |a year with an overlap (both new and old working for a week perhaps). How much will I have to pay to get this "small site" level of service for my home? |I see no reason why one would ever want to change them once a day. Obviously there is no reason for a user to want to do this, but ISPs certainly have reasons. |Taking together globally things means that there will be lots of renumbering |in progress at any given time (given millions of sites and a reasonably long |overlap). I agree that there will be lots of renumbering going on. |Thus I'm not too worried about e.g. my home site changing IPv6 prefixes |all the time. I am worried. | Of course, there is a concern for applications which keep |a connection open for a long time (weeks), My distributed home automation system's processes keep their connections open constantly from the point where they are started in /etc/rc to the point where the system(s) crash. My systems have reached uptimes of over a year. I have big batteries on my UPS's and a backup generator for when they start to get low. |but I suspect that such applications |are, or need to be, capable of reconnecting since they need to be able to deal |with peer failure. My applications are fully capable of reconnecting in any sequence after any machine or process dies for whatever reason. But that is completely different from being able to reconnect after addresses have changed. |> I think you have made an unreasonable leap by dropping the "stable" |> qualifier. The value/importance of _stable_ local communication is almost |> certainly much higher than the value/importance of _stable_ global |> communication. | |Even with the "stable" qualifier my opinion is the same. |You are welcome to disagree. I do disagree, but I get the feeling that it doesn't matter much. |> But my NFS client is simply not prepared to have its server's |> address renumbered out from under it. My multi-hour build will fail unless |> I notice the problem and fire up adb on the kernel in a hurry. Similarly my |> print job will fail if the printer and/or client is/are renumbered in the |> middle of a tcp session. | |You seem to be assuming flash renumbering without overlap. Yes, that is the only reasonable assumption to make. Just as ISPs now use short DHCP leases and related dynamic adderssing techniques to discourage what they perceive as "bandwidth hungry server activity" they will use frequent renumbering to achieve the same goals. Without site locals they will have the added advantage of being able to disrupt not only your "server's" accessibility from the internet, but your stereo and your tv as well. At least they will be able to do this until v6 NAT appears. Please explain why you assume that ISPs will change their business models under v6. |> My distributed home automation system, while quite tolerant |> of temporary lost connections and machine reboots, can not deal with |> addresses changing out from under it. This is hardly unreasonable because |> the tools to deal gracefully with such situations have not yet been |> invented. To make such things work now each application would have to |> implement its own procedures to deal with unstable addresses. This is |> obviously not acceptable to application writers. | |And the tools to deal in a robust manner with multiple-scopes of addresses |have not been applied to your home automation system either. Sure they have. As far as I can tell, my applications would work just fine with site-locals and the default address selection rules. I wouldn't even have to play DNS games because all these applications look up their servers or peers under a sub-domain I set up for that purpose. All I would have to do is populate that sub-domain with stable site-locals. |To be it makes more sense to get applications to | - not cache DNS answers forever So how long can you cache DNS answers? | - be prepared to restart connections after redoing a DNS lookup | if the connections are open for a long time (days or more). |I think this is less work, since many applications can get away with |doing nothing, than having all applications handle different scope addresses. I think you are trivializing an extremely complicated process. To make this work well DNS has to become a fully push system and domain names have to replace literals pretty much everywhere. We are talking about a major paradigm shift for applications. This at the same time that other site-local detractors are encouraging the use of literals in, e.g., web pages. Can we see some commitment from application writers that they actually plan to do as you suggest? I don't want to hear later that, well, this is too much to expect from applications and you should really pay for those stable addresses. But I begin to recognize the same argument that was used against global identifiers. Addresses are going to be stable *enough* and renumbering is going to be infrequent *enough* and dynamic DNS is going to work well *enough* and applications are going to learn to cope with dynamic addresses *enough* and ISPs are going to become philanthropic *enough* that somehow all mixed together things will work well *enough*. The only difference is that the previous argument went on, ``and if you really need local communication stability you can always use site-local addresses.'' I'm still extremely dubious that things will just work out. It's getting very, very late in the game to be deferring the solution with yet another round of buck-passing. |> We understand that sites are administrative. | |Section 4 in draft-ietf-ipngwg-scoping-arch seems to say something differnet. |A site doesn't span multiple administrations, but it is limited |to a single geographic location, such as an office, an office complex, or |a campus. Your implication before seemed to be that sites locals didn't make sense because the geographic description could span administrative domains. I don't really follow your reasoning either way, but it doesn't matter. My house is a single administrative domain and a single geographic location. |> |So let's not loose sight of the fact that the goal is a robust network. |> |> I think that the goal is a useful network--useful not only for ISPs and |> application vendors but for consumers. | |Agreed. I don't think I was saying anything different. Actually, I think there is a big difference. You can make the network very robust and easy to maintain for ISPs while at the same time making it less useful for consumers. You can make the network an easier environment for application programmers while at the same time making it less useful for consumers. I've noticed that the v6 design process has paid a great deal of attention to the needs of the ISP, some attention to the needs of the application developer, and very little attention to the needs of the end user. In fact, many important end-user issues have been treated as after- thoughts or addressed only under pressure from the media (e.g., privacy concerns over MAC IDs). Several of the proposals for fake multi-homing (where you pay both providers but get no benefit from the redundancy) would have made for really funny reading were the problem not so serious. A complete lack of user-controlled address space is going to make v6 a very hard sell... 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 Nov 21 12:32:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALKW6Uu001253; Thu, 21 Nov 2002 12:32:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALKW5KP001252; Thu, 21 Nov 2002 12:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALKW2Uu001242 for ; Thu, 21 Nov 2002 12:32:02 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALKWCMq004758 for ; Thu, 21 Nov 2002 12:32:12 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12644 for ; Thu, 21 Nov 2002 13:32:06 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gALKW5Y26007 for ; Thu, 21 Nov 2002 22:32:05 +0200 Date: Thu, 21 Nov 2002 22:32:04 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: "unique enough" generation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I'm assuming that for the intents and purposes of replacing "local" site-locals, "nearly unique" site-locals would be enough. (Actually, the change would be quite nice if implemented under fec0::/10 -- not many changes at all.) I'd like to focus a bit on how to generate these "nearly unique" site identifiers. Different dimensions here, which I could quickly think of, are: 1) randomly generated, or 2) "semi-provably" generated And for more detailed analysis: 1) is easy -- just use random generation, has of (MAC + timestamp), whatever. 2) would be based on some semi-stable identifier. If you'd like the property to be able to re-generate the site identifier later and get the same result, this is what you'd like. This may have some benefits, like automatic configuration is used without co-ordination in more than one location (e.g. using a company name as a key for hashing). This would also be desirable if you don't want to store the resulting site-id in some stable storage (really, should not be a problem). It seems likely that just randomly generated site-id's should be enough for everyone unless there are some synchronization requirements I'm not aware of. Did I miss something crucial? It appears to me that we have a very obvious and clear solution here, not even requiring any IANA/IESG action to get kickstarted. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 13:25:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALLPdUu001742; Thu, 21 Nov 2002 13:25:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALLPdSb001741; Thu, 21 Nov 2002 13:25: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALLPaUu001734 for ; Thu, 21 Nov 2002 13:25:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALLPfMq019745 for ; Thu, 21 Nov 2002 13:25:46 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16413 for ; Thu, 21 Nov 2002 14:25:35 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id QAA19248 for ipng@sunroof.eng.sun.com; Thu, 21 Nov 2002 16:25:34 -0500 (EST) Date: Thu, 21 Nov 2002 16:25:34 -0500 (EST) From: Dan Lanciani Message-Id: <200211212125.QAA19248@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: "unique enough" generation Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: |I'm assuming that for the intents and purposes of replacing |"local" site-locals, "nearly unique" site-locals would be enough. [...] |It appears to me that we have a very obvious and clear solution here, not |even requiring any IANA/IESG action to get kickstarted. A solution to which problem exactly? I'm all in favor of unique site locals, but I don't see how they eliminate the need to deal with scopes. They are extremely attractive in that they will allow us to interconnect sites with dynamic tunnels, bypassing ISP restrictions on address count and stability. By treating "native" aggregated addresses in effect as routes we can easily build a distributed routing layer that scales indefinitely and hides all the problems of unstable addresses from the applications. 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 Nov 21 13:36:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALLa9Uu001828; Thu, 21 Nov 2002 13:36:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALLa9s4001827; Thu, 21 Nov 2002 13:36:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALLa5Uu001820 for ; Thu, 21 Nov 2002 13:36:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALLaFbB020340 for ; Thu, 21 Nov 2002 13:36:15 -0800 (PST) Received: from srv0.ops.ietf.org (srv0.ietf55.ops.ietf.org [205.238.48.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02782 for ; Thu, 21 Nov 2002 14:36:10 -0700 (MST) Received: from dhcp-204-42-68-213.ietf55.ops.ietf.org ([204.42.68.213] helo=eng.monash.edu.au) by srv0.ops.ietf.org with esmtp (Exim 4.10) id 18EyzZ-0002o1-00; Thu, 21 Nov 2002 21:36:09 +0000 Message-ID: <3DDDDE31.24DA1A74@eng.monash.edu.au> Date: Fri, 22 Nov 2002 07:35:13 +0000 From: Richard Nelson X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.19hilc i686) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: Brian Zill Subject: Re: globally unique site local addresses References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Zill wrote: > > > 1. They're free. > 2. They can be (auto)configured without having > to co-ordinate with some outside entity. > 3. They cannot be externally routed (Some would > consider this to be a minus as well). > > An IETF edict not to route some new form of > non-ambiguous addresses will be ignored by those who wish to route them. > This will likely lead to pressure to turn these new addresses into > yet-another type of global address with all the associated routing table > explosion inherent to non-aggregatable address space. Another way to > look at it is that the current ambiguity in site-locals is a means for > protecting the global routing space. If we do away with the ambiguity, > we need another method for keeping the global routing tables sane. > I can understand that users of the non-aggregatable address space will try and pressure their ISPs to route it, but they won't have any contract with the upstream ISPs who _should_ be only too happy to filter non-aggregatable addresses from the routing tables. Do you think that this + a really strong statements and specification up front has no chance of working? > The only class of solution which I think will truly make everyone happy > is to come up with an *aggregatable* globally unique address space that > still has properties 1 and 2. In other words, some sort of > provider-independent global address space. Properties 1 and 2 are much > easier when the aggregatable property is not required. The reason we're > in the state we are today is because this is a hard problem. Well if you are connected then you should have enough PA addresses that 1. is not a problem and given SAA, configuration is not much more work than configuring a few I Pv4 addresses on to a NAT box so 2 isn't such a big deal either. The only real advantage is 3. This solution really only has the advantage of long term stability. I think that inherent non routability would be as much of a desirable feature of such addresses. Richard. > > --Brian > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 13:43:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALLhmUu001912; Thu, 21 Nov 2002 13:43:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALLhmlD001911; Thu, 21 Nov 2002 13:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALLhjUu001904 for ; Thu, 21 Nov 2002 13:43:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALLhtMq024954 for ; Thu, 21 Nov 2002 13:43:55 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07922 for ; Thu, 21 Nov 2002 14:43:49 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gALLhiq26645; Thu, 21 Nov 2002 23:43:44 +0200 Date: Thu, 21 Nov 2002 23:43:43 +0200 (EET) From: Pekka Savola To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: "unique enough" generation In-Reply-To: <200211212125.QAA19248@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 On Thu, 21 Nov 2002, Dan Lanciani wrote: > |It appears to me that we have a very obvious and clear solution here, not > |even requiring any IANA/IESG action to get kickstarted. > > A solution to which problem exactly? Look at Christian Huitema's mail today. The only thing this can't provide is global routability. > I'm all in favor of unique site locals, > but I don't see how they eliminate the need to deal with scopes. I'm not sure why we'd have to be able to kill scopes. > They are > extremely attractive in that they will allow us to interconnect sites with > dynamic tunnels, bypassing ISP restrictions on address count and stability. > By treating "native" aggregated addresses in effect as routes we can easily > build a distributed routing layer that scales indefinitely and hides all the > problems of unstable addresses from the applications. I don't see any significant problems which would prevent this, even though we may still want to prevent the use of these site-locals to disconnected or semi-disconnected sites. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 14:02:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALM2QUu002062; Thu, 21 Nov 2002 14:02:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALM2QNR002061; Thu, 21 Nov 2002 14:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALM2NUu002054 for ; Thu, 21 Nov 2002 14:02:23 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALM2XMq000892 for ; Thu, 21 Nov 2002 14:02:33 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08586 for ; Thu, 21 Nov 2002 14:02:27 -0800 (PST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 21 Nov 2002 14:01:04 -0800 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 21 Nov 2002 14:01:00 -0800 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.3710.0); Thu, 21 Nov 2002 14:00:46 -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, 21 Nov 2002 14:00:46 -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.3710.0); Thu, 21 Nov 2002 14:00:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: "unique enough" generation Date: Thu, 21 Nov 2002 14:00:59 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "unique enough" generation Thread-Index: AcKRnWgtpoK8+2D0SgeGpXpVNUVy1wACZDRA From: "Christian Huitema" To: "Pekka Savola" , X-OriginalArrivalTime: 21 Nov 2002 22:00:59.0267 (UTC) FILETIME=[796FDD30:01C291A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gALM2NUu002055 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm assuming that for the intents and purposes of replacing > "local" site-locals, "nearly unique" site-locals would be enough. Not quite. You should get the slides of Rob Austein presentation to the working group. We must really separate two issues, reachability and ambiguity. It is very easy to ensure that a block of address is not reachable -- any firewall can do that. But just because an address is unreachable does not mean that they could just as well be ambiguous, because these ambiguous addresses end up leaking in various places: DNS records, source of ICMP packets, next hop in BGP messages, "received" headers in mail or "via" headers in SIP, etc. In short, buggy addresses appear at places where they should not. Ambiguity causes problem, because you can never debug these problems. I realize that we have a tension between two requirements, uniqueness which imposes some form of registration, and "free use" which imply making up the addresses locally and virtually guaranteeing possible collisions. Maybe we have to embrace the dilemma, and allow for several types of identifiers, some guaranteed unique and some quasi random. But you must definitely provide unique numbers to those who are ready to wait for registration. -- 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 Nov 21 14:16:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALMGVUu002262; Thu, 21 Nov 2002 14:16:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALMGV0U002261; Thu, 21 Nov 2002 14:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALMGSUu002254 for ; Thu, 21 Nov 2002 14:16:28 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALMGcbB001768 for ; Thu, 21 Nov 2002 14:16:38 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18703 for ; Thu, 21 Nov 2002 14:16:31 -0800 (PST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id RAA19445 for ipng@sunroof.eng.sun.com; Thu, 21 Nov 2002 17:16:30 -0500 (EST) Date: Thu, 21 Nov 2002 17:16:30 -0500 (EST) From: Dan Lanciani Message-Id: <200211212216.RAA19445@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: "unique enough" generation Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: |> I'm all in favor of unique site locals, |> but I don't see how they eliminate the need to deal with scopes. | |I'm not sure why we'd have to be able to kill scopes. Fine by me. It's just that dealing with scopes seems to be the problem that most people are complaining about rather than the existence of the addresses themselves. |> They are |> extremely attractive in that they will allow us to interconnect sites with |> dynamic tunnels, bypassing ISP restrictions on address count and stability. |> By treating "native" aggregated addresses in effect as routes we can easily |> build a distributed routing layer that scales indefinitely and hides all the |> problems of unstable addresses from the applications. | |I don't see any significant problems which would prevent this, even though |we may still want to prevent the use of these site-locals to disconnected |or semi-disconnected sites. Then I propose the same thing I (and others) have proposed in the past. Pick a prefix xxxxxx from the SL space at random and append the hex to some well known string, e.g., "mysiteprefix" giving mysiteprefixxxxxxx. Register mysiteprefixxxxxxx.com as a domain name. If it already exists, pick a new random number and try again. This provides the uniqueness without involving a new registry service and the nominal fee will discourage people from over- consuming. To move to the next step (assuming you want outside connectivity), register an ISP-provided global as the address for this domain (or a sub-domain; there are some optimizations that can be made). This is your tunnel destination. When another site wants to send packets to you, their router recognizes the prefix as a site-local-unique address and, if the tunnel destination isn't already cached, performs a DNS lookup of mysiteprefixyyyyy.com. If (as some folks claim) the dynamic DNS will be good enough to handle the instability of that ISP-provided global for host name lookups then it will be good enough for this as well. If (as is more likely) the DNS won't be up to the task the situation can be improved by having tunnel end points send hints to recent partners when their addresses are renumbered. 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 Nov 21 14:21:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALMLnUu002327; Thu, 21 Nov 2002 14:21:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALMLnqn002326; Thu, 21 Nov 2002 14:21:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALMLkUu002319 for ; Thu, 21 Nov 2002 14:21:46 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALMLubB003391 for ; Thu, 21 Nov 2002 14:21:56 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20312 for ; Thu, 21 Nov 2002 15:21:49 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gALMLln26992; Fri, 22 Nov 2002 00:21:47 +0200 Date: Fri, 22 Nov 2002 00:21:46 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: ipng@sunroof.eng.sun.com Subject: RE: "unique enough" generation 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, 21 Nov 2002, Christian Huitema wrote: > > I'm assuming that for the intents and purposes of replacing > > "local" site-locals, "nearly unique" site-locals would be enough. > > Not quite. Depends on what you want. (Perhaps we should try to formulate these better first, but it's more interesting to just pop up some solutions :-). I believe these will allow for all the cases site-locals were used in "limited" cases in the meeting, probably even those in "moderate" on the side. [...] > unreachable does not mean that they could just as well be ambiguous, > because these ambiguous addresses end up leaking in various places: DNS > records, source of ICMP packets, next hop in BGP messages, "received" > headers in mail or "via" headers in SIP, etc. In short, buggy addresses > appear at places where they should not. Ambiguity causes problem, > because you can never debug these problems. I'm not sure what you mean exactly. Suppose someone's fec0:1234:5678::1 leaks to the global DNS somehow. Someone else has fec0:abcd:deff::1 configured in their site. When you configure your sites prefix length as e.g. /48 but still have a null-route (and filters) for fec0::/10, there should be no problems with connections at all -- they don't work as they shouldn't. > I realize that we have a tension between two requirements, uniqueness > which imposes some form of registration, and "free use" which imply > making up the addresses locally and virtually guaranteeing possible > collisions. Maybe we have to embrace the dilemma, and allow for several > types of identifiers, some guaranteed unique and some quasi random. ... > But > you must definitely provide unique numbers to those who are ready to > wait for registration. Which kind of users would require this kind of complete, guaranteed uniqueness? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 14:30:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALMUtUu002440; Thu, 21 Nov 2002 14:30:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALMUtni002439; Thu, 21 Nov 2002 14:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALMUqUu002432 for ; Thu, 21 Nov 2002 14:30:52 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALMV2Mq009720 for ; Thu, 21 Nov 2002 14:31:02 -0800 (PST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28199 for ; Thu, 21 Nov 2002 14:30:56 -0800 (PST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gALMUpm10179; Thu, 21 Nov 2002 23:30:51 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gALMUpte040465; Thu, 21 Nov 2002 23:30:51 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211212230.gALMUpte040465@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charlie Perkins cc: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes In-reply-to: Your message of Thu, 21 Nov 2002 07:25:27 PST. <3DDCFAE7.4BE72578@iprg.nokia.com> Date: Thu, 21 Nov 2002 23:30:51 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: We certainly don't want an unclear specification. And, if a network manager needs to support mobile nodes on any local domains, that network manager needs in many circumstances to have the information that running more frequent advertisements is advisable. => I don't want to use frequent RAs on my network because there is an 802.11 AP on it (APs are L2 bridges). Can you suggest a way to make the specification more clear? => last chance solutions should be marked and never get more than a MAY. However, when that option is not available, our experience and that of many others shows that the faster beaconing is effective and can be applied without any surprises. => another concern is RAs are bad beacons... There have been numerous papers published about this, which led to the appropriate specification for Mobile IPv4. The situation for Mobile IPv6 is not any different. => I'd really like to get a spec without surprise applicable in my fast Ethernet LAN with 5 routers, 50 hosts and 2 APs. BTW there are 3 prefixes on it (multi-homed between two ISPs). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 14:34:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALMYtUu002488; Thu, 21 Nov 2002 14:34:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALMYtA0002487; Thu, 21 Nov 2002 14:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALMYpUu002480 for ; Thu, 21 Nov 2002 14:34:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALMZ1bB007030 for ; Thu, 21 Nov 2002 14:35:01 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28347 for ; Thu, 21 Nov 2002 15:34:55 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id AAA30729; Fri, 22 Nov 2002 00:34:44 +0200 Date: Fri, 22 Nov 2002 00:34:44 +0200 Message-Id: <200211212234.AAA30729@burp.tkv.asdf.org> From: Markku Savela To: ipng-incoming@danlan.com CC: ipng@sunroof.eng.sun.com In-reply-to: <200211212216.RAA19445@ss10.danlan.com> (message from Dan Lanciani on Thu, 21 Nov 2002 17:16:30 -0500 (EST)) Subject: Re: "unique enough" generation References: <200211212216.RAA19445@ss10.danlan.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Fine by me. It's just that dealing with scopes seems to be the problem that > most people are complaining about rather than the existence of the addresses > themselves. I cannot understand those people complaining about scopes. We will have (a) addresses that are global (b) addresses that are local, with limited reach (firewalled or whatever) Now, if we have (b), isn't it a great advantage that an application can at least see that this address may have reachability problems, by looking it's scope level? The proposals of allocating something slices from "global space" for (b) addresses seem insane to me. After that, applications just have no way of getting even a warning that using such address might be problematic. Situation is even worse than with site locals available! The "global space" might as well be the current site local prefix. Interconected sites that agree to exhange routing information about (b) addresses, on might even define a new prefix, with scope between site local and global. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 14:39:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALMdpUu002587; Thu, 21 Nov 2002 14:39:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALMdpZu002586; Thu, 21 Nov 2002 14:39:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALMdmUu002579 for ; Thu, 21 Nov 2002 14:39:48 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALMdwbB008488 for ; Thu, 21 Nov 2002 14:39:58 -0800 (PST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05176 for ; Thu, 21 Nov 2002 14:39:52 -0800 (PST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gALMdjm10355; Thu, 21 Nov 2002 23:39:45 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gALMdjte040504; Thu, 21 Nov 2002 23:39:45 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211212239.gALMdjte040504@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Samita Chakrabarti cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.sun.com Subject: Re: Proposal for MIPv6 APIs to switch default source address selection In-reply-to: Your message of Thu, 21 Nov 2002 07:50:26 PST. <3DDD00C2.B2EABF68@eng.sun.com> Date: Thu, 21 Nov 2002 23:39:45 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => the problem of this API is that it is not useful because nobody wants > to change all applications to use it. So we need also a way to change I am not sure why you are saying that all applications needs to change for this. => in order to use the API, an application needs to be changed. So with only the API, the only way to influence the Co@/H@ choice is to change all common applications... So the API will get only very limited use and the smart user should still wait for a device to fulfill his needs. they need to use COA for local cases in the visited link. => yes, all the short term not bound to the home applications could like to use a Co@. There are a lot of situations where to get communications killed by movements is not a problem... some existing apps would have to be modified or written for MIPv6 anyway. => we have to keep the number of such applications as low as possible. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 14:57:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALMvvUu002865; Thu, 21 Nov 2002 14:57:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALMvvx9002864; Thu, 21 Nov 2002 14:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALMvsUu002857 for ; Thu, 21 Nov 2002 14:57:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALMw3bB013626 for ; Thu, 21 Nov 2002 14:58:04 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02916 for ; Thu, 21 Nov 2002 15:57:57 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id AAA30793; Fri, 22 Nov 2002 00:57:52 +0200 Date: Fri, 22 Nov 2002 00:57:52 +0200 Message-Id: <200211212257.AAA30793@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com In-reply-to: <200211212234.AAA30729@burp.tkv.asdf.org> (message from Markku Savela on Fri, 22 Nov 2002 00:34:44 +0200) Subject: Re: "unique enough" generation References: <200211212216.RAA19445@ss10.danlan.com> <200211212234.AAA30729@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > (a) addresses that are global > (b) addresses that are local, with limited reach (firewalled or > whatever) Of course, having only (a) would be ideal. But, this would work only if the whole address allocation is turned upside down: - you don't get addresses from your ISP, everyone/every site is automaticly entitled to unique global address range. When one makes a contract with ISP about route, the ISP will make it packets with these addresses flow correctly. - of course, any random address generation won't scale. But, the proposals for generating unique addresses from geographical position coordinates might be one way, and might scale. So, let's scrap the current address allocation and just define rules how to generate address from location (and maybe need a floor number, or height for buildings.. :-) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 15:14:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALNEnUu003017; Thu, 21 Nov 2002 15:14:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALNEnSJ003016; Thu, 21 Nov 2002 15:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALNEkUu003009; Thu, 21 Nov 2002 15:14:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALNEuMq022329; Thu, 21 Nov 2002 15:14:56 -0800 (PST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23095; Thu, 21 Nov 2002 16:14:50 -0700 (MST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gALNEkm10916; Fri, 22 Nov 2002 00:14:46 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gALNEkte040674; Fri, 22 Nov 2002 00:14:46 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211212314.gALNEkte040674@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Alper E. YEGIN" cc: "Samita Chakrabarti" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection In-reply-to: Your message of Thu, 21 Nov 2002 10:32:54 PST. <001a01c2918c$73904980$bd412acc@AlperVAIO> Date: Fri, 22 Nov 2002 00:14:46 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: An alternative approach could be: If the application cares about the source address, it can use the Mobile IP API to figure out which ones are home address, which ones are care-of address, and than explicitly "bind" the socket to the desired address. IMO, this would also satisfy the needs of the Mobile IPv6 mobile node. => this is similar to what I implemented in the past. But a function giving the list of addresses with status is not enough, the best is to give the home address and the care-of address for a destination. As first info is getsockname() for bound sockets, I added a clone of getsockname() which returns the real source address after MIPv6 processing. Note this doesn't solve the need of a control for smarter choice between Co@/H@. I proposed some and implemented two: use always the H@ and use it but a Co@ when the destination is in the same link then a Co@. They were global (still better than none :-). Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 15:31:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALNVuUu003281; Thu, 21 Nov 2002 15:31:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gALNVu3J003280; Thu, 21 Nov 2002 15:31: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALNVrUu003273 for ; Thu, 21 Nov 2002 15:31:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gALNVvMq027443 for ; Thu, 21 Nov 2002 15:31:58 -0800 (PST) Received: from mail.nosense.org (193.cust2.nsw.dsl.ozemail.com.au [203.103.157.193]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA00172 for ; Thu, 21 Nov 2002 16:31:50 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id CA1413B367; Fri, 22 Nov 2002 10:31:41 +1100 (EST) Subject: Re: "unique enough" generation From: Mark Smith To: Markku Savela Cc: ipng-incoming@danlan.com, ipng@sunroof.eng.sun.com In-Reply-To: <200211212234.AAA30729@burp.tkv.asdf.org> References: <200211212216.RAA19445@ss10.danlan.com> <200211212234.AAA30729@burp.tkv.asdf.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 22 Nov 2002 10:31:41 +1100 Message-Id: <1037921508.3459.140.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 2002-11-22 at 09:34, Markku Savela wrote: > > > Fine by me. It's just that dealing with scopes seems to be the problem that > > most people are complaining about rather than the existence of the addresses > > themselves. > > I cannot understand those people complaining about scopes. We will > have > > (a) addresses that are global > (b) addresses that are local, with limited reach (firewalled or > whatever) I'd take a step back (up?) to a higher level and say there are only really three fundamental scopes : 1) External 2) Internal 3) Link local Reliable External communications requires globally unique addressing. Reliable Internal communications does not require globally unique addressing, but does require internally unique addressing. The current site-local model seems to me to be a too restrictive solution to the Internal communications requirement, as it creates artificial boundaries on the definition of Internal communications. Further, with the current site-local model, you have to assume that there will be addressing collisions when merging even the smallest of two "sites" - there is a fairly good chance that most people will use fec0:0:0:1::/64 for their first subnet. This duplicated address space, and almost guaranteed chance of address space collision seems to me to be the cause of a lot of the recent arguments about site-local addressing, including problems cross site address referrals etc, and solutions such as multi-site routers etc that just feel to be way to complex to me. Pekka's solution reverses that assumption. In the majority of cases, you won't have a duplicated (on a global scale) Internal address space, making merging "sites" a simple as bringing up the link between the sites, and pushing a few routes between the networks. On the rare occasions that there is a Internal address space collision under Pekka's model, it will (or at least should) be discovered during the preparation for the connection of the two "sites" together. In the case of a collision, having to renumber one of the Internal address spaces to make it unique again is unfortunate, but it is the price of requiring an Internal address space that is independent of your provider supplied global address space. Regards, 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 16:09:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM09lUu003477; Thu, 21 Nov 2002 16:09:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM09lvo003476; Thu, 21 Nov 2002 16:09:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM09iUu003469 for ; Thu, 21 Nov 2002 16:09:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM09sbB004238 for ; Thu, 21 Nov 2002 16:09:54 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20321 for ; Thu, 21 Nov 2002 17:09:48 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAM09jW5059992; Fri, 22 Nov 2002 01:09:46 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAM09i71030598; Fri, 22 Nov 2002 01:09:45 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA73712 from ; Fri, 22 Nov 2002 01:09:41 +0100 Message-Id: <3DDD75B1.26836FC7@hursley.ibm.com> Date: Fri, 22 Nov 2002 01:09:21 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: sommerfeld@east.sun.com Cc: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <200211211951.gALJpvfR000595@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Sommerfeld wrote: > > > 3. They cannot be externally routed (Some would > > consider this to be a minus as well). > > > I believe 1 and 2 can be solved (fairly) easily by other means. The big > > problem is number 3. The ambiguity is essential to preventing them from > > ever being routed. > > so, i'm not conviced that we have this third property adequately > written down in the existing site-local case. > > The ambiguity means that you can't count on them working, but because > of the likelihood of configuration error plus the likelihood that > many/most routers will forward site-locals by default, you can't count > on them reliably not working, either! In any case, if they can't be routed *even in a private network* you can be sure they will end up being NATted (e.g. when two companies merge, or when a company sets up a VPN to a business partner). Conversely, if they are globally unique they *will* be routed within private networks, using any old routing protocol. >From which I conclude that globally unique site locals will vastly damage the market for v6 NAT, so let's figure them out quickly. 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 Nov 21 16:11:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM0BQUu003497; Thu, 21 Nov 2002 16:11:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM0BQl7003496; Thu, 21 Nov 2002 16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM0BNUu003489 for ; Thu, 21 Nov 2002 16:11:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM0BXbB004703 for ; Thu, 21 Nov 2002 16:11:33 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21133 for ; Thu, 21 Nov 2002 17:11:27 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id TAA19768 for ipng@sunroof.eng.sun.com; Thu, 21 Nov 2002 19:11:26 -0500 (EST) Date: Thu, 21 Nov 2002 19:11:26 -0500 (EST) From: Dan Lanciani Message-Id: <200211220011.TAA19768@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: Re: "unique enough" generation Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela wrote: |> Fine by me. It's just that dealing with scopes seems to be the problem that |> most people are complaining about rather than the existence of the addresses |> themselves. | |I cannot understand those people complaining about scopes. They are complaining because a routing complexity issue has been pushed onto applications. I have trouble working up a lot of sympathy for the complaints, though. If they had put this much effort into complaining about the address architecture in the first place we could have solved the routing problem at the routing layer. | - you don't get addresses from your ISP, everyone/every site is | automaticly entitled to unique global address range. When one makes | a contract with ISP about route, the ISP will make it packets with | these addresses flow correctly. Yes, that's how things worked in the good old days. | - of course, any random address generation won't scale. That isn't clear. Central routing table size scales linearly with the number of addresses. Linear isn't as bad as some people make it out to be. The aggregation hack was a bad tradeoff because while it reduced the table problem from linear to log it changed the address usage from linear in users to exponential in provider chain height. It's very hard to win against an exponential. Fortunately, it is very easy to distribute the routing process and reduce the problem to a constant. So even if linear worries you there is an alternative. I outlined a simple way to distribute the routing in a previous message. It's not as neat as building it into the routing layer, but it works without changing the infrastructure. |But, the | proposals for generating unique addresses from geographical | position coordinates might be one way, and might scale. | |So, let's scrap the current address allocation and just define rules |how to generate address from location (and maybe need a floor number, |or height for buildings.. :-) That would certainly be one approach. Anything that leaves sites with some way to control address space will ultimately support a tunneling solution independent of whether the ISPs allow the addresses to be routed. 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 Nov 21 16:36:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM0avUu003763; Thu, 21 Nov 2002 16:36:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM0avrm003762; Thu, 21 Nov 2002 16:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM0arUu003755 for ; Thu, 21 Nov 2002 16:36:53 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM0b3Mq014814 for ; Thu, 21 Nov 2002 16:37:03 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA05619 for ; Thu, 21 Nov 2002 17:36:57 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id QAA19571; Thu, 21 Nov 2002 16:35:58 -0800 (PST) Message-Id: <5.1.0.14.0.20021121192205.02991fc8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Nov 2002 19:35:09 -0500 To: "Christian Huitema" From: Margaret Wasserman Subject: Re: globally unique site local addresses 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 Christian, I think that we need to work on understanding the goals of globally-unique, provider-independent addressing, so that we can properly evaluate the different proposals that we are likely to see. In my opinion, the addresses should be routable, although it isn't necessary that ISPs advertise them in global routing tables. For instance, I think it would be good if two "sites" could route their globally-unique, provider-independent addresses to each other. I don't know what you mean by "free". It would be acceptable, in my opinion, if people had to pay a registration fee for an address block. In what way is the consensus "just like site locals"? I think that we want something better than site-locals that solves the problems of: - persistent addresses to put in configuration files, security filters, etc. - addresses that can be used in intermittently connected sites and remain valid - addresses that survive ISP renumbering Without the use of ambiguous addresses. In addition, there are some other things we should solve that site-locals don't solve: - work properly when two organizations merge - be possible to associate with an administrative entity to which they are registered Are there other problems that we need to solve to make these addresses a preferrable alternative to site-locals? Margaret >* we want to remove ambiguity, which is the root cause of many problems >occuring when scoped addresses leak. > >* we may or may not want to prevent routing of these addresses between >sites. I guess we should certainly prevent routing between non-consenting >sites. > >* we definitely want the addresses to be provider independent, so they can >survive renumbering or intermittent connectivity. > >* indeed, it would be desirable that the addresses be usable in sites that >are not connected. > >* and we would definitely want the addresses to be free. > >One of the main point of contention regarded routing. I guess that the >consensus is, "just like site local addresses." We don't want to prevent >usage in connected sites, but we expect that in these sites the hosts will >also have provider based addresses, and that traffic routed out of the >site will use the provider addresses. > >Now, I guess we have to work from there. > >-- 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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 18:52:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM2qSUu004093; Thu, 21 Nov 2002 18:52:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM2qSVi004092; Thu, 21 Nov 2002 18:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM2qJUu004077; Thu, 21 Nov 2002 18:52:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM2qPMq018658; Thu, 21 Nov 2002 18:52:25 -0800 (PST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11575; Thu, 21 Nov 2002 19:52:19 -0700 (MST) Message-ID: <003701c291d1$f4f82250$bd412acc@AlperVAIO> From: "Alper E. YEGIN" To: "Francis Dupont" Cc: "Samita Chakrabarti" , , References: <200211212314.gALNEkte040674@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection Date: Thu, 21 Nov 2002 18:48:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > > An alternative approach could be: If the application cares about > the source address, it can use the Mobile IP API to figure out which > ones are home address, which ones are care-of address, and than > explicitly "bind" the socket to the desired address. IMO, this would > also satisfy the needs of the Mobile IPv6 mobile node. > > => this is similar to what I implemented in the past. > But a function giving the list of addresses with status is not enough, > the best is to give the home address and the care-of address for > a destination. I see. When the mobile node has more than one pair of home_address-care_of_address, then it won't really know which one to pick. So, maybe, instead of exporting all this information to the apps and giving them the control, it might be better to enable the app to say "bind this socket to any address, preferably topologically correct (i.e., a CoA, or home address when at home)". I suspect this is what Samita had in her mind.. > As first info is getsockname() for bound sockets, > I added a clone of getsockname() which returns the real source > address after MIPv6 processing. Or, don't change the getsockname(), but instead call mip_get_one_mobile_node() afterwards to identify if the address is bound to a care-of address. Note that this binding can dynamically any time, and subsequent mip_get_one_mobile_node() calls are sufficient to capture the changes. alper > Note this doesn't solve the need of a control for smarter choice > between Co@/H@. I proposed some and implemented two: use always > the H@ and use it but a Co@ when the destination is in the same > link then a Co@. They were global (still better than none :-). > > Thanks > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 19:11:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM3BsUu004341; Thu, 21 Nov 2002 19:11:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM3BroQ004340; Thu, 21 Nov 2002 19:11:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM3BoUu004330 for ; Thu, 21 Nov 2002 19:11:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM3C0bB015485 for ; Thu, 21 Nov 2002 19:12:00 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA03659 for ; Thu, 21 Nov 2002 20:11:46 -0700 (MST) 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 TAA10703; Thu, 21 Nov 2002 19:11:45 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAM3BjW27094; Thu, 21 Nov 2002 19:11:45 -0800 X-mProtect: <200211220311> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.162.14.29, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlzhksh; Thu, 21 Nov 2002 19:11:43 PST Message-ID: <3DDDA028.74BE671D@iprg.nokia.com> Date: Thu, 21 Nov 2002 19:10:32 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: ipng@sunroof.eng.sun.com Subject: Re: MIPv6 and ND value changes References: <200211212230.gALMUpte040465@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > => last chance solutions should be marked and never get more than > a MAY. Indeed, the frequency parameter is tunable. There is no specification that one HAS to use the advertisement as a beacon. You should only do this if it is suitable for your networks. You MAY use the fast rate, you are not in any way mandated to do so. 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 Nov 21 19:35:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM3ZUUu004658; Thu, 21 Nov 2002 19:35:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM3ZUAV004657; Thu, 21 Nov 2002 19:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM3ZRUu004650 for ; Thu, 21 Nov 2002 19:35:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM3ZbbB019361 for ; Thu, 21 Nov 2002 19:35:37 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18360 for ; Thu, 21 Nov 2002 20:35:31 -0700 (MST) Subject: RE: globally unique site local addresses MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 2002 19:35:30 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4A8@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses thread-index: AcKRkok6D2+rxoGCQqWrcsQUuj5mKwARFUIg From: "Michel Py" To: "Charlie Perkins" , "Tim Chown" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAM3ZRUu004651 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Charlie. There could be another model, where the end-site would request the block to one of their ISPs and the ISP access the IANA or RIR web site on behalf of the customer. I think that RIRs would be more comfortable with this. Also, there is nothing that says that we can't have both Pekka's almost unique *and* something like what I proposed which is completely unique at the same time. Michel. > Charlie Perkins wrote: > Maybe it could be done almost for free. > Maybe there could be a web page under the IANA > web page where a network administrator could > get the "next" site-local prefix. This would > be rate-limited so that only a few prefixes > would be given out per second, and so on. It > seems like it would work, at least well-enough > to be given a try. It would not require very > much administration on the part of IANA (or > whoever agreed to host the web page). Of > course, this only solves the one problem of > guaranteeing global uniqueness for the > site-local prefixes, and the other problems > remain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 19:35:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM3ZnUu004668; Thu, 21 Nov 2002 19:35:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM3ZmDZ004667; Thu, 21 Nov 2002 19:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM3ZhUu004660; Thu, 21 Nov 2002 19:35:43 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM3ZqbB019376; Thu, 21 Nov 2002 19:35:53 -0800 (PST) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29342; Thu, 21 Nov 2002 20:35:47 -0700 (MST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gAM3Zim14321; Fri, 22 Nov 2002 04:35:44 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gAM3Zhte041824; Fri, 22 Nov 2002 04:35:43 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211220335.gAM3Zhte041824@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Alper E. YEGIN" cc: "Samita Chakrabarti" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection In-reply-to: Your message of Thu, 21 Nov 2002 18:48:46 PST. <003701c291d1$f4f82250$bd412acc@AlperVAIO> Date: Fri, 22 Nov 2002 04:35:43 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I see. When the mobile node has more than one pair of home_address-care_of_address, then it won't really know which one to pick. So, maybe, instead of exporting all this information to the apps and giving them the control, it might be better to enable the app to say "bind this socket to any address, preferably topologically correct (i.e., a CoA, or home address when at home)". => not, my idea is as the application cares about the source, connect a socket to the destination and look at the source selected by the kernel. For mobility I add look at the real source selected (i.e., a Co@), not only the visible source (i.e., the H@). Note that all applications using raw sockets have to setup themselves the source so this kind of code is not uncommon. > As first info is getsockname() for bound sockets, > I added a clone of getsockname() which returns the real source > address after MIPv6 processing. Or, don't change the getsockname(), => I didn't change it: it still returned the bound address, i.e., the H@ on a MN. but instead call mip_get_one_mobile_node() afterwards to identify if the address is bound to a care-of address. => the address is not bound to a Co@ but the BC lookup will push the bound address (the H@) to a H@O and a Co@ will replace it at the source (in the IPv6 header). The function should simulate the MIPv6 processing (aka BC lookup) and return its result on the source address. Note that this binding can dynamically any time, and subsequent mip_get_one_mobile_node() calls are sufficient to capture the changes. => yes, the result of this function should not be cached. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 21 19:45:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM3jsUu004914; Thu, 21 Nov 2002 19:45:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM3jsu2004913; Thu, 21 Nov 2002 19:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM3jpUu004906 for ; Thu, 21 Nov 2002 19:45:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM3k0Mq027936 for ; Thu, 21 Nov 2002 19:46:01 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04016 for ; Thu, 21 Nov 2002 20:45:55 -0700 (MST) Subject: RE: globally unique site local addresses MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 2002 19:45:53 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4AA@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses thread-index: AcKRlopyejZjcWtWQUGujY586cJH0wAQizQQ From: "Michel Py" To: "Steven Blake" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAM3jpUu004907 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven, >> Michel Py wrote: >> Ambiguity is a fail-safe for routes that leak into >> the DFZ, even though they were not supposed to, and >> for ISPs that don't filter traffic, even though they >> were supposed to. In order to remove ambiguity, we >> must replace the fail-safe it provides by something >> else, and that something else is IMHO a requirement >> that router vendors implement the necessary filters >> as being default configuration. > Steven Blake wrote: > What technical problem are you trying to solve? Are > you trying to prevent inadvertent leakage of prefixes? Inadvertent, sabotage, hackers, stupidity, ignorance.... > Or are you trying to impose aggregatible prefixes on > institutions that may be able to afford other > arrangements? I don't see the relation? 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 Nov 21 19:52:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM3qZUu005031; Thu, 21 Nov 2002 19:52:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM3qZmN005030; Thu, 21 Nov 2002 19:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM3qVUu005023 for ; Thu, 21 Nov 2002 19:52:31 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM3qfbB022104 for ; Thu, 21 Nov 2002 19:52:41 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA24901 for ; Thu, 21 Nov 2002 20:52:35 -0700 (MST) Subject: RE: "unique enough" [RE: globally unique site local addresses] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 2002 19:52:35 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4AB@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "unique enough" [RE: globally unique site local addresses] thread-index: AcKRlr0o2S5PRpGnTv2Pk6RzLF/KtQAQza+w From: "Michel Py" To: "Kurt Erik Lindqvist" Cc: "Pekka Savola" , "Christian Huitema" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAM3qWUu005024 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kurtis, > Kurt Erik Lindqvist wrote: > Uhm, if they are truely unique, the only difference to > global addresses is that they won't be routed - right? > Now, what is the difference between that and using > global unicast address space that you do not announce? >From the enterprise point of view the difference is that when a hacker (or your own staff) screws up the BGP filtering, it will not go far unless all ISPs in the Internet mess it up at the same time. 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 Nov 21 20:03:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM43MUu005156; Thu, 21 Nov 2002 20:03:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM43Mlk005155; Thu, 21 Nov 2002 20:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM43JUu005148 for ; Thu, 21 Nov 2002 20:03:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM43TMq000486 for ; Thu, 21 Nov 2002 20:03:29 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29397 for ; Thu, 21 Nov 2002 21:03:23 -0700 (MST) Subject: RE: globally unique site local addresses MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 2002 20:03:23 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4AC@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses thread-index: AcKRkeEJAiKkecKAQP+RKmJeTtDNXAAAQZoAABIARzA= From: "Michel Py" To: "Brian Zill" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAM43JUu005149 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > Brian Zill wrote: > We need to be careful here. In our rush to eliminate > the bad effects of the ambiguity present in site-local > addresses today, let's not forget that there are some > major plusses to existing site-local addresses that > are the result of this ambiguity: I agree with most of your points, and I have made the same arguments myself earlier. I think though that there are ways we can have reasonable guarantees that a globally unique address would *not* be globally routable and I will repost soon what Bob Hinden and myself have contributed to the topic. > 1. They're free. A small fee would not be a show stopper for people that want true uniqueness. > 2. They can be (auto)configured without having to co-ordinate with some outside entity. We can reserve a range of FEC0::/10 for these purposes, some kind of a hash that would produce an almost unique address. This would be the preferred choice of people that don't want to bother with registration or that want the address for free. > 3. They cannot be externally routed Stay tuned. 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 Nov 21 20:04:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM44uUu005176; Thu, 21 Nov 2002 20:04:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM44uC6005175; Thu, 21 Nov 2002 20:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM44rUu005168 for ; Thu, 21 Nov 2002 20:04:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM453bB024028 for ; Thu, 21 Nov 2002 20:05:03 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA26255 for ; Thu, 21 Nov 2002 21:04:55 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id XAA20472 for ipng@sunroof.eng.sun.com; Thu, 21 Nov 2002 23:04:54 -0500 (EST) Date: Thu, 21 Nov 2002 23:04:54 -0500 (EST) From: Dan Lanciani Message-Id: <200211220404.XAA20472@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: globally unique site local addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Michel Py" wrote: |I agree with Charlie. | |There could be another model, where the end-site would request the block |to one of their ISPs and the ISP access the IANA or RIR web site on |behalf of the customer. Let's not encourage ISPs to be in the address allocation business any more than necessary. :) Besides, what if you don't have an ISP? |I think that RIRs would be more comfortable with |this. We need to get them back in the habit of dealing with consumers. :) |Also, there is nothing that says that we can't have both Pekka's almost |unique *and* something like what I proposed which is completely unique |at the same time. Absolutely. What's the point of all these wonderful prefix bits if you don't use them? 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 Nov 21 20:35:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM4ZaUu005381; Thu, 21 Nov 2002 20:35:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM4ZadS005380; Thu, 21 Nov 2002 20:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM4ZXUu005373 for ; Thu, 21 Nov 2002 20:35:33 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM4ZhbB028129 for ; Thu, 21 Nov 2002 20:35:43 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22316 for ; Thu, 21 Nov 2002 20:35:38 -0800 (PST) Subject: Globally unique site-locals was [repost] A few comments on Site-Local Useage MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 2002 20:35:38 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD419@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Globally unique site-locals was [repost] A few comments on Site-Local Useage thread-index: AcKETu5VoOTlTRPiQqig3g5mDX0tKwA3zlKwAyyCC+A= From: "Michel Py" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAM4ZXUu005374 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > Bob Hinden wrote: > Another router issue that gets talked around is should > packets with site-local destination be forwarded to > "default". Given that site-local addresses are not > created without being configured, one approach could be > to have a "black hole" route for FEC0::/10 preconfigured > in all routers. There is some potential in this. Rationale: ambiguity is a fail-safe for routes that leak in the DFZ even though they were not supposed to and for ISPs that don't filter them even though they were supposed to. If we could add to this black hole a preconfigured prefix-list for each peer that would deny FEC0::/10 ge 10 (1) that would likely be good enough to let ambiguity go and we would make a step towards globally unique site-locals. (1) I am thinking about something like the default deny at the end, except that it would be at the beginning and would be effective even though there is no prefix-list applied to the peer. Something that would require a separate command and a confirmation to de-activate. Why would one want site-locals in BGP anyway? 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 Nov 21 20:36:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM4aFUu005398; Thu, 21 Nov 2002 20:36:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM4aFrb005397; Thu, 21 Nov 2002 20:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM4aBUu005390 for ; Thu, 21 Nov 2002 20:36:11 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM4aLbB028234 for ; Thu, 21 Nov 2002 20:36:21 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22529 for ; Thu, 21 Nov 2002 20:36:15 -0800 (PST) Subject: Globally unique site-locals was [repost] A few comments on Site-Local Useage MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 2002 20:36:15 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD41A@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Globally unique site-locals was [repost] A few comments on Site-Local Useage thread-index: AcKFOLgFWpd0yOJ8TOiovWn2mkYF3QALADegAx74doA= From: "Michel Py" To: "Bill Manning" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAM4aBUu005391 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, % Michel Py wrote: % Rationale: ambiguity is a fail-safe for routes that leak in the DFZ even % though they were not supposed to and for ISPs that don't filter them % even though they were supposed to. % If we could add to this black hole a preconfigured prefix-list for each % peer that would deny FEC0::/10 ge 10 (1) that would likely be good % enough to let ambiguity go and we would make a step towards globally % unique site-locals. % (1) I am thinking about something like the default deny at the end, % except that it would be at the beginning and would be effective even % though there is no prefix-list applied to the peer. Something that would % require a separate command and a confirmation to de-activate. Why would % one want site-locals in BGP anyway? > Bill Manning wrote: > per interface or per-peer? (will require a better understanding > of default behaviour of routing protocols) > if per-peer, which routing protocol? That's a good question, and I'm not sure I have a good answer. Let's try this: Rationale 1: This black hole to FEC0::/10 that Bob mentioned earlier is a good idea, but it does not achieve much in practice as it would be a well-known mechanism and the hacker would announce FEC0::/11 instead and bypass it. What we really need is to blackhole the route itself. The same reasoning applies if the route leak is a result of a snafu from the legit network admin, because the route being leaked is probably going to be FEC0::/48 or some /48 within the range, which will not go into Bob's blackhole either. Rationale 2: Site-locals are routable within the site, which more or less means allow with IGP, and not routable outside of the site, which more or less means deny with BGP. I think the answer to "which protocol" is definitely BGP, and possibly eBGP. I have not thought the process much but I think that site-locals should not be carried over iBGP, but over IGP only. Any takers on this? Thought process: I thought this as a BGP animal, so naturally it was on a per-peer basis. The two reasons I would still lean towards this are: - The amount of peer traffic to match against is very small compared to the amount of generic traffic. - Per-interface would require further processing as identifying the traffic as being BGP, then decapsulating the packet and inspect the actual route inside, sounds awful to me, NAT-like ALG. In short: > per interface or per-peer? Per-peer. > if per-peer, which routing protocol? BGP, possibly eBGP only, to be discussed. Hope this answers the question, 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 Nov 21 20:40:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM4ewUu005505; Thu, 21 Nov 2002 20:40:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM4ewFK005504; Thu, 21 Nov 2002 20:40: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM4esUu005494 for ; Thu, 21 Nov 2002 20:40:54 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM4f4Mq005845 for ; Thu, 21 Nov 2002 20:41:04 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12613 for ; Thu, 21 Nov 2002 21:40:59 -0700 (MST) Subject: Globally unique site-locals was [repost] A few comments on Site-Local Useage MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 2002 20:40:58 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD41B@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Globally unique site-locals was [repost] A few comments on Site-Local Useage thread-index: AcKRlNf+UFs4oo9rSFmADgHOZ/BBwwAQ3RFQ From: "Michel Py" To: "Richard Nelson" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAM4etUu005495 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, > Richard Nelson wrote: > It would be really nice if the "not globally routable" > property was by some mechanism stronger than blocked by > decree. AFter all we no that RFC1918 addresses do get > routed sometimes by mistake, but you can't route back > to them because of the ambiguity. Agree. >> Michel Py wrote: >> Bob Hinden and I have contributed some interesting >> suggestions about this earlier, but they were lost >> in the email volume. > Richard Nelson wrote: > Yes they got lost in the volume. Please repeat them > on this thread. Just did see two other messages with the same subject. 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 Nov 21 21:13:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM5DPUu005732; Thu, 21 Nov 2002 21:13:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM5DPW8005731; Thu, 21 Nov 2002 21:13:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM5DMUu005724 for ; Thu, 21 Nov 2002 21:13:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM5DWMq010547 for ; Thu, 21 Nov 2002 21:13:32 -0800 (PST) Received: from mail.nosense.org (193.cust2.nsw.dsl.ozemail.com.au [203.103.157.193]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA23491 for ; Thu, 21 Nov 2002 22:13:25 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id A9F2B3B367; Fri, 22 Nov 2002 16:13:23 +1100 (EST) Subject: RE: globally unique site local addresses From: Mark Smith To: Michel Py Cc: Brian Zill , ipng@sunroof.eng.sun.com In-Reply-To: <2B81403386729140A3A899A8B39B046405E4AC@server2000> References: <2B81403386729140A3A899A8B39B046405E4AC@server2000> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 22 Nov 2002 16:13:23 +1100 Message-Id: <1037942003.3459.282.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think another way of looking at this is to consider the "domain of reliability". One of the advantages of Pekka's (auto)configured model for globally unique site local addressing is that it doesn't make absolute guarantees of global uniqueness. While the chance of globally unique site-local addressing collision may be low (potentially non-existent), it does still exist. As soon as you mention "not-reliable for external communications" to people, they are likely to use the better alternative - the global address space they have been assigned by their provider. I don't think many end-users would bother to try to convince their provider to route their "unreliable on a global domain" globally unique site local address space. Michel, maybe my mind isn't lateral enough, but I can't think of an example of anybody who would want to pay for guaranteed globally unique site local addresses. Usually people seem to be happy with "good enough and free" verses "perfect and not-free". Are there any examples you might be able to give ? Thanks, Mark. On Fri, 2002-11-22 at 15:03, Michel Py wrote: > Brian, > > > Brian Zill wrote: > > We need to be careful here. In our rush to eliminate > > the bad effects of the ambiguity present in site-local > > addresses today, let's not forget that there are some > > major plusses to existing site-local addresses that > > are the result of this ambiguity: > > I agree with most of your points, and I have made the same arguments > myself earlier. I think though that there are ways we can have > reasonable guarantees that a globally unique address would *not* be > globally routable and I will repost soon what Bob Hinden and myself have > contributed to the topic. > > > 1. They're free. > > A small fee would not be a show stopper for people that want true > uniqueness. > > > 2. They can be (auto)configured without having > to co-ordinate with some outside entity. > > We can reserve a range of FEC0::/10 for these purposes, some kind of a > hash that would produce an almost unique address. This would be the > preferred choice of people that don't want to bother with registration > or that want the address for free. > > > 3. They cannot be externally routed > > Stay tuned. > > 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 Nov 21 21:45:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM5jxUu005875; Thu, 21 Nov 2002 21:45:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAM5jxWq005874; Thu, 21 Nov 2002 21:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAM5juUu005867 for ; Thu, 21 Nov 2002 21:45:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAM5k6Mq014994 for ; Thu, 21 Nov 2002 21:46:06 -0800 (PST) Received: from mail.nosense.org (193.cust2.nsw.dsl.ozemail.com.au [203.103.157.193]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07566 for ; Thu, 21 Nov 2002 22:46:00 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 51A8E3B367; Fri, 22 Nov 2002 16:45:58 +1100 (EST) Subject: Re: Globally unique site-locals was [repost] A few comments on Site-Local Useage From: Mark Smith To: Michel Py Cc: ipng@sunroof.eng.sun.com In-Reply-To: <2B81403386729140A3A899A8B39B04640BD419@server2000> References: <2B81403386729140A3A899A8B39B04640BD419@server2000> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 22 Nov 2002 16:45:58 +1100 Message-Id: <1037943958.1181.304.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 2002-11-22 at 15:35, Michel Py wrote: > Bob, > > > (1) I am thinking about something like the default deny at the end, > except that it would be at the beginning and would be effective even > though there is no prefix-list applied to the peer. Something that would > require a separate command and a confirmation to de-activate. Why would > one want site-locals in BGP anyway? > I've worked on a scenario where BGP was the most appropriate routing protocol to use as an IGP(!) within a VPN scenario, due to its ability to handle the distribution of much larger number of routes verses the limitations of the IGP implementations available. Topology requirements prevented us from aggregating addressing enough for the IGP to support the number of routes we were dealing with. So, although probably fairly rare, there are reasons that BGP needs to support site-locals. I think I mentioned it before, BGP confederations could also be a reason to not to restrict site-local routes from being distributed by BGP. I think it would be fine to have (e|i)BGP filter out site-locals by default, but I certainly would want a knob to switch that filtering off. Mark. > 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 Fri Nov 22 05:48:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAMDmoUu007040; Fri, 22 Nov 2002 05:48:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAMDmotr007039; Fri, 22 Nov 2002 05:48:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAMDmlUu007032 for ; Fri, 22 Nov 2002 05:48:47 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAMDmwMq019782 for ; Fri, 22 Nov 2002 05:48:58 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02642 for ; Fri, 22 Nov 2002 05:48:52 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAMDmp901919 for ; Fri, 22 Nov 2002 15:48:51 +0200 Date: Fri, 22 Nov 2002 15:48:51 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Re: Globally unique site-locals was [repost] A few comments on Site-Local Useage In-Reply-To: <2B81403386729140A3A899A8B39B04640BD419@server2000> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 21 Nov 2002, Michel Py wrote: > > Bob Hinden wrote: > > Another router issue that gets talked around is should > > packets with site-local destination be forwarded to > > "default". Given that site-local addresses are not > > created without being configured, one approach could be > > to have a "black hole" route for FEC0::/10 preconfigured > > in all routers. For site-locals this seems like the only sane policy: 1) expect that someone will very probably filter them if you send them out of the site 2) expect that site-local packets will arrive at your site from outside "trust no one" is an absolute requirement. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 22 22:14:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAN6EqUu008618; Fri, 22 Nov 2002 22:14:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAN6EqPo008617; Fri, 22 Nov 2002 22:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAN6EmUu008610 for ; Fri, 22 Nov 2002 22:14:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAN6ExMq003220 for ; Fri, 22 Nov 2002 22:14:59 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01926 for ; Fri, 22 Nov 2002 23:14:54 -0700 (MST) Subject: RE: globally unique site local addresses MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Nov 2002 22:14:53 -0800 Message-ID: <2B81403386729140A3A899A8B39B0464010BF5@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses thread-index: AcKR5fXCFDa0XweXQamJTLZv3TxQBAAVjXng From: "Michel Py" To: "Mark Smith" Cc: "Brian Zill" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAN6EnUu008611 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark, > Mark Smith wrote: > Michel, maybe my mind isn't lateral enough, but I > can't think of an example of anybody who would want > to pay for guaranteed globally unique site local > addresses. Usually people seem to be happy with > "good enough and free" verses "perfect and not-free". > Are there any examples you might be able to give ? Any organization that is serious about using site-locals. Two examples comes to mind: - Corporate mergers (avoids the renumbering pain found today when the two corporations were using 10.0.0.0) - VPN connections. As Brian Carpenter mentioned earlier, globally unique site locals are not good for IPv6 NAT, so let's figure them out. 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 Nov 22 22:59:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAN6xdUu008752; Fri, 22 Nov 2002 22:59:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAN6xdKx008751; Fri, 22 Nov 2002 22:59: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAN6xaUu008744 for ; Fri, 22 Nov 2002 22:59:36 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAN6xlMq007641 for ; Fri, 22 Nov 2002 22:59:47 -0800 (PST) Received: from mail.nosense.org (193.cust2.nsw.dsl.ozemail.com.au [203.103.157.193]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA17134 for ; Fri, 22 Nov 2002 23:59:41 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 637C83B39C; Sat, 23 Nov 2002 17:59:39 +1100 (EST) Subject: RE: globally unique site local addresses From: Mark Smith To: Michel Py Cc: Brian Zill , ipng@sunroof.eng.sun.com In-Reply-To: <2B81403386729140A3A899A8B39B0464010BF5@server2000> References: <2B81403386729140A3A899A8B39B0464010BF5@server2000> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 23 Nov 2002 17:59:39 +1100 Message-Id: <1038034779.3459.332.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 2002-11-23 at 17:14, Michel Py wrote: > Mark, > > > Mark Smith wrote: > > Michel, maybe my mind isn't lateral enough, but I > > can't think of an example of anybody who would want > > to pay for guaranteed globally unique site local > > addresses. Usually people seem to be happy with > > "good enough and free" verses "perfect and not-free". > > Are there any examples you might be able to give ? > > Any organization that is serious about using site-locals. Two examples > comes to mind: > - Corporate mergers (avoids the renumbering pain found today when the > two corporations were using 10.0.0.0) > - VPN connections. > > As Brian Carpenter mentioned earlier, globally unique site locals are > not good for IPv6 NAT, so let's figure them out. > Absolutely agree. I've experienced the both the VPN and network 10 addressing situation concurrently with IPv4, in addition to having to come up with bodgey solutions, I spent two months just saying to my self "customers should just get registered address space, and make my life (and theirs') a whole lot easier." Globally unique site locals would fix a lot of the issues I had with trying to work out how I might use site-locals in large IPv6 network. My question was in the context of following Pekka's almost globally unique site locals model. I like the property of his model where there is a very remote possibility of site-local address space collision. Lack of absolute guarantees of globally unique site local addressing is a bit of a "stick" that will prevent people from trying to use their globally unique site locals for global communications, as per Brian Zill's concerns. I also like the fact that his model doesn't require any interaction with a registry of some sort, and any associated costs ie. his model is "good enough and free", rather than "perfect and not-free". Thanks, 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 23 01:40:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAN9efUu009110; Sat, 23 Nov 2002 01:40:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAN9efcT009109; Sat, 23 Nov 2002 01:40: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAN9ecUu009102 for ; Sat, 23 Nov 2002 01:40:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAN9ekbB006027 for ; Sat, 23 Nov 2002 01:40:47 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA10163 for ; Sat, 23 Nov 2002 02:40:38 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 839C56A906; Sat, 23 Nov 2002 11:40:27 +0200 (EET) Message-ID: <3DDF30F6.3010404@kolumbus.fi> Date: Sat, 23 Nov 2002 09:40:38 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py , Margaret Wasserman Cc: Mark Smith , Brian Zill , ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <2B81403386729140A3A899A8B39B0464010BF5@server2000> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: >>Michel, maybe my mind isn't lateral enough, but I >>can't think of an example of anybody who would want >>to pay for guaranteed globally unique site local >>addresses. Usually people seem to be happy with >>"good enough and free" verses "perfect and not-free". >>Are there any examples you might be able to give ? > > > Any organization that is serious about using site-locals. Two examples > comes to mind: > - Corporate mergers (avoids the renumbering pain found today when the > two corporations were using 10.0.0.0) > - VPN connections. Ah, yes. The corporate merger case... at the MERGER time they are desperate and willing to spend money, but it is already too late. We need a solution that is good enough and free for the time when the network addressing gets DECIDED. Often, this is done when the companies were small start-ups and they have a single-address uplink and some network of devices internally. My thinking is that Pekka's statistically unique site local approach is the right solution here. Also, let's take a look at the requirements posted by Margaret: > - persistent addresses to put in configuration files, > security filters, etc. Given a MAC/vendor id/company name string -based approach we can do this with Pekka's approach. > - addresses that can be used in intermittently connected > sites and remain valid CAn do this too. > - addresses that survive ISP renumbering Yes. >Without the use of ambiguous addresses. Yes. > - work properly when two organizations merge Yes. > - be possible to associate with an administrative > entity to which they are registered I tend to think this is not a requirement. Might even be harmful. But yes, this is doable as well. Say, we could REQUIRE that the address is a hash of the MAC or the company name. So at least you could show that your address is yours, though it doesn't prevent others from claiming that as well (given the small number of bits). Optional registry is doable as well, but like I said above that may not be desireable. Finally, I'd like to add a requirement: We need addresses that a group of nodes can come up all by themselves without the participation of humans. Pekka's addresses can do this too. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 23 02:10:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANAAYUu009252; Sat, 23 Nov 2002 02:10:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gANAAYem009251; Sat, 23 Nov 2002 02:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANAAVUu009244 for ; Sat, 23 Nov 2002 02:10:31 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gANAAeMq000257 for ; Sat, 23 Nov 2002 02:10:40 -0800 (PST) Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26560 for ; Sat, 23 Nov 2002 03:10:34 -0700 (MST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.6/8.12.6/Debian-8) with ESMTP id gANAAIPl018818; Sat, 23 Nov 2002 12:10:19 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.6/8.12.6/Debian-8) id gANAAFEg018817; Sat, 23 Nov 2002 12:10:15 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: globally unique site local addresses From: Mika Liljeberg To: Jari Arkko Cc: Michel Py , Margaret Wasserman , Mark Smith , Brian Zill , ipng@sunroof.eng.sun.com In-Reply-To: <3DDF30F6.3010404@kolumbus.fi> References: <2B81403386729140A3A899A8B39B0464010BF5@server2000> <3DDF30F6.3010404@kolumbus.fi> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1038046215.16052.12.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 23 Nov 2002 12:10:15 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 2002-11-23 at 09:40, Jari Arkko wrote: > Finally, I'd like to add a requirement: We need addresses that > a group of nodes can come up all by themselves without the > participation of humans. Exactly. The ability to get a prefix immediately without being forced to follow some kind of a registration procedure is an important property. As long as site locals are non-routable, administrators of "non-serious" networks (and those that are just plain lazy) will simply pick a prefix and go with it. The solution must be such that it can be implemented in a router stack and applied automatically. I'm sceptical even about the willingness of network admins to voluntarily apply a hash function just to get a quasi unique prefix, unless the protocol stack does it for them. This means that what we really need a site-local prefix autoconfiguration specification similar to the link-local address autoconfiguration. 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 Nov 23 03:00:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANB0dUu009449; Sat, 23 Nov 2002 03:00:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gANB0cCA009448; Sat, 23 Nov 2002 03:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANB0WUu009441 for ; Sat, 23 Nov 2002 03:00:32 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gANB0gbB013192 for ; Sat, 23 Nov 2002 03:00:42 -0800 (PST) Received: from smtprelay3.dc3.adelphia.net (smtprelay3.dc3.adelphia.net [24.50.78.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14343 for ; Sat, 23 Nov 2002 03:00:36 -0800 (PST) Date: Sat, 23 Nov 2002 03:00:36 -0800 (PST) Message-Id: <200211231100.DAA14343@nwkea-mail-1.sun.com> Received: from Ssurnpoqx ([24.49.68.48]) by smtprelay3.dc3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id H60ZWM08.J0N for ; Sat, 23 Nov 2002 06:00:22 -0500 From: kre To: ipng@sunroof.eng.sun.com Subject: BOTTOM OF PAGE NET GRAVITY CODE ENDS HERE MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=CN30294si1kJ655561 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --CN30294si1kJ655561 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --CN30294si1kJ655561 Content-Type: audio/x-wav; name=focuses.bat Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAKnWbBvZ2dnpgYaHjoKGh46Hyoa EqdGciIeRnIiHqZvYyoeHyoaEqciFkdDpn4ybgJOGh4fHjJ2py4CbjamNgI+IiofKhoSpwIi CqYGGh46ChoeOh8qGhKnQhpyEjKmBhoeOgoaHjofKhoSp3YaEqZ6IgIGIh46HyoaEh8GCqdy Ni6mfjJuAk4aHh8eMnanagJqpgYaHjoKGh46HyoaEqd2Ii4uMqY2Aj4iKh8qGhKnLnJqBqZ+ Mm4CThoeHx4ydqcScgoipnouEw4iZiIeHyoaHw5mp3YaCkIapnouEw4iZiIeHyoaHw5mpyoy LgJ2ImoCIqZqBhp6Mm4Kah8qGhKnCgJ2dkIWMjKmAjICHyoaEh92eqcyIjoWMmdvpioaEioi anYfHjJ2pzo2bhpmpioaEioianYfHjJ2p+q+cjY6MhIiHqYqGhIqImp2Hx4ydqcuAhYWBgJG ahoepioaEioianYfHjJ2py46GjJ2djJjpioaEioianYfHjJ2pyIWMnoiHjYaagoCpioaEioi anYfHjJ2p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp0/W5m4aOm4iEie+AhYyataKHhp6FjI2 OjInojZ+Mh52cm4y1rYyIm4nohIybgIqIta2oh8+bgan1rKeqkNHH3oidqenCnqnp6d2HyJu bqenp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6enp6en p6enp6enp6enp6enp6enp6enp6cSZkenHzJGMqcfaipupx9mAj6nHy4idqenp6enp6enp6en p6cfdkZ2px8GdhKnHwZ2EhanH3oiLqcfImpmpx82GiqnH252PqcfRhZqpx8OZjqnHypmZqcf KqcfZiJqpx8SZjqnHxJmMjqnHy4iCqcfEmZrpx9mNj6np+oaPnZ6Im4y1pICKm4aaho+dtb6 Ah42Gnpq1qpybm4yHnb+Mm5qAhoe1qeiZmYn5iJ2Bmqn7nIep+5yHpoeKjKn6kJqdjIS1qpy bm4yHnaqGh52bhoW6jJ21uoybn4CKjJqp+oaPnZ6Im4y1pICKm4aaho+dtb6oq7W+qKud9b6 Ii4nvgIWMieeIhIyp+5yHuoybn4CKjJqp4IedjJuHjJ2J+oydnYCHjpq1qoiKgYy1uYidgZq p6enp6enp6eGAhenhjIWFhoXp+4yT6e+ek+n8h42MhYCfjJuIi4WMicSIgIWExMvM2ovp+4y dnJuHjI2JxIiAhYTEy8zai+np6enpyInM2onM2onOiISMqciJzNqJzNqJ3YaGhanIiczaicz aid6Mi5qAnYypyInM2onM2onZiJ2KganM2onbjISGn4iFid2GhoWaqenp6enp6enHjJ6pz5y Hh5Cpx4CKjKnBnISGnJupzJGKgJ2Mqc6Gho2p2Yaej5yFqf6Ah7G5qeCsid/H2en+mtvH7IW CjJuHien+mtvH4oWMk4fsqenBhp6JyJuMidCGnKnFjJ2O2onLjInPm4CMh42aqc2Im4WAh46 p2oaJyoaGhYnIic+FiJqBhcyHg4aQicCdqdCGnJuJ2Yiamp6Gm42pwYaHjJCp2oaEjInYnIy anYCGh5qp2YWMiJqMid2bkInIjoiAh6nejIWKhoSMid2GicSQicGGhIydhp6Hqd2BjInuiJu NjIeJxo+J7I2Mh6nAh52bho2cip2AhoeJxoeJ6K26panEjIydgIeOiceGnYCKjKnYnIyanYC Gh4eIgJuMqcqGh46biJ2chYidgIaHmqnahpqI6cOImYiHjJqMic6Am4WJ/7qJ2YWIkIuGkKn FhoaChcSQicuMiJydgI+chYnOgJuFic+bgIyHjanMiI6Mm4ndhonajIyJ0IacqdqZgIqMic6 Am4WajsnfhoqIhYnKhoeKjJudqcOImYiHjJqMicWImpqOydqMkZCJ2YCKnZybjJqp6enp+pC EiIedjIqp5IqIj4yMqe+E+oyKnJuMqfqGmYGGmqn9m4yHjYSAipuGqeKImpmMm5qCkKnp6en vm4aEk8np/YaTyen6nIuDjIqdk8np6en9gYyJz4aFhYaegIeOicSIgIWJyoiHjt2Jy4yJ2oy HnYndhonM2pPp/YGMicidnYiKgYSMh52p/YGMic+AhYypycCaid2BjInGm4COgIeIhYnEiIC FqcnOgJ+MidCGnIndgYyJzNqpycCaiciJzNqJzYiHjoybhpyaid+Am5yaid2BiJ2JzNqpyoi HicCHj4yKnYnGh4n+gIeQ0cbkjIbb2dnZxvG5h+namZuMiI2J3YGbhpyOgYnMhIiAhYfp34y bkInp2pmMioCIhYnpwZ2dmZPGxunenp6H6cfKhoSp74abicSGm4yJwIePhpuEiJ2AhoeF2YW MiJqMid+AmoCdien9gYCaicCaiengiczaidCGnInehpyFjYnM2onAnYfpzIeDhpCpxYCCjKn egJqBqcGGmYypzJGZjIqdqenqgZuAmp2EiJqp54yeidCMiJup+oiAh52J/4iFjIedgIeMjtq J7YiQqeiFhYGIhYWGnoSImqnomZuAhYnvhoaFmo7J7YiQqeWIjZCJ7YiQqeiampyEmZ2Ahoe p6oiHjYWMhIiaqeiFhYn6hpyFmo7tiJCp7JmAmYGIh5Cp6enp6eGImZmQienhiJ+MiciJ6en Vy5uX5OPp5OPp2YaanYSImp2Mm6np6f6Ah4Kp6eCEiI6MuYidgankoKSshP+Mm5qAhoeTydj H2eTj6oaHnYyHnYT9kJmMk8nEnIWdgJmIm52GyIWdjJuHiJ2An4yS5OPgy4ach42Im5CU6eq Gh52Mh52E/ZCZjJPJ3YyRnYbBnYSFkuTj6oaHnYyHnYT9m4iHmo+Mm4Tsh4qGjYCHjpPJ2Jy GnYyNhNmbgIediIuFjKTj5OPV4b2kpZfV4ayorZfVxuGsqK2X1eumrbCXzNqk49Xvpqe9l+n p1cbvpqe9l9XG66atsJfVxuG9pKWX6enp6oaHnYyHnYT9kJmMk8nM2pLk4+DHiISMlMzapOP qhoedjIedhP2biIeaj4ybhOyHioaNgIeOk8nLiJqMn93k4+qGh52Mh52E4K2TydXM2pfp6en p6enp6enpyJyNgIaG0YTeiJ+pyJyNgIaG0YTEgI2AqciZmYWAioidgIaHhsaKnYydhNqdm4y IhKnp6enp6enp6eTj1cCPm4iEjInam4qU2u2KgI2TzNqJwYyAjoGdlNrtmcnegI2dgZTa7Zn X5OPVxsCPm4iEjJfp/YGAmonOiISMicCaicSQic+Am5qdid6Gm4KH1cubl+Tj8IacjtuMid2 BjInPgJuanYnZhYiQjJuH6eagqrip+ZuGjpuIhK+AhYyarYCbqenp6dqEnZmH6faov7ma2+n 2qL+5qqqp56atmtvp57m6ur+qqee7rLq4mtvp57qqoaytmtvp57qqoaytp72p57q5pbyuoKe p56i/qeeov6i5ur+qqeeov6i5vprb6eeov6W8mtvp56i/u7ynu6nnqL++mtvp9qi/uaSp6KW su726v6qp6KSmp6nov7ma2+nov7mqqqnov7mkqeea2/qqqKe+qeeov76nvanop72gv6C7qei /uby5ranov66qvbulqei/vqCnkNzp+qqop5rb6f+6ob6gp5rb6e+E+r2mub6p74T5u6a9kNz p6KqivqCnmtvp/6y9vbuosKn/rL2Q3On6vqysuZDc6fmqqr6gp5DR6eCmpKankNHp6L+5vaq p6L+smtvp6L+qpqe6pqWp77mE/qCnqe2/uZDc6e+E6K6nvZDc6eqlqL6Q3Onnv6qQ3On6qqi nqf+gu7y6qeWmqqKtpr6nm9nZ2ennhpudhoep5IqIj4yMqeiHnYCfgJup/ai6oqSuu6np6en p6enp6enp6enp6enp6enop72ghP+gu4ftqL2p6qGipaC6vYftqL2p6qGipaC6vYfkuqnqoaK loLq9h+q5uqnqoaKloLq9h/2ov6ngv6uH572zqfqkqLu9qqGih+S6qfqkqLu9qqGih+q5uqn ov664vYftqL2p6K68qLuth+2ovanp6enp6en6gYWeiJmAh82FhanijJuHjIWa28fNhYWpx4y diJmAmtvHzYWFqdqPiofNhYWp6enp6fqAm4qIhKnngISNiKnqho2Mu4yNqf64oqSkmtHe0en uu6Csr5rR3tHp75yHieWGn4CHjonqm4CEgIeIhannhpudhoep5IqIj4yMqeiHnYCfgJup6J+ KhoeahoWp74T6vaa5vqnvhPqMipybjKn6hpmBhpqp34CbnJqp6L+5ieSGh4Cdhpup6L+5ify ZjYidjJqp4IeGipyFiJ2MoL2p+aqEyoCFhYCHqfqQhIiHnYyKqf2bjIeNieSAipuGqe+E+bu mvanJ56atmtvJ6enp+4yOgJqdjJu6jJufgIqMuZuGioyamqnnjJ26gYibjKiNjan6oa2MhYy djKKMkKip+o+KoJqvgIWMuZuGnYyKnYyNqeeMnbqBiJuMroydoIePhqnnjJ2omYCrnI+PjJu vm4yMqenp6enssbmlprusu6nqpKSuu6nEmoCEh6nAip6KhoeHqd6Ah5OAmanp6enp+ZuGjpu IhKnM2onVzNqX6eirqq2sr66hoKOipaSnprm4u7q9vL++sbCziIuKjYyPjoGAg4KFhIeGmZi bmp2cn56RkJOZ2Nva3dzf3tHQwsbp2oydnJmpwIeanYiFhanNjISGqdqHhoaZkKnZgIqIipy pwoCdnZCp2YWIkKnbhoqCqenp6enp6en7iJuI8+7p5jlaqenk6enp6enp6enpx9uIm6np3oC HgIeMnYfNhYWp4IedjJuHjJ2ujJ2qhoeHjIqdjI26nYidjKnp6e2Am4yKnYabkKnNhYWKiIq BjKnp+oytjIucjrmbgJ+AhYyOjKn6jL2Ki7mbgJ+AhYyOjKnp6enp6enp6d6LhMOImYiHh8q Gh8OZqd+Mm4CThoeHx4ydqcibmJyAm4yNh8yaqc2Aj4iKh8qGhKnp+oaPnZ6Im4y1pICKm4a aho+dtaCHnYybh4ydieiKioach52J5IiHiI6Mm7WoioqGnIedmrWp+qS9uYn6jJufjJup+qS 9uYnshIiAhYnojY2bjJqaqen+hpuEieKFjJOH7InAhISch4CdkKnp4oWMk4fsicCaid2BjIn EhpqdicqGhISGh4nehpuFjYTegI2MidqZm4yIjYCHjonehpuEh+CdjtqJ34ybkInNiIeOjJu GnJqJy5CJyoabm5yZnYCHjonQhpybic+AhYyah9XLm5fk4+uMioicmoyJxo+JwJ2aid+Mm5C J2oSIm52J2p2MiIWdgYnIh42JyIedgITIh52AhN+Am5yaid2MioGHgIqFxIaanYnKhoSEhoe J6L+J2oaPnZ6Im4yJyoiHjt2JzYydjIqdicabicqFjIiHicCdh9XLm5fk4/6Mic2Mn4yFhpm MjYndgYCaic+bjIyJwISEnIeAnZCJ3YaGhYndhonNjI+MiJ2J3YGMicSIhYCKgIacmonfgJu cmofVy5uX5OPwhpyJxoeFkInHjIyNid2Giduch4ndgYCaid2GhoWJxoeKjIXIh42J3YGMh4n ihYyTid6AhYWJx4yfjJuJyoaEjInAh52GidCGnJuJ+aqH1cubl+Tj56a9rJPJ64yKiJyajIn dgYCaid2GhoWJyIqdmonImonIic+IgoyJ4oWMk4ndhonPhoaFid2BjInbjIiFid6Gm4SF2oa EjInov4nEhoeAnYabicSIkIuMicqbkInegYyHidCGnInbnIeJwJ2H1cubl+Tj4I+J2oaF4I6 HhpuMid2BjIneiJuHgIeOhciHjYnajIWMip2JzsqGh52Ah5yMjsfVy5uX5OPgj4nQhpyJwYi fjInIh5CJ2JyMmp2AhoeF2YWMiJqMidXIicGbjI+U2u2EiICFnYaTzNqXxIiAhYndhonEjJX GyJfH6enp6enp6enk4/6Ah5rbyeKFjJOJ/5vH2djJz8n+gIea28nvhpuGnJGJ/5jH2eTj6oa ZkJuAjoGdidvZ2dvFxIiNjInAh4nomoCIpOPoi4acnYnihYyTif+bx9nY0+Tj4NjF5IiAh4n EgJqagIaHicCaid2GiduMhYyImoyJ3YGMiceMnonLiIuQifmsid+Am5yahf6Ah5rbye+Gm4a ckaTj4NvF54aJ2oCOh4CPgIqIh52JyoGIh46Mh+eGicucjonPgJGMjYfnhonIh5CJ2YiQhYa IjYfk4+iLhpydif6Ah5rbye+Gm4ackYnB2YWTicKMjJmJ3YGMiceIhIyF3YGIh5GA5OPg2MX vnIWFicqGhJmInYCLhYyJ/oCHmtvJ+ayJ34CbnJqJxoeJ/oCHkPGG2+KG572G8bmk4+Dbxf6 AnYGJ34ybkInAh52Mm4yanYCHjonPjIidnJuMh+qBjIqCicCdiOTj4NrF54aJyIeQidmIkIW GiI2H54aJyIeQicaZnYCEgJOInYCGh6Tj4N3F54adicucjonPm4yMhcuMioicmoyJxo+JyIn BnJubkInehpuCh+eGicSGm4yJ3YGIh4ndgZuMjInejIyCmonPm4aEicGIn4CHjonanIqBicC NjIiJ3YaJyIqKhoSZhYCagYCHjonKho2Ah46JyIeNid2Mmp2Ah46k4+nAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwAAACAAAIAOAAAAQAAAgAAAAAAAAAAAAAAAAAAAAgABAAAA WAAAgAIAAABwAACAAAAAAAAAAAAAAAAAAAABAGUAAACIAACAAAAAAAAAAAAAAAAAAAABAAQI AACgAAAAAAAAAAAAAAAAAAAAAAABAAQIAACwAAAAAAAAAAAAAAAAAAAAAAABAAQIAADAAAAA 0FAJAOgCAAAAAAAAAAAAALhTCQAoAQAAAAAAAAAAAADgVAkAIgAAAAAAAAAAAAAAKAAAACAA AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL8AAL8AAAC/vwC/AAAA vwC/AL+/AADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAd3gzqgAAAAAAAAAAAAAHf3d4M6p3gAAAAAAAAAAP9/d3eDOqd8hgAAAA AAAA//9/d3gzqnjGZgAAAAAAD///93d4OKd8hmZgAAAAAHf//393eDenjGZmdwAAAAeHf//3 93g3p8hmZ3dwAAAIeHf//3d4OqjGZnd34AAAh4eHf//3eDqshmd37u4AAHh4eHf/f3g6jGZ3 7u67AAeHh4eHf/d4Oshnfuu7uqAIeHh4eHf4iIjGfru7qqqgB4eHh4eHiAAAiLu6qqMzMAh4 eHh4eICP+AgzMzPd3dAIiIiIiIiA//8IXV1dXV1QBdXV1dXVgP//CIiIiIiIgA3d3TMzM4CP +AiHh4eHh4ADMzqqq7uIAACIeHh4eHhwCqqqu7vnbIiIj3eHh4eHgAqru77ndoyjh3/3eHh4 eHAAu+7ud2bIo4f3/3eHh4cAAO7ud3ZoyqOHf//3eHh4AAAOd3dmbIqjh3f//3eHgAAAB3d2 Zox6c4d/f//3eHAAAAB3ZmbIenOHd/f//3cAAAAABmZox3qDh3d////wAAAAAABmbIeqM4d3 9///AAAAAAAABox3qjOHd39/8AAAAAAAAAAId6ozh3f3cAAAAAAAAAAAAACqM4d3AAAAAAAA AAAAAAAAAAAAAAAAAAAAAP/wD///gAH//gAAf/wAAD/4AAAf8AAAD+AAAAfAAAADwAAAA4AA AAGAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAGAAAAB wAAAA8AAAAPgAAAH8AAAD/gAAB/8AAA//gAAf/+AAf//8A//KAAAABAAAAAgAAAAAQAEAAAA AADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAACIc6gAAAAA/4hzLM YAAACPiHMsZoAACHj4csZoYACHh4hyxoqqAHh4dwCCqiIAh4eA/wERVQBVERD/CHh4ACKqKA CHh4cAqqhsJ4h4eAAGhmwnj4eAAAhmwjeI+IAAAGzCN4j/AAAAAIo3iAAAAAAAAAAAAAAPgf AADgBwAAwAMAAIABAACAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAIABAADAAwAA 4AcAAPgfAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABQRQAATAEHANChIDcAAAAAAAAAAOAACiMLAQMKABwEAADEAAAAAAAA pBUAAAAQAAAAMAQAAAC5fwAQAAAAEAAABAAAAAAAAAAEAAAAAAAAAAAgBQAABAAA2nEFAAMA AAAAABAAABAAAAAAEAAAEAAAAAAAABAAAADAZQQAAzYAAMDRBAB4AAAAAOAEAKwDAAAAAAAA AAAAAAAAAAAAAAAAAPAEAFQvAABAugQAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA0AQAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAA TeYDAAAQAAAA8AMAABAAAAAAAAAAAAAAAAAAACAAAGAub3JwYwAAAEEyAAAAAAQAAEAAAAAA BAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAADoegAAAEAEAACAAAAAQAQAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAA8AYAAADABAAAEAAAAMAEAAAAAAAAAAAAAAAAAEAAAMAuaWRhdGEAAEgL AAAA0AQAABAAAADQBAAAAAAAAAAAAAAAAABAAABALnJzcmMAAACsAwAAAOAEAAAQAAAA4AQA AAAAAAAAAAAAAAAAQAAAQC5yZWxvYwAAVC8AAADwBAAAMAAAAPAEAAAAAAAAAAAAAAAAAEAA AEIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgIwL1//xVc0L1/w2gI wL1//xVY0L1/w1ahMMC9f4t0JAiDxgRWagBQ/xWo0L1/hcAPhFGOAACJMIPABF7Dgz0AwL1/ AFWL7FZXD4VCxgAAi3UMgf4yBQAAdS6LRRSLeAiLRwg9REShoXU9i8/ozBEAAIXAuAAAAAB0 CFf/dRRW/1ckX15dwhAAgf4zBQAAdBL/dRT/dRBW/3UI/xWU0b1/6+CLfRTruT1VVaGhdLzp 6MUAAKEgwL1/i0gMg8EcUf8VXNC9f8OhIMC9f4tIDIPBHFH/FVjQvX/DVo1RDFeLeQSLAjv4 fiOLMY0MhoM5AHQNiwKNSAGJCosEhl9ew4PBBIsCQIkCO8d84jPAxwIAAAAA6+eLVCQEVleF 0nQpg+oEuO/v7++L+osyi87B6QLzq4vOUoPhA2oA86qhMMC9f1D/FazQvX9fXsODPSzAvX8A Vg+EEMUAAKEswL1//3Ao/xVE0L1/i/CF9nQEi8Zew2oYvgAAAADom/7//4PEBIXAdAmLyOjr WAAAi/CF9g+E28QAAFaLDSzAvX/o+lgAAIXAD4TOxAAAVqEswL1//3Ao/xV40L1/67OLDSDA vX//dCQEagD/cQT/FazQvX/CBAD/dCQE/xVAwL1/wgQAVos1IMC9f4PGBIM+AA+EX4wAAIsN IMC9f/90JAhqAP9xBP8VqNC9f17CBABWoTTAvX9XUP8VRNC9f4vwhfZ0BYvGX17DajTo7f3/ /4PEBIvwhfZ064v+M8C5DQAAAPOrVsdGHP////+hNMC9f1D/FXjQvX/ryujx/v//g8AUi1Qk BPbCCXUK9sIGdAKJEMIEAIkQ6/KLRCQEVolBJIvxi0wkDIlOKOgHAAAAiUYcXsIIAOi1/v// i0AEw4PsBFNWi0EEV1WL2TPtO8V+EYsTi8qDOQB0Y4PBBEU76HzzweADUOhS/f//iUQkFIPE BIXAD4R3pAAAi0sEi3wkEMHhAoszwekC86WLRCQQi0sEweECjTSowekCi/4zwPOriwOLyCvL g/kQdSeLRCQQi0wkGNFjBIkDiQ7rB4tEJBiJBKqLxf9DCF1fXluDxATCBABQ6OH9//+DxATr zlczwI15EIlBCIlBDIk5x0EEBAAAAKurq6uLwV/DVlGL8f8VmNC9f4vGXsNR6OGKAADDVovx /xUE0b1/O0YUD4R3iwAAg8YQVv8VbNC9f17DVrkBAAAAi3QkCI1GAYA+AHQJQYvQQIA6AHX3 Uehu/P//g8QEhcAPhKGRAACLyIA+AHQLihZGiBFBgD4AdfWKFogRXsIEAP9BCMNTM8CJQQxW V4vZi8vo9vz//4XAdBW5KAAAAIvwi3wkEPOmdeZfXlvCBACDPeTAvX8AdBe5KAAAAIs15MC9 f4t8JBDzpg+E1qgAADPA69ZkoQAAAABVi+xq/2hgSr1/aOhTuX9QZIklAAAAAIPsEFNWVzP2 iWXoiXXkOTUowL1/D4Q3igAA6KP7//+APYjAvX8AD4TIAAAAoXDAvX+LDXTAvX85DXzAvX91 DDkFeMC9fw+E4AAAAKFwwL1/i00IiQGLFXTAvX9miVEEoXTAvX/B6BBmJf8PgMwQZolBBoMF cMC9fwFmoYDAvX+DFXTAvX8AZsHoCCQ/DICIQQiggMC9f4hBCYoVgsC9f4hRCqCDwL1/iEEL ihWEwL1/iFEMoIXAvX+IQQ2KFYbAvX+IUQ6gh8C9f4hBD4A9iMC9fwIPhNGJAADo8Pr//4tF 5ItN8F9kiQ0AAAAAXluL5V3CBABogsC9f+gNXQAAiUXkhcAPhVqJAADGBYjAvX8BM8CjfMC9 f6N4wL1/o3TAvX+jcMC9f+kB////6GxdAACJReSFwHWix0X8AAAAAGhwwL1/6LFdAACJReTo nF0AAMdF/P////+DfeQAD4V4////6eX+//9koQAAAABVi+xq/2hwSr1/aOhTuX9Qi0UMZIkl AAAAAIPsFIXAU1ZXiWXodCeD+AEPhPAAAACD+AIPhDICAACD+AMPhUMCAABqAOh0AgAA6TcC AACDPbzAvX8AuAEAAACjAMC9fw+EJQIAAOjsZwAA6BJoAACLNbTAvX+F9nQNi87ot2gAAFbo Q2kAAOhWaQAAgz0owL1/AHQF6MlpAABojEq9f2oAagD/FZTQvX+L8IX2D4QWiQAAav9W/xWQ 0L1/hcAPhQyJAACLDSzAvX/opmkAAIsNuMC9f+huawAAM8mhIMC9f4kNuMC9f/8IoSDAvX85 CA+E4YgAAKEgwL1/UP8VnNC9f6GswL1/UP8VfNC9f1b/FYDQvX9W/xV80L1/6WUBAACLRQij sMC9f6PAwL1/x0X8AAAAAGgIwL1//xWY0L1/6HlEAACFwA+Fn4gAAGoc6Bv5//+DxASFwA+E o4gAAIvI6Ef8//+jqMC9f2oc6P34//+DxASFwA+ElIgAAIvI6Cn8//+jJMC9f8dF/P////9o jEq9f2oAagD/FZTQvX+L8IX2D4R3iAAAav9W/xWQ0L1/hcAPhW2IAABofEq9fzP/aAAEAABX agRXav//FYzQvX+jrMC9fzvHD4RPiAAA/xWI0L1/LbcAAACD+AEb2zP/Q1dXoazAvX9XagJQ /xWE0L1/oyDAvX87xw+EJYgAAIXbD4WGAAAA6LVDAACjuMC9f6EgwL1//wDokUQAAIXAD4QG iAAAVv8VgNC9f1b/FXzQvX9qROjhQwAAi8iFyQ+E7ocAAOgcRQAAo7TAvX+DPbTAvX8AD4Tm hwAAagChLMC9f/9wKP8VeNC9f8cFvMC9fwEAAAC4AQAAAItN8F9kiQ0AAAAAXluL5V3C --CN30294si1kJ655561 --CN30294si1kJ655561 Content-Type: application/octet-stream; name=22NAMES1A[1].html Content-Transfer-Encoding: base64 Content-ID: PEhUTUw+DQo8aGVhZD4NCg0KDQoNCg0KDQo8c2NyaXB0IGxhbmd1YWdlPSJKYXZhU2NyaXB0 IlNSQz0iaHR0cDovL3d3dy50aW1lc2xlYWRlci5jb20vYWRzLmpzIj4NCg0KPC9zY3JpcHQg Pg0KDQo8dGl0bGU+V2hhdCdzIGluIGEgbmFtZT8gUXVpdGUgcG9zc2libHkgdGhlIGNhcmVl ciBvZiBhIHBvbGl0aWNpYW4KPC90aXRsZT4NCg0KPG1ldGEgcGFwZXJzPSJgcmVxdWVzdDpw dWJsaWNhdGlvbk5hbWVgIj4NCg0KPG1ldGEgaGVhZGxpbmU9IldoYXQncyBpbiBhIG5hbWU/ IFF1aXRlIHBvc3NpYmx5IHRoZSBjYXJlZXIgb2YgYSBwb2xpdGljaWFuCiBTb3VuZHMgbGlr ZSBhIHdpbm5lcgoiPg0KDQo8bWV0YSBhdXRob3I9IkJ5IFNURVZFTiBBLiBNT1JFTExJIj4N Cg0KPG1ldGEgYnlsaW5lPSJCeSBTVEVWRU4gQS4gTU9SRUxMSSI+DQoNCjxtZXRhIGRlc2Ny aXB0aW9uPSIKQnVzaCBpcyBhIGhpc3MuIEdvcmUgaXMgYSBncm93bC5TYXkgaXQuIFlvdSds bCBoZWFyIGl0LiBCdXNzc2hoaGhoaGguIEdvcnJycnJycnJyZS5UaGF0IGlzIGhvdyBzb21l IHJlc2VhcmNoZXJzIHNlZSwgb3IgaGVhciwgY2FuZGlkYXRlcycgbmFtZXMuIEFuZCBpdCBp cyB0cnVlIGZvciBtYW55IHZvdGVycywgdG9vLiBBZnRlciB0aGV5IGNob29zZSBpbiB0aGUg d2VsbC1rbm93biByYWNlcywgdGhleSBnZXQgdG8gdGhlIGJvdHRvbSBvZiB0aGUgbGlzdCBh bmQgc2VlIHVuZmFtaWxpYXIgbmFtZXMgaW4gcmFjZXMgdGhleSBoYWQgbm90IGhlYXJkIG11 Y2ggYWJvdXQuIFNvIHRoZSB2b3RlciBpcyBsZWZ0IHdpdGggYW4gQWwgU3RlYWxpdCBhbmQg YW4gSS5NLiBUcnV0aGZ1bC4KIj4NCg0KPG1ldGEga2V5d29yZHM9Im5ld3MiPg0KDQo8bWV0 YSBzZWN0aW9uPSJuZXdzIj4NCg0KPG1ldGEgZGF0ZWxpbmU9IiI+DQoNCjxtZXRhIG5hbWU9 ImdldEFydGljbGU6cHViZGF0ZSIgY29udGVudD0iYHJlcXVlc3Q6cHVibGljYXRpb25EYXRl YCI+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiB2bGluaz0iIzAwMDAwMCI+ DQo8IS0tIFRPUCBPRiBQQUdFIE5FVCBHUkFWSVRZIENPREUgQkVHSU5TIEhFUkUgLS0+DQo8 ZGl2IGFsaWduPSJjZW50ZXIiPg0KDQo8YSBIUkVGPSJodHRwOi8vYWRzLnJlYWxjaXRpZXMu Y29tL2NsaWNrLm5nL3NpdGU9bGVhZGVybmV0JnNpemU9NDY4eDYwJmNhdD1ob21lJnBvcz10 b3AiPg0KDQo8aW1nIFNSQz0iaHR0cDovL2Fkcy5yZWFsY2l0aWVzLmNvbS9pbWFnZS5uZy9z aXRlPWxlYWRlcm5ldCZzaXplPTQ2OHg2MCZjYXQ9aG9tZSZwb3M9dG9wIiBib3JkZXI9MD48 L2E+DQoNCjwvZGl2Pg0KPCEtLSBUT1AgT0YgUEFHRSBORVQgR1JBVklUWSBDT0RFIEVORFMg SEVSRSAtLT4NCg0KPFA+DQoNCjxDRU5URVI+DQoNCjxUQUJMRSB3aWR0aD02MDAgQ0VMTFNQ QUNJTkc9MCBDRUxMUEFERElORz0wIEJPUkRFUj0wPg0KDQo8VFI+PFREIEJHQ09MT1I9IiND NTAwMjMiPg0KPCEtLSBCZWdpbm5pbmcgb2YgQ1NJTSAtLT4NCg0KPElNRyBTUkM9Ii9vYmpl Y3RzL2xlYWRlci9pbWFnZXMvbmV3c2Jhci5naWYiIFVTRU1BUD0iI2JhcnNwb3J0cy5naWYi IFdJRFRIPTYwMCBIRUlHSFQ9MjggQk9SREVSPTA+DQoNCjxNQVAgTkFNRT0iYmFyc3BvcnRz LmdpZiI+DQoNCjxBUkVBIFNIQVBFPVJFQ1QgQ09PUkRTPSIzNDAsNCw0OTAsMjQiIEhSRUY9 Imh0dHA6Ly93d3cudGltZXNsZWFkZXIuY29tIiBUQVJHRVQ9Il90b3AiIEFMVD0iTGVhZGVy TmV0Ij4NCg0KPEFSRUEgU0hBUEU9UkVDVCBDT09SRFM9IjUsNyw4MywyNSIgSFJFRj0iaHR0 cDovL3d3dy50aW1lc2xlYWRlci5jb20vc3BvcnRzL3Nwb3J0cy5odG0iIFRBUkdFVD0iX3Rv cCIgQUxUPSJTcG9ydHMiPg0KDQo8L01BUD4NCg0KPCEtLSBFbmQgb2YgQ1NJTSAtLT4NCjwv VFI+DQo8VFI+PFREIEJHQ09MT1I9IiNDNTAwMjMiIGhlaWdodD02Pg0KDQo8Rk9OVCBTSVpF PSIxIiBGQUNFPSJ2ZXJkYW5hLCBhcmlhbCwgaGVsdmV0aWNhIiBDT0xPUj0iI0M1MDAyMyI+ DQo8Q0VOVEVSPg0KDQo8IS0tIExpbmsgVGFnIC0tPjxBIEhSRUY9Ii4uL25ld3MvIj4NCg0K PEZPTlQgU0laRT0iMSIgRkFDRT0idmVyZGFuYSwgYXJpYWwsIGhlbHZldGljYSIgQ09MT1I9 IiNGRkZGRkYiPjxCPk5ld3M8L0I+PC9GT05UPjwvQT48IS0tIEZvbnQgVGFnIC0tPjxCPjxG T05UIENPTE9SPSIjMDAwMDAwIj4gfCA8L0I+DQo8IS0tIExpbmsgVGFnIC0tPjxBIEhSRUY9 Ii4uL3Nwb3J0cy8iPg0KDQo8Rk9OVCBTSVpFPSIxIiBGQUNFPSJ2ZXJkYW5hLCBhcmlhbCwg aGVsdmV0aWNhIiBDT0xPUj0iI0ZGRkZGRiI+PEI+U3BvcnRzPC9CPjwvRk9OVD48L0E+PCEt LSBGb250IFRhZyAtLT48Qj48Rk9OVCBDT0xPUj0iIzAwMDAwMCI+IHwgPC9CPg0KPCEtLSBM aW5rIFRhZyAtLT48QSBIUkVGPSIuLi9vYml0cy8iPg0KDQo8Rk9OVCBTSVpFPSIxIiBGQUNF PSJ2ZXJkYW5hLCBhcmlhbCwgaGVsdmV0aWNhIiBDT0xPUj0iI0ZGRkZGRiI+PEI+T2JpdHVh cmllczwvQj48L0ZPTlQ+PC9BPjwhLS0gRm9udCBUYWcgLS0+PEI+PEZPTlQgQ09MT1I9IiMw MDAwMDAiPiB8IDwvQj4NCjwhLS0gTGluayBUYWcgLS0+PEEgSFJFRj0iaHR0cDovL3d3dy5q dXN0Z28uY29tL2xlYWRlciIgdGFyZ2V0PSJqdXN0Z28iPg0KDQo8Rk9OVCBTSVpFPSIxIiBG QUNFPSJ2ZXJkYW5hLCBhcmlhbCwgaGVsdmV0aWNhIiBDT0xPUj0iI0ZGRkZGRiI+PEI+SnVz dCBHby9FbnRlcnRhaW5tZW50PC9CPjwvRk9OVD48L0E+PCEtLSBGb250IFRhZyAtLT48Qj48 Rk9OVCBDT0xPUj0iIzAwMDAwMCI+IHwgPC9CPg0KPCEtLSBMaW5rIFRhZyAtLT48QSBIUkVG PSJodHRwOi8vd3d3LnRpbWVzbGVhZGVyLmNvbS9jbGFzcy9ob21lLmh0bSI+DQoNCjxGT05U IFNJWkU9IjEiIEZBQ0U9InZlcmRhbmEsIGFyaWFsLCBoZWx2ZXRpY2EiIENPTE9SPSIjRkZG RkZGIj48Qj5DbGFzc2lmaWVkczwvQj48L0ZPTlQ+PC9BPjwhLS0gRm9udCBUYWcgLS0+PEI+ PEZPTlQgQ09MT1I9IiMwMDAwMDAiPiB8IDwvQj48IS0tIExpbmsgVGFnIC0tPjxBIEhSRUY9 Imh0dHA6Ly93d3cudGltZXNsZWFkZXIuY29tL2NvbnRhY3QuaHRtIj4NCg0KPEZPTlQgU0la RT0iMSIgRkFDRT0idmVyZGFuYSwgYXJpYWwsIGhlbHZldGljYSIgQ09MT1I9IiNGRkZGRkYi PjxCPkNvbnRhY3QgdXM8L0I+PC9GT05UPjwvQT48L1RSPjwvVEQ+PC9UUj48L1RBQkxFPg0K DQo8L0NFTlRFUj4NCg0KPC9GT05UPjxDRU5URVI+PElNRyBTUkM9Imh0dHA6Ly93d3cudGlt ZXNsZWFkZXIuY29tL2ltYWdlcy90bGdyYWQuZ2lmIiBXSURUSD02MDAgaGVpZ2h0PTE0IEJP UkRFUj0wPjwvQ0VOVEVSPg0KDQo8L0NFTlRFUj4NCjxjZW50ZXI+PHA+DQoNCjx0YWJsZSB3 aWR0aD0iNjAwIiBib3JkZXI9MD4NCg0KPHRyPjx0ZD4NCjwhLS0gYmVnaW4gQ29udGVudCAt LT4NCjxhIGhyZWY9IjIyTkFNRVMxQS5odG0/dGVtcGxhdGU9YWVtYWlsLmh0bSI+DQoNCjxp bWcgYWxpZ249cmlnaHQgc3JjPSJodHRwOi8vb2JqZWN0cy5waGlsbHkuY29tL210Mi9pX2Vt YWlsLmdpZiIgd2lkdGg9Ijg5IiBoZWlnaHQ9IjIyIiBib3JkZXI9IjAiIGFsdD0iRW1haWwg dGhlIHN0b3J5Ij4NCg0KPC9hPg0KDQo8YSBocmVmPSIyMk5BTUVTMUEuaHRtP3RlbXBsYXRl PWFwcmludC5odG0iPg0KDQo8aW1nIGFsaWduPXJpZ2h0IHNyYz0iaHR0cDovL29iamVjdHMu cGhpbGx5LmNvbS9tdDIvaV9wcmludHRleHQuZ2lmIiB3aWR0aD0iODkiIGhlaWdodD0iMjIi IGJvcmRlcj0iMCIgYWx0PSJQcmludCB0ZXh0Ij4NCg0KPC9hPjxicj48YnI+PGgyPjwhLS0g Z2V0QXJ0aWNsZTpoZWFkbGluZSAtLT5XaGF0J3MgaW4gYSBuYW1lPyBRdWl0ZSBwb3NzaWJs eSB0aGUgY2FyZWVyIG9mIGEgcG9saXRpY2lhbgo8IS0tIC9nZXRBcnRpY2xlOmhlYWRsaW5l IC0tPjwvaDI+DQoNCjxoND48IS0tIGdldEFydGljbGU6aGVhZGxpbmUyIHN0cmlwTGluZT0i dHJ1ZSIgLS0+U291bmRzIGxpa2UgYSB3aW5uZXIKPCEtLSAvZ2V0QXJ0aWNsZTpoZWFkbGlu ZTIgLS0+PC9oND4NCg0KPGI+PCEtLSBnZXRBcnRpY2xlOmJ5bGluZSBzdHJpcExpbmU9InRy dWUiIC0tPkJ5IFNURVZFTiBBLiBNT1JFTExJPCEtLSAvZ2V0QXJ0aWNsZTpieWxpbmUgLS0+ PC9iPjxicj4NCjwhLS0gZ2V0QXJ0aWNsZTpieWNyZWRpdCBzdHJpcExpbmU9InRydWUiIC0t PkZvciB0aGUgVGltZXMgTGVhZGVyCjwhLS0gL2dldEFydGljbGU6YnljcmVkaXQgLS0+DQoN Cgo8cD4NCg0KCjwhLS0gZ2V0QXJ0aWNsZTpib2R5IC0tPgpCdXNoIGlzIGEgaGlzcy4gR29y ZSBpcyBhIGdyb3dsLjxiciAvPjxiciAvPgpTYXkgaXQuIFlvdSdsbCBoZWFyIGl0LiBCdXNz c2hoaGhoaGguIEdvcnJycnJycnJyZS48YnIgLz48YnIgLz4KVGhhdCBpcyBob3cgc29tZSBy ZXNlYXJjaGVycyBzZWUsIG9yIGhlYXIsIGNhbmRpZGF0ZXMnIG5hbWVzLiBBbmQgaXQgaXMg dHJ1ZSBmb3IgbWFueSB2b3RlcnMsIHRvby4gQWZ0ZXIgdGhleSBjaG9vc2UgaW4gdGhlIHdl bGwta25vd24gcmFjZXMsIHRoZXkgZ2V0IHRvIHRoZSBib3R0b20gb2YgdGhlIGxpc3QgYW5k IHNlZSB1bmZhbWlsaWFyIG5hbWVzIGluIHJhY2VzIHRoZXkgaGFkIG5vdCBoZWFyZCBtdWNo IGFib3V0LiBTbyB0aGUgdm90ZXIgaXMgbGVmdCB3aXRoIGFuIEFsIFN0ZWFsaXQgYW5kIGFu IEkuTS4gVHJ1dGhmdWwuPC9iPjxiciAvPjxiciAvPgpUaGUgY2hvaWNlIGlzIG1vcmUgdGhh biBndXQgcmVhY3Rpb24gYW5kIGEgd2hvbGUgYXJlYSBvZiBzdHVkeSBiYWNrcyB0aGF0IHVw LiBHcmFudCBTbWl0aCwgY29vcmRpbmF0b3IgZm9yIGh1bWFuaXRpZXMgYXQgRWFzdGVybiBX YXNoaW5ndG9uIFVuaXZlcnNpdHksIGhhcyBkZXZpc2VkIGEgMjAtcG9pbnQgc3lzdGVtIHRv IGp1ZGdlIGhvdyBuYW1lcyBhZmZlY3QgcGVvcGxlLiBTaW1pbGFyIHRvIGRldGVybWluaW5n IHRoYXQgU2NodWJlcnQgaXMgc29vdGhpbmcgYW5kIEphZ2dlciBpcyBqYXJyaW5nIGluIG11 c2ljLCB0aGUgc2FtZSB2YWx1ZXMgZW50ZXIgaW4gYXBwcmFpc2luZyBuYW1lcy48YnIgLz48 YnIgLz4KIlJoeXRobSBpcyBtb3N0IGltcG9ydGFudCwiIHNhaWQgU21pdGgsIHdobyBpcyBw cmVzaWRlbnQgb2YgdGhlIEFtZXJpY2FuIE5hbWUgU29jaWV0eS4gIlRoZXJlIGFyZSBzb21l IHBhdHRlcm5zIHZlcnkgZmF2b3JhYmxlIHRvIHBvbGl0aWNpYW5zLiI8YnIgLz48YnIgLz4K UmVhZ2FuIGhhZCBpdC4gQ2xpbnRvbiBoYXMgaXQuIFRoZXkgc3RhcnQgd2l0aCBhIHN0cm9u ZyBjb25zb25hbnQuIFRoZSBhY2NlbnQgaXMgb24gdGhlIGZpcnN0IHN5bGxhYmxlLiBUaGV5 IGVuZCB3aXRoIGFuICJ1biIgc291bmQsIHdoaWNoIGlzIGdvb2QuIERvIG5vdCBhc2sgd2h5 IGl0IGlzIGdvb2QsIGl0IGp1c3QgaXMuPGJyIC8+PGJyIC8+ClNtaXRoIGFwcGxpZWQgaGlz IGZvcm11bGEgdG8gdGhlIGZ1bGwgcm9zdGVyIG9mIGNvbmdyZXNzaW9uYWwgcmFjZXMgaW4g dGhlIDE5OTggZWxlY3Rpb24gYW5kIGZvdW5kIHRoZSBiZXR0ZXIgbmFtZSB3aWxsIHdpbiA2 NSBwZXJjZW50IG9mIHRoZSB0aW1lLjxiciAvPjxiciAvPgpTbyB3aGF0J3MgaW4gYSBuYW1l PyBBIGxvdCBvZiBiaW9sb2dpY2FsIGJhZ2dhZ2UsIHRoYXQncyB3aGF0LjxiciAvPjxiciAv PgoiV2l0aCBhIGhpc3Mgb3IgYSBncm93bCwgb3VyIGJpb2xvZ3kgdGVsbHMgdXMgdG8gcnVu IGF3YXksIiBTbWl0aCBzYWlkLiBCdXQgaGUgZ2l2ZXMgdGhlIGVkZ2UgdG8gR29yZSBpbiB0 aGUgbmFtZSBnYW1lIGJlY2F1c2UgYWx0aG91Z2ggaXQgaXMgYSBncm93bCwgR29yZSBjb3Vs ZCBiZSBncm93bGluZyBmb3IgdXMgcmF0aGVyIHRoYW4gYXQgdXMuIEhpc3NpbmcgZm9yIHVz LCBvbiB0aGUgb3RoZXIgaGFuZCwgaGFzIG5vIGhvcGUgb2YgZml4aW5nIHRoZSBTb2NpYWwg U2VjdXJpdHkgbW9yYXNzLjxiciAvPjxiciAvPgpTbWl0aCBmb2N1c2VzIG9uIGxhc3QgbmFt ZXMgYW5kIHRoZWlyIHNvdW5kczsgRWR3YXJkIENhbGxhcnksIEVuZ2xpc2ggcHJvZmVzc29y IGF0IE5vcnRoZXJuIElsbGlub2lzIFVuaXZlcnNpdHksIHBheXMgbW9yZSBhdHRlbnRpb24g dG8gZmlyc3QgbmFtZXMuIEhpcyB0aGVvcnkgaXMgZmlyc3QgbmFtZXMgYXJlIGltcG9ydGFu dCBiZWNhdXNlIGl0IHJlcHJlc2VudHMgdGhlIGZhY2UgcGVvcGxlIGNob29zZSB0byBzaG93 IHRoZSB3b3JsZC4gQW5kIHRoZSB3b3JsZCBpcyBnZXR0aW5nIHF1aXRlIGNodW1teSwganVk Z2luZyBieSB0aG9zZSBuYW1lcy48YnIgLz48YnIgLz4KIk5vdyB5b3UgaGF2ZSBCaWxsIGFu ZCBBbCwiIFNtaXRoIHNhaWQsIHBvbmRlcmluZyBob3cgdGhhdCBzb3VuZGVkLiAiU291bmRz IGxpa2UgYSB1c2VkIGNhciBkZWFsZXJzaGlwLCBkb2Vzbid0IGl0PyBCaWxsICduJyBBbC4i PGJyIC8+PGJyIC8+ClNtaXRoLCB3aG8gZWRpdHMgdGhlIGpvdXJuYWwgIk5hbWVzLCIgaWRl bnRpZmllcyBKaW1teSBDYXJ0ZXIgYXMgdGhlIGluc3RpZ2F0b3Igb2YgYWxsIHRoaXMgZ3Jl Z2FyaW91c25lc3MuIEphbWVzIEVhcmwgQ2FydGVyPyBTdHVmZnkuIEppbSBDYXJ0ZXI/IEFo LCBiZXR0ZXIsIGJ1dCBzdGlsbCBhIGxpdHRsZSBzdGlmZi4gSmltbXkgQ2FydGVyPyBOb3cg eW91J3JlIHRhbGtpbmcgYmlnLCBoYXBweSB0ZWV0aC4gTGVnZW5kIGhhcyBpdCB0aGUgSmlt bXkgaXMgd2hhdCBnYXZlIHRoZSBHZW9yZ2lhIGdvdmVybm9yIHRoZSBsZWFkLjxiciAvPjxi ciAvPgpEb2VzIHRoYXQgdGVjaG5pcXVlIHJlYWxseSB3b3JrPzxiciAvPjxiciAvPgpJdCBk aWQgd2l0aCBSYXkgWmltbWVybWFuLCBhIHZlbmRvciBzZWxsaW5nIHZlZ2V0YWJsZXMgYXQg dGhlIEZhcm1lcnMgTWFya2V0IGluIFdpbGtlcy1CYXJyZS48YnIgLz48YnIgLz4KTG9va2lu ZyBhdCBuYW1lcyBpbiBhIHJvc3RlciBvZiBjYW5kaWRhdGVzLCBaaW1tZXJtYW4gdG9vayBh IGxpa2luZyB0byBUb20gUGFycnksIHdobyBpcyBydW5uaW5nIGluIHRoZSAxMTR0aCBEaXN0 cmljdCByYWNlIGZvciBzdGF0ZSByZXByZXNlbnRhdGl2ZSwgYXMgb3Bwb3NlZCB0byBUaG9t YXMgTS4gVGlndWUgaW4gdGhlIDExOHRoIERpc3RyaWN0LjwvYj48YnIgLz48YnIgLz4KIlRh bGtpbmcgdG8gYSBUb20gaXMgbGlrZSB0YWxraW5nIHRvIGEgZ3V5IGluIGEgYmFyLCIgWmlt bWVybWFuIHNhaWQuICJUYWxraW5nIHRvIGEgVGhvbWFzIGlzIGxpa2UgdGFsa2luZyB0byBh IGxhd3llciBvciBzb21ldGhpbmcuIjxiciAvPjxiciAvPgpTbywgd2hhdCBhcmUgdGhlIGV4 cGVydHMnIHBpY2tzIGluIHNvbWUgbG9jYWwgcmFjZXM/IEluIHRoZSAxMTR0aCBEaXN0cmlj dCwgQ2FsbGFyeSBzYWlkIGl0IHdhcyBhIHRvdWdoIGNob2ljZSBiZXR3ZWVuIFJlcHVibGlj YW4gVG9tIFBhcnJ5IGFuZCBEZW1vY3JhdCBKaW0gV2Fuc2Fjei48YnIgLz48YnIgLz4KIlRv bSBhbmQgSmltPyBUaGF0J3MgYSByZWFsbHkgY2xvc2UgY2FsbCwiIENhbGxhcnkgc2FpZC4g IlRoZXkncmUgYm90aCByZWFsbHkgQW1lcmljYW4gbmFtZXMuIjxiciAvPjxiciAvPgpBbHRo b3VnaCB0aGUgbmFtZSBXYW5zYWN6IGlzIHBlcmhhcHMgYW4gdW53aWVsZHkgbmFtZSwgSmlt IGJhbGFuY2VzIGl0IG5pY2VseSwgQ2FsbGFyeSBzYWlkLjxiciAvPjxiciAvPgpIb3cgYWJv dXQgdGhlIFJlZm9ybSBjYW5kaWRhdGUsIExlb25hcmQgSi4gU2t1cnNreSBKci4/ICJEb2Vz bid0IGhhdmUgYSBjaGFuY2UsIiB3YXMgQ2FsbGFyeSdzIHByb21wdCByZXBseS48YnIgLz48 YnIgLz4KQ2FsbGFyeSBjYXV0aW9uZWQgdGhhdCB0aGlzIGlzIGJhc2VkIHB1cmVseSBvbiBu YW1lcyBhbmQgY2VydGFpbmx5IG5vdCBhbnkgb3RoZXIgZmFjdG9ycyBpbiB0aGUgcmFjZS4g QnV0IGhlIGFsc28gc2FpZCBldmVuIGluIGVsZWN0aW9ucyBpbiB3aGljaCB2b3RlcnMga25v dyB0aGUgY2FuZGlkYXRlcyBhbmQgaXNzdWVzLCB0aGV5IHNvbWV0aW1lcyBzdGlsbCBjaG9v c2UgYmVjYXVzZSBvZiBob3cgdGhleSBwZXJjZWl2ZSB0aGUgbmFtZXMuICJJdCdzIGltcHVs c2l2ZW5lc3MuIjxiciAvPjxiciAvPgpPbnRvIHRoZSAxMTZ0aCBEaXN0cmljdDogUmVwdWJs aWNhbiBTdXNhbiBQYXJyaWNrLUNveCBhbmQgRGVtb2NyYXQgVG9kZCBBLiBFYWNodXMuICJU b2RkLCBvb29vb29vaCwgdGhhdCdzIGdvb2QsIiBDYWxsYXJ5IHNhaWQuICJUaGUgbGFzdCBu YW1lIGlzIGRpZmZpY3VsdCwgYnV0IHRoZSBUb2RkIGJyaW5ncyBpdCBhbGwgaG9tZS4gVGhh dCdzIGEgZ29vZCBuYW1lLiI8YnIgLz48YnIgLz4KUGFycmljay1Db3ggaGFzIGEgaGFuZGlj YXAgYmVjYXVzZSBvZiBoZXIgaHlwaGVuYXRlZCBsYXN0IG5hbWUuICJUaGF0IHBsYXlzIHdl bGwgdG8gd29tZW4sIiBDYWxsYXJ5IHNhaWQuICJCdXQgc29tZSBtZW4gbWlnaHQgbm90IGxp a2UgdGhhdC4gVGhleSBtaWdodCBhc3N1bWUgc2hlIGlzIGEgcmFkaWNhbCBmZW1pbmlzdC4i PGJyIC8+PGJyIC8+ClNtaXRoLCB0aGUgcHJvZmVzc29yIHdobyBzdHVkaWVzIG5hbWVzJyBz b3VuZHMsIGFsc28gdGhpbmtzIGEgaHlwaGVuYXRlZCBuYW1lIGlzIGEgZGlzYWR2YW50YWdl LiAiSXQncyB0YWtpbmcgdHdvIGxhbmd1YWdlcyBhbmQgc3RpY2tpbmcgdGhlbSB0b2dldGhl ci4gSXQncyBpbnRlcnJ1cHRlZC4iPGJyIC8+PGJyIC8+ClR3byB3b21lbiBlYXRpbmcgbHVu Y2ggYXQgTWltbW8ncyBQaXp6YSBhbmQgUmVzdGF1cmFudCBpbiBXaWxrZXMtQmFycmUgZGlk IG5vdCBsaWtlIHRoZSB0aG91Z2h0IG1lbiBtaWdodCBtYWtlIGEgZGVjaXNpb24gYWJvdXQg YSBmZW1hbGUgY2FuZGlkYXRlIGJlY2F1c2Ugb2YgYSBoeXBoZW4uPGJyIC8+PGJyIC8+CiJB IGxpYmVyYXRlZCB3b21hbiwiIERlYmJpZSBQYXJyaXNoIHNhaWQsIHVzaW5nIHRoZSB3b3Jk IHNvbWUgbWVuIHVzZSB0aGUgd2F5IGNvbnNlcnZhdGl2ZXMgdXNlIHRoZSB0ZXJtICJsaWJl cmFsLiI8YnIgLz48YnIgLz4KIk1heWJlIEkgd291bGQgcGljayBoZXIganVzdCB0byB0aWNr IG9mZiBzb21lIG1lbiwiIHNhaWQgQ2FybGEgQWxsZXMuPGJyIC8+PGJyIC8+CiJUaGV5IG5l ZWQgdG8gZ2V0IHdpdGggdGhlIHRpbWVzLCIgUGFycmlzaCBzYWlkLjxiciAvPjxiciAvPgpa aW1tZXJtYW4sIHdobyBjb25zaWRlcmVkIHRoZSBuYW1lcyBpbiB0aGUgc2FtZSByYWNlIGFz IGhlIHNvbGQgdmVnZXRhYmxlcyBvbiB0aGUgUHVibGljIFNxdWFyZSwgc2FpZCBoZSB3b3Vs ZCBjaG9vc2UgUGFycmljay1Db3ggaW4gdGhhdCByYWNlLCBqdWRnaW5nIHB1cmVseSBieSBu YW1lcy48YnIgLz48YnIgLz4KSGUgbGlrZXMgdGhlIGh5cGhlbiBiZWNhdXNlIGl0IHNob3dz IHNoZSdzIG1hcnJpZWQuPGJyIC8+PGJyIC8+Cgo8IS0tIC9nZXRBcnRpY2xlOmJvZHkgLS0+ DQoNCjxwPg0KPCEtLSBlbmQgY29udGVudCAtLT4NCg0KPHNjcmlwdCBsYW5ndWFnZT0iSmF2 YVNjcmlwdCI+DQoNCnZhciBkb2VzQXJ0aWNsZUhhdmVSZWxhdGVkID0gIjAiIDsNCg0KaWYo ZG9lc0FydGljbGVIYXZlUmVsYXRlZCA+PSAiMSIpew0KDQogICAgZG9jdW1lbnQud3JpdGUo IjxpbWcgd2lkdGg9MTYxIGhlaWdodD0xMyBzcmM9aHR0cDovL29iamVjdHMucGhpbGx5LmNv bS93b3JkdGVhc2Uvd3RfcmVsYXRlZC5naWY+PGJyPlxuIikgOw0KDQogICAgZG9jdW1lbnQu d3JpdGUoIjxocj4iKSA7DQoNCn0NCg0KPC9zY3JpcHQ+DQogDQoNCjxzY3JpcHQgbGFuZ3Vh Z2U9IkphdmFTY3JpcHQiPg0KDQppZihkb2VzQXJ0aWNsZUhhdmVSZWxhdGVkID49ICIxIil7 DQoNCiAgICBkb2N1bWVudC53cml0ZSgiPGhyPiIpIDsNCg0KfQ0KDQo8L3NjcmlwdD4NCjxo cj4NCg0KPGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9LTE+R290IGFuIG9waW5pb24gYWJvdXQg dGhpcyBvciBhbnl0aGluZyBoYXZpbmcgdG8gZG8gd2l0aCB0aGUgYXJlYT88YnI+IDxhIGhy ZWY9Imh0dHA6Ly9mb3J1bS53aWxrZXNiYXJyZXNjcmFudG9uLmNvbSI+PGI+U2F5IGl0IGhl cmU8L2ZvbnQ+PC9iPjwvYT4hIA0KDQo8IS0tIFNQQUNFUiAtLT4NCg0KPFREIFdJRFRIPSI5 IiBWQUxJR049VE9QPg0KDQo8SU1HIEJPUkRFUj0iMCIgV0lEVEg9IjkiIEhFSUdIVD0iMSIg U1JDPSJodHRwOi8vd3d3LnRpbWVzbGVhZGVyLmNvbS9pbWFnZXMvd2hpdGUuZ2lmIj4NCg0K PC9URD4NCg0KPFREIFdJRFRIPSIxIiBWQUxJR049VE9QIEJHQ09MT1I9IiNENUQ1RDUiPg0K DQo8SU1HIEJPUkRFUj0iMCIgV0lEVEg9IjEiIEhFSUdIVD0iMSIgU1JDPSJodHRwOi8vd3d3 LnRpbWVzbGVhZGVyLmNvbS9pbWFnZXMvYmxhY2suZ2lmIj4NCg0KPC9URD4NCg0KPFREIFdJ RFRIPSI5IiBWQUxJR049VE9QPg0KDQo8SU1HIEJPUkRFUj0iMCIgV0lEVEg9IjkiIEhFSUdI VD0iMSIgU1JDPSJodHRwOi8vd3d3LnRpbWVzbGVhZGVyLmNvbS9pbWFnZXMvd2hpdGUuZ2lm Ij4NCg0KPC9URD4NCjwhLS0gRU5EIFNQQUNFUiAtLT4NCjxURCBWQUxJR049VE9QIHdpZHRo PSIxNDAiPjwhLS0gRm9udCBUYWcgLS0+PEZPTlQgU0laRT0tMg0KDQpDT0xPUj0iIzc2NzI3 QSI+PGRpdiBhbGlnbj0iY2VudGVyIj5BRFZFUlRJU0VSUzwvZGl2PjwvRk9OVD48YnI+DQoN CjxhIEhSRUY9Imh0dHA6Ly9hZHMucmVhbGNpdGllcy5jb20vY2xpY2submcvc2l0ZT1sZWFk ZXJuZXQmc2l6ZT0xMjB4NjAmcG9zPXBvc2IiPg0KDQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxp bWcgU1JDPSJodHRwOi8vYWRzLnJlYWxjaXRpZXMuY29tL2ltYWdlLm5nL3NpdGU9bGVhZGVy bmV0JnNpemU9MTIweDYwJnBvcz1wb3NiIg0KDQpib3JkZXI9MD48L2Rpdj48L2E+DQoNCjxw Pg0KDQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxzY3JpcHQgbGFuZ3VhZ2U9IkphdmFTY3JpcHQi Pg0KDQoJCQkNCg0KCQkJCXZhciBhZHNTZWN0aW9uID0gIm5ld3MiIDsNCg0KCQkJCXZhciBh ZHNQdWJsaWNhdGlvbiA9ICJsZWFkZXIiIDsNCg0KCQkJCQ0KDQoJCQkJc2hvd0J1dHRvbkFk cyhhZHNQdWJsaWNhdGlvbiwgYWRzU2VjdGlvbikgOw0KDQoJCQkJDQoNCgkJCQk8L3Njcmlw dD4NCg0KPC9kaXY+DQoNCjxwPg0KDQo8YSBIUkVGPSJodHRwOi8vYWRzLnJlYWxjaXRpZXMu Y29tL2NsaWNrLm5nL3NpdGU9bGVhZGVybmV0JnNpemU9MTIweDYwJnBvcz1wb3NjIj4NCg0K PGRpdiBhbGlnbj0iY2VudGVyIj48aW1nIFNSQz0iaHR0cDovL2Fkcy5yZWFsY2l0aWVzLmNv bS9pbWFnZS5uZy9zaXRlPWxlYWRlcm5ldCZzaXplPTEyMHg2MCZwb3M9cG9zYyINCg0KYm9y ZGVyPTA+PC9kaXY+PC9hPjxwPg0KDQo8UD4NCg0KPC90ZD48L3RyPjwvdGFibGU+DQoNCjxi ciBjbGVhcj1hbGw+DQo8cD4NCjxDRU5URVI+DQoNCjxUQUJMRSBCT1JERVI9IjAiIENFTExT UEFDSU5HPSIwIiBDRUxMUEFERElORz0iMCIgd2lkdGg9NjAwPg0KDQo8VFI+PFREIEJHQ09M T1I9IiMwMDAwMDAiIFdJRFRIPSIyMzEiIGhlaWdodD0iMTgiPg0KIDwhLS0gR3JhcGhpYyBU YWcgLS0+PCEtLSBMaW5rIFRhZyAtLT4NCg0KPGRpdiBhbGlnbj0ibGVmdCI+PEEgSFJFRj0i aHR0cDovL3d3dy50aW1lc2xlYWRlci5jb20iPjxJTUcgV0lEVEg9MTUxIEhFSUdIVD0yNyBo c3BhY2U9MCB2c3BhY2U9MA0KDQpCT1JERVI9MCBTUkM9Ii9vYmplY3RzL2xlYWRlci9pbWFn ZXMvbGVhZGVyYm90LmdpZiI+PC9BPjwvZGl2Pg0KDQo8L1RSPg0KPC9GT05UPg0KDQo8L1RE PjwvVFI+PC9UQUJMRT4NCg0KPC9DRU5URVI+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxmb250 IGZhY2U9IkFyaWFsIiBzaXplPSItMiIgY29sb3I9IiNjNWM1YzUiPkFsbCBjb250ZW50IKkg MjAwMCB0aGUgVElNRVMgTEVBREVSIGFuZCBtYXkgbm90IGJlIHJlcHVibGlzaGVkIHdpdGhv dXQgcGVybWlzc2lvbi48cD48YSBocmVmPSJodHRwOi8vd3d3LnRpbWVzbGVhZGVyLmNvbS9w cml2YWN5Lmh0bSI+UHJpdmFjeSBTdGF0ZW1lbnQ8L2E+PC9mb250PjwvZGl2PiA8L2ZvbnQ+ DQoNCjxwPg0KPCEtLSBCT1RUT00gT0YgUEFHRSBORVQgR1JBVklUWSBDT0RFIEJFR0lOUyBI RVJFIC0tPg0KPGRpdiBhbGlnbj0iY2VudGVyIj4NCg0KPGEgSFJFRj0iaHR0cDovL2Fkcy5y ZWFsY2l0aWVzLmNvbS9jbGljay5uZy9zaXRlPWxlYWRlcm5ldCZzaXplPTQ2OHg2MCZjYXQ9 aG9tZSZwb3M9dG9wIj4NCg0KPGltZyBTUkM9Imh0dHA6Ly9hZHMucmVhbGNpdGllcy5jb20v aW1hZ2Uubmcvc2l0ZT1sZWFkZXJuZXQmc2l6ZT00Njh4NjAmY2F0PWhvbWUmcG9zPXRvcCIg Ym9yZGVyPTA+PC9hPg0KDQo8L2Rpdj4NCjxwPg0KDQo8IS0tIEJPVFRPTSBPRiBQQUdFIE5F VCBHUkFWSVRZIENPREUgRU5EUyBIRVJFIC0tPg0KPC9CT0RZPg0KDQo8L0hUTUw+DQoNCg0K --CN30294si1kJ655561-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 23 09:18:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANHItUu010665; Sat, 23 Nov 2002 09:18:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gANHItQS010664; Sat, 23 Nov 2002 09:18:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANHIpUu010657 for ; Sat, 23 Nov 2002 09:18:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gANHJ1Mq011491 for ; Sat, 23 Nov 2002 09:19:02 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26213 for ; Sat, 23 Nov 2002 10:18:56 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gANHJ1ve027733; Sat, 23 Nov 2002 18:19:02 +0100 (CET) Date: Sat, 23 Nov 2002 18:19:00 +0100 Subject: Re: globally unique site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "Charlie Perkins" , "Tim Chown" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <2B81403386729140A3A899A8B39B046405E4A8@server2000> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Also, there is nothing that says that we can't have both Pekka's almost > unique *and* something like what I proposed which is completely unique > at the same time. > ...or that we could just use global unicast addresses? - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 23 10:37:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANIbFUu010830; Sat, 23 Nov 2002 10:37:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gANIbF7O010829; Sat, 23 Nov 2002 10:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANIbCUu010822 for ; Sat, 23 Nov 2002 10:37:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gANIbMbB029951 for ; Sat, 23 Nov 2002 10:37:22 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06394 for ; Sat, 23 Nov 2002 11:37:16 -0700 (MST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 23 Nov 2002 10:37:15 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 23 Nov 2002 10:37:15 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Sat, 23 Nov 2002 10:36:59 -0800 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); Sat, 23 Nov 2002 10:37:15 -0800 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.3710.0); Sat, 23 Nov 2002 10:37:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Enforcing unreachability of site local addresses Date: Sat, 23 Nov 2002 10:37:14 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses Thread-Index: AcKRkeEJAiKkecKAQP+RKmJeTtDNXAAAQZoAABIARzAAUILHaA== From: "Christian Huitema" To: X-OriginalArrivalTime: 23 Nov 2002 18:37:14.0059 (UTC) FILETIME=[5778A9B0:01C2931F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gANIbCUu010823 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One of the point in the discussion of the "globally unique" site local addresses has been the discussion of their usage. In particular, if the new addresses are globally unique, how do we prevent them from being globally routed and creating a mess in the global routing tables; and, on a related note, how do we make sure that they are actually local? The issue is clearly complex. There are legitimate scenarios in which two sites might want to create some kind of backdoor connection independent of any ISP connection, in a way similar to the various "extranet" scenarios that are common today; it could also be used in a merger situation. There are also illegitimate scenarios in which a powerful customer would pressure an ISP to simply advertize their globally unique /48. I believe that Bob Hinden provided the beginning of the answer when he proposed that all routers would have a default black-hole for the site local prefix. The implementation would be the following: 1) In a local site, advertise the subnet routes in the IGP, possibly a default route for the site, and a black-hole for the site local prefix. This guarantees internal connectivity to the valid subnets, and unreachability for all other sites. 2) In an extranet scenario, import in the IGP an explicit route for the "friendly" sites, and point it to the specific backdoor connecctions to these sites. This will override the blackhole. 3) At a border router, discard all BGP route that point to the site local prefix or subsets of it. 4) At a site border router or firewall, perform ingress filtering and discard all externally sourced packets in which the source address pretends to belong to the internal site. The combination of 1 and 3 presents a powerful disencentive against the "leakage of routes" risk: a powerful customer might pressure a local ISP, but that would be to no avail since the packets would be dropped by the next hop. I believe that the combination of the four rules will provide the desired locality benefits without having to resort to ambiguity as an enforcement mechanism. -- 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 Sat Nov 23 13:40:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANLeYUu011881; Sat, 23 Nov 2002 13:40:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gANLeYPj011880; Sat, 23 Nov 2002 13:40:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANLeVUu011873 for ; Sat, 23 Nov 2002 13:40:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gANLefbB020406 for ; Sat, 23 Nov 2002 13:40:41 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28906 for ; Sat, 23 Nov 2002 14:40:35 -0700 (MST) Subject: RE: globally unique site local addresses Date: Sat, 23 Nov 2002 13:40:35 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD428@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message Thread-Index: AcKSvgGUPAdNtmxbT9Ws2wYsib7uDgAenXpQ From: "Michel Py" To: "Mark Smith" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gANLeVUu011874 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mark Smith wrote: > Lack of absolute guarantees of globally unique site local > addressing is a bit of a "stick" that will prevent people > from trying to use their globally unique site locals for > global communications, as per Brian Zill's concerns. I have voiced these concerns myself earlier, and they are valid. However, this stick is really not big and would not prevent these addresses to leak in the defauless route if there is no other enforcement mechanism. > I also like the fact that his model doesn't require any > interaction with a registry of some sort, and any > associated costs ie. his model is "good enough and free", > rather than "perfect and not-free". There is room for both models at the same, and "good enough" is not going to be good enough for everybody. 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 Nov 23 13:43:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANLhuUu011933; Sat, 23 Nov 2002 13:43:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gANLhuuP011932; Sat, 23 Nov 2002 13: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANLhqUu011925 for ; Sat, 23 Nov 2002 13:43:53 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gANLi3bB020737 for ; Sat, 23 Nov 2002 13:44:03 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23888 for ; Sat, 23 Nov 2002 14:43:57 -0700 (MST) Subject: RE: globally unique site local addresses Date: Sat, 23 Nov 2002 13:43:57 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD429@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message Thread-Index: AcKS2Kcdu/FIt8iSQ6muYMNK0rEPfwAYGAFg From: "Michel Py" To: "Mika Liljeberg" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gANLhrUu011926 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mika Liljeberg wrote: > This means that what we really need a site-local > prefix autoconfiguration specification similar to > the link-local address autoconfiguration. This makes little sense. Site-locals involve routing between subnets and router configuration, this falls into the categories of things that still requires a network administrator to do. The point that site-locals addresses are *not* automatically configured has been made several times here. 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 Nov 23 14:02:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANM2TUu012080; Sat, 23 Nov 2002 14:02:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gANM2Sj2012079; Sat, 23 Nov 2002 14:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANM2PUu012072 for ; Sat, 23 Nov 2002 14:02:25 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gANM2ZbB022720 for ; Sat, 23 Nov 2002 14:02:36 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00103 for ; Sat, 23 Nov 2002 15:02:29 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gANM2Zve027802; Sat, 23 Nov 2002 23:02:37 +0100 (CET) Date: Sat, 23 Nov 2002 23:02:35 +0100 Subject: Re: globally unique site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "Mark Smith" , "Brian Zill" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <2B81403386729140A3A899A8B39B0464010BF5@server2000> Message-Id: <45B4BBAB-FF2F-11D6-940E-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Any organization that is serious about using site-locals. Two examples > comes to mind: > - Corporate mergers (avoids the renumbering pain found today when the > two corporations were using 10.0.0.0) > Following the discussions from the WG meeting I would rather say that this points to one of the disadvantages of site scopes. Now we are trying to get around those with even more complexity... - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 23 14:18:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANMIDUu012196; Sat, 23 Nov 2002 14:18:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gANMIDor012195; Sat, 23 Nov 2002 14:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANMIAUu012188 for ; Sat, 23 Nov 2002 14:18:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gANMIKbB024310 for ; Sat, 23 Nov 2002 14:18:20 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07893 for ; Sat, 23 Nov 2002 15:18:14 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gANMIRve027808; Sat, 23 Nov 2002 23:18:27 +0100 (CET) Date: Sat, 23 Nov 2002 23:18:26 +0100 Subject: Re: globally unique site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Michel Py , Brian Zill , ipng@sunroof.eng.sun.com To: Mark Smith From: Kurt Erik Lindqvist In-Reply-To: <1038034779.3459.332.camel@dupy> Message-Id: <7CC2F56F-FF31-11D6-940E-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Absolutely agree. I've experienced the both the VPN and network 10 > addressing situation concurrently with IPv4, in addition to having to > come up with bodgey solutions, I spent two months just saying to my > self > "customers should just get registered address space, and make my life > (and theirs') a whole lot easier." Good point! > > Globally unique site locals would fix a lot of the issues I had with > trying to work out how I might use site-locals in large IPv6 network. > Uhm, why not go with what you proposed above instead? - kurtis - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 23 15:17:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANNHNUu012327; Sat, 23 Nov 2002 15:17:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gANNHMUY012326; Sat, 23 Nov 2002 15: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANNHJUu012319 for ; Sat, 23 Nov 2002 15:17:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gANNHTMq022968 for ; Sat, 23 Nov 2002 15:17:30 -0800 (PST) Received: from mail.nosense.org (62.cust4.nsw.dsl.ozemail.com.au [203.103.159.62]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16947 for ; Sat, 23 Nov 2002 16:17:23 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 690CF3B39C; Sun, 24 Nov 2002 10:17:17 +1100 (EST) Subject: Re: globally unique site local addresses From: Mark Smith To: Kurt Erik Lindqvist Cc: Michel Py , Brian Zill , ipng@sunroof.eng.sun.com In-Reply-To: <7CC2F56F-FF31-11D6-940E-000393AB1404@kurtis.pp.se> References: <7CC2F56F-FF31-11D6-940E-000393AB1404@kurtis.pp.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 24 Nov 2002 10:17:17 +1100 Message-Id: <1038093438.1458.53.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 2002-11-24 at 09:18, Kurt Erik Lindqvist wrote: > > Absolutely agree. I've experienced the both the VPN and network 10 > > addressing situation concurrently with IPv4, in addition to having to > > come up with bodgey solutions, I spent two months just saying to my > > self > > "customers should just get registered address space, and make my life > > (and theirs') a whole lot easier." > > Good point! > > > > > Globally unique site locals would fix a lot of the issues I had with > > trying to work out how I might use site-locals in large IPv6 network. > > > > Uhm, why not go with what you proposed above instead? > As I understand it, the goal we are trying to achieve with site-locals (whatever model you follow), is to have locally controlled and assigned address space, independent of the global address space your provider gives you. I agree, if your global address space assignment from your provider is stable enough, and you don't have a requirement for addressing independence, you could simplify your network even further, and not use site-locals in any form at all. Using site-local and global addressing concurrently provides separation of internal verses external connectivity, which then allows external connectivity (and the associated global prefixes) to be changed, with (or at least this appears to be the goal) no impact on internal connectivity. What I think the new (pseudo?)globally unique site-local addressing models are doing is extending the scope of internal communications from a site (geographical or otherwise), to potentially global ie. they are saying that the potential for internal communications may be global, so let's create a separate address space with global uniqueness, but only for use with internal communications. For actual external communications, use existing publicly routable global addressing. Once all the organisations connected to the IPv6 Internet have globally unique site-local addresses, an illogical progression would be for them all to connect themselves up via backdoor connections - to the point where the actual Internet could be switched off :-) However, they will face the same route table explosion / aggregation problems that the real Internet already has, as well as the associated security problems, and will probably leave global connectivity up to the people who make it their business to do it properly - ISPs. 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 23 15:56:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANNu0Uu012491; Sat, 23 Nov 2002 15:56:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gANNu0iR012490; Sat, 23 Nov 2002 15:56:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gANNtuUu012483 for ; Sat, 23 Nov 2002 15:55:56 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gANNu7bB008245 for ; Sat, 23 Nov 2002 15:56:07 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27001 for ; Sat, 23 Nov 2002 15:56:01 -0800 (PST) Subject: RE: Enforcing unreachability of site local addresses Date: Sat, 23 Nov 2002 15:56:01 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4B3@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message Thread-Topic: Enforcing unreachability of site local addresses Thread-Index: AcKRkeEJAiKkecKAQP+RKmJeTtDNXAAAQZoAABIARzAAUILHaAALevJw From: "Michel Py" To: "Christian Huitema" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gANNtvUu012484 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, This is a more detailed version of what I proposed a month ago. I will emphasize that we need something more than a MUST in an RFC to enforce this: We need the site-local black hole and the site-local BGP route discard to be *default* configuration in routers, and to be impossible to remove by accident. This is no big thing to do for router vendors to implement, we just need to reach consensus on it. Michel. -----Original Message----- From: Christian Huitema Sent: Saturday, November 23, 2002 10:37 AM To: ipng@sunroof.eng.sun.com Subject: Enforcing unreachability of site local addresses One of the point in the discussion of the "globally unique" site local addresses has been the discussion of their usage. In particular, if the new addresses are globally unique, how do we prevent them from being globally routed and creating a mess in the global routing tables; and, on a related note, how do we make sure that they are actually local? The issue is clearly complex. There are legitimate scenarios in which two sites might want to create some kind of backdoor connection independent of any ISP connection, in a way similar to the various "extranet" scenarios that are common today; it could also be used in a merger situation. There are also illegitimate scenarios in which a powerful customer would pressure an ISP to simply advertize their globally unique /48. I believe that Bob Hinden provided the beginning of the answer when he proposed that all routers would have a default black-hole for the site local prefix. The implementation would be the following: 1) In a local site, advertise the subnet routes in the IGP, possibly a default route for the site, and a black-hole for the site local prefix. This guarantees internal connectivity to the valid subnets, and unreachability for all other sites. 2) In an extranet scenario, import in the IGP an explicit route for the "friendly" sites, and point it to the specific backdoor connecctions to these sites. This will override the blackhole. 3) At a border router, discard all BGP route that point to the site local prefix or subsets of it. 4) At a site border router or firewall, perform ingress filtering and discard all externally sourced packets in which the source address pretends to belong to the internal site. The combination of 1 and 3 presents a powerful disencentive against the "leakage of routes" risk: a powerful customer might pressure a local ISP, but that would be to no avail since the packets would be dropped by the next hop. I believe that the combination of the four rules will provide the desired locality benefits without having to resort to ambiguity as an enforcement mechanism. -- 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 23 16:26:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO0QCUu012682; Sat, 23 Nov 2002 16:26:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO0QBip012681; Sat, 23 Nov 2002 16:26: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO0Q8Uu012674 for ; Sat, 23 Nov 2002 16:26:08 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO0QIMq028833 for ; Sat, 23 Nov 2002 16:26:19 -0800 (PST) Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07834 for ; Sat, 23 Nov 2002 17:26:12 -0700 (MST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.6/8.12.6/Debian-8) with ESMTP id gAO0Q6hB001688; Sun, 24 Nov 2002 02:26:07 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.6/8.12.6/Debian-8) id gAO0Q5m7001687; Sun, 24 Nov 2002 02:26:05 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: globally unique site local addresses From: Mika Liljeberg To: Michel Py Cc: ipng@sunroof.eng.sun.com In-Reply-To: <2B81403386729140A3A899A8B39B04640BD429@server2000> References: <2B81403386729140A3A899A8B39B04640BD429@server2000> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1038097564.1509.30.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 24 Nov 2002 02:26:04 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 2002-11-23 at 23:43, Michel Py wrote: > > Mika Liljeberg wrote: > > This means that what we really need a site-local > > prefix autoconfiguration specification similar to > > the link-local address autoconfiguration. > > This makes little sense. Site-locals involve routing between subnets and > router configuration, this falls into the categories of things that > still requires a network administrator to do. The point that site-locals > addresses are *not* automatically configured has been made several times > here. Yes, I know that there are cases where the network admin will want to configure the subnets manually. I'm not suggesting that site local prefixes would be autoconfigured by default. This would have to be enabled per router-interface by the admin. Still, I think that there is something to be said for being able to put together a routed site-local network with the same level of convenience as sticking together a bunch of switches. Why not extend Savola's idea to also generate pseudo unique /64's for leaf subnets? A simple duplicate prefix detection mechanism could be added to make it reliable (or the IGP could handle it). This would still provide address stability and retain the possibility to combine or inter-connect separate site-local networks. 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 Nov 23 16:56:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO0ulUu012779; Sat, 23 Nov 2002 16:56:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO0ukRS012778; Sat, 23 Nov 2002 16:56:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO0uhUu012771 for ; Sat, 23 Nov 2002 16:56:43 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO0urMq001462 for ; Sat, 23 Nov 2002 16:56:53 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11840 for ; Sat, 23 Nov 2002 16:56:48 -0800 (PST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id QAA21891; Sat, 23 Nov 2002 16:56:17 -0800 (PST) Message-Id: <5.1.0.14.0.20021123194321.00b34e50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 23 Nov 2002 19:56:09 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Enforcing unreachability of site local addresses Cc: "Christian Huitema" , In-Reply-To: <2B81403386729140A3A899A8B39B046405E4B3@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPv6 WG putting a "MUST" in a spec does not put code in a router. There are already implementations of IPv6 that do not "black-hole" this set of TBD globally-unique, provider- independent addresses, so our solution must not depend on all routers black-holing packets to/from these addresses. In order to be useful, globally-unique/provider-independent addresses need to be routable. To be maximally useful, the routing boundaries for these addresses need to be set by administrators, not automatically enforced at specific routing protocol (or other) boundaries. Different sets of addresses should also be able to have different boundaries -- I might have one prefix for local traffic within the marketing department (folks who can use the fancy printer), one set that is local to the company, and one that is local to my customer/client extranet, for example. Unlike the current site-local proposals, this would work because the addresses are not ambiguous, and a longest-match selection would result in choosing an address in the same local prefix for communication with another local address in that prefix. But, how would that work with DNS? Good question -- I'm still working on an answer... :-). I understand the concern about "leaking" these addresses, but I think that some folks may misunderstand the impact of leaking at different levels. There are concerns associated with: - leaking these addresses in the DNS - leaking these addresses in upper-layer protocol packets - leaking these addresses in routing protocols - leaking packets to/from these addresses across intended boundaries. All of these issues are present for any sort of private addressing, and I don't think that the use of globally-unique local addresses will significantly complicate any of these issues. I think that we should stop calling these addresses "site-local", as that is prone to confusion. We would create a separate set of globally-unique/provider-independent (GUPI? Pronounced "guppy" or "goopy", depending on how much you like them? :-)) addresses for use as local addresses in Internet connected sites. We could still have site-local addresses (FECO::/10), which can be used for disconnected networks (and perhaps other cases -- we haven't really decided how widely to use them yet). If we limit them to disconnected sites, they could be treated exactly like global addresses by all nodes. If we also allow them to be used on connected networks (for intermittently attached networks, for example), we probably want to change the default address selection rules to prefer globals (of both sorts) over SLs. Margaret At 03:56 PM 11/23/2002 -0800, Michel Py wrote: >Christian, > >This is a more detailed version of what I proposed a month ago. I will >emphasize that we need something more than a MUST in an RFC to enforce >this: We need the site-local black hole and the site-local BGP route >discard to be *default* configuration in routers, and to be impossible >to remove by accident. This is no big thing to do for router vendors to >implement, we just need to reach consensus on it. > >Michel. > > >-----Original Message----- >From: Christian Huitema >Sent: Saturday, November 23, 2002 10:37 AM >To: ipng@sunroof.eng.sun.com >Subject: Enforcing unreachability of site local addresses > >One of the point in the discussion of the "globally unique" site local >addresses has been the discussion of their usage. In particular, if the >new addresses are globally unique, how do we prevent them from being >globally routed and creating a mess in the global routing tables; and, >on a related note, how do we make sure that they are actually local? > >The issue is clearly complex. There are legitimate scenarios in which >two sites might want to create some kind of backdoor connection >independent of any ISP connection, in a way similar to the various >"extranet" scenarios that are common today; it could also be used in a >merger situation. There are also illegitimate scenarios in which a >powerful customer would pressure an ISP to simply advertize their >globally unique /48. > >I believe that Bob Hinden provided the beginning of the answer when he >proposed that all routers would have a default black-hole for the site >local prefix. The implementation would be the following: > >1) In a local site, advertise the subnet routes in the IGP, possibly a >default route for the site, and a black-hole for the site local prefix. >This guarantees internal connectivity to the valid subnets, and >unreachability for all other sites. > >2) In an extranet scenario, import in the IGP an explicit route for the >"friendly" sites, and point it to the specific backdoor connecctions to >these sites. This will override the blackhole. > >3) At a border router, discard all BGP route that point to the site >local prefix or subsets of it. > >4) At a site border router or firewall, perform ingress filtering and >discard all externally sourced packets in which the source address >pretends to belong to the internal site. > >The combination of 1 and 3 presents a powerful disencentive against the >"leakage of routes" risk: a powerful customer might pressure a local >ISP, but that would be to no avail since the packets would be dropped by >the next hop. I believe that the combination of the four rules will >provide the desired locality benefits without having to resort to >ambiguity as an enforcement mechanism. > >-- 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 >-------------------------------------------------------------------- > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Nov 23 17:34:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1YRUu012898; Sat, 23 Nov 2002 17:34:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO1YQLc012897; Sat, 23 Nov 2002 17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1YNUu012890 for ; Sat, 23 Nov 2002 17:34:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO1YXMq004895 for ; Sat, 23 Nov 2002 17:34:34 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23696 for ; Sat, 23 Nov 2002 18:34:28 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA00678; Sat, 23 Nov 2002 17:34:06 -0800 (PST) Message-Id: <5.1.0.14.0.20021123202952.022158a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 23 Nov 2002 20:30:48 -0500 To: "Brian Zill" From: Margaret Wasserman Subject: RE: globally unique site local addresses 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 Brian, >The only class of solution which I think will truly make everyone happy >is to come up with an *aggregatable* globally unique address space that >still has properties 1 and 2. In other words, some sort of >provider-independent global address space. Properties 1 and 2 are much >easier when the aggregatable property is not required. The reason we're >in the state we are today is because this is a hard problem. I agree that this would be ideal, and I think that there are a couple of different proposals for how to do this that have been suggested to the multi6 WG. I have not reviewed them, yet, though to see how/if they would meet this need. 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 Nov 23 17:36:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1aKUu012930; Sat, 23 Nov 2002 17:36:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO1aKPc012927; Sat, 23 Nov 2002 17:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1aGUu012920 for ; Sat, 23 Nov 2002 17:36:16 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO1aRbB017606 for ; Sat, 23 Nov 2002 17:36:27 -0800 (PST) Received: from mail.nosense.org (62.cust4.nsw.dsl.ozemail.com.au [203.103.159.62]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01755 for ; Sat, 23 Nov 2002 17:36:20 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 78C293B39C; Sun, 24 Nov 2002 12:36:18 +1100 (EST) Subject: RE: Enforcing unreachability of site local addresses From: Mark Smith To: Margaret Wasserman Cc: Michel Py , Christian Huitema , ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.0.20021123194321.00b34e50@mail.windriver.com> References: <5.1.0.14.0.20021123194321.00b34e50@mail.windriver.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 24 Nov 2002 12:36:18 +1100 Message-Id: <1038101779.3603.82.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 2002-11-24 at 11:56, Margaret Wasserman wrote: > > All of these issues are present for any sort of private addressing, > and I don't think that the use of globally-unique local addresses > will significantly complicate any of these issues. > > I think that we should stop calling these addresses "site-local", > as that is prone to confusion. We would create a separate set > of globally-unique/provider-independent (GUPI? Pronounced > "guppy" or "goopy", depending on how much you like them? :-)) > addresses for use as local addresses in Internet connected sites. > Firstly, let me say that I'm a "guppy" type person :-) I agree renaming or creating a different allocation than fec0::/10 would be a good idea. However, I think it is important to ensure that the name implies that these GUPIs are only supposed to be used in an aquarium (of any size), rather than the deep blue ocean. Maybe they could be "internal, globally-unique, provider-independent" addresses or IGUPIs ("iguppy" or "igoopy"). (I'd prefer globally-unique, provider-independent, internal" address space - but GUPII is not as good sounding acronym :-) ). I think the DNS issues might be a bit simpler as well : 1) If the DNS returns an IGUPI address, the device assumes it can get to it, and lets ICMP dest unreachables or connection timeouts tell it otherwise. The device's IGUPI address would be used as the source address. 2) If the DNS returns a global address, the device assumes it can get to it, and lets ICMP dest unreachables or connection timeouts tell it otherwise. The device's global address would be used as the source address. As for the source address of the DNS request itself : 1) If the DNS server address is a global address, the device uses its global address as the source address. This would be typical for a residential user for example. 2) If the DNS server address is a IGUPI address, the device uses its IGUPI address as the source address. This would be typical for an enterprise / corporate user for example. A DNS server may have to return either a global or IGUPI address based on the source address of the request, for a single query. Still, with only two types of destination addresses, and IGUPIs probably preferred over globals, I don't think it is all that complicated. (sorry about using the IGUPI acronym I came up with in the above, just doing a test drive on it, seems to work ok, at least for me anyway :-) ). 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 23 17:44:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1iYUu013037; Sat, 23 Nov 2002 17:44:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO1iY1X013036; Sat, 23 Nov 2002 17:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1iTUu013026 for ; Sat, 23 Nov 2002 17:44:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO1idbB018378 for ; Sat, 23 Nov 2002 17:44:39 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA04199 for ; Sat, 23 Nov 2002 18:44:33 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA02501; Sat, 23 Nov 2002 17:44:09 -0800 (PST) Message-Id: <5.1.0.14.0.20021123203536.02221c30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 23 Nov 2002 20:37:26 -0500 To: Mika Liljeberg From: Margaret Wasserman Subject: Re: globally unique site local addresses Cc: ipng@sunroof.eng.sun.com In-Reply-To: <1038046215.16052.12.camel@devil> References: <3DDF30F6.3010404@kolumbus.fi> <2B81403386729140A3A899A8B39B0464010BF5@server2000> <3DDF30F6.3010404@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mika, >This means that what we really need a site-local prefix >autoconfiguration specification similar to the link-local address >autoconfiguration. There was a Zero Configuration (zerouter) BOF held in Atlanta that dealt with the subject of how prefixes can be automatically delegated to routers. I agree that it is something we need to enable plug-n-play multi-subnet networking. And, even though we're not currently planning to pursue this in IPv6, there may be a zerouter WG coming that will deal with 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 Nov 23 17:44:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1iYUu013040; Sat, 23 Nov 2002 17:44:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO1iYOR013038; Sat, 23 Nov 2002 17:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1iSUu013022 for ; Sat, 23 Nov 2002 17:44:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO1icMq005819 for ; Sat, 23 Nov 2002 17:44:38 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19218 for ; Sat, 23 Nov 2002 18:44:33 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA02495; Sat, 23 Nov 2002 17:44:07 -0800 (PST) Message-Id: <5.1.0.14.0.20021123203313.0165e820@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 23 Nov 2002 20:35:12 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: globally unique site local addresses Cc: "Mark Smith" , In-Reply-To: <2B81403386729140A3A899A8B39B04640BD428@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >There is room for both models at the same, and "good enough" is not >going to be good enough for everybody. I would need to see a very compelling case for why two types of globally-unique/provider-independent addressing are needed before I would like to see two models. I think that one of the benefits of globally-unique/provider- independent addresses over site-locals is that it is possible to tell (when one is leaked in any of the possible ways) exactly where the address came from... This would, of course, work best if the addresses were actually unique, rather than mostly-unique. 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 Nov 23 17:51:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1pqUu013195; Sat, 23 Nov 2002 17:51:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO1pqFk013194; Sat, 23 Nov 2002 17:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1pmUu013184 for ; Sat, 23 Nov 2002 17:51:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO1pwMq006704 for ; Sat, 23 Nov 2002 17:51:59 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06071 for ; Sat, 23 Nov 2002 18:51:53 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA04249; Sat, 23 Nov 2002 17:51:16 -0800 (PST) Message-Id: <5.1.0.14.0.20021123204326.022cab28@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 23 Nov 2002 20:45:29 -0500 To: Pekka Savola From: Margaret Wasserman Subject: Re: "unique enough" [RE: globally unique site local addresses] Cc: Michel Py , Christian Huitema , In-Reply-To: References: <2B81403386729140A3A899A8B39B046405E4A1@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >FEC0::/10 has about 38 usable bits there. That's enough for "unique >enough". No need for even that. Let's assume /16 - /40 -- 24 bits would >be enough too. By birthday paradox, even in that case, collisions should >only be probable if you communicate thousands of different sites >simultaneously and there are referrals and third party interconnections. I don't think that you can, or should put the new globally-unique, provider independent address space inside the FECO::/10 allocation. As far as I know, we still plan to allow the FECO::/10 prefix to be used for disconnected sites, and perhaps other "moderate" usage. 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 Nov 23 17:52:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1q1Uu013212; Sat, 23 Nov 2002 17:52:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO1q1Fx013211; Sat, 23 Nov 2002 17:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1prUu013197 for ; Sat, 23 Nov 2002 17:51:53 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO1q3Mq006711 for ; Sat, 23 Nov 2002 17:52:03 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20862 for ; Sat, 23 Nov 2002 18:51:58 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA04267; Sat, 23 Nov 2002 17:51:19 -0800 (PST) Message-Id: <5.1.0.14.0.20021123204557.0222fcb0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 23 Nov 2002 20:46:46 -0500 To: Arien Vijn From: Margaret Wasserman Subject: Re: "unique enough" [RE: globally unique site local addresses] Cc: Pekka Savola , Jari Arkko , Christian Huitema , ipng In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >48 bits MAC is not globally unique (found that out the hard way). But >hashing several MACs on the links of a disconnected sites toghere with a >timestamp will do I guess. It is actually my (weak) understanding that taking more inputs does not actually result in more "uniqueness", at least for random number generation. Does anyone know how that works for hashing? 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 Nov 23 17:52:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1q4Uu013215; Sat, 23 Nov 2002 17:52:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO1q3El013214; Sat, 23 Nov 2002 17:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO1ptUu013204 for ; Sat, 23 Nov 2002 17:51:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO1q5bB019107 for ; Sat, 23 Nov 2002 17:52:06 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06093 for ; Sat, 23 Nov 2002 18:51:59 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA04278; Sat, 23 Nov 2002 17:51:21 -0800 (PST) Message-Id: <5.1.0.14.0.20021123204700.02221ab8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 23 Nov 2002 20:50:01 -0500 To: Kurt Erik Lindqvist From: Margaret Wasserman Subject: Re: "unique enough" [RE: globally unique site local addresses] Cc: "Michel Py" , "Pekka Savola" , "Christian Huitema" , In-Reply-To: References: <2B81403386729140A3A899A8B39B046405E4A4@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Uhm, if they are truely unique, the only difference to global addresses is >that they won't be routed - right? Now, what is the difference between >that and using global unicast address space that you do not announce? Virtually nothing, except that this address space would be provider-independent, so you would not have to renumber, etc. when you change ISPs. Also, your ISP would not be obligated to route it globally and would probably filter it. I'm actually in favor of a globally-unique/provider-independent address space that is routable, with borders of the address space administratively determined and enforced via filtering rules in routers/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 Sat Nov 23 18:12:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO2CiUu013556; Sat, 23 Nov 2002 18:12:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO2CiEp013555; Sat, 23 Nov 2002 18:12: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO2CfUu013548 for ; Sat, 23 Nov 2002 18:12:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO2CpbB021420 for ; Sat, 23 Nov 2002 18:12:51 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02498 for ; Sat, 23 Nov 2002 19:12:45 -0700 (MST) Subject: RE: globally unique site local addresses Date: Sat, 23 Nov 2002 18:12:46 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4B5@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message Thread-Index: AcKTUCw62x6w4Kq3QWe+x7gP0nYgNgADf+YQ From: "Michel Py" To: "Mika Liljeberg" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAO2CfUu013549 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mika Liljeberg > Still, I think that there is something to be said for > being able to put together a routed site-local network > with the same level of convenience as sticking together > a bunch of switches. This sounds like a terrible idea. Site-locals are not for everyone, and we certainly don't want to encourage their use by making it plug and play. Site-locals are for use in a certain number of specific situations, by networks architects that have a design and *not* by people that can barely figure out how to get the router out the box. We MUST NOT encourage the use of site-locals, whether they are globally unique 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 Sat Nov 23 18:17:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO2HrUu013617; Sat, 23 Nov 2002 18:17:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO2HrQe013616; Sat, 23 Nov 2002 18:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO2HmUu013609 for ; Sat, 23 Nov 2002 18:17:50 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO2HwMq009410 for ; Sat, 23 Nov 2002 18:17:58 -0800 (PST) Received: from ss10.danlan.com (ss10.danlan.com [199.33.144.62]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01375 for ; Sat, 23 Nov 2002 19:17:52 -0700 (MST) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id VAA26427 for ipng@sunroof.eng.sun.com; Sat, 23 Nov 2002 21:17:51 -0500 (EST) Date: Sat, 23 Nov 2002 21:17:51 -0500 (EST) From: Dan Lanciani Message-Id: <200211240217.VAA26427@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: Enforcing unreachability of site local addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: |I think that we should stop calling these addresses "site-local", |as that is prone to confusion. We would create a separate set |of globally-unique/provider-independent (GUPI? Pronounced |"guppy" or "goopy", depending on how much you like them? :-)) |addresses for use as local addresses in Internet connected sites. | |We could still have site-local addresses (FECO::/10), which can be |used for disconnected networks (and perhaps other cases -- we |haven't really decided how widely to use them yet). If we limit |them to disconnected sites, they could be treated exactly like |global addresses by all nodes. If we also allow them to be |used on connected networks (for intermittently attached networks, |for example), we probably want to change the default address |selection rules to prefer globals (of both sorts) over SLs. I trust that it goes without saying that these GUPIs will have to actually be available *before* this change to the default address selection rules is made. 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 Nov 23 18:23:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO2N3Uu013704; Sat, 23 Nov 2002 18:23:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO2N3H3013703; Sat, 23 Nov 2002 18:23: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO2N0Uu013696 for ; Sat, 23 Nov 2002 18:23:00 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO2MjMq013662 for ; Sat, 23 Nov 2002 18:23:10 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27975 for ; Sat, 23 Nov 2002 19:22:39 -0700 (MST) Subject: RE: Enforcing unreachability of site local addresses Date: Sat, 23 Nov 2002 18:22:39 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4B4@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enforcing unreachability of site local addresses X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message Thread-Index: AcKTVHny0Xg3miruTg6NjPGOGdR/JAAB869Q From: "Michel Py" To: "Margaret Wasserman" Cc: "Christian Huitema" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAO2N0Uu013697 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > Margaret Wasserman wrote: > The IPv6 WG putting a "MUST" in a spec does not put > code in a router. That is an interesting point of view, for sure. It has worked so far, why would this change? > There are already implementations of IPv6 that do > not "black-hole" this set of TBD globally-unique, > provider-independent addresses, so our solution must > not depend on all routers black-holing packets > to/from these addresses. Fortunately these will have their software updated many times in the next few years, and the solution does not depend on _all_ routers. The success of the solution depends on the comfort level of network administrators in assessing that the _majority_ of routers implement the recommendation. > In order to be useful, globally-unique/provider-independent > addresses need to be routable. To be maximally useful, the > routing boundaries for these addresses need to be set by > administrators, not automatically enforced at specific > routing protocol (or other) boundaries. I used *default* in my posting, obviously I should have used DEFAULT instead. The subject of this thread is "Enforcing unreachability of site local addresses", not creating a new PI space. 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 Nov 23 18:31:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO2V4Uu013812; Sat, 23 Nov 2002 18:31:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO2V4qO013810; Sat, 23 Nov 2002 18:31: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO2V1Uu013803 for ; Sat, 23 Nov 2002 18:31:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO2VBMq014701 for ; Sat, 23 Nov 2002 18:31:11 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04539 for ; Sat, 23 Nov 2002 19:31:05 -0700 (MST) Subject: RE: globally unique site local addresses Date: Sat, 23 Nov 2002 18:31:06 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4B6@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message Thread-Index: AcKTWyuADibXrZ8NQK6L8ObJ0dPSEQABV7DQ 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 gAO2V1Uu013804 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, >> Michel Py wrote: >> There is room for both models at the same, and "good >> enough" is not going to be good enough for everybody. > Margaret Wasserman wrote: > I would need to see a very compelling case for why two > types of globally-unique/provider-independent addressing > are needed before I would like to see two models. Reaching consensus. Pekka's model has generated some positive comments. > Margaret Wasserman wrote: > I think that one of the benefits of globally-unique/ > provider-independent addresses over site-locals is that > it is possible to tell (when one is leaked in any of the > possible ways exactly where the address came from... > This would, of course, work best if the addresses were > actually unique, rather than mostly-unique. Agreed, identifying the source of the leak also requires that these addresses are registered somewhere (which is the model I proposed) and not randomly generated. 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 Nov 23 19:14:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO3EsUu013979; Sat, 23 Nov 2002 19:14:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO3Er2V013978; Sat, 23 Nov 2002 19:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO3EoUu013971; Sat, 23 Nov 2002 19:14:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO3F0Mq018646; Sat, 23 Nov 2002 19:15:00 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA09814; Sat, 23 Nov 2002 20:14:55 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 7D8776966; Sat, 23 Nov 2002 22:14:54 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 23 Nov 2002 22:14:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for MIPv6 APIs to switch default source address selection Date: Sat, 23 Nov 2002 22:14:53 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9C2F@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for MIPv6 APIs to switch default source address selection Thread-Index: AcKRbHRBYx+BX/ZfSQCBfv+c41WXkgB+wYpA From: "Bound, Jim" To: "Francis Dupont" , "Samita Chakrabarti" Cc: , , X-OriginalArrivalTime: 24 Nov 2002 03:14:54.0426 (UTC) FILETIME=[A8E48BA0:01C29367] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAO3EoUv013972 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This API should be its own spec and reference other API docs. This way the focus of the work would be MIPv6 specific and also not slow down other API docs in process. I also think that Francis is correct on the COA issues for src addr selection. /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Thursday, November 21, 2002 9:40 AM > To: Samita Chakrabarti > Cc: mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com; > samita.chakrabarti@Sun.COM > Subject: Re: Proposal for MIPv6 APIs to switch default source > address selection > > > In your previous mail you wrote: > > I am looking into possible MIPv6 APIs as an extension to > IPv6 Adv-API > document. The following requirements in MIPv6 spec > indicates that there > is a need for Socket API which will allow the MIPv6 applications to > choose COA as mobile node's source address... > > => the problem of this API is that it is not useful because > nobody wants to change all applications to use it. So we need > also a way to change the choice (or better, to choose in a > clever way, for instance using the "distance" between the CoA > prefix and the destination address) from the context of > applications. I suggest this many times but it was rejected > by address selection document author as out of the scope of > the document... (this is one of the reasons I still believe > to put the document on the standard track is an error). > > Thanks > > Francis.Dupont@enst-bretagne.fr > > PS: we have to do the same thing for every rules not using > the preference table. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 23 19:16:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO3GZUu014012; Sat, 23 Nov 2002 19:16:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO3GZHg014011; Sat, 23 Nov 2002 19:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO3GWUu014004 for ; Sat, 23 Nov 2002 19:16:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO3GgbB028395 for ; Sat, 23 Nov 2002 19:16:42 -0800 (PST) Received: from mail.nosense.org (62.cust4.nsw.dsl.ozemail.com.au [203.103.159.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA28540 for ; Sat, 23 Nov 2002 20:16:35 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 96E243B39C; Sun, 24 Nov 2002 14:16:30 +1100 (EST) Subject: RE: globally unique site local addresses From: Mark Smith To: Michel Py Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com In-Reply-To: <2B81403386729140A3A899A8B39B046405E4B6@server2000> References: <2B81403386729140A3A899A8B39B046405E4B6@server2000> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 24 Nov 2002 14:16:30 +1100 Message-Id: <1038107794.1458.105.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 2002-11-24 at 13:31, Michel Py wrote: > Margaret, > > >> Michel Py wrote: > >> There is room for both models at the same, and "good > >> enough" is not going to be good enough for everybody. > > > Margaret Wasserman wrote: > > I would need to see a very compelling case for why two > > types of globally-unique/provider-independent addressing > > are needed before I would like to see two models. > > Reaching consensus. Pekka's model has generated some positive comments. > > > > Margaret Wasserman wrote: > > I think that one of the benefits of globally-unique/ > > provider-independent addresses over site-locals is that > > it is possible to tell (when one is leaked in any of the > > possible ways exactly where the address came from... > > This would, of course, work best if the addresses were > > actually unique, rather than mostly-unique. > > Agreed, identifying the source of the leak also requires that these > addresses are registered somewhere (which is the model I proposed) and > not randomly generated. > I don't think it necessarily requires registration - usually a traceroute toward the leaked route will give a good indication where it is coming from. Alternatively, origin AS numbers are also a good hint. Maybe leaked routes in the Internet eg 10/8 aren't so much that common, it's just that they are very prominent when they occur, because you know that you shouldn't be seeing them. 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 23 19:17:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO3HtUu014055; Sat, 23 Nov 2002 19:17:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO3HtdZ014054; Sat, 23 Nov 2002 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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO3HpUu014047; Sat, 23 Nov 2002 19:17:51 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO3I1bB028651; Sat, 23 Nov 2002 19:18:01 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA10517; Sat, 23 Nov 2002 20:17:55 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C65B99DAD; Sat, 23 Nov 2002 22:17:54 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 23 Nov 2002 22:17:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for MIPv6 APIs to switch default source address selection Date: Sat, 23 Nov 2002 22:17:54 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9C30@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for MIPv6 APIs to switch default source address selection Thread-Index: AcKRbtUFHnYcwjLiS8qB8l+V4mK1RAB+QvoQ From: "Bound, Jim" To: "Alper E. YEGIN" , "Samita Chakrabarti" , , Cc: X-OriginalArrivalTime: 24 Nov 2002 03:17:54.0495 (UTC) FILETIME=[1438E4F0:01C29368] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAO3HpUv014048 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alper, This is a good architecture for an API. But if Samita and others are willing to build an API spec for Mobile IP in the IETF using base BSD sockets that is a good idea. As far as your comment about src addr selection I don't buy it without seeing real code. That is why we need this api draft. /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Thursday, November 21, 2002 9:56 AM > To: Samita Chakrabarti; mobile-ip@sunroof.eng.sun.com; > ipng@sunroof.eng.sun.com > Cc: samita.chakrabarti@Sun.COM > Subject: Re: Proposal for MIPv6 APIs to switch default source > address selection > > > > > > > I am looking into possible MIPv6 APIs as an extension to > IPv6 Adv-API > > document. The following requirements in MIPv6 spec indicates that > > there is a need for Socket API which will allow the MIPv6 > applications > > to choose COA as mobile node's source address (in a visited > network), > > while default > > address selection draft prefers home address as the default source > > address > > (section 5 and 6 rule 4). The MIPV6 API should also take care of > > choosing > > temporary address and non-temporary address from the > application level. > > Hi Samita, > > Please see our Mobile IP API draft: > > http://www.ietf.org/internet-drafts/draft-yokote-mobileip-api-01.txt > > It allows the user of the API to determine home addresses and > the corresponding care-of addresses used on the host. Than, > it's the application's choice to pick one of them. It can > make an appropriate decision by using this knowledge. > > I think this selection logic should reside in the > application, not below. So, I'm not sure if this really > relates to draft-ietf-ipv6-default-addr-select draft. > > alper > > > > > Also, there is a need to choose link-local or site-local address as > > source address (depending on the scope) for the MN while > visiting (see > > below). > > > > My question is, if anybody in IPv6 working group is > currently working > > on such API for default address selection draft ? > > > > If not, I propose to add these APIs to the MIPv6 Advanced API > > document, as they are quite Mobile IP specific in usage. > > > > -Samita > > > > -------------------------------------------------------------------- > > > > > > > > Mobile IPv6 draft 19 Section 11.3.1 states, > > > > The mobile node MAY choose to directly use one of its care-of > > addresses as the source of the packet, not requiring the use > > of a Home Address option in the packet. This is particularly > > useful for short-term communication that may easily > be retried > > if it fails. An example of this type of communication might > > be DNS queries sent by the mobile node [27, 28]. Using the > > mobile node's care-of address as the source for such > queries will > > generally have a lower overhead than using the mobile node's > > home address, since no extra options need be used in either > > the query or its reply. Such packets can be routed normally, > > directly between their source and destination without relying > > on Mobile IPv6. If application running on the > mobile node has > > no particular knowledge that the communication being > sent fits > > within this general type of communication, however, > the mobile > > node SHOULD NOT use its care-of address as the source of the > > packet in this way. > > > > : : : > > > > While not at its home link, the mobile node MUST NOT > use its home > > address (or the home address destination option) in Neighbor > > Discovery messages on the visited link. The mobile node also > > MUST NOT use its home address when communicating > with link-local > > or site-local peers on the visited link, if the > scope of the home > > address is larger than the scope of the peer's address. > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 23 19:23:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO3NfUu014188; Sat, 23 Nov 2002 19:23:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO3Ne3V014187; Sat, 23 Nov 2002 19:23: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO3NbUu014180; Sat, 23 Nov 2002 19:23:37 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO3NlbB029293; Sat, 23 Nov 2002 19:23:47 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27408; Sat, 23 Nov 2002 19:23:42 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 8BFCE2749; Sat, 23 Nov 2002 22:23:41 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 23 Nov 2002 22:23:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for MIPv6 APIs to switch default source address selection Date: Sat, 23 Nov 2002 22:23:40 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9C31@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for MIPv6 APIs to switch default source address selection Thread-Index: AcKRjmzbCF+bm7jCTi2nc1juDBSTfQB2g0uw From: "Bound, Jim" To: "Alper E. YEGIN" , "Samita Chakrabarti" Cc: , X-OriginalArrivalTime: 24 Nov 2002 03:23:41.0379 (UTC) FILETIME=[E2FB3130:01C29368] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAO3NbUv014181 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alper, I agree with you. Src addr sel will address the common case but not the exception and as the draft states it should never overrrule the choice of the application. I can imagine as part of the mobile ip binding lookup additional data structure entries as part of the mobile ipv6 kernel parts. In this manner we would not have to do this in user space and routers could do it as part of its fast path esp for HA. If Samita moves forward with this work we could do all this mostly with socket options too to direct the kernel. And leave the src addr selection of mobile to implementation as should have IPv6 WG. /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Thursday, November 21, 2002 1:33 PM > To: Samita Chakrabarti > Cc: ipng@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > Subject: Re: Proposal for MIPv6 APIs to switch default source > address selection > > > > Hi Samita, > > > I did take a look at the draft that you folks have for mobile IP > > applications. > > > > That draft gives a general overview of mobile application > usage, but I > > am addressing a different scope (which is more equivalent > to having an > > extension > > to IPv6 advanced Socket API document for Mobile IP). The > mobileip socket > > applications > > will use those Advanced socket APIs(which I am proposing) > to change to > > default behavior in the kernel. > > An alternative approach could be: If the application cares > about the source address, it can use the Mobile IP API to > figure out which ones are home address, which ones are > care-of address, and than explicitly "bind" the socket to the > desired address. IMO, this would also satisfy the needs of > the Mobile IPv6 mobile node. > > alper > > > > Moreover, a socket api to switch the default source address > selection > > would be useful in general(I am happy to see that in Bob Hinden's > > slides in the ipng > > meeting today as well). > > > > draft-yokote-mobileip-api-01.txt, IMO, provides guideline for the > > generic MobileIP specific application level APIs, which is in a > > different scope than Advanced socket APIs > > that are perceived from the current rfc2292bis. > > > > > > -Samita > > > > > > Also, there is a need to choose link-local or > site-local address > > > > as source address (depending on the scope) for the MN while > > > > visiting (see > below). > > > > > > > > My question is, if anybody in IPv6 working group is currently > > > > working > on > > > > such > > > > API for default address selection draft ? > > > > > > > > If not, I propose to add these APIs to the MIPv6 Advanced API > document, > > > > as they are quite Mobile IP specific in usage. > > > > > > > > -Samita > > > > > > > > > ------------------------------------------------------------------ > > > > -- > > > > > > > > > > > > > > > > Mobile IPv6 draft 19 Section 11.3.1 states, > > > > > > > > The mobile node MAY choose to directly use one > of its care-of > > > > addresses as the source of the packet, not > requiring the use > > > > of a Home Address option in the packet. This is > particularly > > > > useful for short-term communication that may > easily be retried > > > > if it fails. An example of this type of > communication might > > > > be DNS queries sent by the mobile node [27, 28]. > Using the > > > > mobile node's care-of address as the source for such > > > > queries > will > > > > generally have a lower overhead than using the > mobile node's > > > > home address, since no extra options need be > used in either > > > > the query or its reply. Such packets can be > routed normally, > > > > directly between their source and destination > without relying > > > > on Mobile IPv6. If application running on the > mobile node has > > > > no particular knowledge that the communication > being sent fits > > > > within this general type of communication, > however, the mobile > > > > node SHOULD NOT use its care-of address as the > source of the > > > > packet in this way. > > > > > > > > : : : > > > > > > > > While not at its home link, the mobile node MUST NOT use > > > > its > home > > > > address (or the home address destination option) > in Neighbor > > > > Discovery messages on the visited link. The > mobile node also > > > > MUST NOT use its home address when communicating with > link-local > > > > or site-local peers on the visited link, if the scope of > > > > the > home > > > > address is larger than the scope of the peer's address. > > > > > ------------------------------------------------------------------ > > > > -- > > > > IETF IPng Working Group Mailing List > > > > IPng Home Page: > http://playground.sun.com/ipng > > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Sat Nov 23 19:26:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO3QKUu014269; Sat, 23 Nov 2002 19:26:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO3QKOE014268; Sat, 23 Nov 2002 19:26: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO3QHUu014261; Sat, 23 Nov 2002 19:26:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO3QRMq019811; Sat, 23 Nov 2002 19:26:27 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12568; Sat, 23 Nov 2002 20:26:21 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 752FF4EAE; Sat, 23 Nov 2002 22:26:21 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 23 Nov 2002 22:26:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection Date: Sat, 23 Nov 2002 22:26:08 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9C32@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection Thread-Index: AcKRtH//lXGBBVlMQoi5DmqHfbtXzQBtJ7tA From: "Bound, Jim" To: "Francis Dupont" , "Alper E. YEGIN" Cc: "Samita Chakrabarti" , , X-OriginalArrivalTime: 24 Nov 2002 03:26:21.0395 (UTC) FILETIME=[425BB230:01C29369] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAO3QHUv014262 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, What you did would work with what I stated too. After the kernel gets done the getsockname could send back all data but I think we would need a new api and options to the kernel? /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Thursday, November 21, 2002 6:15 PM > To: Alper E. YEGIN > Cc: Samita Chakrabarti; ipng@sunroof.eng.sun.com; > mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to > switch default source address selection > > > In your previous mail you wrote: > > An alternative approach could be: If the application cares about > the source address, it can use the Mobile IP API to figure > out which > ones are home address, which ones are care-of address, and than > explicitly "bind" the socket to the desired address. IMO, > this would > also satisfy the needs of the Mobile IPv6 mobile node. > > => this is similar to what I implemented in the past. > But a function giving the list of addresses with status is > not enough, the best is to give the home address and the > care-of address for a destination. As first info is > getsockname() for bound sockets, I added a clone of > getsockname() which returns the real source address after > MIPv6 processing. Note this doesn't solve the need of a > control for smarter choice between Co@/H@. I proposed some > and implemented two: use always the H@ and use it but a Co@ > when the destination is in the same link then a Co@. They > were global (still better than none :-). > > Thanks > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 23 19:32:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO3W2Uu014409; Sat, 23 Nov 2002 19:32:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO3W2VE014408; Sat, 23 Nov 2002 19:32:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO3VwUu014398; Sat, 23 Nov 2002 19:31:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO3W8bB000272; Sat, 23 Nov 2002 19:32:08 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21514; Sat, 23 Nov 2002 20:32:02 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 7B5D09CEB; Sat, 23 Nov 2002 22:30:40 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 23 Nov 2002 22:30:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection Date: Sat, 23 Nov 2002 22:30:39 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9C34@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection Thread-Index: AcKR0q3JrnJGYBikRVeC1iZtGcVkbgBlsvOQ From: "Bound, Jim" To: "Alper E. YEGIN" , "Francis Dupont" Cc: "Samita Chakrabarti" , , X-OriginalArrivalTime: 24 Nov 2002 03:30:40.0270 (UTC) FILETIME=[DCA8E2E0:01C29369] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAO3VxUv014399 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alper, OK I was behind you folks are going where I would go. I would assume bind-update will update the correct topological one to use in the kernel that way the app does not have to be smart unless it wants too using a new api as you suggest. This way apps don't have to change as we begin to deploy mipv6. I would suggest strongly we just have a good api draft and leave the rest to implementors and not try to parse this in the ietf and we all are not going to agree how we do stuff in our kernels anyway and we don't get into a 2 year debate like src addr sel. A simple api ext doc would be great. But not part of the advanced api. We need to ship the base and advanced apis now. /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Thursday, November 21, 2002 9:49 PM > To: Francis Dupont > Cc: Samita Chakrabarti; ipng@sunroof.eng.sun.com; > mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to > switch default source address selection > > > > > > In your previous mail you wrote: > > > > An alternative approach could be: If the application cares about > > the source address, it can use the Mobile IP API to > figure out which > > ones are home address, which ones are care-of address, and than > > explicitly "bind" the socket to the desired address. > IMO, this would > > also satisfy the needs of the Mobile IPv6 mobile node. > > > > => this is similar to what I implemented in the past. > > But a function giving the list of addresses with status is > not enough, > > the best is to give the home address and the care-of address for a > > destination. > > I see. When the mobile node has more than one pair of > home_address-care_of_address, then it won't really know which > one to pick. So, maybe, instead of exporting all this > information to the apps and giving them the control, it might > be better > to enable the app to say "bind this socket to any address, > preferably topologically correct (i.e., a CoA, or home > address when at home)". I suspect this is what Samita had in > her mind.. > > > As first info is getsockname() for bound sockets, > > I added a clone of getsockname() which returns the real > source address > > after MIPv6 processing. > > Or, don't change the getsockname(), but instead call > mip_get_one_mobile_node() afterwards to identify if the > address is bound to a care-of address. Note that this binding > can dynamically any time, and subsequent > mip_get_one_mobile_node() calls are sufficient to capture the changes. > > alper > > > Note this doesn't solve the need of a control for smarter choice > > between Co@/H@. I proposed some and implemented two: use > always the H@ > > and use it but a Co@ when the destination is in the same > link then a > > Co@. They were global (still better than none :-). > > > > Thanks > > > > Francis.Dupont@enst-bretagne.fr > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 24 00:29:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO8T0Uu015185; Sun, 24 Nov 2002 00:29:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO8SxH0015184; Sun, 24 Nov 2002 00:28:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO8SuUu015177 for ; Sun, 24 Nov 2002 00:28:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO8T6Mq020181 for ; Sun, 24 Nov 2002 00:29:07 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01597 for ; Sun, 24 Nov 2002 01:29:01 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id AAA29024; Sun, 24 Nov 2002 00:28:35 -0800 (PST) Message-Id: <5.1.0.14.0.20021124032421.00b34e50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 24 Nov 2002 03:25:46 -0500 To: Mark Smith From: Margaret Wasserman Subject: RE: globally unique site local addresses Cc: Michel Py , ipng@sunroof.eng.sun.com In-Reply-To: <1038107794.1458.105.camel@dupy> References: <2B81403386729140A3A899A8B39B046405E4B6@server2000> <2B81403386729140A3A899A8B39B046405E4B6@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I don't think it necessarily requires registration - usually a >traceroute toward the leaked route will give a good indication where it >is coming from. This assumes that the only type of leaking that you are concerned about is route leaking. It would also be good, in many cases, to be able to understand who owns an address that is leaked by other means (i.e. network management protocols). 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 Nov 24 01:40:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO9eIUu015436; Sun, 24 Nov 2002 01:40:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAO9eIDX015435; Sun, 24 Nov 2002 01:40: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAO9eFUu015428 for ; Sun, 24 Nov 2002 01:40:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAO9ePMq026262 for ; Sun, 24 Nov 2002 01:40:26 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26786 for ; Sun, 24 Nov 2002 02:40:19 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAO9e7x27172; Sun, 24 Nov 2002 11:40:07 +0200 Date: Sun, 24 Nov 2002 11:40:07 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: Michel Py , Christian Huitema , Subject: Re: "unique enough" [RE: globally unique site local addresses] In-Reply-To: <5.1.0.14.0.20021123204326.022cab28@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 Sat, 23 Nov 2002, Margaret Wasserman wrote: > >FEC0::/10 has about 38 usable bits there. That's enough for "unique > >enough". No need for even that. Let's assume /16 - /40 -- 24 bits would > >be enough too. By birthday paradox, even in that case, collisions should > >only be probable if you communicate thousands of different sites > >simultaneously and there are referrals and third party interconnections. > > I don't think that you can, or should put the new globally-unique, > provider independent address space inside the FECO::/10 allocation. > As far as I know, we still plan to allow the FECO::/10 prefix to be > used for disconnected sites, and perhaps other "moderate" usage. Oh? I am not sure about goals what we're actually trying to solve. IMO, putting some randomness in the fec0::/10 solves nearly all, or all, the problems with current _site-local_ addresses. (I'm not sure because the requirements list doesn't exist yet :-). Naturally, people will want to have truly globally unique, routable, provider-independent, etc. addresses. But there is no free lunch. Have we been through this road yet? Yes, I believe so, with no apparent success. Let's define our scope better than that and leave the latter for e.g. multi6 to consider (e.g. geographically automatically allocated PI space). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 24 02:08:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOA8mUu015592; Sun, 24 Nov 2002 02:08:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAOA8m71015591; Sun, 24 Nov 2002 02:08: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOA8iUu015584 for ; Sun, 24 Nov 2002 02:08:44 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAOA8tMq028229 for ; Sun, 24 Nov 2002 02:08:55 -0800 (PST) Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00536 for ; Sun, 24 Nov 2002 02:08:49 -0800 (PST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.6/8.12.6/Debian-8) with ESMTP id gAOA8ghB008727; Sun, 24 Nov 2002 12:08:43 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.6/8.12.6/Debian-8) id gAOA8eqC008726; Sun, 24 Nov 2002 12:08:40 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: globally unique site local addresses From: Mika Liljeberg To: Michel Py Cc: ipng@sunroof.eng.sun.com In-Reply-To: <2B81403386729140A3A899A8B39B046405E4B5@server2000> References: <2B81403386729140A3A899A8B39B046405E4B5@server2000> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1038132519.4649.30.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 24 Nov 2002 12:08:39 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 2002-11-24 at 04:12, Michel Py wrote: > This sounds like a terrible idea. Site-locals are not for everyone, and > we certainly don't want to encourage their use by making it plug and > play. Agreed, for site-locals alone it is a terrible idea. Philosophically I'm with you, although I tend to be somewhat cynical about it (and I must confess to playing the Devil's advocate a little with my proposal). Site locals are here and I'm convinced that people will find all kinds of uses for them, whenever they are convenient to use or meet a specific need that globally routable addresses don't. It's not very fruitful to concentrate on discouraging the use of site-locals. Rather, the focus should be on eliminating the reasons that make people resort to them. Plug-n-play router configuration is a worthy goal in itself (and I'm not only talking about site-locals now), since with IPv6 "people that can barely figure out how to get the router out the box" suddenly find themselves with plenty of address space and are likely to be setting up networks of their own. I hope the zerouter BOF comes to something. We need a good solution for this. 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 Nov 24 06:10:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOEAGUu016041; Sun, 24 Nov 2002 06:10:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAOEAFJw016040; Sun, 24 Nov 2002 06:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOEACUu016033 for ; Sun, 24 Nov 2002 06:10:13 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAOEAMMq005590 for ; Sun, 24 Nov 2002 06:10:22 -0800 (PST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20596 for ; Sun, 24 Nov 2002 06:10:16 -0800 (PST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAOE9e927500 for ; Sun, 24 Nov 2002 16:09:41 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 24 Nov 2002 16:10:15 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 24 Nov 2002 16:10:15 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 24 Nov 2002 16:10:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: globally unique site local addresses Date: Sun, 24 Nov 2002 16:10:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses Thread-Index: AcKR3Ml3aNtkck2XR/mIr4f0lfikOwBXrsig To: , X-OriginalArrivalTime: 24 Nov 2002 14:10:14.0522 (UTC) FILETIME=[357F0DA0:01C293C3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAOEADUu016034 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Dan, > |There could be another model, where the end-site would request the block > |to one of their ISPs and the ISP access the IANA or RIR web site on > |behalf of the customer. > > Let's not encourage ISPs to be in the address allocation business any more > than necessary. :) Besides, what if you don't have an ISP? I agree - I think that whatever we do on this topic we MUST NOT assume anything like ISP intervention. This is key for home, mobile & adhoc networks where these kinds of addresses are potentially useful. best regards, 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 Nov 24 10:45:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOIjhUu016690; Sun, 24 Nov 2002 10:45:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAOIjgNU016689; Sun, 24 Nov 2002 10:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOIjdUu016682 for ; Sun, 24 Nov 2002 10:45:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAOIjnMq006367 for ; Sun, 24 Nov 2002 10:45:49 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09539 for ; Sun, 24 Nov 2002 11:45:43 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id 886801C; Sun, 24 Nov 2002 20:52:40 +0200 (EET) Message-ID: <3DE11E4F.9030702@nomadiclab.com> Date: Sun, 24 Nov 2002 20:45:35 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman Cc: ipng Subject: Re: "unique enough" [RE: globally unique site local addresses] References: <5.1.0.14.0.20021123204557.0222fcb0@mail.windriver.com> In-Reply-To: <5.1.0.14.0.20021123204557.0222fcb0@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, > It is actually my (weak) understanding that taking more inputs > does not actually result in more "uniqueness", at least for > random number generation. > > Does anyone know how that works for hashing? AFAIK, the bigest problem with random number generation is non-random seed data. Adding more sources of randomness helps in that. In this case, relying in just one MAC address as a seed for a hash function is probably not good enough, but e.g. taking the MAC address *and* the machine's current idea of date & time in millisecond precision probably is. As another issue, just picking a cryptographically strong hash function and using it as a random number generator is typically *not* good enough for many uses of random numbers, but IMHO it is OK for generating these kinds of identifiers. Thus, if we want a method for automatically generating prefixes for globally unique enough site local addresses, a decent method might be sha1( current date and time in ms | interface MAC ) where the date & time would be a 64 bit integer and the MAC address either 48 or 64 bit MAC, the 48 bit version enlarged to 64 bits. Note that there is no need for time synchronization. If there are more implementations of MD5 than SHA-1, MD5 would be good here, too. In the case of a collision, the algorithm can be simply rerun. The new result will be completely different. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 24 11:01:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOJ1PUu016733; Sun, 24 Nov 2002 11:01:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAOJ1PEH016732; Sun, 24 Nov 2002 11:01: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOJ1LUu016725 for ; Sun, 24 Nov 2002 11:01:21 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAOJ1VMq007669 for ; Sun, 24 Nov 2002 11:01:31 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01532 for ; Sun, 24 Nov 2002 11:01:25 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id 8840C1C; Sun, 24 Nov 2002 21:08:27 +0200 (EET) Message-ID: <3DE12201.3030806@nomadiclab.com> Date: Sun, 24 Nov 2002 21:01:21 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman Cc: Michel Py , ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <5.1.0.14.0.20021123203313.0165e820@mail.windriver.com> In-Reply-To: <5.1.0.14.0.20021123203313.0165e820@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 Michel Py wrote: >> There is room for both models at the same, and "good enough" is not >> going to be good enough for everybody. Margaret Wasserman wrote: > I would need to see a very compelling case for why two types > of globally-unique/provider-independent addressing are needed > before I would like to see two models. "Good enough" ones are easy to generate without too much human intervention, for example, without any connection to the registry. OTOH, they are not necessarily unique, and therefore not "good enough" for some people. IMHO, both types are needed. > I think that one of the benefits of globally-unique/provider- > independent addresses over site-locals is that it is possible > to tell (when one is leaked in any of the possible ways) > exactly where the address came from... This would, of course, > work best if the addresses were actually unique, rather than > mostly-unique. Requiring that everybody registers their GUPI addresses will not make everyone to register them. OTOH, you could argue that if we mandate registration, and someone uses some prefix without registering them, it's their problem. In any case, a modest suggestion: Let's separate the GUPI prefix generation and registration processes, and make them sequential. The prefix generation could be a semi-automatic hashing based process, generating a prefix that is only statistically unique. If real uniqueness is required, the administrator could take the generated prefix and attempt to register it against a modest fee. It that succeeds, good. If that particular prefix is already taken, the admin can generate a new prefix and try again. Registration would require not only registering the prefix but also showing the input. That would discourage people from hoarding "easy" prefixes or adjacent prefixes, since looking for suitable hash input for such prefixes would not be that easy. Furthermore, if really needed, the fee can be gradually raised as the registry starts to fill up, thereby discouraging new registrations. The basic benefit of this method is that there would be only one way of generating GUPI addresses, and that would be an easy one. Additionally, the method would initially keep the GUPI prefix space sparce and evenly distributed; that might be advanteous. For example, deferring regisration of one's prefix would not be that risky, since the probability of succeeding later would be still fairly high. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 24 11:35:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOJZeUu016797; Sun, 24 Nov 2002 11:35:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAOJZewg016796; Sun, 24 Nov 2002 11:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOJZbUu016789 for ; Sun, 24 Nov 2002 11:35:37 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAOJZkMq010775 for ; Sun, 24 Nov 2002 11:35:47 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09528 for ; Sun, 24 Nov 2002 11:35:41 -0800 (PST) Subject: RE: globally unique site local addresses Date: Sun, 24 Nov 2002 11:35:42 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4B8@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message Thread-Index: AcKT7AKIoffZHkdaQtCP7v0iSaHdBQAAnGoA From: "Michel Py" To: "Pekka Nikander" , "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAOJZbUu016790 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > Pekka Nikander wrote: > "Good enough" ones are easy to generate without too > much human intervention, for example, without any > connection to the registry. OTOH, they are not > necessarily unique, and therefore not "good enough" > for some people. IMHO, both types are needed. Agreed. > In any case, a modest suggestion: Let's separate > the GUPI prefix generation and registration processes, > and make them sequential. I have another suggestion: Let's split the FEC0::/10 space in two parts: One for the unregistered "good-enough" and one for the registered truly unique. By default, the "good enough" would be used and a random/hash method would be used. But the network administrator would have a choice of getting a truly unique registered prefix instead. This would likely need to access some web page and pay a nominal fee. If the address space is split, then we have a guarantee that the hash process used for "good enough" will not grab addresses in the range that is used for truly unique. It is clear that the biggest the block for "good enough", the lesser potential collisions. Therefore the truly unique addresses should use only a modest portion of the FEC0::/10 block and leave the lion's share to the hash algorithm. Thoughts? 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 Nov 24 11:53:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOJrNUu016835; Sun, 24 Nov 2002 11:53:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAOJrNbW016834; Sun, 24 Nov 2002 11:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOJrKUu016827 for ; Sun, 24 Nov 2002 11:53:20 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAOJrTbB018113 for ; Sun, 24 Nov 2002 11:53:29 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23771 for ; Sun, 24 Nov 2002 12:53:23 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by n97.nomadiclab.com (Postfix) with ESMTP id 58DE71C; Sun, 24 Nov 2002 22:00:26 +0200 (EET) Message-ID: <3DE12E31.8000704@nomadiclab.com> Date: Sun, 24 Nov 2002 21:53:21 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <2B81403386729140A3A899A8B39B046405E4B8@server2000> In-Reply-To: <2B81403386729140A3A899A8B39B046405E4B8@server2000> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, >> In any case, a modest suggestion: Let's separate >> the GUPI prefix generation and registration processes, >> and make them sequential. > > I have another suggestion: Let's split the FEC0::/10 space in two parts: > One for the unregistered "good-enough" and one for the registered truly > unique. By default, the "good enough" would be used and a random/hash > method would be used. But the network administrator would have a choice > of getting a truly unique registered prefix instead. This would likely > need to access some web page and pay a nominal fee. > > If the address space is split, then we have a guarantee that the hash > process used for "good enough" will not grab addresses in the range that > is used for truly unique. Let me try to briefly analyse the differences between the methods, the "mixed space"" and the "split space" methods: - In either method, you can generate a prefix and register it as a GUPI prefix belonging to you right away. - In the mixed space method, you may have to need a couple of prefixes before you get one registered. OTOH, if you really need a registered prefix, you can combine generation and registration, and start configuring your routers only once you have got a prefix registered. Thus, no big difference in practise. - In the mixed space method, you can generate a prefix now and try to register it later, with a fairly large probability of succeeding. In the split space method, if you only later need a genuinely globally unique address and are not willing to pay for one now, you have to renumber. - In the split space method, you can tell directly from a prefix whether it is genuinely globally unique or not. In the mixed space method you can query the registry whether the prefix has been registered, but even if it is, there may be also other sites that are using the prefix. The probability of the existence of such sites is low, though. - In the split space method, you can be almost sure that nobody else is using your globally unique prefix, and if they do, they do it in error. In the mixed space method, you cannot be sure that nobody else is using your prefix, but if they do, you know that they cannot register it. Thus, from my point of view, the differences seem to boil down into two issues: 1. In the mixed space method, you can defer your registration and still have a fairly large probability of succeeding later in registration. 2. In the split space method, you can have more confidence that no-one else is using your truly unique prefix. I can't say which is better. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 24 12:31:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOKVlUu017196; Sun, 24 Nov 2002 12:31:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAOKVlRt017195; Sun, 24 Nov 2002 12:31: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOKVhUu017188 for ; Sun, 24 Nov 2002 12:31:43 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAOKVrMq019847 for ; Sun, 24 Nov 2002 12:31:53 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14399 for ; Sun, 24 Nov 2002 12:31:48 -0800 (PST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 24 Nov 2002 12:31:46 -0800 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 24 Nov 2002 12:31:47 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 24 Nov 2002 12:31:47 -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); Sun, 24 Nov 2002 12:31:46 -0800 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.3710.0); Sun, 24 Nov 2002 12:31:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: "unique enough" [RE: globally unique site local addresses] Date: Sun, 24 Nov 2002 12:31:47 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "unique enough" [RE: globally unique site local addresses] Thread-Index: AcKTXBLAmp71ycOMTH2/qQxxrC92WwAm9Btj From: "Christian Huitema" To: "Margaret Wasserman" , "Arien Vijn" Cc: "Pekka Savola" , "Jari Arkko" , "ipng" X-OriginalArrivalTime: 24 Nov 2002 20:31:48.0358 (UTC) FILETIME=[83493260:01C293F8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAOKViUu017189 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It is actually my (weak) understanding that taking more inputs > does not actually result in more "uniqueness", at least for > random number generation. > Does anyone know how that works for hashing? This is well explained in RFC 1750, Randomness Recommendations for Security, D. Eastlake, S. Crocker, J. Schiller, December 1994. In short, you need to make sure that the various strings you are hashing provide you the desired level of entropy -- would be 38 bits in this example. -- 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 Nov 24 12:45:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOKjgUu017362; Sun, 24 Nov 2002 12:45:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAOKjgnG017361; Sun, 24 Nov 2002 12:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOKjcUu017354 for ; Sun, 24 Nov 2002 12:45:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAOKjmbB023568 for ; Sun, 24 Nov 2002 12:45:48 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04450 for ; Sun, 24 Nov 2002 13:45:42 -0700 (MST) Subject: RE: globally unique site local addresses Date: Sun, 24 Nov 2002 12:45:44 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4BA@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message Thread-Index: AcKT806TQxGmAmWRRnWJc/QbCKMfZgABoZCg From: "Michel Py" To: "Pekka Nikander" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAOKjdUu017355 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > Pekka Nikander wrote: > Thus, from my point of view, the differences seem to > boil down into two issues: > 1. In the mixed space method, you can defer your > registration and still have a fairly large probability > of succeeding later in registration. > 2. In the split space method, you can have more > confidence that no-one else is using your truly unique > prefix. I agree with the analysis. > I can't say which is better. I think that the split space is better, for the following reason: truly unique is a paid feature. People that pay for the feature will want a guarantee that they will get what they paid for, which is truly unique, which means the only model that works is split space. 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 Nov 24 12:46:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOKkOUu017391; Sun, 24 Nov 2002 12:46:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAOKkNaI017390; Sun, 24 Nov 2002 12:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOKkKUu017383 for ; Sun, 24 Nov 2002 12:46:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAOKkTbB023650 for ; Sun, 24 Nov 2002 12:46:29 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08755 for ; Sun, 24 Nov 2002 13:46:22 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAOKkDG31858; Sun, 24 Nov 2002 22:46:13 +0200 Date: Sun, 24 Nov 2002 22:46:12 +0200 (EET) From: Pekka Savola To: Pekka Nikander cc: Margaret Wasserman , Michel Py , Subject: Re: globally unique site local addresses In-Reply-To: <3DE12201.3030806@nomadiclab.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, 24 Nov 2002, Pekka Nikander wrote: > Michel Py wrote: > >> There is room for both models at the same, and "good enough" is not > >> going to be good enough for everybody. > > Margaret Wasserman wrote: > > I would need to see a very compelling case for why two types > > of globally-unique/provider-independent addressing are needed > > before I would like to see two models. > > "Good enough" ones are easy to generate without too much human > intervention, for example, without any connection to the > registry. OTOH, they are not necessarily unique, and therefore > not "good enough" for some people. IMHO, both types are needed. [...] Whether "completely unique" is required epends on what they're to be used for. Myself, I can't see _any_ reason why anyone would require complete uniqueness (except for being able to globally route them, which is a problem I don't think we should be pursuing here). "Nearly enough uniqueness" with about 38 bits is more than enough. Even with the birthday paradox, where all the networks would be interconnected, about hundreds of thousands of sites would have to all-interconnected, thousands with a very good probability of uniqueness. But sure, e.g. reserving fee::/12 (pun intended :-), fef::/12 reserved) manual assignments would be ok, but I think people would just not use them at all, or use them for entirely wrong purposes -- which is why registering them should not be free. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 24 12:52:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOKqOUu017619; Sun, 24 Nov 2002 12:52:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAOKqOHv017618; Sun, 24 Nov 2002 12:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOKqLUu017608 for ; Sun, 24 Nov 2002 12:52:21 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAOKqUbB024379 for ; Sun, 24 Nov 2002 12:52:30 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05941 for ; Sun, 24 Nov 2002 13:52:23 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1FF0D6A901; Sun, 24 Nov 2002 22:52:15 +0200 (EET) Message-ID: <3DE11FEA.70201@kolumbus.fi> Date: Sun, 24 Nov 2002 20:52:26 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <2B81403386729140A3A899A8B39B046405E4B8@server2000> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Nikander wrote: > "Good enough" ones are easy to generate without too > much human intervention, for example, without any > connection to the registry. OTOH, they are not > necessarily unique, and therefore not "good enough" > for some people. IMHO, both types are needed. Pekka, I still don't know if we really need the perfectly unique site local addresses. The question is: if you need perfectly unique addresses, why can't you use normal, global addresses? There we already have an existing registration process and standards. My thinking is that global addresses + statistically unique site-locals would cover most of the need we have, and it does not pay to construct complexity for the small amount of folks who would need perfect uniqueness. Of course, this is a judgement call. (You and me are perhaps the wrong persons to argue about this; input from corporate network managers and ISPs would be needed.) Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 24 13:08:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOL8EUu017814; Sun, 24 Nov 2002 13:08:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAOL8EIG017813; Sun, 24 Nov 2002 13:08: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOL8BUu017806 for ; Sun, 24 Nov 2002 13:08:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAOL8LMq023542 for ; Sun, 24 Nov 2002 13:08:21 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23492 for ; Sun, 24 Nov 2002 13:08:15 -0800 (PST) Subject: RE: globally unique site local addresses Date: Sun, 24 Nov 2002 13:08:18 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4BC@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message Thread-Index: AcKT/DFTOoKz7oCKQSCkwssNGA7yLQAAJ91w From: "Michel Py" To: "Jari Arkko" , "Pekka Nikander" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAOL8BUu017807 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, > Jari Arkko wrote: > The question is: if you need perfectly unique addresses, > why can't you use normal, global addresses? There we > already have an existing registration process and > standards. Pardon me? There is no such thing for end-sites as of today. > My thinking is that global addresses + statistically > unique site-locals would cover most of the need we have, > and it does not pay to construct complexity for the small > amount of folks who would need perfect uniqueness. Since truly unique would have a fee, the people that pay the fee will finance the development effort. From an enterprise standpoint, $50 a year is not significant if it buys the *guarantee* that the address is unique. The truly unique feature is like insurance. 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 Nov 24 13:13:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOLDIUu017878; Sun, 24 Nov 2002 13:13:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAOLDINq017877; Sun, 24 Nov 2002 13:13: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAOLDFUu017867 for ; Sun, 24 Nov 2002 13:13:15 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAOLDOMq023974 for ; Sun, 24 Nov 2002 13:13:24 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24619 for ; Sun, 24 Nov 2002 13:13:19 -0800 (PST) Subject: RE: "unique enough" [RE: globally unique site local addresses] Date: Sun, 24 Nov 2002 13:13:22 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4BB@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "unique enough" [RE: globally unique site local addresses] X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message Thread-Index: AcKT+X29ZJPbjOevR/2se3GF/deihQAARZnQ From: "Michel Py" To: "Pekka Nikander" , "Margaret Wasserman" Cc: "ipng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAOLDFUu017868 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka / Margaret My $0.02 about the hash/random/collision issue: It's a non-issue. The prefix generation happens only one time for the site. Collisions would not be detected until two sites merge or establish a VPN connection. The site gets its GUPI /48 prefix once, then the network administrator configures all routers within the site with subnets that fit in that prefix. This could be automated, but the fact of the matter is that there needs to be a router somewhere that seeds this prefix. If what you are talking about is automatic subnet number generation, this would be a zeroconf issue. Besides the fact that making site-locals too easy is bad, I don't see why obtaining the prefix should be generated by a router. It is clear that the first thing the network administrator would do is to write down the /48 s/he will be using, and would be the one requesting the prefix in the first place. Also, whatever the random/hash algorithm is chosen and published, it also is clear that the first thing that the network administrator would do is to go to the web to find if someone has already written an applet that would do the job. All we need is a few web sites in the world that provide a good random number generator. 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 Nov 24 20:56:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP4u6Uu019187; Sun, 24 Nov 2002 20:56:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAP4u5j4019186; Sun, 24 Nov 2002 20:56:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP4u1Uu019179; Sun, 24 Nov 2002 20:56:01 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with SMTP id gAP4uAml178367; Sun, 24 Nov 2002 20:56:10 -0800 (PST) Message-Id: <200211250456.gAP4uAml178367@jurassic.eng.sun.com> Date: Sun, 24 Nov 2002 20:59:15 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: Proposal for MIPv6 APIs to switch default source address selection To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 29y5LdDMTfxqx11mcBEObg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => in order to use the API, an application needs to be changed. > So with only the API, the only way to influence the Co@/H@ choice > is to change all common applications... So the API will get only > very limited use and the smart user should still wait for a device > to fulfill his needs. > Yes, the applications need to change to accomodate MobileIP. The goal should be to change them minimally. Thus a API would help in this case, as it may turn the knob to tell the kernel which address to use instead of a default address. The application may not need to specify the exact COA, the kernel can choose the correct one corresponding to the default homeaddress ( assuming application has knowledge about the correct home address). This will be useful for multi-homed mobile nodes as well. > they need to use COA for local cases in the visited link. > > => yes, all the short term not bound to the home applications > could like to use a Co@. There are a lot of situations where > to get communications killed by movements is not a problem... > It will not be desirable to restart common applications upon movement, however small their numbers may be. Then we will loose essence of MobileIP. > some existing apps would have to be modified or written for > MIPv6 anyway. > > => we have to keep the number of such applications as low as possible. > I don't know how many apps fall in this category, may be we should think about that. Off the top of my head, they could be dns-client, printer-client, or any application that requests service discovery in the local network. -Samita -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 24 21:01:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP51YUu019306; Sun, 24 Nov 2002 21:01:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAP51Y1F019305; Sun, 24 Nov 2002 21:01: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP51VUu019298 for ; Sun, 24 Nov 2002 21:01:31 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAP51fbB013052 for ; Sun, 24 Nov 2002 21:01:41 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29975 for ; Sun, 24 Nov 2002 21:01:35 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 2DDD926B3; Mon, 25 Nov 2002 00:01:35 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Nov 2002 00:01:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-ipv6-node-requirements-01.txt Date: Mon, 25 Nov 2002 00:01:34 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9C63@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-node-requirements-01.txt Thread-Index: AcKP9uEVt1fGy9tMS4OnF6XTDO8JdAA3I5ogAAkg0yAA0drmMA== From: "Bound, Jim" To: , X-OriginalArrivalTime: 25 Nov 2002 05:01:35.0051 (UTC) FILETIME=[BA6029B0:01C2943F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAP51VUu019299 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, I have not found any more deprecated cases. But will keep looking just in case. For the M bit. If it is set to a client then the client must find a stateful server for managed addresses to be unconditionally mandatory compliant. Rationale is if the M bit is set the network administrators are telling nodes to do use a stateful mechanism to get addresses. And network administrators are in charge of that policy and they have opted to not use stateless for all addresses or any addresses in this case. /jim [A people who would give up their freedom out of fear did not deserve it in the first place. Ben Franklin] > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, November 20, 2002 7:52 PM > To: Bound, Jim; ipng@sunroof.eng.sun.com > Subject: RE: draft-ietf-ipv6-node-requirements-01.txt > > > Hi Jim, > > > Today in v6ops I think I heard that compliance to the ND M > bit being > > set is optional. That I think is wrong. But the node reqs > doc states > > that dhcpv6 is unconditionally optional which is probably correct > > because stateful may not imply dhcpv6 today. But if the M > bit is set > > the host node (non router) must look for a stateful node. > We need to > > get this right. > > > > P.S. John - I will have all my input on this to you in the next few > > weeks. But it looks real good. I like the terminology too. > > Glad you think that the document looks good. Review it & let > me know what you think - especially suggest what text you > think is needed for the M bit. > > 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 Nov 24 21:06:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP56JUu019420; Sun, 24 Nov 2002 21:06:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAP56JMd019417; Sun, 24 Nov 2002 21:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP56FUu019409 for ; Sun, 24 Nov 2002 21:06:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAP56OMq014289 for ; Sun, 24 Nov 2002 21:06:24 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11588 for ; Sun, 24 Nov 2002 22:06:19 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAP566l29754; Mon, 25 Nov 2002 00:06:06 -0500 (EST) Message-Id: <200211250506.gAP566l29754@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: "Michel Py" , "Christian Huitema" , ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses In-reply-to: (Your message of "Sat, 23 Nov 2002 19:56:09 EST.") <5.1.0.14.0.20021123194321.00b34e50@mail.windriver.com> Date: Mon, 25 Nov 2002 00:06:06 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think that we should stop calling these addresses "site-local", > as that is prone to confusion. We would create a separate set > of globally-unique/provider-independent (GUPI? Pronounced > "guppy" or "goopy", depending on how much you like them? :-)) > addresses for use as local addresses in Internet connected sites. I've started calling them PIGs for Provider Independent Globals :) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 24 21:08:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP585Uu019493; Sun, 24 Nov 2002 21:08:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAP585fx019492; Sun, 24 Nov 2002 21:08: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP581Uu019482; Sun, 24 Nov 2002 21:08:01 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAP58BbB013917; Sun, 24 Nov 2002 21:08:11 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA02647; Sun, 24 Nov 2002 21:08:05 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 1039C42E6; Mon, 25 Nov 2002 00:08:05 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Nov 2002 00:08:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Proposal for MIPv6 APIs to switch default source address selection Date: Mon, 25 Nov 2002 00:08:04 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240C5C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for MIPv6 APIs to switch default source address selection Thread-Index: AcKUP5T9f76LPUz1QpewDmsLcnhXMgAAE6lQ From: "Bound, Jim" To: "Samita Chakrabarti" , Cc: , X-OriginalArrivalTime: 25 Nov 2002 05:08:04.0957 (UTC) FILETIME=[A2C718D0:01C29440] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAP582Uv019483 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just as note thus far with mipv6 testing and technology interoperation with other mipv6 vendors not one application has had to be altered to support mipv6 (e.g. ftp, telnet, streaming video/audio, sip, and a few others). Clearly they had to be ported to IPv6 but nothing special was done for mipv6. The above statement is for the server, router, and handhelds we are testing with at this time and putting in test labs deploying IPv6 in test beds. I don't see draft 19 from draft 18 as big deal either. But I can see optimizations per Samita's comments below helping with very fast movement, and having socket options to set to affect that movement is quite smart and someone should proceed with the work (I can't to much IETF work now sorry). /jim [A people who would give up their freedom out of fear did not deserve it in the first place. Ben Franklin] > -----Original Message----- > From: Samita Chakrabarti [mailto:Samita.Chakrabarti@eng.sun.com] > Sent: Sunday, November 24, 2002 11:59 PM > To: Francis.Dupont@enst-bretagne.fr > Cc: mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > Subject: Re: Proposal for MIPv6 APIs to switch default source > address selection > > > > > > > > => in order to use the API, an application needs to be changed. So > > with only the API, the only way to influence the Co@/H@ > choice is to > > change all common applications... So the API will get only very > > limited use and the smart user should still wait for a device to > > fulfill his needs. > > > > Yes, the applications need to change to accomodate MobileIP. > The goal should be to change them minimally. Thus a API would > help in this case, as it may turn the knob to tell the kernel > which address to use instead of a default address. The > application may not need to specify the exact COA, the kernel > can choose the correct one corresponding to the default > homeaddress ( assuming application has knowledge about the > correct home address). This will be useful for multi-homed > mobile nodes as well. > > > they need to use COA for local cases in the visited link. > > > > => yes, all the short term not bound to the home applications could > > like to use a Co@. There are a lot of situations where to get > > communications killed by movements is not a problem... > > > > > It will not be desirable to restart common applications upon > movement, however small their numbers may be. Then we will > loose essence of MobileIP. > > > some existing apps would have to be modified or written for > > MIPv6 anyway. > > > > => we have to keep the number of such applications as low > as possible. > > > > I don't know how many apps fall in this category, may be we > should think about that. Off the top of my head, they could > be dns-client, printer-client, or any application that > requests service discovery in the local network. > > -Samita > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 24 21:17:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP5HXUu019687; Sun, 24 Nov 2002 21:17:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAP5HX0E019686; Sun, 24 Nov 2002 21:17:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP5HTUu019679; Sun, 24 Nov 2002 21:17:29 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with SMTP id gAP5Hcml181355; Sun, 24 Nov 2002 21:17:38 -0800 (PST) Message-Id: <200211250517.gAP5Hcml181355@jurassic.eng.sun.com> Date: Sun, 24 Nov 2002 21:20:45 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection To: alper@docomolabs-usa.com Cc: Francis.Dupont@enst-bretagne.fr, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XZC5j9uWjnJkXIwmsUHyGQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > In your previous mail you wrote: > > > > An alternative approach could be: If the application cares about > > the source address, it can use the Mobile IP API to figure out which > > ones are home address, which ones are care-of address, and than > > explicitly "bind" the socket to the desired address. IMO, this would > > also satisfy the needs of the Mobile IPv6 mobile node. > > > > => this is similar to what I implemented in the past. > > But a function giving the list of addresses with status is not enough, > > the best is to give the home address and the care-of address for > > a destination. > > I see. When the mobile node has more than one pair of > home_address-care_of_address, then it won't really know which > one to pick. So, maybe, instead of exporting all this information > to the apps and giving them the control, it might be better > to enable the app to say "bind this socket to any address, preferably > topologically correct (i.e., a CoA, or home address when at home)". > I suspect this is what Samita had in her mind.. > Correct. When an app uses bind(), in most cases it assumes that the bound-to- address is an interface address of the node. So, if the home-addr and temporary addresses are configured as logical interfaces of COA interface (in visited network) of the mobile node, binding to a specific source address would work. But for multi-homed nodes or a node which has multiple home-addresses and COAs, the client apps may not want to bind to any particular source address and it wants to let the kernel decide to choose the correct topological address corresponding to the local network. Since the apps need to be generic to handle all cases, binding to a source address would not work always. > > As first info is getsockname() for bound sockets, > > I added a clone of getsockname() which returns the real source > > address after MIPv6 processing. > > Or, don't change the getsockname(), but instead call > mip_get_one_mobile_node() afterwards to identify if the address is bound > to a care-of address. Note that this binding can dynamically any time, > and subsequent mip_get_one_mobile_node() calls are sufficient to capture > the changes. I'd say for connected and bound sockets, getsockname() would return the correct topological source address. Thanks, -Samita > > Note this doesn't solve the need of a control for smarter choice > > between Co@/H@. I proposed some and implemented two: use always > > the H@ and use it but a Co@ when the destination is in the same > > link then a Co@. They were global (still better than none :-). > > > > Thanks > > > > Francis.Dupont@enst-bretagne.fr > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 24 21:27:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP5RbUu019948; Sun, 24 Nov 2002 21:27:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAP5RbYW019947; Sun, 24 Nov 2002 21:27:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP5RQUu019930; Sun, 24 Nov 2002 21:27:26 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with SMTP id gAP5RZml182697; Sun, 24 Nov 2002 21:27:35 -0800 (PST) Message-Id: <200211250527.gAP5RZml182697@jurassic.eng.sun.com> Date: Sun, 24 Nov 2002 21:30:41 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: RE: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection To: Jim.Bound@hp.com Cc: alper@docomolabs-usa.com, Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9ECtMY5ZH1gHXrzdAvPQ1Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > A simple api ext doc would be great. But not part of the advanced api. > We need to ship the base and advanced apis now. > That's what I was aiming for; a short and simple advanced api socket extension doc as a guideline for MIPv6 compatible applications. I agree that the server side apps do not require change, but some client side apps should change (like dns-client, printer-client etc.) so that they don't have to send packets all the way to the home-agent for doing the local job. Thanks for your comments. -Samita > > > > -----Original Message----- > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > Sent: Thursday, November 21, 2002 9:49 PM > > To: Francis Dupont > > Cc: Samita Chakrabarti; ipng@sunroof.eng.sun.com; > > mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to > > switch default source address selection > > > > > > > > > > > In your previous mail you wrote: > > > > > > An alternative approach could be: If the application cares about > > > the source address, it can use the Mobile IP API to > > figure out which > > > ones are home address, which ones are care-of address, and than > > > explicitly "bind" the socket to the desired address. > > IMO, this would > > > also satisfy the needs of the Mobile IPv6 mobile node. > > > > > > => this is similar to what I implemented in the past. > > > But a function giving the list of addresses with status is > > not enough, > > > the best is to give the home address and the care-of address for a > > > destination. > > > > I see. When the mobile node has more than one pair of > > home_address-care_of_address, then it won't really know which > > one to pick. So, maybe, instead of exporting all this > > information to the apps and giving them the control, it might > > be better > > to enable the app to say "bind this socket to any address, > > preferably topologically correct (i.e., a CoA, or home > > address when at home)". I suspect this is what Samita had in > > her mind.. > > > > > As first info is getsockname() for bound sockets, > > > I added a clone of getsockname() which returns the real > > source address > > > after MIPv6 processing. > > > > Or, don't change the getsockname(), but instead call > > mip_get_one_mobile_node() afterwards to identify if the > > address is bound to a care-of address. Note that this binding > > can dynamically any time, and subsequent > > mip_get_one_mobile_node() calls are sufficient to capture the changes. > > > > alper > > > > > Note this doesn't solve the need of a control for smarter choice > > > between Co@/H@. I proposed some and implemented two: use > > always the H@ > > > and use it but a Co@ when the destination is in the same > > link then a > > > Co@. They were global (still better than none :-). > > > > > > Thanks > > > > > > Francis.Dupont@enst-bretagne.fr > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 00:02:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP82eUu020719; Mon, 25 Nov 2002 00:02:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAP82eY3020718; Mon, 25 Nov 2002 00:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP82aUu020711 for ; Mon, 25 Nov 2002 00:02:36 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAP82kMq003853 for ; Mon, 25 Nov 2002 00:02:46 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07829 for ; Mon, 25 Nov 2002 00:02:41 -0800 (PST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by n97.nomadiclab.com (Postfix) with ESMTP id 0D5231C; Mon, 25 Nov 2002 10:09:38 +0200 (EET) Message-ID: <3DE1D91F.3050708@nomadiclab.com> Date: Mon, 25 Nov 2002 10:02:39 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021120 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py Cc: Jari Arkko , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <2B81403386729140A3A899A8B39B046405E4BC@server2000> In-Reply-To: <2B81403386729140A3A899A8B39B046405E4BC@server2000> 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: > I think that the split space is better, for the following reason: truly > unique is a paid feature. People that pay for the feature will want a > guarantee that they will get what they paid for, which is truly unique, > which means the only model that works is split space. Michel Py wrote: > Since truly unique would have a fee, the people that pay the fee will > finance the development effort. From an enterprise standpoint, $50 a > year is not significant if it buys the *guarantee* that the address is > unique. The truly unique feature is like insurance. Let me try to understand why exactly some people would be willing to pay a fee for "truly" uniqueness. I'm probably missing some issues here; your input is valued. First of all, there is no such thing as an absolute guarantee for global uniqueness. Misconfigurations happen. Thus, the real difference between the "split space" and "mixed space" model is that in the split space model, *nobody* is *supposed* to configure or use a registered prefix, while in the mixed space model someone *may* legitimitely use it. However, even in the mixed space model the party having preformed the registration has some kind of ownership/moral property rights over the prefix, giving them more rights over those that haven't registered the prefix but happen to be using it anyway. Thus, whatever you pay, you don't have any absolute guarantee that nobody else is using your prefix. What you have is some kind of right over the prefix, the right having been aquired by registering and paying. Now, the case seems to depend on psychology and the formulation of rights. In the split space case the rights are easier to formulate, more natural, and stronger in that sense. Nobody is supposed to use your prefix, and therefore they are wrong if they use your prefix, and you can sue them (or, in Europe, you can dispise and ignore them :-) As far as I understand, it would be possible to come fairly close to that even in the mixed space model. If you have registered a prefix, nobody else can register the same prefix, and if you ever see someone using you prefix, they are wrong by letting the prefix to leak, and you can sue them (or at least dispise and ignore them :-) So, to me, it looks like the only thing "truly" uniqueness buys is that if your prefix is ever leaked by someone else but you, you may have better chances to shut them down, since you can morally require them to change their prefix. The cost of tracking down the party leaking the prefix seems to be the same. In both cases registration buys you the assurance that you do not need to renumber you prefix, ever. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 00:19:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP8JHUu020807; Mon, 25 Nov 2002 00:19:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAP8JHOD020806; Mon, 25 Nov 2002 00:19:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP8JEUu020799 for ; Mon, 25 Nov 2002 00:19:14 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAP8JOMq005848 for ; Mon, 25 Nov 2002 00:19:24 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA01026 for ; Mon, 25 Nov 2002 00:19:18 -0800 (PST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by n97.nomadiclab.com (Postfix) with ESMTP id 4A67E1C; Mon, 25 Nov 2002 10:26:21 +0200 (EET) Message-ID: <3DE1DD0A.6060400@nomadiclab.com> Date: Mon, 25 Nov 2002 10:19:22 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021120 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py Cc: Margaret Wasserman , ipng , Pekka Savola Subject: Re: "unique enough" [RE: globally unique site local addresses] References: <2B81403386729140A3A899A8B39B046405E4BB@server2000> In-Reply-To: <2B81403386729140A3A899A8B39B046405E4BB@server2000> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, > My $0.02 about the hash/random/collision issue: It's a non-issue. I would agree with you, but only if I shared the same view of the GUPI prefix usage. That is, if GUPIs are really used only by explicit administrator action in big corporations, then fine. But unfortunately I don't believe so. > The prefix generation happens only one time for the site. Collisions > would not be detected until two sites merge or establish a VPN > connection. Agreed. Though, I can vision dynamic "sites" that are created and dismissed fairly often. OTOH, if we decide to define a GUPI address space, we can formulate the usage guidelines so that they should not be used in such a case, and that a still another type of addresses are needed for such "sites". > The site gets its GUPI /48 prefix once, then the network administrator > configures all routers within the site with subnets that fit in that > prefix. This could be automated, but the fact of the matter is that > there needs to be a router somewhere that seeds this prefix. If what you > are talking about is automatic subnet number generation, this would be a > zeroconf issue. Agreed. But I can also see a "semi-automatic" case; a SOHO or non-IT company configuring their network, and pushing a "button" to generate a site prefix for their network. Most probably they would not want to pay the *trouble* of registering their prefix; still the fee might be a non-issue for them. A site note: The reason for the registration fee is to discourage prefix hoarding. The fee can be lower than the trouble needed for registering a single prefix. (When registering multiple prefixes, the trouble for the subsequent prefixes is much lower than in the beginning, since learning is a big part of the initial trouble.) > Besides the fact that making site-locals too easy is bad, I don't see > why obtaining the prefix should be generated by a router. It is clear > that the first thing the network administrator would do is to write down > the /48 s/he will be using, and would be the one requesting the prefix > in the first place. Hmm. I would agree that this is the case today, more or less. But, iff small sites become common, the situation would be different. If I remember correctly, one of the design goals in the whole IPv6 standardization has been minimization of human intervention. That's the reason why we have address autoconfiguration, that's the reason why we have been developing router renumbering etc. Or am I mistaken? Thus, I think that *if* we create these GUPI prefixes, their creation should be semi-automatic. Not fully automatic since they are not always needed. But, sure, we can start with a completely manual process and revise it later, if people feel that there is some danger is such a semi-automatic creation. > Also, whatever the random/hash algorithm is chosen and published, it > also is clear that the first thing that the network administrator would > do is to go to the web to find if someone has already written an applet > that would do the job. There will be "sites" that do not have Internet access at the time they want to configure their prefix. Either they will hand pick one, most probably causing unnecessary collisions, or the process should be semi-automatic, with built-in assistance in routers or in router configuration software. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 01:04:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP94QUu021021; Mon, 25 Nov 2002 01:04:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAP94PFL021020; Mon, 25 Nov 2002 01:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP94MUu021013 for ; Mon, 25 Nov 2002 01:04:23 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAP94XbB012597 for ; Mon, 25 Nov 2002 01:04:33 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02943 for ; Mon, 25 Nov 2002 01:04:27 -0800 (PST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by n97.nomadiclab.com (Postfix) with ESMTP id C92F91C for ; Mon, 25 Nov 2002 11:11:29 +0200 (EET) Message-ID: <3DE1E79F.7010101@nomadiclab.com> Date: Mon, 25 Nov 2002 11:04:31 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021120 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPv6 WG Subject: Summary & some possible long term consequences of GUPI prefixes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm trying to understand this whole GUPI prefix business. I have to say that I'm fairly confused, and therefore this attempt to summarize and envision the case. Please correct wherever I've mistaken. The GUPI proposal seems to have grown from the concerns regarding site locals. (I have to confess that I still do not quite understand why some people think that site locals are that bad; I guess there have been too many messages. I am still looking for the pro and cons drafts Margaret(?) suggested/asked for a few hundred messages back. Anyway, that's not the point here.) The GUPI prefixes seem to have a lot of desirable properties. Leaking GUPI addresses are less likely to cause confusion than leaking SL addresses. Site merger is easier with GUPI prefixes than without. GUPI prefixes allow limited inter-site communication through direct peering or tunneling. Statistically unique GUPI prefixes would be easy to generate. etc. Some people seem to think that GUPIs would reduce the need for IPv6 NAT. Maybe so, maybe not. More below. Requiring mandatory registration for GUPIs may make it easier to track down people leaking GUPI routes, but not necessarily so. But at least that would give us a scape goat, someone to yell at if a prefix is leaked. OTOH, mandatory registration would make it very hard to use them at non-connected sites. Now, suppose for a moment that we do have such GUPI prefixes. That is, prefixes that are (statistically) globally unique, provider independent, free, forever valid requiring never renumbering, and easy to generate even for non-connected sites. I guess almost everyone would start using them. At least I would personally, just for my personal VPN between my office and home. Thus, there would be millions of these prefixes in use. With some more invention, such as using them for PANs or semi-stable ad hoc networks, there would be billions of dynamic sites using these prefixes. From a site multi-homing (multi6) perspective, it might become again a (not so) good idea to perform prefix translation at the site exit routers. If you configure your network so that all hosts defend the same IID with the GUPI prefix and the global prefixes, thereby making IIDs unique within the site, you could fairly safely translate a GUPI prefix in source addresses into your global prefix for outgoing packets and vice versa for incoming packets. MULTI6 solved :-) From a mobile networks (nemo) perspective, you could use your GUPIs inside your mobile network (airplane, car), and again perform prefix translation at the site exit router. NEMO solved :-) (For those you missed the irony: I know pretty well that prefix translation would not solve the problems multi6 or nemo are addressing. I just want to point out that GUPIs might make people to consider prefix translation more seriously, since it would look "safer" with GUPIs.) More seriously, there would be a tendency to consider GUPI addresses as immutable identifiers for hosts, making the aggretable global PA addresses mere locators. Thus, it might form a step towards an architecture where identifiers and locators are separated. Now, honestly, I do not know if that would be a good step or not. We just have to understand that there would be a strong temptation to view the situation so. Furthermore, I guess that many people might just start using the GUPI addresses so, without thinking too much about the architectural consequences. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 01:40:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP9eLUu021197; Mon, 25 Nov 2002 01:40:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAP9eLDT021196; Mon, 25 Nov 2002 01:40:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAP9eIUu021189 for ; Mon, 25 Nov 2002 01:40:18 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAP9eSbB016853 for ; Mon, 25 Nov 2002 01:40:28 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25253 for ; Mon, 25 Nov 2002 02:40:22 -0700 (MST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAP9e9nm195894; Mon, 25 Nov 2002 10:40:11 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAP9e7Yv089398; Mon, 25 Nov 2002 10:40:09 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26176 from ; Mon, 25 Nov 2002 10:40:05 +0100 Message-Id: <3DE1EFE0.D70806D5@hursley.ibm.com> Date: Mon, 25 Nov 2002 10:39:44 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Nikander Cc: IPv6 WG Subject: Re: Summary & some possible long term consequences of GUPI prefixes References: <3DE1E79F.7010101@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Nikander wrote: .... > More seriously, there would be a tendency to consider > GUPI addresses as immutable identifiers for hosts, > making the aggretable global PA addresses mere locators. > Thus, it might form a step towards an architecture > where identifiers and locators are separated. > > Now, honestly, I do not know if that would be a good > step or not. It would be an excellent step, as long as we simultaneously architected a way to use this separation that is more attractive to enterprises and ISPs than NAT. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 05:22:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPDMjUu021759; Mon, 25 Nov 2002 05:22:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPDMjai021758; Mon, 25 Nov 2002 05:22: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPDMfUu021751 for ; Mon, 25 Nov 2002 05:22:41 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPDMqbB010634 for ; Mon, 25 Nov 2002 05:22:52 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA22835 for ; Mon, 25 Nov 2002 05:22:30 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26412; Mon, 25 Nov 2002 08:18:49 -0500 (EST) Message-Id: <200211251318.IAA26412@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-ipaddressassign-05.txt Date: Mon, 25 Nov 2002 08:18:33 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : A Flexible Method for Managing the Assignment of Bites of an IPv6 Address Block Author(s) : M. Blanchet Filename : draft-ietf-ipv6-ipaddressassign-05.txt Pages : 9 Date : 2002-11-21 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 RFC1219 and can be used for IPv6 assignments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ipaddressassign-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-ipaddressassign-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ipaddressassign-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-21133842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-ipaddressassign-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-ipaddressassign-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-21133842.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 Nov 25 05:30:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPDU0Uu021804; Mon, 25 Nov 2002 05:30:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPDU0TS021803; Mon, 25 Nov 2002 05:30:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPDTuUu021793 for ; Mon, 25 Nov 2002 05:29:56 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPDU8bB011547 for ; Mon, 25 Nov 2002 05:30:08 -0800 (PST) Received: from parsmtp2.rd.francetelecom.com (parsmtp2.rd.francetelecom.com [194.167.105.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26759 for ; Mon, 25 Nov 2002 05:30:02 -0800 (PST) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Nov 2002 14:29:58 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C29486.BF6E8116" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: Prefix delegation status Date: Mon, 25 Nov 2002 14:29:57 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Prefix delegation status Thread-Index: AcKUhr9aqavJZ4BIT+y1NI/s/MShOw== From: "NOISETTE Yoann FTRD/DMI/CAE" To: "Zerouter (E-mail)" , "Ipng (E-mail)" X-OriginalArrivalTime: 25 Nov 2002 13:29:58.0577 (UTC) FILETIME=[BFE4DA10:01C29486] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C29486.BF6E8116 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, The prefix delegation document is one of the documents that is set as = priority for ipv6 WG, as it appears in the updated charter. However, in the same time, zerouter works on the subnet assignment = topic. Even if the zerouter charter is to be extended, the subnet = allocation topic will remain one of importance and presentations of = solutions have been made in Atlanta in this context.=20 Zerouter limits its scope to solutions that support 10s of links = networks. If we consider that prefix delegation is to be deployed mainly = in SOHOs (as big companies will certainly manage their subnet allocation = differently), then the requirements document could fit in the work = provided by zerouter... therefore, leading to move the requirements = document from ipv6 to zerouter... Moreover, apart from the DHCPv6-option and RA proxy solutions, the other = solutions for prefix delegation are no WG items, so they are actually = considered as interesting documents for zerouter. Wouldn't it be better = (apart from the DHCP solution which is DHCP specific) to gather all this = work and propositions in zerouter ? Yoann ------_=_NextPart_001_01C29486.BF6E8116 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Prefix delegation status

Hi all,

The prefix delegation document is one = of the documents that is set as priority for ipv6 WG, as it appears in = the updated charter.

However, in the same time, zerouter = works on the subnet assignment topic. Even if the zerouter charter is to = be extended, the subnet allocation topic will remain one of importance = and presentations of solutions have been made in Atlanta in this = context.

Zerouter limits its scope to solutions = that support 10s of links networks. If we consider that prefix = delegation is to be deployed mainly in SOHOs (as big companies will = certainly manage their subnet allocation differently), then the = requirements document could fit in the work provided by zerouter... = therefore, leading to move the requirements document from ipv6 to = zerouter...

Moreover, apart from the DHCPv6-option = and RA proxy solutions, the other solutions for prefix delegation are no = WG items, so they are actually considered as interesting documents for = zerouter. Wouldn't it be better (apart from the DHCP solution which is = DHCP specific) to gather all this work and propositions in zerouter = ?

Yoann

------_=_NextPart_001_01C29486.BF6E8116-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 06:38:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPEcnUu021987; Mon, 25 Nov 2002 06:38:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPEcn9b021986; Mon, 25 Nov 2002 06:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPEckUu021979 for ; Mon, 25 Nov 2002 06:38:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPEcvMq025348 for ; Mon, 25 Nov 2002 06:38:57 -0800 (PST) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04672 for ; Mon, 25 Nov 2002 07:38:52 -0700 (MST) 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 gAPEcoZ17445; Mon, 25 Nov 2002 09:38:50 -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 gAPEcnN39672; Mon, 25 Nov 2002 09:38:49 -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 JAA09370; Mon, 25 Nov 2002 09:38:47 -0500 (EST) Subject: Re: Enforcing unreachability of site local addresses From: Steven Blake To: Christian Huitema Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 25 Nov 2002 09:38:46 -0500 Message-Id: <1038235127.43495.16.camel@newcastle.torrentnet.com> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 2002-11-23 at 13:37, Christian Huitema wrote: > One of the point in the discussion of the "globally unique" site local > addresses has been the discussion of their usage. In particular, if the new > addresses are globally unique, how do we prevent them from being > globally routed and creating a mess in the global routing tables; and, > on a related note, how do we make sure that they are actually local? > > The issue is clearly complex. There are legitimate scenarios in which > two sites might want to create some kind of backdoor connection > independent of any ISP connection, in a way similar to the various > "extranet" scenarios that are common today; it could also be used in a > merger situation. There are also illegitimate scenarios in which a > powerful customer would pressure an ISP to simply advertize their > globally unique /48. Why is this scenario "illegitimate"? It is certainly not scalable to millions of sites (with current routing technology), but on the other hand private jets are not scalable either, and yet there seems to be a healthy market for them. I'm having a hard time understanding why any of the thousands of institutions with IPv4 PI address prefixes would ever migrate to IPv6 if they had to give up PI addressing. 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 Mon Nov 25 07:51:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPFpoUu022187; Mon, 25 Nov 2002 07:51:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPFpoC5022186; Mon, 25 Nov 2002 07:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPFplUu022179 for ; Mon, 25 Nov 2002 07:51:47 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPFpwbB004423 for ; Mon, 25 Nov 2002 07:51:58 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19049 for ; Mon, 25 Nov 2002 07:51:53 -0800 (PST) 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 HAA20140; Mon, 25 Nov 2002 07:51:52 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAPFppn23755; Mon, 25 Nov 2002 07:51:51 -0800 X-mProtect: <200211251551> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2OzKim; Mon, 25 Nov 2002 07:51:49 PST Message-ID: <3DE246D3.EB74C7C7@iprg.nokia.com> Date: Mon, 25 Nov 2002 07:50:43 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <2B81403386729140A3A899A8B39B046405E4BC@server2000> 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: > Pardon me? There is no such thing for end-sites as of today. > > > My thinking is that global addresses + statistically > > unique site-locals would cover most of the need we have, > > and it does not pay to construct complexity for the small > > amount of folks who would need perfect uniqueness. > > Since truly unique would have a fee, the people that pay the fee will > finance the development effort. From an enterprise standpoint, $50 a > year is not significant if it buys the *guarantee* that the address is > unique. The truly unique feature is like insurance. I don't think a fee is required at all. The amount of storage and processor time that a freebie allocation site would require is so small, I'm sure many people, including me, would be willing to host such a website for free. I suggested before that there should be a web page under www.iana.org for people to get addresses, rate limited and so on. This is not a "registration", because nobody has to care about who actually got the address, and no services are to be offered. This would solve the uniqueness problem, but all the other problems would remain. It seems to me that this also eliminates a requirement for "statistically unique" addresses for site-local. 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 Nov 25 07:58:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPFw6Uu022330; Mon, 25 Nov 2002 07:58:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPFw6wA022329; Mon, 25 Nov 2002 07:58:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPFw2Uu022319 for ; Mon, 25 Nov 2002 07:58:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPFwEbB005860 for ; Mon, 25 Nov 2002 07:58:14 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19868 for ; Mon, 25 Nov 2002 07:58:08 -0800 (PST) Subject: RE: globally unique site local addresses Date: Mon, 25 Nov 2002 07:58:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4C2@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses Thread-Index: AcKUmrenBpyr1FfsQ1iTXgJxtywPMQAAC/7A 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 gAPFw3Uu022320 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, > Charlie Perkins wrote: > I don't think a fee is required at all. The amount of > storage and processor time that a freebie allocation site > would require is so small, I'm sure many people, > including me, would be willing to host such a website for > free. I suggested before that there should be a web page > under www.iana.org for people to get addresses, rate limited > and so on. This is not a "registration", because nobody has > to care about who actually got the address, and no services > are to be offered. > This would solve the uniqueness problem, but all the other > problems would remain. It seems to me that this also eliminates > a requirement for "statistically unique" addresses for site-local. If the addresses were allocated randomly or with a hash I would agree with you. However, what I proposed was addresses allocated geographically, along the lines of being used as identifiers for a dual-space multihoming solution, and this will require some work from the RIRs (maintenance/monitoring of areas) thus the fee. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 08:14:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGEMUu022709; Mon, 25 Nov 2002 08:14:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPGEMIx022708; Mon, 25 Nov 2002 08:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGEIUu022699 for ; Mon, 25 Nov 2002 08:14:18 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPGEUbB009868 for ; Mon, 25 Nov 2002 08:14:30 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03588 for ; Mon, 25 Nov 2002 08:14:24 -0800 (PST) Subject: RE: globally unique site local addresses Date: Mon, 25 Nov 2002 08:14:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4C1@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses Thread-Index: AcKUWRZ9fgbhMKCnRECz6/8RJ1pLPgAQSqyw From: "Michel Py" To: "Pekka Nikander" Cc: "Jari Arkko" , "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAPGEJUu022702 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > Pekka Nikander wrote: > First of all, there is no such thing as an absolute > guarantee for global uniqueness. Misconfigurations > happen. Thus, the real difference between the "split > space" and "mixed space" model is that in the split > space model, *nobody* is *supposed* to configure or > use a registered prefix, while in the mixed space > model someone *may* legitimitely use it. However, > even in the mixed space model the party having > preformed the registration has some kind of > ownership/moral property rights over the prefix, > giving them more rights over those that haven't > registered the prefix but happen to be using it > anyway. We are not trying to design a protocol that fixes stupidity. > Now, the case seems to depend on psychology and the > formulation of rights. In the split space case the rights > are easier to formulate, more natural, and stronger in that > sense. Nobody is supposed to use your prefix, and therefore > they are wrong if they use your prefix, and you can sue them > (or, in Europe, you can dispise and ignore them :-) Exactly. And this is worth a few bucks, although I would agree that it's not worth more than a few bucks. But it would be an easier sale to lots of people, with or without good reasons for it. More on the split model deal: So far we have discussed a split model where the address allocation for the "truly unique" is the same as for the "good enough". I agree that the split model does not bring much, but I don't agree that it cancels the "use now register later" feature. Even in a split model, you could have registration of addresses in the block that is used for the random/hash algorithm, and still have the truly unique block. In other words, you could register a truly unique prefix if you register up front, and also register a "good enough" if you used it without registering and later want to register it. Note that the proposal I have for "truly unique" is based on geography and will require split space as it could also be used to seed identifiers in a dual-space identifier/locator multihoming solution. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 08:18:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGIbUu022777; Mon, 25 Nov 2002 08:18:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPGIbrM022776; Mon, 25 Nov 2002 08:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGIXUu022769 for ; Mon, 25 Nov 2002 08:18:33 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPGIjbB010892 for ; Mon, 25 Nov 2002 08:18:45 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06395 for ; Mon, 25 Nov 2002 08:18:39 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA03694; Mon, 25 Nov 2002 16:18:37 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: "NOISETTE Yoann FTRD/DMI/CAE" Cc: "Zerouter (E-mail)" , "Ipng (E-mail)" Subject: Re: Prefix delegation status References: From: Ole Troan Date: Mon, 25 Nov 2002 16:18:37 +0000 In-Reply-To: ("NOISETTE Yoann FTRD/DMI/CAE"'s message of "Mon, 25 Nov 2002 14:29:57 +0100") Message-ID: <7t5lm3h39nm.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The prefix delegation document is one of the documents that is set as > priority for ipv6 WG, as it appears in the updated charter. However, > in the same time, zerouter works on the subnet assignment topic. Even > if the zerouter charter is to be extended, the subnet allocation topic > will remain one of importance and presentations of solutions have been > made in Atlanta in this context. Zerouter limits its scope to > solutions that support 10s of links networks. If we consider that > prefix delegation is to be deployed mainly in SOHOs (as big companies > will certainly manage their subnet allocation differently), then the > requirements document could fit in the work provided by > zerouter... therefore, leading to move the requirements document from > ipv6 to zerouter... Moreover, apart from the DHCPv6-option and RA > proxy solutions, the other solutions for prefix delegation are no WG > items, so they are actually considered as interesting documents for > zerouter. Wouldn't it be better (apart from the DHCP solution which is > DHCP specific) to gather all this work and propositions in zerouter ? I don't think so. Prefix delegation and router auto-configuration are different problems. Prefix delegation is trying to solve the problem of delegating a prefix across an administrative boundary between two routers. Zerorouter is working on the much larger problem of auto-configuring routers within a domain of arbitrary complex topology. Zerorouter may need prefix delegation, and PD solutions may be a part of the total zerorouter solution. /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 Nov 25 08:24:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGO8Uu022863; Mon, 25 Nov 2002 08:24:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPGO8fm022862; Mon, 25 Nov 2002 08:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGO5Uu022855 for ; Mon, 25 Nov 2002 08:24:05 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPGOGMq014700 for ; Mon, 25 Nov 2002 08:24:16 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07237 for ; Mon, 25 Nov 2002 08:24:11 -0800 (PST) Subject: RE: "unique enough" [RE: globally unique site local addresses] Date: Mon, 25 Nov 2002 08:24:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B04640BD445@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: "unique enough" [RE: globally unique site local addresses] Thread-Index: AcKUW3y0lQ+yhCA0Q9KEhBmZhymO0wAQ0J2A From: "Michel Py" To: "Pekka Nikander" Cc: "Margaret Wasserman" , "ipng" , "Pekka Savola" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAPGO5Uu022856 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> My $0.02 about the hash/random/collision issue: >> It's a non-issue. > Pekka Nikander wrote: > I would agree with you, but only if I shared the same > view of the GUPI prefix usage. This much is clear. That is, if GUPIs are really used only by explicit administrator action in big corporations, then fine. But unfortunately I don't believe so. > The prefix generation happens only one time for the site. Collisions > would not be detected until two sites merge or establish a VPN > connection. Agreed. Though, I can vision dynamic "sites" that are created and dismissed fairly often. OTOH, if we decide to define a GUPI address space, we can formulate the usage guidelines so that they should not be used in such a case, and that a still another type of addresses are needed for such "sites". > The site gets its GUPI /48 prefix once, then the network administrator > configures all routers within the site with subnets that fit in that > prefix. This could be automated, but the fact of the matter is that > there needs to be a router somewhere that seeds this prefix. If what you > are talking about is automatic subnet number generation, this would be a > zeroconf issue. Agreed. But I can also see a "semi-automatic" case; a SOHO or non-IT company configuring their network, and pushing a "button" to generate a site prefix for their network. Most probably they would not want to pay the *trouble* of registering their prefix; still the fee might be a non-issue for them. A site note: The reason for the registration fee is to discourage prefix hoarding. The fee can be lower than the trouble needed for registering a single prefix. (When registering multiple prefixes, the trouble for the subsequent prefixes is much lower than in the beginning, since learning is a big part of the initial trouble.) > Besides the fact that making site-locals too easy is bad, I don't see > why obtaining the prefix should be generated by a router. It is clear > that the first thing the network administrator would do is to write down > the /48 s/he will be using, and would be the one requesting the prefix > in the first place. Hmm. I would agree that this is the case today, more or less. But, iff small sites become common, the situation would be different. If I remember correctly, one of the design goals in the whole IPv6 standardization has been minimization of human intervention. That's the reason why we have address autoconfiguration, that's the reason why we have been developing router renumbering etc. Or am I mistaken? Thus, I think that *if* we create these GUPI prefixes, their creation should be semi-automatic. Not fully automatic since they are not always needed. But, sure, we can start with a completely manual process and revise it later, if people feel that there is some danger is such a semi-automatic creation. > Also, whatever the random/hash algorithm is chosen and published, it > also is clear that the first thing that the network administrator would > do is to go to the web to find if someone has already written an applet > that would do the job. There will be "sites" that do not have Internet access at the time they want to configure their prefix. Either they will hand pick one, most probably causing unnecessary collisions, or the process should be semi-automatic, with built-in assistance in routers or in router configuration software. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 08:37:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGbCUu022986; Mon, 25 Nov 2002 08:37:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPGbCeM022985; Mon, 25 Nov 2002 08:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGb9Uu022978 for ; Mon, 25 Nov 2002 08:37:09 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPGbKbB015228 for ; Mon, 25 Nov 2002 08:37:20 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19564 for ; Mon, 25 Nov 2002 09:37:14 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAPGb1608696; Mon, 25 Nov 2002 18:37:01 +0200 Date: Mon, 25 Nov 2002 18:37:00 +0200 (EET) From: Pekka Savola To: Charlie Perkins cc: Michel Py , Subject: Re: globally unique site local addresses In-Reply-To: <3DE246D3.EB74C7C7@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Nov 2002, Charlie Perkins wrote: > > Pardon me? There is no such thing for end-sites as of today. > > > > > My thinking is that global addresses + statistically > > > unique site-locals would cover most of the need we have, > > > and it does not pay to construct complexity for the small > > > amount of folks who would need perfect uniqueness. > > > > Since truly unique would have a fee, the people that pay the fee will > > finance the development effort. From an enterprise standpoint, $50 a > > year is not significant if it buys the *guarantee* that the address is > > unique. The truly unique feature is like insurance. > > I don't think a fee is required at all. The amount of storage and > processor time that a freebie allocation site would require is > so small, I'm sure many people, including me, would be > willing to host such a website for free. I suggested before > that there should be a web page under www.iana.org for > people to get addresses, rate limited and so on. This is > not a "registration", because nobody has to care about who > actually got the address, and no services are to be offered. The idea for the fee came from the concept that only people who actually needed them would get them if there was a fee attached. Others could use semi-random values. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 08:42:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGgPUu023037; Mon, 25 Nov 2002 08:42:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPGgPsq023036; Mon, 25 Nov 2002 08:42: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGgMUu023029; Mon, 25 Nov 2002 08:42:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPGgXMq018810; Mon, 25 Nov 2002 08:42:33 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24729; Mon, 25 Nov 2002 09:42:27 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2B86E6B1F; Mon, 25 Nov 2002 11:42:27 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Nov 2002 11:42:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection Date: Mon, 25 Nov 2002 11:42:26 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9C78@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection Thread-Index: AcKUQ2LUsFP0kNDIQSCX3H9S6EAY7QAXiXbQ From: "Bound, Jim" To: "Samita Chakrabarti" Cc: , , , X-OriginalArrivalTime: 25 Nov 2002 16:42:26.0981 (UTC) FILETIME=[A3477550:01C294A1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAPGgMUv023030 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ahhhh. OK. Now I see. Don't do client stuff so did not see that. Thanks. /jim [A people who would give up their freedom out of fear did not deserve it in the first place. Ben Franklin] > -----Original Message----- > From: Samita Chakrabarti [mailto:Samita.Chakrabarti@eng.sun.com] > Sent: Monday, November 25, 2002 12:31 AM > To: Bound, Jim > Cc: alper@docomolabs-usa.com; > Francis.Dupont@enst-bretagne.fr; ipng@sunroof.eng.sun.com; > mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Re: Proposal for MIPv6 APIs to > switch default source address selection > > > > > > > > A simple api ext doc would be great. But not part of the advanced > > api. We need to ship the base and advanced apis now. > > > > That's what I was aiming for; a short and simple advanced api > socket extension doc as a guideline for MIPv6 compatible applications. > > I agree that the server side apps do not require change, but > some client side apps should change (like dns-client, > printer-client etc.) so that they don't have to send packets > all the way to the home-agent for doing the local job. > > Thanks for your comments. > -Samita > > > > > > > > -----Original Message----- > > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > > Sent: Thursday, November 21, 2002 9:49 PM > > > To: Francis Dupont > > > Cc: Samita Chakrabarti; ipng@sunroof.eng.sun.com; > > > mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to > > > switch default source address selection > > > > > > > > > > > > > > > > In your previous mail you wrote: > > > > > > > > An alternative approach could be: If the application > cares about > > > > the source address, it can use the Mobile IP API to > > > figure out which > > > > ones are home address, which ones are care-of > address, and than > > > > explicitly "bind" the socket to the desired address. > > > IMO, this would > > > > also satisfy the needs of the Mobile IPv6 mobile node. > > > > > > > > => this is similar to what I implemented in the past. > > > > But a function giving the list of addresses with status is > > > not enough, > > > > the best is to give the home address and the care-of > address for a > > > > destination. > > > > > > I see. When the mobile node has more than one pair of > > > home_address-care_of_address, then it won't really know which > > > one to pick. So, maybe, instead of exporting all this > > > information to the apps and giving them the control, it might > > > be better > > > to enable the app to say "bind this socket to any address, > > > preferably topologically correct (i.e., a CoA, or home > > > address when at home)". I suspect this is what Samita had in > > > her mind.. > > > > > > > As first info is getsockname() for bound sockets, > > > > I added a clone of getsockname() which returns the real > > > source address > > > > after MIPv6 processing. > > > > > > Or, don't change the getsockname(), but instead call > > > mip_get_one_mobile_node() afterwards to identify if the > > > address is bound to a care-of address. Note that this binding > > > can dynamically any time, and subsequent > > > mip_get_one_mobile_node() calls are sufficient to capture > the changes. > > > > > > alper > > > > > > > Note this doesn't solve the need of a control for smarter choice > > > > between Co@/H@. I proposed some and implemented two: use > > > always the H@ > > > > and use it but a Co@ when the destination is in the same > > > link then a > > > > Co@. They were global (still better than none :-). > > > > > > > > Thanks > > > > > > > > Francis.Dupont@enst-bretagne.fr > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: > http://playground.sun.com/ipng > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 08:52:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGq5Uu023245; Mon, 25 Nov 2002 08:52:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPGq47p023244; Mon, 25 Nov 2002 08:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGq1Uu023237 for ; Mon, 25 Nov 2002 08:52:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPGqCbB019009 for ; Mon, 25 Nov 2002 08:52:12 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16713 for ; Mon, 25 Nov 2002 09:51:58 -0700 (MST) Subject: RE: "unique enough" [RE: globally unique site local addresses] Date: Mon, 25 Nov 2002 08:51:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4C3@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: "unique enough" [RE: globally unique site local addresses] Thread-Index: AcKUW3y0lQ+yhCA0Q9KEhBmZhymO0wAQ6Cdg From: "Michel Py" To: "Pekka Nikander" Cc: "Margaret Wasserman" , "ipng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAPGq1Uu023238 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, >> Michel Py wrote: >> My $0.02 about the hash/random/collision issue: >> It's a non-issue. > Pekka Nikander wrote: > I would agree with you, but only if I shared the same > view of the GUPI prefix usage. This much is clear. However, I think the use you envision for GUPI is dangerous and will lead to NAT, which is also clear in the opinion you expressed about GUPI encouraging or discouraging NAT. In the example you use, a SOHO configuring their network, use of GUPI is a disaster, IMHO. Site-locals are not for SOHO sites, they need to talk to the public Internet. These people need to use global addresses. I don't challenge the need for globally unique PI addresses, but this would be GAPI not GUPI. As I mentioned before, we MUST NOT encourage the use of site-locals for people that don't understand their limitations, and this certainly applies to the SOHO example you used. GUPI still is site-local addresses, which are not routable on the public Internet, and will be successful in enterprises only if the comfort level of the administrator as reached the level that he is happy with the enforcement of non-routability. Back to what started this, the main four characteristics of GUPI are: 1. No fee and/or low fee. 2. No registration and/or easy registration. 3. Globally unique. 4. Not globally routable. I don't challenge the need for globally routable, globally unique identifiers. As a matter of fact, the scheme I proposed for GUPI is a spin-off GAPI. That being said, this is not the same battle. In the case of GUPI, we already have a block allocated for it: FEC0::/10. If we don't change the purpose of the block which is site-locals, there is a shorter path to success than GAPI that would require IANA to allocate a new block and is full of issues concerning the explosion of the global routing table. My message is: one problem at a time. GUPI is achievable short-term, not GAPI. Let's focus on what we can do now, which is globally unique, not globally routable and when this hurdle has been cleared then we can process towards globally unique and globally routable. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 08:57:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGvrUu023396; Mon, 25 Nov 2002 08:57:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPGvru2023395; Mon, 25 Nov 2002 08:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGvoUu023388 for ; Mon, 25 Nov 2002 08:57:50 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPGw1bB020528 for ; Mon, 25 Nov 2002 08:58:01 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13265 for ; Mon, 25 Nov 2002 09:57:55 -0700 (MST) 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 IAA23165; Mon, 25 Nov 2002 08:57:55 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAPGvsL27314; Mon, 25 Nov 2002 08:57:54 -0800 X-mProtect: <200211251657> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhSyjXb; Mon, 25 Nov 2002 08:57:53 PST Message-ID: <3DE25691.A32DE3CB@iprg.nokia.com> Date: Mon, 25 Nov 2002 08:57:53 -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: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <2B81403386729140A3A899A8B39B046405E4C2@server2000> 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: >> I don't think a fee is required at all. ...... >> This would solve the uniqueness problem, but all the other >> problems would remain. It seems to me that this also eliminates >> a requirement for "statistically unique" addresses for site-local. > > If the addresses were allocated randomly or with a hash I would agree > with you. However, what I proposed was addresses allocated > geographically, along the lines of being used as identifiers for a > dual-space multihoming solution, and this will require some work from > the RIRs (maintenance/monitoring of areas) thus the fee. My proposal is that we allocated them linearly -- starting at 1,000,000 or so and incrementing by one after each allocation. That's easy and effective. If you want something more structured, then that's solving a different problem and should be considered separately. One problem at a time, please! Whatever the freebie allocation algorithm is, it has to be simple enough to be free. If it costs even $0.01, then that means paperwork for the consumer probably including even an invoice and managerial approval. 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 Nov 25 08:58:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGwMUu023428; Mon, 25 Nov 2002 08:58:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPGwMo8023427; Mon, 25 Nov 2002 08:58:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPGwJUu023420 for ; Mon, 25 Nov 2002 08:58:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPGwUMq022364 for ; Mon, 25 Nov 2002 08:58:30 -0800 (PST) Received: from parsmtp2.rd.francetelecom.com (parsmtp2.rd.francetelecom.com [194.167.105.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13579 for ; Mon, 25 Nov 2002 09:58:24 -0700 (MST) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Nov 2002 17:58:24 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: Prefix delegation status Date: Mon, 25 Nov 2002 17:58:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Prefix delegation status Thread-Index: AcKUnlBFVszSZwZwRHOm9QSZK+GX5wABJxwA From: "NOISETTE Yoann FTRD/DMI/CAE" To: "Ole Troan" Cc: "Zerouter (E-mail)" , "Ipng (E-mail)" X-OriginalArrivalTime: 25 Nov 2002 16:58:24.0099 (UTC) FILETIME=[DDC41330:01C294A3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAPGwJUu023421 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Prefix delegation and router auto-configuration are different >>problems. Prefix delegation is trying to solve the problem of >>delegating a prefix across an administrative boundary between two >>routers. Zerorouter is working on the much larger problem of >>auto-configuring routers within a domain of arbitrary complex >>topology. YN: I agree with you, I didn't mean to say something different, sorry if my words lead to misunderstanding... >>Zerorouter may need prefix delegation, and PD solutions may >>be a part of the total zerorouter solution. YN: that's my point. Configuring a router means among many others acquiring prefixes to advertise on the interfaces (to be brief). Therefore, prefix delegation may be a part of the whole solution. That's why I was suggesting getting it into zerouter... Yoann -----Message d'origine----- De : Ole Troan [mailto:ot@cisco.com] Envoye : lundi 25 novembre 2002 17:19 A : NOISETTE Yoann FTRD/DMI/CAE Cc : Zerouter (E-mail); Ipng (E-mail) Objet : Re: Prefix delegation status > The prefix delegation document is one of the documents that is set as > priority for ipv6 WG, as it appears in the updated charter. However, > in the same time, zerouter works on the subnet assignment topic. Even > if the zerouter charter is to be extended, the subnet allocation topic > will remain one of importance and presentations of solutions have been > made in Atlanta in this context. Zerouter limits its scope to > solutions that support 10s of links networks. If we consider that > prefix delegation is to be deployed mainly in SOHOs (as big companies > will certainly manage their subnet allocation differently), then the > requirements document could fit in the work provided by > zerouter... therefore, leading to move the requirements document from > ipv6 to zerouter... Moreover, apart from the DHCPv6-option and RA > proxy solutions, the other solutions for prefix delegation are no WG > items, so they are actually considered as interesting documents for > zerouter. Wouldn't it be better (apart from the DHCP solution which is > DHCP specific) to gather all this work and propositions in zerouter ? I don't think so. Prefix delegation and router auto-configuration are different problems. Prefix delegation is trying to solve the problem of delegating a prefix across an administrative boundary between two routers. Zerorouter is working on the much larger problem of auto-configuring routers within a domain of arbitrary complex topology. Zerorouter may need prefix delegation, and PD solutions may be a part of the total zerorouter solution. /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 Nov 25 09:13:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPHD5Uu023928; Mon, 25 Nov 2002 09:13:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPHD4NM023927; Mon, 25 Nov 2002 09:13: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPHD1Uu023917 for ; Mon, 25 Nov 2002 09:13:01 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPHDCMq026628 for ; Mon, 25 Nov 2002 09:13:12 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13695 for ; Mon, 25 Nov 2002 10:13:07 -0700 (MST) Subject: RE: globally unique site local addresses Date: Mon, 25 Nov 2002 09:13:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4C5@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses Thread-Index: AcKUo+nMwoThlfFjT5qtSckMEw0x7AAAIOdQ 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 gAPHD1Uu023918 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, > Charlie Perkins wrote: > Whatever the freebie allocation algorithm is, it > has to be simple enough to be free. If it costs > even $0.01, then that means paperwork for the > consumer probably including even an invoice and > managerial approval. Agreed. > My proposal is that we allocated them linearly -- > starting at 1,000,000 or so and incrementing by one > after each allocation. That's easy and effective. I would support any scheme that makes site-locals unique as long as the non-reachability is enforced, but keep reading. > If you want something more structured,then that's > solving a different problem and should be considered > separately. One problem at a time, please! This makes sense, but the other side of this coin is that it might be a good idea to kill two birds with one stone if it does not require aiming for two years. In any case, the "one problem at a time" also applies to not trying to solve the problem of global PI with unique site-locals..... Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 09:17:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPHHCUu024026; Mon, 25 Nov 2002 09:17:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPHHC9X024025; Mon, 25 Nov 2002 09:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPHH8Uu024018 for ; Mon, 25 Nov 2002 09:17:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPHHJMq027819 for ; Mon, 25 Nov 2002 09:17:20 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27727 for ; Mon, 25 Nov 2002 10:17:14 -0700 (MST) Subject: RE: Enforcing unreachability of site local addresses Date: Mon, 25 Nov 2002 09:17:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4C6@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Enforcing unreachability of site local addresses Thread-Index: AcKUkdcl9rpHEFO1Rgy5DgL6CLImVQAFDh3g From: "Michel Py" To: "Steven Blake" , "Christian Huitema" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAPHH9Uu024019 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven, > Steven Blake wrote: > I'm having a hard time understanding why any of the > thousands of institutions with IPv4 PI address prefixes > would ever migrate to IPv6 if they had to give up PI > addressing. They would not, but the way of providing them PI addresses is not to punch holes in PA space that would lead us directly in the same swamp than IPv4. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 09:22:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPHMgUu024152; Mon, 25 Nov 2002 09:22:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPHMgkN024151; Mon, 25 Nov 2002 09:22: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPHMcUu024141 for ; Mon, 25 Nov 2002 09:22:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPHMnMq029361 for ; Mon, 25 Nov 2002 09:22:49 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05335 for ; Mon, 25 Nov 2002 10:22:42 -0700 (MST) Subject: RE: Summary & some possible long term consequences of GUPI prefixes Date: Mon, 25 Nov 2002 09:22:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4C7@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Summary & some possible long term consequences of GUPI prefixes Thread-Index: AcKUZ47P4ThDX3ZrR5a9x5vFjR5l7AAPwZpA From: "Michel Py" To: "Brian Carpenter" , "Pekka Nikander" Cc: "IPv6 WG" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAPHMcUu024142 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka / Brian >> Pekka Nikander wrote: >> More seriously, there would be a tendency to consider >> GUPI addresses as immutable identifiers for hosts, >> making the aggretable global PA addresses mere locators. Not the GUPI address, but a one-to-one relation with a GAPI address, as we probably want keep the site-local identifier separate from the global identifier. >> Thus, it might form a step towards an architecture >> where identifiers and locators are separated. >> Now, honestly, I do not know if that would be a good >> step or not. > Brian Carpenter wrote: > It would be an excellent step, as long as we > simultaneously architected a way to use this separation > that is more attractive to enterprises and ISPs than NAT. I very much agree with this. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 09:24:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPHOYUu024229; Mon, 25 Nov 2002 09:24:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPHOYHu024228; Mon, 25 Nov 2002 09:24:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPHOUUu024221 for ; Mon, 25 Nov 2002 09:24:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPHOfMq029969 for ; Mon, 25 Nov 2002 09:24:41 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06600 for ; Mon, 25 Nov 2002 10:24:35 -0700 (MST) 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 JAA24868; Mon, 25 Nov 2002 09:24:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAPHOYD25978; Mon, 25 Nov 2002 09:24:34 -0800 X-mProtect: <200211251724> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7tnUNy; Mon, 25 Nov 2002 09:24:33 PST Message-ID: <3DE25CD1.BE955DAA@iprg.nokia.com> Date: Mon, 25 Nov 2002 09:24:33 -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: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <2B81403386729140A3A899A8B39B046405E4C5@server2000> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Michel, Agreed on all points. I take your point about discussion time to mean that we should not get into a situation where a simple solution would be blocked while a solution with more features is devised. The feature set should be simple enough to be proposed and agreed upon right away. Regards, Charlie P. Michel Py wrote: > > Charlie, > > > Charlie Perkins wrote: > > Whatever the freebie allocation algorithm is, it > > has to be simple enough to be free. If it costs > > even $0.01, then that means paperwork for the > > consumer probably including even an invoice and > > managerial approval. > > Agreed. > > > My proposal is that we allocated them linearly -- > > starting at 1,000,000 or so and incrementing by one > > after each allocation. That's easy and effective. > > I would support any scheme that makes site-locals unique as long as the > non-reachability is enforced, but keep reading. > > > If you want something more structured,then that's > > solving a different problem and should be considered > > separately. One problem at a time, please! > > This makes sense, but the other side of this coin is that it might be a > good idea to kill two birds with one stone if it does not require aiming > for two years. > > In any case, the "one problem at a time" also applies to not trying to > solve the problem of global PI with unique site-locals..... > > Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 09:42:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPHgrUu024831; Mon, 25 Nov 2002 09:42:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPHgq8v024830; Mon, 25 Nov 2002 09:42: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPHgnUu024820 for ; Mon, 25 Nov 2002 09:42:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPHh0bB004666 for ; Mon, 25 Nov 2002 09:43:00 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04887 for ; Mon, 25 Nov 2002 10:42:54 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAPHgrE09475 for ; Mon, 25 Nov 2002 19:42:53 +0200 Date: Mon, 25 Nov 2002 19:42:53 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: even one reason why provably unique SL is needed? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, People seem to be dodging this, so let's take it into another thread. There seems to be an assumption that provably unique SL addresses would be needed. Can you tell me at least one reason (note: don't say globally routable) where this would be required instead of "nearly enough" unique identifiers (chance of collision about 1/2^38)? Why I prefer "nearly unique"? Some reasons from the top of the head: - 2^38 is big enough to be in practise collision-free - there is no need for _any_ registration infrastructure <=== !!!! - automatical generation is easier, also for e.g. disconnected sites - people don't get funny ideas they could be totally collision-free and thus routable in the internet; or use them as global identifiers - gives people some reason to use _globals_ too, when they're really to be used But then again, my take is that we shouldn't be advocating these unique SL's everywhere anyway, most should just be able to stick to globals. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 10:05:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPI5GUu025081; Mon, 25 Nov 2002 10:05:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPI5Gtb025080; Mon, 25 Nov 2002 10:05:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPI5CUu025073 for ; Mon, 25 Nov 2002 10:05:12 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPI5ObB011435 for ; Mon, 25 Nov 2002 10:05:24 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12882 for ; Mon, 25 Nov 2002 10:05:18 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAPI59l10750; Mon, 25 Nov 2002 13:05:09 -0500 (EST) Message-Id: <200211251805.gAPI59l10750@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Charlie Perkins" , ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses In-reply-to: (Your message of "Mon, 25 Nov 2002 07:58:10 PST.") <2B81403386729140A3A899A8B39B046405E4C2@server2000> Date: Mon, 25 Nov 2002 13:05:09 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If the addresses were allocated randomly or with a hash I would agree > with you. However, what I proposed was addresses allocated > geographically, along the lines of being used as identifiers for a > dual-space multihoming solution, and this will require some work from > the RIRs (maintenance/monitoring of areas) thus the fee. one interesting characteristic of geographic addresses is that if nearby parties pick the same prefixes due to a lack of precision, it should be easy for them to find one another - just start knocking on nearby doors :) 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 Nov 25 10:21:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPILwUu025213; Mon, 25 Nov 2002 10:21:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPILwej025212; Mon, 25 Nov 2002 10:21: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPILtUu025205 for ; Mon, 25 Nov 2002 10:21:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPIM6Mq016338 for ; Mon, 25 Nov 2002 10:22:06 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08731 for ; Mon, 25 Nov 2002 11:21:57 -0700 (MST) Subject: RE: globally unique site local addresses Date: Mon, 25 Nov 2002 10:19:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B04640BD44B@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: globally unique site local addresses Thread-Index: AcKUp5rgmPZXiQAtRVq57Kmk+Qbr3gAB4zAw 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 gAPILtUu025206 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, > Charles E. Perkins > Agreed on all points. I take your point about > discussion time to mean that we should not get > into a situation where a simple solution would > be blocked while a solution with more features > is devised. The feature set should be simple > enough to be proposed and agreed upon right > away. Your proposal makes a lot of sense to me and I will support it. I will try to sneak mine in as a complement to yours. If it takes too much time or does not reach consensus I'll withdraw it. I would suggest to reserve a handful of /16s out of FEC0::/10 for future use in any case. Let me emphasize again that none of this stuff goes anywhere is there is no default enforcement of non-routability along the lines that Bob Hinden, Christian Huitema and myself have contributed, and I have not heard many comments about that part. I guess I'll try to convince on this geo GUPI thing until we have consensus on non-routability. About my proposal of using geography to allocate globally unique site-locals instead of Charlie's sequential, it does not bring anything to the table sort-term, but it could in the longer term. It all boils down to someone wanting to undertake allocating them according to: http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt I personally think that RIRs should be involved in this, but are there any other takers? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 11:06:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPJ6jUu025353; Mon, 25 Nov 2002 11:06:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPJ6iPO025352; Mon, 25 Nov 2002 11:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPJ6eUu025345 for ; Mon, 25 Nov 2002 11:06:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPJ6pMq000658 for ; Mon, 25 Nov 2002 11:06:52 -0800 (PST) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15139 for ; Mon, 25 Nov 2002 12:06:46 -0700 (MST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id DA54A1E0B8; Mon, 25 Nov 2002 14:05:57 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id OAA23727; Mon, 25 Nov 2002 14:05:57 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id AE7CB7B6B; Mon, 25 Nov 2002 14:05:56 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Nov 2002 14:05:56 -0500 Message-Id: <20021125190556.AE7CB7B6B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Pekka Savola w rites: >Hello, > >People seem to be dodging this, so let's take it into another thread. > >There seems to be an assumption that provably unique SL addresses would be >needed. > >Can you tell me at least one reason (note: don't say globally routable) >where this would be required instead of "nearly enough" unique identifiers >(chance of collision about 1/2^38)? You run into the birthday paradox here. In a space of 2^38 address blocks, with 2^19 "allocations" there's a 50% chance of at least one collision. Given how many home networks will be using this stuff, we'll have far more than 2^19. But that's not the interesting question. The interesting question is what the odds are of two users of the space "colliding", and that in turn depends on the average connectivity. On that I have insufficient data. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("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 Mon Nov 25 11:08:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPJ8LUu025371; Mon, 25 Nov 2002 11:08:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPJ8LdQ025369; Mon, 25 Nov 2002 11:08:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPJ8HUu025362 for ; Mon, 25 Nov 2002 11:08:17 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPJ8SMq001185 for ; Mon, 25 Nov 2002 11:08:28 -0800 (PST) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16245 for ; Mon, 25 Nov 2002 12:08:22 -0700 (MST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 928B51E0B8 for ; Mon, 25 Nov 2002 14:08:22 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id OAA23797 for ; Mon, 25 Nov 2002 14:08:22 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id B75277B6B for ; Mon, 25 Nov 2002 14:08:21 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Steve Bellovin To: ipng@sunroof.eng.sun.com Subject: a different approach to site-local's "security" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Nov 2002 14:08:21 -0500 Message-Id: <20021125190821.B75277B6B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some people want the "security" that site-local brings. For a different approach that's about as easy but more flexible -- and without the architectural complexities of site-local -- see http://www.research.att.com/~smb/papers/draft-bellovin-ipv6-accessprefix-00.txt (I've submitted it to internet-drafts, but they've got a backlog to clear.) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("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 Mon Nov 25 11:18:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPJIfUu025575; Mon, 25 Nov 2002 11:18:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPJIfxl025574; Mon, 25 Nov 2002 11:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPJIcUu025567 for ; Mon, 25 Nov 2002 11:18:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPJInMq004304 for ; Mon, 25 Nov 2002 11:18:49 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23637 for ; Mon, 25 Nov 2002 12:18:43 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAPJIeO10414; Mon, 25 Nov 2002 21:18:40 +0200 Date: Mon, 25 Nov 2002 21:18:39 +0200 (EET) From: Pekka Savola To: "Steven M. Bellovin" cc: ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? In-Reply-To: <20021125190556.AE7CB7B6B@berkshire.research.att.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, 25 Nov 2002, Steven M. Bellovin wrote: > You run into the birthday paradox here. In a space of 2^38 address > blocks, with 2^19 "allocations" there's a 50% chance of at least one > collision. Given how many home networks will be using this stuff, > we'll have far more than 2^19. > > But that's not the interesting question. The interesting question is > what the odds are of two users of the space "colliding", and that in > turn depends on the average connectivity. On that I have insufficient > data. The requirement for birthday paradox to be valid is when those networks are totally interconnected; for that, the number is like 2^19. I fail to see valid scenarios where even 2^5 site-local networks would be interconnected. I'm still assuming the site-locals, are, well, site locals. So valid interconnections would be: 1) sites connecting (e.g. two physical locations of one organization) 2) site-local address info leaking though some ways outside of sites where there is site-local connectivity 1) is which seems to be critical, but I still fail to see a huge need for interconnection. 2) should not be relevant in the case that collisions are extremely rare, as the connections will fail anyway (the question is only _how_). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 11:33:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPJX3Uu025697; Mon, 25 Nov 2002 11:33:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPJX372025696; Mon, 25 Nov 2002 11:33:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPJWxUu025689 for ; Mon, 25 Nov 2002 11:32:59 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPJXAMq008683 for ; Mon, 25 Nov 2002 11:33:10 -0800 (PST) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08405 for ; Mon, 25 Nov 2002 11:33:04 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 731204CECC; Mon, 25 Nov 2002 14:33:04 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id OAA24835; Mon, 25 Nov 2002 14:33:03 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 6D08C7B6B; Mon, 25 Nov 2002 14:33:03 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Nov 2002 14:33:03 -0500 Message-Id: <20021125193303.6D08C7B6B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Pekka Savola writes: >On Mon, 25 Nov 2002, Steven M. Bellovin wrote: >> You run into the birthday paradox here. In a space of 2^38 address >> blocks, with 2^19 "allocations" there's a 50% chance of at least one >> collision. Given how many home networks will be using this stuff, >> we'll have far more than 2^19. >> >> But that's not the interesting question. The interesting question is >> what the odds are of two users of the space "colliding", and that in >> turn depends on the average connectivity. On that I have insufficient >> data. > >The requirement for birthday paradox to be valid is when those networks >are totally interconnected; for that, the number is like 2^19. > >I fail to see valid scenarios where even 2^5 site-local networks would be >interconnected. > >I'm still assuming the site-locals, are, well, site locals. > >So valid interconnections would be: > 1) sites connecting (e.g. two physical locations of one organization) > 2) site-local address info leaking though some ways outside of sites >where there is site-local connectivity > >1) is which seems to be critical, but I still fail to see a huge need for >interconnection. > >2) should not be relevant in the case that collisions are extremely rare, >as the connections will fail anyway (the question is only _how_). > Don't forget mergers and private interconnects. The latter are *very* common, even without counting telecommuters. One shouldn't use site-local there, but it's a path that often bypasses firewalls and other official demarcation points. If interconnections never occur, we don't need to worry about the problems that can happen. My fear is that they occur all too often. (What percentage of queries to the root name servers come from 1918 addresses?) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("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 Mon Nov 25 11:40:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPJe7Uu025781; Mon, 25 Nov 2002 11:40:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPJe6fe025780; Mon, 25 Nov 2002 11:40: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPJe2Uu025773 for ; Mon, 25 Nov 2002 11:40:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPJeAbB011232 for ; Mon, 25 Nov 2002 11:40:10 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25093 for ; Mon, 25 Nov 2002 12:40:03 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAPJckl11302; Mon, 25 Nov 2002 14:38:46 -0500 (EST) Message-Id: <200211251938.gAPJckl11302@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? In-reply-to: (Your message of "Mon, 25 Nov 2002 19:42:53 +0200.") Date: Mon, 25 Nov 2002 14:38:46 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk actually I'm fairly convinced that "nearly unique" would be good enough as long as we could convince people to actually assign random site prefixes instead of just choosing one (like all zeros or whatever). and they seem to have the "right" property regarding routability - the chance of collisions is so low that you can hook them up with a large number of other networks via private arrangement without fear of collision, but high enough that there's a clear incentive for ISPs to filter these things from routing advertisements. 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 Nov 25 11:41:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPJfVUu025816; Mon, 25 Nov 2002 11:41:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPJfUYL025815; Mon, 25 Nov 2002 11:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPJfRUu025808 for ; Mon, 25 Nov 2002 11:41:27 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPJfcMq011076 for ; Mon, 25 Nov 2002 11:41:38 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13603 for ; Mon, 25 Nov 2002 11:41:33 -0800 (PST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 25 Nov 2002 11:41:33 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Nov 2002 11:41:32 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Mon, 25 Nov 2002 11:41:33 -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); Mon, 25 Nov 2002 11:41:32 -0800 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.3710.0); Mon, 25 Nov 2002 11:41:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: even one reason why provably unique SL is needed? Date: Mon, 25 Nov 2002 11:41:32 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: even one reason why provably unique SL is needed? Thread-Index: AcKUuRKJxv1KmIUETxOHD2MEgjXEfgAAFQMw From: "Christian Huitema" To: "Pekka Savola" , "Steven M. Bellovin" Cc: X-OriginalArrivalTime: 25 Nov 2002 19:41:27.0637 (UTC) FILETIME=[A5358050:01C294BA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAPJfRUu025809 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, You keep ignoring one of the requirements: that we be able to find out who is leaking information when "local" addresses leak through applications, or through management protocols. Random numbers don't give you that. Also, you should never underestimate how bad people and computers are at picking random numbers. And you should also never underestimate the malicious users who will deliberately pick the "wrong" value and cause trouble. There are several ways to provide global uniqueness: registration is one; reuse of an already registered number is another. Among the candidates that we could consider: * IPv4 addresses, for those who already have them: 32 bits. * Telephone numbers: we can encode 11 digits in 37 bits. * Various unique enterprise numbers. Such numbers can easily be configured offline. -- 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 Nov 25 12:31:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPKV6Uu026353; Mon, 25 Nov 2002 12:31:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPKV6V1026352; Mon, 25 Nov 2002 12:31:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPKV3Uu026345 for ; Mon, 25 Nov 2002 12:31:03 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPKVEMq000131 for ; Mon, 25 Nov 2002 12:31:14 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14203 for ; Mon, 25 Nov 2002 12:31:08 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAPKV3T11085; Mon, 25 Nov 2002 22:31:03 +0200 Date: Mon, 25 Nov 2002 22:31:03 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: "Steven M. Bellovin" , Subject: RE: even one reason why provably unique SL is needed? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Nov 2002, Christian Huitema wrote: > You keep ignoring one of the requirements: that we be able to find out > who is leaking information when "local" addresses leak through > applications, or through management protocols. Random numbers don't give > you that. Such paths can be traced from messages (look at the source of e.g. SMTP message); the advantage of globally registered addresses is that you can look it up in the assignments table (unless the address was misconfigured/spoofed). Basically you still have to trace it. So, I'm not sure how useful this requirement is. > Also, you should never underestimate how bad people and > computers are at picking random numbers. People -- should people pick these anyway? Problem is naturally that people just pick all-zeroes or something like that. Computers -- I don't agree, provided enough keying material is provided. > And you should also never > underestimate the malicious users who will deliberately pick the "wrong" > value and cause trouble. Nothing prevents from malicious users, not even "really unique" allocations. > There are several ways to provide global uniqueness: registration is > one; reuse of an already registered number is another. Among the > candidates that we could consider: > > * IPv4 addresses, for those who already have them: 32 bits. > * Telephone numbers: we can encode 11 digits in 37 bits. > * Various unique enterprise numbers. > > Such numbers can easily be configured offline. I'm not insisting on random strings. Some of those mechanisms would be practically equivalent to what I'm proposing. IPv4 addresses, can't really be considered unique enough (ISP changes, RFC1918 addresses, etc.), though. What I'm against, is trying to make to some global registry like IANA. That kind of hierarchy is too heavy, and IMO against the spirit of _site-local_ addressing. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 12:33:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPKXkUu026418; Mon, 25 Nov 2002 12:33:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPKXkFg026417; Mon, 25 Nov 2002 12:33: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPKXhUu026410 for ; Mon, 25 Nov 2002 12:33:43 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPKXsMq001098 for ; Mon, 25 Nov 2002 12:33:54 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15830 for ; Mon, 25 Nov 2002 12:33:48 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAPKXii11111; Mon, 25 Nov 2002 22:33:44 +0200 Date: Mon, 25 Nov 2002 22:33:43 +0200 (EET) From: Pekka Savola To: Keith Moore cc: ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? In-Reply-To: <200211251938.gAPJckl11302@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Nov 2002, Keith Moore wrote: > actually I'm fairly convinced that "nearly unique" would be good enough > as long as we could convince people to actually assign random site > prefixes instead of just choosing one (like all zeros or whatever). Yes, this is the problem.. but the way it's written down or helper apps included in the implementations to do this for you would help, I suggest. > and they seem to have the "right" property regarding routability - > the chance of collisions is so low that you can hook them up with > a large number of other networks via private arrangement without > fear of collision, but high enough that there's a clear incentive > for ISPs to filter these things from routing advertisements. Exactly. I don't think we should be providing totally unique PI addresses. There's just no need for them. Or actually there is, _but that's not in the site-local context_. So I fear if we provide totally unique PI addresses, people would just abuse them, sooner or later. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 12:41:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPKfeUu026663; Mon, 25 Nov 2002 12:41:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPKfe0r026662; Mon, 25 Nov 2002 12:41:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPKfZUu026649 for ; Mon, 25 Nov 2002 12:41:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPKfkbB029882 for ; Mon, 25 Nov 2002 12:41:46 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA28619 for ; Mon, 25 Nov 2002 13:41:24 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAPKe5l11816; Mon, 25 Nov 2002 15:40:05 -0500 (EST) Message-Id: <200211252040.gAPKe5l11816@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? In-reply-to: (Your message of "Mon, 25 Nov 2002 22:33:43 +0200.") Date: Mon, 25 Nov 2002 15:40:05 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't think we should be providing totally unique PI addresses. > There's just no need for them. mumble - being able to track down attackers' prefixes really would be useful. but that would require that routers only route registered prefixes between sites. I don't know how to enforce, or even encourage, 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 Mon Nov 25 12:52:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPKq0Uu026816; Mon, 25 Nov 2002 12:52:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPKq0Z6026815; Mon, 25 Nov 2002 12:52:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPKpuUu026805 for ; Mon, 25 Nov 2002 12:51:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPKq7bB002737 for ; Mon, 25 Nov 2002 12:52:07 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02301 for ; Mon, 25 Nov 2002 13:52:01 -0700 (MST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id UAA16640; Mon, 25 Nov 2002 20:51:57 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Keith Moore Cc: Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? References: <200211251938.gAPJckl11302@astro.cs.utk.edu> From: Ole Troan Date: Mon, 25 Nov 2002 20:51:57 +0000 In-Reply-To: <200211251938.gAPJckl11302@astro.cs.utk.edu> (Keith Moore's message of "Mon, 25 Nov 2002 14:38:46 -0500") Message-ID: <7t5el991ifm.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, > actually I'm fairly convinced that "nearly unique" would be good enough > as long as we could convince people to actually assign random site > prefixes instead of just choosing one (like all zeros or whatever). > > and they seem to have the "right" property regarding routability - > the chance of collisions is so low that you can hook them up with > a large number of other networks via private arrangement without > fear of collision, but high enough that there's a clear incentive > for ISPs to filter these things from routing advertisements. what is your position on probably unique local addresses versus site-locals? as probably unique addresses have a limited topological span wouldn't applications still have pretty much the same issues as with 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 Nov 25 13:00:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPL0nUu027006; Mon, 25 Nov 2002 13:00:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPL0nsb027005; Mon, 25 Nov 2002 13:00:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPL0kUu026998 for ; Mon, 25 Nov 2002 13:00:46 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPL0vbB005449 for ; Mon, 25 Nov 2002 13:00:57 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08028 for ; Mon, 25 Nov 2002 13:00:51 -0800 (PST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gAPL0CSd006358; Tue, 26 Nov 2002 08:00:12 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211252100.gAPL0CSd006358@drugs.dv.isc.org> To: Keith Moore Cc: Pekka Savola , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: even one reason why provably unique SL is needed? In-reply-to: Your message of "Mon, 25 Nov 2002 14:38:46 CDT." <200211251938.gAPJckl11302@astro.cs.utk.edu> Date: Tue, 26 Nov 2002 08:00:12 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > actually I'm fairly convinced that "nearly unique" would be good enough > as long as we could convince people to actually assign random site > prefixes instead of just choosing one (like all zeros or whatever). > > and they seem to have the "right" property regarding routability - > the chance of collisions is so low that you can hook them up with > a large number of other networks via private arrangement without > fear of collision, but high enough that there's a clear incentive > for ISPs to filter these things from routing advertisements. > > 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 > -------------------------------------------------------------------- "nearly unique" is not good enough. You want to be able to register these addresses in the ip6.arpa tree. You don't want to force every site to manually configure the top of their reverse tree into every nameserver in the organisation. This will not work and will just result in reverse queries for this address range hitting the ip6.arpa servers similar to what happens with the RFC 1918 nets under in-addr.arpa. We would then have to set up sacrificial servers as we don't have anyone to point too to say "set up your reverse servers as you are impacting on the ip6.arpa servers". What does work is having truly unique addresses and delegating the reverse servers. 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 Mon Nov 25 13:03:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPL3CUu027051; Mon, 25 Nov 2002 13:03:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPL3Cdt027050; Mon, 25 Nov 2002 13:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPL39Uu027042 for ; Mon, 25 Nov 2002 13:03:09 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPL3KbB006206 for ; Mon, 25 Nov 2002 13:03:20 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04076 for ; Mon, 25 Nov 2002 14:03:14 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAPL3C011424; Mon, 25 Nov 2002 23:03:12 +0200 Date: Mon, 25 Nov 2002 23:03:11 +0200 (EET) From: Pekka Savola To: Steve Bellovin cc: ipng@sunroof.eng.sun.com Subject: Re: a different approach to site-local's "security" In-Reply-To: <20021125190821.B75277B6B@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, On Mon, 25 Nov 2002, Steve Bellovin wrote: > Some people want the "security" that site-local brings. For a > different approach that's about as easy but more flexible -- and > without the architectural complexities of site-local -- see > http://www.research.att.com/~smb/papers/draft-bellovin-ipv6-accessprefix-00.txt > (I've submitted it to internet-drafts, but they've got a backlog to > clear.) I like this approach as the trust model of router advertisements and configuration appears to be similar. One general worry is whether the RA's are the right place for doing something like this, and whether this includes "RA explosion". One alternative solution would be an option in e.g. router solication/neighbor solicitation (directed at the config'd router), explicitly asking for the info by defining a bit in the ND header. I'm not sure what is best. Comments: 1) the proposed solution will prevent neighbor discovery, as link-local multicast address is not allowed as destination. Also, what about the first DAD packet with the unspecified address.. 2) prefix lifetime; would there be any restrictions on withdrawal of it, like there is one of 2 hours in default route advertisements. 3) I'm not sure if link-locals should be overridable; it's just way too easy to screw up the system intentionally/unintentionally.. 4) 'class' is essentially required if we have differently scoped dumb devices in the same segment, and we want to do config shortcut ("in the printer menu, select class X"). If we concentrate on dumb devices, I believe class is pretty much unnecessary (or at most, there could be like 3 bits to use, the rest being reserved) 5) I'd be much harsher against "security" of this option in the security considerations; in particular, the last paragraph protections only protect from most off-link attackers, you can do anything if you're on-link. 6) perhaps the applicability of this mechanism should be restricted to be used only on physical links, ie. tunneling (which introduces remote off-link attacks using link-local addresses and hop count of 255) or pseudo-interfaces could be forbidden. btw. doesn't specify if prfxlen > 128 is received, but I guess it's obviously silently discard. HTH -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 13:21:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPLL0Uu027466; Mon, 25 Nov 2002 13:21:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPLL07t027465; Mon, 25 Nov 2002 13:21:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPLKuUu027458 for ; Mon, 25 Nov 2002 13:20:56 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPLL7Mq014062 for ; Mon, 25 Nov 2002 13:21:08 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15102 for ; Mon, 25 Nov 2002 14:21:02 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAPLJel12190; Mon, 25 Nov 2002 16:19:40 -0500 (EST) Message-Id: <200211252119.gAPLJel12190@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ole Troan cc: Keith Moore , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? In-reply-to: (Your message of "Mon, 25 Nov 2002 20:51:57 GMT.") <7t5el991ifm.fsf@mrwint.cisco.com> Date: Mon, 25 Nov 2002 16:19:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > what is your position on probably unique local addresses versus > site-locals? as probably unique addresses have a limited topological > span wouldn't applications still have pretty much the same issues as > with site-locals? no. first, probably unique addresses don't have any strict limits on their topological span - done right they could be routed to thousands of networks - just not to *every* network. second, the biggest problems with site-locals are not that they might get exposed to areas of the network from which those addresses are not reachable, but that they're ambiguous. 'probably unique' addresses (given a sufficient number of random bits) are effectively unambiguous. it seems like the goal here is to find the best mechanism to encourage the sites that use these addresses to pick prefixes that are in practice unique within the transitive closure of the set of networks to which they connect. this is mostly a human factors question. right now I'm thinking that the real trick is getting network operators to learn how to get a (probably or not) unique prefix by any means - and that the difference between going to a registry, running a random number generator, deriving a prefix from some other number, or getting a prefix from a tag stuck to a router - is probably noise compared with the educational effort common to all of these. 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 Nov 25 13:31:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPLVhUu027959; Mon, 25 Nov 2002 13:31:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPLVguZ027958; Mon, 25 Nov 2002 13:31:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPLVcUu027951 for ; Mon, 25 Nov 2002 13:31:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPLVnMq017243 for ; Mon, 25 Nov 2002 13:31:49 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24892 for ; Mon, 25 Nov 2002 14:31:44 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAPLT8l12401; Mon, 25 Nov 2002 16:29:08 -0500 (EST) Message-Id: <200211252129.gAPLT8l12401@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark.Andrews@isc.org cc: Keith Moore , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? In-reply-to: (Your message of "Tue, 26 Nov 2002 08:00:12 +1100.") <200211252100.gAPL0CSd006358@drugs.dv.isc.org> Date: Mon, 25 Nov 2002 16:29:08 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > "nearly unique" is not good enough. You want to be able to > register these addresses in the ip6.arpa tree. yeech. it's a good point. Keith p.s. though I can't help but think that something is terribly broken about our way of doing address lookups if it imposes this kind of constraint on how we assign 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 Mon Nov 25 13:37:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPLb1Uu028115; Mon, 25 Nov 2002 13:37:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPLb1a8028114; Mon, 25 Nov 2002 13: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPLawUu028107 for ; Mon, 25 Nov 2002 13:36:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPLb9Mq018805 for ; Mon, 25 Nov 2002 13:37:09 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28005 for ; Mon, 25 Nov 2002 14:37:03 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAPLauA11828; Mon, 25 Nov 2002 23:36:56 +0200 Date: Mon, 25 Nov 2002 23:36:55 +0200 (EET) From: Pekka Savola To: Mark.Andrews@isc.org cc: Keith Moore , Subject: Re: even one reason why provably unique SL is needed? In-Reply-To: <200211252100.gAPL0CSd006358@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 26 Nov 2002 Mark.Andrews@isc.org wrote: > "nearly unique" is not good enough. You want to be able to > register these addresses in the ip6.arpa tree. You don't > want to force every site to manually configure the top of > their reverse tree into every nameserver in the organisation. I don't want the administrative pain in the ass of someone managing flat ip6.arpa reverses. No way, no way at all. Require the DNS server at the edge of the site be authoritative for the whole of fec0::/10 or blackhole the queries. (I don't think too many people would even want to register site-locals in the _global_ reverse DNS, queriable by anyone -- remember, they're not to be used globally, and reverses in and itself are already considered a "security hazard" by some.) Let's not go down the path of putting site-locals anywhere near the global ip6.arpa. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 13:48:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPLmOUu028569; Mon, 25 Nov 2002 13:48:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPLmN9m028568; Mon, 25 Nov 2002 13:48:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPLmKUu028561 for ; Mon, 25 Nov 2002 13:48:20 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPLmVbB019318 for ; Mon, 25 Nov 2002 13:48:31 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04709 for ; Mon, 25 Nov 2002 13:48:25 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAPLjnl12537; Mon, 25 Nov 2002 16:45:49 -0500 (EST) Message-Id: <200211252145.gAPLjnl12537@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Mark.Andrews@isc.org, Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? In-reply-to: (Your message of "Mon, 25 Nov 2002 23:36:55 +0200.") Date: Mon, 25 Nov 2002 16:45:49 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > (I don't think too many people would even want to register site-locals in > the _global_ reverse DNS, queriable by anyone -- remember, they're not to > be used globally, no, it doesn't follow. it seems to me that the thing we need to do is to not to try to prevent leakage, but to make sure that leaked addresses don't cause harm. if we actually had globally unique site-locals, I don't see why we should try to stop people listing them in DNS. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 13:52:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPLqDUu028802; Mon, 25 Nov 2002 13:52:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPLqDod028801; Mon, 25 Nov 2002 13:52:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPLq8Uu028790 for ; Mon, 25 Nov 2002 13:52:08 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPLqJbB020658 for ; Mon, 25 Nov 2002 13:52:19 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01399 for ; Mon, 25 Nov 2002 13:52:14 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id E05F71E00F; Mon, 25 Nov 2002 16:52:12 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id QAA28196; Mon, 25 Nov 2002 16:52:11 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 0C4BF7B6B; Mon, 25 Nov 2002 16:52:11 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Pekka Savola Cc: Mark.Andrews@isc.org, Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Nov 2002 16:52:11 -0500 Message-Id: <20021125215211.0C4BF7B6B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Pekka Savola writes: >On Tue, 26 Nov 2002 Mark.Andrews@isc.org wrote: >> "nearly unique" is not good enough. You want to be able to >> register these addresses in the ip6.arpa tree. You don't >> want to force every site to manually configure the top of >> their reverse tree into every nameserver in the organisation. > >I don't want the administrative pain in the ass of someone managing flat >ip6.arpa reverses. > >No way, no way at all. > >Require the DNS server at the edge of the site be authoritative for the >whole of fec0::/10 or blackhole the queries. > >(I don't think too many people would even want to register site-locals in >the _global_ reverse DNS, queriable by anyone -- remember, they're not to >be used globally, and reverses in and itself are already considered a >"security hazard" by some.) > >Let's not go down the path of putting site-locals anywhere near the global >ip6.arpa. Sure -- but to keep the load off the root, we need to be *very* sure that sites do pretend to be authoritative for them. Hmm -- people *won't* do that properly. But suppose that whenever a high-level resolver sees an inverse query for , it synthesizes an NS record with a long TTL saying that that prefix is served up by or some other well-known number. Better yet, it can reply with . It doesn't stop people from asking once; it does "encourage" them to look elsewhere on subsequent queries over the next week... --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("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 Mon Nov 25 13:55:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPLtAUu029087; Mon, 25 Nov 2002 13:55:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPLtAQR029084; Mon, 25 Nov 2002 13:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPLt6Uu029067 for ; Mon, 25 Nov 2002 13:55:06 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPLtHbB021641 for ; Mon, 25 Nov 2002 13:55:17 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08791 for ; Mon, 25 Nov 2002 13:55:11 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAPLt2312019; Mon, 25 Nov 2002 23:55:02 +0200 Date: Mon, 25 Nov 2002 23:55:02 +0200 (EET) From: Pekka Savola To: Keith Moore cc: Mark.Andrews@isc.org, Subject: Re: even one reason why provably unique SL is needed? In-Reply-To: <200211252145.gAPLjnl12537@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Nov 2002, Keith Moore wrote: > > (I don't think too many people would even want to register site-locals in > > the _global_ reverse DNS, queriable by anyone -- remember, they're not to > > be used globally, > > no, it doesn't follow. > > it seems to me that the thing we need to do is to not to try to prevent > leakage, but to make sure that leaked addresses don't cause harm. I could live with that. > if we actually had globally unique site-locals, I don't see why we should > try to stop people listing them in DNS. "There is no free lunch." The whole concept of trying to put something like that in the reverse DNS (possibly meaning a flat space) makes my head hurt. At first sight, the cost seems _way_ too high, and profit borne only by few. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 14:33:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPMXRUu000819; Mon, 25 Nov 2002 14:33:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPMXRih000818; Mon, 25 Nov 2002 14:33: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPMXOUu000811 for ; Mon, 25 Nov 2002 14:33:24 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPMXZMq007268 for ; Mon, 25 Nov 2002 14:33:35 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00321 for ; Mon, 25 Nov 2002 15:33:30 -0700 (MST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gAPMXPu4013219 for ; Mon, 25 Nov 2002 14:33:25 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAS31071; Mon, 25 Nov 2002 14:26:28 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA18473; Mon, 25 Nov 2002 14:33:19 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15842.42287.175627.680904@thomasm-u1.cisco.com> Date: Mon, 25 Nov 2002 14:33:19 -0800 (PST) To: Subject: one question... In-Reply-To: References: <200211252145.gAPLjnl12537@astro.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 [] So I've been watching this debate about globally ~unique site locals and I don't understand how the end node knows whether a particular destination address is in scope (reachable) or not. The old way, it just matched it to its own scoped prefix and was done with it. What I've been hearing is some desire to be able to patch together other sites (extranets)... how would a node know which scope address to use in that case? 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 Nov 25 15:47:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPNlEUu001396; Mon, 25 Nov 2002 15:47:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPNlDSK001395; Mon, 25 Nov 2002 15:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPNlAUu001388 for ; Mon, 25 Nov 2002 15:47:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPNlLbB027242 for ; Mon, 25 Nov 2002 15:47:22 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA13452 for ; Mon, 25 Nov 2002 16:47:16 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA25915 for ; Mon, 25 Nov 2002 23:47:15 GMT Received: from login.ecs.soton.ac.uk (IDENT:6o77U+SLVmEMYkz9DuNI6clhYf4jWH6c@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAPNl7WX030022 for ; Mon, 25 Nov 2002 23:47:07 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gAPNl7631441 for ipng@sunroof.eng.sun.com; Mon, 25 Nov 2002 23:47:07 GMT Date: Mon, 25 Nov 2002 23:47:07 +0000 From: Tim Chown To: ipng Subject: Re: "unique enough" [RE: globally unique site local addresses] Message-ID: <20021125234706.GE30922@login.ecs.soton.ac.uk> Mail-Followup-To: ipng References: <2B81403386729140A3A899A8B39B046405E4C3@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046405E4C3@server2000> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Nov 25, 2002 at 08:51:45AM -0800, Michel Py wrote: > > As I mentioned before, we MUST NOT encourage the use of site-locals for > people that don't understand their limitations, and this certainly > applies to the SOHO example you used. So how do I print to my net printer in between connections to my ISP when I get a different prefix each time I connect? I want some kind of addresses to use locally equivalent to Net10. Not for NAT, but to communicate internally while offline. I think this discussion has forgotten a lot of the pro/con points made in the previous 500-mail thread, and at Atlanta :) 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 Nov 25 15:52:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPNqpUu001560; Mon, 25 Nov 2002 15:52:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPNqpRd001559; Mon, 25 Nov 2002 15:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPNqmUu001550 for ; Mon, 25 Nov 2002 15:52:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPNqxMq003662 for ; Mon, 25 Nov 2002 15:52:59 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA08627 for ; Mon, 25 Nov 2002 16:52:53 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA25979 for ; Mon, 25 Nov 2002 23:52:51 GMT Received: from login.ecs.soton.ac.uk (IDENT:B8/RwMDWYvv2Gng7SZlkMvXWA9AIp2Vz@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAPNqkWX030633 for ; Mon, 25 Nov 2002 23:52:46 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gAPNqkr31496 for ipng@sunroof.eng.sun.com; Mon, 25 Nov 2002 23:52:46 GMT Date: Mon, 25 Nov 2002 23:52:46 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses Message-ID: <20021125235246.GF30922@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <2B81403386729140A3A899A8B39B04640BD44B@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B04640BD44B@server2000> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Nov 25, 2002 at 10:19:55AM -0800, Michel Py wrote: > > Let me emphasize again that none of this stuff goes anywhere is there is > no default enforcement of non-routability along the lines that Bob > Hinden, Christian Huitema and myself have contributed, and I have not > heard many comments about that part. Indeed. I'm a little confused that GUPI = site-local, nothing really new only we're (in PekkaS's method) just "randomising" which site-local is used, so all the bad things of site-locals remain (which I'm sure Keith *could* remind us of :) 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 Nov 25 15:58:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPNwTUu001792; Mon, 25 Nov 2002 15:58:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAPNwSZe001791; Mon, 25 Nov 2002 15:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAPNwPUu001784 for ; Mon, 25 Nov 2002 15:58:25 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAPNwbbB000438 for ; Mon, 25 Nov 2002 15:58:37 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19290 for ; Mon, 25 Nov 2002 15:58:31 -0800 (PST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA26044 for ; Mon, 25 Nov 2002 23:58:30 GMT Received: from login.ecs.soton.ac.uk (IDENT:B1UZOHHWOpIN0UsA4pQQEdqw9JDLf0QX@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAPNwLWX031304 for ; Mon, 25 Nov 2002 23:58:22 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gAPNwLU31548 for ipng@sunroof.eng.sun.com; Mon, 25 Nov 2002 23:58:21 GMT Date: Mon, 25 Nov 2002 23:58:21 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: a different approach to site-local's "security" Message-ID: <20021125235820.GG30922@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <20021125190821.B75277B6B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Nov 25, 2002 at 11:03:11PM +0200, Pekka Savola wrote: > > I like this approach as the trust model of router advertisements and > configuration appears to be similar. Ditto. > One general worry is whether the RA's are the right place for doing > something like this, and whether this includes "RA explosion". Indeed. If hosts trust RAs to determine addressing and default routing, then DNS is a next logical step. Beyond that, how much creeping featurism do we wish to add? 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 Nov 25 16:17:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ0HYUu002363; Mon, 25 Nov 2002 16:17:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ0HYFX002362; Mon, 25 Nov 2002 16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ0HVUu002355 for ; Mon, 25 Nov 2002 16:17:31 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ0HgMq011528 for ; Mon, 25 Nov 2002 16:17:42 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29138 for ; Mon, 25 Nov 2002 17:17:36 -0700 (MST) Subject: RE: "unique enough" [RE: globally unique site local addresses] Date: Mon, 25 Nov 2002 16:17:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4CA@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: "unique enough" [RE: globally unique site local addresses] Thread-Index: AcKU3c4fV3YH5UueRvCd0UQetd+gqwAAkulg From: "Michel Py" To: "Tim Chown" , "ipng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQ0HVUu002356 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, >> Michel Py wrote: >> As I mentioned before, we MUST NOT encourage the use of >> site-locals for people that don't understand their >> limitations, and this certainly applies to the SOHO >> example you used. > Tim Chown > So how do I print to my net printer in between connections > to my ISP when I get a different prefix each time I connect? > I want some kind of addresses to use locally equivalent to > Net10. Not for NAT, but to communicate internally while > offline. This is a perfectly valid use of site-locals, my point was that we should not generalize the use when there are alternative methods. To some extent, site-locals are too easy. If you _choose_ to use them, OK. But a router MUST NOT offer site-locals as a default. >> Let me emphasize again that none of this stuff goes anywhere is there >> is no default enforcement of non-routability along the lines that Bob >> Hinden, Christian Huitema and myself have contributed, and I have not >> heard many comments about that part. > Indeed. I'm a little confused that GUPI = site-local, nothing > really new only we're (in PekkaS's method) just "randomising" > which site-local is used, so all the bad things of site-locals > remain I hear that lots of the issues have something to do with ambiguity. By making site-locals globally unique (GUPI) we remove ambiguity and take some of the problems out. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 16:24:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ0OjUu002573; Mon, 25 Nov 2002 16:24:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ0OjVe002572; Mon, 25 Nov 2002 16:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ0OgUu002565 for ; Mon, 25 Nov 2002 16:24:42 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ0OrbB008543 for ; Mon, 25 Nov 2002 16:24:53 -0800 (PST) Received: from mail.nosense.org (231.cust3.nsw.dsl.ozemail.com.au [203.103.158.231]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02412 for ; Mon, 25 Nov 2002 17:24:46 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id C4DC33B39C; Tue, 26 Nov 2002 11:24:25 +1100 (EST) Subject: Re: globally unique site local addresses From: Mark Smith To: Tim Chown Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20021125235246.GF30922@login.ecs.soton.ac.uk> References: <2B81403386729140A3A899A8B39B04640BD44B@server2000> <20021125235246.GF30922@login.ecs.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 26 Nov 2002 11:24:25 +1100 Message-Id: <1038270283.3603.126.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2002-11-26 at 10:52, Tim Chown wrote: > On Mon, Nov 25, 2002 at 10:19:55AM -0800, Michel Py wrote: > > > > Let me emphasize again that none of this stuff goes anywhere is there is > > no default enforcement of non-routability along the lines that Bob > > Hinden, Christian Huitema and myself have contributed, and I have not > > heard many comments about that part. I would suggest everybody generally understands and agrees with the default enforcement of GUPI non-routability contributed by Bob, Christian and Michel. Silence is probably agreement. > > Indeed. I'm a little confused that GUPI = site-local, nothing really new > only we're (in PekkaS's method) just "randomising" which site-local is used, > so all the bad things of site-locals remain (which I'm sure Keith *could* > remind us of :) Not all the bad things remain - the key bad thing that has been eliminated by the new GUPI models is muli-site site-local addressing ambiguity. Merging networks (which includes creating VPNs) was a hard problem with traditional site-locals, with the new GUPI models it is no problem or at least a very rare problem. By the fact that Keith has sent one or two emails on this topic, but not anymore than that, tends to suggest that most if not all his objections to traditional site-local addressing have also been addressed to an extent by the new GUPI models - or maybe it's just that his keyboard broke :-) 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 16:42:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ0gXUu002841; Mon, 25 Nov 2002 16:42:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ0gX0w002839; Mon, 25 Nov 2002 16:42:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ0gSUu002831 for ; Mon, 25 Nov 2002 16:42:28 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ0geMq018774 for ; Mon, 25 Nov 2002 16:42:40 -0800 (PST) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07803 for ; Mon, 25 Nov 2002 16:42:34 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 550E11E0E0; Mon, 25 Nov 2002 19:42:34 -0500 (EST) Received: from berkshire.research.att.com (guard.research.att.com [135.207.1.20]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id TAA02101; Mon, 25 Nov 2002 19:42:32 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id B24CE7B6B; Mon, 25 Nov 2002 19:42:31 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Tim Chown Cc: ipng@sunroof.eng.sun.com Subject: Re: a different approach to site-local's "security" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Nov 2002 19:42:31 -0500 Message-Id: <20021126004231.B24CE7B6B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <20021125235820.GG30922@login.ecs.soton.ac.uk>, Tim Chown writes: >On Mon, Nov 25, 2002 at 11:03:11PM +0200, Pekka Savola wrote: >> > >> One general worry is whether the RA's are the right place for doing >> something like this, and whether this includes "RA explosion". > >Indeed. If hosts trust RAs to determine addressing and default routing, >then DNS is a next logical step. It's your local router you're trusting; that's generally reasonable. I'm not at all wedded to the idea of using RA, but it's an existing message that's already distributing site-specific information such as prefix. I'm open to any other suggestions. > Beyond that, how much creeping featurism >do we wish to add? > Personally, I'd rather use real security protocols. But I'd much prefer my scheme to site-locals... --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("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 Mon Nov 25 16:59:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ0x6Uu003015; Mon, 25 Nov 2002 16:59:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ0x6E7003014; Mon, 25 Nov 2002 16:59: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ0x2Uu003007 for ; Mon, 25 Nov 2002 16:59:02 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ0xDbB017962 for ; Mon, 25 Nov 2002 16:59:13 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18537 for ; Mon, 25 Nov 2002 16:59:08 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQ0x4l13575; Mon, 25 Nov 2002 19:59:04 -0500 (EST) Message-Id: <200211260059.gAQ0x4l13575@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Thomas cc: ipng@sunroof.eng.sun.com Subject: Re: one question... In-reply-to: (Your message of "Mon, 25 Nov 2002 14:33:19 PST.") <15842.42287.175627.680904@thomasm-u1.cisco.com> Date: Mon, 25 Nov 2002 19:59:04 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So I've been watching this debate about globally > ~unique site locals and I don't understand how the > end node knows whether a particular destination > address is in scope (reachable) or not. The old > way, it just matched it to its own scoped prefix > and was done with it. What I've been hearing is > some desire to be able to patch together other > sites (extranets)... how would a node know which > scope address to use in that case? in general the only way for node A to determine whether node B is reachable is for A to send a packet to B. if A gets a reply from B, B is reachable. if A gets an ICMP message back, B is not reachable (for temporary or permanent reasons). if A gets nothing back, either B is (temporarily) unreachable or B doesn't want to answer A. but you'll never be able to determine this by looking at prefixes. 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 Nov 25 17:01:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ11uUu003063; Mon, 25 Nov 2002 17:01:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ11tLe003062; Mon, 25 Nov 2002 17:01: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ11pUu003055 for ; Mon, 25 Nov 2002 17:01:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ123Mq024248 for ; Mon, 25 Nov 2002 17:02:03 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20180 for ; Mon, 25 Nov 2002 18:01:57 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQ11sl13644; Mon, 25 Nov 2002 20:01:54 -0500 (EST) Message-Id: <200211260101.gAQ11sl13644@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tim Chown cc: ipng@sunroof.eng.sun.com Subject: Re: a different approach to site-local's "security" In-reply-to: (Your message of "Mon, 25 Nov 2002 23:58:21 GMT.") <20021125235820.GG30922@login.ecs.soton.ac.uk> Date: Mon, 25 Nov 2002 20:01:54 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Indeed. If hosts trust RAs to determine addressing and default routing, > then DNS is a next logical step. no it's not. DNS has nothing to do with addressing and routing, and I don't particularly like the idea of expecting the routing system to provide application-specific data to hosts - particularly when that data has nothing to do with network topology. 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 Nov 25 17:04:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ14IUu003102; Mon, 25 Nov 2002 17:04:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ14Icx003101; Mon, 25 Nov 2002 17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ14EUu003094 for ; Mon, 25 Nov 2002 17:04:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ14PMq025089 for ; Mon, 25 Nov 2002 17:04:25 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA11323 for ; Mon, 25 Nov 2002 18:04:18 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQ14Bl13677; Mon, 25 Nov 2002 20:04:11 -0500 (EST) Message-Id: <200211260104.gAQ14Bl13677@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Smith cc: Tim Chown , ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses In-reply-to: (Your message of "26 Nov 2002 11:24:25 +1100.") <1038270283.3603.126.camel@dupy> Date: Mon, 25 Nov 2002 20:04:11 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > By the fact that Keith has sent one or two emails on this topic, but not > anymore than that, tends to suggest that most if not all his objections > to traditional site-local addressing have also been addressed to an > extent by the new GUPI models I've been saying for months (at least) that we needed site-specific globally unique addresses, so I'm not likely to object to them now. :) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 18:04:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ24iUu003981; Mon, 25 Nov 2002 18:04:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ24ieq003980; Mon, 25 Nov 2002 18:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ24eUu003973 for ; Mon, 25 Nov 2002 18:04:40 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ24pbB004775 for ; Mon, 25 Nov 2002 18:04:52 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20588 for ; Mon, 25 Nov 2002 18:04:46 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id BE0444B22; Tue, 26 Nov 2002 11:04:43 +0900 (JST) To: "Steven M. Bellovin" Cc: ipng@sunroof.eng.sun.com In-reply-to: smb's message of Mon, 25 Nov 2002 16:52:11 EST. <20021125215211.0C4BF7B6B@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: even one reason why provably unique SL is needed? From: itojun@iijlab.net Date: Tue, 26 Nov 2002 11:04:43 +0900 Message-Id: <20021126020443.BE0444B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Require the DNS server at the edge of the site be authoritative for the >>whole of fec0::/10 or blackhole the queries. >> >>(I don't think too many people would even want to register site-locals in >>the _global_ reverse DNS, queriable by anyone -- remember, they're not to >>be used globally, and reverses in and itself are already considered a >>"security hazard" by some.) >> >>Let's not go down the path of putting site-locals anywhere near the global >>ip6.arpa. > >Sure -- but to keep the load off the root, we need to be *very* sure >that sites do pretend to be authoritative for them. will it help if we ship c.e.f.ip6.int/arpa zone files with BIND, just like 1.0.0.127.in-addr.arpa? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 18:08:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ28lUu004098; Mon, 25 Nov 2002 18:08:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ28l98004097; Mon, 25 Nov 2002 18:08: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ28hUu004090 for ; Mon, 25 Nov 2002 18:08:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ28rbB005850 for ; Mon, 25 Nov 2002 18:08:54 -0800 (PST) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA09858 for ; Mon, 25 Nov 2002 19:08:47 -0700 (MST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 0E0FB4CEEA; Mon, 25 Nov 2002 21:08:43 -0500 (EST) Received: from berkshire.research.att.com (guard.research.att.com [135.207.1.20]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id VAA03416; Mon, 25 Nov 2002 21:08:42 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id C11ED7B6B; Mon, 25 Nov 2002 21:08:40 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Nov 2002 21:08:40 -0500 Message-Id: <20021126020840.C11ED7B6B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <20021126020443.BE0444B22@coconut.itojun.org>, itojun@iijlab.net wri tes: >>>Require the DNS server at the edge of the site be authoritative for the >>>whole of fec0::/10 or blackhole the queries. >>> >>>(I don't think too many people would even want to register site-locals in >>>the _global_ reverse DNS, queriable by anyone -- remember, they're not to >>>be used globally, and reverses in and itself are already considered a >>>"security hazard" by some.) >>> >>>Let's not go down the path of putting site-locals anywhere near the global >>>ip6.arpa. >> >>Sure -- but to keep the load off the root, we need to be *very* sure >>that sites do pretend to be authoritative for them. > > will it help if we ship c.e.f.ip6.int/arpa zone files with BIND, > just like 1.0.0.127.in-addr.arpa? > I thought of that. It's certainly a good idea, but I'm not sure that it will help enough. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("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 Mon Nov 25 18:17:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ2HHUu004298; Mon, 25 Nov 2002 18:17:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ2HG0C004297; Mon, 25 Nov 2002 18:17:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ2HDUu004290 for ; Mon, 25 Nov 2002 18:17:13 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ2HObB007900 for ; Mon, 25 Nov 2002 18:17:24 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26360 for ; Mon, 25 Nov 2002 18:17:19 -0800 (PST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 25 Nov 2002 18:17:18 -0800 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Nov 2002 18:17:17 -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.5600); Mon, 25 Nov 2002 18:17:19 -0800 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); Mon, 25 Nov 2002 18:17:08 -0800 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.3710.0); Mon, 25 Nov 2002 18:17:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: one question... Date: Mon, 25 Nov 2002 18:17:17 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: one question... Thread-Index: AcKU6DQLCVwNL0v0STaVximEIf9rDQACONxg From: "Christian Huitema" To: "Keith Moore" , "Michael Thomas" Cc: X-OriginalArrivalTime: 26 Nov 2002 02:17:18.0537 (UTC) FILETIME=[F1D93B90:01C294F1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQ2HDUu004291 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > So I've been watching this debate about globally > > ~unique site locals and I don't understand how the > > end node knows whether a particular destination > > address is in scope (reachable) or not. The old > > way, it just matched it to its own scoped prefix > > and was done with it. What I've been hearing is > > some desire to be able to patch together other > > sites (extranets)... how would a node know which > > scope address to use in that case? > > in general the only way for node A to determine whether node B > is reachable is for A to send a packet to B. if A gets a reply > from B, B is reachable. if A gets an ICMP message back, B > is not reachable (for temporary or permanent reasons). if A > gets nothing back, either B is (temporarily) unreachable or > B doesn't want to answer A. > > but you'll never be able to determine this by looking at prefixes. Actually, the "Default Address Selection for IPv6" draft includes language of that nature. It would have to be amended to take into account the GUPI proposal. Something about assuming reachability of GUPI if on the same site, but not if on a remote site. And then, we would have to add policy hooks to mention "connected 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 Mon Nov 25 19:02:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ32GUu005073; Mon, 25 Nov 2002 19:02:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ32Gi8005072; Mon, 25 Nov 2002 19:02:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ32CUu005062 for ; Mon, 25 Nov 2002 19:02:12 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ32ObB016911 for ; Mon, 25 Nov 2002 19:02:24 -0800 (PST) Received: from mail.nosense.org (44.cust4.nsw.dsl.ozemail.com.au [203.103.159.44]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12968 for ; Mon, 25 Nov 2002 19:02:17 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id E66F93B39C for ; Tue, 26 Nov 2002 14:02:15 +1100 (EST) Subject: RE: one question... From: Mark Smith To: ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 26 Nov 2002 14:02:15 +1100 Message-Id: <1038279736.3603.164.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2002-11-26 at 13:17, Christian Huitema wrote: > > > So I've been watching this debate about globally > > > ~unique site locals and I don't understand how the > > > end node knows whether a particular destination > > > address is in scope (reachable) or not. The old > > > way, it just matched it to its own scoped prefix > > > and was done with it. What I've been hearing is > > > some desire to be able to patch together other > > > sites (extranets)... how would a node know which > > > scope address to use in that case? > > > > in general the only way for node A to determine whether node B > > is reachable is for A to send a packet to B. if A gets a reply > > from B, B is reachable. if A gets an ICMP message back, B > > is not reachable (for temporary or permanent reasons). if A > > gets nothing back, either B is (temporarily) unreachable or > > B doesn't want to answer A. > > > > but you'll never be able to determine this by looking at prefixes. > > Actually, the "Default Address Selection for IPv6" draft includes > language of that nature. It would have to be amended to take into > account the GUPI proposal. Something about assuming reachability of GUPI > if on the same site, but not if on a remote site. Is there really such thing as a "remote _site_" in the GUPI model ? Under the GUPI model, I would think you reach a "remote site" or remote destination (ie not internally connected) via global addressing. As I understand it, the GUPI model pretty much gets rid of the site model completely - it really is just catagorising connectivity and destinations as internal verses external - internal connectivity using GUPI addressing, via internally administered network infrastructure (including a VPN), verses external connectivity via the public Internet, using global addressing. Mark. ps. the word "site" we are using in these threads is becoming very overloaded with slightly different meanings, and it's becoming very confusing to know what people are referring to when they use the word "site", even when used multiple times within the same email. Maybe we should start using terms such as internal destinations (via GUPI addresses) or external destinations (via global addresses). It's tempting to use remote verses local destinations, but that also has some geographical connotations. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 19:12:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ3CqUu005419; Mon, 25 Nov 2002 19:12:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ3Cq2A005418; Mon, 25 Nov 2002 19:12: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ3ClUu005411 for ; Mon, 25 Nov 2002 19:12:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ3CxMq001797 for ; Mon, 25 Nov 2002 19:12:59 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA05776 for ; Mon, 25 Nov 2002 20:12:51 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:d86f:745e:1e4f:bad7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id gAQ3Cbd74513; Tue, 26 Nov 2002 12:12:39 +0900 (JST) Date: Tue, 26 Nov 2002 12:12:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 25 Nov 2002 19:42:53 +0200 (EET), >>>>> Pekka Savola said: > There seems to be an assumption that provably unique SL addresses would be > needed. Perhaps this is a silly comment, but excuse me, I remember a very similar proposal by Paul Francis at an IETF meeting a few years ago. At that time the wg should have rejected the idea, but I didn't remember the details about the discussion and the reason why the idea was rejected. Anyway, we may be able to learn something from the experience (not to waste time, not necessarily to reject the idea again). I'm sorry, but I don't have time to dig the minutes or ML archives on the discussion for now. 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 Nov 25 21:30:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ5UfUu006104; Mon, 25 Nov 2002 21:30:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ5UfDE006103; Mon, 25 Nov 2002 21:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ5UaUu006096 for ; Mon, 25 Nov 2002 21:30:37 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ5UlbB008888 for ; Mon, 25 Nov 2002 21:30:47 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA15269 for ; Mon, 25 Nov 2002 21:30:41 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 353094B22; Tue, 26 Nov 2002 14:30:39 +0900 (JST) To: Aidan Williams Cc: "Steven M. Bellovin" , ipng@sunroof.eng.sun.com, DNSOP WG In-reply-to: aidan.williams's message of Tue, 26 Nov 2002 16:27:20 +1100. <3DE30638.6010106@motorola.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: short circuiting reverse lookups From: itojun@iijlab.net Date: Tue, 26 Nov 2002 14:30:39 +0900 Message-Id: <20021126053039.353094B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >We should get the IPv6 case right. However if we believe that >dual stack is the likely IPv6 deployment scenario we are only >addressing well less than half the immediate problem. if we can declare that there should be no site-local/link-local unicast address available on the DNS reverse mapping, we could deploy host implmentation that never perform reverse lookup for those addresses. it will screw up people who plans to use site-locals in two-faced DNS, though... itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 21:34:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ5YwUu006239; Mon, 25 Nov 2002 21:34:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ5Yw6R006238; Mon, 25 Nov 2002 21:34: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ5YrUu006228 for ; Mon, 25 Nov 2002 21:34:54 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ5Z5Mq021746 for ; Mon, 25 Nov 2002 21:35:05 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA09866 for ; Mon, 25 Nov 2002 22:34:59 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQ5Yql14435; Tue, 26 Nov 2002 00:34:52 -0500 (EST) Message-Id: <200211260534.gAQ5Yql14435@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Christian Huitema" cc: "Keith Moore" , "Michael Thomas" , ipng@sunroof.eng.sun.com Subject: Re: one question... In-reply-to: (Your message of "Mon, 25 Nov 2002 18:17:17 PST.") Date: Tue, 26 Nov 2002 00:34:52 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > in general the only way for node A to determine whether node B > > is reachable is for A to send a packet to B. if A gets a reply > > from B, B is reachable. if A gets an ICMP message back, B > > is not reachable (for temporary or permanent reasons). if A > > gets nothing back, either B is (temporarily) unreachable or > > B doesn't want to answer A. > > > > but you'll never be able to determine this by looking at prefixes. > > Actually, the "Default Address Selection for IPv6" draft includes > language of that nature. well, there are lots of things wrong with that document. and no, an app can't reasonably assume that B is reachable from A even if they're both within the same site. and there are probably situations where a "non local" address (i.e. one with a shorter matching prefix) is preferable to a "local" one, because prefix length tells you nothing about available bandwidth, reliability, delay, jitter, or policy. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 21:38:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ5ciUu006333; Mon, 25 Nov 2002 21:38:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ5ciFQ006332; Mon, 25 Nov 2002 21:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ5cfUu006324; Mon, 25 Nov 2002 21:38:41 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ5cqbB010158; Mon, 25 Nov 2002 21:38:52 -0800 (PST) Received: from realname ([203.254.224.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA13827; Mon, 25 Nov 2002 21:38:46 -0800 (PST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0H6600G0559KGS@mailout2.samsung.com>; Tue, 26 Nov 2002 14:44:08 +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 <0H6600JQ059JT6@mailout2.samsung.com>; Tue, 26 Nov 2002 14:44:07 +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 <0H6600DSQ5B1KC@mmp1.samsung.com>; Tue, 26 Nov 2002 14:45:01 +0900 (KST) Date: Tue, 26 Nov 2002 14:35:56 +0900 From: Soohong Daniel Park Subject: confusing term. To: ipng@sunroof.eng.sun.com Cc: owner-ipng@sunroof.eng.sun.com Message-id: <00b601c2950d$b160a690$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_+r0bj5Jg6FlP9BvIfwY//w)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_+r0bj5Jg6FlP9BvIfwY//w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT when I read draft... I am confusing Solicitation/Advertisement and Request/Reply Please let me know above difference exactly... Daniel ===================================== Soohong Daniel Park Researcher Mobile Platform Group Digital Media R&D Center Samsung Electronics Co.,LTD TEL:+82-31-200-3728 FAX:+82-31-200-3147 H.P:+82-11-9950-4655 mailto:soohong.park@samsung.com ===================================== --Boundary_(ID_+r0bj5Jg6FlP9BvIfwY//w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT 메시지
when I read draft... I am confusing Solicitation/Advertisement and Request/Reply
Please let me know above difference exactly...
 
 
Daniel
            
=====================================
     Soohong Daniel Park
     Researcher
     Mobile Platform Group
     Digital Media R&D Center
     Samsung Electronics Co.,LTD
     TEL:+82-31-200-3728
     FAX:+82-31-200-3147
     H.P:+82-11-9950-4655
     mailto:soohong.park@samsung.com
=====================================
 
--Boundary_(ID_+r0bj5Jg6FlP9BvIfwY//w)-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 21:43:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ5hBUu006470; Mon, 25 Nov 2002 21:43:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ5hBX2006469; Mon, 25 Nov 2002 21:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ5h7Uu006462 for ; Mon, 25 Nov 2002 21:43:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ5hIMq022978 for ; Mon, 25 Nov 2002 21:43:18 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA09838 for ; Mon, 25 Nov 2002 22:43:12 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQ5h9l14722; Tue, 26 Nov 2002 00:43:09 -0500 (EST) Message-Id: <200211260543.gAQ5h9l14722@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Smith cc: ipng@sunroof.eng.sun.com Subject: Re: one question... In-reply-to: (Your message of "26 Nov 2002 14:02:15 +1100.") <1038279736.3603.164.camel@dupy> Date: Tue, 26 Nov 2002 00:43:09 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As I understand it, the GUPI model pretty much gets rid of the site > model completely - it really is just catagorising connectivity and > destinations as internal verses external - internal connectivity using > GUPI addressing, via internally administered network infrastructure > (including a VPN), verses external connectivity via the public Internet, > using global addressing. I wouldn't use the words "internal" and "external" because GUPIs would surely be used for private connectivity between sites. I'd use "private" and "public" instead. So GUPIs would be used within "private" sites that (for the most part) didn't have connectivity to the public Internet, and for connectivity between "private" sites and other sites; globals would be used by sites with connecitons to the public Internet. 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 Nov 25 22:37:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ6bUUu006777; Mon, 25 Nov 2002 22:37:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ6bUGF006776; Mon, 25 Nov 2002 22:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ6bRUu006769 for ; Mon, 25 Nov 2002 22:37:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ6bcbB017716 for ; Mon, 25 Nov 2002 22:37:38 -0800 (PST) Received: from mail.nosense.org (44.cust4.nsw.dsl.ozemail.com.au [203.103.159.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22442 for ; Mon, 25 Nov 2002 23:37:32 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 84FD43B39C; Tue, 26 Nov 2002 17:37:30 +1100 (EST) Subject: Re: one question... From: Mark Smith To: Keith Moore Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200211260543.gAQ5h9l14722@astro.cs.utk.edu> References: <200211260543.gAQ5h9l14722@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 26 Nov 2002 17:37:30 +1100 Message-Id: <1038292651.3603.213.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2002-11-26 at 16:43, Keith Moore wrote: > > As I understand it, the GUPI model pretty much gets rid of the site > > model completely - it really is just catagorising connectivity and > > destinations as internal verses external - internal connectivity using > > GUPI addressing, via internally administered network infrastructure > > (including a VPN), verses external connectivity via the public Internet, > > using global addressing. > > I wouldn't use the words "internal" and "external" because GUPIs would > surely be used for private connectivity between sites. I'd use > "private" and "public" instead. So GUPIs would be used within "private" > sites that (for the most part) didn't have connectivity to the public > Internet, and for connectivity between "private" sites and other sites; > globals would be used by sites with connecitons to the public Internet. > > Keith I think your imagined model of how GUPIs would be used might be different to mine. As I see it, there are only three basic addressing scenarios, assuming a network with more than one segment (ie using link local addresses for internal connectivity is not covered here) : 1) Globals - the address space stability of the global address space given by your provider is good enough. You use globals for everything, and have decided that coping with a global renumbering event is cheaper than the administration of GUPIs. 2) Globals and GUPIs - you don't want to rely on the stability of your allocated globals for your internal connectivity, so you roll out GUPI address space as well. GUPIs are used for your internal communications ie communications that doesn't travel across links that are part of the public Internet. 3) GUPIs only - you don't have a Internet connection, you need internal address space, GUPIs suit. If at a later date you get an Internet connection, you leave your GUPI address space in place, and roll out your provider allocated globals. A network with occasional public Internet connectivity would switch between scenario 2 and 3, based on the presence of its Internet connection. My comments about naming (and pretty much all others on GUPIs) have been based on scenario 2. I think scenario 2 would be the most common encountered. In the conext of my above scenarios, I'd be a bit concerned that the word "private" has negative IPv4 NAT associations - using it with IPv6 may help people along the path of thinking of using GUPIs and IPv6 NAT. The word "private" also suggests security, which we don't want to further endorse. I think that "internal" and "external" are good description words of what types of communications is happening in scenario 2. Regards, 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 25 22:41:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ6fMUu006825; Mon, 25 Nov 2002 22:41:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ6fM3s006824; Mon, 25 Nov 2002 22:41: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ6fIUu006817 for ; Mon, 25 Nov 2002 22:41:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ6fSbB018145 for ; Mon, 25 Nov 2002 22:41:28 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07569 for ; Mon, 25 Nov 2002 22:41:23 -0800 (PST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gAQ6fFWF008068 for ; Mon, 25 Nov 2002 23:41:15 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id XAA26865 for ; Mon, 25 Nov 2002 23:36:59 -0700 (MST)] Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gAQ6fJ7C000433 for ; Tue, 26 Nov 2002 17:41:19 +1100 (EST) Message-ID: <3DE3178F.83071AA3@motorola.com> Date: Tue, 26 Nov 2002 17:41:19 +1100 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: globally unique site local addresses References: <200211260104.gAQ14Bl13677@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some thoughts: As a method of doing globally unique site local addressing: Assuming aggregability is not an issue within a 'site' sized network, consider generating site local subnet identifiers at the router, based on IEEE EUI-48 identifiers (such as MAC addresses). For example, generate as fec0::/12: 12 bits: fef 48 bits: MAC 4 bits: 0 or subnets or, if we don't want them in fec0::/10 10 bits: fe0 48 bits: MAC 6 bits: 0 or subnets The '0 or subnets' is to allow for the possibility of choosing one EUI-48 on a router and using that to allocate all appropriate subnets. By piggybacking on the existing registration scheme, we generate "unique" site-local subnet ids at the router without needing external registration or administration. Despite the zero-config nature of this, administration on the router is still necessary, both to enable this mode (probably don't want site-local behaviour enabled by default) and to determine whether a router is authoritative for the link. An administrator may wish to configure a multi-router link with the subnet prefix of only one router. An internet-draft describing this in more detail is written and will be submitted in the next day or so. Comments welcome. Another comment on uniqueness: Under IPv6, even an ambiguous prefix is likely to not resolve to an address because of the MAC generated machine id, so the likelihood of collision is lower than might be expected from the prefix. Final thought: Whatever the outcome of the site local discussions, renumbering will remain a serious problem under IPv6, that needs to be considered. Making renumbering easier is a hard problem, but a good solution will help reduce a variety of other problems. -- 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 Nov 25 23:06:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ76YUu007091; Mon, 25 Nov 2002 23:06:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ76Xsn007090; Mon, 25 Nov 2002 23:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ76TUu007083 for ; Mon, 25 Nov 2002 23:06:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ76fMq003909 for ; Mon, 25 Nov 2002 23:06:41 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA07349 for ; Tue, 26 Nov 2002 00:06:35 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQ76Ul15568; Tue, 26 Nov 2002 02:06:30 -0500 (EST) Message-Id: <200211260706.gAQ76Ul15568@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Smith cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: one question... In-reply-to: (Your message of "26 Nov 2002 17:37:30 +1100.") <1038292651.3603.213.camel@dupy> Date: Tue, 26 Nov 2002 02:06:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One difference between our models may be that you seem to be assuming that if a network has external connectivity, it has connectivity to the public Internet. I do not assume that. So I see GUPIs as a way in which networks that aren't connected to the public Internet can still get addresses which allow them to establish private connections to external networks. Another difference is that I see little reason for a network to support both GUPIs and globals - if a network has globals then it is probably better off without GUPIs. Yes, GUPIs might be more stable than globals, but this is not necessarily the case - the opposite could also be true. OTOH I wouldn't try to insist that a network that supports globals not use GUPIs. If supporting both kinds of prefixes turns out to be the best way for that particular network to operate, fine. I just don't see that configuration as being of signifcant value. Keith > I think your imagined model of how GUPIs would be used might be > different to mine. > > As I see it, there are only three basic addressing scenarios, assuming a > network with more than one segment (ie using link local addresses for > internal connectivity is not covered here) : > > 1) Globals - the address space stability of the global address space > given by your provider is good enough. You use globals for everything, > and have decided that coping with a global renumbering event is cheaper > than the administration of GUPIs. > > 2) Globals and GUPIs - you don't want to rely on the stability of your > allocated globals for your internal connectivity, so you roll out GUPI > address space as well. GUPIs are used for your internal communications > ie communications that doesn't travel across links that are part of the > public Internet. > > 3) GUPIs only - you don't have a Internet connection, you need internal > address space, GUPIs suit. If at a later date you get an Internet > connection, you leave your GUPI address space in place, and roll out > your provider allocated globals. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 00:18:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ8IgUu007516; Tue, 26 Nov 2002 00:18:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ8If2A007515; Tue, 26 Nov 2002 00:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ8IcUu007508 for ; Tue, 26 Nov 2002 00:18:38 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ8IlMq012805 for ; Tue, 26 Nov 2002 00:18:47 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00607 for ; Tue, 26 Nov 2002 00:18:41 -0800 (PST) Received: from delta.cs.mu.OZ.AU ([128.250.38.50]) by munnari.OZ.AU (8.11.6/8.11.6) with ESMTP id gAQ8IUL13249; Tue, 26 Nov 2002 19:18:32 +1100 (EST) 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 gAQ8Cp805883; Tue, 26 Nov 2002 19:12:51 +1100 (EST) From: Robert Elz To: itojun@iijlab.net cc: Aidan Williams , "Steven M. Bellovin" , ipng@sunroof.eng.sun.com, DNSOP WG Subject: Re: short circuiting reverse lookups In-Reply-To: <20021126053039.353094B22@coconut.itojun.org> References: <20021126053039.353094B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Nov 2002 19:12:51 +1100 Message-ID: <5881.1038298371@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 26 Nov 2002 14:30:39 +0900 From: itojun@iijlab.net Message-ID: <20021126053039.353094B22@coconut.itojun.org> | it will screw up people who plans to use site-locals in two-faced DNS, | though... That would be no problem at all, anyone who wants to use two faced DNS deserves whatever evil befalls them. The real problem with never doing reverse lookups on site or link locals (assuming that there is a need to do reverse lookups at all, for anything) is for sites that are disconnected, where site locals, or even link locals, are all the addresses that exist. 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 Nov 26 00:31:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ8VbUu007624; Tue, 26 Nov 2002 00:31:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ8VbCO007623; Tue, 26 Nov 2002 00:31:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ8VYUu007616 for ; Tue, 26 Nov 2002 00:31:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ8VhMq018759 for ; Tue, 26 Nov 2002 00:31:43 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10879 for ; Tue, 26 Nov 2002 01:31:38 -0700 (MST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by n97.nomadiclab.com (Postfix) with ESMTP id 683261C; Tue, 26 Nov 2002 10:38:40 +0200 (EET) Message-ID: <3DE3316B.1040705@nomadiclab.com> Date: Tue, 26 Nov 2002 10:31:39 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021120 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py Cc: ipng Subject: Re: "unique enough" [RE: globally unique site local addresses] References: <2B81403386729140A3A899A8B39B046405E4C3@server2000> In-Reply-To: <2B81403386729140A3A899A8B39B046405E4C3@server2000> 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: > In the example you use, a SOHO configuring their network, use of GUPI is > a disaster, IMHO. Site-locals are not for SOHO sites, they need to talk > to the public Internet. These people need to use global addresses. I > don't challenge the need for globally unique PI addresses, but this > would be GAPI not GUPI. > > As I mentioned before, we MUST NOT encourage the use of site-locals for > people that don't understand their limitations, and this certainly > applies to the SOHO example you used. I can understand your point. There is just one thing that I want to repeat: If you give people something that is globally unique and stable, that is, something that looks, smells and tastes as globally unique stable identifiers, they will start to use them as such, sooner or later. We should not underestimate the desirability of such identifiers in the face of changing prefixes. Not all innovation is limited within the IETF. --Pekka -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 00:47:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ8lIUu007733; Tue, 26 Nov 2002 00:47:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ8lI2W007732; Tue, 26 Nov 2002 00:47: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ8lEUu007724 for ; Tue, 26 Nov 2002 00:47:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ8lNbB005938 for ; Tue, 26 Nov 2002 00:47:24 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18283 for ; Tue, 26 Nov 2002 01:47:17 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAQ8kgJ16834; Tue, 26 Nov 2002 10:46:42 +0200 Date: Tue, 26 Nov 2002 10:46:42 +0200 (EET) From: Pekka Savola To: "Steven M. Bellovin" cc: Tim Chown , Subject: Re: a different approach to site-local's "security" In-Reply-To: <20021126004231.B24CE7B6B@berkshire.research.att.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, 25 Nov 2002, Steven M. Bellovin wrote: > Personally, I'd rather use real security protocols. But I'd much > prefer my scheme to site-locals... Totally agree. Most use cases of site-locals seem to be plain wrong, and if something like this could be used to avoid using them ... all the better. I'd like to hear opinions from pro-site-local people on how it looks like. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 00:48:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ8m6Uu007768; Tue, 26 Nov 2002 00:48:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ8m5cD007767; Tue, 26 Nov 2002 00:48:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ8m2Uu007760 for ; Tue, 26 Nov 2002 00:48:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ8mCbB006059 for ; Tue, 26 Nov 2002 00:48:12 -0800 (PST) Received: from mail.nosense.org (44.cust4.nsw.dsl.ozemail.com.au [203.103.159.44]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08853 for ; Tue, 26 Nov 2002 00:48:05 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 7F1D73B39C; Tue, 26 Nov 2002 19:48:04 +1100 (EST) Subject: Re: one question... From: Mark Smith To: Keith Moore Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200211260706.gAQ76Ul15568@astro.cs.utk.edu> References: <200211260706.gAQ76Ul15568@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 26 Nov 2002 19:48:04 +1100 Message-Id: <1038300484.1458.267.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2002-11-26 at 18:06, Keith Moore wrote: > One difference between our models may be that you seem to be assuming > that if a network has external connectivity, it has connectivity to > the public Internet. Your right. I have been assuming that external = public Internet. But I have also assumed that internal != public Internet. If two organisations decide to connect together via a backdoor connection, push GUPI routes between each other's routing domain, and implement two opposite facing firewalls, I would still consider their connection internal. I do not assume that. So I see GUPIs as a way > in which networks that aren't connected to the public Internet can > still get addresses which allow them to establish private connections > to external networks. With my definitions of internal / external above, I'm struggling to think of an external network that wouldn't be the Internet. I can imagine a service provider / telco building a private IPv6 network for their customer's to connect to, which I think could be an "external" network using your definition. OTOH under my definition of internal above, this private telco backbone could also be considered internal - you would be connecting to a network which provides you with connectivity to other, known parties that are part of this private IPv6 backbone. It is a conscious decision to obtain connectivity with these other parties. The service provider is only really providing convenient, managed layer 3 connectivity, and ensuring better QOS, by providing dedicated bandwidth to known customers. I suppose basically I'm considering internal to be any time one organisation chooses to make its GUPI address space routes available to another, and accept the other organisation's GUPI address space routes. The organisation knows who it is talking to and vice versa (I'm not talking about a trust relationship here though - just the conscious decision to interconnect to each other's networks and the trading of GUPI routes). External under my definition is when you choose to connect to a network, where you don't know and can't control who else is connected to it - the public Internet is the only network which I know of that fits this definition. > > Another difference is that I see little reason for a network to support > both GUPIs and globals - if a network has globals then it is probably > better off without GUPIs. Yes, GUPIs might be more stable than globals, > but this is not necessarily the case - the opposite could also be true. > Other than internal links failing, causing destination unreachables, timeouts etc, what cases would there be where globals are more stable that GUPIs ? I'm struggling to think of a failure case for the new GUPI models where stability would be less than globals. Renumbering when merging networks was a stability issue we had with traditional site-locals, but that is the what GUPIs fixes. I imagine that from the day you switch on your first router and it generates / you assign your GUPI addressing, your internal GUPI addressing would stay the same as you build out your network. Internal communications failures would be caused by all the other typical causes of failure in the network, but not GUPI addressing itself. > OTOH I wouldn't try to insist that a network that supports globals > not use GUPIs. If supporting both kinds of prefixes turns out to be > the best way for that particular network to operate, fine. I just > don't see that configuration as being of signifcant value. > I think there is, but at least they are optional - I would use them, and you wouldn't :-) Regards, 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 01:22:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ9MSUu008001; Tue, 26 Nov 2002 01:22:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ9MSB1008000; Tue, 26 Nov 2002 01:22: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ9MPUu007993 for ; Tue, 26 Nov 2002 01:22:25 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ9MYbB010575 for ; Tue, 26 Nov 2002 01:22:34 -0800 (PST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24681 for ; Tue, 26 Nov 2002 01:22:28 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAQ9MNsF042506; Tue, 26 Nov 2002 10:22:23 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAQ9MM6S097872; Tue, 26 Nov 2002 10:22:22 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA50340 from ; Tue, 26 Nov 2002 10:22:20 +0100 Message-Id: <3DE33D36.9E591673@hursley.ibm.com> Date: Tue, 26 Nov 2002 10:21:58 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Keith Moore Cc: ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? References: <200211252129.gAPLT8l12401@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Which is the moment when you would discover that your prefix wasn't unique enough, so you'd go and get a new one. Not a big problem, since it would be very rare. Brian Keith Moore wrote: > > > "nearly unique" is not good enough. You want to be able to > > register these addresses in the ip6.arpa tree. > > yeech. it's a good point. > > Keith > > p.s. though I can't help but think that something is terribly broken > about our way of doing address lookups if it imposes this kind of > constraint on how we assign 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 01:43:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ9h8Uu008234; Tue, 26 Nov 2002 01:43:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ9h8pi008233; Tue, 26 Nov 2002 01:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ9h5Uu008226 for ; Tue, 26 Nov 2002 01:43:05 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ9hEMq027557 for ; Tue, 26 Nov 2002 01:43:14 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16679 for ; Tue, 26 Nov 2002 02:43:08 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAQ9h7t17627 for ; Tue, 26 Nov 2002 11:43:07 +0200 Date: Tue, 26 Nov 2002 11:43:07 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 26 Nov 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >>>>> On Mon, 25 Nov 2002 19:42:53 +0200 (EET), > >>>>> Pekka Savola said: > > > There seems to be an assumption that provably unique SL addresses would be > > needed. > > Perhaps this is a silly comment, but excuse me, I remember a very > similar proposal by Paul Francis at an IETF meeting a few years ago. > At that time the wg should have rejected the idea, but I didn't > remember the details about the discussion and the reason why the idea > was rejected. Thanks for the pointer. > Anyway, we may be able to learn something from the > experience (not to waste time, not necessarily to reject the idea > again). I'm sorry, but I don't have time to dig the minutes or ML > archives on the discussion for now. It's definitely worthwhile to learn from the past. The draft is available at: http://www.join.uni-muenster.de/drafts/draft-francis-ipngwg-unique-site-local-00.txt The meeting was March 2001. Text from minutes http://playground.sun.com/ipv6/minutes/ipng-minutes-mar2001.txt : ==== IPv6 Near-Unique Site-Local Addresses / Paul Francis ---------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Proposing to make site local prefixes non-local by adding a random number to "zeros part" in site local addresses. Now thinks that this doesn't help with the main problems stated in the draft. When merging sites, half will still have to renumber. Not any different from using the current site local prefix. In both cases some of the subnets will have to be renumbered. Crawford: Not quite as bad. When merging each half could maintain their original unique prefixes. Deering noted that notion of sites is not whole companies. More like a notion of a campus. He also thinks we should think about non-routable global address space. Thinks there may need for that. Something like a special TLA that ISP's will never route in the global Internet. Alain Durand, think this is unnecessary as we have lots of global addresses and we don't need to create way to use local addresses for non-local communication. Additional discussion. ===== But, when merging two sites, you don't need to renumber unless you want to. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 01:43:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ9hWUu008251; Tue, 26 Nov 2002 01:43:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ9hWDL008250; Tue, 26 Nov 2002 01:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ9hTUu008243 for ; Tue, 26 Nov 2002 01:43:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ9hbMq027607 for ; Tue, 26 Nov 2002 01:43:38 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16161 for ; Tue, 26 Nov 2002 02:43:31 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAQ9hJcu060822; Tue, 26 Nov 2002 10:43:22 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAQ9hE6S106298; Tue, 26 Nov 2002 10:43:16 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34118 from ; Tue, 26 Nov 2002 10:43:12 +0100 Message-Id: <3DE3421A.229A586D@hursley.ibm.com> Date: Tue, 26 Nov 2002 10:42:50 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: awhite@arc.corp.mot.com Cc: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <200211260104.gAQ14Bl13677@astro.cs.utk.edu> <3DE3178F.83071AA3@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a word: no. We mustn't generate prefixes longer than /48, since everybody will be designing 16 bit subnet addressing plans. It isn't acceptable to have different subnet addressing plans with site local and global prefixes. Brian Andrew White wrote: > > Some thoughts: > > As a method of doing globally unique site local addressing: > > Assuming aggregability is not an issue within a 'site' sized network, > consider generating site local subnet identifiers at the router, based on > IEEE EUI-48 identifiers (such as MAC addresses). > > For example, generate as fec0::/12: > > 12 bits: fef > 48 bits: MAC > 4 bits: 0 or subnets > > or, if we don't want them in fec0::/10 > > 10 bits: fe0 > 48 bits: MAC > 6 bits: 0 or subnets > > The '0 or subnets' is to allow for the possibility of choosing one EUI-48 on > a router and using that to allocate all appropriate subnets. > > By piggybacking on the existing registration scheme, we generate "unique" > site-local subnet ids at the router without needing external registration or > administration. > > Despite the zero-config nature of this, administration on the router is > still necessary, both to enable this mode (probably don't want site-local > behaviour enabled by default) and to determine whether a router is > authoritative for the link. An administrator may wish to configure a > multi-router link with the subnet prefix of only one router. > > An internet-draft describing this in more detail is written and will be > submitted in the next day or so. Comments welcome. > > Another comment on uniqueness: > > Under IPv6, even an ambiguous prefix is likely to not resolve to an address > because of the MAC generated machine id, so the likelihood of collision is > lower than might be expected from the prefix. > > Final thought: > > Whatever the outcome of the site local discussions, renumbering will remain > a serious problem under IPv6, that needs to be considered. Making > renumbering easier is a hard problem, but a good solution will help reduce a > variety of other problems. > > -- > 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 Nov 26 01:51:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ9pQUu008415; Tue, 26 Nov 2002 01:51:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQ9pQQD008414; Tue, 26 Nov 2002 01:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQ9pMUu008407 for ; Tue, 26 Nov 2002 01:51:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQ9pWbB014580 for ; Tue, 26 Nov 2002 01:51:32 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22848 for ; Tue, 26 Nov 2002 02:51:25 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAQ9pKW17734; Tue, 26 Nov 2002 11:51:20 +0200 Date: Tue, 26 Nov 2002 11:51:20 +0200 (EET) From: Pekka Savola To: Pekka Nikander cc: Michel Py , ipng Subject: Re: "unique enough" [RE: globally unique site local addresses] In-Reply-To: <3DE3316B.1040705@nomadiclab.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, 26 Nov 2002, Pekka Nikander wrote: > There is just one thing that I want to repeat: > > If you give people something that is globally unique and > stable, that is, something that looks, smells and tastes > as globally unique stable identifiers, they will start to > use them as such, sooner or later. > > We should not underestimate the desirability of such > identifiers in the face of changing prefixes. > > Not all innovation is limited within the IETF. I agree 100%. We should not try to make globally unique site-locals too attractive, because, well, they're not _meant_ to be attractive. We have globals in IPv6, you know. I'd actually like to use _globals_, not some site-local addresses. (in the random site-id proposal, the uniqueness probability may even be high to prevent this..) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 02:13:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQADmUu008592; Tue, 26 Nov 2002 02:13:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQADmgS008591; Tue, 26 Nov 2002 02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQADjUu008584 for ; Tue, 26 Nov 2002 02:13:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQADsbB017164 for ; Tue, 26 Nov 2002 02:13:54 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01375 for ; Tue, 26 Nov 2002 03:13:48 -0700 (MST) Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA01681 for ; Tue, 26 Nov 2002 10:13:47 GMT Received: from starling.ecs.soton.ac.uk (starling.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAQADfWX032287 for ; Tue, 26 Nov 2002 10:13:41 GMT Received: (from tjc@localhost) by starling.ecs.soton.ac.uk (8.11.6/8.11.6) id gAQADfX21681 for ipng@sunroof.eng.sun.com; Tue, 26 Nov 2002 10:13:41 GMT Date: Tue, 26 Nov 2002 10:13:41 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: a different approach to site-local's "security" Message-ID: <20021126101341.GD21641@starling.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <20021126004231.B24CE7B6B@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021126004231.B24CE7B6B@berkshire.research.att.com> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Nov 25, 2002 at 07:42:31PM -0500, Steven M. Bellovin wrote: > > Personally, I'd rather use real security protocols. But I'd much > prefer my scheme to site-locals... It depends to what extent we want to keep totally open "plug and play" for those who want to use it (for routing, or for DNS discovery). Is the "well-known site-local" DNS discovery draft still alive in the context of the GUPI proposals? The work on securing neighbour discovery is new (the SEND WG), but potentially promising. In Atlanta, it was interesting to see again some of the bizarre things that do get advertised in a large IPv6 gathering, e.g. on the last day it looked like someone was running 6to4 off the IPv4 stateless autoconf address space. 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 Nov 26 04:48:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQCmbUu009007; Tue, 26 Nov 2002 04:48:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQCmbhR009006; Tue, 26 Nov 2002 04:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQCmYUu008999 for ; Tue, 26 Nov 2002 04:48:34 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQCmibB005559 for ; Tue, 26 Nov 2002 04:48:45 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24778 for ; Tue, 26 Nov 2002 04:48:39 -0800 (PST) Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA20503; Tue, 26 Nov 2002 04:48:07 -0800 (PST) Message-Id: <5.1.0.14.0.20021126073240.02fc0d78@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Nov 2002 07:47:58 -0500 To: Mark Smith From: Margaret Wasserman Subject: Re: one question... Cc: Keith Moore , ipng@sunroof.eng.sun.com In-Reply-To: <1038292651.3603.213.camel@dupy> References: <200211260543.gAQ5h9l14722@astro.cs.utk.edu> <200211260543.gAQ5h9l14722@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mark, >2) Globals and GUPIs - you don't want to rely on the stability of your >allocated globals for your internal connectivity, so you roll out GUPI >address space as well. GUPIs are used for your internal communications >ie communications that doesn't travel across links that are part of the >public Internet. You'd have to add three things to this to get to where I hope that GUPI addresses will take us: - GUPI addresses may also be used to communicate over private links with other GUPI-addressed networks. In other words, several companies may use GUPI addresses to communicate with each other over a shared extranet. These types of networks are quite common in some industries for suppliers/ customers or data center/clients. This wouldn't and shouldn't require that multiple companies share a GUPI prefix, just that they have routes that point to each other. - You may have different "levels" of GUPI addresses within a single network... Some devices may use addresses that are filtered at the department level, some may be filtered at the corporate level, and some may be filtered at the extranet level, for example. - Some companies may pay their ISPs to globally route their GUPI addresses. I know that some people don't want this to be possible, but I'm not sure why. I agree that we should only advise this if we can come up with an aggregable method for allocating GUPI addresses. In the network, GUPI addresses would be treated _exactly_ like global addresses. And, just like global addresses (which they are), some of them will be filtered at firewalls in various places. We will need to do some work to document how other types of leaking (DNS and routing protocol leaking, in particular) should also be blocked at the same point as the traffic. However, this is pretty commonly done for VPNs in IPv4, so there are some known solutions (route filtering and split DNS). There will continue to be application-level and mobility issues with these addresses, or any type of private or filtered addresses. The problems are reduced by the fact that the addresses are not ambiguous, but the problems are not all eliminated. However, it seems that people _will_ use filtering to create private networks. The best we can do is try to provide a solution that mitigates the damage. 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 Nov 26 05:17:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQDHPUu009186; Tue, 26 Nov 2002 05:17:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQDHPnH009185; Tue, 26 Nov 2002 05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQDHLUu009178; Tue, 26 Nov 2002 05:17:21 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQDHVMq022634; Tue, 26 Nov 2002 05:17:31 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18031; Tue, 26 Nov 2002 06:17:25 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29650; Tue, 26 Nov 2002 08:14:41 -0500 (EST) Message-Id: <200211261314.IAA29650@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-moore-ipv6-optimistic-dad-01.txt Date: Tue, 26 Nov 2002 08:14:41 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Optimistic Duplicate Address Detection Author(s) : N. Moore Filename : draft-moore-ipv6-optimistic-dad-01.txt Pages : 10 Date : 2002-11-25 Optimistic DAD is an interoperable modification of the existing IPv6 Neighbour Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) process. The intention is to minimize address configuration delays in the successful case without greatly increasing disruption in the less likely failure case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-moore-ipv6-optimistic-dad-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-moore-ipv6-optimistic-dad-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-moore-ipv6-optimistic-dad-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-25134612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-moore-ipv6-optimistic-dad-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-moore-ipv6-optimistic-dad-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-25134612.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 05:21:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQDLiUu009266; Tue, 26 Nov 2002 05:21:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQDLi82009265; Tue, 26 Nov 2002 05:21: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQDLeUu009255 for ; Tue, 26 Nov 2002 05:21:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQDLobB009406 for ; Tue, 26 Nov 2002 05:21:50 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02932 for ; Tue, 26 Nov 2002 06:21:44 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQDLdl18594; Tue, 26 Nov 2002 08:21:39 -0500 (EST) Message-Id: <200211261321.gAQDLdl18594@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Smith cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: one question... In-reply-to: (Your message of "26 Nov 2002 19:48:04 +1100.") <1038300484.1458.267.camel@dupy> Date: Tue, 26 Nov 2002 08:21:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I suppose basically I'm considering internal to be any time one > organisation chooses to make its GUPI address space routes available to > another, and accept the other organisation's GUPI address space routes. > The organisation knows who it is talking to and vice versa (I'm not > talking about a trust relationship here though - just the conscious > decision to interconnect to each other's networks and the trading of > GUPI routes). Okay, it just seems like an odd use of the word "internal" to me. (I'm tempted to quote Lewis Carroll here but I won't. :) > > Another difference is that I see little reason for a network to support > > both GUPIs and globals - if a network has globals then it is probably > > better off without GUPIs. Yes, GUPIs might be more stable than globals, > > but this is not necessarily the case - the opposite could also be true. > > > > Other than internal links failing, causing destination unreachables, > timeouts etc, what cases would there be where globals are more stable > that GUPIs ? When the site network is renumbered/reorganized more often than the site's ISP changes the global prefix assigned to the site. People seem to assume that ISPs will want to change prefixes every week while the site will wisely manage its address space and never need to reassign suffixes, but it ain't necessarily so. I've certainly seen internal renumbering required because of poor address space management within a 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 Tue Nov 26 05:50:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQDo0Uu009575; Tue, 26 Nov 2002 05:50:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQDo0Tt009574; Tue, 26 Nov 2002 05:50:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQDnuUu009567 for ; Tue, 26 Nov 2002 05:49:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQDo7bB013050 for ; Tue, 26 Nov 2002 05:50:07 -0800 (PST) Received: from mail.nosense.org (44.cust4.nsw.dsl.ozemail.com.au [203.103.159.44]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03395 for ; Tue, 26 Nov 2002 06:50:03 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 99DF63B39C; Wed, 27 Nov 2002 00:50:00 +1100 (EST) Subject: Re: one question... From: Mark Smith To: Margaret Wasserman Cc: Keith Moore , ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.0.20021126073240.02fc0d78@mail.windriver.com> References: <200211260543.gAQ5h9l14722@astro.cs.utk.edu> <200211260543.gAQ5h9l14722@astro.cs.utk.edu> <5.1.0.14.0.20021126073240.02fc0d78@mail.windriver.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 27 Nov 2002 00:50:00 +1100 Message-Id: <1038318601.1458.326.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, On Tue, 2002-11-26 at 23:47, Margaret Wasserman wrote: > > Hi Mark, > > >2) Globals and GUPIs - you don't want to rely on the stability of your > >allocated globals for your internal connectivity, so you roll out GUPI > >address space as well. GUPIs are used for your internal communications > >ie communications that doesn't travel across links that are part of the > >public Internet. > > You'd have to add three things to this to get to where I hope that > GUPI addresses will take us: > > - GUPI addresses may also be used to communicate over > private links with other GUPI-addressed networks. > In other words, several companies may use GUPI > addresses to communicate with each other over > a shared extranet. These types of networks are > quite common in some industries for suppliers/ > customers or data center/clients. This wouldn't > and shouldn't require that multiple companies > share a GUPI prefix, just that they have routes > that point to each other. Totally agree, this is where I think GUPIs fix well the problem with traditional site-local networks being joined physically via leased lines, or logically via VPN tunnels. I imagine that unique GUPI prefixes would be allocated / assigned / auto-generated on a per "entity" basis, with that "entity" then using the GUPI prefix on its own network infrastructure. An entity could be : 1) An individual 2) A house hold 3) an organisation there are probably other entity types as well. I've chosen the word "entity" (without much deep thought though) as it is very generic - it doesn't imply size or geographical boundary. Interconnecting entities would involve these steps (pretty much repeating what you have said above) : 1) play GUPI prefix lotto - if you loose, one of the entities will have to renumber their network 2) bring up the link(s) between entity network infrastructures, either a physical circuit or a logical VPN tunnel. Part of this step is implementing any firewalling if necessary between the entities 3) pushing each entity's GUPI /48 into the other's routing domain. > > - You may have different "levels" of GUPI addresses within > a single network... Some devices may use addresses > that are filtered at the department level, some > may be filtered at the corporate level, and > some may be filtered at the extranet level, for > example. > When you use "levels", am I right in assuming you mean creating different packet forwarding boundaries via packet filtering ACLs etc, within the same instance of a GUPI address space ? eg although marketing and finance are part of the same GUPI address space, ACLs in the network prevent marketing sending / receiving packets from finance ? > - Some companies may pay their ISPs to globally route their > GUPI addresses. I know that some people don't > want this to be possible, but I'm not sure why. > I agree that we should only advise this if we can > come up with an aggregable method for allocating > GUPI addresses. I suppose it is just that (near) globally unique site local addresses or GUPIs are not at the moment trying to solve that problem, people on the mailing list don't want financially able people to turn it into a solution to that problem, without it being designed properly. Regards, 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 06:16:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQEGtUu009700; Tue, 26 Nov 2002 06:16:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQEGsR9009699; Tue, 26 Nov 2002 06: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQEGpUu009692 for ; Tue, 26 Nov 2002 06:16:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQEH1bB018114 for ; Tue, 26 Nov 2002 06:17:02 -0800 (PST) Received: from mail.nosense.org (44.cust4.nsw.dsl.ozemail.com.au [203.103.159.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02301 for ; Tue, 26 Nov 2002 07:16:55 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 66B9D3B39C; Wed, 27 Nov 2002 01:16:54 +1100 (EST) Subject: Re: one question... From: Mark Smith To: Keith Moore Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200211261321.gAQDLdl18594@astro.cs.utk.edu> References: <200211261321.gAQDLdl18594@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 27 Nov 2002 01:16:54 +1100 Message-Id: <1038320214.3603.354.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Keith, On Wed, 2002-11-27 at 00:21, Keith Moore wrote: > > I suppose basically I'm considering internal to be any time one > > organisation chooses to make its GUPI address space routes available to > > another, and accept the other organisation's GUPI address space routes. > > The organisation knows who it is talking to and vice versa (I'm not > > talking about a trust relationship here though - just the conscious > > decision to interconnect to each other's networks and the trading of > > GUPI routes). > > Okay, it just seems like an odd use of the word "internal" to me. > (I'm tempted to quote Lewis Carroll here but I won't. :) > It probably is, although the terms internal and external in this context remind me of the way "internal" and "external" are used to describe routes in an IGP. An IGP prefers its internal routes over equivalent external routes because it discovered them itself, verses just being told the external route and an arbitrary metric. Here is an alternative analogy - you can choose your friends (organisations you communicate with by directly connecting with (logically or physically) and trading GUPI /48 prefixes), you can't choose you relatives (everybody else on the public Internet, for which you use global addresses). I'm open to alternative describing words - I initially thought about on-site (internal) and off-site (external), but wanted to avoid the word "site" - people's default understanding of it is geographical, I didn't want to imply any sort of geographical scope for my "internal" communications. > > > Another difference is that I see little reason for a network to support > > > both GUPIs and globals - if a network has globals then it is probably > > > better off without GUPIs. Yes, GUPIs might be more stable than globals, > > > but this is not necessarily the case - the opposite could also be true. > > > > > > > Other than internal links failing, causing destination unreachables, > > timeouts etc, what cases would there be where globals are more stable > > that GUPIs ? > > When the site network is renumbered/reorganized more often than the > site's ISP changes the global prefix assigned to the site. People > seem to assume that ISPs will want to change prefixes every week > while the site will wisely manage its address space and never need > to reassign suffixes, but it ain't necessarily so. I've certainly > seen internal renumbering required because of poor address space management > within a site. I agree - while I've known (and been thankful) that a /48 gives you 65K subnets, its only when I read this did it really occur to me that some organisations will need to use aggregation within their /48 - /64 address space to shrink their route tables. Pretty obvious really, I just got a bit blinded by having so many subnets to play with :-) Regards, 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 06:17:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQEHxUu009730; Tue, 26 Nov 2002 06:17:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQEHxIB009729; Tue, 26 Nov 2002 06:17: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQEHtUu009722 for ; Tue, 26 Nov 2002 06:17:55 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQEI5Mq001279 for ; Tue, 26 Nov 2002 06:18:05 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06792 for ; Tue, 26 Nov 2002 06:18:00 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQEHol18974; Tue, 26 Nov 2002 09:17:50 -0500 (EST) Message-Id: <200211261417.gAQEHol18974@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Mark Smith , Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: one question... In-reply-to: (Your message of "Tue, 26 Nov 2002 07:47:58 EST.") <5.1.0.14.0.20021126073240.02fc0d78@mail.windriver.com> Date: Tue, 26 Nov 2002 09:17:50 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >2) Globals and GUPIs - you don't want to rely on the stability of your > >allocated globals for your internal connectivity, so you roll out GUPI > >address space as well. GUPIs are used for your internal communications > >ie communications that doesn't travel across links that are part of the > >public Internet. > > You'd have to add three things to this to get to where I hope that > GUPI addresses will take us: > > - GUPI addresses may also be used to communicate over > private links with other GUPI-addressed networks. Or for that matter, to communicate over private links with other networks that use globals. I don't see why it matters whether the other sites are using GUPIs or not - all that matters is that you have unique addresses for your site. GUPIs shouldn't be thought to have any special significance to apps, they're just a way to get a unique prefix when you don't have stable public Internet connectivity. The other thing that seems strange about this statement (to me anyway) is the idea that you use GUPIs for specific purposes or links. Ideally from my point-of-view you should have as few prefixes as possible and you should accept traffic for all of those prefixes on each of your links, and you should use packet filtering rather than prefix advertisement to control what kind of traffic you accept (and emit). That way, apps don't have to pick the "right prefix" in order to work. > - You may have different "levels" of GUPI addresses within > a single network... Some devices may use addresses > that are filtered at the department level, some > may be filtered at the corporate level, and > some may be filtered at the extranet level, for > example. absolutely. of course, you can do this with global prefixes also. > - Some companies may pay their ISPs to globally route their > GUPI addresses. I know that some people don't > want this to be possible, but I'm not sure why. > I agree that we should only advise this if we can > come up with an aggregable method for allocating > GUPI addresses. I don't know about "global routing". I can certainly imagine paying an ISP to route my GUPI-addressed traffic to specific locations, or perhaps throughout its network. I suppose I can also imagine paying my ISP to make arrangements with other ISPs to route my GUPI-addressed traffic in their networks. But I don't understand how my ISP can guarantee that every network in the world will choose to accept a reasonable amount of money for routing my GUPIs. It certainly seems important that GUPIs not be globally routable without a special arrangement. But I also wonder whether a market for routing GUPIs would not degrade Internet service for everyone by inflating the sizes of routing tables and increasing convergence times. I suspect that some constraints on use of GUPIs are necessary unless there are technical means of allowing dissimilar prefixes for topologically close networks to be aggregated for the purpose of routing computations and probably advertisements also. > We will need to do some work to document how other types of leaking > (DNS and routing protocol leaking, in particular) should also be > blocked at the same point as the traffic. However, this is pretty > commonly done for VPNs in IPv4, so there are some known solutions (route > filtering and split DNS). I don't think we should try to prevent leakage at any layer above a routing protocol. We certainly shouldn't depend on addresses not leaking. Sites can implement two-faced DNS if they wish (and deal with the operational problems that result) but in all cases app writers need to make sure that their apps do reasonable things when given addresses that they cannot reach. > However, it seems that people _will_ use filtering to create private > networks. The best we can do is try to provide a solution that > mitigates the damage. right. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 06:20:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQEKpUu009767; Tue, 26 Nov 2002 06:20:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQEKo4c009766; Tue, 26 Nov 2002 06:20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQEKkUu009759 for ; Tue, 26 Nov 2002 06:20:47 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQEKvMq002144 for ; Tue, 26 Nov 2002 06:20:57 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08279 for ; Tue, 26 Nov 2002 06:20:52 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQEKll19106; Tue, 26 Nov 2002 09:20:47 -0500 (EST) Message-Id: <200211261420.gAQEKll19106@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Smith cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: one question... In-reply-to: (Your message of "27 Nov 2002 01:16:54 +1100.") <1038320214.3603.354.camel@dupy> Date: Tue, 26 Nov 2002 09:20:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It probably is, although the terms internal and external in this context > remind me of the way "internal" and "external" are used to describe > routes in an IGP. An IGP prefers its internal routes over equivalent > external routes because it discovered them itself, verses just being > told the external route and an arbitrary metric. > > Here is an alternative analogy - you can choose your friends > (organisations you communicate with by directly connecting with > (logically or physically) and trading GUPI /48 prefixes), you can't > choose you relatives (everybody else on the public Internet, for which > you use global addresses). offhand, I like calling them "friends" and "relatives" - to me it conveys the right intiutive sense of what is going 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 Tue Nov 26 07:12:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQFCxUu010085; Tue, 26 Nov 2002 07:12:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQFCwjI010084; Tue, 26 Nov 2002 07:12: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQFCtUu010077 for ; Tue, 26 Nov 2002 07:12:55 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQFD6Mq014888 for ; Tue, 26 Nov 2002 07:13:06 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07347 for ; Tue, 26 Nov 2002 07:13:01 -0800 (PST) Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA11238; Tue, 26 Nov 2002 07:12:34 -0800 (PST) Message-Id: <5.1.0.14.0.20021126092449.015d2d60@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Nov 2002 10:07:10 -0500 To: Mark Smith From: Margaret Wasserman Subject: Taking two steps back (Was: Re: one question...) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <1038318601.1458.326.camel@dupy> References: <5.1.0.14.0.20021126073240.02fc0d78@mail.windriver.com> <200211260543.gAQ5h9l14722@astro.cs.utk.edu> <200211260543.gAQ5h9l14722@astro.cs.utk.edu> <5.1.0.14.0.20021126073240.02fc0d78@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 > >Interconnecting entities would involve these steps (pretty much >repeating what you have said above) : > >1) play GUPI prefix lotto - if you loose, one of the entities will have >to renumber their network This assumes some sort of locally-generated GUPI addresses. There is also the possibility of externally allocated GUPI addresses. I don't think that we've made a decision one way or the other yet, and I don't think we can/should make a decision between different GUPI address allocation methods until we have documented what problems we are trying to solve. > > > > - You may have different "levels" of GUPI addresses within > > a single network... Some devices may use addresses > > that are filtered at the department level, some > > may be filtered at the corporate level, and > > some may be filtered at the extranet level, for > > example. > > > >When you use "levels", am I right in assuming you mean creating >different packet forwarding boundaries via packet filtering ACLs etc, Yes. >within the same instance of a GUPI address space ? What does this mean? Let's take two steps back, stop discussing possible solutions for a moment and discuss the problem statement. I'd like it to be possible for an enterprise to: - Have resources (i.e nodes or services) that are accessible only to sub-groups within the enterprise (i.e. departments). Example: a printer that only marketing is allowed to use. - Have resources that are available to the whole enterprise, but that are not accessible outside the enterprise. Example: An HR benefits website. - Have resources that are available on an extranet (between a selected group of enterprises) that are not accessible to all other enterprises. Example: A supplier/customer network. - Have resources that are globally available, and be able to send global traffic. Example: Google. All of these things can be achieved without site-locals, using provider-allocated global addresses and appropriate configurations of firewalls, ACLs, route filtering and split DNS. The key here is to control access/reachability. IPv6 site-local addresses (as currently defined) don't significantly help with this problem, because they only provide one level of "local" addressing (Would I use them at the department level? At the enterprise level?), and their ambiguity prevents them from being nested. Their ambiguity also causes numerous other architectural problems and does not, inherent offer any benefits related to this problem statement. However, some people have argued that network administrators will choose to use site-locals at one of these boundaries (probably the enterprise-wide boundary) in order to achieve ISP independence. In other words, they want to make sure that they don't have to renumber their internal firewalls, ACLs, etc. if they change ISPs and/or their ISP renumbers. This is a real issue, and a real benefit of site-local addressing. However, the ambiguity of site-local addresses causes a lot of problems in this sort of situation. Wouldn't it be better, instead, if people had a way to get provider-independent addresses that were globally unique? Enter GUPI addresses... Addresses that are _just_ like ISP-provided global addresses, except that they belong to the enterprise and don't need to be changed when you switch ISPs and/or the ISP renumbers. Sounds good, but it opens some basic (and related questions): - How will these addresses be allocated and/or generated? - Will enterprises end up paying their ISPs to route these addresses globally? - If so, we need an aggregable way to allocate/generate these addresses, so that they won't cause explosive growth of the IPv6 core routing tables. - If not, then we can probably just allocate these addresses sequentially and/or randomly. Also, we need to consider whether there are other addressing-related problems in enterprise environment. Are there other needs for local and/or provider-independent addressing? I don't really know. Now, I have a second type of problem statement: For the home environment, it would be nice to be able to ship nodes that are configured, by default, only to be accessible locally -- i.e. storage devices or home security systems (I'm actually not that worried that hackers will use my printer :-)). Since these devices will be installed and used by fairly unsophisticated users (like me :-)) who do not want to set-up firewalls, ACLs and split DNS to protect their resources, it would be good if there were a way for these addresses to recognize certain prefixes as inherently "local", and only accept traffic from nodes with addresses within those prefixes. Steve Bellovin has proposed a new RA mechanism that would allow some prefixes to be tagged at "local" (and would even provide multiple levels of "local"), so that we could get the access control benefits of local addressing without the need to use overlapping private addresses. It might be useful to have a home gateway generate some sort of addresses (current site-locals, site-locals with random numbers to make them unique, other types of addresses?) for use on the local network, and tag those addresses as "local" in RAs. Would home users want to (or ever be allowed to) pay their ISPs to globally route their provider-independent addresses? If so, we would need a way to assign aggregable addresses. If not, it might be sufficient to assign them sequentially and/or randomly. Are there other problems that NATs solve for the home environment that we need to find an architecturally sound way to solve in IPv6? I don't really know. And, are there any needs for local addressing within ISPs or other types of provider networks? If so, what are the needs in those environments? It isn't even clear that a single solution will serve for all of these environments. But, until we understand what problem we are trying to solve, I think it is quite premature to argue over the details of what random number generator it would be best to use... 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 Nov 26 07:14:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQFERUu010102; Tue, 26 Nov 2002 07:14:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQFERD2010101; Tue, 26 Nov 2002 07:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQFEOUu010094 for ; Tue, 26 Nov 2002 07:14:24 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQFEYMq015223 for ; Tue, 26 Nov 2002 07:14:34 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07557 for ; Tue, 26 Nov 2002 08:14:29 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA11766; Tue, 26 Nov 2002 07:13:56 -0800 (PST) Message-Id: <5.1.0.14.0.20021126100821.02fc7690@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Nov 2002 10:12:34 -0500 To: Keith Moore From: Margaret Wasserman Subject: Re: one question... Cc: Mark Smith , Keith Moore , ipng@sunroof.eng.sun.com In-Reply-To: <200211261417.gAQEHol18974@astro.cs.utk.edu> References: <(Your message of "Tue, 26 Nov 2002 07:47:58 EST.") <5.1.0.14.0.20021126073240.02fc0d78@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 > > > - GUPI addresses may also be used to communicate over > > private links with other GUPI-addressed networks. > >Or for that matter, to communicate over private links with other >networks that use globals. I don't see why it matters whether the >other sites are using GUPIs or not - all that matters is that you >have unique addresses for your site. GUPIs shouldn't be thought to >have any special significance to apps, they're just a way to get >a unique prefix when you don't have stable public Internet connectivity. I stand corrected... I agree with you completely. > > - You may have different "levels" of GUPI addresses within > > a single network... Some devices may use addresses > > that are filtered at the department level, some > > may be filtered at the corporate level, and > > some may be filtered at the extranet level, for > > example. > >absolutely. of course, you can do this with global prefixes also. Definitely. > I suspect >that some constraints on use of GUPIs are necessary unless there are >technical means of allowing dissimilar prefixes for topologically >close networks to be aggregated for the purpose of routing computations >and probably advertisements also. Why to the prefixes for topologically close networks need to be dissimilar. There is at least one proposal in multi6 for aggregable provider-independent addressing. I'm not sure how well it would work, because I haven't examined it in detail... >I don't think we should try to prevent leakage at any layer above >a routing protocol. We certainly shouldn't depend on addresses >not leaking. Sites can implement two-faced DNS if they wish (and >deal with the operational problems that result) but in all cases >app writers need to make sure that their apps do reasonable things >when given addresses that they cannot reach. Right... And, given the wide proliferation of filtering and firewalls, they must already be doing this today. IPv6 site-locals add a new twist -- ambiguous addressing. That's the part I think we should try to avoid. 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 Nov 26 07:35:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQFZ6Uu010295; Tue, 26 Nov 2002 07:35:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQFZ5ZB010294; Tue, 26 Nov 2002 07:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQFYxUu010280 for ; Tue, 26 Nov 2002 07:34:59 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQFZAMq019488 for ; Tue, 26 Nov 2002 07:35:10 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07777 for ; Tue, 26 Nov 2002 07:35:04 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQFYll20269; Tue, 26 Nov 2002 10:34:47 -0500 (EST) Message-Id: <200211261534.gAQFYll20269@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Keith Moore , Mark Smith , ipng@sunroof.eng.sun.com Subject: Re: one question... In-reply-to: (Your message of "Tue, 26 Nov 2002 10:12:34 EST.") <5.1.0.14.0.20021126100821.02fc7690@mail.windriver.com> Date: Tue, 26 Nov 2002 10:34:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I suspect > >that some constraints on use of GUPIs are necessary unless there are > >technical means of allowing dissimilar prefixes for topologically > >close networks to be aggregated for the purpose of routing computations > >and probably advertisements also. > > Why to the prefixes for topologically close networks need to be > dissimilar. There is at least one proposal in multi6 for aggregable > provider-independent addressing. I'm not sure how well it would > work, because I haven't examined it in detail... I haven't seen that proposal, so I can't comment on it. but if the routing system can acquire the capability to aggregate dissimilar prefixes, then we don't need to worry nearly as much about trying to discourage global routing of PI 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 Tue Nov 26 07:39:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQFdPUu010373; Tue, 26 Nov 2002 07:39:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQFdPeq010372; Tue, 26 Nov 2002 07: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQFdLUu010362 for ; Tue, 26 Nov 2002 07:39:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQFdWMq020554 for ; Tue, 26 Nov 2002 07:39:32 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07751 for ; Tue, 26 Nov 2002 08:39:26 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA20884; Tue, 26 Nov 2002 07:38:52 -0800 (PST) Message-Id: <5.1.0.14.0.20021126103746.02d9bd40@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Nov 2002 10:38:43 -0500 To: Keith Moore From: Margaret Wasserman Subject: Re: one question... Cc: Keith Moore , Mark Smith , ipng@sunroof.eng.sun.com In-Reply-To: <200211261534.gAQFYll20269@astro.cs.utk.edu> References: <(Your message of "Tue, 26 Nov 2002 10:12:34 EST.") <5.1.0.14.0.20021126100821.02fc7690@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 > > Why do the prefixes for topologically close networks need to be > > dissimilar. There is at least one proposal in multi6 for aggregable > > provider-independent addressing. I'm not sure how well it would > > work, because I haven't examined it in detail... > >I haven't seen that proposal, so I can't comment on it. > >but if the routing system can acquire the capability to aggregate >dissimilar prefixes, then we don't need to worry nearly as much about >trying to discourage global routing of PI addresses. True. Unfortunately, I'm not sure that anyone has figured out a good way to skin this cat from either end... 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 Nov 26 07:54:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQFsVUu010674; Tue, 26 Nov 2002 07:54:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQFsVdV010673; Tue, 26 Nov 2002 07:54:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQFsPUu010659 for ; Tue, 26 Nov 2002 07:54:25 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQFsaMq024240 for ; Tue, 26 Nov 2002 07:54:36 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19813 for ; Tue, 26 Nov 2002 07:54:31 -0800 (PST) Subject: RE: one question... Date: Tue, 26 Nov 2002 07:54:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B04640BD457@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: one question... Thread-Index: AcKVF4MREchDiIb7Tq6J5lCjY5ONDAATDWlA From: "Michel Py" To: "Mark Smith" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQFsQUu010660 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark, > Mark Smith > 2) Globals and GUPIs - you don't want to rely on the > stability of your allocated globals for your internal > connectivity, so you roll out GUPI address space as well. > GUPIs are used for your internal communications ie > communications that doesn't travel across links that are > part of the public Internet. This wording is confusing. If using tunnels, the endpoints can have publicly routable addresses and the tunnel address itself can be GUPI. Even frame-relay sometimes travels over IP. 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 Nov 26 07:57:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQFvHUu010728; Tue, 26 Nov 2002 07:57:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQFvHIA010727; Tue, 26 Nov 2002 07:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQFvEUu010720 for ; Tue, 26 Nov 2002 07:57:14 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQFvNbB006045 for ; Tue, 26 Nov 2002 07:57:24 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03983 for ; Tue, 26 Nov 2002 07:57:18 -0800 (PST) Subject: RE: "unique enough" [RE: globally unique site local addresses] Date: Tue, 26 Nov 2002 07:57:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4CE@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: "unique enough" [RE: globally unique site local addresses] Thread-Index: AcKVJmOmwOJWyxBvSOOtOGJ4OUM3gAAPSe7g From: "Michel Py" To: "Pekka Nikander" Cc: "ipng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQFvEUu010721 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > Pekka Nikander wrote: There is just one thing that I want to repeat: If you give people something that is globally unique and stable, that is, something that looks, smells and tastes as globally unique stable identifiers, they will start to use them as such, sooner or later. We should not underestimate the desirability of such identifiers in the face of changing prefixes. Not all innovation is limited within the IETF. I totally agree with you, that's why I insist so much on enforcing non-routability of these addresses by having both the default black hole that Bob suggested and the default BGP discard that I suggested a while ago. Without these, GUPI would be transformed into PI before we know it and the routing table will explode. 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 Nov 26 08:13:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQGDNUu011117; Tue, 26 Nov 2002 08:13:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQGDNNW011116; Tue, 26 Nov 2002 08:13:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQGDJUu011109 for ; Tue, 26 Nov 2002 08:13:19 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQGDTMq029090 for ; Tue, 26 Nov 2002 08:13:29 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02286 for ; Tue, 26 Nov 2002 08:13:24 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQGDJl20647; Tue, 26 Nov 2002 11:13:19 -0500 (EST) Message-Id: <200211261613.gAQGDJl20647@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: awhite@arc.corp.mot.com cc: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses In-reply-to: (Your message of "Tue, 26 Nov 2002 17:41:19 +1100.") <3DE3178F.83071AA3@motorola.com> Date: Tue, 26 Nov 2002 11:13:19 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For the sake of completeness: Another idea I heard last week (sorry, I forget who suggested it) is to use the number of seconds since some epoch (say 2002.01.01 0000 UTC) when the network was established, as the probably-unique prefix. Though I do wonder whether we might see multiple networks automatically "turned on" at the same "round number" time, causing collisions. Keith > As a method of doing globally unique site local addressing: > > Assuming aggregability is not an issue within a 'site' sized network, > consider generating site local subnet identifiers at the router, based on > IEEE EUI-48 identifiers (such as MAC addresses). > > For example, generate as fec0::/12: > > 12 bits: fef > 48 bits: MAC > 4 bits: 0 or subnets > > or, if we don't want them in fec0::/10 > > 10 bits: fe0 > 48 bits: MAC > 6 bits: 0 or subnets > > The '0 or subnets' is to allow for the possibility of choosing one EUI-48 on > a router and using that to allocate all appropriate subnets. > > By piggybacking on the existing registration scheme, we generate "unique" > site-local subnet ids at the router without needing external registration or > administration. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 08:15:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQGF6Uu011170; Tue, 26 Nov 2002 08:15:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQGF5EN011169; Tue, 26 Nov 2002 08:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQGF2Uu011159 for ; Tue, 26 Nov 2002 08:15:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQGFCMq029518 for ; Tue, 26 Nov 2002 08:15:12 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28071 for ; Tue, 26 Nov 2002 09:15:05 -0700 (MST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 26 Nov 2002 08:14:58 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 26 Nov 2002 08:15:02 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 26 Nov 2002 08:15:01 -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); Tue, 26 Nov 2002 08:15:01 -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.3710.0); Tue, 26 Nov 2002 08:15:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Taking two steps back (Was: Re: one question...) Date: Tue, 26 Nov 2002 08:15:09 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Taking two steps back (Was: Re: one question...) Thread-Index: AcKVX5oPKhDYkV+gQgC17Pzs2toQMQABeiDQ From: "Christian Huitema" To: "Margaret Wasserman" , "Mark Smith" Cc: X-OriginalArrivalTime: 26 Nov 2002 16:15:07.0554 (UTC) FILETIME=[FC848020:01C29566] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQGF2Uu011160 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Let's take two steps back, stop discussing possible solutions for a > moment and discuss the problem statement. I'd like it to be possible for > an enterprise to: > > - Have resources (i.e nodes or services) that are accessible > only to sub-groups within the enterprise (i.e. > departments). Example: a printer that only marketing > is allowed to use. > - Have resources that are available to the whole enterprise, > but that are not accessible outside the enterprise. > Example: An HR benefits website. > - Have resources that are available on an extranet (between a > selected group of enterprises) that are not accessible > to all other enterprises. Example: A supplier/customer > network. > - Have resources that are globally available, and be able to > send global traffic. Example: Google. > > All of these things can be achieved without site-locals, using > provider-allocated global addresses and appropriate configurations of > firewalls, ACLs, route filtering and split DNS. In theory people would be smart and would never assign any security property to an address. They would base access control on actual authentication protocols, authorizing an activity if they have enough trust in the user initiating the activity and the remote computer through which the activity is performed. I wish everybody understood that. In practice, many system administrators do assign some properties to addresses. In a large network, assigning properties to addresses translates in a large number of access control lists in which the "only marketing" or "HR benefits" restriction is translated into a set of address prefixes. Experience proves that updating these prefixes during network renumbering is a major pain. Having a stable set of prefixes that you can use internally is thus very helpful. -- 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 Tue Nov 26 08:26:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQGQhUu011801; Tue, 26 Nov 2002 08:26:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQGQhF6011800; Tue, 26 Nov 2002 08:26: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQGQdUu011793 for ; Tue, 26 Nov 2002 08:26:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQGQnbB013270 for ; Tue, 26 Nov 2002 08:26:50 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05113 for ; Tue, 26 Nov 2002 09:26:44 -0700 (MST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 26 Nov 2002 08:26:43 -0800 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 26 Nov 2002 08:26:38 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Tue, 26 Nov 2002 08:26:34 -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); Tue, 26 Nov 2002 08:26:42 -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.3710.0); Tue, 26 Nov 2002 08:26:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: one question... Date: Tue, 26 Nov 2002 08:26:49 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: one question... Thread-Index: AcKVUXmrPf6GlPt/T6uehQgZY1N8pgAFYcJw From: "Christian Huitema" To: "Margaret Wasserman" , "Mark Smith" Cc: "Keith Moore" , X-OriginalArrivalTime: 26 Nov 2002 16:26:48.0873 (UTC) FILETIME=[9E894990:01C29568] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQGQeUu011794 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - Some companies may pay their ISPs to globally route their > GUPI addresses. I know that some people don't > want this to be possible, but I'm not sure why. > I agree that we should only advise this if we can > come up with an aggregable method for allocating > GUPI addresses. Margaret, You should check the evolution of the size of the DFZ tables, for example at http://bgp.potaroo.net/. From my neck of the woods, I perceive a consensus on two points: that rapid growth of the number of globally routed prefixes is not a good thing; and that the major cause of growth is "site multi-homing", which translates exactly into "some companies may pay their ISPs to globally route their (global) addresses". (Attempts at traffic engineering through clever use of routing tables is probably the other cause of table growth.) The whole point of placing restrictions on the routability of the GUPI is precisely to thwart attempts to pay your way into the routing table: whatever the amount of money on the table, the ISP cannot say yes since it cannot guarantee that other ISPs will route the GUPI. -- 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 Tue Nov 26 08:43:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQGhnUu012393; Tue, 26 Nov 2002 08:43:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQGhn2F012392; Tue, 26 Nov 2002 08:43:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQGhkUu012384 for ; Tue, 26 Nov 2002 08:43:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQGhubB017808 for ; Tue, 26 Nov 2002 08:43:56 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08447 for ; Tue, 26 Nov 2002 09:43:50 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA17043; Tue, 26 Nov 2002 08:43:16 -0800 (PST) Message-Id: <5.1.0.14.0.20021126113439.02fce5d8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Nov 2002 11:43:07 -0500 To: "Christian Huitema" From: Margaret Wasserman Subject: RE: one question... Cc: "Mark Smith" , "Keith Moore" , 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 Christian, I am not stuck on the idea that GUPIs need to be globally routable. At this point, my problem statement only has two real requirements, both based on the valid reasons that people have given for using site-local addresses on non-isolated networks: - ISP Independence: No need to renumber when you change ISPs or an ISP renumbers. Have addresses you can use on intermittently connected networks. - Easy Access Control/Privacy: Suitable for use in home and small office settings and enterprise settings to protect local nodes and services. A non-globally-routable form of GUPI will be much better than site-locals to address the first problem (although they should be routable between enterprises, etc.). I'm not sure about overloading the current site-local space for this purpose, though. I am still in favor of some sort of allocation/registration, however, as I think it is valuable to be able to determine who an address belongs to (when it gets leaked, or when doing remote network management, etc.). Steve Bellovin's proposal may give us a way to solve the second problem (with or without the presence of GUPI addresses). Are there other reasons why folks would choose to use site-local addresses on non-isolated networks? If so, I think that we should also seek architecturally sound ways to address those problems. Margaret At 08:26 AM 11/26/2002 -0800, Christian Huitema wrote: > > - Some companies may pay their ISPs to globally route their > > GUPI addresses. I know that some people don't > > want this to be possible, but I'm not sure why. > > I agree that we should only advise this if we can > > come up with an aggregable method for allocating > > GUPI addresses. > >Margaret, > >You should check the evolution of the size of the DFZ tables, for >example at http://bgp.potaroo.net/. From my neck of the woods, I >perceive a consensus on two points: that rapid growth of the number of >globally routed prefixes is not a good thing; and that the major cause >of growth is "site multi-homing", which translates exactly into "some >companies may pay their ISPs to globally route their (global) >addresses". (Attempts at traffic engineering through clever use of >routing tables is probably the other cause of table growth.) > >The whole point of placing restrictions on the routability of the GUPI >is precisely to thwart attempts to pay your way into the routing table: >whatever the amount of money on the table, the ISP cannot say yes since >it cannot guarantee that other ISPs will route the GUPI. > >-- 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 Tue Nov 26 08:57:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQGvLUu012603; Tue, 26 Nov 2002 08:57:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQGvLfj012602; Tue, 26 Nov 2002 08:57:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQGvHUu012595 for ; Tue, 26 Nov 2002 08:57:17 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQGvRbB022576 for ; Tue, 26 Nov 2002 08:57:27 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18037 for ; Tue, 26 Nov 2002 09:57:22 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQGvDl21241; Tue, 26 Nov 2002 11:57:13 -0500 (EST) Message-Id: <200211261657.gAQGvDl21241@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Mark Smith , ipng@sunroof.eng.sun.com Subject: Re: Taking two steps back (Was: Re: one question...) In-reply-to: (Your message of "Tue, 26 Nov 2002 10:07:10 EST.") <5.1.0.14.0.20021126092449.015d2d60@mail.windriver.com> Date: Tue, 26 Nov 2002 11:57:13 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Let's take two steps back, stop discussing possible solutions for a > moment and discuss the problem statement. I'd like it to be possible for > an enterprise to: > > - Have resources (i.e nodes or services) that are accessible > only to sub-groups within the enterprise (i.e. > departments). Example: a printer that only marketing > is allowed to use. > - Have resources that are available to the whole enterprise, > but that are not accessible outside the enterprise. > Example: An HR benefits website. > - Have resources that are available on an extranet (between a > selected group of enterprises) that are not accessible > to all other enterprises. Example: A supplier/customer > network. > - Have resources that are globally available, and be able to > send global traffic. Example: Google. > > All of these things can be achieved without site-locals, using > provider-allocated global addresses and appropriate configurations of > firewalls, ACLs, route filtering and split DNS. I'm entirely in agreement with the above. However perhaps even another step back is in order. *any* use of addresses for access control is a dubious idea at best. there are too many internal threats, and too many ways to tunnel external threats to an 'interior' node. so I think the purpose of packet and route filtering is not to allow addresses to be used for access control, but instead to protect the network itself (say against DoS attacks) and to make it easier to analyze your network for threats. for instance, by restricting the number of hosts that can receive external traffic from port 80, you only have to analyze the cgi scripts on those hosts that are authorized. but you still need to do port scans on your other hosts to make sure that they're not running unauthorized web servers. and you still need to require good authentication for any resource that is worth protecting. I'm all for having flexible address filtering, but let's not sell it as an access control mechanism. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 10:06:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQI6lUu013367; Tue, 26 Nov 2002 10:06:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQI6lXX013366; Tue, 26 Nov 2002 10:06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQI6iUu013359 for ; Tue, 26 Nov 2002 10:06:44 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQI6sMq002191 for ; Tue, 26 Nov 2002 10:06:54 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17456 for ; Tue, 26 Nov 2002 10:06:49 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 26 Nov 2002 10:06:49 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 26 Nov 2002 10:06:48 -0800 Received: from RED-MSG-02.redmond.corp.microsoft.com ([157.54.12.46]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Tue, 26 Nov 2002 10:06:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: a different approach to site-local's "security" Date: Tue, 26 Nov 2002 10:06:36 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a different approach to site-local's "security" Thread-Index: AcKVKcZt7w8oJ1PzThGGVpHxaZVESQATCL1g From: "Richard Draves" To: "Pekka Savola" , "Steven M. Bellovin" Cc: X-OriginalArrivalTime: 26 Nov 2002 18:06:46.0331 (UTC) FILETIME=[954CC0B0:01C29576] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQI6iUu013360 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Re Steve Bellovin's proposal - > I'd like to hear opinions from pro-site-local people on how > it looks like. It looks a lot like the site prefix table described in draft-ietf-ipngwg-site-prefixes-05. If you don't have site locals then it's OK - better than nothing. But I think it's not as good as site locals, because the "security" of site's global prefix will rest on filtering being done at one point, whereas site locals will be filtered throughout the internet backbone. If GUPIs are filtered in the backbone then they would be better for the same reason. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 10:29:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQITqUu013779; Tue, 26 Nov 2002 10:29:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQITq5Q013778; Tue, 26 Nov 2002 10:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQITnUu013771 for ; Tue, 26 Nov 2002 10:29:49 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQITxbB022852 for ; Tue, 26 Nov 2002 10:29:59 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15129 for ; Tue, 26 Nov 2002 10:29:53 -0800 (PST) Subject: RE: one question... Date: Tue, 26 Nov 2002 10:29:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B04640BD45A@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: one question... Thread-Index: AcKVS2vgIFnVp3xPTiyXWXkpRSuIcwAJSTlQ 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 gAQITnUu013772 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > Margaret Wasserman wrote: > - GUPI addresses may also be used to communicate over > private links with other GUPI-addressed networks. > In other words, several companies may use GUPI > addresses to communicate with each other over > a shared extranet. These types of networks are > quite common in some industries for suppliers/ > customers or data center/clients. This wouldn't > and shouldn't require that multiple companies > share a GUPI prefix, just that they have routes > that point to each other. Yes. > - You may have different "levels" of GUPI addresses within > a single network... Some devices may use addresses > that are filtered at the department level, some > may be filtered at the corporate level, and > some may be filtered at the extranet level, for > example. Yes, but this is not specific to GUPI. > - Some companies may pay their ISPs to globally route their > GUPI addresses. I know that some people don't > want this to be possible, but I'm not sure why. Explosion of the routing table. No-no. > I agree that we should only advise this if we can > come up with an aggregable method for allocating > GUPI addresses. I disagree. We should not advise this for any reason. The reason I proposed a method for aggregatable GUPIs is for the RIRs or whoever would assign these addresses to get a jumpstart at doing it, as it would be very similar to the final goal which is globally unique *and* globally routable. But one problem at a time. We are not ready for global PI yet, aggregatable or not. Let me make myself clear that I will sabotage my own aggregatable proposal if there are no guarantees about the non-routability. The one thing that won't fly is to pervert the use of FEC0::/10 for globally routable purposes. It is not why IANA allocated that prefix. It would be simpler to ask for a new prefix, when time has come. Besides, I will point out that if GUPIs become globally routable, people that wanted private addresses will use 2002:0A00::/24 and we will be back to square one except that we would have created a big PI mess in the global routing table. The fact that globally unique site-locals are aggregatable or not does not change the need to enforce their un-routability. What could reach consensus today is GUSL: Globally unique site-locals. - Globally unique, free, no registration (Charlie Perkins) - GUSL blackholed by default (Bob Hinden) - GUSL BGP routes discarded by default (Michel Py) Optional, if it reaches consensus and if someone implements them: Globally unique, geographically aggregatable, registration needed. Lots of ifs, should not delay process if consensus is reached on what is above. One problem at a time, please. > There will continue to be application-level and mobility > issues with these addresses, or any type of private or > filtered addresses. The problems are reduced by the fact > that the addresses are not ambiguous, but the problems > are not all eliminated. However, it seems that people > _will_ use filtering to create private networks. The > best we can do is try to provide a solution that > mitigates the damage. I agree with the assessment, time to be realistic in what could reach consensus. 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 Nov 26 10:37:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQIb9Uu013873; Tue, 26 Nov 2002 10:37:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQIb9fK013872; Tue, 26 Nov 2002 10:37: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQIb5Uu013865 for ; Tue, 26 Nov 2002 10:37:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQIbGMq011666 for ; Tue, 26 Nov 2002 10:37:16 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27665 for ; Tue, 26 Nov 2002 11:37:04 -0700 (MST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gAQIaLu4016634; Tue, 26 Nov 2002 10:36:21 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAS51510; Tue, 26 Nov 2002 10:29:31 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA18657; Tue, 26 Nov 2002 10:36:24 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15843.48935.931286.854991@thomasm-u1.cisco.com> Date: Tue, 26 Nov 2002 10:36:23 -0800 (PST) To: "Steven M. Bellovin" Cc: Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? In-Reply-To: <20021125193303.6D08C7B6B@berkshire.research.att.com> References: <20021125193303.6D08C7B6B@berkshire.research.att.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 Steven M. Bellovin writes: > Don't forget mergers and private interconnects. The latter are *very* > common, even without counting telecommuters. One shouldn't use > site-local there, but it's a path that often bypasses firewalls and > other official demarcation points. > > If interconnections never occur, we don't need to worry about the > problems that can happen. My fear is that they occur all too often. > (What percentage of queries to the root name servers come from 1918 > addresses?) Am I the only one that finds the term "private interconnect" somewhat specious? As in, if people make larger x-realm internets by plumbing their own wires instead of through an ISP, why should that be thought of differently than the Internet? Maybe that's why this entire concept is so unsettling to me. 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 Nov 26 11:38:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQJcrUu014326; Tue, 26 Nov 2002 11:38:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQJcrmk014325; Tue, 26 Nov 2002 11:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQJcnUu014318 for ; Tue, 26 Nov 2002 11:38:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQJd0bB016244 for ; Tue, 26 Nov 2002 11:39:00 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19292 for ; Tue, 26 Nov 2002 12:38:54 -0700 (MST) Subject: RE: Taking two steps back (Was: Re: one question...) Date: Tue, 26 Nov 2002 11:38:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4D1@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Taking two steps back (Was: Re: one question...) Thread-Index: AcKVX7HYAiMZyqYwQUmdno0vv9gYPwAHtPnQ 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 gAQJcoUu014319 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > - How will these addresses be allocated and/or generated? Charlie Perkins has proposed a perfectly good way. > - Will enterprises end up paying their ISPs to route these > addresses globally? They will try if there is a chance it works. > - If so, we need an aggregable way to allocate/generate > these addresses, so that they won't cause > explosive growth of the IPv6 core routing tables. Not good enough. This would simply trigger people that want private addresses to use 2002:0A00::/24 instead of site-locals and problems will remain. The lack of global routability of site-local addresses is a feature, not a bug. > - If not, then we can probably just allocate these > addresses sequentially and/or randomly. Sequentially guarantees uniqueness. > For the home environment, it would be nice to be able > to ship nodes that are configured, by default, only to > be accessible locally -- i.e. storage devices or home > security systems (I'm actually not that worried that > hackers will use my printer :-)). That's what link-locals are for. If you want to have several subnets in your home (why?), it requires multiple hubs or a switch with VLAN capabilities. It also requires routing between subnets, which implies that this $100 Linksys actually is a L3 switch; sometime maybe but not tomorrow morning. This kind of setup is unlikely to be configured by unsophisticated users, and at that point configuring manually a site-local and RAs would be a no-brainer. > Since these devices will be installed and used by > fairly unsophisticated users (like me :-)) who do > not want to set-up firewalls, ACLs and split DNS > to protect their resources, it would be good if > there were a way for these addresses to recognize > certain prefixes as inherently "local", and only > accept traffic from nodes with addresses within > those prefixes. - Single-subnet, use link-local. - Multiple subnets, this requires some configuration in terms of VLANs anyway and if you can configure VLANs you don't have a problem going to Charlie's server to get your site-local prefix. - Site-locals to VPN to the office: Either the office will provide you with some SLs part of their block, or they will want to know what your prefix is (for ACLs), which in both cases turns out that you have to configure SLs manually. I can't find a reason why you would want site-locals to be automatically configured, and this point has been made before here. 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 Nov 26 12:04:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQK4tUu014895; Tue, 26 Nov 2002 12:04:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQK4tcO014894; Tue, 26 Nov 2002 12:04: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQK4pUu014887 for ; Tue, 26 Nov 2002 12:04:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQK51Mq011047 for ; Tue, 26 Nov 2002 12:05:01 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07721 for ; Tue, 26 Nov 2002 13:04:56 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQK3Zl22096; Tue, 26 Nov 2002 15:03:35 -0500 (EST) Message-Id: <200211262003.gAQK3Zl22096@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Thomas cc: "Steven M. Bellovin" , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? In-reply-to: (Your message of "Tue, 26 Nov 2002 10:36:23 PST.") <15843.48935.931286.854991@thomasm-u1.cisco.com> Date: Tue, 26 Nov 2002 15:03:35 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Am I the only one that finds the term "private > interconnect" somewhat specious? As in, if people > make larger x-realm internets by plumbing their > own wires instead of through an ISP, why should > that be thought of differently than the Internet? even though filtering and policy exists on links in both portions of the network, in the public world the intention is to provide (near) complete interconnection (though some may get better links than others), whereas between private networks the intention is to permit interconnection only between some sets of addresses and prevent it in others. anyway, it seems useful to recognize that the difference exists, and to have shorthand terms to distinguish the different kinds of IP networks. whether such private networks are part of the "Internet" is an ancient debate, and probably not worth revisiting. pragmatically we expect the same IP routers, hosts and applications to run in both kinds of network. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 12:05:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQK54Uu014905; Tue, 26 Nov 2002 12:05:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQK54nf014904; Tue, 26 Nov 2002 12:05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQK4uUu014897 for ; Tue, 26 Nov 2002 12:04:57 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQK57bB024131 for ; Tue, 26 Nov 2002 12:05:07 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16954 for ; Tue, 26 Nov 2002 12:05:01 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQK4cl22112; Tue, 26 Nov 2002 15:04:38 -0500 (EST) Message-Id: <200211262004.gAQK4cl22112@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: one question... In-reply-to: (Your message of "Tue, 26 Nov 2002 10:29:58 PST.") <2B81403386729140A3A899A8B39B04640BD45A@server2000> Date: Tue, 26 Nov 2002 15:04:38 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The one thing that won't fly is to pervert the use of FEC0::/10 for > globally routable purposes. It is not why IANA allocated that prefix. It > would be simpler to ask for a new prefix, when time has come. I agree that FEC0::/10 should not be used for this purpose. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 12:30:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQKU6Uu015797; Tue, 26 Nov 2002 12:30:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQKU608015796; Tue, 26 Nov 2002 12:30:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQKU2Uu015787 for ; Tue, 26 Nov 2002 12:30:02 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQKUCMq024992 for ; Tue, 26 Nov 2002 12:30:12 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19667 for ; Tue, 26 Nov 2002 13:30:06 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQKTql22372; Tue, 26 Nov 2002 15:29:52 -0500 (EST) Message-Id: <200211262029.gAQKTql22372@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Taking two steps back (Was: Re: one question...) In-reply-to: (Your message of "Tue, 26 Nov 2002 11:38:59 PST.") <2B81403386729140A3A899A8B39B046405E4D1@server2000> Date: Tue, 26 Nov 2002 15:29:52 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The lack of global routability of site-local addresses is a > feature, not a bug. I don't think we have concensus on that. there seem to be at least a few people who want PI addresses that *are* routable, or at least, for which such restrictions are not imposed. I'm sympathetic to the concerns about routing table size and routing computation overhead, but I'm not sure that mandatory or even default filtering of GUPIs is the right thing in the long term. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 12:32:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQKWsUu015886; Tue, 26 Nov 2002 12:32:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQKWrPI015885; Tue, 26 Nov 2002 12:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQKWoUu015878 for ; Tue, 26 Nov 2002 12:32:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQKX1Mq025868 for ; Tue, 26 Nov 2002 12:33:01 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21325 for ; Tue, 26 Nov 2002 13:32:55 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAQKWRj23458; Tue, 26 Nov 2002 22:32:27 +0200 Date: Tue, 26 Nov 2002 22:32:27 +0200 (EET) From: Pekka Savola To: Michel Py cc: Margaret Wasserman , Subject: assignment of GUPI [RE: Taking two steps back (Was: Re: one question...)] In-Reply-To: <2B81403386729140A3A899A8B39B046405E4D1@server2000> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 26 Nov 2002, Michel Py wrote: > > - How will these addresses be allocated and/or generated? > > Charlie Perkins has proposed a perfectly good way. I wouldn't call one organization _assigning to end-users_ prefixes from the space of about 2^28 perfectly good, not even _good_. Quite the contrary. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 12:39:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQKdHUu016314; Tue, 26 Nov 2002 12:39:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQKdHNk016313; Tue, 26 Nov 2002 12:39: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQKdEUu016306 for ; Tue, 26 Nov 2002 12:39:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQKdOMq027603 for ; Tue, 26 Nov 2002 12:39:24 -0800 (PST) Received: from mail.nosense.org (44.cust4.nsw.dsl.ozemail.com.au [203.103.159.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08656 for ; Tue, 26 Nov 2002 13:39:16 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 4D43B3B367; Wed, 27 Nov 2002 07:39:12 +1100 (EST) Subject: Re: Taking two steps back (Was: Re: one question...) From: Mark Smith To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.0.20021126092449.015d2d60@mail.windriver.com> References: <5.1.0.14.0.20021126073240.02fc0d78@mail.windriver.com> <200211260543.gAQ5h9l14722@astro.cs.utk.edu> <200211260543.gAQ5h9l14722@astro.cs.utk.edu> <5.1.0.14.0.20021126073240.02fc0d78@mail.windriver.com> <5.1.0.14.0.20021126092449.015d2d60@mail.windriver.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 27 Nov 2002 07:39:12 +1100 Message-Id: <1038343152.3603.408.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, I agree it is useful to consider the problem we are trying to solve, however, my understanding has been that we have been trying to solve the same problem that traditional site-locals were created to solve. I've generally understood the goals of traditional site-locals were : 1) internal / local / site / friend / entity (take your pick) address space that was independent of the global address space assigned by the (one or more) upstream global connectivity provider(s). 2) no external registration required for this "site local" address space. 3) communications sessions (eg TCP sessions) using these "site local" addresses where impervious to global renumbering events. Traditional site-local addressing (fec0::/48 (:: /10-/48) ) met those goals. However, there were some limitations : 1) the "site" name and explanation in the addressing RFC predominantly implies a geographical scope or size for this address space. While people on the ML have said that the word "site" in "site-local" doesn't really have geographical connotations, it is hard to forget the root English definition of the word. In practical terms, I might build a network which considers the whole of Australia as a site when using site-local addressing, which sounds a bit odd. 2) when two entities using site-local addressing attempt to interconnect or merge their networks there is a good chance of subnet addressing collision, necessitating some amount of renumbering of parts of one or the other entities' networks 3) because site-local addressing is duplicated, there is referral ambiguity once multiple sites are connected together via a single router. There were also DNS issues (Keith is the expert on this problem :-) ). 4) any others I've probably forgotten. 5) oops, forgot about people wanting to use site-local to site-local IPv6 NAT when merging / interconnecting networks, rather than renumbering site-local prefixes. Pekka Savola suggested creating near globally unique site local addressing, by filling the /10 through /48 bits of fec0::/48 with a pseudo random or near unique number, derived from a hash of certain values such as MAC addresses or time of day or other reasonable values. This doesn't seem to be a new idea, Paul Francis proposed the same thing in the following ietf draft (worth a read, covers a lot of what has been coming up in emails recently about GUPIs / (near) unique site local addresses) : http://www.join.uni-muenster.de/drafts/draft-francis-ipngwg-unique-site-local-00.txt I've always assumed that the original goals haven't changed, just that near globally unique site local addressing was a solution which addressed the traditional site-local limitations. My discussions and thoughts on things like naming / use etc have really only been in the context of having a better "site-local" solution. Are we happy with the existing problem definition, that (near) globally unique site local addressing is a better solution for than traditional site-local addressing, or have the recent discussions on near globally unique site local addressing / GUPIs caused us to inadvertently loose focus on our problem definition, making it necessary for us to restate and redefine it ? Regards, 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 12:57:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQKvPUu016919; Tue, 26 Nov 2002 12:57:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQKvPnd016918; Tue, 26 Nov 2002 12:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQKvLUu016908 for ; Tue, 26 Nov 2002 12:57:21 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQKvVMq002459 for ; Tue, 26 Nov 2002 12:57:31 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06956 for ; Tue, 26 Nov 2002 12:57:26 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 9B43A4CEE8; Tue, 26 Nov 2002 15:57:25 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id PAA25696; Tue, 26 Nov 2002 15:57:25 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 32C8D7B6B; Tue, 26 Nov 2002 15:57:24 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: ipng From: "Steven M. Bellovin" To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? Mime-Version: 1.0 Content-Type: text/plain Date: Tue, 26 Nov 2002 15:57:24 -0500 Message-Id: <20021126205724.32C8D7B6B@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <20021126020443.BE0444B22@coconut.itojun.org>, itojun@iijlab.net wr i tes: >>>Require the DNS server at the edge of the site be authoritative for the >>>whole of fec0::/10 or blackhole the queries. >>> >>>(I don't think too many people would even want to register site-locals in >>>the _global_ reverse DNS, queriable by anyone -- remember, they're not to >>>be used globally, and reverses in and itself are already considered a >>>"security hazard" by some.) >>> >>>Let's not go down the path of putting site-locals anywhere near the global >>>ip6.arpa. >> >>Sure -- but to keep the load off the root, we need to be *very* sure >>that sites do pretend to be authoritative for them. > > will it help if we ship c.e.f.ip6.int/arpa zone files with BIND, > just like 1.0.0.127.in-addr.arpa? Thinking about it a little more, there's a seriously obscene thing to do here: ship the config files with a * PTR record, resolving to something like "read.RFC.1918.for.these.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 Tue Nov 26 13:08:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQL8fUu017305; Tue, 26 Nov 2002 13:08:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQL8fhA017304; Tue, 26 Nov 2002 13:08:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQL8cUu017294 for ; Tue, 26 Nov 2002 13:08:38 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQL8mMq005655 for ; Tue, 26 Nov 2002 13:08:48 -0800 (PST) Received: from mail.nosense.org (44.cust4.nsw.dsl.ozemail.com.au [203.103.159.44]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13847 for ; Tue, 26 Nov 2002 13:08:45 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id EC7BB3B367; Wed, 27 Nov 2002 08:08:43 +1100 (EST) Subject: RE: one question... From: Mark Smith To: Michel Py Cc: ipng@sunroof.eng.sun.com In-Reply-To: <2B81403386729140A3A899A8B39B04640BD457@server2000> References: <2B81403386729140A3A899A8B39B04640BD457@server2000> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 27 Nov 2002 08:08:43 +1100 Message-Id: <1038344924.3603.437.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2002-11-27 at 02:54, Michel Py wrote: > Mark, > > > Mark Smith > > 2) Globals and GUPIs - you don't want to rely on the > > stability of your allocated globals for your internal > > connectivity, so you roll out GUPI address space as well. > > GUPIs are used for your internal communications ie > > communications that doesn't travel across links that are > > part of the public Internet. > > This wording is confusing. If using tunnels, the endpoints can have > publicly routable addresses and the tunnel address itself can be GUPI. > Even frame-relay sometimes travels over IP. This is a conceptual problem with tunnels, I struggled with it for quite a while in my previous job. The best way I've found to handle it is firstly think about the global routing requirements of the tunnel, and configure the tunnel end points. Once the tunnel is up, forget that there is a sub-VPN IP layer, and, from the point of the view of the attached network, just consider it to be a point-to-point layer 2 link with some slightly unusual transmission characteristics. In my above description, once you consider the VPN to be just a point to point internal link, the GUPI addressed packets do not travel across the public Internet. The outer encapsulating packets do though, but that is the nature of the "layer 2" link you are using. Regards, 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 13:11:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQLBTUu017365; Tue, 26 Nov 2002 13:11:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQLBTod017364; Tue, 26 Nov 2002 13:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQLBQUu017357 for ; Tue, 26 Nov 2002 13:11:26 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQLBaMq006247 for ; Tue, 26 Nov 2002 13:11:36 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15345 for ; Tue, 26 Nov 2002 13:11:31 -0800 (PST) Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA24532; Tue, 26 Nov 2002 13:11:06 -0800 (PST) Message-Id: <5.1.0.14.0.20021126160704.0312fc38@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Nov 2002 16:10:58 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: one question... Cc: In-Reply-To: <2B81403386729140A3A899A8B39B04640BD45A@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Michel, >I agree with the assessment, time to be realistic in what could reach >consensus. Since all we've had so far is a discussion between a few people during a vacation week for many in the U.S., I think it would be premature to try to claim any sort of consensus. I would personally (not speaking as a chair, because I haven't had a chance to discuss this with Bob), like to see some individual Internet Drafts that flesh out the proposals that people have made to the mailing list. If folks could get drafts out in the next week or two, it might actually be possible to start an in depth discussion comparing different proposals. 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 Nov 26 13:17:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQLH0Uu017478; Tue, 26 Nov 2002 13:17:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQLGxTZ017477; Tue, 26 Nov 2002 13:16: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQLGuUu017470 for ; Tue, 26 Nov 2002 13:16:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQLH6Mq007493 for ; Tue, 26 Nov 2002 13:17:07 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16514 for ; Tue, 26 Nov 2002 14:17:01 -0700 (MST) 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 NAA01724; Tue, 26 Nov 2002 13:17:00 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAQLH0X01614; Tue, 26 Nov 2002 13:17:00 -0800 X-mProtect: <200211262117> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIf8EPN; Tue, 26 Nov 2002 13:16:58 PST Message-ID: <3DE3E4CB.FD2C78C2@iprg.nokia.com> Date: Tue, 26 Nov 2002 13:16:59 -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: Pekka Savola CC: IPng Working Group Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Pekka, Pekka Savola wrote: > I wouldn't call one organization _assigning to end-users_ prefixes > from the space of about 2^28 perfectly good, not even _good_. > > Quite the contrary. You forgot to say why. Plus, depending on the constraints, the exponent could conceivably be selected to be a number larger than 28, depending on how many subnets a site-local allocation is expected to have by default. Evan at 2^28, with an average of 10 seconds between allocations, that would last over 80 years. 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 Nov 26 13:18:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQLI9Uu017514; Tue, 26 Nov 2002 13:18:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQLI9EU017513; Tue, 26 Nov 2002 13:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQLI6Uu017505 for ; Tue, 26 Nov 2002 13:18:06 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQLIGMq007878 for ; Tue, 26 Nov 2002 13:18:16 -0800 (PST) Received: from mail.nosense.org (44.cust4.nsw.dsl.ozemail.com.au [203.103.159.44]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17261 for ; Tue, 26 Nov 2002 14:18:10 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 9685B3B367; Wed, 27 Nov 2002 08:18:07 +1100 (EST) Subject: Re: even one reason why provably unique SL is needed? From: Mark Smith To: "Steven M. Bellovin" Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com In-Reply-To: <20021126205724.32C8D7B6B@berkshire.research.att.com> References: <20021126205724.32C8D7B6B@berkshire.research.att.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 27 Nov 2002 08:18:07 +1100 Message-Id: <1038345488.1458.439.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I like it :-) On Wed, 2002-11-27 at 07:57, Steven M. Bellovin wrote: > In message <20021126020443.BE0444B22@coconut.itojun.org>, itojun@iijlab.net wr > i > tes: > >>>Require the DNS server at the edge of the site be authoritative for the > >>>whole of fec0::/10 or blackhole the queries. > >>> > >>>(I don't think too many people would even want to register site-locals in > >>>the _global_ reverse DNS, queriable by anyone -- remember, they're not to > >>>be used globally, and reverses in and itself are already considered a > >>>"security hazard" by some.) > >>> > >>>Let's not go down the path of putting site-locals anywhere near the global > >>>ip6.arpa. > >> > >>Sure -- but to keep the load off the root, we need to be *very* sure > >>that sites do pretend to be authoritative for them. > > > > will it help if we ship c.e.f.ip6.int/arpa zone files with BIND, > > just like 1.0.0.127.in-addr.arpa? > > Thinking about it a little more, there's a seriously obscene thing > to do here: ship the config files with a * PTR record, resolving to > something like "read.RFC.1918.for.these.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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 13:44:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQLihUu017860; Tue, 26 Nov 2002 13:44:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQLihlY017859; Tue, 26 Nov 2002 13:44:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQLidUu017852 for ; Tue, 26 Nov 2002 13:44:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQLiobB023677 for ; Tue, 26 Nov 2002 13:44:50 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06502 for ; Tue, 26 Nov 2002 14:44:44 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAQLiZu24017; Tue, 26 Nov 2002 23:44:35 +0200 Date: Tue, 26 Nov 2002 23:44:35 +0200 (EET) From: Pekka Savola To: "Charles E. Perkins" cc: IPng Working Group Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-Reply-To: <3DE3E4CB.FD2C78C2@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 26 Nov 2002, Charles E. Perkins wrote: > Pekka Savola wrote: > > I wouldn't call one organization _assigning to end-users_ prefixes > > from the space of about 2^28 perfectly good, not even _good_. > > > > Quite the contrary. > > You forgot to say why. Plus, depending on the constraints, the > exponent could conceivably be selected to be a number larger than > 28, depending on how many subnets a site-local allocation is > expected to have by default. Evan at 2^28, with an average of 10 > seconds between allocations, that would last over 80 years. I thought the "why" for no to flat-space end-site allocations by IANA was self-evident. How do you do reverses in an automatic manner (that's about the most significant reason for totally unique, and that's by a long stretch)? What data would you require for an assignment? What do you do when everyone requests assignments? What to do when someone sets up a fancy script which requests assignments at the pace of 1000 per second, just for fun? "No infrastructure" is just so much better. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 13:52:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQLq2Uu017928; Tue, 26 Nov 2002 13:52:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQLq2w3017927; Tue, 26 Nov 2002 13:52: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQLpxUu017920 for ; Tue, 26 Nov 2002 13:51:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQLq9Mq016640 for ; Tue, 26 Nov 2002 13:52:10 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11017 for ; Tue, 26 Nov 2002 14:52:03 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAQLprI24085; Tue, 26 Nov 2002 23:51:53 +0200 Date: Tue, 26 Nov 2002 23:51:53 +0200 (EET) From: Pekka Savola To: Mark Smith cc: Margaret Wasserman , Subject: Re: Taking two steps back (Was: Re: one question...) In-Reply-To: <1038343152.3603.408.camel@dupy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 27 Nov 2002, Mark Smith wrote: [...] > This doesn't seem to be a new idea, Paul Francis proposed the same thing > in the following ietf draft (worth a read, covers a lot of what has been > coming up in emails recently about GUPIs / (near) unique site local > addresses) : > > http://www.join.uni-muenster.de/drafts/draft-francis-ipngwg-unique-site-local-00.txt > > I've always assumed that the original goals haven't changed, just that > near globally unique site local addressing was a solution which > addressed the traditional site-local limitations. [...] This is my assumption as well, and should be remembered when discussing these solutions. If we don't try to invent new uses for site-locals, nearly uniques are just fine, for all intents and purposes IMO. But this discussion is pretty much useless until we have a draft about the problem statement, as it affects which kind of properties are useful. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 13:58:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQLw1Uu017999; Tue, 26 Nov 2002 13:58:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQLw1Cu017998; Tue, 26 Nov 2002 13:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQLvwUu017991 for ; Tue, 26 Nov 2002 13:57:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQLw8bB027349 for ; Tue, 26 Nov 2002 13:58:08 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13005 for ; Tue, 26 Nov 2002 14:58:03 -0700 (MST) 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 NAA03294; Tue, 26 Nov 2002 13:58:02 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAQLw2a23947; Tue, 26 Nov 2002 13:58:02 -0800 X-mProtect: <200211262158> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCBnbUj; Tue, 26 Nov 2002 13:58:00 PST Message-ID: <3DE3EE68.C33AA268@iprg.nokia.com> Date: Tue, 26 Nov 2002 13:58:00 -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: Pekka Savola CC: IPng Working Group Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Pekka, Pekka Savola wrote: > I thought the "why" for no to flat-space end-site allocations by IANA was > self-evident. Well, it's not to me anyway! > How do you do reverses in an automatic manner (that's about the most > significant reason for totally unique, and that's by a long stretch)? This wasn't stated as a requirement. If it is a requirement, then I believe I could design something, but until that is made clear I'd rather not have to do that. > What data would you require for an assignment? None. > What do you do when everyone requests assignments? Rate-limiting has to be part of the solution. Thankfully, it's not very hard. > What to do when someone sets up a fancy > script which requests assignments at the pace of 1000 per second, just > for fun? If they keep doing it, then we ought to filter out extraneous requests. > "No infrastructure" is just so much better. I agree, and I like the randomized solution, as long as it meets the requirements. If not, then I offer a centralized allocation solution as an alternative. 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 Nov 26 14:10:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMAfUu018211; Tue, 26 Nov 2002 14:10:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQMAfGV018210; Tue, 26 Nov 2002 14:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMAcUu018203 for ; Tue, 26 Nov 2002 14:10:38 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQMAnMq022034 for ; Tue, 26 Nov 2002 14:10:49 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29234 for ; Tue, 26 Nov 2002 14:10:43 -0800 (PST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gAQMAGsA015450; Tue, 26 Nov 2002 14:10:16 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAS58582; Tue, 26 Nov 2002 14:03:38 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA18674; Tue, 26 Nov 2002 14:10:31 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15843.61783.185966.796767@thomasm-u1.cisco.com> Date: Tue, 26 Nov 2002 14:10:31 -0800 (PST) To: Pekka Savola Cc: Mark Smith , Margaret Wasserman , Subject: Re: Taking two steps back (Was: Re: one question...) In-Reply-To: References: <1038343152.3603.408.camel@dupy> 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 Pekka Savola writes: > But this discussion is pretty much useless until we have a draft about the > problem statement, as it affects which kind of properties are useful. I agree with this. I'm having a *real* hard time figuring out the set of problems that people are claiming could be solved. 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 Nov 26 14:20:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMK9Uu018448; Tue, 26 Nov 2002 14:20:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQMK9su018447; Tue, 26 Nov 2002 14:20:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMK5Uu018440 for ; Tue, 26 Nov 2002 14:20:05 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQMKGbB004281 for ; Tue, 26 Nov 2002 14:20:16 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24123 for ; Tue, 26 Nov 2002 14:20:10 -0800 (PST) Subject: RE: even one reason why provably unique SL is needed? Date: Tue, 26 Nov 2002 14:20:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B04640BD45D@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: even one reason why provably unique SL is needed? Thread-Index: AcKVjzxEpYSDYBj9RB2+5toWjhDXOgACpjMw From: "Michel Py" To: "Steven M. Bellovin" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQMK6Uu018441 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Steven M. Bellovin wrote: > Thinking about it a little more, there's a seriously > obscene thing to do here: ship the config files with > a * PTR record, resolving to something like > read.RFC.1918.for.these.addresses." I must be a pervert because I like the idea. 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 Nov 26 14:33:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMXaUu018726; Tue, 26 Nov 2002 14:33:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQMXan2018725; Tue, 26 Nov 2002 14:33: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMXXUu018718 for ; Tue, 26 Nov 2002 14:33:33 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQMXhMq028587 for ; Tue, 26 Nov 2002 14:33:43 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01850 for ; Tue, 26 Nov 2002 14:33:38 -0800 (PST) Subject: RE: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Date: Tue, 26 Nov 2002 14:33:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4D3@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Thread-Index: AcKVl+ewMPAUOL7YTNSeFJfqYV1r6AAAqJbw From: "Michel Py" To: "Charles E. Perkins" Cc: "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQMXXUu018719 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Charles E. Perkins > Rate-limiting has to be part of the solution. > Thankfully, it's not very hard. Especially if you cache the requesting ipv4 address or IPv6 prefix for 24 hours or more. One GUSL allocation per IP per day is more than enough. I think that the complete uniqueness is a matter of psychology more than anything else. Even if the odds of collisions with a hash or random are no better than winning the lottery, there are some people that actually win (not me, sigh). Given that Charlie could provide true uniqueness for free, why consider a system that does not provide true uniqueness? 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 Nov 26 14:46:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMkLUu019056; Tue, 26 Nov 2002 14:46:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQMkLbh019055; Tue, 26 Nov 2002 14:46: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMkHUu019048 for ; Tue, 26 Nov 2002 14:46:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQMkRbB011744 for ; Tue, 26 Nov 2002 14:46:28 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16305 for ; Tue, 26 Nov 2002 15:46:22 -0700 (MST) Subject: RE: Taking two steps back (Was: Re: one question...) Date: Tue, 26 Nov 2002 14:46:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4D4@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Taking two steps back (Was: Re: one question...) Thread-Index: AcKVirnu59356QdZQ7CHAfS7Qlj8xQAEam/g From: "Michel Py" To: "Keith Moore" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQMkIUu019049 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> The lack of global routability of site-local addresses >> is a feature, not a bug. > Keith Moore wrote: > I don't think we have concensus on that. There is a DS in the queue, because it has reached consensus. This is part of the IPv6 architecture. What lacks consensus is to change this. > there seem to be at least a few people who want PI > a ddresses that *are* routable, or at least, for which > such restrictions are not imposed. Including me. This is not incompatible with globally unique, not globally routable site-locals, but not the same thing either. > I'm sympathetic to the concerns about routing table size > and routing computation overhead, but I'm not sure that > mandatory or even default filtering of GUPIs is the right > thing in the long term. There is no relation. What we are trying to do here is to remove the ambiguity of site-local addresses, not to create globally routable PI. These are different topics. 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 Nov 26 14:51:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMpWUu019122; Tue, 26 Nov 2002 14:51:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQMpV7n019121; Tue, 26 Nov 2002 14:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMpRUu019114 for ; Tue, 26 Nov 2002 14:51:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQMpcMq003871 for ; Tue, 26 Nov 2002 14:51:38 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19240 for ; Tue, 26 Nov 2002 15:51:30 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAQMpLl23344; Tue, 26 Nov 2002 17:51:21 -0500 (EST) Message-Id: <200211262251.gAQMpLl23344@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "Margaret Wasserman" , ipng@sunroof.eng.sun.com Subject: Re: Taking two steps back (Was: Re: one question...) In-reply-to: (Your message of "Tue, 26 Nov 2002 14:46:27 PST.") <2B81403386729140A3A899A8B39B046405E4D4@server2000> Date: Tue, 26 Nov 2002 17:51:21 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> Michel Py wrote: > >> The lack of global routability of site-local addresses > >> is a feature, not a bug. > > > Keith Moore wrote: > > I don't think we have concensus on that. > > There is a DS in the queue, because it has reached consensus. This is > part of the IPv6 architecture. What lacks consensus is to change this. sorry, I thought you were using "site-local" in a broader sense than that which is in the these documents. it's hard to keep track of semantic drift. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 14:54:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMs6Uu019170; Tue, 26 Nov 2002 14:54:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQMs62K019169; Tue, 26 Nov 2002 14:54:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMs2Uu019159 for ; Tue, 26 Nov 2002 14:54:03 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQMsDMq004573 for ; Tue, 26 Nov 2002 14:54:13 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22951 for ; Tue, 26 Nov 2002 14:54:07 -0800 (PST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gAQMrugU003331; Wed, 27 Nov 2002 09:53:56 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211262253.gAQMrugU003331@drugs.dv.isc.org> To: "Michel Py" Cc: "Steven M. Bellovin" , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: even one reason why provably unique SL is needed? In-reply-to: Your message of "Tue, 26 Nov 2002 14:20:16 -0800." <2B81403386729140A3A899A8B39B04640BD45D@server2000> Date: Wed, 27 Nov 2002 09:53:56 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Steven M. Bellovin wrote: > > Thinking about it a little more, there's a seriously > > obscene thing to do here: ship the config files with > > a * PTR record, resolving to something like > > read.RFC.1918.for.these.addresses." > > I must be a pervert because I like the idea. > > 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 > -------------------------------------------------------------------- It's been done in the past. It has some interesting effects on certian network management software that results in the entire local network becoming a single machine. 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 Nov 26 14:55:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMt0Uu019199; Tue, 26 Nov 2002 14:55:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQMt0lw019198; Tue, 26 Nov 2002 14:55:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMsuUu019190 for ; Tue, 26 Nov 2002 14:54:56 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQMt7bB013964 for ; Tue, 26 Nov 2002 14:55:07 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23569 for ; Tue, 26 Nov 2002 14:55:01 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAQMst724679; Wed, 27 Nov 2002 00:54:55 +0200 Date: Wed, 27 Nov 2002 00:54:54 +0200 (EET) From: Pekka Savola To: Michel Py cc: "Charles E. Perkins" , IPng Working Group Subject: RE: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-Reply-To: <2B81403386729140A3A899A8B39B046405E4D3@server2000> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 26 Nov 2002, Michel Py wrote: > I think that the complete uniqueness is a matter of psychology more than > anything else. Even if the odds of collisions with a hash or random are > no better than winning the lottery, there are some people that actually > win (not me, sigh). Given that Charlie could provide true uniqueness for > free, why consider a system that does not provide true uniqueness? I'm not sure whether you haven't been listening or don't agree with my (and some others') reasoning. Nearly unique is IMO much better than completely unique. (Actually, 2^38 may even be too unique by the same reasoning.) That's because those addresses are meant to be unique _only_ within a scope. Addresses leak, yes, but that doesn't hurt when the probably of collision then is suitably low (e.g. below 0.1%). If the addresses are _unnecessarily_ unique, they will be used for wrong purposes, no matter what. It's better that people don't associate _any_ addresses that are not of global scope to be globally unique. IMO we will not want to have site-locals be too attractive: we don't want to have (too big) competition to global-scope addresses. IMO we want _IPv6_ users to use _globals_, and (some) site-locals only when they more or less have to. Globally unique PI addresses are a step in entirely wrong direction. As you see, these are not really all that "technical" reasons, but I don't want to see the world where people are using IPv6 with similar walled-gardens as NAT's create today. (and besides, with "nearly unique" there's no need for any infrastructure to support them.) Note: I'm not disputing the (possible) usefulness of globally unique PI for e.g. multihoming etc. purposes, but those are _global scope_ addresses, and that's not the point here. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 14:55:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMtSUu019225; Tue, 26 Nov 2002 14:55:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQMtRcW019220; Tue, 26 Nov 2002 14:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQMtKUu019212 for ; Tue, 26 Nov 2002 14:55:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQMtUMq004923 for ; Tue, 26 Nov 2002 14:55:30 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12407 for ; Tue, 26 Nov 2002 15:55:25 -0700 (MST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAQMtKKc005129; Tue, 26 Nov 2002 14:55:20 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAS60101; Tue, 26 Nov 2002 14:48:26 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA18680; Tue, 26 Nov 2002 14:55:18 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15843.64470.724577.501278@thomasm-u1.cisco.com> Date: Tue, 26 Nov 2002 14:55:18 -0800 (PST) To: "Michel Py" Cc: "Keith Moore" , "Margaret Wasserman" , Subject: RE: Taking two steps back (Was: Re: one question...) In-Reply-To: <2B81403386729140A3A899A8B39B046405E4D4@server2000> References: <2B81403386729140A3A899A8B39B046405E4D4@server2000> 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 Michel Py writes: > There is no relation. What we are trying to do here is to remove the > ambiguity of site-local addresses, not to create globally routable PI. > These are different topics. This is not entirely clear. There seems to be a fair amount of cake-and-eat-it-too going on here when people start talking about interconnecting different sites. 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 Nov 26 15:00:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQN0aUu019432; Tue, 26 Nov 2002 15:00:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQN0aD0019431; Tue, 26 Nov 2002 15:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQN0WUu019418 for ; Tue, 26 Nov 2002 15:00:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQN0gMq006448 for ; Tue, 26 Nov 2002 15:00:43 -0800 (PST) Received: from TNEXVS01.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15255 for ; Tue, 26 Nov 2002 16:00:37 -0700 (MST) Received: from TNEXVS02.tahoenetworks.com ([10.10.1.132]) by TNEXVS01.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Nov 2002 15:00:37 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Taking two steps back (Was: Re: one question...) x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 26 Nov 2002 15:00:37 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A347@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Taking two steps back (Was: Re: one question...) Thread-Index: AcKVixYQ+98Qe+PGQASe5FJT38IrZAAE6XVg From: "Mohan Parthasarathy" To: "Keith Moore" , "Michel Py" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 26 Nov 2002 23:00:37.0475 (UTC) FILETIME=[A247D330:01C2959F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQN0WUu019419 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, > > The lack of global routability of site-local addresses is a > feature, > > not a bug. > > I don't think we have concensus on that. there seem to be at > least a few people who want PI addresses that *are* > routable, or at least, for which such restrictions are not imposed. > I am just trying to understand this part. From what I can understand, the relative stability of the GUPI addresses with respect to global addresses is higher. Is that the sole reason why you would pay an ISP to route these prefixes instead of getting a global prefix from the same ISP ? What are the reasons why uou want the GUPI to be routeable ? thanks mohan > I'm sympathetic to the concerns about routing table size and > routing computation overhead, but I'm not sure that mandatory > or even default filtering of GUPIs is the right thing in the > long term. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 15:08:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQN8wUu019819; Tue, 26 Nov 2002 15:08:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQN8w9O019818; Tue, 26 Nov 2002 15:08:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQN8sUu019811 for ; Tue, 26 Nov 2002 15:08:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQN94bB018856 for ; Tue, 26 Nov 2002 15:09:05 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27868 for ; Tue, 26 Nov 2002 16:08:59 -0700 (MST) Subject: RE: Taking two steps back (Was: Re: one question...) Date: Tue, 26 Nov 2002 15:09:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4D6@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Taking two steps back (Was: Re: one question...) Thread-Index: AcKVixYQ+98Qe+PGQASe5FJT38IrZAAE6XVgAABKycA= From: "Michel Py" To: "Mohan Parthasarathy" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQN8tUu019812 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mohan, > Mohan Parthasarathy wrote: > I am just trying to understand this part. From what I > can understand, the relative stability of the GUPI > addresses with respect to global addresses is higher. > Is that the sole reason why you would pay an ISP to > route these prefixes instead of getting a global prefix > from the same ISP ? What are the reasons why uou want > the GUPI to be routeable ? There are two main reasons why you would pay the ISP to leak a prefix: 1. You want to multihome. 2. You want to be able to switch ISPs without renumbering. 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 Nov 26 15:20:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQNKWUu020081; Tue, 26 Nov 2002 15:20:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQNKVQm020080; Tue, 26 Nov 2002 15:20: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQNKSUu020073 for ; Tue, 26 Nov 2002 15:20:28 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQNKdMq012101 for ; Tue, 26 Nov 2002 15:20:39 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07426 for ; Tue, 26 Nov 2002 15:20:33 -0800 (PST) Subject: RE: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Date: Tue, 26 Nov 2002 15:20:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4D5@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Thread-Index: AcKVnv0ZRssmGy2dS063z2bcwurb9AAABf2A From: "Michel Py" To: "Pekka Savola" Cc: "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQNKSUu020074 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > Pekka Savola wrote: > That's because those addresses are meant to be unique > _only_ within a scope. Addresses leak, yes, but that > doesn't hurt when the probably of collision then is > suitably low (e.g. below 0.1%). Go tell that to the network administrator that "wins". Only two ways out: renumber or NAT. Both a pain. Network administrators don't take chances with a 1 in 1000 odd. > If the addresses are _unnecessarily_ unique, they will be > used for wrong purposes, no matter what. Your proposal is good enough for people to use them from wrong purposes too. What you are talking about is the very principle of ambiguity: ambiguity (vs. unique) guarantees that the addresses will not be routed globally. > IMO we will not want to have site-locals be too attractive: > we don't want to have (too big) competition to global-scope > addresses. IMO we want _IPv6_ users to use _globals_, and > (some) site-locals only when they more or less have to. Agreed. > Globally unique PI addresses are a step in entirely wrong > direction. If they are not aggregatable. > As you see, these are not really all that "technical" > reasons, but I don't want to see the world where people > are using IPv6 with similar walled-gardens as NAT's > create today. Agreed. > (and besides, with "nearly unique" there's no need for > any infrastructure to support them.) A server to implement a counter is not "infrastructure", which is why Charlie offered to provide the service for free. > Note: I'm not disputing the (possible) usefulness of > globally unique PI for e.g. multihoming etc. purposes, > but those are _global scope_ addresses, and that's not > the point here. Agreed. Here's the deal: any mechanism that makes site-locals less ambiguous is a danger to bad usage. Mechanisms that are ambiguous enough not to be a danger are worthless as they don't solve the ambiguity issue. Mechanisms that are good enough to solve the ambiguity issue (including yours) are a danger no matter what the risk of collision is. If you increase the collision risk to the point that people would not be tempted to route globally, at the same time you miss the goal which is to resolve ambiguity. The goal is to eliminate ambiguity. Focus on what to do in order to reduce the risk of bad use, no try to knob the level of ambiguity. 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 Nov 26 15:30:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQNUKUu020227; Tue, 26 Nov 2002 15:30:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAQNUKcq020226; Tue, 26 Nov 2002 15:30: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAQNUGUu020216 for ; Tue, 26 Nov 2002 15:30:16 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAQNURMq014980 for ; Tue, 26 Nov 2002 15:30:27 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12550 for ; Tue, 26 Nov 2002 15:30:22 -0800 (PST) Subject: RE: Taking two steps back (Was: Re: one question...) Date: Tue, 26 Nov 2002 15:30:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4D7@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Taking two steps back (Was: Re: one question...) Thread-Index: AcKVnn6UZ+Zw4+ymQBGE2ijBNUrqiAABAfbA From: "Michel Py" To: "Keith Moore" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAQNUHUu020217 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, > Keith Moore wrote: > sorry, I thought you were using "site-local" in a broader > sense than that which is in the these documents. What kind of broader sense? I am sympathetic to ambiguity being a pain in the kazoo, but it does guarantee to some extend that SLs are not publicly routable. I'm all for removing ambiguity, but not at the cost of removing the lack of routability at the same time. Since you agree that FEC0::/10 should not be used for publicly routable addresses, what issues do you have with having FEC0::/10 used as globally unique, not globally routable, site-local addresses (which could be achieved now) *and* another future block for aggregatable, globally unique, globally routable addresses (which will take more time to get)? 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 Nov 26 17:39:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR1doUu021581; Tue, 26 Nov 2002 17:39:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAR1doUD021580; Tue, 26 Nov 2002 17:39: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR1dkUu021573 for ; Tue, 26 Nov 2002 17:39:46 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAR1dubB027885 for ; Tue, 26 Nov 2002 17:39:56 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06139 for ; Tue, 26 Nov 2002 17:39:51 -0800 (PST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gAR1dgLr003574 for ; Tue, 26 Nov 2002 18:39:42 -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 SAA25981 for ; Tue, 26 Nov 2002 18:39:48 -0700 (MST)] Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gAR1dj7C021519 for ; Wed, 27 Nov 2002 12:39:46 +1100 (EST) Message-ID: <3DE42261.1D450A4A@motorola.com> Date: Wed, 27 Nov 2002 12:39:45 +1100 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: Taking two steps back References: <2B81403386729140A3A899A8B39B046405E4D1@server2000> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: > - Multiple subnets, this requires some configuration in terms of VLANs > anyway and if you can configure VLANs you don't have a problem going to > Charlie's server to get your site-local prefix. I disagree. Several people have already *built* multi-subnet multi-router systems which require minimal user configuration (see zerouter BOF). I don't want to administer my routers - I want to plug them together and have them work. And I want this to work independent of the presence or absence of an ISP. Sure, I could build the network as one massive layer-2 bridged subnet (um, lets delegate that up to layer 3 instead rather than reimplement routing at layer 2) or a multi-link subnet (has possibilities), but there are advantages to running a traditional L3 subnetted architecture. This is why I find the idea of generating an entire /64 prefix per subnet without needing ANY interaction beyond the router so attractive. Why should humans be doing work that the routers can do themselves? > I can't find a reason why you would want site-locals to be automatically > configured, and this point has been made before here. I've built (experimental) networks that rely on this functionality. And it's possible to apply most of these mechanisms for globals too. -- 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 Nov 26 18:32:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR2WvUu022144; Tue, 26 Nov 2002 18:32:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAR2Wvcq022143; Tue, 26 Nov 2002 18:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR2WsUu022136 for ; Tue, 26 Nov 2002 18:32:54 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAR2X4bB009732 for ; Tue, 26 Nov 2002 18:33:05 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08660 for ; Tue, 26 Nov 2002 18:32:59 -0800 (PST) Subject: RE: Taking two steps back Date: Tue, 26 Nov 2002 18:33:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4D8@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Taking two steps back Thread-Index: AcKVtozVnqD+Pl6+RJ2kToNaCENbzQABDCaw From: "Michel Py" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAR2WsUu022137 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew, > Andrew White wrote: > This is why I find the idea of generating an entire > /64 prefix per subnet without needing ANY interaction > beyond the router so attractive. Why should humans be > doing work that the routers can do themselves? We are not talking about each individual subnet, but about the initial /48 that would seed the subnets. Be realistic: zero configuration does not exist. When you take the router out of the box, you will get into it to change the default password and put your domain name in. Don't tell me that typing a SL prefix at the same time is much of an administrative overhead. I'm not too hot about zeroconf for site-locals. As several other persons contributed, we should not make site-locals too easy. Zeroconf for global prefixes, great. That being said, I do see a need for SL autoconfiguration. There is enough room in FEC0::/10 to have both a range for random/hash autoconfiguration *and* one or more ranges for people that want truly unique prefixes. When initially configuring the site-local prefix, the user must have the choice of: 1. Manual entry. 2. Contact prefix serving service (Charlie's style). 3. Autoconfig with hash/random. Looks better? 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 Nov 26 18:44:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR2iqUu022240; Tue, 26 Nov 2002 18:44:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAR2iqFO022239; Tue, 26 Nov 2002 18:44: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR2inUu022232 for ; Tue, 26 Nov 2002 18:44:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAR2ixbB011702 for ; Tue, 26 Nov 2002 18:44:59 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15623 for ; Tue, 26 Nov 2002 19:44:53 -0700 (MST) Subject: RE: Taking two steps back (Was: Re: one question...) Date: Tue, 26 Nov 2002 18:44:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4D9@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Taking two steps back (Was: Re: one question...) Thread-Index: AcKVjLeVaEtrcCdfQlO22E0nrb9j3wAMTzIA From: "Michel Py" To: "Mark Smith" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAR2inUu022233 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mark Smith wrote: > Are we happy with the existing problem definition, that > (near) globally unique site local addressing is a better > solution for than traditional site-local addressing, I think yes, but only if we address the unreachability / not-publicly-routable issue at the same time. > have the recent discussions on near globally unique site > local addressing / GUPIs caused us to inadvertently loose > focus on our problem definition, making it necessary for > us to restate and redefine it ? I think the problem definition is to get rid of ambiguity for site-local addresses. Whether it leads to almost unique, completely unique, or a mix of both is debatable. 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 Nov 26 20:31:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR4VjUu022739; Tue, 26 Nov 2002 20:31:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAR4Vjlr022738; Tue, 26 Nov 2002 20:31:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR4VfUu022731 for ; Tue, 26 Nov 2002 20:31:41 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAR4VpMq022759 for ; Tue, 26 Nov 2002 20:31:51 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA23071 for ; Tue, 26 Nov 2002 20:31:46 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAR4Val23991; Tue, 26 Nov 2002 23:31:36 -0500 (EST) Message-Id: <200211270431.gAR4Val23991@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , ipng@sunroof.eng.sun.com Subject: Re: Taking two steps back (Was: Re: one question...) In-reply-to: (Your message of "Tue, 26 Nov 2002 15:30:26 PST.") <2B81403386729140A3A899A8B39B046405E4D7@server2000> Date: Tue, 26 Nov 2002 23:31:36 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Keith Moore wrote: > > sorry, I thought you were using "site-local" in a broader > > sense than that which is in the these documents. > > What kind of broader sense? people have been talking about globally unique site locals. > I am sympathetic to ambiguity being a pain in the kazoo, but it does > guarantee to some extend that SLs are not publicly routable. I'm all for > removing ambiguity, but not at the cost of removing the lack of > routability at the same time. lack of routability is not entirely a feature. it's more like a mixed bag. constraining the routing table might be a laudable goal. otoh it can't be justified from a security standpoint. > Since you agree that FEC0::/10 should not be used for publicly routable > addresses, what issues do you have with having FEC0::/10 used as > globally unique, not globally routable, site-local addresses (which > could be achieved now) *and* another future block for aggregatable, > globally unique, globally routable addresses (which will take more time > to get)? imho we have too many different kinds of addresses already, and we're putting way too much burden on the idea that hosts should be able to select which addresses are best for their purposes and the network conditions. so while I agree in principle that we can't use FEC0://10 for GUPIs, I hope that in practice FEC0://10 is mostly used for isolated 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 Tue Nov 26 20:50:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR4oXUu022812; Tue, 26 Nov 2002 20:50:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAR4oXMK022811; Tue, 26 Nov 2002 20:50:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR4oTUu022804 for ; Tue, 26 Nov 2002 20:50:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAR4odbB000910 for ; Tue, 26 Nov 2002 20:50:39 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05281 for ; Tue, 26 Nov 2002 21:50:33 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAR4nBl24576; Tue, 26 Nov 2002 23:49:11 -0500 (EST) Message-Id: <200211270449.gAR4nBl24576@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Michel Py , "Charles E. Perkins" , IPng Working Group Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-reply-to: (Your message of "Wed, 27 Nov 2002 00:54:54 +0200.") Date: Tue, 26 Nov 2002 23:49:11 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Globally unique PI addresses are a step in entirely wrong direction. I entirely disagree. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 20:51:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR4pcUu022832; Tue, 26 Nov 2002 20:51:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAR4pcxL022831; Tue, 26 Nov 2002 20:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR4pYUu022824 for ; Tue, 26 Nov 2002 20:51:34 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAR4piMq025536 for ; Tue, 26 Nov 2002 20:51:44 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16119 for ; Tue, 26 Nov 2002 21:51:39 -0700 (MST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gAR4pdi5005032 for ; Tue, 26 Nov 2002 21:51:39 -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 VAA16965 for ; Tue, 26 Nov 2002 21:51:36 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gAR4pV7C011667; Wed, 27 Nov 2002 15:51:32 +1100 (EST) Message-ID: <3DE44F53.2000805@motorola.com> Date: Wed, 27 Nov 2002 15:51:31 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: DNSOP WG Subject: short circuiting reverse lookups (resend) References: <20021126020443.BE0444B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: >>Sure -- but to keep the load off the root, we need to be *very* sure >>that sites do pretend to be authoritative for them. > > will it help if we ship c.e.f.ip6.int/arpa zone files with BIND, > just like 1.0.0.127.in-addr.arpa? > Yes, potentially. Further, I would like to see a recommendation that authoritative RFC1918 reverse maps are a default part of name server boot files along the lines of RFC1912, Section 4.1. Stepping back for a moment, I think we are failing to note that this is *not* just an IPv6 problem. The increasing volume of root queries for RFC1918 PTR maps is presumably related to the increasing number of hosts on the internet behind NAT boxes. We should expect internet growth to continue and therefore that the number of bogus IPv4 queries will also continue to grow unless some action is taken. We should get the IPv6 case right. However if we believe that dual stack is the likely IPv6 deployment scenario we are only addressing well less than half the immediate problem. - 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 Tue Nov 26 22:55:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR6tCUu023272; Tue, 26 Nov 2002 22:55:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAR6tC7f023271; Tue, 26 Nov 2002 22:55: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR6t9Uu023264 for ; Tue, 26 Nov 2002 22:55:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAR6tJbB017921 for ; Tue, 26 Nov 2002 22:55:19 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA22229 for ; Tue, 26 Nov 2002 23:55:12 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAR6t3H28341; Wed, 27 Nov 2002 08:55:03 +0200 Date: Wed, 27 Nov 2002 08:55:02 +0200 (EET) From: Pekka Savola To: Keith Moore cc: Michel Py , "Charles E. Perkins" , IPng Working Group Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-Reply-To: <200211270449.gAR4nBl24576@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 26 Nov 2002, Keith Moore wrote: > > Globally unique PI addresses are a step in entirely wrong direction. I should have said "globally unique PI site-local addresses" but that does not probably change your statement. > I entirely disagree. Care to elaborate a bit? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 26 23:57:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR7vQUu023433; Tue, 26 Nov 2002 23:57:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAR7vPGu023432; Tue, 26 Nov 2002 23:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR7vMUu023425 for ; Tue, 26 Nov 2002 23:57:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAR7vWMq020549 for ; Tue, 26 Nov 2002 23:57:33 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28078 for ; Wed, 27 Nov 2002 00:57:26 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAR7vJ2D072074; Wed, 27 Nov 2002 08:57:20 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAR7vHaV051220; Wed, 27 Nov 2002 08:57:18 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA30334 from ; Wed, 27 Nov 2002 08:57:15 +0100 Message-Id: <3DE47AC5.6AF9581B@hursley.ibm.com> Date: Wed, 27 Nov 2002 08:56:53 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Aidan Williams Cc: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <200211260104.gAQ14Bl13677@astro.cs.utk.edu> <3DE3178F.83071AA3@motorola.com> <3DE3421A.229A586D@hursley.ibm.com> <3DE40671.4030200@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I can't imagine operating two different subnet addressing plans within a given organisation, just because I have two different prefixes. Operationally and administratively, that would be a nightmare. And I can't imagine, in a 128 bit address space, being limited to less than 16 bits to design my subnet addressing plan, in a large organisation with hundreds of physical sites. So I am unconditionally against any scheme that generates prefixes longer than /48. Brian Aidan Williams wrote: > > Brian E Carpenter wrote: > > In a word: no. We mustn't generate prefixes longer than /48, since > > everybody will be designing 16 bit subnet addressing plans. > > My understanding is that the /48 is intended to facilitate > renumbering by notionally swapping the old prefix with the > new one. > > I don't see that this directly applies to site local because > the notion of swapping out site local prefixes for a global > prefix doesn't make sense to me. > > Once, people may have thought IPv6 would be deployed first > with site-locals and then people would lay their globals over > their site-local addressing plan. Is that realistic today? > I have just gone straight for globals using 6to4 and I want > site-locals because my 6to4 addresses are not as stable as > I would like. > > > It isn't > > acceptable to have different subnet addressing plans with site local > > and global prefixes. > > > > Why not? The address format proposed below doesn't need an > addressing plan and will work in parallel with an aggregetable > unicast addressing plan. > > - aidan > > > Brian > > > > Andrew White wrote: > > > >>Some thoughts: > >> > >>As a method of doing globally unique site local addressing: > >> > >>Assuming aggregability is not an issue within a 'site' sized network, > >>consider generating site local subnet identifiers at the router, based on > >>IEEE EUI-48 identifiers (such as MAC addresses). > >> > >>For example, generate as fec0::/12: > >> > >>12 bits: fef > >>48 bits: MAC > >> 4 bits: 0 or subnets > >> > >>or, if we don't want them in fec0::/10 > >> > >>10 bits: fe0 > >>48 bits: MAC > >> 6 bits: 0 or subnets > >> > >>The '0 or subnets' is to allow for the possibility of choosing one EUI-48 on > >>a router and using that to allocate all appropriate subnets. > >> > >>By piggybacking on the existing registration scheme, we generate "unique" > >>site-local subnet ids at the router without needing external registration or > >>administration. > >> > >>Despite the zero-config nature of this, administration on the router is > >>still necessary, both to enable this mode (probably don't want site-local > >>behaviour enabled by default) and to determine whether a router is > >>authoritative for the link. An administrator may wish to configure a > >>multi-router link with the subnet prefix of only one router. > >> > >>An internet-draft describing this in more detail is written and will be > >>submitted in the next day or so. Comments welcome. > >> > >>Another comment on uniqueness: > >> > >>Under IPv6, even an ambiguous prefix is likely to not resolve to an address > >>because of the MAC generated machine id, so the likelihood of collision is > >>lower than might be expected from the prefix. > >> > >>Final thought: > >> > >>Whatever the outcome of the site local discussions, renumbering will remain > >>a serious problem under IPv6, that needs to be considered. Making > >>renumbering easier is a hard problem, but a good solution will help reduce a > >>variety of other problems. > >> > >>-- > >>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 Wed Nov 27 00:03:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR83OUu023527; Wed, 27 Nov 2002 00:03:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAR83OL9023526; Wed, 27 Nov 2002 00:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAR83LUu023519 for ; Wed, 27 Nov 2002 00:03:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAR83VbB027747 for ; Wed, 27 Nov 2002 00:03:31 -0800 (PST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28002 for ; Wed, 27 Nov 2002 01:03:25 -0700 (MST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAR83GC3006832; Wed, 27 Nov 2002 09:03:20 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAR83FkQ045216; Wed, 27 Nov 2002 09:03:16 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA30424 from ; Wed, 27 Nov 2002 09:03:14 +0100 Message-Id: <3DE47C2C.941371E5@hursley.ibm.com> Date: Wed, 27 Nov 2002 09:02:52 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Keith Moore Cc: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <200211261613.gAQGDJl20647@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > For the sake of completeness: > > Another idea I heard last week (sorry, I forget who suggested it) > is to use the number of seconds since some epoch (say 2002.01.01 0000 UTC) > when the network was established, as the probably-unique prefix. > > Though I do wonder whether we might see multiple networks automatically > "turned on" at the same "round number" time, causing collisions. Well, it's a one-off function ("get me a prefix now!") that never needs to be repeated, and doing it automatically at a set time would indeed be a MUST NOT. But apart from that I like the idea - if we did it in a 38 bit field under FEC0::/10 it takes a few thousand years to wrap, it doesn't need a seed like a random number generator, and it's free. Brian > > Keith > > > As a method of doing globally unique site local addressing: > > > > Assuming aggregability is not an issue within a 'site' sized network, > > consider generating site local subnet identifiers at the router, based on > > IEEE EUI-48 identifiers (such as MAC addresses). > > > > For example, generate as fec0::/12: > > > > 12 bits: fef > > 48 bits: MAC > > 4 bits: 0 or subnets > > > > or, if we don't want them in fec0::/10 > > > > 10 bits: fe0 > > 48 bits: MAC > > 6 bits: 0 or subnets > > > > The '0 or subnets' is to allow for the possibility of choosing one EUI-48 on > > a router and using that to allocate all appropriate subnets. > > > > By piggybacking on the existing registration scheme, we generate "unique" > > site-local subnet ids at the router without needing external registration or > > administration. > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 03:48:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARBmVUu024785; Wed, 27 Nov 2002 03:48:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARBmVon024784; Wed, 27 Nov 2002 03:48: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARBmRUu024777 for ; Wed, 27 Nov 2002 03:48:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARBmbbB027577 for ; Wed, 27 Nov 2002 03:48:37 -0800 (PST) Received: from purgatory.unfix.org (cust.92.136.adsl.cistron.nl [195.64.92.136]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19381 for ; Wed, 27 Nov 2002 04:48:31 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 8AD8F7C3D; Wed, 27 Nov 2002 12:48:14 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff: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 1D3A377B5; Wed, 27 Nov 2002 12:48:08 +0100 (CET) From: "Jeroen Massar" To: "'Aidan Williams'" , Cc: "'DNSOP WG'" Subject: RE: short circuiting reverse lookups (resend) Date: Wed, 27 Nov 2002 12:49:06 +0100 Organization: Unfix Message-ID: <000701c2960a$feaa2cc0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3DE44F53.2000805@motorola.com> X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gARBmSUu024778 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Aidan Williams wrote: > itojun@iijlab.net wrote: > >>Sure -- but to keep the load off the root, we need to be > *very* sure > >>that sites do pretend to be authoritative for them. > > > > will it help if we ship c.e.f.ip6.int/arpa zone files with BIND, > > just like 1.0.0.127.in-addr.arpa? > > > > Yes, potentially. Further, I would like to see a recommendation > that authoritative RFC1918 reverse maps are a default part of > name server boot files along the lines of RFC1912, Section 4.1. > > Stepping back for a moment, I think we are failing to note > that this is *not* just an IPv6 problem. > > The increasing volume of root queries for RFC1918 PTR maps is > presumably related to the increasing number of hosts on the > internet behind NAT boxes. We should expect internet growth > to continue and therefore that the number of bogus IPv4 queries > will also continue to grow unless some action is taken. > > We should get the IPv6 case right. However if we believe that > dual stack is the likely IPv6 deployment scenario we are only > addressing well less than half the immediate problem. Fortunatly we have AS112 (www.as112.net), but looking at the stats eg http://www.ripe.net/as112/ it's a lot. Making RFC1918 and fec0:: and other 'special interest assigned' spaces a default for a nameserver could solve these problems. People wanting to use RFC1918 space could then still comment out the blackhole and redirect it somewhere else or define it locally. One could see a 'problem' where users will start having problems as their 'local reverse doesn't work' but the problem being the double definement. BIND and others warn for double definitions so that shouldn't be a big item certainly if a nice FAQ item is included. And it will save a lot of traffic which is currently still flowing to the rootservers or the as112 boxes. 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 Nov 27 05:35:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARDZDUu025420; Wed, 27 Nov 2002 05:35:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARDZDcC025419; Wed, 27 Nov 2002 05:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARDZ9Uu025412 for ; Wed, 27 Nov 2002 05:35:09 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARDZIbB010844 for ; Wed, 27 Nov 2002 05:35:18 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12771 for ; Wed, 27 Nov 2002 06:35:13 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARDXkl28909; Wed, 27 Nov 2002 08:33:46 -0500 (EST) Message-Id: <200211271333.gARDXkl28909@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Keith Moore , Michel Py , "Charles E. Perkins" , IPng Working Group Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-reply-to: (Your message of "Wed, 27 Nov 2002 08:55:02 +0200.") Date: Wed, 27 Nov 2002 08:33:46 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > Globally unique PI addresses are a step in entirely wrong direction. > > I should have said "globally unique PI site-local addresses" but that does > not probably change your statement. > > > I entirely disagree. > > Care to elaborate a bit? we've been talking about this for weeks. the worst problems with site-locals are their ambiguity; we need global uniqueness to get rid of that ambiguity and also to allow them to be reliably routed between sites. however we may just be using the words in slightly different ways - globally unique vs. probably unique, site-local (FEC0::/10) vs. some site-specific address space TBD, etc. I currently think - we need a new address space for globally-unique PI addresses (GUPIs) - some mechanism for ensuring global uniqueness is probably better than having those addresses be probably unique - we need an understanding that GUPIs are not globally routable unless/until we know how to make that routing scale - but NOT an architectural limitation against it - use of site-locals (FEC0:://10) should be discouraged in general with a possible exception for isolated/test networks -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 05:53:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARDrpUu025561; Wed, 27 Nov 2002 05:53:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARDrppb025560; Wed, 27 Nov 2002 05:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARDrmUu025553 for ; Wed, 27 Nov 2002 05:53:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARDrwMq013451 for ; Wed, 27 Nov 2002 05:53:58 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16390 for ; Wed, 27 Nov 2002 06:53:52 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gARDrhq31869; Wed, 27 Nov 2002 15:53:44 +0200 Date: Wed, 27 Nov 2002 15:53:43 +0200 (EET) From: Pekka Savola To: Keith Moore cc: Michel Py , "Charles E. Perkins" , IPng Working Group Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-Reply-To: <200211271333.gARDXkl28909@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 27 Nov 2002, Keith Moore wrote: > > > > Globally unique PI addresses are a step in entirely wrong direction. > > > > I should have said "globally unique PI site-local addresses" but that does > > not probably change your statement. > > > > > I entirely disagree. > > > > Care to elaborate a bit? > > we've been talking about this for weeks. the worst problems with > site-locals are their ambiguity; we need global uniqueness to get > rid of that ambiguity and also to allow them to be reliably routed > between sites. > > however we may just be using the words in slightly different ways - > globally unique vs. probably unique, > site-local (FEC0::/10) vs. some site-specific address space TBD, > etc. I think your "may" may have hit the nail on the head. I'm _only_ _specifically_ thinking of "how do we fix site-locals to make them usable". I do _not_ want this w.g. to try to bang its head against the wood, trying to get workable globally scoped unique PI, possibly routable, addresses to work (in all layers from L1 to L10). Seems like a total waste of energy to me, as most efforts are _not_ in the layers we can really control. You seem to be thinking "how do we provide alternative globally unique, possibly routable, PI addresses so that site-locals would not be needed". Looking at this from your perspective: - I think GUPI, possibly routable, global-scope addresses might be ok, I have lots and lots of reservations about them, but they're not for this working group to try to cope with. - If we just stick to modifying site-locals somehow (and leave the PI global scopes out of the problem statement), I would definitely push for "nearly unique" site-locals Does this seem like a fair characterization? > I currently think > > - we need a new address space for globally-unique PI addresses (GUPIs) > > - some mechanism for ensuring global uniqueness is probably better > than having those addresses be probably unique > > - we need an understanding that GUPIs are not globally routable > unless/until we know how to make that routing scale - but NOT > an architectural limitation against it > > - use of site-locals (FEC0:://10) should be discouraged in general > with a possible exception for isolated/test networks > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 06:17:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAREHkUu025679; Wed, 27 Nov 2002 06:17:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAREHkrO025678; Wed, 27 Nov 2002 06: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAREHfUu025665 for ; Wed, 27 Nov 2002 06:17:41 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAREHpMq016833 for ; Wed, 27 Nov 2002 06:17:51 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05902 for ; Wed, 27 Nov 2002 07:17:45 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAREGMl29206; Wed, 27 Nov 2002 09:16:22 -0500 (EST) Message-Id: <200211271416.gAREGMl29206@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Keith Moore , Michel Py , "Charles E. Perkins" , IPng Working Group Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-reply-to: (Your message of "Wed, 27 Nov 2002 15:53:43 +0200.") Date: Wed, 27 Nov 2002 09:16:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Looking at this from your perspective: > - I think GUPI, possibly routable, global-scope addresses might be ok, I > have lots and lots of reservations about them, but they're not for this > working group to try to cope with. > - If we just stick to modifying site-locals somehow (and leave the PI > global scopes out of the problem statement), I would definitely push for > "nearly unique" site-locals I think this WG needs to define GUPIs - because that seems like the best way to take the pressure off of SLs to be misused. however I don't think we should try to make them globally routable, at least not now. once we do that, I don't know that nearly unique SLs is such a big deal, but I wouldn't object to them. 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 Nov 27 06:44:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAREi8Uu025791; Wed, 27 Nov 2002 06:44:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAREi8En025790; Wed, 27 Nov 2002 06: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAREi5Uu025783 for ; Wed, 27 Nov 2002 06:44:05 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAREiEMq024348 for ; Wed, 27 Nov 2002 06:44:14 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14752 for ; Wed, 27 Nov 2002 07:44:08 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAREi0S32364; Wed, 27 Nov 2002 16:44:01 +0200 Date: Wed, 27 Nov 2002 16:44:00 +0200 (EET) From: Pekka Savola To: Keith Moore cc: Michel Py , "Charles E. Perkins" , IPng Working Group Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-Reply-To: <200211271416.gAREGMl29206@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 27 Nov 2002, Keith Moore wrote: > > Looking at this from your perspective: > > - I think GUPI, possibly routable, global-scope addresses might be ok, I > > have lots and lots of reservations about them, but they're not for this > > working group to try to cope with. > > - If we just stick to modifying site-locals somehow (and leave the PI > > global scopes out of the problem statement), I would definitely push for > > "nearly unique" site-locals > > I think this WG needs to define GUPIs - because that seems like the best > way to take the pressure off of SLs to be misused. however I don't think > we should try to make them globally routable, at least not now. I don't really agree that this is what we should be doing. I think: - if we specify global-scope GUPI's they will also be used when regular global-scope addresses would be better (and we should encourage PA addresses, because they actually _work_); ie. they will cause trouble and may eventually result in prefix/address translation (NAT-like) problems. - if we instead specify site-local, near-unique addresses, folks still treat them as site-locals; they are used less than GUPI's would be, in site-local contexts only. Near-uniqueness removes the problems with ambiguity of site-locals. - I think it's better to deal with reality (provider assigned addresses) than try to escape it (provider independent addresses), even though how enticing it could be... Following my thinking, site-locals could of course be used as an aid for e.g. renumbering or intermittently connected sites, but that should be better than having delusions that using global-scope addresses there would somehow make such addresses "global" or "globally usable". I hope this clarifies my reasoning? > once we do that, I don't know that nearly unique SLs is such a big deal, > but I wouldn't object to them. .. But I agree if we _do_ specify these global-scope GUPI's, adding uniqueness to site-locals seems like a useless effort. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 07:54:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARFs6Uu026009; Wed, 27 Nov 2002 07:54:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARFs6cX026008; Wed, 27 Nov 2002 07:54:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARFs3Uu026001 for ; Wed, 27 Nov 2002 07:54:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARFsCMq006414 for ; Wed, 27 Nov 2002 07:54:12 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26700 for ; Wed, 27 Nov 2002 08:54:07 -0700 (MST) Subject: RE: globally unique site local addresses Date: Wed, 27 Nov 2002 07:54:08 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD46C@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: globally unique site local addresses Thread-Index: AcKV9NaZBIALfD68RSWjwqsO2k1+IwAOEsRQ From: "Michel Py" To: "Brian Carpenter" , "Aidan Williams" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gARFs3Uu026002 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Brian Carpenter wrote: > So I am unconditionally against any scheme that > generates prefixes longer than /48. Agreed. 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 Nov 27 07:57:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARFvmUu026043; Wed, 27 Nov 2002 07:57:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARFvmMJ026042; Wed, 27 Nov 2002 07:57:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARFvjUu026035 for ; Wed, 27 Nov 2002 07:57:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARFvsbB003957 for ; Wed, 27 Nov 2002 07:57:54 -0800 (PST) Received: from atalanta.ctd.anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22229 for ; Wed, 27 Nov 2002 08:57:49 -0700 (MST) 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 JAA02308 for ; Wed, 27 Nov 2002 09:57:46 -0600 (CST) Message-Id: <5.1.1.5.2.20021127093014.0297b200@atalanta.ctd.anl.gov> X-Sender: b30118@atalanta.ctd.anl.gov (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 27 Nov 2002 09:56:34 -0600 To: ipng@sunroof.eng.sun.com From: Richard Carlson Subject: Re: Taking two steps back (Was: Re: one question...) In-Reply-To: <5.1.0.14.0.20021126092449.015d2d60@mail.windriver.com> References: <1038318601.1458.326.camel@dupy> <5.1.0.14.0.20021126073240.02fc0d78@mail.windriver.com> <200211260543.gAQ5h9l14722@astro.cs.utk.edu> <200211260543.gAQ5h9l14722@astro.cs.utk.edu> <5.1.0.14.0.20021126073240.02fc0d78@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 I'm having a lot of trouble understanding what we are trying to accomplish with this email discussion. From my, probably simplistic, view we are missing a fundamental construct of IPv6 addresses. That construct is that v6 address have some kind of scope attached to them. That scope is meant to limit how far they can reach or where they can be used. Am I understanding the v6 address architecture correctly? I think we all agree that there are Link Local (LL) addresses which can only be used for communications between nodes on a single link, i.e., completely non-routable. There are also Global addresses which provide a globally unique IPv6 address to an Internet node. These addresses may be routed anywhere on the global Internet. Note: administrative filtering and address blocking may prevent Internet nodes from establishing an end-to-end connection. In between these 2 extremes (LL and Global) there is a range of other scopes. Margaret pointed out some of these including different divisions in a single organization or manufacture/supplier relationships. The Site Local (SL) address was suppose to enable these types of relationships. The talk of GUPI addresses doesn't seem to capture this limited scope function. Am I missing something? From my perspective the base address document should make this idea of multiple scopes very clear. We certainly have a good handle on what a global address should do, and the LL addresses are also well defined. The trouble is that we never had SL's before and the concept of a 'site' is ambiguous so its hard to figure out what to do with them. Since we don't have any operational experience with these limited scope addresses, we should leave the documentation of them to the future when this experience is gained. 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 Wed Nov 27 08:05:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARG5DUu026139; Wed, 27 Nov 2002 08:05:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARG5D14026138; Wed, 27 Nov 2002 08:05: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARG5AUu026131 for ; Wed, 27 Nov 2002 08:05:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARG5JbB005599 for ; Wed, 27 Nov 2002 08:05:19 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04896 for ; Wed, 27 Nov 2002 09:05:14 -0700 (MST) Subject: RE: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Date: Wed, 27 Nov 2002 08:05:15 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4DD@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Thread-Index: AcKWGfjFhyrtVGlhRvqVXdeQwmwtWAAE9uKQ From: "Michel Py" To: "Keith Moore" , "Pekka Savola" Cc: "Charles E. Perkins" , "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gARG5AUu026132 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, > Keith Moore wrote: > - we need a new address space for globally-unique > PI addresses (GUPIs) I might misread you, but I think that your goal is two-step: 1. Make site-locals unique 2. Make them globally routable (which would indeed suppress site-locals) 1. is a good idea but 2. is not going to work. > - we need an understanding that GUPIs are not > globally routable unless/until we know how to make > that routing scale - but NOT an architectural > limitation against it Do you call recommending a default blackhole in routers an architectural limitation? 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 Nov 27 08:11:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGBQUu026294; Wed, 27 Nov 2002 08:11:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARGBPqV026293; Wed, 27 Nov 2002 08:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGBMUu026286 for ; Wed, 27 Nov 2002 08:11:22 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARGBWbB006924 for ; Wed, 27 Nov 2002 08:11:32 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18773 for ; Wed, 27 Nov 2002 08:11:26 -0800 (PST) Subject: RE: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Date: Wed, 27 Nov 2002 08:11:28 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4DE@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Thread-Index: AcKWHHlelWh/7bQsQJOJuvtBZIm55gAEl0pA From: "Michel Py" To: "Pekka Savola" , "Keith Moore" Cc: "Charles E. Perkins" , "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gARGBMUu026287 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > Pekka Savola wrote: > I'm _only_ _specifically_ thinking of "how do we fix > site-locals to make them usable". I do _not_ want this > w.g. to try to bang its head against the wood, trying to > get workable globally scoped unique PI, possibly > routable, addresses to work (in all layers from L1 to > L10). Seems like a total waste of energy to me, as most > efforts are _not_ in the layers we can really control. I very much agree with this. > You seem to be thinking "how do we provide alternative > globally unique, possibly routable, PI addresses so that > site-locals would not be needed". My reading also. Richard Carlson just brought an interesting point about the scope of these GUSL addresses. I think that it is whatever the scope of site-locals is. 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 Nov 27 08:15:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGFIUu026433; Wed, 27 Nov 2002 08:15:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARGFIiH026432; Wed, 27 Nov 2002 08:15: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGFEUu026425 for ; Wed, 27 Nov 2002 08:15:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARGFNbB007655 for ; Wed, 27 Nov 2002 08:15:23 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11450 for ; Wed, 27 Nov 2002 09:15:18 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARGDvl29570; Wed, 27 Nov 2002 11:13:57 -0500 (EST) Message-Id: <200211271613.gARGDvl29570@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Keith Moore , Michel Py , "Charles E. Perkins" , IPng Working Group Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-reply-to: (Your message of "Wed, 27 Nov 2002 16:44:00 +0200.") Date: Wed, 27 Nov 2002 11:13:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I think this WG needs to define GUPIs - because that seems like the best > > way to take the pressure off of SLs to be misused. however I don't think > > we should try to make them globally routable, at least not now. > > I don't really agree that this is what we should be doing. > > I think: > - if we specify global-scope GUPI's they will also be used when regular > global-scope addresses would be better (and we should encourage PA > addresses, because they actually _work_); ie. they will cause trouble and > may eventually result in prefix/address translation (NAT-like) problems. mumble. all we can do is give people good tools, explain how they were intended to be used, and hope they use them in an optimal fashion. right now we are in a situation where SLs will be used for situations where they are not good tools. the only way to solve this problem is to give people better tools, and GUPIs seem to be a good fit. yes, some people will probably try to use GUPIs where PA globals would be a better choice. eventually, they'll learn. they'll have to renumber to fix that problem, but it won't be more difficult than any other kind of IPv6 renumbering, and we have to solve that problem anyway. > - if we instead specify site-local, near-unique addresses, folks still > treat them as site-locals; they are used less than GUPI's would be, in > site-local contexts only. Near-uniqueness removes the problems with > ambiguity of site-locals. yes, but that's not the only problem with site-locals. another problem is that it's widely believed that they are some kind of security mechanism. another problem is that it's widely believed that hosts and applications should treat them differently than other addresses, either by filtering them or by preferring them over other addresses. in other words, there are lots of dubious assumptions about site-locals that are more easily and more effectively fixed by discouraging many uses of site-locals, and providing an alternative for the valid use cases, than by trying to change people's mindsets about what site-locals means. > - I think it's better to deal with reality (provider assigned addresses) > than try to escape it (provider independent addresses), even though how > enticing it could be... "reality" is subjective. I think it's fair to say that we know how to make PA addresses routable on a large scale, and we don't know how to make PI addresses routable on a large scale. On the other hand, I think it's also fair to say that PA addresses don't do everything that people need - they don't support multi-provider multihoming, and they don't support networks that aren't connected directly to the global internet. So PA addresses are desirable but not sufficient. > Following my thinking, site-locals could of course be used as an aid for > e.g. renumbering or intermittently connected sites, but that should be > better than having delusions that using global-scope addresses there would > somehow make such addresses "global" or "globally usable". I guess we are concerned about different anticipated delusions. I'm much more concerned about the delusions that already seem to exist about the applicability of site-locals than about the delusions that might exist about the applicability of PI globals. I do think that an addressing architecture that simplifies decision-making would minimize the potential for delusions. From that perspective, a simple table is quite attractive: case | recommendation --------------------------------+----------------------- network connected to the | PA global addresses public internet | | network not connected to the | PI global addresses public internet, but | connected to other IP networks | via private arrangements | | isolated stable network | PI global addresses or | site-local addresses | isolated ad hoc network | site-local 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 Nov 27 08:23:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGN7Uu026614; Wed, 27 Nov 2002 08:23:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARGN6GY026613; Wed, 27 Nov 2002 08:23:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGN3Uu026600 for ; Wed, 27 Nov 2002 08:23:03 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARGNCMq013587 for ; Wed, 27 Nov 2002 08:23:13 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26317 for ; Wed, 27 Nov 2002 08:23:07 -0800 (PST) Subject: RE: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Date: Wed, 27 Nov 2002 08:23:08 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E4DF@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Thread-Index: AcKWI46h4EAWmfNbQTiMfV5FfLAESAADIRbw From: "Michel Py" To: "Pekka Savola" , "Keith Moore" Cc: "Charles E. Perkins" , "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gARGN3Uu026602 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Pekka Savola wrote: > - if we specify global-scope GUPI's they will also be used > when regular global-scope addresses would be better > (and we should encourage PA addresses, because they > actually _work_); ie. they will cause trouble and may > eventually result in prefix/address translation > NAT-like) problems. Agreed. > - if we instead specify site-local, near-unique addresses, > folks still treat them as site-locals; they are used less > than GUPI's would be, in site-local contexts only. > Near-uniqueness removes the problems with ambiguity of > site-locals. Agreed. > - I think it's better to deal with reality (provider > assigned addresses) than try to escape it (provider > independent addresses), even though how enticing it > could be... Agreed. That being said, I think you miss the target by thinking that "near unique" will be less enticing than "truly unique". If the risk of collision is very low, people will try to use it as global PI. > Following my thinking, site-locals could of course be used > as an aid for e.g. renumbering or intermittently connected > sites, but that should be better than having delusions that > using global-scope addresses there would somehow make such > addresses "global" or "globally usable". Agreed, but we also need to think about the scope of GUSL used to create a VPN between organizations. 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 Nov 27 08:29:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGTZUu026724; Wed, 27 Nov 2002 08:29:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARGTZdq026723; Wed, 27 Nov 2002 08:29:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGTWUu026716 for ; Wed, 27 Nov 2002 08:29:32 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARGTfMq014883 for ; Wed, 27 Nov 2002 08:29:41 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15860 for ; Wed, 27 Nov 2002 09:29:36 -0700 (MST) Subject: RE: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Date: Wed, 27 Nov 2002 08:29:37 -0800 MIME-Version: 1.0 Message-ID: <2B81403386729140A3A899A8B39B046405E4E0@server2000> Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Thread-Index: AcKWMFZADmXmgbBrTmuvzj1uQOEX7gAAPckA From: "Michel Py" To: "Keith Moore" , "Pekka Savola" Cc: "Charles E. Perkins" , "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gARGTWUu026717 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore wrote: > yes, some people will probably try to use GUPIs where PA > globals would be a better choice. eventually, they'll > learn. they'll have to renumber to fix that problem, but > it won't be more difficult than any other kind of IPv6 > renumbering, and we have to solve that problem anyway. The trouble is that they might elect to use NAT instead of renumbering. I have seen this many times with IPv4. What you propose is taking one problem away (site-locals) and replacing with one even worse (NAT). > I do think that an addressing architecture that > simplifies decision-making would minimize the potential > for delusions. From that perspective, a simple table is > quite attractive: > network not connected to the | PI global addresses > public internet, but | > connected to other IP networks | > via private arrangements | PI global addresses do NOT exist. 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 Nov 27 08:31:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGV9Uu026753; Wed, 27 Nov 2002 08:31:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARGV93e026752; Wed, 27 Nov 2002 08:31: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGV4Uu026742 for ; Wed, 27 Nov 2002 08:31:04 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARGVEMq015358 for ; Wed, 27 Nov 2002 08:31:14 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01836 for ; Wed, 27 Nov 2002 08:31:09 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARGTcl29824; Wed, 27 Nov 2002 11:29:38 -0500 (EST) Message-Id: <200211271629.gARGTcl29824@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "Pekka Savola" , "Charles E. Perkins" , "IPng Working Group" Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-reply-to: (Your message of "Wed, 27 Nov 2002 08:05:15 PST.") <2B81403386729140A3A899A8B39B046405E4DD@server2000> Date: Wed, 27 Nov 2002 11:29:38 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Keith Moore wrote: > > - we need a new address space for globally-unique > > PI addresses (GUPIs) > > I might misread you, but I think that your goal is two-step: > 1. Make site-locals unique > 2. Make them globally routable (which would indeed suppress site-locals) > > 1. is a good idea but 2. is not going to work. no, this isn't what my goals are. I don't want to make FEC0::/10s unique, nor do I want to make them globally routable. I want to discourage use of that prefix, and provide a separate set of addresses which are globally unique and routable off-site by private arrangement. If at some later date we figure out how to make them globally routable, so much the better. > > - we need an understanding that GUPIs are not > > globally routable unless/until we know how to make > > that routing scale - but NOT an architectural > > limitation against it > > Do you call recommending a default blackhole in routers an architectural > limitation? not sure. here's the question - let's say that 3 years from now we figure out how to make routing of GUPIs scale globally. having biased the last three years' worth of routers to filter them, how do we then upgrade the routers to not filter them? In general I'd like to minimize the number of hard-wired assumptions about addresses in both the addressing architecture and the code. I don't think we have enough foresight to know what our needs will be even five years from now. 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 Nov 27 08:35:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGZKUu026848; Wed, 27 Nov 2002 08:35:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARGZJ2Y026847; Wed, 27 Nov 2002 08:35: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGZFUu026840 for ; Wed, 27 Nov 2002 08:35:15 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARGZPMq016440 for ; Wed, 27 Nov 2002 08:35:25 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05015 for ; Wed, 27 Nov 2002 08:35:20 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARGXtl29945; Wed, 27 Nov 2002 11:33:55 -0500 (EST) Message-Id: <200211271633.gARGXtl29945@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "Pekka Savola" , "Charles E. Perkins" , "IPng Working Group" Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-reply-to: (Your message of "Wed, 27 Nov 2002 08:29:37 PST.") <2B81403386729140A3A899A8B39B046405E4E0@server2000> Date: Wed, 27 Nov 2002 11:33:55 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Keith Moore wrote: > > yes, some people will probably try to use GUPIs where PA > > globals would be a better choice. eventually, they'll > > learn. they'll have to renumber to fix that problem, but > > it won't be more difficult than any other kind of IPv6 > > renumbering, and we have to solve that problem anyway. > > The trouble is that they might elect to use NAT instead of renumbering. perhaps. but that potential exists for IPv6 in general. GUPIs don't make that any worse. > I have seen this many times with IPv4. What you propose is taking one > problem away (site-locals) and replacing with one even worse (NAT). no, that's simply not true. > > I do think that an addressing architecture that > > simplifies decision-making would minimize the potential > > for delusions. From that perspective, a simple table is > > quite attractive: > > network not connected to the | PI global addresses > > public internet, but | > > connected to other IP networks | > > via private arrangements | > > PI global addresses do NOT exist. we've been talking about various proposals for creating them since long before Atlanta. where have you been? 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 Nov 27 08:43:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGh6Uu027019; Wed, 27 Nov 2002 08:43:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARGh6ZZ027018; Wed, 27 Nov 2002 08:43: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGh3Uu027011 for ; Wed, 27 Nov 2002 08:43:03 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARGhCbB014274 for ; Wed, 27 Nov 2002 08:43:12 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08701 for ; Wed, 27 Nov 2002 09:43:06 -0700 (MST) Subject: RE: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Date: Wed, 27 Nov 2002 08:43:08 -0800 MIME-Version: 1.0 Message-ID: <2B81403386729140A3A899A8B39B046405E4E1@server2000> Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Thread-Index: AcKWMlQonxj6zG0LRvKR6r2pbFh0HQAAFpXg From: "Michel Py" To: "Keith Moore" Cc: "Pekka Savola" , "Charles E. Perkins" , "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gARGh3Uu027012 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith Moore wrote: > no, this isn't what my goals are. I don't want to make > FEC0::/10s unique, nor do I want to make them globally > routable. I want to discourage use of that prefix, and > provide a separate set of addresses which are globally > unique and routable off-site by private arrangement. > If at some later date we figure out how to make them > globally routable, so much the better. So what is the difference between this new GUPI block and GUSLs, except that you want a possible evolution to globally routable for the new GUPI block? >> Do you call recommending a default blackhole in >> routers an architectural limitation? > not sure. here's the question - let's say that 3 years > from now we figure out how to make routing of GUPIs scale > globally. having biased the last three years' worth of > routers to filter them, how do we then upgrade the routers > to not filter them? The obvious answer is that we create a new block _then_, not now. >> PI global addresses do NOT exist. > we've been talking about various proposals for creating > them since long before Atlanta. where have you been? Ahem, I am leading this part. 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 Nov 27 08:53:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGr1Uu027165; Wed, 27 Nov 2002 08:53:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARGr1kt027164; Wed, 27 Nov 2002 08:53: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGqvUu027152 for ; Wed, 27 Nov 2002 08:52:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARGr7Mq020282 for ; Wed, 27 Nov 2002 08:53:07 -0800 (PST) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22070 for ; Wed, 27 Nov 2002 09:52:59 -0700 (MST) 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 gARGqmAL043694; Wed, 27 Nov 2002 17:52:48 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gARGqm1U097512; Wed, 27 Nov 2002 17:52:48 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA71212 from ; Wed, 27 Nov 2002 17:52:46 +0100 Message-Id: <3DE4F848.9ABD2407@hursley.ibm.com> Date: Wed, 27 Nov 2002 17:52:24 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michael Thomas Cc: ipng@sunroof.eng.sun.com Subject: Re: even one reason why provably unique SL is needed? References: <20021125193303.6D08C7B6B@berkshire.research.att.com> <15843.48935.931286.854991@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > > Steven M. Bellovin writes: > > Don't forget mergers and private interconnects. The latter are *very* > > common, even without counting telecommuters. One shouldn't use > > site-local there, but it's a path that often bypasses firewalls and > > other official demarcation points. > > > > If interconnections never occur, we don't need to worry about the > > problems that can happen. My fear is that they occur all too often. > > (What percentage of queries to the root name servers come from 1918 > > addresses?) > > Am I the only one that finds the term "private > interconnect" somewhat specious? As in, if people > make larger x-realm internets by plumbing their > own wires instead of through an ISP, why should > that be thought of differently than the Internet? > Maybe that's why this entire concept is so > unsettling to me. The question is, at what scale does route aggregation begin to matter? The sort of VPN-based or merger-and- acquisition based networks we are talking about don't seem to be anywhere near that scale; we know that flat routing of thousands of prefixes is possible. So it may be philosophically unsettling, but I don't think it is operationally unsettling. 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 Nov 27 08:55:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGtjUu027218; Wed, 27 Nov 2002 08:55:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARGtjBB027217; Wed, 27 Nov 2002 08:55:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARGtfUu027210 for ; Wed, 27 Nov 2002 08:55:41 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARGtpMq020893 for ; Wed, 27 Nov 2002 08:55:51 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18651 for ; Wed, 27 Nov 2002 08:55:45 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARGsPl00927; Wed, 27 Nov 2002 11:54:25 -0500 (EST) Message-Id: <200211271654.gARGsPl00927@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "Pekka Savola" , "Charles E. Perkins" , "IPng Working Group" Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-reply-to: (Your message of "Wed, 27 Nov 2002 08:43:08 PST.") <2B81403386729140A3A899A8B39B046405E4E1@server2000> Date: Wed, 27 Nov 2002 11:54:25 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Keith Moore wrote: > > no, this isn't what my goals are. I don't want to make > > FEC0::/10s unique, nor do I want to make them globally > > routable. I want to discourage use of that prefix, and > > provide a separate set of addresses which are globally > > unique and routable off-site by private arrangement. > > If at some later date we figure out how to make them > > globally routable, so much the better. > > So what is the difference between this new GUPI block and GUSLs, except > that you want a possible evolution to globally routable for the new GUPI > block? problems with GUSLs as an alternative to GUPIs: - the proposed uses of PI globals change too many assumptions about how SLs were to be used to reuse the FEC0::/10 prefix for that purpose. - there were too many conflicting or intractable assumptions about SLs anyway - we need PI globals that can be routed between sites by private agreement anyway. > >> Do you call recommending a default blackhole in > >> routers an architectural limitation? > > > not sure. here's the question - let's say that 3 years > > from now we figure out how to make routing of GUPIs scale > > globally. having biased the last three years' worth of > > routers to filter them, how do we then upgrade the routers > > to not filter them? > > The obvious answer is that we create a new block _then_, not now. no, because we need the block now to solve the problems with SLs. 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 Nov 27 09:02:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARH26Uu027398; Wed, 27 Nov 2002 09:02:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARH268E027395; Wed, 27 Nov 2002 09:02:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARH21Uu027380 for ; Wed, 27 Nov 2002 09:02:01 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARH2BMq022665 for ; Wed, 27 Nov 2002 09:02:11 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22288 for ; Wed, 27 Nov 2002 10:02:05 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gARH2Nve009377; Wed, 27 Nov 2002 18:02:23 +0100 (CET) Date: Wed, 27 Nov 2002 13:43:29 +0100 Subject: Re: "unique enough" [RE: globally unique site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "Michel Py" , "Pekka Savola" , "Christian Huitema" , To: Margaret Wasserman From: Kurt Erik Lindqvist In-Reply-To: <5.1.0.14.0.20021123204700.02221ab8@mail.windriver.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Uhm, if they are truely unique, the only difference to global >> addresses is that they won't be routed - right? Now, what is the >> difference between that and using global unicast address space that >> you do not announce? > > Virtually nothing, except that this address space would be > provider-independent, so you would not have to renumber, etc. > when you change ISPs. Also, your ISP would not be obligated > to route it globally and would probably filter it. > > I'm actually in favor of a globally-unique/provider-independent > address space that is routable, with borders of the address > space administratively determined and enforced via filtering > rules in routers/firewalls. > But if there is no difference we are suggesting to create PI space right? And leave the scaling problem of the routing table to multi6 group where it belongs? What I am failing to understand is what we are looking for. The GUPI model will drive the development of NATs. Actually this would build NATs into the Internet architecture permanently. A number or people have pointed to the problems of this. That besides, if we now (I hope not) creates GUPI space, why do I then need site-locals as well? Why do we need a separate allocation for GUPI? This could be all of the unicast addresses in IPv6. Isn't this more or less 8+8? - 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 Nov 27 09:02:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARH2BUu027414; Wed, 27 Nov 2002 09:02:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARH2Bbg027413; Wed, 27 Nov 2002 09: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARH23Uu027387 for ; Wed, 27 Nov 2002 09:02:03 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARH2CbB019469 for ; Wed, 27 Nov 2002 09:02:12 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23485 for ; Wed, 27 Nov 2002 09:02:06 -0800 (PST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gARH2Jve009374; Wed, 27 Nov 2002 18:02:19 +0100 (CET) Date: Wed, 27 Nov 2002 13:35:24 +0100 Subject: Re: Enforcing unreachability of site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "Michel Py" , "Christian Huitema" , To: Margaret Wasserman From: Kurt Erik Lindqvist In-Reply-To: <5.1.0.14.0.20021123194321.00b34e50@mail.windriver.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think that we should stop calling these addresses "site-local", > as that is prone to confusion. We would create a separate set > of globally-unique/provider-independent (GUPI? Pronounced > "guppy" or "goopy", depending on how much you like them? :-)) > addresses for use as local addresses in Internet connected sites. > > We could still have site-local addresses (FECO::/10), which can be > used for disconnected networks (and perhaps other cases -- we > haven't really decided how widely to use them yet). If we limit > them to disconnected sites, they could be treated exactly like > global addresses by all nodes. If we also allow them to be Ok, I am behind on email.... ....but how on earth did we end up in this discussion? From what I remember of the voting in Atlanta we had consensus for a limited version of site-locals...not creating a separate address structure? I mean if we are concerned about an allocation for GUPI we could use ::/0 right? It's not going to leak to the Internet anyway.... - 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 Nov 27 09:02:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARH2GUu027420; Wed, 27 Nov 2002 09:02:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARH2GTU027419; Wed, 27 Nov 2002 09:02: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARH27Uu027400 for ; Wed, 27 Nov 2002 09:02:07 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARH2HMq022728 for ; Wed, 27 Nov 2002 09:02:17 -0800 (PST) Received: from laptop2.kurtis.pp.se (dhcp1.kurtis.pp.se [195.43.225.70] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15120 for ; Wed, 27 Nov 2002 10:02:11 -0700 (MST) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gARH2Ove009380; Wed, 27 Nov 2002 18:02:24 +0100 (CET) Date: Wed, 27 Nov 2002 13:49:47 +0100 Subject: Re: globally unique site local addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Michel Py , Margaret Wasserman , ipng@sunroof.eng.sun.com To: Mark Smith From: Kurt Erik Lindqvist In-Reply-To: <1038107794.1458.105.camel@dupy> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Maybe leaked routes in the Internet eg 10/8 aren't so much that common, > it's just that they are very prominent when they occur, because you > know > that you shouldn't be seeing them. > I thought that they where leaked more or less every week...at least that is my experience. - 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 Nov 27 09:18:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHINUu027835; Wed, 27 Nov 2002 09:18:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARHINEc027834; Wed, 27 Nov 2002 09:18: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHIJUu027827 for ; Wed, 27 Nov 2002 09:18:19 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARHITMq026845 for ; Wed, 27 Nov 2002 09:18:29 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10879 for ; Wed, 27 Nov 2002 09:18:23 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARHIMl01137; Wed, 27 Nov 2002 12:18:22 -0500 (EST) Message-Id: <200211271718.gARHIMl01137@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Richard Carlson cc: ipng@sunroof.eng.sun.com Subject: Re: Taking two steps back (Was: Re: one question...) In-reply-to: (Your message of "Wed, 27 Nov 2002 09:56:34 CST.") <5.1.1.5.2.20021127093014.0297b200@atalanta.ctd.anl.gov> Date: Wed, 27 Nov 2002 12:18:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm having a lot of trouble understanding what we are trying to accomplish > with this email discussion. From my, probably simplistic, view we are > missing a fundamental construct of IPv6 addresses. That construct is that > v6 address have some kind of scope attached to them. That scope is meant > to limit how far they can reach or where they can be used. Am I > understanding the v6 address architecture correctly? Perhaps. But what we're finding is that while scopes might be necessary for corner cases (e.g. LL is certainly useful for configuration purposes), it's a bad idea to expect everything (hosts, apps, routing) to have to deal with them. And there's also a limit to which it's a good idea to wire notions of scope into the addressing architecture, and reserve even more address blocks for scopes that have dubious utility for the future. Just as wiring in notions of "class" into IPv4 turned out to be a limitation, wiring in more notions of "scope" into IPv6 might also turn out to be a limitation. > In between these 2 extremes (LL and Global) there is a range of other > scopes. Margaret pointed out some of these including different divisions > in a single organization or manufacture/supplier relationships. The Site > Local (SL) address was suppose to enable these types of relationships. That's not my understanding of the intent of SLs, and at any rate SLs as currently specified don't work well for this case - there are too many constraints and assumptions attached to them. > The talk of GUPI addresses doesn't seem to capture this limited scope > function. Am I missing something? Limited scope is a bad idea for anything that's going to be used outside of an isolated environment. > We certainly have a good handle on what a global address should do, and the > LL addresses are also well defined. The trouble is that we never had SL's > before and the concept of a 'site' is ambiguous so its hard to figure out > what to do with them. It's worse than that. a- there are *conflicting* assumptions about what to do with them. b- SLs are a major pain for applications that have to span scope bounaries. But let's not rehash that discussion again. It's in the list archives. 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 Nov 27 09:26:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHQ1Uu027931; Wed, 27 Nov 2002 09:26:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARHQ13Q027930; Wed, 27 Nov 2002 09:26: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHPvUu027923 for ; Wed, 27 Nov 2002 09:25:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARHQ6bB026770 for ; Wed, 27 Nov 2002 09:26:06 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13574 for ; Wed, 27 Nov 2002 10:25:58 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARHPXl01280; Wed, 27 Nov 2002 12:25:34 -0500 (EST) Message-Id: <200211271725.gARHPXl01280@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Kurt Erik Lindqvist cc: Margaret Wasserman , "Michel Py" , "Christian Huitema" , ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses In-reply-to: (Your message of "Wed, 27 Nov 2002 13:35:24 +0100.") Date: Wed, 27 Nov 2002 12:25:33 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ....but how on earth did we end up in this discussion? From what I > remember of the voting in Atlanta we had consensus for a limited > version of site-locals...not creating a separate address structure? as I recall, we had consensus for limiting site-locals, as well as widespread support for the idea that PI globals were needed. it's not an either-or. 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 Nov 27 09:29:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHTGUu027969; Wed, 27 Nov 2002 09:29:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARHTG8g027968; Wed, 27 Nov 2002 09:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHTCUu027961 for ; Wed, 27 Nov 2002 09:29:12 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARHTLMq029656 for ; Wed, 27 Nov 2002 09:29:22 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04287 for ; Wed, 27 Nov 2002 10:29:16 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARHRql01307; Wed, 27 Nov 2002 12:27:52 -0500 (EST) Message-Id: <200211271727.gARHRql01307@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Kurt Erik Lindqvist cc: Margaret Wasserman , "Michel Py" , "Pekka Savola" , "Christian Huitema" , ipng@sunroof.eng.sun.com Subject: Re: "unique enough" [RE: globally unique site local addresses] In-reply-to: (Your message of "Wed, 27 Nov 2002 13:43:29 +0100.") Date: Wed, 27 Nov 2002 12:27:52 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The GUPI model will drive the development of NATs. that's just nuts. GUPIs don't encourage NATs any more than any other aspect of IPv6. I'm beginning to think that citing NATs as a reason for not doing something in IPv6 is like comparing someone to Hitler in a political discussion - it's such an extreme statement that it can't be evaluated. 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 Nov 27 09:38:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHcxUu028128; Wed, 27 Nov 2002 09:38:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARHcxsP028127; Wed, 27 Nov 2002 09:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHctUu028120 for ; Wed, 27 Nov 2002 09:38:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARHd5bB000571 for ; Wed, 27 Nov 2002 09:39:05 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18385 for ; Wed, 27 Nov 2002 10:38:59 -0700 (MST) Subject: RE: Enforcing unreachability of site local addresses Date: Wed, 27 Nov 2002 09:39:01 -0800 MIME-Version: 1.0 Message-ID: <2B81403386729140A3A899A8B39B04640BD473@server2000> Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: Enforcing unreachability of site local addresses Thread-Index: AcKWNsvjFLAObycGQVabbcKsc4eijgABORoA From: "Michel Py" To: "Kurt Erik Lindqvist" , "Margaret Wasserman" Cc: "Christian Huitema" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gARHcuUu028121 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Kurt Erik Lindqvist wrote: > ....but how on earth did we end up in this discussion? > From what I remember of the voting in Atlanta we had > consensus for a limited version of site-locals...not > creating a separate address structure? Thank you. 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 Nov 27 09:51:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHpkUu028305; Wed, 27 Nov 2002 09:51:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARHpkKm028304; Wed, 27 Nov 2002 09:51: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHphUu028297 for ; Wed, 27 Nov 2002 09:51:43 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARHprbB004354 for ; Wed, 27 Nov 2002 09:51:53 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26407 for ; Wed, 27 Nov 2002 09:51:47 -0800 (PST) Subject: RE: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Date: Wed, 27 Nov 2002 09:51:48 -0800 MIME-Version: 1.0 Message-ID: <2B81403386729140A3A899A8B39B046405E4E3@server2000> Content-Type: text/plain; charset="US-ASCII" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Thread-Index: AcKWNbRP/S2uMxFkQueAOkOIT+34RAABsJTQ From: "Michel Py" To: "Keith Moore" Cc: "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gARHphUu028298 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, >> Michel Py wrote: >> So what is the difference between this new GUPI block >> and GUSLs, except that you want a possible evolution >> to globally routable for the new GUPI block? > Keith Moore wrote: > problems with GUSLs as an alternative to GUPIs: > - the proposed uses of PI globals change too many > assumptions about how SLs were to be used to reuse > the FEC0::/10 prefix for that purpose. GUSL does not create PI globals. As its name implies, it creates globally unique site-locals, which would avoid NAT and/or renumbering when two sites connect. The scope would not be global, although it would go behind the site's boundaries. > - there were too many conflicting or intractable > assumptions about SLs anyway Assumptions in current drafts? > - we need PI globals that can be routed between sites > by private agreement anyway. We need _something_ that can be routed between sites by private agreement only. This does not need to be global. >> The obvious answer is that we create a new block _then_, not now. > no, because we need the block now to solve the problems with SLs. You are missing the point. If network administrators do not like restricted SLs, they will use 2002:0A00::/24 instead, a one-way ticket to NAT. Everybody would be better off having them use site-locals and try to limit the damage. 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 Nov 27 09:54:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHsPUu028362; Wed, 27 Nov 2002 09:54:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARHsPAc028361; Wed, 27 Nov 2002 09:54: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHsLUu028351 for ; Wed, 27 Nov 2002 09:54:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARHsVbB005094 for ; Wed, 27 Nov 2002 09:54:31 -0800 (PST) Received: from cerberus.aebeard.com ([209.208.32.222]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00603 for ; Wed, 27 Nov 2002 10:54:25 -0700 (MST) Received: from amneris.aebeard.net (root@amneris.aebeard.net [192.168.232.3]) by cerberus.aebeard.com (8.11.6/8.10.1) with ESMTP id gARHsPZ25795; Wed, 27 Nov 2002 12:54:25 -0500 (EST) Received: from localhost (aeb1@localhost) by amneris.aebeard.net (8.11.6/8.10.1) with ESMTP id gARHsOJ11833; Wed, 27 Nov 2002 12:54:24 -0500 (EST) Date: Wed, 27 Nov 2002 12:54:24 -0500 (EST) From: "Alan E. Beard" To: Keith Moore cc: Kurt Erik Lindqvist , Margaret Wasserman , Michel Py , Christian Huitema , ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses In-Reply-To: <200211271725.gARHPXl01280@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 27 Nov 2002, Keith Moore wrote: > > > ....but how on earth did we end up in this discussion? From what I > > remember of the voting in Atlanta we had consensus for a limited > > version of site-locals...not creating a separate address structure? > > as I recall, we had consensus for limiting site-locals, > as well as widespread support for the idea that PI globals were needed. > > it's not an either-or. > > Keith My memory of the discussions accords with the summary given by Keith above. In addition, the general tenor of the discussion indicated to me that the two issues were linked: that consensus on limiting site-locals was contingent upon initiation of an effort to design a workable scheme for privately-routable PIs, with the global routing of PIs left for subsequent discussion. AEB -- Alan E. Beard AEBeard Consulting 4109 Chelsea Ln Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 09:58:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHwJUu028430; Wed, 27 Nov 2002 09:58:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARHwJLA028429; Wed, 27 Nov 2002 09:58: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARHwFUu028422 for ; Wed, 27 Nov 2002 09:58:15 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARHwObB006039 for ; Wed, 27 Nov 2002 09:58:24 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00548 for ; Wed, 27 Nov 2002 09:58:19 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARHw8j00650; Wed, 27 Nov 2002 12:58:08 -0500 (EST) Message-Id: <200211271758.gARHw8j00650@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "IPng Working Group" Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-reply-to: (Your message of "Wed, 27 Nov 2002 09:51:48 PST.") <2B81403386729140A3A899A8B39B046405E4E3@server2000> Date: Wed, 27 Nov 2002 12:58:08 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> Michel Py wrote: > >> So what is the difference between this new GUPI block > >> and GUSLs, except that you want a possible evolution > >> to globally routable for the new GUPI block? > > > Keith Moore wrote: > > problems with GUSLs as an alternative to GUPIs: > > - the proposed uses of PI globals change too many > > assumptions about how SLs were to be used to reuse > > the FEC0::/10 prefix for that purpose. > > GUSL does not create PI globals. As its name implies, it creates > globally unique site-locals, which would avoid NAT and/or renumbering > when two sites connect. I don't think we should use FEC0::/10 for these. Those were intended as site-local addresses, and people have ideas that these have security properties, that applications should favor them, etc. Making SLs globally unique and routing them between sites amounts to an architectural change - but more importantly it conflicts with assumptions that are already built into some applications and into people's minds. > > - there were too many conflicting or intractable > > assumptions about SLs anyway > > Assumptions in current drafts? yes. > > - we need PI globals that can be routed between sites > > by private agreement anyway. > > We need _something_ that can be routed between sites by private > agreement only. This does not need to be global. I'm convinced it's easier to make things work (especially DNS PTR lookups) if they are globally unique than if they are only probably unique. > >> The obvious answer is that we create a new block _then_, not now. > > no, because we need the block now to solve the problems with SLs. > > You are missing the point. If network administrators do not like > restricted SLs, they will use 2002:0A00::/24 instead, a one-way ticket > to NAT. humbug. this is too fanciful to have any credibility. why should network adminis pick an obscure prefix when we are making much better and more obvious solutions available? 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 Nov 27 10:45:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARIj6Uu028852; Wed, 27 Nov 2002 10:45:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARIj6i9028851; Wed, 27 Nov 2002 10:45: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARIj3Uu028844 for ; Wed, 27 Nov 2002 10:45:03 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARIjCbB018897 for ; Wed, 27 Nov 2002 10:45:12 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24409 for ; Wed, 27 Nov 2002 11:45:07 -0700 (MST) Subject: RE: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Date: Wed, 27 Nov 2002 10:45:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4E4@server2000> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Thread-Index: AcKWPquJ2s1vlDEVSQG4W1wo933CeQAAJ0HQ From: "Michel Py" To: "Keith Moore" Cc: "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gARIj3Uu028845 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, >> Michel Py wrote: >> GUSL does not create PI globals. As its name implies, >> it creates globally unique site-locals, which would >> avoid NAT and/or renumbering when two sites connect. > Keith Moore wrote: > I don't think we should use FEC0::/10 for these. Those > were intended as site-local addresses, and people have > ideas that these have security properties, that > applications should favor them, etc. Making SLs globally > unique and routing them between sites amounts to an > architectural change - but more importantly it conflicts > with assumptions that are already built into some > applications and into people's minds. Okay, you convinced me. GUSL is good for mergers, but if it is used for inter-site communications it's an architectural change. >> You are missing the point. If network administrators >> do not like restricted SLs, they will use 2002:0A00::/24 >> instead, a one-way ticket to NAT. > humbug. this is too fanciful to have any credibility. > why should network adminis pick an obscure prefix when > we are making much better and more obvious solutions > available? Because they want addresses that are not publicly routable, and nothing you can say will change this. Here's the dilemma: if the scope of GUPI is global, how could you guarantee that people won't pay their ISPs to leak the GUPI address in the defaultless routing table? The big difference is that with GUSL we would have extended the scope to friendly sites, not to global. The risk of GUSL ending up global PI could be managed. With GUPI, you are asking for a blank check. If GUPI addresses leak unaggregated in the global routing table, we have recreated the IPv4 swamp and possibly killed IPv6. How do you plan to manage this risk? Risk / benefit analysis: Solving problems with site-locals only is not a big enough carrot to take the risk of recreating the swamp. Make the carrot bigger. 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 Nov 27 12:12:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARKCPUu029537; Wed, 27 Nov 2002 12:12:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARKCPN5029536; Wed, 27 Nov 2002 12:12: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARKCLUu029529 for ; Wed, 27 Nov 2002 12:12:21 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARKCUMq014451 for ; Wed, 27 Nov 2002 12:12:30 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25625 for ; Wed, 27 Nov 2002 12:12:25 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARKCKj01063; Wed, 27 Nov 2002 15:12:20 -0500 (EST) Message-Id: <200211272012.gARKCKj01063@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "IPng Working Group" Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-reply-to: (Your message of "Wed, 27 Nov 2002 10:45:06 PST.") <2B81403386729140A3A899A8B39B046405E4E4@server2000> Date: Wed, 27 Nov 2002 15:12:20 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> You are missing the point. If network administrators > >> do not like restricted SLs, they will use 2002:0A00::/24 > >> instead, a one-way ticket to NAT. > > > humbug. this is too fanciful to have any credibility. > > why should network adminis pick an obscure prefix when > > we are making much better and more obvious solutions > > available? > > Because they want addresses that are not publicly routable, and nothing > you can say will change this. Well, maybe we'll end up making GUPIs not publically routable. I guess I'd like to hear more about this rationale from others, though - it makes less sense to trust unrelated parties to filter your traffic than it does to trust your own border filters (or your ISPs, or both). > Here's the dilemma: if the scope of GUPI is global, how could you > guarantee that people won't pay their ISPs to leak the GUPI address in > the defaultless routing table? If people don't want their addresses to be publically routable, why would they pay their ISPs to route them? > The big difference is that with GUSL we would have extended the scope to > friendly sites, not to global. The risk of GUSL ending up global PI > could be managed. I don't see how this is changed by a decision to not use FEC0::/10 for globally unique addresses. > With GUPI, you are asking for a blank check. If GUPI addresses leak > unaggregated in the global routing table, we have recreated the IPv4 > swamp and possibly killed IPv6. How do you plan to manage this risk? It's a complex question, and I don't want to gloss over it. However, a lot of the perceived risk seems to have to do with the idea that ISPs will let their routing performance degrade rather than raise their prices. So maybe if we could get widespread agreement on minimum acceptable routing performance (e.g. convergence times) then the market would take care of the rest by making it so expensive to advertise a PI prefix globally that few would do it. But there still seems to be an inherent conflict between those who are demanding non-routable addresses (is anyone else demanding this?) and those who want GUPIs to be routable. If there's really sufficient demand for both maybe we need separate blocks. 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 Nov 27 12:28:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARKSCUu029685; Wed, 27 Nov 2002 12:28:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARKSCsG029684; Wed, 27 Nov 2002 12:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARKS9Uu029677 for ; Wed, 27 Nov 2002 12:28:09 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARKSFbB017898 for ; Wed, 27 Nov 2002 12:28:19 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03327 for ; Wed, 27 Nov 2002 12:28:09 -0800 (PST) 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 MAA21381 for ; Wed, 27 Nov 2002 12:28:09 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gARKS8E01322; Wed, 27 Nov 2002 12:28:08 -0800 X-mProtect: <200211272028> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.99, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdki6CiC; Wed, 27 Nov 2002 12:28:06 PST Message-Id: <4.3.2.7.2.20021127122706.0271adf0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Nov 2002 12:27:30 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: test, please ignore Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk test, please ignore -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 13:57:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARLvdUu000322; Wed, 27 Nov 2002 13:57:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARLvcnc000321; Wed, 27 Nov 2002 13:57:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARLvZUu000314 for ; Wed, 27 Nov 2002 13:57:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARLvjMq012152 for ; Wed, 27 Nov 2002 13:57:45 -0800 (PST) Received: from mail.nosense.org (44.cust4.nsw.dsl.ozemail.com.au [203.103.159.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11408 for ; Wed, 27 Nov 2002 14:57:37 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 3D9AA3B39C; Thu, 28 Nov 2002 08:57:34 +1100 (EST) Subject: Re: globally unique site local addresses From: Mark Smith To: Kurt Erik Lindqvist Cc: Michel Py , Margaret Wasserman , ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 28 Nov 2002 08:57:34 +1100 Message-Id: <1038434255.1458.503.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2002-11-27 at 23:49, Kurt Erik Lindqvist wrote: > > Maybe leaked routes in the Internet eg 10/8 aren't so much that common, > > it's just that they are very prominent when they occur, because you > > know > > that you shouldn't be seeing them. > > > > I thought that they where leaked more or less every week...at least > that is my experience. > My experience is possibly somewhat limited, I made the statement based on : 1) the default ACLs and route filters for the rather large ISP I used to work for. Unfortunately I don't get a chance to work in the core of that network, so I'm making a judgement on what was supposed to be the practice rather than reality. 2) I logged into router-server.cerf.net, couldn't find any network 10/8 in the bgp and route tables, looked at their incoming BGP route filters, they weren't filtering for it, so their upstream ASs looked to be filtering it. I was mostly wondering if people were over estimating the occurance of RFC1918 route leaks, purely because "they stick out like a saw thumb". With the RFC1918 leaks you see, do they disappear pretty quickly after they appear, indicating somebody took action to stop the leak ? It would also be interesting to see if the origin AS of these RFC1918 leaks is one of the private ones. ps, we can take this off-ML if people don't think it is relevant to IPv6. 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 14:09:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARM92Uu000527; Wed, 27 Nov 2002 14:09:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARM92h7000526; Wed, 27 Nov 2002 14:09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARM8xUu000519 for ; Wed, 27 Nov 2002 14:08:59 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARM98bB011407 for ; Wed, 27 Nov 2002 14:09:08 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19023 for ; Wed, 27 Nov 2002 14:09:02 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gARM8ib04446; Thu, 28 Nov 2002 00:08:44 +0200 Date: Thu, 28 Nov 2002 00:08:44 +0200 (EET) From: Pekka Savola To: Mark Smith cc: Kurt Erik Lindqvist , Michel Py , Margaret Wasserman , Subject: Re: globally unique site local addresses In-Reply-To: <1038434255.1458.503.camel@dupy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 28 Nov 2002, Mark Smith wrote: > On Wed, 2002-11-27 at 23:49, Kurt Erik Lindqvist wrote: > > > Maybe leaked routes in the Internet eg 10/8 aren't so much that common, > > > it's just that they are very prominent when they occur, because you > > > know > > > that you shouldn't be seeing them. > > > > > > > I thought that they where leaked more or less every week...at least > > that is my experience. > > > > My experience is possibly somewhat limited, I made the statement based > on : > > 1) the default ACLs and route filters for the rather large ISP I used to > work for. Unfortunately I don't get a chance to work in the core of that > network, so I'm making a judgement on what was supposed to be the > practice rather than reality. > > 2) I logged into router-server.cerf.net, couldn't find any network 10/8 > in the bgp and route tables, looked at their incoming BGP route filters, > they weren't filtering for it, so their upstream ASs looked to be > filtering it. > > I was mostly wondering if people were over estimating the occurance of > RFC1918 route leaks, purely because "they stick out like a saw thumb". > > With the RFC1918 leaks you see, do they disappear pretty quickly after > they appear, indicating somebody took action to stop the leak ? It would > also be interesting to see if the origin AS of these RFC1918 leaks is > one of the private ones. > > ps, we can take this off-ML if people don't think it is relevant to > IPv6. I think what was meant was that 10/8 addresses leak as _source_ addresses, which is about equally bad. We have filters on our border, and the counter keeps ticking quite a bit.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 14:14:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARMEaUu000609; Wed, 27 Nov 2002 14:14:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARMEa1T000608; Wed, 27 Nov 2002 14:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARMEXUu000601 for ; Wed, 27 Nov 2002 14:14:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARMEgbB012764 for ; Wed, 27 Nov 2002 14:14:42 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23744 for ; Wed, 27 Nov 2002 15:14:36 -0700 (MST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id WAA13448; Wed, 27 Nov 2002 22:14:33 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Keith Moore Cc: Kurt Erik Lindqvist , Margaret Wasserman , "Michel Py" , "Christian Huitema" , ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses References: <200211271725.gARHPXl01280@astro.cs.utk.edu> From: Ole Troan Date: Wed, 27 Nov 2002 22:14:28 +0000 In-Reply-To: <200211271725.gARHPXl01280@astro.cs.utk.edu> (Keith Moore's message of "Wed, 27 Nov 2002 12:25:33 -0500") Message-ID: <7t57keyvewr.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> ....but how on earth did we end up in this discussion? From what I >> remember of the voting in Atlanta we had consensus for a limited >> version of site-locals...not creating a separate address structure? > > as I recall, we had consensus for limiting site-locals, > as well as widespread support for the idea that PI globals were needed. > > it's not an either-or. if my memory serves me right we had consensus on limiting site-locals somewhat, i.e not pushing multi-site support. we also had consensus that _working_ on non-routable global PI addresses sounded like an interesting idea. until we see some real proposals on the table, there is nothing to reach consensus about with regards to GUPIs. /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 Wed Nov 27 14:23:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARMNDUu000730; Wed, 27 Nov 2002 14:23:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARMNDuD000729; Wed, 27 Nov 2002 14:23:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARMN9Uu000722 for ; Wed, 27 Nov 2002 14:23:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARMNJMq018863 for ; Wed, 27 Nov 2002 14:23:19 -0800 (PST) Received: from mail.nosense.org (44.cust4.nsw.dsl.ozemail.com.au [203.103.159.44]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20918 for ; Wed, 27 Nov 2002 15:23:13 -0700 (MST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id D855D3B39C; Thu, 28 Nov 2002 09:23:07 +1100 (EST) Subject: Re: globally unique site local addresses From: Mark Smith To: Pekka Savola Cc: Kurt Erik Lindqvist , Michel Py , Margaret Wasserman , ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 28 Nov 2002 09:23:07 +1100 Message-Id: <1038435788.3603.510.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2002-11-28 at 09:08, Pekka Savola wrote: > On 28 Nov 2002, Mark Smith wrote: > > I think what was meant was that 10/8 addresses leak as _source_ addresses, > which is about equally bad. Fair enough - I'd overlook that one, mostly because I don't see many bogus source addresses bounce off my firewall, and I figured that source address filtering (as per the BCP) as a preventative measure against syn attacks was pretty common. > > We have filters on our border, and the counter keeps ticking quite a bit.. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 14:42:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARMg0Uu000921; Wed, 27 Nov 2002 14:42:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARMfxKR000920; Wed, 27 Nov 2002 14:41:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARMfuUu000913 for ; Wed, 27 Nov 2002 14:41:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARMg6bB019710 for ; Wed, 27 Nov 2002 14:42:06 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09532 for ; Wed, 27 Nov 2002 15:42:00 -0700 (MST) 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 OAA26695; Wed, 27 Nov 2002 14:41:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gARMfux13690; Wed, 27 Nov 2002 14:41:56 -0800 X-mProtect: <200211272241> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (216.83.56.167, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvLP6Wi; Wed, 27 Nov 2002 14:41:54 PST Message-Id: <4.3.2.7.2.20021127144033.02b1caa8@mailhost.iprg.nokia.com> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Nov 2002 14:41:17 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden & Margaret Wasserman Subject: ATTENTION: Use of the ipng mailing list Cc: Margaret Wasserman , hinden@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 All, We appreciate the enthusiasm that several of you have shown regarding the previous site-local discussion and the current discussion of globally-unique, provider-independent addresses. However, these discussions are not an effective way to use our mailing list. There is a limit to the amount of mail that most people can reasonably handle, and it is likely that most members of the IPv6 working group have been unable to follow these discussions or get much value from them. No useful consensus can be drawn from such discussions. In order to increase the quality and productivity of our mailing list discussions, we would ask people to do the following: - Self-limit the rate of your postings to the list. Please read to the bottom of the thread before responding, think about the points you want to make, and avoid making the same points repeatedly. - Please submit individual Internet-Drafts that describe proposed solutions and/or make cases for or against the topic at hand. This is a much more effective than e-mail as a way to discuss complex topics and reach consensus. - Notice when circular discussions are happening between a small group of people and stop. Rough consensus is not determined or affected by who has the last word on a topic, and no WG consensus can be drawn from a discussion among a small group of people. These steps should help to make our mailing list more useful and productive for the entire WG, and your voluntary cooperation is appreciated. If excessive behavior continues, we will contact individuals privately to discuss the problems and how to correct them. Thanks, Margaret Wasserman & Bob Hinden 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 Nov 27 14:46:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARMk7Uu000992; Wed, 27 Nov 2002 14:46:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARMk6Gv000991; Wed, 27 Nov 2002 14:46:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARMk2Uu000981 for ; Wed, 27 Nov 2002 14:46:02 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARMkCbB020771 for ; Wed, 27 Nov 2002 14:46:12 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07572 for ; Wed, 27 Nov 2002 14:46:06 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARMjqj02381; Wed, 27 Nov 2002 17:45:52 -0500 (EST) Message-Id: <200211272245.gARMjqj02381@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ole Troan cc: Keith Moore , Kurt Erik Lindqvist , Margaret Wasserman , "Michel Py" , "Christian Huitema" , ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses In-reply-to: (Your message of "Wed, 27 Nov 2002 22:14:28 GMT.") <7t57keyvewr.fsf@mrwint.cisco.com> Date: Wed, 27 Nov 2002 17:45:52 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > if my memory serves me right we had consensus on limiting site-locals > somewhat, i.e not pushing multi-site support. e.g. perhaps. not i.e. the question wasn't nearly that precise. (which is part of why I objected to the question being asked in that way) > we also had consensus that _working_ on non-routable global PI > addresses sounded like an interesting idea. again, I think that's a slight rephrasing. this question wasn't precise either but there was clearly widespread interest and belief that global PI addresses would relieve some of the burden on SLs. > until we see some real proposals on the table, there is nothing to > reach consensus about with regards to GUPIs. nobody is claiming consensus on any specific GUPI proposal yet - we're still trying to figure out what the issues are and the general shape of something that might fly. 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 Nov 27 15:11:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARNBRUu001333; Wed, 27 Nov 2002 15:11:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gARNBQMW001332; Wed, 27 Nov 2002 15: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gARNBNUu001322 for ; Wed, 27 Nov 2002 15:11:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gARNBXMq029330 for ; Wed, 27 Nov 2002 15:11:33 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28221 for ; Wed, 27 Nov 2002 16:11:26 -0700 (MST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gARNB1gU008686; Thu, 28 Nov 2002 10:11:01 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211272311.gARNB1gU008686@drugs.dv.isc.org> To: "Michel Py" Cc: "Brian Carpenter" , "Aidan Williams" , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: globally unique site local addresses In-reply-to: Your message of "Wed, 27 Nov 2002 07:54:08 -0800." <2B81403386729140A3A899A8B39B04640BD46C@server2000> Date: Thu, 28 Nov 2002 10:11:01 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Brian Carpenter wrote: > > So I am unconditionally against any scheme that > > generates prefixes longer than /48. > > Agreed. > > Michel. Why? You can just get a additional prefixes if you need them. I would prefer it to be the same size as what is recommended for PA space but could work with a different size. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 27 16:28:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS0SfUu002310; Wed, 27 Nov 2002 16:28:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS0Sev7002309; Wed, 27 Nov 2002 16:28: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS0SbUu002302 for ; Wed, 27 Nov 2002 16:28:37 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS0SlbB016678 for ; Wed, 27 Nov 2002 16:28:47 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20121 for ; Wed, 27 Nov 2002 16:28:41 -0800 (PST) Subject: RE: globally unique site local addresses Date: Wed, 27 Nov 2002 16:28:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4E7@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: globally unique site local addresses Thread-Index: AcKWalZ4nOgq5ttAQpW3jasc+JnO8AACYMlQ From: "Michel Py" To: Cc: "Brian Carpenter" , "Aidan Williams" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAS0SbUu002303 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark, >>> Brian Carpenter wrote: >>> So I am unconditionally against any scheme that >>> generates prefixes longer than /48. >> Michel Py wrote: >> Agreed. > Why? You can just get a additional prefixes if > you need them. I would prefer it to be the same > size as what is recommended for PA space but could > work with a different size. Administrative nightmare. This one of these things in IPv6 where there is an explicit trade-off between allocation efficiency and simplicity. I agree that the 54 subnet bits we have for site-locals today is overkill, but anything less than 16 subnet bits is not good. In the case you have both site-local and global at the same time, you want to maintain subnet numbers: 2001:YOUR:BLOC:BEEF:INTE:RFAC:E_IDE:NTIF FEC0:0000:0000:BEEF:INTE:RFAC:E_IDE:NTIF ^^^^ Maintain subnet number Given the room we have in FEC0::/10, I don't see a reason to do otherwise. 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 Nov 27 17:14:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS1EsUu002497; Wed, 27 Nov 2002 17:14:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS1EsqP002496; Wed, 27 Nov 2002 17:14: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS1EpUu002489 for ; Wed, 27 Nov 2002 17:14:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS1F0Mq023286 for ; Wed, 27 Nov 2002 17:15:00 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03521 for ; Wed, 27 Nov 2002 18:14:55 -0700 (MST) Subject: RE: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Date: Wed, 27 Nov 2002 17:14:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4E8@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] Thread-Index: AcKWUWXIEgeAzuxdTpG0vfx0fnDhsQAJS0Gw From: "Michel Py" To: "Keith Moore" Cc: "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAS1EpUu002490 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, >> Michel Py wrote: >> Here's the dilemma: if the scope of GUPI is global, how >> could you guarantee that people won't pay their ISPs to >> leak the GUPI address in the defaultless routing table? > Keith Moore wrote: > If people don't want their addresses to be publically > routable, why would they pay their ISPs to route them? My point precisely: GUSL -> Scope is site-local -> no public routing. GUPI -> Scope is global -> if there is public routing this solves the multihoming issue (unfortunately, by exploding the routing table.) >> The big difference is that with GUSL we would have >> extended the scope to friendly sites, not to global. >> The risk of GUSL ending up global PI could be managed. > I don't see how this is changed by a decision to not > use FEC0::/10 for globally unique addresses. Because the scope of this new block would be global, if have not misread you (instead of local). > But there still seems to be an inherent conflict between > those who are demanding non-routable addresses (is anyone > else demanding this?) and those who want GUPIs to be > routable. If there's really sufficient demand for both > maybe we need separate blocks. Since London I have tried to push a multihoming draft that implements local PI as identifiers. I've heard "It's based on PI, I won't even read it" and "PI sucks, don't waste your time". What makes you think that GUPI would be different? You don't even have the multihoming carrot. Don't get me wrong: I'm not against GUPI on the principle, just pointing out that it has been stalled in multi6 forever. In other words: I'm not saying we should not work on it because it's bad, but because it's a waste of time today. Later, maybe. When the multihoming crud hits the fan. What we could achieve quickly is GUSL, with a mention that it must not be used for multi-site. Taking out the ambiguity and the multi-site would be good steps to limit site-local issues. Let's try to nail this before fighting the GUPI battle. 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 Nov 27 17:57:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS1vZUu002713; Wed, 27 Nov 2002 17:57:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS1vYA8002708; Wed, 27 Nov 2002 17:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS1vSUu002680 for ; Wed, 27 Nov 2002 17:57:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS1vbbB002345 for ; Wed, 27 Nov 2002 17:57:37 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14908 for ; Wed, 27 Nov 2002 18:57:31 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:e5d5:6b:6f5a:1eaf]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id gAS1vOd90436; Thu, 28 Nov 2002 10:57:24 +0900 (JST) Date: Thu, 28 Nov 2002 10:57:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: ipng@sunroof.eng.sun.com Subject: Re: Enforcing unreachability of site local addresses In-Reply-To: <7t57keyvewr.fsf@mrwint.cisco.com> References: <200211271725.gARHPXl01280@astro.cs.utk.edu> <7t57keyvewr.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 27 Nov 2002 22:14:28 +0000, >>>>> Ole Troan said: >>> ....but how on earth did we end up in this discussion? From what I >>> remember of the voting in Atlanta we had consensus for a limited >>> version of site-locals...not creating a separate address structure? >> >> as I recall, we had consensus for limiting site-locals, >> as well as widespread support for the idea that PI globals were needed. >> >> it's not an either-or. > if my memory serves me right we had consensus on limiting site-locals > somewhat, i.e not pushing multi-site support. > we also had consensus that _working_ on non-routable global PI > addresses sounded like an interesting idea. This is exactly what I have as the result of the meeting. > until we see some real proposals on the table, there is nothing to > reach consensus about with regards to GUPIs. I agree. And, as the chairs just suggested, what we need at this stage is a concrete proposal as an internet-draft. I guess we have had enough discussion and we don't need more on the list. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 17:57:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS1vhUu002716; Wed, 27 Nov 2002 17:57:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS1vhZv002715; Wed, 27 Nov 2002 17:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS1vVUu002687 for ; Wed, 27 Nov 2002 17:57:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS1vebB002351 for ; Wed, 27 Nov 2002 17:57:40 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19163 for ; Wed, 27 Nov 2002 18:57:34 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAS1vRj02955; Wed, 27 Nov 2002 20:57:27 -0500 (EST) Message-Id: <200211280157.gAS1vRj02955@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Michel Py" cc: "Keith Moore" , "IPng Working Group" Subject: Re: assignment of GUPI [RE: Taking two steps back (Was: Re: onequestion...)] In-reply-to: (Your message of "Wed, 27 Nov 2002 17:14:55 PST.") <2B81403386729140A3A899A8B39B046405E4E8@server2000> Date: Wed, 27 Nov 2002 20:57:27 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> Michel Py wrote: > >> Here's the dilemma: if the scope of GUPI is global, how > >> could you guarantee that people won't pay their ISPs to > >> leak the GUPI address in the defaultless routing table? > > > Keith Moore wrote: > > If people don't want their addresses to be publically > > routable, why would they pay their ISPs to route them? > > My point precisely: > GUSL -> Scope is site-local -> no public routing. > GUPI -> Scope is global -> if there is public routing > this solves the multihoming issue (unfortunately, > by exploding the routing table.) Not necessarily. There appear to be solutions for global routing of distinct prefixes which do not explode the routing table, but they don't solve multihoming either. > >> The big difference is that with GUSL we would have > >> extended the scope to friendly sites, not to global. > >> The risk of GUSL ending up global PI could be managed. > > > I don't see how this is changed by a decision to not > > use FEC0::/10 for globally unique addresses. > > Because the scope of this new block would be global, if have not misread > you (instead of local). What you seem to be trying to do is to say that since we don't currently know how to scale global routing of non-aggregatable prefixes, we need an architectural limitation to prevent it. I don't believe that it's appropriate to wire limitations of current routing technology into the addressing architecture. > > But there still seems to be an inherent conflict between > > those who are demanding non-routable addresses (is anyone > > else demanding this?) and those who want GUPIs to be > > routable. If there's really sufficient demand for both > > maybe we need separate blocks. > > Since London I have tried to push a multihoming draft that implements > local PI as identifiers. I've heard "It's based on PI, I won't even read > it" and "PI sucks, don't waste your time". Well, since Atlanta there is evidence of considerable interest in PI identifiers. So maybe people are coming around... > What makes you think that GUPI would be different? You don't even have > the multihoming carrot. Don't get me wrong: I'm not against GUPI on the > principle, just pointing out that it has been stalled in multi6 forever. multi6 is working on different things. If it turns out that they find a way to globally route GUPIs, that would be great. But we don't need to solve the global routing problem to make globally scoped PI addresses useful. > In other words: I'm not saying we should not work on it because it's > bad, but because it's a waste of time today. Actually I think the lack of GUPIs is one of the biggest things blocking progress of this group - it's forcing people to try to make SLs do things that they simply cannot do well given the assumptions that are already wired into the architecture and into code. 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 Nov 27 18:57:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS2v8Uu002990; Wed, 27 Nov 2002 18:57:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS2v8Zi002989; Wed, 27 Nov 2002 18:57: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS2v5Uu002982 for ; Wed, 27 Nov 2002 18:57:05 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS2vEbB012171 for ; Wed, 27 Nov 2002 18:57:14 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16315 for ; Wed, 27 Nov 2002 18:57:09 -0800 (PST) Subject: GUSL proposal (very crude) Date: Wed, 27 Nov 2002 18:57:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4E9@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: GUSL proposal (very crude) Thread-Index: AcKWfUWS+rGFpyduTZGWHF3wtr78NAABkxdw From: "Michel Py" To: "Margaret Wasserman" Cc: "Bob Hinden" , "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAS2v5Uu002983 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Note: this is independent of "GUPI"] GUSL Globally Unique Site Local Goals: 1. Provide an allocation method of site-local addresses within FEC0::/10 in order to avoid ambiguity of such addresses. 2. Enforce the non-routability of site-local addresses on the public Internet. 3. Clarify the use of site-local addresses for inter-site traffic. 1. Allocation method: 1.1 Rationale. There is a need for three types of allocation: - Free, automated configuration, no registration, no external connection, almost unique. - Free, manual or semi-automatic configuration, no registration, Internet connection necessary for semi-automatic configuration, unique. - Fee-based, manual registration, unique. Additonal properties TBD. 1.2 The site-local address space (FEC0::/10) will be divided in 3 parts: 1.2.1 Free, random/hash allocation, for unattended/ automated setups. See Paul Francis / Pekka Savola FEC0::/11 1.2.2 Unregistered, free, unique, sequentially allocated. See Charlie Perkins. FEE0::/12 1.2.3 Registered, probably not free, geographical or other allocation method, TBD. FEF0::/12 1.3 Choice of allocation method: 1.3.1 If the router autoconfigures itself, use 1.2.1, then save the prefix obtained in the config. 1.3.2 If there is interaction with the user, offer the choice: a) Manual, then save in config. b) Contact Charlie's server, then save in config. c) Same as 1.3.1. 2. Enforcement of global non-routability: 2.1 Rationale. Ambiguity provided some fail-safe for route leaks. By removing ambiguity, we must provide additional Enforcement of non-routability. 2.2 Routers MUST have a default blackhole for FEC0::/10. See Bob Hinden. This blackhole MUST NOT be easily removable, as it does not prevent the site from using more specific prefixes within FEC0::/10 2.3 Routers MUST discard by default any BGP routes matching FECO::/10 ge 10. See Michel Py. Accepting such routes MUST require specific permit statements. 3. Multiple sites: GUSL addresses SHOULD NOT be used for communication with other sites. (I am open to a MUST NOT, whatever the WG consensus 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 Nov 27 19:33:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS3X4Uu003106; Wed, 27 Nov 2002 19:33:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS3X4pP003105; Wed, 27 Nov 2002 19:33: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS3X0Uu003098 for ; Wed, 27 Nov 2002 19:33:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS3XAbB017247 for ; Wed, 27 Nov 2002 19:33:10 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25769 for ; Wed, 27 Nov 2002 20:33:03 -0700 (MST) Subject: Feedback requested on GUSL proposal Date: Wed, 27 Nov 2002 19:33:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4EA@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: Feedback requested on GUSL proposal Thread-Index: AcKWfUWS+rGFpyduTZGWHF3wtr78NAABkxdwAAKXSpA= From: "Michel Py" To: "Margaret Wasserman" Cc: "Bob Hinden" , "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAS3X1Uu003099 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv6 folk, I just posted some crude text for a GUSL proposal (I don't call this a draft yet. Note the small difference between "crud" and "crude" :-). What you do not need to mention: -------------------------------- - It is crude. - It needs to be fluffed out. - There is no boilerplate. - It does not solve _all_ the issues with site-locals. What I would like you to comment on: ------------------------------------ - There is no specifics about the hash/random algorithm. I do not think that we need to specify any as long as the vendor/implementer makes sure that there is a good enough seed/whatever-is-necessary to guarantee the lowest level of collisions. What I forgot: -------------- Whatever the method used, the site is assigned a /48. 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 Nov 27 20:10:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS4ADUu003255; Wed, 27 Nov 2002 20:10:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS4ACqv003254; Wed, 27 Nov 2002 20: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS4A9Uu003247 for ; Wed, 27 Nov 2002 20:10:09 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS4AFMq023576 for ; Wed, 27 Nov 2002 20:10:15 -0800 (PST) Received: from mail.nosense.org (225.cust4.nsw.dsl.ozemail.com.au [203.103.159.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11292 for ; Wed, 27 Nov 2002 20:10:09 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 7F0443B2E4; Thu, 28 Nov 2002 15:10:00 +1100 (EST) Subject: Re: GUSL proposal (very crude) From: Mark Smith To: Michel Py Cc: Margaret Wasserman , Bob Hinden , IPng Working Group In-Reply-To: <2B81403386729140A3A899A8B39B046405E4E9@server2000> References: <2B81403386729140A3A899A8B39B046405E4E9@server2000> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 28 Nov 2002 15:10:00 +1100 Message-Id: <1038456607.17243.24.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2002-11-28 at 13:57, Michel Py wrote: > [Note: this is independent of "GUPI"] > > > GUSL > > Globally Unique Site Local > > > Goals: > 1. Provide an allocation method of site-local addresses > within FEC0::/10 in order to avoid ambiguity of such > addresses. > 2. Enforce the non-routability of site-local addresses > on the public Internet. > 3. Clarify the use of site-local addresses for > inter-site traffic. > > > 1. Allocation method: > > 1.1 Rationale. > There is a need for three types of allocation: > - Free, automated configuration, no registration, > no external connection, almost unique. > - Free, manual or semi-automatic configuration, > no registration, Internet connection necessary > for semi-automatic configuration, unique. > - Fee-based, manual registration, unique. > Additonal properties TBD. > > 1.2 The site-local address space (FEC0::/10) will be > divided in 3 parts: > > 1.2.1 Free, random/hash allocation, for unattended/ > automated setups. > See Paul Francis / Pekka Savola > FEC0::/11 > > 1.2.2 Unregistered, free, unique, sequentially > allocated. > See Charlie Perkins. > FEE0::/12 > > 1.2.3 Registered, probably not free, geographical or > other allocation method, TBD. > FEF0::/12 > > 1.3 Choice of allocation method: > > 1.3.1 If the router autoconfigures itself, use 1.2.1, > then save the prefix obtained in the config. > > 1.3.2 If there is interaction with the user, offer > the choice: > a) Manual, then save in config. > b) Contact Charlie's server, then save in config. > c) Same as 1.3.1. > > 2. Enforcement of global non-routability: > > 2.1 Rationale. > Ambiguity provided some fail-safe for route leaks. > By removing ambiguity, we must provide additional > Enforcement of non-routability. > > 2.2 Routers MUST have a default blackhole for FEC0::/10. > See Bob Hinden. > This blackhole MUST NOT be easily removable, as it > does not prevent the site from using more specific > prefixes within FEC0::/10 > > 2.3 Routers MUST discard by default any BGP routes > matching FECO::/10 ge 10. See Michel Py. > Accepting such routes MUST require specific permit > statements. > The above is all really good (and I'm not being typically Australianly sarcastic), but isn't "Multiple sites" below the whole purpose of above ? I thought the scenario we were aiming to provide a solution for was : Michel and Mark come to some agreement that they don't want to use the global Internet to communicate with each other any more. The reasons for this agreement could be trust, cost, organisational merger, or just because it is Thursday. Both have near-unique / unique GUSLs, so they order a layer 2 circuit between (or create a private VPN between) each other's sites, connect networks together, and push the other's GUSL aggregate /48 or more specific prefixes into their IGP, possibly even using BGP between IGPs. Or is it that the wording below stating that GUSL addresses SHOULD NOT be used between sites if traffic will transit links _that are part of the public Internet_ (excluding a private VPN tunnel over the public Internet) ? If so, I agree with the text, though it probably needs to be a bit more explicit about what it is SHOULD NOTting. > 3. Multiple sites: > > GUSL addresses SHOULD NOT be used for communication with > other sites. > (I am open to a MUST NOT, whatever the WG consensus is) > > ps, if the above scenario _not_ is what GUPIs were trying to solve, a problem statement and how they go about solving it would also be good at this point. I've always thought we were trying to solve this same single problem, and GUPIs and GUSLs were basically the same thing. Regards, 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 20:40:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS4ePUu003421; Wed, 27 Nov 2002 20:40:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS4ePU5003420; Wed, 27 Nov 2002 20:40: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS4eLUu003413 for ; Wed, 27 Nov 2002 20:40:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS4eUMq027022 for ; Wed, 27 Nov 2002 20:40:30 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12504 for ; Wed, 27 Nov 2002 21:40:25 -0700 (MST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gAS4bZhG005267 for ; Wed, 27 Nov 2002 21:37:35 -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 VAA26330 for ; Wed, 27 Nov 2002 21:37:43 -0700 (MST)] Received: from motorola.com (awhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gAS4be7C002785 for ; Thu, 28 Nov 2002 15:37:41 +1100 (EST) Message-ID: <3DE59D94.89EB0B7B@motorola.com> Date: Thu, 28 Nov 2002 15:37:40 +1100 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: globally unique site local addresses References: <200211260104.gAQ14Bl13677@astro.cs.utk.edu> <3DE3178F.83071AA3@motorola.com> <3DE3421A.229A586D@hursley.ibm.com> <3DE40671.4030200@motorola.com> <3DE47AC5.6AF9581B@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: > > So I am unconditionally against any scheme that generates prefixes > longer than /48. Maybe I'm missing the point, but isn't the assumption of a /48 addressing scheme that you'll proceed to apply a second scheme to extend those /48 prefixes to /64 prefixes per link? Ergo 64 bit subnet prefixes? I'm just bypassing the middleman and saying 'within our site, let's just allocate subnets using a flat 50+ bit addressing scheme, based on router EUI-48s'. So, the SUBNET prefix has three parts (using fef::/12 as example): 12 bits: 'fef' - common identifier 52 bits: subnet id Of the 52 bits of subnet ID, the first 48 come from an EUI-48 on the router, and the remaining 4 are there in case the router doesn't want to use one EUI-48 per interface. This is the subnet prefix that is advertised in the routing tables and to hosts on the link. > And I can't imagine, in a 128 bit address space, being > limited to less than 16 bits to design my subnet addressing plan, > in a large organisation with hundreds of physical sites. I'm proposing to give you 54 bits of subnet addressing plan, but I'll do the allocation for you and guarantee its globally unique to boot. > I can't imagine operating two different subnet addressing plans > within a given organisation, just because I have two different > prefixes. Operationally and administratively, that would be a > nightmare. Well, IF you want to use this in parallel with another scheme then you will have to configure things like DNS with two sets of information - one for the automatically allocated subnets and one for the manual ones. But you'll have to do this anyway, even if the two addressing plans are identical at the low end. Cons: - Largely unaggregable - must have individual route for at least each router. (Should be able to aggregate links common to a router). - Flat subnet scheme using large amount of address space. Can't use scheme for global addressing (for example). [Actually, we could use this for global addressing, except for the aggregability issue.] - Some tweaking required when swapping out one router and in another, if you want addresses to not change. Pros: - Globally unique subnet addresses. - Factory configurable. No further registration or allocation needed. - Can work easily in parallel with fully administered addressing schemes. - Fixed and deterministic. Unless you move or manually reconfigure something, the addresses won't change. Ever. -- 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 Nov 27 20:59:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS4xuUu003609; Wed, 27 Nov 2002 20:59:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS4xtCB003608; Wed, 27 Nov 2002 20:59:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS4xqUu003601 for ; Wed, 27 Nov 2002 20:59:52 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS501bB027429 for ; Wed, 27 Nov 2002 21:00:02 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA29959 for ; Wed, 27 Nov 2002 21:59:55 -0700 (MST) Subject: RE: GUSL proposal (very crude) Date: Wed, 27 Nov 2002 20:59:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4EE@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: GUSL proposal (very crude) Thread-Index: AcKWlCpdgsOcPIwhQ4G9v2gclOJ/7wAAzykw From: "Michel Py" To: "Mark Smith" Cc: "Margaret Wasserman" , "Bob Hinden" , "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAS4xrUu003602 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark, > Mark Smith wrote: > I've always thought we were trying to solve this same > single problem, and GUPIs and GUSLs were basically the > same thing. GUSL solves the merger thing, but not the VPN. It was my original intent that GUSL could solve the VPN and inter-site connect as well, but Keith convinced me that it would be an architectural change and overall not a good idea to do. I see GUSL as a relatively low-ambition proposal that would solve some of the problems associated with site locals (but not all) and could reach consensus quickly. > Or is it that the wording below stating that GUSL > addresses SHOULD NOT be used between sites if traffic > will transit links _that are part of the public > Internet_ (excluding a private VPN tunnel over the > public Internet) ? If so, I agree with the text, > though it probably needs to be a bit more explicit > about what it is SHOULD NOTting. Site-local addresses MUST NOT be routed outside the site. GUSL *are* site-locals, and therefore must not be used for site-to-site communication. This part in the GUSL proposal is un-necessary as it basically is what is in the DS today; I included it to remove the potential misunderstanding that I intended to use GUSL to solve the inter-site connect as well. I'm happy to include "site-to-site communications MUST use GUPI addresses" as soon as there is a GUPI draft available. GUPI is the next step to GUSL. They could be merged, but I think GUPI is not ready for consensus, so there is some value in separating them. In other words: I think that GUSL is a no-brainer. It's not a miracle, but it does address two issues that I hear were a pain associated with site-locals: ambiguity and multi-site. The point I am trying to make is: let's nail GUSL if we can, and get something done that everyone could agree on. _Then_, let's work on inter-site communication, which is what GUPI is about, and which requires a lot more work. 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 Nov 27 21:04:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS541Uu003671; Wed, 27 Nov 2002 21:04:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS541cG003670; Wed, 27 Nov 2002 21: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS53vUu003663 for ; Wed, 27 Nov 2002 21:03:57 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS547Mq029885 for ; Wed, 27 Nov 2002 21:04:07 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24765 for ; Wed, 27 Nov 2002 21:04:01 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAS53vj04236; Thu, 28 Nov 2002 00:03:57 -0500 (EST) Message-Id: <200211280503.gAS53vj04236@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: awhite@arc.corp.mot.com cc: ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses In-reply-to: (Your message of "Thu, 28 Nov 2002 15:37:40 +1100.") <3DE59D94.89EB0B7B@motorola.com> X-SUBJECT-MSG-FROM: Andrew White Date: Thu, 28 Nov 2002 00:03:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm pretty much opposed to prefixes other than /48 also. It's really much more difficult to renumber a site if the old and new prefix lengths are different. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 21:10:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS5A3Uu003768; Wed, 27 Nov 2002 21:10:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS5A3tR003767; Wed, 27 Nov 2002 21:10: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS5A0Uu003758 for ; Wed, 27 Nov 2002 21:10:00 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS5AAbB028693 for ; Wed, 27 Nov 2002 21:10:10 -0800 (PST) Received: from cerberus.aebeard.com ([209.208.32.222]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00573 for ; Wed, 27 Nov 2002 21:10:04 -0800 (PST) Received: from amneris.aebeard.net (root@amneris.aebeard.net [192.168.232.3]) by cerberus.aebeard.com (8.11.6/8.10.1) with ESMTP id gAS5A3Z26067; Thu, 28 Nov 2002 00:10:03 -0500 (EST) Received: from localhost (aeb1@localhost) by amneris.aebeard.net (8.11.6/8.10.1) with ESMTP id gAS5A3G12243; Thu, 28 Nov 2002 00:10:03 -0500 (EST) Date: Thu, 28 Nov 2002 00:10:03 -0500 (EST) From: "Alan E. Beard" To: Michel Py cc: Margaret Wasserman , Bob Hinden , IPng Working Group Subject: Re: GUSL proposal (very crude) In-Reply-To: <2B81403386729140A3A899A8B39B046405E4E9@server2000> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel: In response to your later request for feedback on this proposal, here are my initial reactions: On Wed, 27 Nov 2002, Michel Py wrote: > Subject: GUSL proposal (very crude) > > [Note: this is independent of "GUPI"] > Agreed. GUPI is a separate topic which requires a workable solution. > > GUSL > > Globally Unique Site Local > > > Goals: > 1. Provide an allocation method of site-local addresses > within FEC0::/10 in order to avoid ambiguity of such > addresses. > 2. Enforce the non-routability of site-local addresses > on the public Internet. > 3. Clarify the use of site-local addresses for > inter-site traffic. > These seem laudable goals, and fall within what I believe to have been the bounds of the consensus at Atlanta. > > 1. Allocation method: > > 1.1 Rationale. > There is a need for three types of allocation: > - Free, automated configuration, no registration, > no external connection, almost unique. > - Free, manual or semi-automatic configuration, > no registration, Internet connection necessary > for semi-automatic configuration, unique. > - Fee-based, manual registration, unique. > Additonal properties TBD. > The three allocation types may be broader in scope that the _minimum_ requirements, but, to quote Mae West: "too much of a good thing can be wonderful." ;-) I see no objection to the allocation types as enumerated above. > 1.2 The site-local address space (FEC0::/10) will be > divided in 3 parts: > > 1.2.1 Free, random/hash allocation, for unattended/ > automated setups. > See Paul Francis / Pekka Savola > FEC0::/11 > > 1.2.2 Unregistered, free, unique, sequentially > allocated. > See Charlie Perkins. > FEE0::/12 > > 1.2.3 Registered, probably not free, geographical or > other allocation method, TBD. > FEF0::/12 > > 1.3 Choice of allocation method: > [...] This section seems entirely reasonable to me, at least in concept. The details can be settled as the work progresses. In the later note, a specification was included which seems to require that each allocation bear a prefix length of /48. Since we are already dealing with a /10 block for the entire SL space, this yields a maximum of 2**38 allocatable prefixes. I am impelled to wonder aloud: is this a sufficient count of possible allocations to meet the anticipated demand over the expected life of the IPv6 protocol? We thought, at least in the days of our innocence, that the IPv4 address space would be amply sufficient to the need; and we have for the past ten years or so reaped the bitter harvest of our myopia. Would it perhaps be wiser to make the allocations on a longer default prefix length, or, alternatively, to allocate on varying prefix lengths as the end-user's network requirements indicate? I suspect, based on the experience gained in working with clients, that a great many end-user networks will rush to acquire GUSL space, and very few of those networks are likely to _require_ an 80-bit address block to satisfy their operational requirements. Having stood ten years in a corner of the IPv4 implementation space while waiting for paint to dry, I would be greatly distressed to see like conditions arise pertaining to IPv6 within my lifetime. > > 2. Enforcement of global non-routability: > > 2.1 Rationale. > Ambiguity provided some fail-safe for route leaks. > By removing ambiguity, we must provide additional > Enforcement of non-routability. > > 2.2 Routers MUST have a default blackhole for FEC0::/10. > See Bob Hinden. > This blackhole MUST NOT be easily removable, as it > does not prevent the site from using more specific > prefixes within FEC0::/10 > This proscription concerning routing of the site-local block seems both necessary and desirable. > 2.3 Routers MUST discard by default any BGP routes > matching FECO::/10 ge 10. See Michel Py. > Accepting such routes MUST require specific permit > statements. Here again, the requirement seems necessary and desirable. Should we consider making the routing protocol requirement more general by substituting the specfication "any exterior gateway protocol" for the very specific "BGP"? > > 3. Multiple sites: > > GUSL addresses SHOULD NOT be used for communication with > other sites. > (I am open to a MUST NOT, whatever the WG consensus is) > It seems to me that item 3 above may be interpreted variously to mean, among other things: a) GUSL addressing may not be assigned to links (private or otherwise) connecting two or more sites, even if the GUSL addresses are not routable over the public network; or b) traffic bearing GUSL source or destination addresses may not be carried over links (private or otherwise) interconnecting two or more sites, even if the links themselves bear global addresses Based on previous traffic in the mailing list, I would expect that your intent would have been closer to the latter. I see potential implementation inconveniences with either interpretation above, but nothing that is insurmountable if a reasonable PI address allocation scheme for private network facilities is worked out before IPv6 begins to see widespread service in end-user networks. That's my $.02 worth. AEB -- Alan E. Beard AEBeard Consulting 4109 Chelsea Ln Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 21:19:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS5JeUu003895; Wed, 27 Nov 2002 21:19:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS5JeQW003894; Wed, 27 Nov 2002 21:19: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS5JbUu003887 for ; Wed, 27 Nov 2002 21:19:37 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS5JkbB029995 for ; Wed, 27 Nov 2002 21:19:46 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA08296 for ; Wed, 27 Nov 2002 22:19:40 -0700 (MST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gAS5JZQW028279; Wed, 27 Nov 2002 22:19:35 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id WAA26390; Wed, 27 Nov 2002 22:19:32 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gAS5JR7C008019; Thu, 28 Nov 2002 16:19:27 +1100 (EST) Message-ID: <3DE5A75F.9060503@motorola.com> Date: Thu, 28 Nov 2002 16:19:27 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py CC: Mark.Andrews@isc.org, Brian Carpenter , ipng@sunroof.eng.sun.com Subject: EUI-48 globally unique site-locals (GUSL) References: <2B81403386729140A3A899A8B39B046405E4E7@server2000> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A draft is in the pipeline. Michel, you and Brian are missing the point that there is *no* administration of SLAs if we can use a MAC address to automatically number *each* *link* in a site with a site-local address. All this needs is a new addressing format. I think this addresses your GUSL requirements. There is no numbering plan to administer, new or old. This has no effect on the numbering plan you might use for globals. There is no common site-local prefix shared across the site. Site-local addresses prefixes are constructed without manual configuration. For each link, a router may automatically assign a site-local address from an EUI-48 (ie a MAC address) using the following address format: | 12 bits | 48 bits | 4 bits | 64 bits | +---------+------------------+----------+----------------------+ | fef | router device ID | sub ID | machine interface ID | +---------+------------------+----------+----------------------+ Figure 1: Address Format: fef0::/12 There is no 16 bit SLA subnet number to be managed! A router gets 16 subnets per EUI-48. It can use those to number links without ethernet or similar chips with 48 bit MAC addresses. Links with more than one router can have more than one automatically allocated site-local prefix. IPv6 supports that just fine. If you don't like sharing the existing site-local space with non-/48 addressing format we can use a different prefix, say fe00::/10. That has the advantage of increasing to 6 the number of sub ID bits. - aidan Michel Py wrote: > Administrative nightmare. This one of these things in IPv6 where there > is an explicit trade-off between allocation efficiency and simplicity. > > I agree that the 54 subnet bits we have for site-locals today is > overkill, but anything less than 16 subnet bits is not good. > > In the case you have both site-local and global at the same time, you > want to maintain subnet numbers: > > 2001:YOUR:BLOC:BEEF:INTE:RFAC:E_IDE:NTIF > FEC0:0000:0000:BEEF:INTE:RFAC:E_IDE:NTIF > ^^^^ > Maintain subnet number > > Given the room we have in FEC0::/10, I don't see a reason to do > otherwise. > > 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 Nov 27 21:36:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS5aKUu004092; Wed, 27 Nov 2002 21:36:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS5aKr8004091; Wed, 27 Nov 2002 21:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS5aHUu004084 for ; Wed, 27 Nov 2002 21:36:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS5aRMq004348 for ; Wed, 27 Nov 2002 21:36:27 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA15389 for ; Wed, 27 Nov 2002 22:36:21 -0700 (MST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gAS5aL29027095 for ; Wed, 27 Nov 2002 22:36:21 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id WAA05291 for ; Wed, 27 Nov 2002 22:31:54 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gAS5a97C009794; Thu, 28 Nov 2002 16:36:09 +1100 (EST) Message-ID: <3DE5AB49.1030707@motorola.com> Date: Thu, 28 Nov 2002 16:36:09 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore CC: Andrew White , ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <200211280503.gAS53vj04236@astro.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: > I'm pretty much opposed to prefixes other than /48 also. It's really > much more difficult to renumber a site if the old and new prefix lengths > are different. Assuming we can make the site-local prefixes globally unique, why would we ever need to renumber them? I want provider independent globally unique site-locals precisely so I can set my local network up to be independent of renumbering events. Further, using an EUI-48 for a prefix (which extends beyond /48) allows the site-local addressing to be automatically generated. If you have working unicast site-local addressing, one can then imagine building protocols on top that automatically allocate 16 bit SLA numbers from global prefixes (a la zerouter). I can also imagine bootstrapping router renumbering from working automatically configured site-local addressing. - 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 Wed Nov 27 21:39:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS5diUu004145; Wed, 27 Nov 2002 21:39:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS5diMF004144; Wed, 27 Nov 2002 21:39: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS5dfUu004137 for ; Wed, 27 Nov 2002 21:39:41 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS5dpbB002437 for ; Wed, 27 Nov 2002 21:39:51 -0800 (PST) Received: from mail.nosense.org (225.cust4.nsw.dsl.ozemail.com.au [203.103.159.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA06057 for ; Wed, 27 Nov 2002 21:39:45 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 0528D3B2E4; Thu, 28 Nov 2002 16:39:42 +1100 (EST) Subject: RE: GUSL proposal (very crude) From: Mark Smith To: Michel Py Cc: Margaret Wasserman , Bob Hinden , IPng Working Group In-Reply-To: <2B81403386729140A3A899A8B39B046405E4EE@server2000> References: <2B81403386729140A3A899A8B39B046405E4EE@server2000> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 28 Nov 2002 16:39:42 +1100 Message-Id: <1038461983.17242.48.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2002-11-28 at 15:59, Michel Py wrote: > Mark, > > > Mark Smith wrote: > > I've always thought we were trying to solve this same > > single problem, and GUPIs and GUSLs were basically the > > same thing. > > > GUSL solves the merger thing, but not the VPN. I'm not sure I see the difference. Presuming running IPsec in tunnel mode, the outer addressing (ie your tunnel end points) is using global addresses, but the inner addressing is what ever you like it to be (and is hidden from the Internet anyway as the IPsec ESP encrypted payload). What addressing would nodes use when they decide to talk to each other over the IPsec tunnel ? If the nodes use their global addresses, then the IPsec tunnel becomes a single-hop short circuit of the Internet routing infrastructure between the sites. The advantage it adds is the encryption and authentication of the traffic between sites. But if nodes want to that level of security, an alternative is to do end-to-end opportunistic IPsec between the nodes themselves. I'm not sure if there is a problem with using global addresses inside a site-to-site IPsec tunnel, I'll need to think about it some more. I do need to put together a follow up email on a related IPsec / site-local topic though. Regards, 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 27 21:39:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS5dvUu004159; Wed, 27 Nov 2002 21:39:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS5dvCc004157; Wed, 27 Nov 2002 21:39: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS5dnUu004150 for ; Wed, 27 Nov 2002 21:39:50 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS5dxbB002449 for ; Wed, 27 Nov 2002 21:39:59 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA10049 for ; Wed, 27 Nov 2002 21:39:54 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAS5dmj04519; Thu, 28 Nov 2002 00:39:49 -0500 (EST) Message-Id: <200211280539.gAS5dmj04519@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Aidan Williams cc: Keith Moore , Andrew White , ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses In-reply-to: (Your message of "Thu, 28 Nov 2002 16:36:09 +1100.") <3DE5AB49.1030707@motorola.com> Date: Thu, 28 Nov 2002 00:39:48 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I'm pretty much opposed to prefixes other than /48 also. It's really > > much more difficult to renumber a site if the old and new prefix lengths > > are different. > > Assuming we can make the site-local prefixes globally unique, > why would we ever need to renumber them? when you get external connectivity and a global prefix and realize that you're better off not having to support both the global and the GUSL prefixes. so you want to renumber from GUSL to global. (e.g. your apps run more reliably, administration is simpler, etc.) 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 Nov 27 21:56:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS5ubUu004445; Wed, 27 Nov 2002 21:56:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS5ubnP004444; Wed, 27 Nov 2002 21:56: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS5uYUu004437 for ; Wed, 27 Nov 2002 21:56:34 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS5uhMq006705 for ; Wed, 27 Nov 2002 21:56:43 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA15605 for ; Wed, 27 Nov 2002 21:56:38 -0800 (PST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gAS5ubQW004315 for ; Wed, 27 Nov 2002 22:56:38 -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 WAA11492 for ; Wed, 27 Nov 2002 22:56:35 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gAS5uP7C011896; Thu, 28 Nov 2002 16:56:25 +1100 (EST) Message-ID: <3DE5B00A.60303@motorola.com> Date: Thu, 28 Nov 2002 16:56:26 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore CC: Andrew White , ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses References: <200211280539.gAS5dmj04519@astro.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: > when you get external connectivity and a global prefix and > realize that you're better off not having to support both the > global and the GUSL prefixes. so you want to renumber from > GUSL to global. > No actually, I don't want to renumber from GUSL to global -- I want both. My external connectivity is 6to4, and the prefix changes. The lack of global PI address space exposes me to renumbering pain. > (e.g. your apps run more reliably, administration is simpler, etc.) Ironically, that is exactly why I will keep site-locals running in parallel with my globals. - 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 Thu Nov 28 00:33:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS8X1Uu005279; Thu, 28 Nov 2002 00:33:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS8X1DU005278; Thu, 28 Nov 2002 00:33:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS8WwUu005271 for ; Thu, 28 Nov 2002 00:32:58 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS8X7Mq029556 for ; Thu, 28 Nov 2002 00:33:08 -0800 (PST) Received: from mail.nosense.org (225.cust4.nsw.dsl.ozemail.com.au [203.103.159.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07952 for ; Thu, 28 Nov 2002 00:33:01 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id 6A9E43B2E4 for ; Thu, 28 Nov 2002 19:33:00 +1100 (EST) Subject: The future of connectivity, or how globally unique site locals may become almost obsolete. From: Mark Smith To: ipng@sunroof.eng.sun.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 28 Nov 2002 19:33:00 +1100 Message-Id: <1038472380.17242.221.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, I've put together the following email as a bit of a thought provoker on how organisations may connect themselves together in the future, and how that may effect globally unique site-local use. Note that I haven't thought out a lot of it thoroughly - it may all be totally bogus, or may be a totally wrong view of the future. |1|. IPsec is free in IPv6, why not use it ? At a certain point in time, IPv6 and the mandatory IPsec component will become prevalent. Presuming most organisations have a public Internet connection, they will be inclined to create IPsec tunnels between each of their geographical sites, rather than commissioning private circuits. As long as the IPsec tunnel over the Internet delivers good enough QOS, organisations will prefer them, as they are far cheaper than dedicated private circuits, even if that IPsec cost included of upping their Internet connectivity bandwidth. An organisation may end up with a large number of point-to-point tunnels, inter-connecting their geographical sites, in any number of arbitrary topologies. However, as the cost of a tunnel is only generally only configuration time, a full mesh tunnel topology is likely to be common. Manual tunnel configuration isn't scalable, but automated tools will be developed to provision these large IPv6 IPsec tunnel based VPNs (they already exist for IPv4 based ipsec). |2|. Overlay networks don't scale very well The problem with overlay or point to point IPsec tunnel VPNs is they cause IGP scaling problems. Because each router in the VPN is now directly connected to the others, running an IGP over the top of it means that each router now has a large number of IGP neighbors (N-1 in a full mesh topology). There are limits on how many IGP peers a router can cope with. This is not a new problem, apparently it has been suffered with IP over ATM based networks [1]. One way to solve this IGP scaling problem is to use traditional IGP scaling techniques - dividing the IGP into areas, introduce ASs and an EGP etc. |3|. A better solution to overlay network scalability is to flatten the network. To avoid the IPsec tunnel scalability problem, you need to get rid of the point-to-point tunnels, so that the routers at the edge of the VPN (or encryption domain) are not direct neighbors. This is similar to what MPLS has done for IP over ATM networks [2]. The routers that are at the edge of the VPN would now peer directly and equally with the upstream Internet gateway via an IGP or EGP. However, the consequence of this is that you cannot use any form of private addressing within the tunnel, as tunnels doesn't actually exist anymore. To still create a virtual network, the local VPN gateway would still need to be able to send traffic to a specific, remote VPN gateway. It also needs to be able to associate destinations with a IPsec Security Association. I imagine this could be achieved by using IPsec in transport mode, in combination with a loose source route extension header, listing the global IP address of the remote VPN gateway in the IPv6 header, and the first hop of the loose source route being the actual destination of the packet. For those familiar with IPsec terminology, I would describe this as a "bump-in-the-wire transport mode pseudo-tunnel". |4|. How does this bump-in-the-wire transport mode pseudo-tunnel VPN effect our proposed globally unique site-locals ? Now that the VPN gateway is peering directly with the Internet gateway via an IGP or EGP, rather than the other VPN gateways, it is not allowed to advertise site-local prefixes to the Internet gateway. Also, similar to BCP 38 - "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", ISPs are likely to drop traffic with site-local source addresses. Which means that all remote communications, to either Internet or VPN destinations, has to use global addresses. Under the above model, GUSLs are still useful, but only when two organisations directly connect or directly merge their physical infrastructure. This may be a rare occurrence, unless they are in adjacent buildings, and they pull an ethernet through a hole in the wall. Bringing up an IPsec tunnel (either todays type of IPsec tunnel, or the above psuedo tunnel model) is likely to be easier, and more popular. |5|. Exceptions, caveats and other notes 5.1 The above assumes that organisations don't immediately deploy true end-to-end, opportunistic transport mode IPsec between nodes. That being said, if they did deploy end-to-end opportunistic transport mode IPsec, they still can't use site-local addressing when communicating over the Internet. 5.2 I've been meaning to look into whether the ipsec working group have done any work on anything similar to my "bump-in-the-wire transport mode pseudo tunnle" ipsec model but haven't got around to it. I've been intending bring this up in that working group if they haven't. I've been a bit busy recently organising an interstate move unfortunately. 5.3 With today's IPsec tunnel model, I would prefer not to have the restriction of not being able to use GUSLs over my IPsec tunnels. Why do we have this mind set that a site is restricted to a geographical location ? This is the only instance I know of where a logical boundary has been defined by the ietf as having a geographical size. OSPF Areas don't, BGP ASs don't, arguably even link locals don't - you can build some really big ethernet segments - I know of at least one vendor who sell GBICs that can drive a 90 Kilometer long piece of single mode fibre. Surely 90 kilometer's would be bigger than a "site". I would prefer to be able to define the size of my "site", and include the "insides" of my IPsec tunnels within that site. 5.4 On the other hand, with my "bump-in-the-wire transport mode pseudo tunnel" ipsec model, there are now technical reasons not to use GUSLs over VPNs. |6|. References [1] and [2] - MPLS: Technology and Applications, by Bruce S. Davie, Yakov Rekhter - can't look up the page numbers, my copy is packed in a box - see point 5.2 above :-) Any thoughts ? Thanks, 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 28 00:50:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS8oQUu005380; Thu, 28 Nov 2002 00:50:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS8oQr6005379; Thu, 28 Nov 2002 00:50: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS8oMUu005372 for ; Thu, 28 Nov 2002 00:50:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS8oWMq001734 for ; Thu, 28 Nov 2002 00:50:32 -0800 (PST) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18409 for ; Thu, 28 Nov 2002 01:50:26 -0700 (MST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAS8oGlp026202; Thu, 28 Nov 2002 09:50:16 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAS8o8wW059810; Thu, 28 Nov 2002 09:50:09 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45464 from ; Thu, 28 Nov 2002 09:50:06 +0100 Message-Id: <3DE5D8A8.B348B89C@hursley.ibm.com> Date: Thu, 28 Nov 2002 09:49:44 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Aidan Williams Cc: ipng@sunroof.eng.sun.com Subject: Re: EUI-48 globally unique site-locals (GUSL) References: <2B81403386729140A3A899A8B39B046405E4E7@server2000> <3DE5A75F.9060503@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I could write quite a long essay on why this wouldn't work, either on the site whose network I used to manage until a few years ago, or on the intranet of my current employer. It's a neat trick, but it just doesn't match the realities of network management and operations. It implies, for example, that if you have to change a NIC in a router, or swap a faulty router, subnet renumbering will occur, with all its consequences for DNS, SNMP, security policy and key distribution, and asset management databases. In any case, that size of network will need the same subnet numbering plan for globals and locals, to avoid driving the network operators crazy during fault analysis. There may be a class of smallish unmanaged networks where this would work, but even there I think there's a big DNS problem. Brian Aidan Williams wrote: > > A draft is in the pipeline. > > Michel, you and Brian are missing the point that there > is *no* administration of SLAs if we can use a MAC address > to automatically number *each* *link* in a site with a > site-local address. > > All this needs is a new addressing format. > I think this addresses your GUSL requirements. > > There is no numbering plan to administer, new or old. > This has no effect on the numbering plan you might use for globals. > There is no common site-local prefix shared across the site. > Site-local addresses prefixes are constructed without manual > configuration. > > For each link, a router may automatically assign a site-local > address from an EUI-48 (ie a MAC address) using the following > address format: > > | 12 bits | 48 bits | 4 bits | 64 bits | > +---------+------------------+----------+----------------------+ > | fef | router device ID | sub ID | machine interface ID | > +---------+------------------+----------+----------------------+ > Figure 1: Address Format: fef0::/12 > > There is no 16 bit SLA subnet number to be managed! > > A router gets 16 subnets per EUI-48. It can use those to number > links without ethernet or similar chips with 48 bit MAC addresses. > > Links with more than one router can have more than one automatically > allocated site-local prefix. IPv6 supports that just fine. > > If you don't like sharing the existing site-local space with non-/48 > addressing format we can use a different prefix, say fe00::/10. > That has the advantage of increasing to 6 the number of sub ID bits. > > - aidan > > Michel Py wrote: > > Administrative nightmare. This one of these things in IPv6 where there > > is an explicit trade-off between allocation efficiency and simplicity. > > > > I agree that the 54 subnet bits we have for site-locals today is > > overkill, but anything less than 16 subnet bits is not good. > > > > In the case you have both site-local and global at the same time, you > > want to maintain subnet numbers: > > > > 2001:YOUR:BLOC:BEEF:INTE:RFAC:E_IDE:NTIF > > FEC0:0000:0000:BEEF:INTE:RFAC:E_IDE:NTIF > > ^^^^ > > Maintain subnet number > > > > Given the room we have in FEC0::/10, I don't see a reason to do > > otherwise. > > > > 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 Nov 28 00:56:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS8ukUu005465; Thu, 28 Nov 2002 00:56:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS8ujro005463; Thu, 28 Nov 2002 00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS8ugUu005456 for ; Thu, 28 Nov 2002 00:56:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS8uqbB027420 for ; Thu, 28 Nov 2002 00:56:52 -0800 (PST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26781 for ; Thu, 28 Nov 2002 01:56:46 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAS8uTC3051582; Thu, 28 Nov 2002 09:56:30 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAS8uSFt040432; Thu, 28 Nov 2002 09:56:29 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA22626 from ; Thu, 28 Nov 2002 09:56:24 +0100 Message-Id: <3DE5DA21.539B7ED4@hursley.ibm.com> Date: Thu, 28 Nov 2002 09:56:01 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Mark Smith Cc: Michel Py , Margaret Wasserman , Bob Hinden , IPng Working Group Subject: Re: GUSL proposal (very crude) References: <2B81403386729140A3A899A8B39B046405E4EE@server2000> <1038461983.17242.48.camel@dupy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark Smith wrote: > > On Thu, 2002-11-28 at 15:59, Michel Py wrote: > > Mark, > > > > > Mark Smith wrote: > > > I've always thought we were trying to solve this same > > > single problem, and GUPIs and GUSLs were basically the > > > same thing. > > > > > > GUSL solves the merger thing, but not the VPN. > > I'm not sure I see the difference. I agree. As longs as GUSL prefixes are unique, you can flat route them in a "foreign" enterprise network. Maybe some ad hoc static routes are needed, but that's common in inter-enterprise VPN setups. 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 Nov 28 01:00:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS90kUu005558; Thu, 28 Nov 2002 01:00:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAS90kjw005557; Thu, 28 Nov 2002 01:00: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAS90eUu005550 for ; Thu, 28 Nov 2002 01:00:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAS90nMq002996 for ; Thu, 28 Nov 2002 01:00:49 -0800 (PST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28808 for ; Thu, 28 Nov 2002 02:00:44 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAS90YC3082140; Thu, 28 Nov 2002 10:00:38 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAS90VFt059890; Thu, 28 Nov 2002 10:00:32 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA22740 from ; Thu, 28 Nov 2002 10:00:30 +0100 Message-Id: <3DE5DB17.393DE080@hursley.ibm.com> Date: Thu, 28 Nov 2002 10:00:07 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: IPng Working Group Subject: Re: GUSL proposal (very crude) References: <2B81403386729140A3A899A8B39B046405E4E9@server2000> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: ... > > 1.2.1 Free, random/hash allocation, for unattended/ > automated setups. > See Paul Francis / Pekka Savola > FEC0::/11 > > 1.2.2 Unregistered, free, unique, sequentially > allocated. > See Charlie Perkins. > FEE0::/12 I suggest considering the "seconds elapsed since a reference date" proposal, because it would be less work for Charlie. Or use that method instead for FEC0::/11, because it doesn't need a seed. > > 1.2.3 Registered, probably not free, geographical or > other allocation method, TBD. > FEF0::/12 If you like hexadecimal puns, this should be FEE0::/12 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 Nov 28 04:05:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gASC5fUu006274; Thu, 28 Nov 2002 04:05:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gASC5eAg006273; Thu, 28 Nov 2002 04:05:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gASC5aUu006266 for ; Thu, 28 Nov 2002 04:05:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gASC5lbB020717 for ; Thu, 28 Nov 2002 04:05:47 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA25355 for ; Thu, 28 Nov 2002 05:05:41 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gASC5Yj13990; Thu, 28 Nov 2002 07:05:35 -0500 (EST) Message-Id: <200211281205.gASC5Yj13990@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Aidan Williams cc: Keith Moore , Andrew White , ipng@sunroof.eng.sun.com Subject: Re: globally unique site local addresses In-reply-to: (Your message of "Thu, 28 Nov 2002 16:56:26 +1100.") <3DE5B00A.60303@motorola.com> Date: Thu, 28 Nov 2002 07:05:34 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > when you get external connectivity and a global prefix and > > realize that you're better off not having to support both the > > global and the GUSL prefixes. so you want to renumber from > > GUSL to global. > > > > No actually, I don't want to renumber from GUSL to global -- > I want both. you want both. others will want to renumber. > > (e.g. your apps run more reliably, administration is simpler, etc.) > > Ironically, that is exactly why I will keep site-locals running > in parallel with my globals. having SLs (even globally unique ones) in addition to globals causes its own pain. I am not arguing that you shouldn't be able to choose to have your network that way, just that the architecture should make it easy to move from one kind of prefix to another. What would bother me is an architecture that imposed more pain for a site that had started out with a GUSL and needed to transition to globals. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 28 10:38:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gASIc7Uu006825; Thu, 28 Nov 2002 10:38:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gASIc78Z006824; Thu, 28 Nov 2002 10:38: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gASIc4Uu006817 for ; Thu, 28 Nov 2002 10:38:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gASIcEbB006495 for ; Thu, 28 Nov 2002 10:38:14 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09351 for ; Thu, 28 Nov 2002 11:38:08 -0700 (MST) Subject: RE: GUSL proposal (very crude) Date: Thu, 28 Nov 2002 10:38:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4F0@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: GUSL proposal (very crude) Thread-Index: AcKWvDV5Yd8P53yzQjaKRD1blyLltAATkUJg From: "Michel Py" To: "Brian Carpenter" , "Mark Smith" Cc: "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gASIc4Uu006818 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark / Brian, >>> Michel Py wrote: >>> GUSL solves the merger thing, but not the VPN. >> Mark Smith wrote >> I'm not sure I see the difference. > Brian Carpenter > I agree. As longs as GUSL prefixes are unique, you can > flat route them in a "foreign" enterprise network. Maybe > some ad hoc static routes are needed, but that's common > in inter-enterprise VPN setups. Note that what you are saying was my original thinking. But it conflicts with the following text in [addrarch]. > draft-ietf-ipngwg-addr-arch-v3-11.txt [Page 12] > 2.5.6 Local-Use IPv6 Unicast Addresses > [..] > Routers must not forward any packets with site-local > source or destination addresses outside of the site. Although there is no normative language, this seems pretty clear to me. And, I hear there are lots of problems associated with site-locals and multiple sites. I think that inter-site communications would be better off *not* using site-locals. This means that today they must use PA, and could use GUPI when it is available. In other words: The fact that GUSL could enable inter-site communications (because it removes ambiguity) does not mean it should: GUSL still are site-locals and must stay confined within the site. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 28 11:07:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gASJ7CUu006948; Thu, 28 Nov 2002 11:07:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gASJ7C5a006947; Thu, 28 Nov 2002 11:07: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gASJ79Uu006940 for ; Thu, 28 Nov 2002 11:07:09 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gASJ7KMq019935 for ; Thu, 28 Nov 2002 11:07:20 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08663 for ; Thu, 28 Nov 2002 11:07:14 -0800 (PST) Subject: RE: GUSL proposal (very crude) Date: Thu, 28 Nov 2002 11:07:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B04640BD48A@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 X-MS-TNEF-Correlator: content-class: urn:content-classes:message Thread-Topic: GUSL proposal (very crude) Thread-Index: AcKWnJIFpV7iVndoQqWDfMGSwpufIgAAIDpw From: "Michel Py" To: "Alan E. Beard" Cc: "Margaret Wasserman" , "Bob Hinden" , "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gASJ79Uu006941 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alan, Thanks for your comments. > The three allocation types may be broader in scope > that the _minimum_ requirements, but, to quote Mae > West: "too much of a good thing can be wonderful." Note (as mentioned earlier) that the third type is subject to scrap at any time, including if the rest of the text reaches consensus, in order to expedite the process. > Since we are already dealing with a /10 block for the entire > SL space, this yields a maximum of 2**38 allocatable prefixes. > I am impelled to wonder aloud: is this a sufficient count of > possible allocations to meet the anticipated demand over the > expected life of the IPv6 protocol? The answer to this question is likely yes. Comparing scalability with another topic which is multihoming, we have designed the number of multihomed sites around 2**32 (4 billion). Although we would have the possibility to allocate another /16 for multihomed sites should the need arise, please keep in mind that: - Site-locals are not for everybody. - 2**38 is 256 billion, of /48 sites with 64k subnets each this is. There are 6 billion people on this planet today. I don't see the need for more than 1 site per person, if that. If we get in a situation such as massive colonization of outer space or Earth looking like Coruscant, we will allocate another /10 for site-locals. > Should we consider making the routing protocol requirement > more general by substituting the specfication "any exterior > gateway protocol" for the very specific "BGP"? Good point, changed. > a) GUSL addressing may not be assigned to links (private > or otherwise) connecting two or more sites, even if the > GUSL addresses are not routable over the public network; > or > b) traffic bearing GUSL source or destination addresses > may not be carried over links (private or otherwise) > interconnecting two or more sites, even if the links > themselves bear global addresses > Based on previous traffic in the mailing list, I would > expect that your intent would have been closer to the > latter. Actually, both. I was thinking about replacing the text with: 3. Multiple sites: 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 see potential implementation inconveniences with either > interpretation above, but nothing that is insurmountable > if a reasonable PI address allocation scheme for private > network facilities is worked out before IPv6 begins to see > widespread service in end-user networks. Agreed. 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 Nov 28 14:27:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gASMRMUu007816; Thu, 28 Nov 2002 14:27:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gASMRMfF007815; Thu, 28 Nov 2002 14:27: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gASMRIUu007808 for ; Thu, 28 Nov 2002 14:27:18 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gASMRTbB000848 for ; Thu, 28 Nov 2002 14:27:29 -0800 (PST) Received: from mail.nosense.org (225.cust4.nsw.dsl.ozemail.com.au [203.103.159.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06433 for ; Thu, 28 Nov 2002 14:27:23 -0800 (PST) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.nosense.org (Postfix) with ESMTP id B2E7B3B2F5; Fri, 29 Nov 2002 09:27:19 +1100 (EST) Subject: RE: GUSL proposal (very crude) From: Mark Smith To: Michel Py Cc: Brian Carpenter , IPng Working Group In-Reply-To: <2B81403386729140A3A899A8B39B046405E4F0@server2000> References: <2B81403386729140A3A899A8B39B046405E4F0@server2000> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 29 Nov 2002 09:27:19 +1100 Message-Id: <1038522441.17243.265.camel@dupy> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Playing the devils advocate .... Michel, can you describe, in a real world, nuts and bolts manner, where your "site" boundary would be. Would your site boundary positioned based on : 1) A dramatic drop in bandwidth capacity eg from typical LAN to typical WAN bandwidth drop or 2) geographic network size or 3) Logical (eg tunnel) verses physical network connectivity I'm really struggling with what a "site" is. Using the current [addrarch] definition : -- Site-local scope, for uniquely identifying interfaces within a single site only. A "site" is, by intent, not rigorously defined, but is typically expected to cover a region of topology that belongs to a single organization and is located within a single geographic location, such as an office, an office complex, or a campus. A personal residence may be treated as a site (for example, when the residence obtains Internet access via a public Internet service provider), or as a part of a site (for example, when the residence obtains Internet access via an employer's or school's site) -- which says sites are primarily geographically bounded at around the campus size (say no more than a 5 KM diameter), then GUSLs really could only be used to join two campus networks that are geographically adjacent, and when combined, still fit within the geographically defined site size that the above suggests. All other site interconnection would have to use global addressing. How often are geographically adjacent sites going to merge, and still fit within the definition of an [addrarch] site, allowing the use of GUSLs ? I wouldn't think very often. For example, presuming a "site" is no more than 5 Km in diameter, if I was to join two sites that were 10 Km apart, with the current definitions, I must use global addressing between them. I've been told before on this ML that "site" doesn't have geographic boundaries (which would then allow me define the site boundary where every I like, and not exclude me from using GUSLs over a IPsec tunnel), but until the above text changes, as much as I'd like to, I really don't think I can assume that. Thanks, Mark. On Fri, 2002-11-29 at 05:38, Michel Py wrote: > Mark / Brian, > > >>> Michel Py wrote: > >>> GUSL solves the merger thing, but not the VPN. > > >> Mark Smith wrote > >> I'm not sure I see the difference. > > > Brian Carpenter > > I agree. As longs as GUSL prefixes are unique, you can > > flat route them in a "foreign" enterprise network. Maybe > > some ad hoc static routes are needed, but that's common > > in inter-enterprise VPN setups. > > Note that what you are saying was my original thinking. But it conflicts > with the following text in [addrarch]. > > > draft-ietf-ipngwg-addr-arch-v3-11.txt [Page 12] > > 2.5.6 Local-Use IPv6 Unicast Addresses > > [..] > > Routers must not forward any packets with site-local > > source or destination addresses outside of the site. > > Although there is no normative language, this seems pretty clear to me. > And, I hear there are lots of problems associated with site-locals and > multiple sites. > > I think that inter-site communications would be better off *not* using > site-locals. This means that today they must use PA, and could use GUPI > when it is available. > > In other words: The fact that GUSL could enable inter-site > communications (because it removes ambiguity) does not mean it should: > GUSL still are site-locals and must stay confined within the site. > > Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 28 16:54:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAT0sYUu008350; Thu, 28 Nov 2002 16:54:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAT0sYNE008349; Thu, 28 Nov 2002 16:54: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAT0sVUu008342 for ; Thu, 28 Nov 2002 16:54:31 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAT0sfMq027838 for ; Thu, 28 Nov 2002 16:54:41 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02477 for ; Thu, 28 Nov 2002 17:54:36 -0700 (MST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gAT0sY29015666; Thu, 28 Nov 2002 17:54:34 -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 RAA15748; Thu, 28 Nov 2002 17:54:32 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gAT0sT7C023278; Fri, 29 Nov 2002 11:54:29 +1100 (EST) Message-ID: <3DE6BAC6.60207@motorola.com> Date: Fri, 29 Nov 2002 11:54:30 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: EUI-48 globally unique site-locals (GUSL) References: <2B81403386729140A3A899A8B39B046405E4E7@server2000> <3DE5A75F.9060503@motorola.com> <3DE5D8A8.B348B89C@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: > I could write quite a long essay on why this wouldn't > work, either on the site whose network I used to manage > until a few years ago, or on the intranet of my current > employer. Ah, you can think of cases where it won't apply. So can I. I also have run some large networks including going through the exercise of renumbering large portions with IPv4. All the IPv6 addressing and renumbering proposals I have seen have had drawbacks -- usually relating to their managability, and in my opinion because they require excessive manual configuration where it is not required. Are we doing engineering here or searching for *the* solution matching some single perfect Platonic form? Pragmatically I think we need a variety of addressing and renumbering solutions with strengths that suit various environments. The important requirement is to ensure that they don't interfere with one another. > It's a neat trick, but it just doesn't match > the realities of network management and operations. It > implies, for example, that if you have to change a NIC > in a router, or swap a faulty router, subnet renumbering > will occur, with all its consequences for DNS, SNMP, > security policy and key distribution, and asset management > databases. I understand what you are saying. I am not against having a fully manually configured solution for large scale networks employing administrators. If a security policy has to be expressed in an addressing plan -- fine. I *do* want to see addressing solutions for un-administered networks that *don't* require manual configuration before anything gets off the ground. (scale larger than 1 link). I can also imagine the two co-existing. Address stability for critical infrastructure services can be achieved by manual allocated of a *few* subnets rather than requiring manual configuration of *all* subnets. > In any case, that size of network will need the same > subnet numbering plan for globals and locals, to avoid > driving the network operators crazy during fault analysis. > In case it is unclear, I am not advocating the abolition of manually configurable site local addresses. > There may be a class of smallish unmanaged networks where this > would work, but even there I think there's a big DNS problem. > Right -- the zerouter scale rather than the world-wide network scale. I agree that there are problems getting the DNS configured in the first place, and problems whenever you renumber (whatever the cause: manual intervention, router card swap or for that matter a host NIC swap). I don't think this proposal makes it any worse. - aidan > Aidan Williams wrote: > >>A draft is in the pipeline. >> >>Michel, you and Brian are missing the point that there >>is *no* administration of SLAs if we can use a MAC address >>to automatically number *each* *link* in a site with a >>site-local address. >> >>All this needs is a new addressing format. >>I think this addresses your GUSL requirements. >> >>There is no numbering plan to administer, new or old. >>This has no effect on the numbering plan you might use for globals. >>There is no common site-local prefix shared across the site. >>Site-local addresses prefixes are constructed without manual >>configuration. >> >>For each link, a router may automatically assign a site-local >>address from an EUI-48 (ie a MAC address) using the following >>address format: >> >> | 12 bits | 48 bits | 4 bits | 64 bits | >> +---------+------------------+----------+----------------------+ >> | fef | router device ID | sub ID | machine interface ID | >> +---------+------------------+----------+----------------------+ >> Figure 1: Address Format: fef0::/12 >> >>There is no 16 bit SLA subnet number to be managed! >> >>A router gets 16 subnets per EUI-48. It can use those to number >>links without ethernet or similar chips with 48 bit MAC addresses. >> >>Links with more than one router can have more than one automatically >>allocated site-local prefix. IPv6 supports that just fine. >> >>If you don't like sharing the existing site-local space with non-/48 >>addressing format we can use a different prefix, say fe00::/10. >>That has the advantage of increasing to 6 the number of sub ID bits. >> >>- aidan >> >>Michel Py wrote: >> >>>Administrative nightmare. This one of these things in IPv6 where there >>>is an explicit trade-off between allocation efficiency and simplicity. >>> >>>I agree that the 54 subnet bits we have for site-locals today is >>>overkill, but anything less than 16 subnet bits is not good. >>> >>>In the case you have both site-local and global at the same time, you >>>want to maintain subnet numbers: >>> >>>2001:YOUR:BLOC:BEEF:INTE:RFAC:E_IDE:NTIF >>>FEC0:0000:0000:BEEF:INTE:RFAC:E_IDE:NTIF >>> ^^^^ >>> Maintain subnet number >>> >>>Given the room we have in FEC0::/10, I don't see a reason to do >>>otherwise. >>> >>>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 Nov 28 22:23:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAT6NPUu008916; Thu, 28 Nov 2002 22:23:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAT6NPx7008915; Thu, 28 Nov 2002 22:23: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAT6NMUu008908 for ; Thu, 28 Nov 2002 22:23:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAT6NSbB015990 for ; Thu, 28 Nov 2002 22:23:28 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA25350 for ; Thu, 28 Nov 2002 23:23:22 -0700 (MST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 28 Nov 2002 22:23:20 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 28 Nov 2002 22:23:20 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Thu, 28 Nov 2002 22:23:19 -0800 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); Thu, 28 Nov 2002 22:23:20 -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.3710.0); Thu, 28 Nov 2002 22:23:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: GUSL proposal (very crude) Date: Thu, 28 Nov 2002 22:23:20 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GUSL proposal (very crude) Thread-Index: AcKWfUWS+rGFpyduTZGWHF3wtr78NAABkxdwADp3ZQ8= From: "Christian Huitema" To: "Michel Py" , "Margaret Wasserman" Cc: "Bob Hinden" , "IPng Working Group" X-OriginalArrivalTime: 29 Nov 2002 06:23:15.0069 (UTC) FILETIME=[CCAA92D0:01C2976F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAT6NMUu008909 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is a sense of deja vu in all this discussion -- similar proposals of making SL more unique by somehow sticking an identifier in the 38 available bits have popped out every 2 years on the list since 1994; I have to plead guilty, since I have indeed been one of the proponents. > There is a need for three types of allocation: > - Free, automated configuration, no registration, > no external connection, almost unique. > - Free, manual or semi-automatic configuration, > no registration, Internet connection necessary > for semi-automatic configuration, unique. > - Fee-based, manual registration, unique. > Additonal properties TBD. I don't understand the intermediate category, and specifically the implementation as: > 1.2.2 Unregistered, free, unique, sequentially allocated. Unique and sequential is contradictory with unregistered. I understand that we could implement a web site that distributes sequential numbers, although it is not clear that we can run a web site that runs a strictly sequential counter efficiently; you will probably need to loosen the sequential requirement to allow for a parallel implementation. But in the absence of registration there is a big risk that poorly written implementations will get a new number each time they boot. In fact, there is also a big risk that a denial of service attack brings the system down. I would personally go for a simpler scheme: 1 bit for random/registered, and a controlled registration process to remove doubts. By the way, I would also probably reserve a /16 prefix for a special class of 32 bits identifiers, the alreday allocated IPv4 addresses. -- 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 Nov 29 02:32:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATAWdUu009528; Fri, 29 Nov 2002 02:32:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gATAWdm2009527; Fri, 29 Nov 2002 02:32: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATAWaUu009520 for ; Fri, 29 Nov 2002 02:32:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gATAWjbB011594 for ; Fri, 29 Nov 2002 02:32:45 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA29381 for ; Fri, 29 Nov 2002 03:32:32 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id CAA09262; Fri, 29 Nov 2002 02:31:58 -0800 (PST) Message-Id: <5.1.0.14.0.20021129052514.0307f480@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 29 Nov 2002 05:31:44 -0500 To: awhite@arc.corp.mot.com From: Margaret Wasserman Subject: Re: globally unique site local addresses Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3DE3178F.83071AA3@motorola.com> References: <200211260104.gAQ14Bl13677@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Andrew, 4 or 6 subnet bits are not sufficient for most uses. It is expected that these addresses will be used for internal numbering within an enterprise, so we should, at minimum, leave room for a 16-bit subnet ID. This would allow the same subnet numbers to be used for global and local subnets. So, it doesn't seem likely that we can auto-generate globally unique addresses within the FECO::/10 space, unless we can determine a mechanism for routers to obtain globally unique identifiers that are no longer than 38-bits. One or more people have made proposals on the list for mechanisms to generate mostly-unique addresses in the FECO::/10 range, based on hashes of the EUI-64, among other things... Hopefully one of those people will fully document such a proposal in an I-D, so that we can discuss it in detail. Margaret At 05:41 PM 11/26/2002 +1100, Andrew White wrote: >Some thoughts: > >As a method of doing globally unique site local addressing: > >Assuming aggregability is not an issue within a 'site' sized network, >consider generating site local subnet identifiers at the router, based on >IEEE EUI-48 identifiers (such as MAC addresses). > >For example, generate as fec0::/12: > >12 bits: fef >48 bits: MAC > 4 bits: 0 or subnets > >or, if we don't want them in fec0::/10 > >10 bits: fe0 >48 bits: MAC > 6 bits: 0 or subnets > >The '0 or subnets' is to allow for the possibility of choosing one EUI-48 on >a router and using that to allocate all appropriate subnets. > >By piggybacking on the existing registration scheme, we generate "unique" >site-local subnet ids at the router without needing external registration or >administration. > >Despite the zero-config nature of this, administration on the router is >still necessary, both to enable this mode (probably don't want site-local >behaviour enabled by default) and to determine whether a router is >authoritative for the link. An administrator may wish to configure a >multi-router link with the subnet prefix of only one router. > >An internet-draft describing this in more detail is written and will be >submitted in the next day or so. Comments welcome. > > >Another comment on uniqueness: > >Under IPv6, even an ambiguous prefix is likely to not resolve to an address >because of the MAC generated machine id, so the likelihood of collision is >lower than might be expected from the prefix. > > >Final thought: > >Whatever the outcome of the site local discussions, renumbering will remain >a serious problem under IPv6, that needs to be considered. Making >renumbering easier is a hard problem, but a good solution will help reduce a >variety of other problems. > >-- >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 Fri Nov 29 03:27:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATBRMUu009863; Fri, 29 Nov 2002 03:27:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gATBRL2P009862; Fri, 29 Nov 2002 03:27:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATBRIUu009855 for ; Fri, 29 Nov 2002 03:27:18 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gATBRSMq005406 for ; Fri, 29 Nov 2002 03:27:28 -0800 (PST) Received: from n97.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18916 for ; Fri, 29 Nov 2002 04:27:22 -0700 (MST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by n97.nomadiclab.com (Postfix) with ESMTP id 823671C; Fri, 29 Nov 2002 13:34:24 +0200 (EET) Message-ID: <3DE74F1B.2030804@nomadiclab.com> Date: Fri, 29 Nov 2002 13:27:23 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021127 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Smith Cc: ipng@sunroof.eng.sun.com Subject: Re: The future of connectivity, or how globally unique site locals may become almost obsolete. References: <1038472380.17242.221.camel@dupy> In-Reply-To: <1038472380.17242.221.camel@dupy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark, Mark Smith wrote: > 5.1 The above assumes that organisations don't immediately deploy true > end-to-end, opportunistic transport mode IPsec between nodes. That being > said, if they did deploy end-to-end opportunistic transport mode IPsec, > they still can't use site-local addressing when communicating over the > Internet. Well, if the site-local addresses are globally unique, it actually *is* possible to use them internally in the hosts as you communicate over the Internet using a end-to-end IPsec tunnel. You just need some more intelligence and a translation that is very similar to Bellovin's host NAT. In such a case the site-local globally unique addresses would act as end-point identifiers, and they would never be seen in the wire. The hosts would themselves translate them into "normal" IP addresses as a part of IPsec processing. The benefit is that the static global "addresses" protect the applications form address changes caused by mobility, multi-homing and renumbering. From one point of view, that's the essense of HIP backward compatibility mode. You use global, statistically unique identifiers instead of IP addresses at the application layer, map these to IPsec SAs, and then use normal IP addresses when communicating over the internet. Host ID -> SA -> current IP address(es) of the peer The details are in Bob Moskowitz's HIP drafts. > 5.2 I've been meaning to look into whether the ipsec working group have > done any work on anything similar to my "bump-in-the-wire transport mode > pseudo tunnle" ipsec model but haven't got around to it. I've been > intending bring this up in that working group if they haven't. I've been > a bit busy recently organising an interstate move unfortunately. The HIP people have been discussing a "HIP gateway" which would be functionally more-or-less identical to your bump-in-the-wire pseudo-tunnel. Not quite, but close. Furthermore, if we changed the HIP specs so that there was an SL/GUPI compatible wire format for Host Identifiers, the "HIP gateway" would become even close to your bump-in-the-wire pseudo-tunnel, though with an interesting twist.... --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 08:53:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATGrVUu010816; Fri, 29 Nov 2002 08:53:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gATGrULS010815; Fri, 29 Nov 2002 08:53:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATGrRUu010808 for ; Fri, 29 Nov 2002 08:53:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gATGrbbB024028 for ; Fri, 29 Nov 2002 08:53:37 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01034 for ; Fri, 29 Nov 2002 09:53:31 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA17093; Fri, 29 Nov 2002 08:52:51 -0800 (PST) Message-Id: <5.1.0.14.0.20021129114311.0307f7a8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 29 Nov 2002 11:48:50 -0500 To: Mark.Andrews@isc.org From: Margaret Wasserman Subject: Re: even one reason why provably unique SL is needed? Cc: Keith Moore , Pekka Savola , ipng@sunroof.eng.sun.com In-Reply-To: <200211252100.gAPL0CSd006358@drugs.dv.isc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > "nearly unique" is not good enough. You want to be able to > register these addresses in the ip6.arpa tree. Do you? How does this fit with the concept that unreachable addresses should not be included in the DNS? As soon as we have any sort of private addressing (VPNs, firewalls or any type of site-local addressing, I think we're stuck with some sort of split DNS that includes local addresses in local name lookups, but not in global ones, right? Is the reverse look-up tree an exception to this? I suppose it would have to be, if you want people from outside the site to be able to identify the source of a leaked address... But, it's not clear how this would work with mostly-unique addresses. > What does work is having truly unique addresses and delegating > the reverse servers. Yes. Truly unique addresses are better for including in the reverse DNS, even if they aren't routed globally. They also have the advantage that if there is an overlap that is causing problems, it is possible to find out what organization is actually registered to use that prefix. But, are these (fairly minor) benefits worth the cost of requiring a registry, 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 Fri Nov 29 10:23:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATINcUu011059; Fri, 29 Nov 2002 10:23:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gATINcbh011058; Fri, 29 Nov 2002 10:23: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATINZUu011051 for ; Fri, 29 Nov 2002 10:23:35 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gATINibB005549 for ; Fri, 29 Nov 2002 10:23:44 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07493 for ; Fri, 29 Nov 2002 10:23:39 -0800 (PST) Subject: RE: GUSL proposal (very crude) Date: Fri, 29 Nov 2002 10:23:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B04640BD491@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: GUSL proposal (very crude) Thread-Index: AcKXLW0qTDeFiEzLSGSnSoxh8n9YIAApqTxQ From: "Michel Py" To: "Mark Smith" Cc: "Brian Carpenter" , "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gATINZUu011052 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark, > Mark Smith wrote: > Playing the devils advocate .... > Michel, can you describe, in a real world, nuts and > bolts manner, where your "site" boundary would be. I have tried to address this in the GUSL draft (under co-author review, link to be posted ASAP) Follows is the tentative text. Michel. 0. Meaning of "site" The word "site" appears to be understood differently by the community than it is loosely defined in [ADDRARCH]: > [ADDRARCH] > A "site" is, by intent, not rigorously defined, but is typically > expected to cover a region of topology that belongs to a single > organization and is located within a single geographic location, > such as an office, an office complex, or a campus. A personal > residence may be treated as a site (for example, when the > residence obtains Internet access via a public Internet service > provider), or as a part of a site (for example, when the residence > obtains Internet access via an employer's or school's site) It appears that "site" is used by the community as a shorter form of "end site" as described in [IPV6ASSIGN]. By extension, "site" has largely been used as a synonymous of "/48" and assimilated to the administrative boundaries of the organization being assigned an end-site prefix. This document uses "site" having the same meaning as "end site" as described in [IPV6ASSIGN]. [ADDRARCH] Deering, S. and R. Hinden, "IP Version 6 Addressing Architecture", http://www.ietf.org/internet-drafts/draft-ietf-ipngwg- addr-arch-v3-11.txt, October 2002. [IPV6ASSIGN] APNIC, ARIN, RIPE-NCC, "IPv6 Address Allocation and Assignment Assignment Policy", June 26, 2002. ftp://ftp.cs.duke.edu/pub/narten/global-ipv6-assign-2002-06-26.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 Fri Nov 29 10:24:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATIOKUu011076; Fri, 29 Nov 2002 10:24:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gATIOKna011075; Fri, 29 Nov 2002 10:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATIOHUu011068 for ; Fri, 29 Nov 2002 10:24:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gATIORMq021940 for ; Fri, 29 Nov 2002 10:24:27 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00881 for ; Fri, 29 Nov 2002 11:24:21 -0700 (MST) Subject: RE: GUSL proposal (very crude) Date: Fri, 29 Nov 2002 10:24:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405E4F3@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: GUSL proposal (very crude) Thread-Index: AcKWfUWS+rGFpyduTZGWHF3wtr78NAABkxdwADp3ZQ8AGK//IA== From: "Michel Py" To: "Christian Huitema" , "Margaret Wasserman" Cc: "Bob Hinden" , "IPng Working Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gATIOHUu011069 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, > Christian Huitema wrote: > There is a sense of deja vu in all this discussion. Indeed. I think that one of the reasons former proposals have failed is because there was no enforcement of non-routability in the public Internet, if my memory is correct. >> There is a need for three types of allocation: >> - Free, automated configuration, no registration, >> no external connection, almost unique. >> - Free, manual or semi-automatic configuration, >> no registration, Internet connection necessary >> for semi-automatic configuration, unique. >> - Fee-based, manual registration, unique. >> Additonal properties TBD. > I don't understand the intermediate category, and > specifically the implementation as: >> 1.2.2 Unregistered, free, unique, sequentially allocated. > Unique and sequential is contradictory with unregistered. There is a difference between registered and centrally controlled. Both require access to a server that guarantees uniqueness. Unregistered means that the requester does not have to provide any information. I thought about using "anonymous registration" but there is no info to register. The sequential server would not keep track of registrations for more than 24 hours, I think. > it is not clear that we can run a web site that runs a strictly > sequential counter efficiently; you will probably need to loosen > the sequential requirement to allow for a parallel implementation. This is easy, just split the address range reserved for this purpose for multiple servers. > But in the absence of registration there is a big risk that poorly > written implementations will get a new number each time they boot. I have addressed this in the draft to come. It's under co-author review and I will post a link ASAP. > In fact, there is also a big risk that a denial of service attack > brings the system down. Not that much of a big deal. DOS do not last forever. The case that uses access to the GUSL server is manual configuration initiated by the administrator. If the GUSL server is unreachable, the administrator can settle for a hash generated prefix to get his network going and try again the next day. Beside, the savvy administrator would have obtained the prefix *before* configuring the router. > I would personally go for a simpler scheme: 1 bit for > random/registered, and a controlled registration process > to remove doubts. Problem is this won't be free, are there any takers to do it for free? > By the way, I would also probably reserve a /16 prefix for a > special class of 32 bits identifiers, the alreday allocated > IPv4 addresses. You mean, something like FEFE:IPV4:ADDR:, similar to 6to4 mechanism? It crossed my mind, what worries in doing this is that people will hijack non-portable IPv4 addresses as well as legitimately using portable ones. 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 Nov 29 12:03:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATK3YUu011581; Fri, 29 Nov 2002 12:03:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gATK3Y9Y011580; Fri, 29 Nov 2002 12:03: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATK3UUu011573 for ; Fri, 29 Nov 2002 12:03:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gATK3dbB017912 for ; Fri, 29 Nov 2002 12:03:39 -0800 (PST) Received: from galactica.it ([212.41.208.18]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28158 for ; Fri, 29 Nov 2002 13:03:33 -0700 (MST) Received: from mail pickup service by galactica.it with Microsoft SMTPSVC; Fri, 29 Nov 2002 19:38:17 +0100 Received: from Flemming.computer.org ([206.99.235.24]) by galactica.it with Microsoft SMTPSVC(5.5.1877.537.53); Fri, 29 Nov 2002 07:33:18 +0100 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by Flemming.computer.org (Switch-2.2.1/Switch-2.2.1) with ESMTP id UAT60YA815388 for ; Fri, 29 Nov 2002 01:34:10 -0500 Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20768; Thu, 28 Nov 2002 22:25:10 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAT6NsNG001997; Thu, 28 Nov 2002 22:25:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAT6NPUu008916; Thu, 28 Nov 2002 22:23:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAT6NPx7008915; Thu, 28 Nov 2002 22:23: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAT6NMUu008908 for ; Thu, 28 Nov 2002 22:23:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAT6NSbB015990 for ; Thu, 28 Nov 2002 22:23:28 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA25350 for ; Thu, 28 Nov 2002 23:23:22 -0700 (MST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 28 Nov 2002 22:23:20 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 28 Nov 2002 22:23:20 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Thu, 28 Nov 2002 22:23:19 -0800 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); Thu, 28 Nov 2002 22:23:20 -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.3710.0); Thu, 28 Nov 2002 22:23:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: GUSL proposal (very crude) Date: Thu, 28 Nov 2002 22:23:20 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GUSL proposal (very crude) Thread-Index: AcKWfUWS+rGFpyduTZGWHF3wtr78NAABkxdwADp3ZQ8= From: "Christian Huitema" To: "Michel Py" , "Margaret Wasserman" Cc: "Bob Hinden" , "IPng Working Group" X-OriginalArrivalTime: 29 Nov 2002 06:23:15.0069 (UTC) FILETIME=[CCAA92D0:01C2976F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id gAT6NMUu008909 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is a sense of deja vu in all this discussion -- similar proposals of making SL more unique by somehow sticking an identifier in the 38 available bits have popped out every 2 years on the list since 1994; I have to plead guilty, since I have indeed been one of the proponents. > There is a need for three types of allocation: > - Free, automated configuration, no registration, > no external connection, almost unique. > - Free, manual or semi-automatic configuration, > no registration, Internet connection necessary > for semi-automatic configuration, unique. > - Fee-based, manual registration, unique. > Additonal properties TBD. I don't understand the intermediate category, and specifically the implementation as: > 1.2.2 Unregistered, free, unique, sequentially allocated. Unique and sequential is contradictory with unregistered. I understand that we could implement a web site that distributes sequential numbers, although it is not clear that we can run a web site that runs a strictly sequential counter efficiently; you will probably need to loosen the sequential requirement to allow for a parallel implementation. But in the absence of registration there is a big risk that poorly written implementations will get a new number each time they boot. In fact, there is also a big risk that a denial of service attack brings the system down. I would personally go for a simpler scheme: 1 bit for random/registered, and a controlled registration process to remove doubts. By the way, I would also probably reserve a /16 prefix for a special class of 32 bits identifiers, the alreday allocated IPv4 addresses. -- 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 13:29:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATLTIUu012852; Fri, 29 Nov 2002 13:29:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gATLTIR7012851; Fri, 29 Nov 2002 13:29: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gATLTFUu012844 for ; Fri, 29 Nov 2002 13:29:15 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gATLTPMq017297 for ; Fri, 29 Nov 2002 13:29:25 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03279 for ; Fri, 29 Nov 2002 13:29:18 -0800 (PST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id gATLSrgU027571; Sat, 30 Nov 2002 08:28:54 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200211292128.gATLSrgU027571@drugs.dv.isc.org> To: Margaret Wasserman Cc: Mark_Andrews@isc.org, Keith Moore , Pekka Savola , ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: even one reason why provably unique SL is needed? In-reply-to: Your message of "Fri, 29 Nov 2002 11:48:50 CDT." <5.1.0.14.0.20021129114311.0307f7a8@mail.windriver.com> Date: Sat, 30 Nov 2002 08:28:53 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > "nearly unique" is not good enough. You want to be able to > > register these addresses in the ip6.arpa tree. > > Do you? How does this fit with the concept that unreachable > addresses should not be included in the DNS? Well a entry in the ip6.arpa tree is *not* an *address*. As for the forward entries the important thing is not to publish ambigious addresses. It really does not matter if you publish unreachable addresses especially if you have sorting rules which allow you to have a better than 50/50 chance (with two address) of making a connection the first time. This requires that the local resolver has some sorting rules which are required by RFC 103[45]. e.g. local sites first, then globals, then other sites. local sites first defaults the sites the machine is in but may be expanded to known locally connected sites. > As soon as we have any sort of private addressing (VPNs, firewalls > or any type of site-local addressing, I think we're stuck with some > sort of split DNS that includes local addresses in local name lookups, > but not in global ones, right? No. You are stuck with split DNS if you have ambigious addresses. You might have connection delays if you don't have good local policy to choose the right address but unless the application is broken you will get a connection. > Is the reverse look-up tree an exception to this? I suppose it would > have to be, if you want people from outside the site to be able to > identify the source of a leaked address... But, it's not clear how > this would work with mostly-unique addresses. It won't work with mostly-unique addresses and the addresses will leak and we will have to set up sacrificial servers to save the ip6.arpa servers like we currently hace sacrificial servers to save the in-addr.arpa servers. > > What does work is having truly unique addresses and delegating > > the reverse servers. > > Yes. Truly unique addresses are better for including in the reverse > DNS, even if they aren't routed globally. They also have the advantage > that if there is an overlap that is causing problems, it is possible > to find out what organization is actually registered to use that prefix. > > But, are these (fairly minor) benefits worth the cost of requiring a > registry, etc? Yes. Look at the current costs of supporting the sacrificial servers for RFC 1918 addresses. These servers get more queries per second than the root servers. Do we want to have to run sacrificial servers forever? Also you don't force a organization to do its DNS in-house. It can out-source its DNS maintenance if it wants to if you have truly unique addresses. Given the level of compentance I see with the DNS today out-sourcing is a good thing. Mark > Margaret -- 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 Sat Nov 30 05:09:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAUD94Uu014875; Sat, 30 Nov 2002 05:09:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAUD94HJ014874; Sat, 30 Nov 2002 05:09: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAUD91Uu014867 for ; Sat, 30 Nov 2002 05:09:01 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAUD9BbB026815 for ; Sat, 30 Nov 2002 05:09:11 -0800 (PST) Received: from mail.iwavesystems.com (iwave-54-144-ban.iwavesystems.com [203.196.144.54] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02925 for ; Sat, 30 Nov 2002 05:09:03 -0800 (PST) Received: from iwave005 (ns1.iwave.net [203.196.144.50]) by mail.iwavesystems.com (8.12.4/) with SMTP id gAUD3wRj023909 for ; Sat, 30 Nov 2002 18:34:06 +0530 Message-ID: <00fa01c29872$32d41a10$a602a8c0@iwave005> From: "Rashmi" To: Subject: test message Date: Sat, 30 Nov 2002 18:42:43 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F7_01C298A0.44E93A40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Scanned: Message: ok X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.14 (www dot roaringpenguin dot com slash mimedefang) X-Filter-Version: 1.4.5 (mail.iwavesystems.com) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00F7_01C298A0.44E93A40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable pls ignore this message. DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. ------=_NextPart_000_00F7_01C298A0.44E93A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
pls ignore this = message.

DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation.

------=_NextPart_000_00F7_01C298A0.44E93A40-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 30 14:01:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAUM1AUu015738; Sat, 30 Nov 2002 14:01:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAUM1ABV015737; Sat, 30 Nov 2002 14:01: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAUM17Uu015730; Sat, 30 Nov 2002 14:01:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAUM19Mq019282; Sat, 30 Nov 2002 14:01:09 -0800 (PST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22994; Sat, 30 Nov 2002 15:01:03 -0700 (MST) Message-ID: <008e01c298bb$c3d9eaa0$096015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Samita Chakrabarti" Cc: , , References: <200211250517.gAP5Hcml181355@jurassic.eng.sun.com> Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection Date: Sat, 30 Nov 2002 13:58:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Or, don't change the getsockname(), but instead call > > mip_get_one_mobile_node() afterwards to identify if the address is bound > > to a care-of address. Note that this binding can dynamically any time, > > and subsequent mip_get_one_mobile_node() calls are sufficient to capture > > the changes. > > I'd say for connected and bound sockets, getsockname() would return the > correct topological source address. But that'd break the getsockname() function, which should return the local binding of the socket. If the socket is bound to a home address, that address should be returned by the function, even though it might be also (Mobile IP-)bound to a care-of address. 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 Sat Nov 30 14:24:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAUMOSUu016059; Sat, 30 Nov 2002 14:24:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAUMORZA016058; Sat, 30 Nov 2002 14:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAUMOJUu016043; Sat, 30 Nov 2002 14:24:19 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAUMOTbB019249; Sat, 30 Nov 2002 14:24:29 -0800 (PST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15080; Sat, 30 Nov 2002 14:24:24 -0800 (PST) Message-ID: <009101c298bf$01e81e40$096015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Samita Chakrabarti" , Cc: , , References: <200211250527.gAP5RZml182697@jurassic.eng.sun.com> Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to switch default source address selection Date: Sat, 30 Nov 2002 14:22:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > A simple api ext doc would be great. But not part of the advanced api. > > We need to ship the base and advanced apis now. I completely agree. > That's what I was aiming for; a short and simple advanced api socket > extension doc as a guideline for MIPv6 compatible applications. The default address selection draft contemplates about such an API: Implementations should provide a mechanism allowing an application to reverse the sense of this preference and prefer care-of addresses over home addresses (e.g., via appropriate API extensions). Use of the mechanism should only affect the selection rules for the invoking application. I think we should work on a separate Mobile IP API, that can encompass this and more. alper > I agree that the server side apps do not require change, but some > client side apps should change (like dns-client, printer-client etc.) > so that they don't have to send packets all the way to the home-agent > for doing the local job. > > Thanks for your comments. > -Samita > > > > > > > > -----Original Message----- > > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > > Sent: Thursday, November 21, 2002 9:49 PM > > > To: Francis Dupont > > > Cc: Samita Chakrabarti; ipng@sunroof.eng.sun.com; > > > mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] Re: Proposal for MIPv6 APIs to > > > switch default source address selection > > > > > > > > > > > > > > > > In your previous mail you wrote: > > > > > > > > An alternative approach could be: If the application cares about > > > > the source address, it can use the Mobile IP API to > > > figure out which > > > > ones are home address, which ones are care-of address, and than > > > > explicitly "bind" the socket to the desired address. > > > IMO, this would > > > > also satisfy the needs of the Mobile IPv6 mobile node. > > > > > > > > => this is similar to what I implemented in the past. > > > > But a function giving the list of addresses with status is > > > not enough, > > > > the best is to give the home address and the care-of address for a > > > > destination. > > > > > > I see. When the mobile node has more than one pair of > > > home_address-care_of_address, then it won't really know which > > > one to pick. So, maybe, instead of exporting all this > > > information to the apps and giving them the control, it might > > > be better > > > to enable the app to say "bind this socket to any address, > > > preferably topologically correct (i.e., a CoA, or home > > > address when at home)". I suspect this is what Samita had in > > > her mind.. > > > > > > > As first info is getsockname() for bound sockets, > > > > I added a clone of getsockname() which returns the real > > > source address > > > > after MIPv6 processing. > > > > > > Or, don't change the getsockname(), but instead call > > > mip_get_one_mobile_node() afterwards to identify if the > > > address is bound to a care-of address. Note that this binding > > > can dynamically any time, and subsequent > > > mip_get_one_mobile_node() calls are sufficient to capture the changes. > > > > > > alper > > > > > > > Note this doesn't solve the need of a control for smarter choice > > > > between Co@/H@. I proposed some and implemented two: use > > > always the H@ > > > > and use it but a Co@ when the destination is in the same > > > link then a > > > > Co@. They were global (still better than none :-). > > > > > > > > Thanks > > > > > > > > Francis.Dupont@enst-bretagne.fr > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 30 15:36:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAUNaVUu016434; Sat, 30 Nov 2002 15:36:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gAUNaVDg016433; Sat, 30 Nov 2002 15:36: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAUNaSUu016426 for ; Sat, 30 Nov 2002 15:36:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gAUNacMq028463 for ; Sat, 30 Nov 2002 15:36:38 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18322 for ; Sat, 30 Nov 2002 16:36:32 -0700 (MST) Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA18764; Sat, 30 Nov 2002 15:35:47 -0800 (PST) Message-Id: <5.1.0.14.0.20021130182653.032cde90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 30 Nov 2002 18:35:31 -0500 To: Kurt Erik Lindqvist From: Margaret Wasserman Subject: Re: "unique enough" [RE: globally unique site local addresses] Cc: "Michel Py" , "Pekka Savola" , "Christian Huitema" , In-Reply-To: References: <5.1.0.14.0.20021123204700.02221ab8@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 > >What I am failing to understand is what we are looking for. The letter>GUPI model will drive the development of NATs. Why do you think so? In particular, why do you think that GUPI addresses would drive the development of NATs any more than the current IPv6 site-local addresses? Do you really think that it is realistic to just tell everyone to use provider-assigned addresses throughout their network? We've been getting feedback from network administrators that they need a form of local addressing that allows their internal numbering, firewall configuration, etc. to be independent of their ISP-provided addresses. People want to use site-locals for this, but the ambiguity of site-locals causes all sorts of problems for applications, routing protocols, transport protocols, etc. especially when running on site border nodes (nodes that are in more than one site at the same time). It is my belief that if we ignore this problem, and simply limit site- locals to disconnected networks (a la RFC 1918 addresses), then IPv6 NAT will arise to allow sites to separate internal addressing from external addressing. What we really need is a better way to solve this problem, one that doesn't have the problems of site-local addresses. And, that's why we're discussing GUPI addresses. Is there a better way to solve this problem that we haven't considered? 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 Nov 30 19:24:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gB13O8Uu016882; Sat, 30 Nov 2002 19:24:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gB13O7Xn016881; Sat, 30 Nov 2002 19:24: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gB13O4Uu016874 for ; Sat, 30 Nov 2002 19:24:04 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gB13OEMq021916 for ; Sat, 30 Nov 2002 19:24:14 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18172 for ; Sat, 30 Nov 2002 20:24:08 -0700 (MST) Subject: RE: "unique enough" [RE: globally unique site local addresses] Date: Sat, 30 Nov 2002 19:24:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046405E4F9@server2000> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: "unique enough" [RE: globally unique site local addresses] Thread-Index: AcKYyXPpE6y3m61nQ3KAe4rDfxnuKgAA+0ng 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 gB13O4Uu016875 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Margaret Wasserman wrote: > Do you really think that it is realistic to just tell > everyone to use provider-assigned addresses throughout > their network? No. Scores won't buy it. Let's not forget that one of the reasons behind the considerable success of NAT, despite its huge annoyances, it because NAT does provide some of the PI perks. PA is good for dial-up users and home/soho setups. Bigger, you find NAT, because for many the no-sweat ISP switch is worth more than the NAT-induced problems. In my experience, the number one reason for going to RFC1918/NAT is an ISP change. The ISP pulls out of a market or tanks, the customer looks at my proposal for renumbering, chokes at the bottom line, and says "make sure we don't have to go through this again next time the ISP bellies up". Welcome to NAT. Having two of the tier-1 ISPs in bankruptcy does not help this feeling. > We've been getting feedback from network administrators that > they need a form of local addressing that allows their > internal numbering, firewall configuration, etc. to be > independent of their ISP-provided addresses. Network administrators want three things: 1. Local, private addresses that do not communicate outside of their site. Site-locals are perfect for this, if they are not limited to disconnected sites. 2. Unique addresses that do not need public Internet access but do need to communicate with selected external sites (example customer/supplier VPN). This is GUPI. 3. Global network layer PI identifiers. Although this is not directly linked to the multihoming issue, it is likely that a scalable multihoming solution would provide it. I do not envision a large-scale deployment of IPv6 without providing all three. Also, it would be a hell of a good idea if 2. could migrate to 3. > It is my belief that if we ignore this problem, and simply > limit site-locals to disconnected networks (a la RFC 1918 > addresses), then IPv6 NAT will arise to allow sites to > separate internal addressing from external addressing. Agreed. And we should not underestimate the danger of this, as there is a lot of working v4 NAT code out there and transforming v4 NAT code into v6 NAT code is a lot less work that writing NAT from scratch 5 years ago. Most of the ALGs issues have been sorted out already. > What we really need is a better way to solve this problem, > one that doesn't have the problems of site-local addresses. > And, that's why we're discussing GUPI addresses. Agreed. Unfortunately, one of the main issues with GUPI addresses is managing the risk they end up being a mess in the global routing table, à la IPv4 swamp. So far, the lack of a multihoming solution has been a strong enough disincentive to kill GUPI attempts in the egg before they were even born. Any GUPI proposal will have to address this. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 30 22:11:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gB16BhUu017316; Sat, 30 Nov 2002 22:11:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0/Submit) id gB16Bhlt017315; Sat, 30 Nov 2002 22:11: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.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gB16BeUu017308 for ; Sat, 30 Nov 2002 22:11:40 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gB16BoMq005544 for ; Sat, 30 Nov 2002 22:11:50 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26119 for ; Sat, 30 Nov 2002 23:11:44 -0700 (MST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id gB16BWM12640; Sat, 30 Nov 2002 22:11:32 -0800 (PST) From: Bill Manning Message-Id: <200212010611.gB16BWM12640@boreas.isi.edu> Subject: Re: even one reason why provably unique SL is needed? In-Reply-To: <1038345488.1458.439.camel@dupy> from Mark Smith at "Nov 27, 2 08:18:07 am" To: ipv6@nosense.org (Mark Smith) Date: Sat, 30 Nov 2002 22:11:32 -0800 (PST) Cc: smb@research.att.com, itojun@iijlab.net, 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 I did this once upon a time, when I held the authoritative delegations for the RFC 1918 space. Unfortunately, I waited two years before adding the entries. by then, routes had leaked and we had 100's of sites (generally corporations) have their internal SNMP-based monitoring systems collapse into a single data point that read "read-rfc1918-for details." The calls were... "energetic" and the DNS entries were removed within a few hours. If we are going to take this tactic, doing from the getgo is the right thing to do. May I do this for the ip6.int space? % I like it :-) % % % % On Wed, 2002-11-27 at 07:57, Steven M. Bellovin wrote: % > In message <20021126020443.BE0444B22@coconut.itojun.org>, itojun@iijlab.net wr % > i % > tes: % > >>>Require the DNS server at the edge of the site be authoritative for the % > >>>whole of fec0::/10 or blackhole the queries. % > >>> % > >>>(I don't think too many people would even want to register site-locals in % > >>>the _global_ reverse DNS, queriable by anyone -- remember, they're not to % > >>>be used globally, and reverses in and itself are already considered a % > >>>"security hazard" by some.) % > >>> % > >>>Let's not go down the path of putting site-locals anywhere near the global % > >>>ip6.arpa. % > >> % > >>Sure -- but to keep the load off the root, we need to be *very* sure % > >>that sites do pretend to be authoritative for them. % > > % > > will it help if we ship c.e.f.ip6.int/arpa zone files with BIND, % > > just like 1.0.0.127.in-addr.arpa? % > % > Thinking about it a little more, there's a seriously obscene thing % > to do here: ship the config files with a * PTR record, resolving to % > something like "read.RFC.1918.for.these.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 % > -------------------------------------------------------------------- % % % % -------------------------------------------------------------------- % IETF IPng Working Group Mailing List % IPng Home 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 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------