From owner-ipng@sunroof.eng.sun.com Sun Jun 1 20:35:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h523ZATX026973; Sun, 1 Jun 2003 20:35:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h523ZAKk026972; Sun, 1 Jun 2003 20:35:10 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h523Z7TX026965 for ; Sun, 1 Jun 2003 20:35:07 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h523XQuc028007 for ; Sun, 1 Jun 2003 20:33:26 -0700 (PDT) Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h523XKht019363 for ; Sun, 1 Jun 2003 21:33:20 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KWMCVAA3XG9B42YC@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Mon, 2 Jun 2003 13:29:58 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id EAF3A12C007; Mon, 02 Jun 2003 13:29:56 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id CE8D812C00D; Mon, 02 Jun 2003 13:29:56 +1000 (EST) Date: Mon, 02 Jun 2003 13:29:56 +1000 From: Greg Daley Subject: Re: Misusing registries for uniqueness (was Re: Draft on Globally Unique IPv6 Local Unicast Addresses) To: Robert Elz Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EDAC4B4.4060703@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3ED6F3AB.6050003@eng.monash.edu.au> <20030527193820.GA6652@fysh.org> <2377861193.1054241155@hkruse.csm.ohiou.edu> <1054272212.1703.15.camel@vega.amorsen.dk> <9764.1054285740@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, Robert Elz wrote: > Date: Fri, 30 May 2003 16:01:15 +1000 > From: Greg Daley > Message-ID: <3ED6F3AB.6050003@eng.monash.edu.au> > > | It's not that dumb an idea, it reminds me of > | base-85 (RFC-1924) IPv6 addressing notation. > > Which is a joke, not an idea (dumb or otherwise)... I know :) I live in the same city as you, word spreads. > | It certainly does solve the uniqueness issue > | for any given instant. What happens if you > | 're-number' your telephone? > > This has the same problem as MAC addresses - it isn't stable (someone > else can quite validly end up with the number that used to be yours). Indeed. Similar issues exist with geographically generated private addressing schemes: that land occupancy or ownership is finite time (sometimes very short in terms of the Internet's life). > But, if abusing number spaces to try and gain easier uniqueness is > an aim, then a (less automatic but perhaps still reasonable) method > would be to abuse the IEEE OUI space (instead of the MAC address space). > > That is, any organisation with an OUI (22 real bits big) has 18 bits > (256K) of numbers they can allocate however they see fit. And of > course, organisations that the IEEE allows can go get new numbers. > (The IETF is one such organisation of course, so IANA would have > numbers to allocate). > > (This re-use of numbers would not conflict with other uses of the OUI, > it would be in parallel, just as MAC48 and EUI-48 are - it would be > xxx-40 of course, or -45 or something, depending upon prefix length). > > Of course, IEEE would probably need to agree to their number space > being abused this way before we could suggest it as a method. > > Doing this still doesn't guarantee any kind of uniqueness, all it does > is provide a ready made answer to the "one monopoly organisation" > problem, while similtaneously making it effectively impossible for > anyone to snarf any large fraction of the address space (no need to > prescribe huge fees - like Eur 10). Umm, except the IEEE, who I'm sure are good people... I was thinking that the OUI space would be a bit of overkill for most organizations (2^18 networks is a lot). Then I looked on the IEEE website and noticed that they have already considered allocation of blocks of 4096 addresses to organizations as "Individual Address Blocks". http://standards.ieee.org/regauth/oui/index.shtml Essentially, they are 36 bit unique identifiers drawn from the OUI space. Organizations which really need a unique identifier could make use of these 36 bits to prove ownership of a MAC (only ~550USD). I'm not sure if this is palatable to the IEEE considering the somewhat stringent statement I found at: http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html "The IEEE-RAC solicits any information that poses a threat to the viability of the unique MAC-48/EUI-48/EUI-64 address space, whether an IEEE proposed standard or another standard or specification. Further, in carrying out this duty to preserve the longevity of these identifier capabilities, the RAC will act, via liaison or direct coordination, to prevent potentially abusive uses for the consumption of the OUI." Given the title of the thread, this may be worth consideration. Of course an organization may choose to purchase 2^(addrspaceprefixlen) consecutive NICs from the same manufacturer... :) Greg. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 2 14:50:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h52LowTX002100; Mon, 2 Jun 2003 14:50:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h52Lovjf002098; Mon, 2 Jun 2003 14:50:57 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h52LorTX002091 for ; Mon, 2 Jun 2003 14:50:53 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h52LnDuc015823 for ; Mon, 2 Jun 2003 14:49:13 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h52Ln8YU009559 for ; Mon, 2 Jun 2003 15:49:08 -0600 (MDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h52Ln6D25077; Mon, 2 Jun 2003 14:49:06 -0700 (PDT) Message-Id: <200306022149.h52Ln6D25077@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3542 on Advanced Sockets Application Program Interface (API) for IPv6 Cc: rfc-editor@rfc-editor.org, ipng@sunroof.eng.sun.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 02 Jun 2003 14:49:05 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3542 Title: Advanced Sockets Application Protocol Interface (API) for IPv6 Author(s): W. Stevens, M. Thomas, E. Nordmark, T. Jinmei Status: Informational Date: May 2003 Mailbox: matt@3am-software.com, Erik.Nordmark@sun.com, jinmei@isl.rdc.toshiba.co.jp Pages: 77 Characters: 173028 Obsoletes: 2292 I-D Tag: draft-ietf-ipngwg-rfc2292bis-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3542.txt This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable. This document is a product of the IP Version 6 Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030602144706.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3542 --OtherAccess Content-Type: Message/External-body; name="rfc3542.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030602144706.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 2 16:06:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h52N6YTX003499; Mon, 2 Jun 2003 16:06:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h52N6XOc003498; Mon, 2 Jun 2003 16:06:33 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h52N6UTX003491 for ; Mon, 2 Jun 2003 16:06:30 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h52N4ouc019389 for ; Mon, 2 Jun 2003 16:04:50 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h52N4j3K025496 for ; Mon, 2 Jun 2003 17:04:45 -0600 (MDT) 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 QAA01600 for ; Mon, 2 Jun 2003 16:04:44 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h52N4id08491; Mon, 2 Jun 2003 16:04:44 -0700 X-mProtect: <200306022304> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLKk7Wg; Mon, 02 Jun 2003 16:04:40 PDT Message-Id: <4.3.2.7.2.20030602111033.02326ae8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Jun 2003 16:03:31 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Status of Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [My opinions as document author] Overall I believe there is general agreement that this type of address is an improvement over site-local because the prefixes are unique. Below is my summary of conclusions reached and open issues raised on the mailing list. 1) A global-ID of 41 bits is a reasonable choice. 2) It is important to allow for /48 prefixes (with 16-bit subnet IDs) to maintain compatibility with RFC3177. 3) The central allocation proposed in the draft is OK for some situations, but there is also need for local allocation for sites who can not want to use a central allocation authority. Pseudo-random numbers is a reasonable choice for this given the field size.. The suggestion made on the list to split FC00::/7 into FC00::/8 and FD00::/8 to allow for each type of allocations is a good approach. I plan to make this change in the next version of the draft and include pseudo-code of an local allocation algorithm. Brain Haberman is helping with this text. 4) The scope of these address is smaller from global unicast address but larger than site-local. They are scoped in a different manner than link-local, site-local, and global in that the scope of an individual /48 prefix is created by a set of adhoc routing agreements and is not limited by the non-uniqueness of the prefix like site-local. From a host's perspective this difference in scope shows up by different reachability than global unicast and could be handled by default that way. It is probably better for nodes and applications to treat them differently from global unicast addresses. A starting point might be to give them preference over global unicast, but fall back to global unicast if a particular destination is found to be unreachable. Much of this behavior can be controlled by how they are allocated to nodes and put into the DNS. However it is useful if a host can have both types of addresses and use them appropriately. This creates a host with multiple global addresses, a form of multihoming. Approaches to this problem have been proposed in drafts like where a server is queried for the best source and destination address pair to reach a destination. In the long term this approach might be combined with a DNS request where the request included all of the requesters source addresses that could be used and the resolver would return the preferred source and destination addresses. This is, of course, not a trivial change to DNS but might be a reasonable approach to move forward in this area. I would proposed that the IPv6 w.g. define the address format and default node and application behavior, and leave the more ambitious address selection solutions to multi6 or other working groups as appropriate. I would appreciate your feedback and thoughts. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 2 22:50:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h535oqTX004350; Mon, 2 Jun 2003 22:50:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h535op7t004349; Mon, 2 Jun 2003 22:50:51 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h535omTX004342 for ; Mon, 2 Jun 2003 22:50:48 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h535n8Nh020408 for ; Mon, 2 Jun 2003 22:49:09 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h535n2ht011414 for ; Mon, 2 Jun 2003 23:49:03 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h535mr209437; Tue, 3 Jun 2003 08:48:54 +0300 Date: Tue, 3 Jun 2003 08:48:53 +0300 (EEST) From: Pekka Savola To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: Status of In-Reply-To: <4.3.2.7.2.20030602111033.02326ae8@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, 2 Jun 2003, Bob Hinden wrote: > 4) The scope of these address is smaller from global unicast address but > larger than site-local. They are scoped in a different manner than > link-local, site-local, and global in that the scope of an individual /48 > prefix is created by a set of adhoc routing agreements and is not limited > by the non-uniqueness of the prefix like site-local. > > From a host's perspective this difference in scope shows up by different > reachability than global unicast and could be handled by default that > way. It is probably better for nodes and applications to treat them > differently from global unicast addresses. I hope you're not implying that apps should know the difference between the two? That would be broken. The host probably could, though. > A starting point might be to > give them preference over global unicast, but fall back to global unicast > if a particular destination is found to be unreachable. Much of this > behavior can be controlled by how they are allocated to nodes and put into > the DNS. I think a better method would be to give preference to global unicast, ie., reverse the scoping rule to prefer the greatest scope. The communication would still work if a node had only local unicast addresses though, or if global addresses were blocked in a firewall etc. This is particularly important if local addresses like these are ever getting into DNS or the like. > However it is useful if a host can have both types of addresses > and use them appropriately. This creates a host with multiple global > addresses, a form of multihoming. I fail to see how a local and a global address could be considered a form of multihoming. [snip] > I would proposed that the IPv6 w.g. define the address format and default > node and application behavior, and leave the more ambitious address > selection solutions to multi6 or other working groups as appropriate. Yep. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 3 00:15:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h537FITX004652; Tue, 3 Jun 2003 00:15:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h537FIbl004651; Tue, 3 Jun 2003 00:15:18 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h537FETX004644 for ; Tue, 3 Jun 2003 00:15:14 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h537DXNh008830 for ; Tue, 3 Jun 2003 00:13:33 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h537DR3K026364 for ; Tue, 3 Jun 2003 01:13:27 -0600 (MDT) Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h537DRq9017490 for ; Tue, 3 Jun 2003 00:13:27 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h537D0VN011521 for ; Tue, 3 Jun 2003 02:13:23 -0500 Received: from motorola.com (aewhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.9/8.12.9) with ESMTP id h537D0e7026995 for ; Tue, 3 Jun 2003 17:13:00 +1000 (EST) Message-ID: <3EDC4A7B.7BB0EBA3@motorola.com> Date: Tue, 03 Jun 2003 17:12:59 +1000 From: Andrew White Reply-To: awhite@arc.corp.mot.com Organization: Motorola Australia Research Centre X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Subject: Re: Status of References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > I hope you're not implying that apps should know the difference between > the two? That would be broken. The host probably could, though. In most situations, an application would not be required to know the difference between the addresses, relying on correct behaviour of gethostbyname (destination address selection) and source address selection. However, certain applications may wish to deliberately operate at a certain scope (such as those doing ip address referrals between hosts which have local and global addresses and those which only have global addresses) and these would need to override the default address selection rules, thus being conscious of address scoping. > I think a better method would be to give preference to global unicast, > ie., reverse the scoping rule to prefer the greatest scope. On what grounds? Local scoped addresses are not mandatory, and thus should only be put in place if they are intended to be used. To my way of thinking, the presence of a locally scoped address suggests that the network is unwilling to trust the global address for local communication, and would thus expect the local address to be preferred for local-local traffic. > > However it is useful if a host can have both types of addresses > > and use them appropriately. This creates a host with multiple global > > addresses, a form of multihoming. > > I fail to see how a local and a global address could be considered a form > of multihoming. It depends on your definition of multi-homing. I've hear the term used in the following ways: - A network with access to the global internet via more than one independent path. - A node with more than one usable address (having addresses in more than one logical subnet simultaneously). The second definition is being referred to above. -- 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 Jun 3 00:31:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h537V9TX004865; Tue, 3 Jun 2003 00:31:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h537V8Tu004864; Tue, 3 Jun 2003 00:31:08 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h537V5TX004857 for ; Tue, 3 Jun 2003 00:31:05 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h537TOuc010846 for ; Tue, 3 Jun 2003 00:29:25 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h537TILv005046 for ; Tue, 3 Jun 2003 00:29:19 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h537TEv10042; Tue, 3 Jun 2003 10:29:14 +0300 Date: Tue, 3 Jun 2003 10:29:14 +0300 (EEST) From: Pekka Savola To: awhite@arc.corp.mot.com cc: IPng Subject: Re: Status of In-Reply-To: <3EDC4A7B.7BB0EBA3@motorola.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, 3 Jun 2003, Andrew White wrote: > > I hope you're not implying that apps should know the difference between > > the two? That would be broken. The host probably could, though. > > In most situations, an application would not be required to know the > difference between the addresses, relying on correct behaviour of > gethostbyname (destination address selection) and source address selection. > > However, certain applications may wish to deliberately operate at a certain > scope (such as those doing ip address referrals between hosts which have > local and global addresses and those which only have global addresses) and > these would need to override the default address selection rules, thus being > conscious of address scoping. Yes, applications should of course be *able* to influence these, if they desire so, provided that: - they don't need to if they don't want to (including multi-party apps) - the API is de-facto standardized so every app doesn't have to reinvent the wheel for 10 different operating systems > > I think a better method would be to give preference to global unicast, > > ie., reverse the scoping rule to prefer the greatest scope. > > On what grounds? Local scoped addresses are not mandatory, and thus should > only be put in place if they are intended to be used. Yes, but used by *WHOM* ? If they're used in the site, and that only, typically that would be OK. This also begs the question whether local-scoped addresses would be deployed without global addresses or not (as some have required). If there are local-only nodes, the reason to deploy local-scoped addresses could be simply to use them when needed, no more no less -- without disturbing the global communication of nodes with global addresses! > To my way of > thinking, the presence of a locally scoped address suggests that the network > is unwilling to trust the global address for local communication, The motivations vary a lot. > and would > thus expect the local address to be preferred for local-local traffic. That may be a desire, yes, but they may be others -- particularly regarding how you intend to deploy the addresses. To me, by default using the global addresses would seem like a plus: even if/when they leak (to a site which is also using local addresses), nothing bad happens: the global addresses are still tried first (and not second) -- the way it should be. This way, people could also publish local addresses in the non-split DNS (whether that's a good or bad thing is a different issue). > > > However it is useful if a host can have both types of addresses > > > and use them appropriately. This creates a host with multiple global > > > addresses, a form of multihoming. > > > > I fail to see how a local and a global address could be considered a form > > of multihoming. > > It depends on your definition of multi-homing. I've hear the term used in > the following ways: > > - A network with access to the global internet via more than one independent > path. In some cases, it's more detailed than that, but yes. > - A node with more than one usable address (having addresses in more than > one logical subnet simultaneously). This is an abuse of the term. > The second definition is being referred to above. That's "multi-addressing". (Note that there's a significant overlap with the two definitions above.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 3 03:50:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53AoPTX005466; Tue, 3 Jun 2003 03:50:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h53AoPgK005465; Tue, 3 Jun 2003 03:50:25 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53AoMTX005458 for ; Tue, 3 Jun 2003 03:50:22 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h53AmeNh021333 for ; Tue, 3 Jun 2003 03:48:40 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h53AmTep004260 for ; Tue, 3 Jun 2003 04:48:34 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h53AmJP18093; Tue, 3 Jun 2003 17:48:19 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h53AiZ426716; Tue, 3 Jun 2003 17:44:35 +0700 (ICT) From: Robert Elz To: Pekka Savola , Bob Hinden cc: IPng Subject: Re: Status of In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Jun 2003 17:44:35 +0700 Message-ID: <27695.1054637075@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 3 Jun 2003 10:29:14 +0300 (EEST) From: Pekka Savola Message-ID: | Yes, applications should of course be *able* to influence these, if they | desire so, provided that: | - they don't need to if they don't want to (including multi-party apps) I doubt that the latter (parenthetical requirement) is possible. | - the API is de-facto standardized so every app doesn't have to reinvent | the wheel for 10 different operating systems That would indeed be nice. | This also begs the question whether local-scoped addresses would be | deployed without global addresses or not (as some have required). Pekka, there's no way to stop it. Regardless of what address forms are created, or not created, this is going to happen, however dumb we see it as being. What we need to do is minimise the harm, we cannot prevent it. | If there are local-only nodes, the reason to deploy local-scoped addresses | could be simply to use them when needed, no more no less -- without | disturbing the global communication of nodes with global addresses! There are also those who will always prefer to use local addresses over global, regardless of what is available. I'd have global addresses available everywhere, and use them only when that's the only thing that works (when routing cannot get other addresses to work). None of us can impose our model of how any of this should work on the world at large - we have to be able to cope with different methods of building networks. And yes, that means that applications either have to be able to cope as well, or they need to simply admit that they're not going to work (or not work well) in all environments. | That's "multi-addressing". (Note that there's a significant overlap with | the two definitions above.) The difference doesn't matter here. All that matters at this level is that a node has two different addresses, which don't work the same from all different possible peers - from some one works better, from others the other does, to the extent sometimes that one of them won't work at all (and that one can be either address, of any scope). Bob, in the next version of your draft, could you include some mention of how this change (from FEC0::/10 to FC00::/7) is planned to affect Node Information Queries (from Matt Crawford's draft) ? 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 Jun 3 04:30:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53BUFTX005718; Tue, 3 Jun 2003 04:30:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h53BUFX2005717; Tue, 3 Jun 2003 04:30:15 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53BUCTX005710 for ; Tue, 3 Jun 2003 04:30:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h53BSUuc018550 for ; Tue, 3 Jun 2003 04:28:30 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h53BSOLv016087 for ; Tue, 3 Jun 2003 04:28:25 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h53BSES11871; Tue, 3 Jun 2003 14:28:14 +0300 Date: Tue, 3 Jun 2003 14:28:14 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: Bob Hinden , IPng Subject: Re: Status of In-Reply-To: <27695.1054637075@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 3 Jun 2003, Robert Elz wrote: > | Yes, applications should of course be *able* to influence these, if they > | desire so, provided that: > | - they don't need to if they don't want to (including multi-party apps) > > I doubt that the latter (parenthetical requirement) is possible. Hence why the ordering could be reversed: no modifications necessary for working-by-default-for-the-first-try configuration. > | This also begs the question whether local-scoped addresses would be > | deployed without global addresses or not (as some have required). > > Pekka, there's no way to stop it. Regardless of what address forms > are created, or not created, this is going to happen, however dumb we > see it as being. What we need to do is minimise the harm, we cannot > prevent it. I didn't say this would be a bad thing, but we should figure out whether folks want to do "local only" or "local + global" deployments (and their variations). The reality affects subsequent decisions, of course, but this should be taken into account. > | If there are local-only nodes, the reason to deploy local-scoped addresses > | could be simply to use them when needed, no more no less -- without > | disturbing the global communication of nodes with global addresses! > > There are also those who will always prefer to use local addresses over > global, regardless of what is available. I'd have global addresses > available everywhere, and use them only when that's the only thing that > works (when routing cannot get other addresses to work). True.. in certain deployments, this has some merits. What I'd like is to look at the problem from all the angles and document the tradeoffs and implications of both ways and see from there: not just assume that "local = smaller scope" is automatically better. > None of us can impose our model of how any of this should work on the > world at large - we have to be able to cope with different methods of > building networks. That includes of course imposing the requirement how you want to build the network on other people ;-) [...] > Bob, in the next version of your draft, could you include some mention of > how this change (from FEC0::/10 to FC00::/7) is planned to affect Node > Information Queries (from Matt Crawford's draft) ? You mean that NIQ should be amended to allow queries from that space and forget about the TTL=255 security hack? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 3 04:52:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53BqCTX006027; Tue, 3 Jun 2003 04:52:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h53BqCED006026; Tue, 3 Jun 2003 04:52:12 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53Bq8TX006013 for ; Tue, 3 Jun 2003 04:52:08 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h53BoQNh001129 for ; Tue, 3 Jun 2003 04:50:26 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h53BoI3K019270 for ; Tue, 3 Jun 2003 05:50:19 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h53Bo5P03915; Tue, 3 Jun 2003 18:50:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h53BjR428602; Tue, 3 Jun 2003 18:45:27 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: Bob Hinden , IPng Subject: Re: Status of In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Jun 2003 18:45:27 +0700 Message-ID: <26533.1054640727@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 3 Jun 2003 14:28:14 +0300 (EEST) From: Pekka Savola Message-ID: | Hence why the ordering could be reversed: no modifications necessary for | working-by-default-for-the-first-try configuration. Which is "working-by-default-for-the-first-try" depends entirely upon how the network is built - in some environments, global addresses might not work first try (for some applications, I'd be tempted to have an attempt from any global source addr, or to any global dest addr, automatically dropped on the floor - and not for any supposed security reason). | You mean that NIQ should be amended to allow queries from that space and | forget about the TTL=255 security hack? I really meant that NIQ as currently defined, for QTYPE==3, has an "S" bit in the query that requests "site local" addresses. Something needs to work out how that applies (how NIQ applies in general) to these new kind of addresses. NIQ is too useful to just allow to wither. That's as in draft-ietf-ipngwg-icmp-name-lookups-09.txt which is the most recent I can find. It has no mention I could see of what address types should be allowed, nor any TTL==255 hack. I can imagine that in some environments restricting NIQ to LL addresses, and/or TTL==255 might be worthwhile as a kind of security (close to useless), but I certainly can't imagine the spec ever permitting only that - that would outlaw its use in other environments where real security (as in IPsec) existed for the query. 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 Jun 3 07:36:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53EaPTX006727; Tue, 3 Jun 2003 07:36:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h53EaO17006726; Tue, 3 Jun 2003 07:36:24 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53EaLTX006719 for ; Tue, 3 Jun 2003 07:36:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h53EYeNh005697 for ; Tue, 3 Jun 2003 07:34:40 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h53EYX4Z006624 for ; Tue, 3 Jun 2003 07:34:34 -0700 (PDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h53EYHCi046536 for ; Tue, 3 Jun 2003 16:34:24 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h53EYFo7101774 for ; Tue, 3 Jun 2003 16:34:15 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA19558 from ; Tue, 3 Jun 2003 16:34:13 +0200 Message-Id: <3EDCB1FE.B8AECCDE@hursley.ibm.com> Date: Tue, 03 Jun 2003 16:34:38 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <20030527193820.GA6652@fysh.org> <2377861193.1054241155@hkruse.csm.ohiou.edu> <1054272212.1703.15.camel@vega.amorsen.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So, Benny is turning it upside down - instead of asking the registry for a number, we tell the registry which number we'd like (and the registry will say no if the number is already registered). It would work, but I don't see any particular advantage over having the registry pick a number. It's an opaque, meaningless value either way. Brian Benny Amorsen wrote: > > On fre, 2003-05-30 at 02:45, Hans Kruse wrote: > > I actually see a lot of value in the /56 proposal; I really like the > > simplicity of creating the /56 from any MAC-48 in the network. It > > accomplishes the uniqueness property without requiring central > > registration, and should serve organizations up to considerable size very > > well. And it readily discourages the notion of "make up a prefix" for > > temporary or (temporarily) disconnected networks. > > I have been lurking in this discussion by reading it as a newsgroup over > at gmane.org. (I tried to post too, but even though gmane.org said it > was posted, I do not think it reached the mailing list.) > > It seems to me that things would be easier by letting people invent > their own numbers by whatever method they prefer. Then, if they care > whether the numbers are unique, they can register the numbers they > picked in one or more registries. This way they can be assured that > other well-behaved people will not use the same numbers, and at the same > time it is clear to everyone that the numbers are not /guaranteed/ to be > unique. > > Later when two organisations need to connect to each other directly and > the numbers conflict, I bet the organisation that registered its numbers > has a good chance of being the one not having to renumber... > > By the way, I am not very fond of the MAC-address method. If we are into > misusing other registries, we could turn a phone number into hexadecimal > (including the international prefix.) 12 digits can be stored in 40 > bit... > > /Benny > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Tue Jun 3 07:40:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53EeOTX006761; Tue, 3 Jun 2003 07:40:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h53EeNnc006760; Tue, 3 Jun 2003 07:40:23 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53EeKTX006750 for ; Tue, 3 Jun 2003 07:40:20 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h53Eccuc022798 for ; Tue, 3 Jun 2003 07:38:38 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h53EcW4Z008922 for ; Tue, 3 Jun 2003 07:38:33 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Status of MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 3 Jun 2003 07:38:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Message-ID: <963621801C6D3E4A9CF454A1972AE8F5067195@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of Thread-Index: AcMpoovzjm0e2b0DR5qgQTAu5SkznwAN51oQ From: "Michel Py" To: "Pekka Savola" , Cc: "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h53EeKTX006751 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Andrew White wrote: >> - A network with access to the global internet via >> more than one independent path. > Pekka Savola wrote: > In some cases, it's more detailed than that, but yes. Agree. >> Andrew White wrote: >> - A node with more than one usable address (having addresses >> in more than one logical subnet simultaneously). > Pekka Savola wrote: > That's "multi-addressing". (Note that there's a significant > overlap with the two definitions above.) I don't even think that there is a need for a word; the capacity of a host to have multiple addresses has been built into IPv6 for a long time. In my experience, "multi-addressing" is generally used for a form of multihoming where a host that has multiple global PA addresses form multiple providers to connect to the global Internet via multiple paths. IMHO, a host that has a global address and a local address is neither multihomed nor multi-addressed. It's just a regular IPv6 host. 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 Jun 3 11:19:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53IJnTX008377; Tue, 3 Jun 2003 11:19:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h53IJm9Y008376; Tue, 3 Jun 2003 11:19:48 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53IJiTX008369 for ; Tue, 3 Jun 2003 11:19:44 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h53II3Nh019327 for ; Tue, 3 Jun 2003 11:18:03 -0700 (PDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h53IHu3K020062 for ; Tue, 3 Jun 2003 12:17:57 -0600 (MDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h53IHlra003229; Tue, 3 Jun 2003 14:17:47 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h53IHlZs003228; Tue, 3 Jun 2003 14:17:47 -0400 (EDT) Date: Tue, 3 Jun 2003 14:17:47 -0400 (EDT) From: Scott Bradner Message-Id: <200306031817.h53IHlZs003228@newdev.harvard.edu> To: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <3EDCB1FE.B8AECCDE@hursley.ibm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So, Benny is turning it upside down - instead of asking the registry > for a number, we tell the registry which number we'd like (and > the registry will say no if the number is already registered). does wonders to the routing table Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 3 11:27:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53IR4TX008535; Tue, 3 Jun 2003 11:27:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h53IR4ol008534; Tue, 3 Jun 2003 11:27:04 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h53IR1TX008527 for ; Tue, 3 Jun 2003 11:27:01 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h53IPJuc010103 for ; Tue, 3 Jun 2003 11:25:19 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h53IPD3K022818 for ; Tue, 3 Jun 2003 12:25:13 -0600 (MDT) 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 LAA20621; Tue, 3 Jun 2003 11:25:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h53IPCK09615; Tue, 3 Jun 2003 11:25:12 -0700 X-mProtect: <200306031825> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdt6opdc; Tue, 03 Jun 2003 11:25:10 PDT Message-ID: <3EDCE830.50908@iprg.nokia.com> Date: Tue, 03 Jun 2003 11:25:52 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Robert Elz , Bob Hinden , IPng Subject: Re: Status of 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 Tue, 3 Jun 2003, Robert Elz wrote: > >>There are also those who will always prefer to use local addresses over >>global, regardless of what is available. I'd have global addresses >>available everywhere, and use them only when that's the only thing that >>works (when routing cannot get other addresses to work). >> >> > >True.. in certain deployments, this has some merits. > Deployments that expect to encounter intermittent global connectivity and/or frequent renumbering events may be better served by preferring local use addresses over global. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 3 17:18:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h540IkTX009937; Tue, 3 Jun 2003 17:18:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h540Ikgh009936; Tue, 3 Jun 2003 17:18:46 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h540IgTX009929 for ; Tue, 3 Jun 2003 17:18:42 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h540H0uc018932 for ; Tue, 3 Jun 2003 17:17:00 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h540Gsht001606 for ; Tue, 3 Jun 2003 18:16:54 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HFX00H2OKS60T@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 03 Jun 2003 18:16:54 -0600 (MDT) Received: from sun.com ([129.146.12.19]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HFX00J46KS4UI@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 03 Jun 2003 18:16:54 -0600 (MDT) Date: Tue, 03 Jun 2003 17:16:52 -0700 From: Alain Durand Subject: Re: Status of To: Fred Templin Cc: Pekka Savola , Robert Elz , Bob Hinden , IPng Message-id: <3EDD3A74.1050603@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: <3EDCE830.50908@iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred Templin wrote: > > > Pekka Savola wrote: > >> On Tue, 3 Jun 2003, Robert Elz wrote: >> >>> There are also those who will always prefer to use local addresses over >>> global, regardless of what is available. I'd have global addresses >>> available everywhere, and use them only when that's the only thing that >>> works (when routing cannot get other addresses to work). >>> >> >> >> True.. in certain deployments, this has some merits. >> > > Deployments that expect to encounter intermittent global connectivity > and/or > frequent renumbering events may be better served by preferring local use > addresses over global. > > Fred Kre, Fred, I will argue that prefering global scope (when available) will _generally_ result in having better chance of connecting. Yes, I agree with you, there are _some_ cases where this is not true, but those are not the _general_ case in the Internet. What we are talking about here is setting up default. (The I of IETF stands for Internet, not for local networks.) On another note, we have shipping IPv6 products. I think is is getting very late in the game to invent yet another address format that nodes are supposed to recognize and give priority to. Please, keep things simple. - 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 Jun 4 07:11:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54EBmTX013311; Wed, 4 Jun 2003 07:11:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h54EBlY5013310; Wed, 4 Jun 2003 07:11:47 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54EBiTX013303 for ; Wed, 4 Jun 2003 07:11:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h54EA3Nh021086 for ; Wed, 4 Jun 2003 07:10:03 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h54E9tLv028577 for ; Wed, 4 Jun 2003 07:09:57 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h54E9j205724; Wed, 4 Jun 2003 21:09:48 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h54Dxip09843; Wed, 4 Jun 2003 20:59:44 +0700 (ICT) From: Robert Elz To: Alain Durand cc: Fred Templin , Pekka Savola , Bob Hinden , IPng Subject: Re: Status of In-Reply-To: <3EDD3A74.1050603@sun.com> References: <3EDD3A74.1050603@sun.com> <3EDCE830.50908@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Jun 2003 20:59:44 +0700 Message-ID: <9841.1054735184@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 03 Jun 2003 17:16:52 -0700 From: Alain Durand Message-ID: <3EDD3A74.1050603@sun.com> | On another note, we have shipping IPv6 products. | I think is is getting very late in the game to | invent yet another address format that nodes | are supposed to recognize and give priority to. I absolutely agree with this. Further, I believe that 38 bits of identifier is plenty for gaining lower collision chances with non-routable addresses (which is all any of this can possibly achieve). Hence, I see no real reason at all to stray from FEC0::/10 - and lots of reasons to remain in that space. 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 Wed Jun 4 07:20:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54EKtTX013444; Wed, 4 Jun 2003 07:20:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h54EKs76013443; Wed, 4 Jun 2003 07:20:54 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54EKpTX013436 for ; Wed, 4 Jun 2003 07:20:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h54EJANh023205 for ; Wed, 4 Jun 2003 07:19:10 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h54EJ2Lv003774 for ; Wed, 4 Jun 2003 07:19:03 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h54EJ0206122; Wed, 4 Jun 2003 21:19:00 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h54E8op09863; Wed, 4 Jun 2003 21:08:50 +0700 (ICT) From: Robert Elz To: Alain Durand cc: Fred Templin , Pekka Savola , Bob Hinden , IPng Subject: Re: Status of In-Reply-To: <3EDD3A74.1050603@sun.com> References: <3EDD3A74.1050603@sun.com> <3EDCE830.50908@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Jun 2003 21:08:50 +0700 Message-ID: <9861.1054735730@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 03 Jun 2003 17:16:52 -0700 From: Alain Durand Message-ID: <3EDD3A74.1050603@sun.com> | I will argue that prefering global scope (when available) will | _generally_ result in having better chance of connecting. | Yes, I agree with you, there are _some_ cases where this is not | true, but those are not the _general_ case in the Internet. | What we are talking about here is setting up default. | (The I of IETF stands for Internet, not for local networks.) Having agreed with half of Alain's mail (and splitting this deliberately because there are two separate points here), let me disagree with this part. What will work best depends upon just what is being counted. If you count all the possible places I might try to connect, and determine which address would work, and which would not, you're absolutely right. But, if you count all the connections I attempt to make, and work out which address would work, and which would not (or is not best to use) then you're wrong - because I, and I suspect most people, make huge numbers of local "connections" compared with the number of remote ones. (Just to be obvious, sending a DNS request to the local cache is a local connection for this purpose, and one of those tends to precede each remote (and many local) connection...) What's more, there are cases where both will work. For those, which order we select as the default determines which of the two is used. For this case (which is for me actually the interesting case - if only one address works, that's the one that will end up being used) which order I'd prefer actually depends upon the application. For some, using the global address is just fine (for some perhaps, even necessary). For others, it isn't, and the local (more stable, probably) should be preferred. 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 Wed Jun 4 07:31:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54EV6TX013671; Wed, 4 Jun 2003 07:31:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h54EV5nN013670; Wed, 4 Jun 2003 07:31:05 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54EV2TX013663 for ; Wed, 4 Jun 2003 07:31:02 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h54ETLuc020057 for ; Wed, 4 Jun 2003 07:29:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h54ETFep015960 for ; Wed, 4 Jun 2003 08:29:15 -0600 (MDT) 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 HAA11790; Wed, 4 Jun 2003 07:29:15 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h54ETFf02789; Wed, 4 Jun 2003 07:29:15 -0700 X-mProtect: <200306041429> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (209.157.142.164, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIQo4gw; Wed, 04 Jun 2003 07:29:13 PDT Message-Id: <4.3.2.7.2.20030604072330.02ba46d8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Jun 2003 07:29:05 -0700 To: Robert Elz From: Bob Hinden Subject: Re: Status of Cc: IPng In-Reply-To: <9841.1054735184@munnari.OZ.AU> References: <3EDD3A74.1050603@sun.com> <3EDD3A74.1050603@sun.com> <3EDCE830.50908@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 KRE, >Hence, I see no real reason at all to stray from FEC0::/10 - and lots >of reasons to remain in that space. I think you are suggesting that the draft be changed to reuse the FEC0::/10 space with a resulting 38-bit global ID. This would allow for 274,877,906,944 prefixes, or 30 per person in 2050. My preference would be for a larger global ID, but I would like to hear what other folks think. 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 Jun 4 08:27:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54FR9TX014083; Wed, 4 Jun 2003 08:27:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h54FR8Co014082; Wed, 4 Jun 2003 08:27:08 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54FR4TX014075 for ; Wed, 4 Jun 2003 08:27:04 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h54FPNuc006500 for ; Wed, 4 Jun 2003 08:25:23 -0700 (PDT) Received: from TH-CD329B749CE7 (port245.ds1-sg.adsl.cybercity.dk [217.157.187.122]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h54FPFYU002804 for ; Wed, 4 Jun 2003 09:25:15 -0600 (MDT) Message-Id: <200306041525.h54FPFYU002804@brmea-mail-2.sun.com> From: To: Subject: Re: 45443-343556 Date: Wed, 4 Jun 2003 17:26:09 +0200 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_000705C7" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multipart message in MIME format --CSmtpMsgPart123X456_000_000705C7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file. --CSmtpMsgPart123X456_000_000705C7 Content-Type: application/octet-stream; name="45443.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="45443.pi" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABSj0hvFu4mPBbuJjwW7iY8lfIoPAzuJjz+8Sw8bO4mPEDxNTwb7iY8Fu4m PBXuJjwW7ic8hu4mPHTxNTwb7iY8/vEtPA3uJjxSaWNoFu4mPAAAAAAAAAAAUEUAAEwBAwBEk9c+ AAAAAAAAAADgAA8BCwEGAADgAAAAEAAAABABANDyAQAAIAEAAAACAAAAQAAAEAAAAAIAAAQAAAAA AAAABAAAAAAAAAAAEAIAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AAAAAAIA0AEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABDREQwAAAAAAAQAQAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADgQ0REMQAAAAAA 4AAAACABAADWAAAABAAAAAAAAAAAAAAAAAAAQAAA4ENERDIAAAAAABAAAAAAAgAAAgAAANoAAAAA AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAMC41NABDREQhDAkCCVr2ocZm5U6G3dgBANDSAAAAwAEAJgoAbP9l 2f6LwTPJiUgEAggMEMcASGJBAMP9d///Vovx6AoAAC/2RCQIAXQHVgyVylmLxl7CBAAH2X7fG4tG BMcGKIXAHFB2CL91P9mF9ipew4tBBAMISleLfCQMP2DbbzM5fhBzIjgIMsHvDEfB9tu79ucMV4ka EJz0WYke/3YQagAELnv/3wgQnINmGACDxAxfdkcMOWQCeQQMBJ9kkGcMBBRTVv901m7/yyQQM9uL Bv9QHDlcDHYtW+i7bW//EIoMA408AxVRi84YPF91Dq7b27e/i04YiheIFJdGGEM7KxRy1UVbd7u9 w8IIBZBIBlcsIFdTm9vcs22dDGmJFGwlVe3Wdf+L7FFRU4tdDC5Tb3VHUCgH9r997I0MG2Qcg2UM mPsDck5qBI1F+LDu9rvYUK7dgGX8AANFwgNQF7d2a7FQVomMBgOOXhjG3W7H/kX8A1GNTfhELIMn A4OeBItP2O2/B4PAAzvDdrI7cHZCUorDK+Zcu20TKiBTiDpeWljb3rIEVFDoyekLDdsW2wjr+d0Q OxWk223tGGBBUxPPOgFb5ATdD78QTzkdsLVBp/F1BVgE3/e58rD/dQxN9ST9DFogPmzs9jP/g35c cn6gU/IIiF217W/Y1Mc7D7YIiomwtEmIiw9pDrsLSAEM+QL6gL195Nv5/w9AA4qARft1Az/6PP9k Dc/2BvvQBBQmBNFvbwvLMBQmx3NHBDvbdoI759zAboNzW4J6E4WXbhc223OjVgheHAoeipu+u/1/ YCvHjUQF+IgY/lGAOGSAIABBO9uyYRcxcttqZskYeZSwbS0Ba189AkAFwwsviwE2jVX4KRxv/MO3 UkQ4i00MvAMrwV6Ke4D6/9hrS/+IEXQBR0FOdXrHNVc25K7bMFNufQg6VzY0i3Ubuu5bks4rxlq/ CL2QHhlB9m9v7Up18A/5SHQFAgbrCMZGAj0DP9YR7AM9pP0IqIoIwOECVvg3/ogOilABwOqD4gMK 0YgWioIUbZZl+wSITgEVAgIPVgEvFMqyFgIGkoUkPwrYM2TbwYhSXkrpCDy9b3ZsUuE/PFMCPGyl C/ZTBhZKAkgDN7b/8ooEPAdyDTwNdgcgUWoBD91v+FjrAjPAMVdqQFm4/gC/mvPsN/atq8FfD76B 6IgRDIAHN7fu/0GD+UB85YAN7Qv/Bm21xwWwdt9qNQHa4/YFqMQKdQfItiHWGgiSBSEUqb37zXOp 6S1o2TRAAB6gv1nDvPD5gQu4mU1BpNiKikXzfqPwKotVxxKJdeyIAVvdr+8RiEEBiFnKIM4NjRRT 7d2NWwTPiWGIBxMaxIlHKTCyjt9fCBlOIKsBM+PYwq7GFQLHZGJmCB0W2N1QYPSDs2SJDcEAybsB chCnBdy6FRGbbS7ZuLqiK5fwTXDb63Wmx0PoJW0SFNbF3H8LaYNN/P/CF29ea1sPchvtIk6D7Fi4 7JhiJgNJ6pfZ41bYbf+8ChMYpuYgW4W+8C52vFDpExSag3jOD5TAhG2RsQVRQinMI8xns7G3IlDh JFB0LVO/K2xyJIkPlQ8TGIeAffMA1wzcGroR8+sZCq/Zdsm6IrwbVnRMWKzCTmcGrN8DWz/ccHCL QDdLuIwDTQ9RB9s+beAI/BKsquxUrOl725ULegf1FgpXLA+E2UXZ5Mietl0EsJ7stTas4q1ElQ+F nW4pG8I7BZkITdz+WMP7idpJFAdFg33kAHUjgrlFxkGcO+wCO7DtyMmcCOsDENzLsGu68toJYgf2 LXQNsbNZ16v9VZyX5dwMP2Km3esNNGi0EVxeRQiX8GsZXxq4bPVM7cf6DfGNeRSJTezAFa++LJEc 5nOBBmJD2FaT48OxA/eLTwSDY17oUQNTYreNsxpSGFt22FN3nOPbyDJQUIPBBC5aEt45EFLYPFLO MDDzhJQ/0kK17y4J1RQBPPQ7iYBa62KLNtLoK2AnZy62/BaLMB7uUMjxI1h2HmZLlAKS8bcQeV4D f+hrJeFZpHux961ZXFmZDMhCQk54vviQC8gHsgnLGDAONyyErkDwMlcMCK9wYCE5CisJE5Y1A4xX bwgWYx/JO8fIi/g0haNwwoTwXYtHBKj2+CNXMvIDuAYHVxzIcwkBBrioupbhiD47L4DJQaxLFCve VV7oreHgjlj2iX3wyxx0TjvSbxef8P8Cg/gKfUN1DMEn1jXIkjHg4KtQK6zmGsL8DGAbTQw+CVsE wxGE23SyIVk2EhaGwgScaLeGLjCMCIuF240ts71cQBYBgDsACA22xmfx8TBoDwFbVw5N6P/I43bD 6/AA6QyNRjx31FMw+qM0YeQzb+WNWP/0X3YXb3cFEpgB2IocGID7LnSb2fEtti6l1H4WDwxAf2zo cA0JC08LLgPoi9jkNsNCLpCmfKOmQrNdaAMOXegLlysMLN+Fsy3EB/BQbfXM9EJbMIwiP34ZTAEB W+4K3SZ/QIEBOXM4Q/DUnpZ0e+SIAyXIQwdpppV6ao0Y7fFZEm9XhK8hk8Qt4gteF/DepGUSorQN 3/AtgEVd7I2eQCBAag+JAxz22x9B+osLMWaJRDE8DQD02m/3PkGlJrik93cMFzLwrAQgD7sNtrfA wW7t2yPLKgvIgckOT4kPHPZu+4WD1cHgE4HhIYeJC8GJBxhry9l7TjSbNQGJD6UYvDMM8MkMFbjA mWK8mw6h9Idm/wUGdfc3w8F8TjDhSeD/ZoPhAE2h0Aw3SbuUJ34ZyrKwax9qEWoCASs9Hmj/gXdf 4eB1rQ0YYg9yahC7sZ2MmrQpZscOAvxut88rIRJRZa5IRbAiEFB2BfMtteBFDIsM67lSJQOOEuZ4 ndaUwYGhhvMfie3Bg8uGQeSHrfSLk3WOFaGqEZMtfJzoM4yCwDZqh3cHgzUxJ1BodD6Lhpv2DLa5 amOBV4IGEwys/fsNGPsz9s0laLgLKz7xDez2KbBSfxEjIU+2rdF4iHQG1dAC1IPE61jYj8xxrycG ww64izJhNal0MxulLr/0pdCL8NxKb8YPZvfHEYXifnm2L7CyUN5V5DM6FcfM6bPdmh8DeAAhwBC5 inXP9psG+iP5O/kercIED3+U3rMeoY7cbPwQiwNriJXawejjAnvJ+HD2wV5h5FsTEMAD+GYkUrsV sA35fjG+JDPQdN3OxO4D7JzUAi3y8WHQWBCF+JwvEFy8bScB1k91z4GGJJmkdhR6Hy28A7vQIH4z besxLI5CYWUpGx9lgZE02HQIMiJeK2gsBGTrewu4MORqUKkT6LHYxBNYh+BefRRDO/7xUkubJnQD aDfsEIA+4UpIbB0awguBG3Uj4enWaYyKBia0bC91dGT5wEaoByMOravCsmQ/CEFghcF4+7bxNAh0 3bw/RNeNQwJSB+vP5rbCX42NXAMBfhvahgZ/fMJjtfYQRv9oeMv/TRQ1/MhZu3R0DuHg65lD65aA 62IdXQlKmh+SbCfMwriNDlhQ8HJlMXM+yWcQLEQm4TdPASjh8FmBUycE3E5vOgWjheVdFBgKHL6E XMK2bDMCMA0Yw23dsXfs6YZIF/BLwzpaz1BLl20D3I9nMIx91wFZBzvZeJDMBwPwRQZGYO1GS3YD Rg1K8cYGEn770rIBH3UKZgEHIoM7D3VPyLku0J3ARgIsa1/ciM3kcAXUAFJ0m3X3oR7VdBh/jU8g EHb0ZrOWBIiEjreVcyeiA05XkkM2QQ6Lt3F0O1DDzDvIF2dKBLAEGFDWINtdAkgCdUWaVu3lI08F dBwWi0cYFI1VIDAXB8MAUicxtphMmIyw49xnYAhpOOnj3BhNhSg4s9zei2hiAqFHOcBW1rZvz7iL 8FT33hv2T/AGUTGg1GrVKF5RiNi38UOKAIgGFnnZdaV/Vab8WVDgDAwsF5174CKBJIQEZKNFF6+/ XXoC718WbJCbQYvOVz4m44st2M47tl03TJLZKeYOUTB1jjQG/x+4VzWLyMHpEGaFyXQsXN1lw1a/ JjPrEWQNeMABjjkBURNztyxMgiFJ9C7/93YJHKCyhfZ52XUHPu7WbqnEMFhqBs0EQEHzjd2CUDEk YLUOCyDbbIY2vYUfCxzrKTl2rmxoy54ZDRQtzGEfFaB9av8WOywcwTa7lVNndQYwx//FS5Yi8m93 FFY4yJLp6OYf4BRHcN/WZd/2UPH878P5c9lCet9Ww9MMXOAOhycV1fPQNRcQY1wLW1eLFd/ZYRZo MlFLZCjwAEPVuhgluGymuwIIDF5gTAzhspSkQIP9tAhFtg3UggtE4Bl1dLRbGhne9wrfEzgB/YJQ tiAs7hoOAaMS+tgA6yNhyS3JrhydPGHHYJmL5PxRxxlxW2u7U+Gmg2YkA79ZE13fbEP8mSv/Dbxz Xmwme2duNbgIJCUKI8ff4i82vFGP+YtfCjM783RAK9qFEwWLNq542Qz2JyaM6+n/d2BnZwhHM1BD rVlKh/l1W+E2wAidT9lHeyzIhLxFNzv3yzQjJCR4uKhP+SxO7i2hA8rv1wzt0YEE56GWY8GocKRc aFcri+EubLDUldU1du37gQN+2h182I3OyRfSXiAPvn2K5oql4FBWLN7oQMPBBXwkOABOHdILso0M gNCC1B8GOUMIczgJAzdeco7wK/E5JXMDye/CV3g7+3UeSYcDhc9WaelY64o2Pc97C+t5M/8San92 PzvwdTs7SYB4//5zKRABm3TUzxr+st24aYtLVE8IBQwM/kD/6zbAzk7RKIfEKC2gwxLdjVYiUIyZ pRl7H0fMdzDHyec6bR0MumzIdw1qWyx4EkdmKUDD1sIrxjhzbNg1Mt1GF28IK8MDfwSgUVSn7rBv 83yLdwgr89NWhQpqkCsmY2cGP4MmoXtl1PFwGm00SwkDajRbMeFPK4P//Xa6pzP/23/h0jvKrIpB /zrCdBk8QhU7+nVM/shSiHb3wWgRBjLA60UUFThUXsb+3e10BHPr5zHqiVYIiBHr4xQXjC901G3X Hxg7x3MYPn8mE53rBZTxDhtqsFvRHrMBhOsp+CJgdF2LikO3G3QXfm0QDrzyc4KdMZPoi9rDgLJc dN1uW/P9G41I/4pAOAoGqYiQB1EjnRQj4YAIhF6kVskDqrx0cWEIDKwvWV7oTgHJ/PtmPzkXLZ3Y yX3c9Euzt4Tbogt2yle+Pr8gQIHi8/EcJ490pHAbc4tRpzvCd68+44wOv1CvCivCPDGQvkMtrdCa 0HfN1m1X8Qxa+DsIdVM5PBfZunR1TloQE71emw8NPXDwIGOLDVpXqFOB+MW+I22gdYYJMokVP0AI b8Qq9JE2FXhK6yU7E61QaBpQjyEesHty6yQo1PBXHZZ/6+ASiFHLI1yU0WBgINun5GHBMkXCU++L TbGGDGIO3gg9V9w2SkKmc4T5U+rKuaWOsRjhiRCeShue1dQnJKgsGP8uDtJjA54w7lUQVzm6hVfl cx6UBrvFiofN42wIs//jqCO93DgU/09fiRgmahilJQpH+YtMfY11dkRusrnIOQsIPrEatZgy32qE /RtbtdGekPwOO0IIdmGLSsc302/kwXNVK8jNIHdMi3L9amh0YVkrMwP5BRpXX5Se0eIyq2zPrNv8 DA5aMNER3aq89VKLWL8CzY18N4EvbCxVc6fLEvyLwyu3BBeBUhpO3FBHostg8M8MuoPPdVRipB+n iYHmdoLlMQztrI1HAn0V2ozazVDRhMQJa+TAicJrGrbW4HcZWbjMK0AAJj896Lnb0jGudhegdvjH UDIbIkJ1KEDo014IsYkuSbYbQG2AYIdtqW4fO987dzD7dktGsArNTQy8TjopkpqYFZUOJNekagqr mB8gUultdE1O///LReTJtTV9Mn8ydwlSEjpVtK1eSSgRKb5oF2hLdJwQqOjC86k8mB4bt9iL+AkX OzJUq0hfyiBbLtBWM0PepiUanC3W6HhQJPbrkJPCkdzp69UbRgKAf/61Mkat+/QMYR9Lw/aDIWYI UcYB+ujuBr0GVEAIdC92bLaj7DsYdS9JXewjwNlgv0IaKkgMjH05plwjRhQHMIQQp9joABDCb5NY sqGgGFDyAyY5030Mv6DCHDg8q1UZIjehFa4cNEYf8JNa8s19o8EeeXTVyA+EllA+GrO6CQkrAzzv HMINBVJaA+v2I4vu/jsKwQZd8HRliweJWAQEAztfh4mNt40FiV7FFx4qnIkOPgUw3omxBaW7geYk +VY5eAQmWFqr7YYOODk4dSQYtg/t5a3rIwSiiTqLTywsiUsFze2WaLyKLJ0fCwo9ATmbmfBXQ3Bi 71uaMHBDDT3LtzPTttwki08rtOQu/R3UaJEO6lqZCb3Nzdzr9RzReRGJQ7Cl1lyeYcxrD0YPbgBm CPXrDQnrytCZIyhBpXZfKdC6BnwsD4ULXjg7kppdA7NC/OIU8wBGBK3UXjB1NLmoJxLtp7Z/iQU1 y4NgDZTs38B7ItkQhAg5eSx1RotIB1cytnA+6zoAMhkjvrPBnmQAKlM5TB+Lqgz2UC8aGhdcsrFW LgcZyzhr59x2I2BJLNEsCB8R+97D3MtmkOs8Uj5IP3ZkZwurAD4APTMMrVtiifsZ4AwTaMUV1paD RLROhTbk/1FpoWHUBBcudqVmNORjzCy9wbOC0Sq57Ts94Lk2is/NJU2WJsXO/uY2jU9vV235QIO9 F6f+ddtvQceZa9mU7UBqsmqFeA4gn0E+gjcm8HUhajA7s8dALO6IHetHoxoYoWO6/wW8IhEs9pGX LGskfrU1pRwsol4MagUwE25ZXm6K2FtgS4BU8/BSqaXoKOqLohTq2bFCbSx8Kn2JBwb5wAalXwMM tyTWwIZLvP9DDDs8dCtwOwU4WGf5AnUgFHN8EMuXYhi0r7IciXgIiY6dc70+Dg+0Cevqtc3o+OkC iTgU9zt41azMaJ2OGxc5UNqehy0bjS1oVQkrURsxRtsuClqJGokKYgQ1ek3vMwmkaGatBWEyLr7L VkPLSqnHi4QstEFuJ3O7UphTdKyENyNkfZILJViBhVT/c0ForwC5zfwqN+ACowXndRClIEAQx6Ti YrBrzQiLENAEOxVI+q3dtmJKVFEE5gVWBF47SlDT/PmEQlEEOwoCQsAQYMsaGwTHIVOyYCFXB5Ca a7k4RkaF3ghgL5i9hS+3ipnbNgjcUFYRBIpoZzMXDwwIVNkI2Va/AUiM8Wh6nIwlYvAGaHjdGsZv Jtc5M3UeswgwK00+rZv4EziyDYuJDQlRE1tHhtrr0jCFkskv68BOJunzuHxZUexpMNnIdot4Pj0m ggch8jxga/iLB/Cza7azRp9bSFwE8gqWdFZ+OUEIdAKg7FHCkOSSUJY/JhbitR52eghtsCUbRocs LbaLF6OAFbouovp7daIdSKsyg8cQCN8LOsVXLg9fEbAyuFjGoDlm/IA/UlD/cQiGJTwIA1zBhMeY B3ApKAz+8ivHHd2mCP+nO9kIy9ZRMvrfEAfIA8f32RvJI8hRPF2h3/51EjtdFD6DyP/rCNkLDxbQ eMCVwGjFp4S8klclySXVSNGdIMylQwMGmmoqE8dnFOxm1TBSIM+hKLBSuEnQpmOtLBNgkiIey6oR CaGFW1zIsNpgC7DEVxwRQk1snKDhrPZyGLtR7VazLUpXTtLCkXJLCdrvomtLC8pEA8g78Xc6EIJC PeuF0z4r8gUYsxhR9YYTYNAQJ8DPQmi75CBkwBh5EEjLyEJIhCegFKC7FDs6rxUoCKOkDa/OgK+4 BMORw+I8alirdHsDCU48Uw3pXrcaCoSjgovrMt9DOSpIA0F+IFYEbApQHOZ7sKoVYsLzKXVZJhYd 9bhZdBqqjmaQ4pmjuubwLlgkXi3QEkYn3FfV7FxQ6k0JUGh/ZsCL8PhmodEwBAvA62LT7Y5li74O MwVyK8E5MKpdwAYhjYQLAA5HLvRtJdz/KCZB8CL3pHIocBap5pami+I/9nbwnLKQ4HCwaSpeSRjf xoLmCAxXigvxhf+IRVtWS9LHhQ9BcxQ2uHYShTSYdkTpbyuKEogQQEl1FsdfSU0QKdIkDDPbs8G/ vtk73leG6VaJ0lz20jT/fvqLS9lD/9bh3jv4dy4YPcddihCIEUFA6znaMbL0vt8DxppyWcI2Cyls TksM3YUTNjNcA8JlO9BXCnV1O/OID0dCaEsIaZ5cBIwVrYNt8FFwo1mQEGAkdqimDRN0pE5+1nTX ba41dD8WB0Y/mAIMHQU4bV/D1U1jCA0GRzw2RtY+ZoneAhtQAq0XGQNcO1vAtg4BHT2Gq9FiWh9f gewMb6UFHp7Tg2A5hfj+DDj3Eh3HhfQFFYA7GsGuXrno/T6Z94PY3IX/fEX4EQn5HNDbgHdp0hj6 67PbyRQrTTZZBo08BY+aAOnZC3JjZVWhC1GD5OBQZkCqDPIrKCxejTbedcypoS0GoxRyUCubJVdm oEt/MDldbrO5hQj5Lz9/tGgECqhpZrZQGiwR4VBwoEW/3rtkKZ9Zg7ShOQ8RU+9TAu+5N+ku32AS EQwUdBA4BPOxaGBu2+NZaqykoxdZeacAFKGDWLsGU7UFxpbAg0ZTJBGP9aDOBNhrfyH9jHIdRg0J Ki6cagoBKAHvFwnxj4UQPCVxvPkhlKHM0PM/0lCu2bxGb03UHd+sG4FTvIAMwivJOtWEEnY/8PEQ UhblrSvbCYYFUqt/e60JmIZeNNd3CPFndnatNHK3WVleqUku8BVpXtsgUSRCsZzZPl4UUzw8okNL CJ7cLMxDX3WrojsjSsQVCPrw1F1SUCj6XyNXOMPbGHd+lXQ/Vxs5ZjiBFMFoaLCZ9yabe66aGTvQ E7WSanjdWY04ygzH/cEILhs0vBB0TapSDTyLryx7kSi2wH6mPR357S84FUM86TvzryHcPRN9uDgP tvB4Q71kC2tfGFNCgC0JB24r6RABgUhW6qpnSpSoEMwuMy9mAQaIFXubAINzEYss9eyJIdWyyH38 QW9ELHiPEzwAyYW9OMm4nYupDMF2IJzkDHpaMlq51GhsqKpwmWkjOiJbWFCnujZ90MqLWjelF/Db EVq22ALcemLalra2usCvKBp8A5z/5Az/hQqtOzW5fCA7znQcO8JdYKlGOORCSX7xwaqPG7SNQQTU 00wuMwFsxdTqDKIRko3U0QktsDJfisdN1HAwawOIXQs68PyLRguDHBroOwV0JTqDEhfaF9TaJLq5 RyPn69moQuRKDovPDDGGCgamHtRzHQ1JVKgD/2IHK6MYFs0+PEJeyS9gL2yjURbMKIY70yEfhYEi KwgWmIAhHE9IwACj2EYUAhgMKE4gcC/ktrtRSZNeyAdGr/mEqYeDs/MhUDhqsNkGnvbmOOSB/QhS SEqsbyLeirFTaICNA1NqB/iqJbpoCIAi2JtQcIFT8P5Eai4CKByyNWVQE0zoHa4r+COGMpc58hIf xg8GDNIabDiwiypud434uMDUAcn8dgcpL4vw9TZaAYQqpQEk2FyNXu6VQFVW6zKbI+laSD4YDPcq txlEav8p/GelIPbYgg6IHDcRRJ7VsBoAamg6+pXt7a5Q7IvE0cyJCB/sAbOdCtCVTEDlqWP8gMKN cARjN/3AjuCDQMQ812Y9zboqkZX7QY4EfNtzxTtRPC3IP3OvNv4rAQ4FdQpoAxaA81ah7Jbc5OI9 aCWhhcy5pUiNXCYiNNuRcgogPTNC3AYUD9KF3GQ9j1AbzuBkTjcacQkHO06x4JYssOPwGAXrgxPc a6xVt3cN91kFyxDKUQhG6RYxmqpbFivCFvk7Izj/Uc5EO6uJXez/6EnYJTIweZi4dUJWWKM5qDA+ MpI1gIZYDno0AgMGNMEHW+ajcC05JFI0mBHcpb9xBGoXiUEYzmiw0qvhu9LQODKbB4Qzg4M+ACTQ Bo0JPhYeB0Tb3kqxI7sokjF9ReaOsF/kmeopKE0kBMofSEvkaKCRSeEhFpAQaePgl+PARghl11zk HPaQjDr2Iu/kQcqCQcbgTNGv4kkZOBMElJPQJpVzUne8Af1icBnbuFN7aEAhn2jAxnbIVzlM1MJc aFeNOJECBrqzImB+yPVeoKE4iZbPx7hXKjDmdA45/Zlmk5GGtlbokGTYtc/k3Gg8ZQ2e3hBgM9ls sypQaDgXFDtcZOxv9oV0EHRxqpgjd+hkkQOpr2jjDmtEs1O4aLyMv55AspM3wOMzpXIUsfeoKKng dBtQElMyU2Xpx3YTuDWS9lTzUHDzLsoIxQ9N4zkFdZ63mEQNxx2cK8jbOOZuKKhJkr83e1Ose1gX h6QFNlkkW8qN2AzIiAaFeKEhOdlmzboMB3fYe8swJY0nM72IZ8POXLEM48CoG7ZGOITYj41GUO3s MbcVWVx1ZREQhCMYoVjVFHWdrVBLhQBhE1QMSEcCGog1VvUsyWA+5As4yJ/FKzs893UUn41V5GgJ dQUTCN5ADmzCnV5vnFAC++hXPPFw9yJGqJGNFv5ZJtQuoY7oF4yEICX0Zo604xKOL1GhRINFTfjY elLQRcpoLnQ0hWD7Vi09s2FehWMez4CRDgxlkGQDf4yutVYuFFBbA/b+w4D7Aexg4Xp+1Thf9LBS AxgkllajU1lfYGotDgV5O3i6XqphdR2LD9YH2A6tZoX4F6pD5ABGr5RC21LuKlqxnGw7RQxbQwuG dGbwZFWcEvAgTohWFsKxyckEUpvs3LCkJ1i8QUYXQ6AtfgELuzRIYI+s7gZeFXrAXSkLMIMmAIHb v+yD/wZI9kUQFHRGoRA8AOVSvkiSHQzgfsRYDDRyfEMSbBg4uZI4Yny1EmjPXPsOd1cREw9h6xcY cil7F0Ih0ZANwhB5AwRiqWSV7HMIGxqLLpz/JFAAr08EDMA7sPk0vItMQMq4O8ZySgkwtFC7Ru5w htxbe3c5KwQHDHMDGvlxg2gEpScHOglAAbcfEYj055do1WhAw95P60sAGrXhkE3hrC5ZcJvQ+CQS cFKuXD3A9/ArcQ4SOE3gwt5wsWaAAzcYAcLHjI7t0M25ZNWNlAxTGKyaDSzgZdtdA+4tTGIKam2E luQLCMUymGHgiRgYBUdUs6JQI5f0TgpmULPGfSwpaKiRe8loC4VW9UdEiQRShlMtq2xabaYK8WGA dkJccIUUDMh9EC57gmUFu6wDwU5A6rAy42uBCjmAPDriOu5GNSB1IlMVaj0wGVRipFsKRxniSJQ7 eC4BiMlNjvMXDgAHcF0xktoaDjkak06z3C5wdZl+5AD9EqhhhNYRDKFNZ8vH6dDaE6iMmoklY4yB NbUBOcR0Z+KTjbo6VxpX82xIHaupFq4OXzwC8JO2aCg+Aq1fxIL5vgRtdRz/Nlj+R1hL2I39OQZX EilcmW6kywedtArIQkCqyyc0BibVaUC0V8QhagAkcRqpoV2cUSAdDLlW0Ql0EyEgBwOrJOFrIMj3 SHgDIzl7vlUMA79qJF9SWTR58IVDBssMjGEQCELOkmxjXF8IuLArOTjwvGY16bEybDHLIzfTRuRR 2EhQHFhWn4Al5wxeE51LRr2QAzAtIL0ZdSX8KljBkrOBKlhovD5g4AEh/z3JHnBHGSNVcs4NpzpD IM/RPiAIWCAeB/eopBBmY8PDrXQlJCFXMqyWjWG6UAewvQ5NycNho7I+PJCP+Ew8IlZHiP4yoCuW Wg89NO9yH9jRgV0MGHQUsWolesuJC+QchXqzNlEV0xjBO+T7ZgwZCDIIzwu1CX7RF0UUQkYwkWRb WCSVr7jJyQY78+wRsA2CUDdsARIh2CvbDiCeEjIbCEsLLs+H54bQzcBrMl9XzkMo3CG/U4kwgYpR jkJKdyIhiPt+NCRw0YuU/tFu7Ajh+k0LsX4ydXdBaP5NFI1eRBDLr0GTirU6O8QUaAuEAjAdYcNv MiF9yxkUAJet3gvIFAsZqg9vIA+YGAx/HMjEhBs/WACD6wIG5LYRVMgeBMgtDHfzzSUS2g3xF1SN doZkwxRFEAjhFhiOBWJeAhzAAsB8VH5pMHwetAAz/3V27PEOhrZAqAnh3wxtEDCOIkBXIbtQsizL sgJUWFxgZMuyLMtobHB0eHzqAjbEjYZNiThkeEE+96sWjqAQRger54luIowAKHRAAaOzObuJvrAS cIuN1f/2pWABJlWUA8oJAnUDA03oi7WmaPvBajyZWyqcWPsL+2P/HZzBmWvbZFlf9/nt99or04mW SSoOWMDBkFRZxUfKQsoQQqG8hBe47C2wBK6oCzBk266IRbIherH5Fd1d/KyKRA+/QJPrczB3BDcu kr80GRUUGhAZ3EAj1lQfODQUa+IcS1UMR3TB3BP8nv8C0YKURhqSBM7FqkMjPc0ORtSl7AVpG0yZ svPugHRqWL8gihjwBRkCTWNTIABBMIPDJJBnytzwjozwA4sFMw9oDHULj8Lesg9o4JIYC5IlJ5AD BNSSDIWw5NSSqOwAGVuAiAUc6c3SCURqQI2+HmjE7bt0BwVTagkUfGBNhBq7T5NsFLx4KYawKjvD b9b8/1APnsBIJP6DwC0PvsBQUEwGG7zaqPuYrKHayNso9ja/pEHajRzri4jNmt/cKdZsw4IFDfnl yDdLcoXI0MyBcUHC5RcGwDtYADmckktGQKM5giyYTKUHE73ZADWMwsVGA+y/mLSnKGEJtG1xPgYk vaJqICw5kIoTDMGVx1OPgWRKTrZEODSIe6F4CjleYCUPjr/D0heogQOadBlogIL3vyQDgHBcA8c5 WAi49n6iZEAEXI1EOBBEuFQBYEVlCMHx3zWDxyA7RmAPjEPk9rkgwZUu+cQpBFfkCGL2eSgMkHhs O0Ypip0odhQ5cliF0GAC6DbwirpBJPTIU8+WMMiFJM6LHoFssMIuf85ogpRwCR6e3B0IAI2pnciS TUwZJVttQ1XIcslzjAYLrKx42UgzC8TEEY18AXtj4QeohQkqM2DbiZwWK5wSjIcSBksDjDRhKfrC hATDqHi/qJW1Ehq0UNtXWswZrAfeggusZeAbDZArrFDsFjARpQFp5rWIAzLSYL1wlXCsLXshnFAS czCoCzgZfIR6nhf6K3QFSQV1DYt6M8kWikL9O/sPlMFBufGAur816iJIFwIKSHUcaHQ3653sXwF5 BgVoYJVv/9cZSyODWVDXWaCjgU2ObCNMqhlkYdhZJBzExOdC4grEDqzyLAaQwAS3PJVwYScTrDgV xLkgC5GTqAZVGWcCLCY4BZiF0qgRjZFgmtikizFZQq6QksTfpAbIBQcbG/TIdkJSkoh+cYuY2C7w mu3B5wQRhLmg1wfwe9VyRZ0PAhJyGIMtw1H2IJZtpgWDxxTEfwH4u7SD7xD/Tdh1YqR0Nmj0lJ4F 9mEwaOyUQhBAsEBCenjnmlqNbYO4hIoJTV5pSDcSgQCNLEamhLHDnMxZ112MOttbQmiQO8vXucpm U3Yz44xG39FatRVpVDc9L9FOLoYAAqRIi5R0TbxZN+RohJQ3UA4yEbzgJsIjtoxTdUocyCwxnBaz cizkwjOAIRZyYc/faHAncJvdairVx/tQU1UL3taBEMdqQWjdLDFS7R2xtppF2VCQEUayB6pUmUth Kb9dwigQjC5mNLvK/f1oEewN0M5QJXQHMKXkQt7iWrtoODj5os2GO+M64CiuQKbsJMEkHKyt5MJ2 HKpzy/JvEcfsg8dEi0XsVAJTcjuU/viARZAQQTZSIFB424DWgMawCpbkEy9mJWB0SoHCtgmPC0EB NAtEb8g6A/dAaPlKYVOHYNa2ZQMDEhdJ/hKCUBLYD4Q8BFv7cfeNuKEPb0XoVxUqVxcL1BHcWQFl EKBqBWwfAavUAtj9r9yC60PmA5993DlcB1hvcqu2D5kOoASU4ahRL/zUi1XoK8idyldRTgbqLFq8 vMEQjKAQLGy7vK/8W25ba6fjRB8Q2wK4m07BrvqLnaIrx/NT8NvcDYV0360F3sn+CLgRuVsCA/iU ou3tRehocwmNTZWDFCxTwDBF6M+C6xyxWtzbn6SguAI5JfiTdNvfE/5oTHUkV2pcF7C4WVNZbUfP dt91CBbrE+XrEdzNNfDaSMcHaVcDH29zHybNbPrcpGouxEKEro3nIXRyGUlQro2GY1WXaVopOXZ1 9iK2wEnAnkNQquFaDUBT7Uki9pXZFljkTggHDA2c1AwzDDz6GsNmsZBEg1GtFMgJDLhISg6wZjlO dEAGM6wYkqhTzHKkohhGJF0vAr1WdGAriYX8gJJcX0mIU79wch5Xl9yTYhWev2gbAwFUIN3Kbl2/ XCY8TGVvmRvjEgxRMwBYjc3Qv7OVtbJ1zRIZzGBSh2V0hlNwCvYHV4yxgk9/2Vk1BG+BrQ4sFV9c FiXPcxl4PfukoPDUrwJ0jF72VlmwigC3FwxWhy2rPRzEsbCy6gYPrLBcJflUkmBVW1s1NQjudFZt 5NUAuiE71N9V5JRsbNQBVlKxFW36OYUhIJZXMAsofeTofNNBWMsMU1c7xr+Xt/8u0Iv3ih6A+z10 GQR+fxQgfRuXl5dUDXRPCnRKCXSrJscqBkaVZw+2TPjQj8PVaLyDiB49Ce+yeObp5CA3Mesg+I1+ AUaPlUdBpOxWdHQRUtDehajqNQ2+mAixNhQswyDBDVaU9hvU+ovYWYXb2aIDgCMAVmRu/99++ExZ dqZ+Sj1qS191BGpK6wgMST1xgf8ty2pJX4ocN4AkN4n+VmW7I5dzVr64sYgfF9kLjSiiCeulVqD2 374wds0w/4pEAzwgdAQ8CXVV8pf8bMnA8IAnAFbU92KneEre9twKOXbfhIvf2NaFPyO3lG2I441X o4fmdCDUT9mLvrEZxgMNQ4BQbrcLhgFDI4vzSOD+BQx6kO1fW4VzGNETtVWmLNFFYIIU2NiK5gKy WNgQHmBPE0wJJsjIIZGPpijiz3xTvYLLUhwIFQE7KP3/Ek7BXpn3/o0EQTlHDHMJ2IUdzAhX/Dv7 3zmgrZ2/CC/ldZflZOHp5Ffw9nXofwLcMHJoxA2zQvfYG8BAkODAV0BC2xRqByVGxX5sOTcothIT r3SFGw9vmEHsvgZQNMbDdQc797K22/92A07r5YpGAYBmnkZXxQ+EPwsuO1MQU+EPK/4BXVNVqH1H kf5rfwNIWY6Xm70TDY6nbBs8xgYN6aRGueRCax47pCD/yLCCCQlwlSBEorgMIWQO4HzUzuYUmdLG YQEWiun5rPCw9P8EhMl9A8YAP0CAOFrs4JijoDlZ+jwBFzi5gkUBV0gCPqtCp7Q5dRSiDZ3otTV/ jXUoFmoktoRAQyoVR4Jw5IIfCBTc2kNF/9YNMF8Ia84ALYdduJE8YG7hMWpT8l2TSNYGeIm4bXYG vQB0aAmFZA1YgWW0EJbQUw4Z2JBpK4mGpOuKCALOCEQ8DZU4ZByhKv8UW7BYFCeVP9h/sINzJ4hV JS/re2j8lWEHOWFg/JVDUzYCNYRoMSG+ImZwU0Qx8LA3/SLMVnOZXLlo9FFhHwq59OtgaOyTrHhF cuxaf1K3CwK1+BxqTBGv6NMxIVjaCXQJ4QU5g3o9wM+zAAoLp8dKdSe43YYDVbvkjmjgBLyzVSb3 pNd/dDIPf2GOSZcgFCjbqO/WliBXxkkd67ki0DhjZC5fK1NqCZhLEbj+N0jmoXcOFPmME1LBAXLc FCkxNjYxDBUzwK8MvhZ0qbf0Avh2S9QIVyGgvG36K/qKChB3GQQgcw8WxHLXsw4NdAUKc5TbGo1S rQT0EYjf/V1tK85Jg/lMfhH4jTQXQEK/BWw3X3LBWV9tM9JrwGS3DbaC95P4VxRo+HWtXiK+C2/0 cEDrB8MEHIP66wJqBFiXulVHtSqAJAlBJuSSgCcgNE0t+ECDTjDECWiAU927GATHBsRiBUZcRFdU ulMyg0Kqa1QdVWargxmDMgQnLYE+kBcGFOxe0RQvJA/lVWmLrjoJ4l/mxTS4DeRgJa9OIAOVsqrb 2HqLMAvLFFbN7NIt5prUzLxZuJ2osm2oZmrw4x/gi4omHTb+9HUmD9SyGhPiWkZEAeoban2DamzH X0YwdD2N8hBRQCSU+9kuaSVqaGASPdyS7tjHWnkOYrvrCwhlgVJoW8F7CosKA1HbdhJxwh0wQB0F RNj39m02BSpBa/92MFpIB/AM6jAYoWEgBUw04AfmvwCtNsiEc9214Pq17hsCghThbwlQgk5cYomd mcqgFpbBGBG9IjEE13wTI8M7fGvcx0BzmGmJjIXkRBSlohER6AArEStQ1w1DtwAPykCGkgYrzXbO EVN/+akqeObcjdR/sViMbzvHGcAtbEB2B3nkhfZfinZ0gvTjK8glO893AwMWCgcW6VO6whQxrMFF IVTB0VnHjOK02Fqj0lmJGSQ6Fq9ia4UZBx9SzLmFhrNoIznAp+EwnUowso27WK+NUbiznIvFubI3 R5Y6qWAIORk93INh9iQSPR3XuKjbFtUENSsHackCCe6bnjvBD4OdxS44USXXMC2/5git4m0o9/E/ xEE9fCdfTejo/9ZNSZVbwtuCHj743k4hGCOikVOu/FlrXSnX7GoYJKoFyAS/vLTsKezUCGZ3fYhY /xhnCAKzJPop0vbZ2FZKcERKPhiIneNI20qUGGfKS/txIihE6AUdbJjg/uGOO1IM6xKWOgbcawAO B5KMILhwNR7G0o41bqOgc9YFgzP/tWQRG8VhROI4RMDcL9oRo1RSCDEYUQWrmAQxhRqm6Il5GtOp Cm2lGE4EOLHigDbhWhR8FmP81S4JUFpAl2eUus5sqELNhb8tiecixhwBq1FkJv1/1el4dZD8NQh+ Ndmh+FTJGBCwMNtmoF2FzKfvRX3D1i6ViyBtqXzNnTwyETLIbGhss7oCLaDXJlcmEKnYfApWaF1R DKzoCI9YVoriI5gVs39bKBY0q0wot8DlMOEGbMsldAvL0yxPBY9oBFNc9zSDNANQAhcMDaBgQEAi KDRwa1BlEU8QiAiueyeSagsqEHogh0CYCSdTgbyMIKhsVgkcGzI0OD9RzcIXkm82izJEsG6VJQuP RzzgT9UDVHWiU1doPNeFIODcpGO73Y7jwwHi+3QegYNmrAQWnrrHK8PjI4BbbqoN6BxIAYhXJ+oM OEhmh0Bq8rBor5AwElVElh9sKAbhv/oJFBqfuWYftXnYO9/qZoiY3WxIABcUCMZgzTZIBrlFJeuh 9sF250ZILgxTo4vD6xZZjj1LxEjpRAcXZjI2ZOHR4DA4oLfapxznJAIy4K2ZWC4LtR17OxiO7Ghw sOQ+EAyB/05PO9ZWLOkU75c5RJdcihnU/tQdzOpkcwNdPMPYXlmo3GhkTxKUPmQb2Jud6xdoWBRe i/sFBGgkEj8CH0eENBsGWkvQ/VDPhiW8FEC6FwJ1Zl/QyQ5T30wNxFvgd5XZHWZ3i/uD/1QVCx92 A+BTiSpXKvfrHrstwW0o64j5E4HuEdhjV8TXI/dNjyRCBjEvcYEH2SLyBAFq/NloG9IcsoCw/P7L meMRWnMSAgkRrevfvhmQjcn3O/6Cy3jGQ7RsUvlonyOUdDNQZ5Rx2yBnHxtWvvtfCt8LXp7VLBVf x19ZtFaKOLAo2VYY0kXxF9l9/Mmz4TEnrM/wgf5iARnQyV/cVovPVrmGEOA+ScC+pCv4hpwA4Evz 5MfpMQmC3xzbhE8wwAm1A/Mr94IY0SF181uG4FRBEyIWSICBBHRrB8r0khXhqcspSFFoAkKPkbdp EKInUdFWUOEs6DWKokjT5oDOGATAFSw1xUItyVGEXQ7B6cADHekwWRtbmCgJ3RR10cktBJkq/u88 JdiWckO8RG02/L0Elcy1E+0hiQb/e6twzS0CG+BMCLxdM/GEoglIbVI1rVwk3xdaU1+PXAcyMpBc pGTAgH4gy7jQVjUC+q1U4B1AX8HgBB4CAmbNVsE0HQBe11cgQB3ldytqh3LkbaMYiXNSqY3CCEsE SAtN5EhFOW0jRk0IiAkElyrJIPBKAi3L662o8azokMRr4iTuGVUJf5VrwmiAthH0V0g72DH7sAbb sxurzwMOVE4EEAOcLWgRfY1DASIwLsSu6Q5p25sPuAPTocHiMCmi3QfBUiTl6PguyFbHy8HhBFF/ A1CxViD6vxnCa29z32i/OxP2EdhqRAcGx1QCx0mYRRMdFFlfNIpahjMfAxWKiiWH4QnGCJ4QMLDj oTP/9lF0I7Z+Gv/L1LvFBypmEkcvEDtRyeBycXzm8ha/we9+R7D2VUPtOS50KVc4bgR+Foq6g7VT QjdkwjNEtT/0Xgd87lu4rIkuX4kl0jzIvgIIXl3DO0IZIACkeUFk+VzBEHlkNwh+JLbC2GGRA8v1 4EmZqSsYasXEEA5CUbJXxcHmBWMsNA6vzvEQImPbI7JPBF8QXhEMgJNVmLnJbXY2Igf2khHNkPji F0FAQdlXj8R3DVcRbliKRzRFxzSNjbAaoHPGzntvCSUMBqrqVhOyDMkXV/F1jULMgL5eU8sFZgFt QX5HNIvLJ0S+5LCULSdEi0dUqOV2gM8FR1hYQCk7Mtw3igs7QBuRB7HPZuo7UF53EE2eciADyBAQ IHQgQ8ggIDBY0QAS8gQ4hLySA28bbyc5SVA/i8HHAOAob1hBPXYAxwEiuExXL7hSkxLdKhMN3V3o d6FdAM9f3YbcHRKzuEDx3+Ce80XQfQjVwdR0/+OriCeH5F5y8Djt0McgYbeoR8V8tkmpE66DnCMR MtGgFN9bOt0cJD11Ewv6awYMAmS2S1lvCgwUCTDl+/c/8tHB6hiIEAYQiFABBwh6i0XwAohIAwdd yYooAapdKsIPthSEIMD3lt0IC8oEwVVXai62egy3BDF+uHDbM3y3Vbr4F04SLYgBRRTeecx8e3AJ u/jcDfAZg8YEAHpVJCcBZ1XMOFWNL8HhCJZwLh8/3234kG1mcy0/+GLwGoPi0LZA3O30Wdr/BDWz 2YoGwOADCkhlWf7HBQiIB4pGDIhHARACY5DblxQD3UYYkgBjUFhkcy9adOKSGSB0b0MuCJkoagQQ DIxtiwQFKDDsBLorLD9DAhNwTjgQEgl5JmQYQCABkZGXSIPHKFezJgMedLIMMWs3gAp9KgaJvwa3 sda+A4PgB4mmCgcIGkYBLNvSbAYMAhDUAxRmaAsgOhII19CATNnNCN1fGB0QMLNtzyCiBzAWGA2S 5ZJlOCBAKDRcYeFIywwSyQ3Zo2BQgXfJown3hfUI3CUYWYhWJ7bLaAMOJBB8EHIQK2EKD/GzlQ6j AtshGyCvGMZ72gDcBUZ8nUHBHkSEyLKrg7RX+D+zXr1gVyByUE7EACIEokJs3tBTLuBBKlgG0Hut PZAKutIgUMx1CwvBuybMKHS32e4LVu6tHYLdOgvyiZ1gCea6bxuOgAxex4VoCwNpDxvZ3MuQibVk DiBsmBDbN3KznXCInXSgpssHqLkZsQELiDRbw9m+SIVTUAYwYQPudomwzv+n7JSFVDa9DCLBO8bm dHbXiFa4IzyiMaX4seJqMEZaO8N9BQXYtq3660+4mDpwCCrIAsw1124CjGgGEBCsBNtcl88fK1R8 1ERk4BmdbIeWhAROhVC9onODJE4HUxBAmIs9wYcW600PurDLBhcsviDlcauYW7ZtcxvnsAigBbio +4W//WTARcDY4QS43GWw3sHiqratmSgHHOTN7HAVbMfxJzMd5J/ZxUAoBs5vX7v/d78Zi1AYudiB D7cxO9Z0DkFBgfneDnzvvSHCBJ4C+BR89MekHL0EFn/vrqQoivwMgu7820X8ob8NWeUwLRN8A2oS WIqDgVS9BdC1QW9uGC+ChxfJuQByCINidX7ffSPkdYoxoCF2vmg8mRsh4G0suXZ/GA5M0pzk4PSY 8NAmeQ75ALasEIgmeSZ5IGQwQCd5JnlAHFD4l5M8kzRg1HCwkzyTPICMkGiTPJM8oESwIJO9kzzA /JbvDtiGPJM84LTwcXkJFzPOhj8DN2oT7YeDsPNoLbh2R3bo6VfkO+T5d2FofJq3SA7g8pnkmTTw EAC4eSZpHuyZEKggfSZ5JoQwYEC45BmSk6Jxhwi3JN03B3eLeARonJuEUCTPJN94DmBUcGTPJM8w gAyQwCTPZM/ooA7EsAByss+gwLeiFIjbeB7IUHguXEKc+pnsPOS3JJyEwJojuexAV2wDIAqlZ0KG m0ZjdiCY7EpoAFA+fLt3yau5GSom/zS7mZBm89AwnRDgszmQARDweQWXPJBPVMC1FYnA5ABSkLXG eUUiRsgBeVH/SdQwDLRmgX3w0wd33bV/gxbYZoN98gZ3DUYI9ghz11wNDLKakARk7ciF35pUp2pK +LsqLaHz/d6StxahK9ssx2bLfvbRuegTitdo4SkVrId19ct/BE4sD/aR5pKDOAgHp8JGyeC5UmC6 hKpNJbgpd7Y6mjykA1mQUZ0L3JIIeUVUNkgWVPvxNKYriGA3wZBBR26RAhpQ/AU5h64rnqF5XTMB XbseWbk7QsyLUhOE3QIvixLnOxJpEsoN4mAjFDwtOAwEeY54gggiD51BcBgEq+sdBEuNlIvCVpeN EPCS5U3gUEB1A37dFtE12HRLHVNjN3s7saRZxAWFlrYHwScGJzl9hK4PabYjR+j+XiM31Ad+v5Mt G18rytEBLpT9ZLaNRkFnV7tgyUT9SYxAqLswljHhGZHZXgY7pKno7GvtPmgWLjBIFArAr9uaFLaX gAsLtXpJjSK3SY4i1P2xIWaIAJURJYwjxCgx+5JM1nLJyWExpA2gmc0wSyOBJsT4Zo6DImiQnaKJ mfWZ7bVrCiLkIWn7Zo5CJWyv3IhB7rDub7AYefZZWg55jB6RLclldbBPSKE9+8UI/sG1oEVp/Rc+ XMJvwlc2Yvhj5ks4wHAbFw812cn2BdFWD9gPayJctIRpaYEwGVlkcBClzJ7uvS6CTQcDfwTdCXgP HsXQRZpuWGAMwARFcG5BCHtcdZqxiy0Pev1VLJo96EVWorgStB7way2m42lySQdVnyxgiSg1ZMhY xYAJPpTubzOsKVmrCuGsIVLz7No5dScPdMZlmny1CkF0sEsoOKRbU2iUbFhR8RzBYEV06AxMUQ8F pl+elcT+cl+oAsXni/BXO/MyEcfaDxSA/EwvmJ1qjSBYIBAfyU7AreIJAuJNlHo2FWOsEVb3m8Ui RTJBCimsiFk0ZS9QTw5k2NjcvinJV36Jw3XLWNQFHaSq2Psl4bnZe63uthxFtx/BgcARqbpXIclH 21fSR+gCDkgvdDsrNoJYxSjYfowTsYzboxRneAbUIgRZtSUFhkKxabsP78z8GOEqLYtFyLJQFU4F B17aMDlVAmHW0Rl7arO94Whq629qRIQUXlZn2gDB0G+0U0kV0+BOgHIYEhIU2umWoEEIUoUmEAFq odmYBfZUvAVOuIs1DNYKWUKC2rQEhJ0rivHcDwfUs+g5ahiFsKOGoCVBWepLBY/2fex8D6OVOwPp Fo4GmqGeBDYUTicdL35xw4hYEDIQ6TLf3BCxgrxkQhG5pAAnPh6csdodvpEFpg9KGQLAGwnnY1gz qWDzEJBvcFPooGgAnmIn4ArWR0IDTjfrXgF87E2wSljTcFik81kYA7DrsG9ICTwIDKA6IxPwBW2F 2oPYYa1snXCDCnMu6dyBF3dzkOCbrANpDJCzVz+Rk8MmDw9QDpuFJAvFxN6cV7scmIgDr37FCzmb LCBXEORJGpJ0xODv0IABnEUTwDNa1Uh4DVmnpLFBHCwOdRxlMxsGwgBwbrZqQewIfk+VvmPgdFeD t2NQhW9d2P+4Sh0RNFB9akCJddQqfT8sdLKMpOTZV8a5ar703OKmAxQ5deA95wHQ83UF6Oy7XtxX uK1rM7cdha5C6Ps7H6L+AttzybDkAwWDfAgIA4x3AZepdV+Ix3RYUCZOgpjUbjiA4FAGWQEMAh56 d8t8GIFOWSMNgL1ZwADaSxBktjcV2uACPAKHDWA55lphCbh+FPqqL9Un9AtDwTxFD4/BsdTmxUDv Q4SczBJixz6IRe6Si9iU8RkbwWwDFWgUEmBJx9gEEFeloMYJ4qP77kvJpMPpS8pTJdwmjFhsDM1f HsIkH8MODAx1C4whQzIKCUhxqJqQIipc2GiTMP7rAukahCxq8UCHdeCCM7xYeOcxGIOQO8YaHjMW go0m6PzUSpX6FjUi4n195HQJccLrCaCgrumyYSykys29cThYf+wVUFrHBCRAdxt+6+IBiL0A8ASo ylFE4lBi3fSBAaFku3RZv8JsB+AxxTy4BQLSNz+saKSfy0+8IVWcQGcN0hDhYEFN8JV7nNzkq2CM 8EkRTHjwGTiHS7yiIHtOLnCEbIo61ZCfbQhQhR9wSo0zIrZWd7R58A+3be8Jgh2wqbTTRle4DYxs 30T1K6CssGhQrqEj3GgCXUtmJRBEVH0fiizSfSsTYJEkqmTBxEcKkhXCw4rQhreH4Is9qESUh1Zo paCfrYFoBna8EYxAjkM+yyHAkKCKrCZ5tgg1mIIQMwF+WJxNAbkveGjrdPAZ4VkMMrMMfMdFvYKE 8A4cE/I9CTIEgyk16SsZIfKx8EZoTIQMZC1UQEyETIQsGJ49G4ERNsYHM5Q+tmIQROTPVsDTQhkZ 6QUQvMD3HA8RzDDz0rCLsQB8pKmK7VmEMjsw9ghyCWpzw3MnW2yQVzScEhoVNeyPNhS1DOsKPPMu 9kCvBTfA4Gi0nqD+yFqJgMPDaD8AD2QB59kdAgg3wZFsvDr6nokbJohGpQjkGLhT6zDjQH8F2VG7 zHzqAEM5ElrWJk3PCAiPhAw2QE+PAcJirx3HijqTja0XD43BSJx5hlxeQsHwVr1Is9zriCmIdH1D q4YkY7Mk/FH71lqtnC/UDuAAsIZspVd4mBIXIz90O/7l9Is912ZISvI1BI4J8jqAV7Ci9FHxog0C QQMLjIKTESVZw2EF0QWVKlCxKQjy23EZQMPySl4J9Is6i0Z0JIgQphRX1emeAE12EAk4kcsGaojY i3mMl/JAHshguHC4gLiBPJAHkLiguHkgD+SwuMC40LhAHsgD4LjwuDyQB/IAuRC5ILkgD+SBMLlA uR7IA3lQuWC5cLlKHvJAgLmnnI5cXvJguIzBjTpgupAH8kBwuoC6D+SBPJC6oLqwutkDeSDAutC6 okCeITlKnQi6kCPQc41k3djguQ/kgTzwuQC6ELrIA3kgILowurnsQB5AulCi7U+g2QCI2I4HeSBH Lo41sLnAuSt5yAPQuUWeEOiZsLBXX3TYVjhacpC5OKLQ801OkLk0lKmATNgg2KA0uU/zHMigyd5U UHoBOZC47hleySEE2I8ejyoIXrFC7KGHiAfdV+j8mGBTsUBjDCuNPETf6CUcB4pNrQLT6FlFwLcL eYP6VgWIFDNLxW+/vyQzAEb/GYP+CHzbroOh2ArQwwglC71ZqBaJ6lPvSP+3/67gA8Yz0ogQgDwX OwqxB7MBKsrS4wjkvt/aGEJLLepGg8cIQtc2a4XcGGRAiR4xeA3gV1VSfhsh3tp/Uzwr+I1EFcBC O9YXmopMGRK/baWoNO0ffhWLzo1X7P1f+ovBi/tEAvOli8iD4QPzpIROaSi+0QE9sMBBrOhv/393 uCgLsQ+L0IgKgMEPQoD5eHL1q7sovLb+0BUhUD02U2o4HKDubsEReY/CwL5EHI19tDZgFxcS+MgX agfsWXtrrtoM9EhvDovzWR3b7VZt1AlStDLmRdAH1C7LsmwF8LXR1fGLQgC31jm0w3kcwP8XoMAe 1wT+wopcNbSIXAW0LaLWdAfU1CAT/f8d0HzkrRyDwBwzyV6KVA3UQYhQ5Bq8RNQHs3pOde45qUhW 2hwwJ5tYLzQTVFJdhvR1gEW2CmjyFMB2xwCa/FC+MBRqIAGCBghLX4Ss+xZRBU9191ZIXORE5aC4 DNQO21uhWPUXweAGKwUR3bC334IQMBFAQXn36x8amIvCvdvb0Svkkui/IDCRWyBoo0Sht8ZFCC7c yo2bEAjNRQ8MMsl7gXgF9SDigMICCzuyHGQ1ygE0ArEKOawZrDMiyTILBEZrOGQxCBwDy0y3Uim2 B8lNoQe8CEbjQtsUoR1blIrLmJxi/3CPmu2dCsaEMHSxEduoVKQJpkuxsN2+YQR804CTBoMkBC0Q BhNcsAxaIRmgnHQEhAg4XWRoD98yO2RZvpDA/twKjfLIVuIMcLwz2wKiY6Od/Bd+3AGcjtFKYNds F0aRDv8ttOZL2FxDkGWNTAW8Mnth+wtLTohUBduKA5uFdeZDiHfnNnf8dSImWXUV3IiQX42iV7oJ vHZ3JFVcgujhN1lcsqgF84pFC78AF4Cbqtr6WcheSFG8RTRXx0tTQOp3G3LRHooHJYrYR8DoBC4I /qUEgOMPioAUo2cOVSVDFO3HZbDXqg8jF/BqFA2T8CV1+1JFQCCun763wkXDvEzIiolJOkP7jS6U dObAPBBy62tQnlE4gvXr0ehCP6Tbq0inLgiKBkbj/yO3NoGrClBGwOMECsNZiAdHsAFdaImFdd1g XaJDXbIKa0BDTLFwBN+QERcTIpncIdTBUVvhqSxUqIpxDCbwAvj2Cw+ZK8LR+Ag793UVoA20sG1H lSm9GEWlmv4wUl0XsJbofAtHUG7Sw597CVALm5tZv6hZDBEKaK2AIPj+zVVs+gAtEIhEDeB0AU4q ESUItZOOAbM6Q1dWapJKWZ46gtFXdowUp6OGGy4SRW60e4hgxZLY16uKJSlMQJvXtFDt68pdGCKC 3AAxEBdLyr1ZxT4K/zrFxozf32Gp5FwJumZHUlDvICeDQa3sxJADGEzDU5VyAhghB5V+lKkHPd0i OphRjBN9VKz6RkEAFUHM/yWYIyNbAZgFoJxAYhGmcjXiuZmoSxbxgDCyHgToAHRxvlBjevBIgEEX nc7Ap56dvOKWL9FYf+hf4H7ExEQw4164lFkKcLWMKwVGg3IYY+LzGI21Kg67ERxMfkIoWGr8lgNF YBEN1aFTv7SQCPfHBmRZoTxryFKzEFUcUV1AIwDllyRoJFGPvciVjrioWeuQE6IvUIO4DKK+kJy7 mOi9VSQ7wES8WPxzEWfr8blETopDDBUW+1Cfwwzh34UQKHu40LUPyLMkz+lY0pdzCskoBoRFRMbZ 2ZdE6uQr5OQRyICAgHQ+jwC7+OeY0YCAyVXyQphbdAByACmgmRMD1yPkmR+h0L7fvUCF4gK7Xwdo uO23QdAQ6ym7CHU11SNBhb5oIv9x3hoe9rJFuzBoralEiT0idtZ96yU+BguDBWJPimaCPfftORLG mFXUX0s/w4kiYCXAXNo2AlSsC37Xw0WEwrlsFDjJCbiYRBybzh6QLgXtOn5dQ4vMDFLdGqKlY6Pr ERF8MT0EucAcEdIMIEKQa3wOk9qZgl4ZXnUUJE8VvAw9CudvPp9ad4Zi1gJfqAiaVemZW7R3BGdq CmhvmLnYs0u48B5yR3eqU9jHdIQAYklomdw4AogQpTgbRvVRv11KiAdbFHxGjQQ22ySWuKEM27yY /IFPZoMn9SNfCzSTRHUiizUcDmLrHhyfDgUlys4eFBxN22JlV5EIuNksuI1l+OVvG/m3U3VsJAwz 2zvrX1pVZFgVg+07jXy+V9QU2wcEoCJTU1dWgFUO6wpoBgdIej0wQEZG19eP4iP6xV1bVmaHtiPd t/HA/wN0FgUKC3RkV0YjeEMVHMCbon63DOscHHURg2aJLarmgj6mBmMCkHu7DB0DABUNZUNMKGBk bZtikAWcDPKdCIEwKWhIPEGcIXIEM1k/QDtX2kecJsZHdA2ok4IO5NgEAHlSpLNunG11iyrYTWSJ TmbtzFWKVghMVPaI3MBI+gluq8MoGkJ2snNgFpxWTUzhAFA5aA+LVJv7dIIudDtHRopEhVzI1W+u BHIt99mwKivRQKGFXOnu+hnVm+9V1wYQyoPiA8503c3XX/OrOgYjSj72QZbeX8OuFwGxPFlZbsBU NFzMPVde30xFC75gSNEDxjvFrm71/nYIO4mCeCH3xxfOlQzHC1thqgvR32hyKbn/JJVYrkA0uttb 1H4cg+mdLgMDyBeFZtfcynCtHo1okAfsrdiq6bqABKwD0CPqBq25p6t+AQJWCFnZScaWxsdczI1J K3mWZWwlAQICpuTrziaQI0YhRz+MmqbrDk8GPAM0LCT7v6ZpHBQMv0SO5IlEj+QHpmmapujo7Ozw mqZpmvD09Pj4/AoeWGr8m42wA3XfIbQSCf/wcAN8JSJH75QR71Bgs4G9kJ0L+RGYISG4ow0KK8kg vH2NdDFnfDn8fyQ1zm57Df3j/HfwrxVOJuG8742gr4/5K133i3z4riyQCAQoA1CgQgEyHzq35OsW 9k5YT1a2S7tdwrAfo+4C7wIpeMsG5IyQJyQar2xJqy0DrkXXXZgBQFukBqwDTdM0TbS8xMzU52ma ZoSvlxwcGBimaZqmFBQQEAyQpmmaDAgIBASm256wHwCwBQgDGBKcW8IssJe3tYeBLYTZD4MTyy4m hLdW/L1MMHfr/JXYCniLFR4NLAb2S9Al8Cvy0jvGcz1SHU7miCCiLLUT2Qd1CFUELDA0+7/vKw0b owTB+QKNDIiJR76tt9C9iUkFC0zwSlU4GJmI2/SgQXhB3R4WWQRIw5WxAvUCfUxHj/1BwHUNILqs oZiDIAATh3hjCKNLydMvwAkIPlT8ZIsUuPeHHTeLA2SjB+Ra2AAwKghttOCCtT8DvlhZhwQkDQZo QO/3QUJkoTBxk6jCDeNusV3tlOuiEyK4bGLa7Nba2CT9XWdBBC1bwCy2lUxpiXJcmgPXncIET/yN PADfEIrGQxQR+70jyG0LNyAeFDLaWESToOV8EOY2U8HsKRz0GYksUtHy8B+yQBOgzNEIOOyDh+AR R4DbUBhRZcXMCA3WWoIc98GCaGsi3PxRmHB7cMEG8pUng3B4x1uwuTSueNjI3PqyV8vmGsAY0joF 5ByJgq4s6K7sUdPFqBv0A/gFnszJcthbiRKJbfid2NglYMItIcwBhWA7E7BsBRDUQQ//MK1Aq3aD xn8hwk+FJFyWzH10F71YHMJ2ktjrCS/YzswidwhG5GFH785E7KbgZq2vx0AkbuZaFwVLTQQQ7XgT ztgUBRABCm7jw0IEdXgkZgsTSzGOAeuhQjS0a3pMCPcg/2MYTiBq20NkClq/dyFfW4ZCbUzGX5vd g0sdbLb+OwXHR35OvrbAZioAhsUuBY/vuwQmfgUeDPdNpd8a8XM0R33K+i4URokx2aVfaAVzATtH DHdr8HZHPXCuuUN3Qe/bKDcy9PFVMI4EtJ54uMOVXZpAZ/eGgyk2lgbuAw+Bm6pMcsuJArhJOyB4 xZ1pav4sHErdaAxAZMVRYyVXaAvuGQdYLxioNf2/dHQuO5YkdCiNNHaLDLOJTLpIfN8iuhd8s44S aAEBLbMR77c/PaS+/1QI68NkjwVDs1AoikgcxQ1xR4b3gXkEaHGOUgw5o7tXaCkgm4pRu9C3a/sI tusKCPBLAkP5o7EdemsMWWPvahlRQ4O9OFDhpYns216MXY0DUMM885kUDNzfvgUIacn9Q+qBwcOe JgAXhRoUlANXygr3BLh/cH/MQdniVZLL/7FUuqd+oWaE6mY7BfqzOwzoeZrmafgu5vYhqmmepuLy FODwzMZXR+eh6BNF+DQ1EJOCzMIbLWwVT+YSIc6OC8LRx7IF3AWaB6l9bwWOKlt14L9Cpedr/NsA X6NFXlAPtxIE+gnieZ749vLw6mhsxLPHnRxLAjILDhr2GwB9jmoYfxjhjaQk0v8fV/fBAw5itlT0 igFBrjsON/rfCIoBuv/+/n4D0INpM8J04QIQwKkA2YF03Vy/u+lB/CYjhOR0GqldOA6pl7d/e2Vq 682Nef/rDQT+6wj965UH65YD/GAMXxmKEYgf7AusZIgXR2Lu6wWJF4O1WCmzZ25pi73RbrIRa+Ev NIQ5J/fCQm3sjWkSB2rHOO6SbXB2ZgjGswAMGewF2wiIB9/eFMhiDDlAkOO45KS5MiQTQUyyNUY1 K0MJ/v0ooyCT/G8ceYGcyLjgt9i4crlsnly48LccuEC4PAA5BMi4yLiuG2yEP78GrAObpmmapJyU jIR8uHceAUZvyLjwGbUy3eAD7OBvISd5AGC6ELpcNkdOaLlguni5mLkEciC5wLlgug02CnlgulsU 0zRN1wYcAyQsNDyMAKNNRFe6b2jTdScfcAV4A4icusCyIcBvzAAOOmji2blEpQScWDJsgvJWC9eq m6n/9v8xwwuKDjoPdVJGR0h0HQqKFzjRdUWKOh7dhU7tVwEJO9DW6FKVgAVj45kDpVt/wOA1K/On UotOqW2luxYfJRA49aAWEPSWrlQNDQK45qBrLW5rX4OlNH3EBd5+oysPOMp152MYOO6Q3b5fbwYR geEVgeIFOzTNSASmO8xer1OwSv+Rrlt2ilz9whKKCkIyy3RsN9rrbTwuEf2XSRJXdvm+VKDjCAPf BhDrF3bxs0bUwH4tPkh19vJY/ysuJ+mLCjPLv6v5g/FCL1fiz4MDhKyGOlfg7kr8KyMy62LGCgx3 a79lqchfjUL/PQT+XwVeuMzI/fyUWtUQnSv2fX8WSi5+IMCka8kbWX8aXOD/dC3/TgR4CosOD7Y0 iQ6PLsEHxxq/WbIJbDwKQFOtF3jr1zvR19tbPSui5zXJbRLDpX6GCsAHDcwLxAUKWxH+AhgB3TBH BB4DGsqlEsW2m274MMVWARyCDTtqQKkSgIsjY6xzJ5MFf4tquPZGDEB0BmW/WcF1HKIFrOhD12DC zgwwgzYkaxXx5K2RzbN3k+8KxerTjXAl6xKLRlgABogcTAwtc662Xxw4ZEs52TvWvQlF9lnEeq1j joBZAnDVLdspgAXHtw0P2GitnnjN3rhEU8OuiPciQi6q8QFoEXeXgPlFwEK8oDdmqXkxszuA2Fs+ K9ImV1A72I0UxM5x9w4uqIAqaFuVbV+JCJug3F83Tgwgg8v/MLiJBlkLXgAp+LDnCHjFw8UTD/QL 8HbQijMROTUgDX50oQjIAhnuNk4EsPpf9kAp9eRKxb7MShhqGtibbi8oDPbBGDCDbQF1D1Dz4/2D gOAdQ+saFb0XlrVtEyECixroC/ix29hjQf80sE+cSkY7c8Ox+9p8jImF6zkUASOcEIRHQZkIgaPb gFnRmPiNZ3xNY023IBC39dgIjdG9p2ZhjMM7Da74B3xHkdoRowTBatnB2+LwWzcKF+7thscFRKhB Npu7LIzqo0AIDkj+6jzNt/kYTD7qIlDmVKG/Tco/XfSb2X3+m7u1/aa+/oDMDGaH2W383330Bf4I DZFvWPSLVfhaGVbS0puJ0873gD/eWSmgpe2tfYEBx0movTdtazfV/Mc16MUO+lACZ9gcwFZofhAE H8bWQw1m4lR/Mqb4+aMLX+oOft+ILusPVzwQK6K1RltJiawnFenw7Ithp2rrWTJZB6NpWA2z8KR0 PecCwdhqCY1WV+UdHWcfiBPG5UgZ60BebCWabDoJ/prkO0WjylqN+KDQIPc9/BD67WGX4jCC8Drr dumWKG7LdWaZHmbOStTAdt7rw/aA6hq5RigAGzUqHXvLShp17QIlyDlAGQI2YN/eEcM5RQkcRuvG tSULAMGWHo1GghgMN0Eht19ZQDXj99Ajo1RMgMZMCrZCc8BemZa07FKBaOSgGKlX+slbCQiT+PaH HopRAZVb3j5pEpD6weDHhrUK2xKlcW8LLa1J2JXoDd8hdcVcWWEunMYW8ME5p7sDYoDgdyISBAeq BoJovRa7s9pzsBAT8Pje2QQIF4Ib8VSpM3chkzTh1Q7ocwwwiKDroaDaQRxdAxkQvoHbxg+D5vCT XG808JqMeaJVag+Edlh3EBw7oHUZdhwDjtwgYE7xHLM9aAtwEBD/TKZsG94AHjqAGLECe0L2gSPY uhMZZlUcRBhDUOxSUFT2hhXADb4YEEMFdYTJBr/1UFdUOUKK+IrZHppud6vCPfB5chEI8nd5ut0N qz30B+sxGfYoVniWp/gf+hfKOkc3RoSL0AiFv9Gck2+7B00AjsFF9oBT7xG7T8NFALYchCZ7QQ5Z /kWK+YrYi/M1NQY55JA1NTU1RSbkQ/GKhrZhaBRKdbi8Ncau6TWiHG1/GPSx+wMNqHELIfdZfAdF Ey3jSOsKr9HDMBjjBfyGEaa3IZUf8ixZWVsgFBBZ8MIN8DgedFViFDgf4nQviqB99kKh0faC7Bg6 Do5a32IpVTqddBU4WCEbtFvdCnQNEesEFzBAewhb9zgYddEDFjAGHQVGTt0o2J8EdbFfkM5Z9pHs dDIhHx6XC84BqSUg8oxLGnxSlBSL/lZR7SsUqeC6ozPqI7iZ2ncvB3WJi9a1bRtceAg6y4U4DIUG iBwL+La2Be+JDlZKZh9TQalV8h3wuvEep5SR4I9sqwIWgo3TficHTX9mV6R28wwOiw1gAopgE8XC BEFLCJpH6018q62zNz/+LYvuGv5gWHuFK+UPu0OcPWwjQlZAC6E8cG61UbMEDXSb5UbQVtS2+DDr 8/1Cjh2kCK0klYC0TQxhWBLgFHltu9TfrIPJ//KuQb5PiuT9CQo5ePFHOAd053gBZhQRIxwosSIM JVYpytohiB0NtkawFBRrsyixMhTggOKtEbbgD4cqAtrJIGtTiV2oJ5WPcJT6d0LWzdMRBO0o68D7 6ysFqr5jawNZgCKLQ/xIFNBAtZxvUzN04I02U4KuDiF0bZB1dUAaREMe2ENgkenrJwkuO7AtUFlR U1IgBK/CQXUdjfyutoa1J1bVGARcFYmADQC1PG0hyi4OW1iLMFEnBdDaVzuAt4iwFeJRg3/JeyRM 9oa7XBlHQLkIUgGLT0DsxPL//7+AH4YHmff/i9Bp0oDgefgD8o1GqnT/d4yAM+EBO/B8GyvwQgYU Bqr9XoCF4gELBUIMx9baXopbRFEUmUJRqUFa/Xe0BjaJQRxpwICu/v+PXG5FFMRmtKtRHO43/kI9 jV8EORN9yYPDBOv2EjET8bdIKhBqBysUh3NCJVeiaEuRilbr3p6pPGyTnRAOABcYFVwzL9taCPDx /xgQ9rYA0Q8OPImDYSAiYNCL0jGyfhJcdWeKbfD8DL4Qml2KLapWM6RBEmj/VlBf7RBmJfB/Zj0D bfexoC3dBcisqH0QPQSCAsHdHwkUcCM+cfrUtX5PDX4id9Z1AbRFGlMhUSK9De5pahwf0k1puHEV IxHckj4J2e6C+gIVK5SK3HuiZQNBqwOBBajzPRFsSlGd+DT4ZVd6M0FYvC/0JkXgzOcc60cdoAhi uwvUZgqP3RgM6x0tYyU3+4TASBmtG9wEam7ZZfh2Ext/aJeAH2r/aNBkGygTBCAmxaSppcJRQAQe tQGxbRgblK9NAbReICLFXngLKbiJosVN1v9VFOPvtmdAMQi43hfwmAHNAkAGC4keokIRPbUFMti4 9n/gzdQd9kEO6HEbbiuxKs4KdnTtcjLnSsG5VLEjenUaf+OUCEKBOGNzbeDfcaINJvyXxuYpcyTC QJoh8GSNDHR44POliS/UFXZFBoL0VTZ14JhFkSXqZBJtNoRsLRBlWK4xaGX6m3Az0orUiRVIWTy5 zRWgTiCaRA1yf7YNewPKCkDoEKM8BxgFx7EN5KNcFkNiMvb0utFZuBgQELP9QFBydgEKaF9sO/Yf aqM0ugEJNqMswQkG6QRi2zbRjrxYK9DFpMG3Y7fCvGAbBdjXnPZF0LtNW7HMBn7UrQpY45xWPhAp glaJC4WmcFXw2yOgCLyFURHuXljcCWmYUFE9BGBZZAqz9W0wmB6WhDT7HdiVSxsMJOEIXWjlzJlK wNhZLySCbrAhWSVAw8MiBsgxP7uYI7HhE/XHBiBw/zcaQE8No4pQW0AKgBaDaBbdbyl7NAEOIjxG AlpAXFQld2WnCFdHExfB3PYwSOsGLgQXSQt6G8WDeRcBRfwgBXB2cQShw8oszPbsKGXFahtpQGSb wQn4dgRZSJ0bIIedQOde7rsN+oAdzABRPQAQ4n53vESvchSBs8weLRCFAdtCEMcXc+wixAyLowO1 huGjQLc+Mwr9wm05MEECEWaLEEBAQoh/qaU19qfR+EjDoeij1Y4foXD/0GiMkLl4kK4h32MfXmh0 DgC2toPQgcMnN7ynEAz1qgl5AVdlgiB0U7M9eMFqKl8RNyB8Yal4dwMRkxJ7iT10Iqo71XeIHXAo POuIIqBgqbFfVun8ftXP3oUTiwacg+4EO45z7bsw5NmZmJCTaKQQKmyw5JxMWz/EPqKvfF9MiY2z Wd1mVRFqDXUIbBekDHr1yHMNcOmoNZjGeGoZCRYuAQ4MmhDE/AEOidYZlKMZl4XhiSuAlfC+M+r/ GSEYV78gBZMZOT50PxDBC1ti9p9mdB+Buizwbm8DHGlqW214VpXwwRJ061b1f9ayHgxQpnUsOXgU dieLSPQCbGwaSbTJsbZVJEISuHUmIAIcVj9qss1uwNGb6x8XGiQ9yu0CV75YHe2KzXJWkBiAQAix gRKvhbO6GDvvqWK2xHypf7t/R7XEYMIeB0t/7Ua1wRDlYnt1XQpF8Vh0vVdPg3hsZ0cot1cmH7Bw bAdAtVS0onDKt8aT6rywPQFJAQ5AS0WeQX5R+QAQC2e2IJcd2wnRIQxAnzYIyNB98E+NGOsK9lfu GJKhtlTNo2vYdDsbLKpC/2+LMDt/fDt7BH93dAXA0Nad3kPWfDl4a8R+ZD+ZDI14CTNYWPgR+H41 djI3grTBGMDAtfgaX/jUgG5b4jkef+GP/AWiAmjh9AB/wuskcLHOLGDselM0gOSWh0lrVsOwLKTJ cNMXRBSsvzSA6Igkyg5DC6zFNGlItvdeFL5JRvAgZvDwwAvQ1aBh2yEcP2toSyE2muXZsjO+okAc c2QCWRYlHPjwxKWIf/hzTzs+fEO0fz42Gih20E4QLMFn9Au1XTtkBoDkdSaxZ/DYyjpmauVQbuuQ iSW+6MZ+qRIDGZgFVi9MDLDAbYB4RI1QZEFktri01GDOwUWDwcFS9tYjOwsNvCL2BqIF9gckbu/S xBibFKgBDgQJqIwHYtkXCQL9A7o5Qk5iw21IDCh1ETAic/+rbg2Vq607rnRV98CLYXx+BTt32jwM AL/N/27wpAxoTCx+caT6xcwz6xpGt3OvrUhUUTY08FoWFq1E6xliXQhoFIGeaVWPdpaBHOsigM1s MvjYw3AeLGBrSxnd0lfRByx1QkMMjl02WFcY0YqIAOp1Jxx7+3UoQIlv/3MMHRBXccLfA9SZK7cH h6F6XcgRMggYWBxkoQ1oGdS93BukLWBGxdimbArhZBlk5HDgfUMOlwZpeMdNQEhwN91ZE4CEZVOz Vl4JcHyEx1X/IEho6B0upTjUHwAweUJWw0bVGRGtkrLxpEr1OqJ2Ys+WbbAyWNuWiZx45INajcDm 4IE/EimzAKXXuzQjgX8Um6uvVVszgYsF1NRPJTRIjZLzacPxtZObuzcZg3gTgXgKDhgFcjSCBFzf XRKFUTJwC+rZHmYr7nXhCWu49T2bFAhgClVcfBAwsPGhzvYB2ERJzHcCmzN2GAFZJjCF7+TbE1cR XB44RqDyPbWABzQjUMCbUmnrthDpCBVDFCkV8kA6x1KHS3PkACi6D0fSonYUJlcFFmiz1Iw9BD7d 6PuevgcitNPG8OuXYA9zABNVdTpX77lDMox0flMzfp3sZGecUF/rZjl0Vts32IQ1SPl4DDvEBHMU UYB07GlGa/BzASJJoTvAGZKadAg067zVwMNUsJxREsmuhig9gGXNSHQmhYobUQQRWFnsD6lR/3AY aGErEZXoHDgtfWbxwgQl9kBaFXQELVHd3cTWhVx8DRgyoIsMDotRBUrMRVUAFZwVLDpR8WHqhsyD VdRNbe6tRfvrpLWagW2L3V0Tlqheby7rgfkEkQIUUSr2uSEpsAV8eq1y0GHqYYlv6heLo/BddDpq dGpiA04oGpA8KdEb2SpcGRdoGDcSEGf7xmxZOGASenrRtzCJBlhe2iXHh2BrlwLArhkGFMngPaJw j5tG+yizuWs3jBs/bCk5kiMmFak6WG1q67msWXYiOWFyhGGxkIX+mtXqBjlwYD3urCBYhWZgG3vA CsbrCwWDx0Lpor9FcnYPHWCoNqH0LTSssaS7FuTbBzEZMIBVmDIkFbzpHYyB62wHS/tGD4zEwNzd yIH7igUPj5cG20ULbhe9sOPj9sMEJmhBfQaD/wKDdLtEuP+Fi8ONS/9pwG1sUIvWx2jdqHj4A9Fr A8JBGWgQl7wMQCaXDb9CvwjIa8k8A5wFDQyhTwpaUQdmASjgbsDfQowRgIFVfP90IBRRgXA3loM9 ECFvVJjoWeX/Oml4BJvN0TsUi8Ggb0uG6tSh4qoUG151B/VWhqq4ruc7xn2EEsW7f8ajGTHhiicc dVmjHKohIWSPWu6JGBjX9Gv+ZBozybj4pBUZiQS1VCG4V8AgmoincBFvG0vqHLoIpXaCF34pvP4F g+AfGLXAxAzgql9pBMCLBIahQACw+9+cCv+DwiBBgfpoLHzR8fAR/5et7YA9cOQF0jR33+KNrrlq UXIXPVhfdxArqdeiblb4BWr16cUiQd18UKUudoqWvWAUfQse0yIOmchCUes4nQOZQOs4WWCpZh/6 g0rHu4hBtKhAm9cKDLXf0aogCkfKlgwBZqkDBcS/yg2yARHzWas2V+m9LfgCCEnqAY/a8ZOYLwDR 4DMoatL2woIAtN3QdTe0V4P5EBd+5LKwAv9T4Ty9DMmNPI8CUIHeSb9Ir5QKW1uo/YDhgoD5MNbO eTuB1RxBA/ICvj8iujVaMDsExQTuDmhQEX1Miw5Iag5EYwBAXg1V2ygWqxAbCaMWxQFwsCLvbfxo DzXUw1/kM9u3+Nj+v0Geigc8YXQaPHJ0Dzx37iJ6a4Lo2bnA6yDJg86XfnWLwrkJQ84CV1qKtQZa +EcBRzrDG+OC0wduBQJO7evfVH8Gy9vfPmCD6Ct0RQQZdDYOMbO1U9tITKzSYQijY0sdJKKDySG3 FI69vX0gEOui1kB1fQlA65j7QqlW7w0a/oPm/A8nuKN4AoHOhOuCuD7QYHv4yHVZC8iH32ViqYW3 txLjBwt0EgQGdUAT21vsG407gM1AHmP4dS5f+MlaQD+B5v8fFpiL4JAXznMWi20RuDqN0gtBiCN0 ZIBopNMQUbqjhZHeErvIETvLfXYsmD7fGuq/fOKJcG0FKBboWKgECDwoFbQCHPmA+OmRARQ5HYZZ D475YACumhg7w3Q3sw1gsnUhEw0bJAA/gLEwFFDgBPpvPMTrXzGx60RqOMHmAv+awZ5eMrwOVgY6 koaZM9YwFTpGDcvZJzz7OE/zbdvK9olfBAIMvx8EHLYg1SQABVtqWq0vwcAscziLzmr3LT7IsQkM jfZEgQTlP5ubgB20ARfrzTABGEpzS7sgDBV5UQn6CjiLzfiCgyCUXDmpLlrqA/Q8+AG4vYZ7C/8W hhZ2S3RWqtwfWTvHpgtQbQbPRqdgCvIkjTa2UDf/HSqjOI9kaq4fB8F+WvaAZOi7RKWIB80MV38G QDrUqQ5n8yFMS1vDqFcZwfFEQxX/ZoFmDPf7RQYRYapodC0NftQj/DsdwAVzcgsNLVZyY7NiCxON zYJhgTQWB5URMFKyZ1uEUxARWQ8pU7pGNBNyiGHw9mtNSzjCFRuJMC13/8BuRIRTSWDrDhgKORLa wJ1ACEYQ5CUYSiSXfKXO1hSzIkaCqgQy3TZoVJjI+ALwdTwYOhaN0FwYCRyDDEKbDAoDIOMAhVLg ywoSLUShp9EDflOA5fdVbEDBRQxSRfxDFyD3CA+G6hFR+//QF6hoUPwnbXMpQ9QNcAqwigmTe/sb VQfoxgANQIgI78iNlSmztjP0K8p5nnzM0DtnDSjQK/j+/Q1X4GSLt1Bx/zQw6ZBDAApQLV+OqDqg NuwL1UVbr5U6EnKicRO1kLAAfzuLdGJqBV45+kxiwoWRF6HrQbomwe+KS8eNTfRXUWG3wJnLZAvR q+unGQaAZSyigRCNh3YslyBAlsWAWtjaOBoQqvZibU/ybhw469Kk8FVAHaEGvzDgvKcZZJDNmwes nHyNJooQsxyDntaxhRPKUjQHdT6UXZwq1hg0IAYRKtj1Jgemgz5WEe9RtJdkWdYjZ8UG/BFf/zZA YvY9YpJg/1ckJgVNP9wA4OJN8RlEgXeB/hgUMPRsXxELCzhjoXeJ0hM5Zvd3SXVSpQ6c/UXgK1NX jQm76oBZUAmJeTVKQVxRdRNaRsgslTqKAJAYFYJYKHI/uaK0NRFJPgcEsJxUF1wZAhF1WyCDFYUO VQVlQaOtwBQgECUeIvpYNoBmDe4OJhyMLyr4WeBIAqrBn4gZ9oofR9zMjfYrKOyJD6f0Bt0Fl6gL 0utBi3XQqHIbvQk5Vew93BfoS7zd9XwTBHh/DgrDioCg7u215LUAD10PhMbADpegLkoceAdzD4cd vUW4mjDL3OhAnPBZlu0CeFXMAtjg5A3cpmX83FDYv0jP2ChvSzY7BAN0LYofdSkcOOfiVlkGDuli D6EIJwgEAU8OWcYRgIAC+yqzwVHBdSNMS9mWXIuz20WdjRJGBCsOhW/txieLFr7LMYCNREHquZDJ tumK8D4e8O48FnvTBQC/OY0EiTZvJQZzGzRJlgRodCDmuigvbHQSWKAynZ4cMtn9uBAgPzah+zeo OX8BNHUOR0cngHfEALaYGIjQ5YGbKTAcDGYBgKWDwwFQmr4o5roKP5jY+LBXRzMYqZPgRhZS+Gfj xPObYRzlCGUPjZYAWPlvIRKA4XgX6EMPhJ+0bV2DbXADbBAMuOkSsdUwDKgnMIHqBS28wP3wXcEv CbeF/38ZIRAIyMX2QSH4RP441MxtowAJuTyoErf6okLL2MEyToWi62620iDUZoM4eMoJQBs+Idrz 55yAwyATQI2hzcDtvbj9XjvKaarPKBvYzhzwBsvVN413c32NN4YuiLPzOsTzRsR1ARlt9Hv7bEuF Ml7Y6ynTWnQyBDtGsH0JdMVIfOiN18E6zc4W+ZZZiCr0R/iBEXO/IAJ0M4tI1EbtJoQs9kWAyA+Y zZy7ItHo42nmUsNjD460DL8OvqE4CaPA14rewrcqFDGi5mhnv9WRX6lFAzzMn8gI8MNGfGtdS024 i0DtvMhXEFuw0YK4BeL5RkuodRfEFIHmdNPNtjZD8CsOJCBMuawBX1ldEvYWRAsNjxBWLXUNOgFj uSxIUHzgfZamlufGQhlpDNEABZ59lsx2BoSAUYT9ezpbwzMbI7GRycFmqOeCXdQnPK5HgzA5If04 9nQWSkCBCOOi7PHFWi7WJiT+fz0EpRgQYrvQUfEJ1HRdinHq/bIAbBtRlQKIRevrSCTcPYMhCDvC Aus1l8FbF7obIJkJZp/sZolBOFGxaAWu9aVYd0hqQDwKaV/b6rAGczqjv0E9mDFG93QhBUBKDA+2 wGBfu8CZ6yULt8HyIArMnkwI6+AHDq0Nvf0ZdBvjfxd8dHMRWKB+2MWD0tn32mmL+uvhBrzWZgV3 LucAsnRVg/B9Cf3r/vdzAI1bugvH0qdgtVoHYLfFXmH0Jtq7Sn8GGe5OmVJQV40dW1uawAnE3Rqs KqPXttvEi2bDMAfAFxE9mbjFd/s5Z35gXdTNa677Fg+IGOu1UCsMAn+3RpCjAqXXGIA5d9d1wDB1 vQ0kQA/GATAaoJYINpjYpvRQAN7+TPz2w9Im9sduefms3Yot6xQPCivrCQJ0C/vGJKAgNJHgK3Xk AjxYjW30GAx4hFZqINz2XD0eLTQRA+oUNfO5IqwVXixDBmQzPjEEMF4XfUShQb9++6FQ0aDbfN0i PQVxA0PrQ95VCvoCyTLMWyjZe6EXWc9P22ULtoDHFVgC9MwRQLL4d/KlOgMHAfv5fWPRDO33E/mD InZaNM12g+OvMOIDS5fOXphl09YL454MIPgNIG1JBHgOiyYKBV8HCIgC/7XychWfADobIVnQJaIt YOc3g4z+feaiFyx3qX4hixAYjB6VnhS5oLGtxY4NByB/pR5FOFR5aXJR17VLODEmPBykJmsi3iEG V0aiUDY/RgLXfMNL4r75AEAwV4NSUgx32Y2txQFBY1H8HGYdV3BL0Gh0AATTtaKfVGUcbnrdBUBm G0e2hhP4CDjw3Z/cOYq2C1HcTQJtSSt6fhQzqGN2WAB3c4WCA2hkLQDuU5ydYmhIDjSizciEIyex cBHaBc/Z0znKxCUHH7cdn6HLLEbJSz4J+b4GagS+BoXI/WPF1IoNcCqDsUVs/w5Gig6IBorBBUZg 80tt7FgnihUdCBHaOq51TcTKdBtAHfQRBtl1gdh0KhgT+WWh+UX4Vong7R6sMHT6ONsWil+xAUiK EUDCiAr2TUl0sh3dAOqgcoky5QJ4UVFyCCvsHNUHxsgia/GwpQEgk12b/AzyvQoRPhqYECI6I6Cf KE9BFz09X4syACtBPwUGASM8LxVWIjDRox1sQQuirj0ttuW+fwf6D5/BA9ADylFRxSQjAC4y8+GZ 2ycRb6CZu8QwXsnBOA6iRI1dY5W2rVFBa6NHtT9XPvy+wFA+TwPHYd47D7z7pQ11deoHLY1HASV+ EopQYanIRUTIwWiGXWs1fX1NaHDPF7BxazqDyAP+UXuwVei2LhDWyERQRW/UDhtWQUXBnkt5BX/j C9v32xMtsPtkfBGdamSZXvf+SHfbCtwJmQaL2hYKIDZIyAqyAbUWIMwPIigcFS2hdyGbkYMQEBkW 3LBlKkOQLBEqVUHBEbryCG2p2I8aO7UV3xWFWtq+2sv1xv6AJ5O7NA8Y+wN7ATBhvXB4URA5Ni4w WUfDlq0b9wP4tAxEFwgKBYegL0Sj2A1aUEd5fStkeVoVbXve6wcDOZEoFnAz1wSZLQgDV52gsyrH FGgSSNeG+6n9V2AtigcfEKL5QqvXauEpUgCNLgAuIWRIO7uxAPTSnMFc/HwmUCIPX2rd9AqKB+8+ +SBH/iMBjyZgyFBT1BVRrHpDngFTlDmquVs6EDAyBUV0LGb1EADXoihm3Fu/7FXNiboIFd1X6xHQ XCNkEpVqKCeoqzgMsBqoCfUzglbgVgP3Vq8hQYP1EF5fjFMUukHAs0HgDeI7HVShlAkCnsmDLX5S ft/+hdumVp3Qu7iEnbhgiDkYdHReVbu+YzBCPVA5fPHgKr4itor8Bl4E3VEXfoUh4UCDJbuFCs06 SUu5xzV16P2oOPbzq6qJXQ+GrX3uaOtHHbe8Ik3vGoS9fYDozq9wQf8D0jvC61R8W+WUJYhaSvkw Z2Lu3VZPjTRStPtCVPyqjZ5wlIA7GlChFSU/Rt9B24BFJT82+jvHdxRv3+5L7PyKklggCJBHQBN2 9UFIEK1LTDkA6ulhKnZ8BHLBCMcFluj+8D6EUKOkEFeNtmQ7v9D9vavSpaVZo9Gl61JAeZg1N2h5 2kf/xqHF7goWAT3LcvFTOIXoBJ0riQn4t889oCUKukmrAOsO3/eOApNQIat0Dy6KBLMGVIgNbN6H qeF8Y/BYIlklLdl+cittcv5kqOjB/yX0YI9cyFYU/fj8dQ+NLSvQofCjGUkt0Yo2ELN0IqCJWGBr MgQNx0gM29la8LgE+AUSCwgZlvA8EVdxvu+9EYLAH6PS5c+tAkyIX9ycWveIEJXsSBWKgL/vhYyF FgH+voeIhAUGpaIhbUAMOIIt6PtF8saFDSCQN+hNLFy3VfO4CvI7wXcdsXtsISi8KkG4IACL2abf 3BAWq4vLqkJCikL/cogMDfHQX1tq6fqLtWdqdqx67DmJfWfsR60kVyP9HVaxJUSTHlbhIxEtsZL8 xwJLvNuFCVzKjY1y7BG/n7HQ9sLNFgMQipQFZIiQTt52QL/rHBoCdBAgjcZ7d1vr44CgHIlEu2HC DQC/60kVJUFyGQSxf1hjWrJLyIDBIIiISZuTl7cfHWFyE3p3DiDpIAPdsFI2TEq+h8Bd0A1UKNhy Emr9C5hc+AVgWfwo2CiXIpE8gGaXPewvFTcQokZXV8RTaHxkixZzMKAef+yzlV/pCMYj6yIgeNGE CD4b8Ab8FF8z+XYfAgAUfhCwi4gROdd4WTQAvEv4FKEdRh0NjOAVsFljY2yaSArj5DjTRCCztsVo GMw8IHMuUIpFS7IkoXm1YhE0WSBwwNVQbG+45DvfhZxjfUgWwUaYG6Qegq0B/8RB3OoTzAQxqd93 EVkDb22LOGfcdGai3GGY65K1IVf0TewabAQPs6UKiw/Yy1ILUCUyCA1A3Vy0bT4ceLLT1X8eAwAh m9oyC2EAO8qPQGXIawgFs2jEWJKM/Buz3Ild4BJ172Itg7J933S0VmTktWrulGd0nI+znN/jNrsD 6waMKGggytVIWFs7ANG8sXHFvwxVhHECJIXSoADAEiNKV5bgAjlnH/FJAvPQ5pbqDF52Kx6DwhRN UcmrLlVoYmRrwmIpUHfko6OHRiYPou3fUVxmZKsPCuToaCUkyP3CaEDnI1lgQ9Q34K0BwyvY+3o7 2wbcLqPUxcTMBftvc4DSPaEYjQyAoeAH31HdGogqcxRsK1AMgfoC3Au7ACRyBz8U6+hsFIBCk4Dw CAtsL12gQfIrcQxa+MJs/A36/FfB7g/pevxpyQQCLUsKYMH9jAFEmW70l2CJ6pkMLwF1dX96g77R wfmeP0lfiUbPdgPVEu271YtMEwQ7AyJIDy4R0K6D8By/qt+iRNHT7w2R1yF8sFywv/tE/gl1K3Uh Oeskg8HgHi37dO7BIbywxBIkBnkEUTZj24J5fFWJCgQIAzcqd6lWeQiMZ/8EAqa29k+D/z97hl8A ADVoNrqX7EigK+BbuX/MEaGJVfhJWjvKpjmJ+rmtdfPKQRv7QD47+kzdNgp9+r90a0YZsI6AwFG9 upFLHhnq0iFUEQn5sGAevdIhlGfbFmtMUr9JvkoLBAporSwIEZHh7Io7EXUJOf2JALLmujds+SkL JokvDjcFZLYFCFhjikzF7rfaBwTv/U0P/sGIC3Mlu38LsSwPnLuIi8/T63YJGaP37WQNjUSxCRjr KSTABPcstk/gGSVZBA+dlxoeO4S3CTiLVEW8Gokw1cLSXBNFCEj6S/Tu9/V2wN+mDdANiz3gYG1E ewOkDwNIDFIlaCE2e1PnU1H/1x8yHPeHvQcJUAgOOUAQg6SIbAZnd7MkD/5IQwpIEgmOveF5QxOD YAT+EYN4V/fahmhs4XAMWhIJx0hIVBDy9IsVhUKBHvJbkssAYBOxyCgjTBGgZlXd0kgUxWi83xGm /w0vOwUiNU+t15bnFJY6bEzrFOv8ugMko6yJNXzkSgGbKmYvaG18cktIgiwbSBd28F3s6DAXakk0 fQ6p09yghUKU7f/g6xDuRi1yJoox0+gOI9e3EHehaYufSRTfLrxzGYtL4TsjKyP+C8/a7Rov7MMU O5oYcucHdXnNhHy3nzvYJhUF67aId7fmGXVZJHMRg3uWCO+QZ+cTN+vtJg0btoMwZy/uB+t8e7j9 0OaF23QUkOwtWVsQiYy6laAOqDj/cWjda/Drd8elFIsWh7cSlc05LYuMkLZ29rBLgJBEiDeLEnAR /xDRylXdaEhEC9aLKRYKagu+kdbfCs6RTBwEv/4jOQtVoOTo13TpeICoWxHDmlxYoEz+7mB3V851 DWZqIGRfhcl8BdHhXbfdrfP3iyBU+UMKK3/xB5r+XXvB/gROg/4/fvheq6ZBMlH2JGEgFgIC0n0r ER04x93flpzT8+wjXIhEiQP+D3XqIL2LCg0hC+sxF24xWmwrlaEyIRmFYAXXKTaYLIV12eQcIgrA egT4AATKtemVr3oIkDmtbaVeqftCDKUisywDSMJkBv5XaKl0C30pxJkL9xFkl8Y2Yr+wzowJOwp6 wG67jwl8rusvKA2NTnSx70O2CXsEsbytFr4milyP7gk3aucCXG7piQqJA/yyeTD8to1K0SIBEjL8 n1ZvGwLLjXkPPnUa2ZG6Qo/yG0s7pF0QDBoGa1MIZZ4U6Y1CBAgCDcythQBcpoMwX6imI9OJUHLV 4FehRBQQiP6IYDGYQZzAPT3TB78KaMS/CEUw4o9sX7GBM1yJRhB0KmpbB6+F7CBTslcZ3BeQi5Ng DHuepUYFJPz0fMW+Ua1OJJ9+BP8FYoNAlKJBAEZRLaKjXOlzcaB2tFoAw8VP4ENsfdxowzdpwIFa +zDRtgF4gh9ACAIE3bo1LCVKHvuFweffeQyANuSzixCAAER38QehcO0jjZcAcNb6dzxHg0vbjUd3 SPKDiH70N4N5d42I/AbHQPzwQg7v/z53R0T9x4DoEBQFAN6i9FYsaMp2x/dQvFEkgwwF+ABfJkFb FCi1Zgw/3D5CPoNknkRCvJ7jikZDrlKNRt8L3XpQYIz/iE5DdQMJeAS6LMtoLKsVcH5q2LQjVStO 3BFziy9RJv7XjXAXK1EM6zbB6g9Mn5JKhIJP/Ek7XDVeARcrXDlR+t11tLvFjl8c9sNwTwgD2Ts6 K8Zbh49FARrwP000KmyNdgZOvz5fSXrCLF87H1PIJB+J+D7TIVyQGRhInLIhnJA+ll63NaGRCFKJ CGR/Ctobcc8rzgF7E+20mUCbqnAJfySL2wnJRDH8DGKbiRvIjRziy1s/lmWJ1ggFTktZS2SSZVlZ WVwTa6RkGSET5bhKIvZsuhHrJSBKOgxc7IS5FvUQLJm2EVz8OzJChgFRa5/iX4lCEBQffgR2xPAW bfAZD406UV0MZro1uSlZo0s2XDOks06Xe7US6BDrdj1RQ4NZioUR/JatMOwbGCHST0dhcxa7WnMe AM50Bnkw5JMPDnUoIY1OPLQEsnYGdnl3gu4ysnF3cQiOA2UlrCHcEHXtlq2Hw3tYakvtWUt5mGRZ S1wPYQZpWJYZD+JhOUjWeS7OD+UQSyZ5YXlOh6kLDWEDSxj8OvUVsDCKX6I9o+AxHY1kBgE0GCmT U/5nBZwqR8/MEz/biC842XTRrFESde0L2GhbAUsyw8NWCI16BTRyqWFQ8Ar49zPLA/Cxq2EF3GDP M8a2Q79bz28lBnTTAR2B5qJ1xIWmWgE/a4vwUPBL8DjYdDbH7zjcdCdpuga1h+fTEhXchhXwpgbU 65Ze40bPSec3Bv38oaq1gxqrug8h/9BFBINcIxgI2jRhD1MgC8m2aGqzqYn4jevDEPxbhErXTrdB s1q2ILd/+3fDJgrkigd0IQpSHUZHOPxyBod3Ar3BTfcC5jj4CdjGOMRpSXXX7jbbAoXETZu5/wAP gpDowo4nGNm28hYFBci2aB98pT3EK3+QOBmiU/zZEw2L2WoTQID2UK0jvsup9i98K93/igYLhR90 IwvbdB93oOiHqHwBHg4SVBfrqAQJB1lebIEo2wl51WUJdQ7W2nZyAnFYOBZd6w5gobnDX+swW5xb MQgLiWsPVrpT7AWRAHz3Aq4Zbu/xB0IPq5br8x+PD1Eh4PIKRg+jc/PFoIoRG15eWE10F5zaUYDh BMMBQFcxskBf8Fe+FIa6XIoRZVxpinEB0DWWCt9PKBkU4msjvF1GONDiC2QKCvoZNhaT9aVfshDw daA1XFh9fg9hAvwoEN29cYnaOOAxikEDMRiKZq9de7eJwRB03+uxLzSKwijbXCugQskMn8cFSjRC xSEINo9FR4AXdwyzD7cEvEZQ6kHrUgbKDv+fAAqluURWAYBedA6AZf79RgWlAIww/WoC6wlFn1q1 Df34P41Np6iDKorYUR4YKZoRHDcCIvhCVREOCiNFDHAbbsjPCOluyAUi4EOhqzX34YJ+hWbCBdEd 92QBuJ+1GAnhA9NbGiBS9UlxCNn8ei1oiM+pPaCxnCldNqzKbRMMIAkOLn8lGL6SAPmIJF1PAEQg SPzH9FQ5xwAhXjiy3SU4g1zyzljNI8eKbsoYUML3cSLQdTdyEqbg/uUQAyBuVbtYGgmoUGv0vkQH e1Yw+l2WWXW5kM11WihNmxgQazMXBQSazwoGc8/x+hD2nTSXGBoF11nJzNA0bI1wJtcJSAgIbXHp 1lsGDIq49sH9DfhCNANxWQrACVgEfnP2IJgRk4NIBAKEy4d1k0ORJAQSjiaHLCcICJAqDhEFLZDG v7C1DRdQj9Ejy4Pi78Hbdabr4gvKcAgURRmDwtpWqhJxGvcXFn5INnfR6RgW+8HpAyPP8L4pWf0F X/4WsN8t/Uz774TLB+iDSQwQqAQKCGwP+QioCASo+gbpt29L9wyoIAlFWK8GuQAMviPB2VoO4nQ0 PX8zBgjqBuioDHsozwgD67Bdua6ii7WP6woL+SsBW47LoUSDIPxskG3kAyA9AiIb7EIHe+PrGjHn gwvrCwxW9XkZ6wiJCE0UlJb4QtcPvhApBYHiHyP/ZTsW69IInXhIIHnjdhOxa+UNGN2b3VgQHg0q MjJQUHfAw/ZrIRDdBx5AD/2IFdFU0FOi1EN1ADoFCDRP9wKEgyb+CAj7BMYWTvP3AkZYGd+3rTXe prr/82FdDOnRJUm8xQbadBYCNB6APQzrGCzfwi+IgOX7gM0CCAn3BA1qbxT3AiEWNShuy/ZsMwcT MAcWFOsS7Wyr3SQjyiMOBwgDLPGRpPrdQEDdHxU4U/YLjS8R+IPnH7GzW3QUhF2qru0TwA8mL1kV 95xSW2PD+WbXFvZvBRA6okLksBn7/KIFcJF/HSXIDg5nB1EhuN+y9+Ay2yPIF4jJ51gHoVjETQgo O8gu4QCfBLDdAc8F0KwvWzc4GqXZ4EX09Otu2T6AZR8fCCTAJZPNmv8sJ0bYgQxy0MAeb5PtkUzA 3Rnz/oHZTrYC2c4QCcQbS44S5spl8xAMZks2Ky9wIo8+Yh1wEWM8DC5u5Vym/50rJwD6rQvFVvzO VH0JZVsHtmtFFOtUQnM40xGXAArLN0X6v71dKgVNZokIuAP8LzvIfR8ru1aUysGEPZSA0W3WaAW3 9A34dMUBC8OcKfj4SHXjIUvGUYPmfqEY6ykvGXW0Ex6ItP3NiRGCDnvJ04kLaiAW76oVLbb5/4vS N4gDwV88tfo4BK01OMYUMcL0EG0+6KPsEAIBy2ZgCPAcpyPY6HsoiXQgQ+B/qAgU4CRzHsATeCSF ASWgowdWM2EIiEN+jDttEIgNKZsQGlGiSbggK6kNOqF4u81+HAYDfxfaIojOYCbXCyEMFLpcheir EDv4LB/6cAHjQT3WfO2gBM3C5Uq47ByWTHwdQbnexwXrFplVDhub3xzUBwLrBqgBA1jIthGJTQRW 0eB9QSwcO37JFDNKJfSGwdeuM/r82CCD2MFWzg7wBf7lRuXglk0PgPhUdGHI9gvBZij+zoF9utKt 2AjwfxBVCJV5PHX3Tc4R/4MqSbj4f7YtV9jKyGbsEvwXUflXiK3tNBP3fnwH6SuTo7cA9ARYXRm8 cJwxiW08Vj07XKNRsFSggr375KTbIAoV3Q5AZY/JlmcPTVcyvlgbDKoedNL2LkLQ7W0QbtFlDAgL gFbB27elJgEMCE7r54hlDu86APdoE27jPlFElZMCyau+AhbWDScVUQzh8NsfDegEZiW9D7/wge4l M/1ZQIMXiVVRm919/mW7WaEbKw0M2+IODBWtguH0xYMWLeyc03S3FrHYCx/jbQwi/MFEiSCDWA6+ 9ok3fArbLejx210Imx0Qm9eezXWzEYKbDCMQ9P2mE8ERVIHZ6N7x3dg76u3ADZTZ6xhMwMLFLEY3 JGoL4w9XvfPPKA78s/8FG6sVnAQCXQxfFnzWDLtBMw2wrsV24X62BqCJHQgyNIxnOgT9ikknJMhw XazZ+/1XSBwQIwdbQ6JuSiXMELiFXqET9mQFG6i/L9ZmOR1WegFaoxOJFWJ/q3hV+/Fr9jwDxhPV lPvrIqoUG6G4BmESDdTYrTMnEK4/ow3r5HrttQyNDwUNqGoHhmpGEq0/v8Slch8kNZgXMRTCH0GO OvJ9xBDA30MFvaEdgGA/ZHvvzFQKIEM9OJwjui3kaMlKAcbmeK87QQihJUCiJPZtDYg2HzQWvK+3 IQB8EVBWKRkaAQIO0HuQGkgAeBVB1dbgLPCeb6MbmfJbmhAju048VsiDIvY1d6ypWtoarZD9eYJ0 LSh4RtRnwkZWJ4IbR5ezMGRpyVkCl3pQcLI8KzQI9vb/OsN8Bzw5fwNG6+80OnVOLWXDjm1LWYsm A8guKhhkk8/zI0YnmLVqrmFj+xp9aFQrlAyadBw/95KMvpwJ7rvrETorcXgNds/qWQKCEQPYrEA0 2jOn/1sPY0GGgCDHnRh0omJ7KgZaZSC2/bv+7Gs9mqrNBag+BxE+C2awsgI9CFxsu7uAzJy3DbYM UWYUqAzSne0OtAeysCDfoft1HQms/xqu2WE3zqoi6xQTVxR72wG7JVBXIgEHEAViwuQG65ruLGFU UBFgB17rGpxBXCkJWDyqziDfGlpWbBdrUavGTkfrQh5b+gY7Vx9XIFfkVwAG0QpRT3gRu0Gw2VN9 ERhqCkPLrfgDWIsVpK7atK5O/n7i/xw70H0eO8oPjL/+jQ+PtwfKfh5bhIgmmRroCXyU+S639hF/ 8n4IKZX8LTga2S7uBAUGacChwE9AVMp1D5xrfFvUZ6idwaDBDrg1VsT2nAzv9QF4VOkQRTU+Ktyq OXgM2RAD1Wv6RlSEGIuGfKvMCQp1Az4YsPvTKWnS/d9+Q1mNQ/9XwfgX+WoHA/iNhDolnF/CUbCG XzqyXztVHIolqNt9DooHK44cNYaVWpb5VQ2jFriKvnQYBXU40VolbrbvtoBgBge0O85+kRIbKvfp B+sbiNMJi8n1ULmxgAcI601ig4JCjQkrbOt3ePcNNu9FKGagC9jvNjss/Agwo/jrVSphry/JtAUF lCrnsX8zuHkNBQBcJgVJDOsRumyz2PY7wnwOtkESRWqwCAjxyNUveAlxAl8kO7Bfgi1YB/8VLqWK J0c4vUHr/8R08ixBPBoayYDh/hRBhuCoX4KEDqTSGsAc/8mVEJem63gRFaZgQogPuBKyPN0GDpBn Jx/Y2BpAiA448tpAiG0JzNiU2AK/4BLiCgDD/lZD5aAI/TIwWEMwMJv1CehTC2hduvdAKB4KzMYo gr8Q6LItcWNDIXN7CAWCvwkFYY0MdoN8j4PN3bb6RVZVjWuXVAtdXkF115ld93QzeDwlU3Cj6B1W DLpBueWkKgg2QkSPbQtFAiJLj1UMqME71zsIMBqLNI/raniF9wvXHLj5EFyAYpM1BT9dFn+KYJDY Vdgpi0EcJ6Jkt1ADGFAkjmcBdFBIBrYUf1WDPA4FgaHEwsVT9RQmFKd4xSsUNCYJuxUWgHr3vV5F aAAUQVjIe6WIZxcoBhEImAU09IMXLERcaXY8bS0gc3IFng82qlrtVD4NAqhqvOTiDwyDYDab27ad 3yiaEAEn4gBOVFDroBaJmYkIfzsqSs3fhbwXFTivjSjcE7I8BfBVLb3wO9F9JyZSweGNfhnZ3lpY S2Q5/CM9HfDmqP9CA98703zidRF+WD32wzdM4QXHRliDTF49kA8/h/wcgU49kYQ+PZNzyM8hhS49 jYLz/BzyHj2Phg49kger6kNAijBYauGJBq1U3XhF0BS4cl/oUQ6vhmigSklgCT8M9MDFFSwfY1US P4LZ2USrOTJXi8KwqhLA9o08SQK64rUNaAGIBBT17xf1NboQDIorDXQkruCQgp8FR/FI3Ig4uTTY YiJ1JfUUzUCUB0kRLPF8MH3ZJ6HmSeO30retIQ0HCjwgdkUMIHeD7oOq+kYED+nUYOZHxFUo2Fs0 cBW0WgjpBMAtTmj8PD0SzYBqqzArZuF+qXbojQS9BPlCC5R7hIWJNVgxyglK/RUinUE4H3Rs3f6s KMDoWUWAP0kiVcuaoog05QYuIFLBFuk2M4h9e6FKWQP9N3XJXf+EVL8TKrgdC4kebEaTDdsk2DW9 DwIcr77Iq7hhhABKgDqhKQuKN9uiaIv+OBg0GAwGgeNTqNtFG8AHp/iJBIjUSddcDObWoQgV6tqw Lyckhl9m64iGNQNIWlDgjOhunKNMBlvDGBu0FWTlGyFiECMg1lFcx7VDLYIFov8DNyMqFm4EC4A4 m0TGIhZe10CA+r4pfdLRRrAiQTUB3gDKRL2xFkZAunpHxgvV684MRSYydnuFeUAc60MeBd+Sty0E QETa9oMZGJe35u6IHkZlIHQJCQgJdcx1AwWiY41IsUpm/7+vmS7aGABOq+BEK2bMEb0FJysXyM5G f2C8i1UU/wICCF+rvhWFIlx1BEA3kiwNVaNUDZanGKO1bwUIeAEijeMd6cpEpWDrAHAscfsOuhgP lMKJBdHrdUv29u8SdQ5DiMYGXEaxS3XzgHwbJrqnSkxVCoo/roEB2nQ63HUoJ0wYsBniBh8bD67N DQhAAxUBQHRyXxvCCG4wDw48xyADLzbJJxJUUA5uuAhJoczearfHGz4tNGFN0TP2wLAVbCVoBNXr 82oEXqNJeyGgKD+IcC1sJTmE6oidOSsbAl4KE23WUT59gUMMPyfdSguZwpkec+tAQK9Kn70IGHX5 BvIrxi8/qjXaxtH4jkACXQN+I1igQjQp6DvrdDIV29uSMhQQdCMcVQVVc00vJCUhCxqkzsoMECdc y3cQB1wDz2LD61NkrjURKUylhbGD4oPidDyuCoRY0vav+wT2K8dAalXOKFh6opcLulZQnG2Q5VdQ zEWzoGcYXVuUYZjrRztogA08Z8SlSVM0GxfAxE4ALQ1+wCCkVCsb/yk78HMebwS436X3XfrGRgUK oSf7JAUf63pBHKjeZHAEqlAgKV0Lz9YaUQbsCsY40cQW0I1YnjuhuF8j000DO/h80vNnffaBZe5W vsRMkwY8g4M0P3Zrc42IgsFzHIBgCL0FS7NgQIvwJIHBDD1zjYDghk18t7xaACrECRCjTG4IaCKc CDk4igPYNnoL7jKoCEhRqtAAqxqJNCP8Mr+DWwKBi+QJiQiKC4i2UH8j9kZDO/d8tOsNIyUuAX/b gzyB/+F1TTYCvdUKDi/IavZYqUDDL+LDSKTA9Q3UItntB1+D/3oXV3AfDkUVUDHkBoC6IraKTugP TQrAS+zuCgjrBAWAQ2wDfJcLMBuvS8IBMKc6whARURQNQ8RbOEA8PbykYMeHCHchaPxOXKHQzhx2 EkRZ7f8VWXwRjFSppKwIsdHBRjBwxzuTC0EYoB8sALDSLb2XappPAzuWGgMcOrMwzCpsvOhwDXtd 0U0Q18/6dQsBgidq8e9co3t2RA0HuGATF0GIaAdkag5dwFuCZhKKvQfNXopi1N88dikZqUsnjyf8 i/iDSWoDyKp4QHdoYEFXEM6SdJ+PYP9VRBBX0ZDBxgwcHUDts5m7v7Z00xYRaBAgqXIBzmAnGDgn 48U2aIsIJr2NMOwm0REONj4IavSpzhYny1ASkJIcchEJit0LN5oAZFECOpYugDdwUwEmOmFQCuR0 HaB0CxcXOkHuGRQRAFpBgx43S1HqVmUaddKTqZARbe0bMdHgQMMLQwGzdbsjBwJCROlBMOATAp7m a+2oZlgzW9LKySXopWrBUOuMVomYLRgV9qQoC3vReAb/KxuEbAPI2GAIMyQC9SSg9Q+vVEXxhYpW i953DfGHioHwbHc6Ox2cAPRQTh1IUy+K7ZV1K2MIycgggyxcIhmQAuBt9OupU/mPokPA/4Zo7I7x 6/hqCshqFgYobEUU8BXRFIdTNSJc7Cd4EpIxAj4EO11WpKBr5YD3IB/SQRHw4SkQDf2stzACvvQs AWH/FHwp32BCUJk0HFUjFgO9DJ0CHrtFCEc7W3ylXpQQ8DDiw19Di1YgDwEQGqjQgANUq54WCGYB 6UK24NxCnc+KyHF3LnbWEDcEdzwG/maWTPUDxopIadGJCKACBqJ+NQAliq0XFk8+I74VqweNUwEN xkQwtVgABU76FtIXwEK8UvZIySoN0XY5CRzsBWNlAbSf1M4sgNd2+G2RJACjvNU2MVIR7kty9AFV bL29FAYwBIpiBKiAT/g2QPXiztwMBKpc8Q2cJPuIAeuqCmzlCPrI55eKVG38g8verTwaodbabDOu PA2ytDTC3f5aE1rDSTnDcxghaoXWoIhIwwjbuahYBl6tROtzyoCdNzcr0/9qAc9hqLrJCglHJpov uK0gHvacHhOKRf8XNCj870aLD0OIRDEF6yk7cC7etgIAv2MFFgrrGMsI2ABN/5J2zhl6GQF3v5IP gq6h4IgjEVx081Sg9u4GqEDkAogGK0YiAAOTcLGMzgwORCzJhfOB6kRADP1byFVlQUMNGBvl3F31 6xFFjUEUGBIK6qjoCqRhAkyo2k4BnoxGdaGpUVbggFdVElH4wQxdXehg4AMAFtrGzwwL5dDoBJsY 7J8t0ar9RAoR9sWYyKUd5Ci7Kdr/gEFs9UIVQSPGKzwcVS0RLAgQg6SftY7qYNHAzghA6wfWamgn gMjzEOEEqrby8iB0GDB0ClB01SxVN13rFZ0CDPG+DVKmA4nwugAHfQv9QzepI8q/jzvIfzF0IMuW aqtoQ6IZFwJby4BbTQdEM0P4hfZ0I0wIBENaOhGma7o+JgUvBwYkg1Gilb+PFoyne8YYfRUBOwUH 5FD42BFkvoB9x+k0kaEAYn1aFGorxDI32arFgd2oNzj0D/YB9sTtC/dgidhCNwgUmwoWfGMGygsQ aIvOyCC90c9r33UauhgCIFYK0oEsVV0d5bfkSvAATArqmRWkGU/IFIczBcPirrEyFPhWKOIECBok i9jg4SzPKk3/Ca8IDoKtu6gBFq6IWbD1YRC0ihFQgMkBGASFwhOHVtxteiH/C0iIgXV46nRz9sYL Wi8GAnRtyavFaxCDYhafviEAExyBOIKJjaUTUYzLzs4OaoO2WEIT7hPnIMaoWL3QFlQ/19o0Gizb FSorMEMwAmDHblqaw1A8dLXkc3jYtNs22wuSgIsgjXGL84tAwyCjy3/YgDgRSwQIzpu72C2wqAh0 IkY9aLFCg9uFxhNyD/kkcnQCQcAMDTx3FzS27vUEMV45wx+SwRqYbXIVB8q7LEO8x5IIMAwSIFeH uWAIDFSEAsOGP2oS3IFG2EVq26IDFL1gdQOpD4AomRsqukTFdPZBdUS+CQS7+nUjEgxZJhTcKNVG DE4IBKUiRg/0ZlU9jV4MVThXwSKqQV8KBVOX1EVUpW4ahVcAtysRaiQl+/26DEHVfm0pg0Rb7sG/ DCCDxQRDgf2CoH2MMkl9n15Ovj5WSj5RZ3MPjQydwbaQI6kCG6fCQFEwBv+bEQPW6+TB4wWL+1e3 WV4tg6gL3UUEW7+/qVY7DVNXc4PBllpyWc7BITBHRTDaqjY3E9HSJuB1HqIQSVNJWN5eoh/s9OsI BPXrA/YWBX+2GxwHiRww3bC2QOLrFg5/exdBCrlYKEoVoIVZN/zxHHY7pCsfWivIflBae8nzUFCD DLIkHGE5yH5EO01zHyBRIkl76fMIchWJ8DyNhZBYTgDRQVM4iSaGOss0tRwCY3uQvMDB57z3SQDz LZ2LA0g4FzzZVhYMs5gkgWlQFuY4ttFCnlNBoBR1B6wNvinrLVAUTC7AayRWJhhhmBgCAVMj2i4L AylN657O5WXtNXbTrqiAZNSEsLn92vDHmnKbuxJc4ASKKRNAzUFjVby+baCEexZRHT1sBUHbDnKV 4HQOFteJCASc11mN8dp6BT0ZxkwQdAPXGAylWT0rWAAoGIFUeC5Rx54CXZngw2a2tQGYns7/hjlL toIN4IgIwo0ZZQAMUStx8ECZBZqnUFkMyVKviqo+jkhBKjjEBjy/tuxEkSrnAMsmYom6+RhDGJ93 H8R3CxAz0vfxqQwH0+tBc1CdCgp8RRNwCeD/0enR29Hq0dgLx/fzX7q2FGpkPSFE9+YD0VW7++5y DjsndwhyBzsrdgFOTL1kDsIQ428qnYg3m25Qbgy9Zuy2BcIL61BuEAwVdU3EkG7IPJEEEETVNINr DA4IZrqtaz+7GxEUBwi9CO9WwNoN2gB8s4FvL4rKAl4QqIKAlTkhYvZn7kq4IAqRsKH3/g/aF96k CCT+iQ6JRi8YGmyogOQk7/ejYBAigCJePKOgFQhaC1Mh4mAUeXUHm1DfUTBjCAFXdGe31qgJ7mVR WBhJeAmAVr5jfhBXOiJAnQr4FOtYKDa25/vOGbPDhoivLEzrBbidhIktXJJODXkoAc6cHmxcx4V9 Fd0W6xSPX1VAORaoRV8DBQ8AaEWvp0dE6zm0UWVcwFlUzVYtHgFsNqH8HIQxFtGVip4GCNlawMfv C/DOHRa4WT8QDKEAwfodqrjW9/+JNjlZ3EszqKI4VfbD9YW2DQhJWAgEApql2QoDBggEEAKiK6BZ IAHHBUKrqGF8nROYP4iu4NG+8L+Q1r3dEjVCyx+bBAcUdGHLNAhy1mYLx+K3oC6NC8WNzAEjz157 rSvcDDvN0kUB1Uw2d5h7f19d9scQW1k7kVZ6sGSuihaJl+/duWYCEK4GIPfDjKGjkWMLg7qHyr4d LGoJqqYBEiAJ3rbQtoANe60IBAiF1hFVKmQmAyZSLOTMDCdnCy+irrX3C8JeT4KKJBA6NDhFbs82 OzTgcqm6fFl/VDqatbAKcktDdYqV9VFJ9axXuEwAQxhHBYPIhRK4M1yKYD+qdR3KcnYuqITcFnYP j1BdZ6rKeulK1N+oRapBUF6LXn0lORQ96lhSfgvIuUqdPK4KWN2aF8T7UlXrZYsVEoeCBZYKQ8jv SjZaoaUaD+Mwm4hgKl6IgV0JWENBwEYrqgn6xl5EbfWK/B9RciSo1wLgmCEAtQ24rhUGRlCtdVvx DQX9AywgGAAN0cHLLW2xgyiZWb5qE/D//+vi4clZFivKg8r/0+L30oUUsHUcgkos/UaD/gN9ESuw sSja7lZGDcAEEHzy1VczVbK1+0rKW8KMvU5MFDOzFjaqNncfWSlR0w030bmbl0ABK1BOeBwboRUC HrBGkBaD7wTTsIg2TuciMGorEThZJVxZwNjdB+pfAWbDXpmzyKquqFNR9mrophY5HG5KK/JaZ/DC JeTihcEhQ1McHunZD6DZ5A5XDh8icnThObf8WVvlK0BZIQBkojfd+EA7wYatAdB2KTyC2d8mrcUi CSrdKRsUoIZvXjCJNAEFSlwEYDoE4wg+RILid/wlDUGzwDB5+SQrTW3gZs7BOlu8mTahAhrih848 4D6IpwzXD4teggUuLeYrYdakyCPO1Nxt59oQ6AseiQelNNsVFlovTf/L7XXcS0TUamP0GluikLth qDJcaHwPwUoUl6hwBAQQ/KoteJTUogBLMILehQl54M56aaOtw7UjSFrZaW0UpqiAkD8GG4rasgX0 AhdmgePeBUxV3ST/Px1V8NYgRRH7AcCqBCXKQvLJBBl+0QwIICteqiHmYh4TEfQCcGR7u54iAREV 6AT/UwUHa1EhH3gdrQ1diPCLRxUrT4QL/2WF2Xw+6zw72H8/K1PwGesOezwXBAhWSkaOyW4DQgxA I0b7tmS/a5d7ITg7H3woUjAMHU/mIpcmi3cUcgOc+xpRbSs6HhEBxX6XWvd/IQPzIwq35jAQwJ0b fxCTclXVKi2buEW98JcvC/ELf/9ANqKOVuwWNfi5iQBcihZuCtx1BUUBjtCEMWtocB3I5r4g41PT dBWIYkEzBiRAHhaBACPULPF2gB7WD+4iP/UsYhsyBFWhEF/aED2iokoMU34BxgYN4EKtMOyffh9b RKaAAkX1I4LLW4S+0kEwWhtWCtxt/+116TbYJ9siuPV8EoC/fA1BOd5W8AZBOuv1/rS4BADbMQv/ hRJXwwo4gQVX2dZ1GQTgVpxXnLRtqR4jmPzYA3UN2P3TBowRFPylpWalGjHCa0TsILZ9FBCGgwto e0XaiYy/g/NgmFFB3JrZmANKBImS0uALna0eVcZCBr//aHxstMRGJcbB6MZGMzXBGxZYEse4Jl7U 2aNUD8aUAG5VpHQTqPvRUS8fuQA8eb/g6yH/tTZoVJqH0yRBe6IwFvpmBa6izLaHSyYBxnRLNLbK VhX/JsggC2yYqA1H4gs1ws4v9YUcBDDJi9rBCQvZjfFX0e8MEok/gcfQy+vfFKMB3QoLz2aUDhgB EaoVywLgyAUyahih+CBcMGbQmz6qDh4BhmwF0Bs1o4AIZ0QdRLZnexsYeFMZFMFrilUlhaNDwa5U dKckFkkFobwBIeAl51Az2Tw3BOgBJY6UXRilYrYNjVMsSrpzCQHoGB/gVWFYIiVjJERCCDgXMIMa 0VJv3LI6+WEABSEz2zP2diFqlQmE4FZf1rlkbRxVUhEU10CfHKt7CGGNZczRkhpZFXMUbFQdFVeG egeWcrVk2eY2xl0BNTJFLTyARlC4iHVv6fvZErChE3QltCkfRpd47XXrLR3Z4wMEogB0syAdLzdX 1UZwFerD6WcWnoupOlmKEdrmTro67mwYLvoqBEAkADgZCYDtl2OvmgZZlpMHFoPG3iwe41uDOQyU xjnrGIHiPDaINN0JDgBX0hq0rcVT7VUKBAgVDdv9X3X4sHWFo12ISoB/2pBBSjDyFYQH8p1eAvWK g8/jJuu2ARg/WvdN8q7y3tRGQS7+4fOmikbelorexsk6R5V0fkn30ZELTaAGESTYRRu9gIu4o2UC VLe1khsvYAx0MjaA2fIBNJRQHTpGREtUr4UKPj0UDQIv+PwvdqMiRmQUdhcQyB1R/4A8OD11D1cO ATRVCVpH0QUc0xtZCkoTaAGuUhbnINDzRiey5gQdBogeCoQaFC0On8A1oVuRAaqlRWpcCuieoSOi PJIB8OcXcAP0YMRCaLxq2yAADeUE3We1PB2Fo3YLaLDqPKPPFih6KRGgEGiMXdXmfgejZBQMo2ih 5gC4ewusFv/Q+HhS1fveoRW9UxHNEOqZAq1NTvBiWFD66yvC1QYLSOO0g6KLYEYhQTmBtpevPAkq BnQYFghN+3UXGCmjHXREvwTrQgznWZ5ncHA1eHixHbKCKGMp7uBZW2srokfhH0IpbISgwjsEEtkr iEWVumKp5Ud1dRb/hNRTGEtbxDd75yTZpTlRs9ZKyY43F+igkZoEGgh+Cwpwb2y3+AQQi1ZUEYLt VlAaoHVJDViBdj+W84zfVfQXdTf5EV+BYa8+p8EIaJRowrtkVtAqYV7xU6awGazgAvzKPUED7F24 FEJ84smJD5p/0ABKsJhHTAQNVkhZMbSdYOcIFQtZtYkSpVrBM0YlUh/g0QwV1IdLdAWvrE9yBFAS WMH2gAU5cEH0URtmBW8OUr64BBWE60U0/MXDos2IkVaQy//IAoZeHTmZ8oHZ3rIbGBXcKr6qHNq/ dRANAB8vjYXFU9kDYBZVEjRS24noNQLsN/sDQ+wRxH1FKdmdQK+KB94IFY4Rj0sa69gBOAUXQjha Ap2CQFDADW9QKUh9RvGIN5uUmAcmPQg6KM8jAKYL2BwBGwNO1SAABWwaSrFl34yK3UX83iC0womy p6lhwht41QTCzAwyO8phuCEc8DvOc0IEXokKVPTAjJ+zVoqmYbXYNhs/FwPWgaGhIjATA8BcrxRx FpIXGbGkGQgIiq2iBqqCi3cCFyLgzgP2bTQ/wOEGdYm58YtN14nLk8WgfsHqH9Hhoi1QDoA2Uxcu 8uG2IhNvHOkLzvnY54nWSuwL0ercKh/0QAFnVQ8QsemFiMToO8JWR05ARxDf3t8TiVMEAgh2UVfw xH63ePONffDyU6WVz1MF0+R7QNYPcTsoNKOABwotVMuaYPAgIP92a6igHUe2Y185VRMBN6iXSwSK UuGAgHiMTrUN6sHuOxDRrbXA1tyA8P9zfgM3vqabbR9iczEQZR3/rQmqC/frZlxmP50ADqsKHVzC myrAUqOkWufAWmzOsaGJi1Xovo0C3Kosy7Lg1NDkJYhutx/siS6KD3EEUWmQdAr2WGCLymTB56Ne qnhXo3AJD4d3At6+AX0ulkEx+zF8DAQ5fwcDW3e1MkwviTq7q7B4qng2DgXBMytPFA2UIwIOl9S/ trRzOxkuJDzHjs1Y6zX3i4WnJNjm655OoWK2a1D1UX6uSnnb3APTZ0QxBC10LOXNfXkwdFJDD46J Sg1FfhKx3UeWY3tlD49yCGoGfUYzX+xPagsHpQklj5tzh7UAV1kLTZO1sNs1AO3CKS1IfTkVotEi TuM2x7jzByncagFa6w6LFmomKEXf7dVvBXTstBlzLvSvgOswIGpQbAX02GkQNriHKeu3Cmc5anOv WFrhXgLcsLEu12520E0n83AxkJErHBFshu9ETEa5ItMKzT6zjS0IAXbSXSFaAMx1YDYEPtzKkY5b T/6LTRCRZhBORMd0ZFviFQRJg2VYDuy+b+DMBYL2Mg+MGfPRFB9rj+lPCiEOoP4i/AlqCVhPCTBE 68Hc5koY4wlZbP9cAWgF5WyVG8IVBGW0nJ4sVqBELgcKT1iOmNk2fwqklRHeeCI2dgcwaUngcvYL yEmgmrbD6NBIVQNXHKBf4gNWto2U0IH+UBSAco8Vd8K+vlELcGwF1pdJN9BPYKhwNRz5OEMXfjYo PB/ZGFg5p3YVHA2m/4B9uwV8A/5Fu3q7SCAwR8I1JQiOhqWVvo8FkwAQ/BrysgMMmBoAtn8L6CpQ 7SoqdPs5W1uqWhR9+wMjCeCrZdlKlAcY3CsTuM7Cbz3BfjAH1LsD1C4DhqdVEMoBDLDQYB24JEZx KILWcmNDReNXB7DrJfHbvVNP0MesfHU3gzyeWpZtwEjCxsr2tbBbodU4Q2JK66sJZfsA3Eg/FWXQ KjEWsA8Whk2u69YvUOJacQaJWQKZQQqh3cKuZuwRoF89Q64DBc2yaZY+L4oBPzeBME3TNGDlz5sv qDYJitET2ogF74vIvs3xt2bTbAu3LlfGIswD5eZN0zRN5+jp6uvsyHbZNO3u++8/ovwr9UbF0DpD Ai2cBdBAZaIguN0e/kbQUkIaanUVZoMjAHTH5fYYAwMBBDBsNExmItqHC2p6uElmxxbQaixaanVH D05yoQITxTLgagbi1N1GlnQVgfzfHuu+dyF1LmjYGQ8yIxAdaNC6CURrjVnCZwUc2d8pJGglaMgc Bg4WSm2A4QKTzyFB8BL86RhpwBBNKu4IZvzCDXJ04QxOXVX6a8lNaEP9C8f2jbQBDO28McH+pKHx JbjyD7/GOdzwfKEKw9Co+v8/cksXsx0g5EYYQmP2rgRvG1YBRzN0Ecc1i263iwN+fwiQMjkQgyXU 7UJBPRVfhXX6hV0jSnhTfPoATjcczMwcCEWWyRxZh1tsxXXxBxdngeYDbml72H4NHP1OGvPyAdnE l94KIZkcflD5FI118LJJvLJSCCRVS8kOM1AXDHEVNPSt0IpFNmSAZfsARQQlWi0NCRwULFFBq7QE IYphRxtFl7i3NY1UfDCGDwf00gXxBkjr8UBahb90QGb/jQAqwywDiFMHYEVjo+kYxijNtlW6Lwyg Ayz02QjeShgDa4BjBT2pqoc703F1BDApwlAzoCIcuUmNBcmRCwEx4hE3/3ajDNUHuOy8wP4E1QGa gAeLXbVF0BRnBvhOuaKOKr+XVzaNooEaBVTT7aFt5OTvdD7HLx5VQaoPYltINiGFV1CJYmfvZzp8 +51R7BwvKnW4lcOkilBT3/UEswehYrFGRFSBueCuAGoDwSWANFH9BQzXzoDhf+sNgbvgu3Bu/HUR gMmANIgKDCTgxmYlzQPG5oIRk0BIJJ222IAti0vhV2bsT5e2Q+QSRv/5urczbbz9/vgjwiPKgeeD Zj0RjRQBtghNZYhaAdLLf/rkj2wKrfr9vw+Hor8/d+Cw7QqtOmbxukbN0Fa1YwxWCBUdhUu1OfYU OQZgpTeh11G1XQ/oHh5ZotKtsRY5Zr85A4Lv0HcsL4kGJH6Pl1Tczq38CAwFDwPASFWjPSFJ3jeg 2qsq0AxHmQsQ3wrUCE0CCQ+vwWC00V0xwfxRljGrBQ7IMQY+MbXCjS9Zg230AovodW0S7a8JqAgv DFh/nIGRtEuf3ALAzPp+JWbngMRFBiFTGMgIns3Ojh1/4gY5FTJ9Kw1iYSlMCIYBl2YFU7fYPdwB IGBAr2BbmlVL6ibscI1aaGob3Nxfd9eotlCK3DZCPQxSgWpbfjUg3i6x1V2W7d4ACeId4gAq5ivQ MnRECzDQPii4ba1FF8kH63lF4gA+uL7M3kOmcxu7orZebN4LxxsOQk4Ct4W2bAXkBg7Y6xr33zZg cNUb/wvWGYHHRAWi1gMxyvoyChoGWlO78CJgBwU0y+tggtpPbSJjfWq7ULMT6pXGuvEMFhCpcI5B wVeNIUG1w1TKQFCJ1f6pdtOtKieNv4E8g2D2C+1WaYOqNfSlAGP2XhOgFY6NxDzFbNdjPnXDe6fo uiAyhDBAnKop/gk6X3VAV7iiUAUKU7QvjKa8ZPs9PR/rIxx4DGEjmyNQpwACnMSLXRFJ/nUUO/N+ EFbcFLEiWoM5vBQ8Rn4IFL4coZzEG5gNKUZW1F1RNRTtrzpqAZ1SLIHi8Lt4RaDY3AlSGZgl1sCd qBmxLr1oxGcloKI6939B4ivCFTin/CpcOYNWUaEi4NuXIcQCciIeyjhdygsFYtvKUC/TvoSKAE3Q /wk6CHIEOsp2rUAP5oOMfRs2pb0xMKWdoowsJ5YYCGE3ZtrPeJ404n449yQ1pIFiVvwJ6UCbwAwq zwCUdcUEBoVRFmCItWFlJRFTQGG2zZuE3DuTqs7ui6RbV1qLNeFsQvtReXFIc9Z5xYOi4eAqYcAn 5BcGDPyJfdjbM9bYiJH/4DktGku8CYNivBYWFY9lUCMidKqFnNu0A6jHn1ShCHRVaj2jErEwIRqZ WXhTbILidED9O6FYzd3gN304XgEPlIQFXA1cN94CT9o8xKMbAnVU5CleakMTGTk9lBFnYKDBIIG6 3xsGz1KXDAQxOGDPGh1035AzdRMat0XLM2DEK009J4o6SIYfQTwDKVqJx458Q4PhXwB9EaJ/Mv80 t408t1QUCwB8xULzRsPrGp0gCqbOromeLIjWPOs1hXRRqL0Et+syPS4JAqz0YqF9tSU5J6DAsZDK QC2qYq3v2gywg2SwPrCAF72nmUaKklDu2QSZknQuF1PbLTh7kVkrY1kO7fjfIt5A99sb2/fTI9hu FRDJIMARr78rghUbo+PWpJwoueAtmb42qY1KVpgDBtMKggVqONseg+gm4YJKFtcj9kTAbwU7wfh3 ww/RWNUC+jvJLDTswDGdX8MZjRd0AsBVG+kQPQBaK+Ep5vUBMqiXPUjFi+4Yh63d0qffkxNQ5QR6 iBro1sKJ/wNZJOkCmommLMXEV8AAGKzoHqucoDfCaQtY/20i4gDKOxhikZGRrZ0FFBAMz5GRkQgE APxh+J4jIyP01BxiII6MPEfwYezoJGIyMvJ85GHg3Ng9REEzUMzOwW3GNhUGBdcKFBVpHxWPjBUg uMhsmKHUkEu6kSvw8DWCCrZibSATFRlk2Qcm/8ysrL42cE8TAc4Ibrts2NgVwx4H3C725EMuAo1N nLgwZ8Imm1zYB8gPI4McFgeouLg52dqwmEn/E+D48mywA9QvxBsgbtWF/QKkJzPrFIBsKbtoUG5T 9/Ai4S17uIgqTyPZFtjkzAeauIE9OyyfFAhvi8NlS04wb/e02cAmW/bWuGAcW5ATyLsDG7hvECeZ x7jgYFuSAwhweHAzJwd2MuiIE+CwAHJyIPDYGUCu5ABxKFDBkpMD7HgVfCjiJlwk1bKFDbsNuKAZ F9F5sjFsyB8r5PhxBoQdIRsgcgvMEoZFljgIMnaXsezsvEJILp+IsGyyZRRrsBMsDCOE314ycglk YyXnE+TYJ2vJCHMfN/C4OBcpIJNM8GAXJcxtLuw7Tu8Hvvdm77s0mAeLF6y8l5LB53OZI0PSgCzP dLjzmNmQDEn7uIgH2dkpoIRqWE4jZS9hU7h0f8tSkAFkdHXDOZCmUWN10GRLzgbgR2ATMIJgyZDj DuGQbVlGuI0P4Fvy7MA7DBMIdieGHWAPMHZPWBXj2QjP0z9R0zSCgHYDzj5mCd8LEB+wJhlkQvDw 4BlLWEpfKkR2ypY9EHeHR0h3h102g0dCGZ0KQHlGdpedUAppmFzzlXkuGWh0+Fg2GQoxpP9qU3cG A/JK39h3yKChsMkWp+wHY0AOBk8AeKyfwZBBBsR8Ahvsm/kHjD7gB6zLfkamaUW4cFbMXCSxrI3P HCcnpWRjy3nHAASEZaUv9Bv/bMmGJIK/aHkfdmAMufBVmEyXPExIQ8vw8FxyySXw8PAIyCWX8PAx sJNLa/DQvw4sZZ+HuEB6E6Vo0ocJyx4rB5h6p4NwYFfAExg3CHayJWcb6BMYe4tJF8kAe3tnW6Ss F5h7W6/IgR0ZkHvsuPATgp4MxpBrNCvbG/ZQhG/a3N0HI78XZMBVLej+XmUXoaDR6kNkA/ZkO5xg vyCkZMIKNsg2yEj5RoCgB7I3mwywLe9DJduSXc8YfJTIEZSMzdRvWLq7ZEh6lDloiNVblqwQoE1j 2MgOC9mRobDwcMk2bFAyPXCQbAJ7IcAYfWOAQ99bCasTmVPAdCiDJVuAfsVFcmBLxLQgHUCeX7B+ aH/nDqzsYIe7mBPwlRxATtgAgAAWwOAogNcnQAB2yLgAAG2jiBMXEFsSA65rtstfEWETC0RaE14D mq5pmmKq8jkfuYKVTbPsA1EUBpq/FZfLbfMA/ws3FyY3FTrDO79srSZoByA/pKxNP+TW/f8NFtIR qOkAEEs2XJ/MP09uA7FyWKCa5ra5AT8G7NmsC29/PwDwvwd7QQYZQT0kH/v/5+c+gIQu0E914EGN 7bWg98awPi/tg5w84D8zIEBoayr/77bb0acOl6YDtAdzdHJpbmcgdG9vIGzrTna3bwgAoB/+pqQD 8A/2N3eyuaicByx2YWxpZCA3LtDtD3Bvc2l0aTgAOP0orM3N38C7APA/ZCwgTSBsd999CHkAAE0v ZC8GAFBNA0Gd7O/fRGVjZW1iZXIxTm92C09jtR/2r5YKU2VwdBRBdWd1e/PPz70HSnVsQQduZUFw cmlsPWvffE1hcmNoRmVicnULI2Fu99577wpnX1dTS0fvvde9Qzd5Qz87M7H23G8jYXR1cmQYT14J sPZg21RoEnMTV2VkfAx2rHB2VHUJTQsQU3UH9957bkM7Ny8nIxm/ZLwfPwfiyE+CmGx8NslAB8kc UEDo5gFR4fyGuSDrDy+RyrddQ7elA2iD+QeyywNVbq47tP9rbm93biBleGPpoSuwH2Buednoy2d9 0YcDh36uO3n20tQH3gMXLNUhl5fdBzDVN47Vl9Vhrjt5RtcyBzYDFzlMM8iciIzjbL+1rgLQEMkH BgIQBEUABdWP0fg1MA+iKDhQWAd517q/kDcwMFdQBw8gCwAIYGhgtdJtvgAAcHB4CAcVBwBC23jO GgEOfwDlZWaXD91sASn2AChsbArwb+efLsB+AVBBmUdBSXNQcm+tPRS+GnNzb3Lu52UPDW7+t8Jl bq0AS0VSTkVMMzIAZSswcvstWQDXaPPjbPNMc2d6HPTnA195bjF+1ZvfLWZyZXhwZm1vZDhoec12 35UnWF9jYWJzD2xkH6303tceZh9mFgeBjanjGA/zZcoAdINjYOZupVKjaQNxckEU9873zGGYBwAg B733mL0kM/43ByhMfuw7B2xvZzEwQhwOx9sYAIGDipHp4XA4mJ+mrS8mk8kUAgkQF2QymUweJSwz to+TyTpBSPNaA3K33bjRHF1tZWdycrsgE90BPXtMT1NTDQ0KmElOR5e1m5YO609NQRIRUq4L7fY2 MDI4CC0gRwVsZYhh63K1ILFSZHoNaJrbON9scDcnN9V0PVvb2loEjWiDcP0jZh4DdnN31XdpOGHw kqeQyzc2c3RkFu54BjVwGiB2aX11Ufi21iEzpWMjIMlNIV+sWShfNF/aa1uhKmhcL1gG3PvCTvbi XzE5929wZVhbwzWaMZIPInNjgmEyYCs4tnsbCBG2TGQZVyO7FYbkN221rHRovxBG8m1hL2xvY2sX 5hyDrTRkZS4Co2G4taIhcm0AED8QClt7cmFtIEptNi8MLYW9MDlPEEFCPmfaKm1fLis4wlegkXbh KHNfBs50HjAyHG5yrHWxLQV0OhFk5n/eFlrhTS1gOWYVVmlzBgfjH6pDKysgUpxMaQwc5gaDCwot FkWtcbY9DiERUNQ6vgDQtWGXLgA85eAlddt6SSdJPv9UNUZYA7Q6Lr1HZXRMd3RBEnY+25kzLb51 1BMPV6VkCvRdTWdNYmFnZUJvVqa3Cg24NVUuZGzdfE/+/TEjUU5BTgdJTkYARAAXU/zc8otnukm+ AwspSrCEdbctAyijQYsLaQaQ7kAXAWACON1yADBrGAMAfSEbMl9IE0NYNF8CmxMzNwKA2CDNkECQ gIeQDCRDuNAhhMG+Q+ATsAdC0l3YCGwzARMgkm+B/TsobMcvTAXy7Bso/2x3wKQvJAPIgJg7su9E sKATw+PoI7qzBxZbeE0bgwcBKx2eaY43R9w3BhvkCqSvLwkZbCBpUNxnxGywwQbMD9QH8w++yaYZ +wUDTgcHQNKc7GcLTgi4Zwb53CwnBzQ8y4MMNthED0wHVFzwC9J0XwZkmxhupBkskC8nAkAZbLCB jL+ULwNmkIGkcKiwA8mAfYO4Z6jUSTPIIMwG2HaQkwMAT/gXTweEgwxyHycvTw9WYoW8KG9rp0IS 1lqed5IBG2RgWC+AGbBBBoSMh7BIBmwgoCfYV8gBGbQAcMjIFXJg/3DckiafGycvYMPyjaSXB79f eJBM9gCtK0CnqA5kAzL80CcQUEAGkkv4JAzIFXIgcThIJAMykExwA8mADGCYdMhAMiDAiFMDSTMC 6KCuhQzIpv+uUHIMJAN2wCdA1DaQNIMEaOh//UzTDfMHAfuzA1GADSSXZ6gYJ80gA8nQLAL4PcAM JEB3kCvkgC8oc3QbyAZsbIdYL5gnwQaSAYCw/6bk050LfwF0QcgRksVB0FGbP9MM8pnYB+DoBWLU NE3wBvgHVHqwsPcPBz/PfCVjHPQPdGZCQMkr5CQfSHQUUgayy+AcUr94LzDmBotkX49AB2PZk68u BwNjUlhSz7KA9eRgUmhS/18VcsAGgCcAdTqQDMiUKKhSCANZwP8nxAcMJAM2vC+A6EAyYIPwh7Bk ILnsBFMn2BiAXCEHAHYsMiADyShAUJAMyEBUeEDSDDJoAqBIBuzsfFMbhC/QckAGGZykAHcMMsgV vMQDN8hA0jDc5GdAMiBNAe9oZJc86QRUHwxUmC/ypIMMJCxUHzdUybM8eUJUTVQEVORl8ORjVG5U N/h3kM1ggYcKIHhskEGunKSsB5BBBhm0vMRBBhlkzNTcBpJmsORvCZD48uTJwfcAVQhVE1VBBjt5 G1UjByvkJXSQMztVp/h4ByzIK1BVLyh5IINcIWx0MshAMliIkIMMJAOIpK8OJM0gA7jEVRlskBMn z9o3CnnGgaTw8FVX+FUnT548A1YOVhlWJDTdyZNWL1Y6BwBIyMsYwT9WZ2B6QBawV2RW/yckAzbY eF+AV7gDyYANmH/grOQKOSAIe8AGsgEZyDgv3JAr5MD/e/AGGcg6ex9XV0EGkssvuCTYQHLZLFeH 6EQnnL1CDhB8WFf/EWawgewnbH908uTHew8HR39XilfTNE13kgcFmgaidA8wTQet4wcJ0jRN08MK zgvZ2GCDDOHpJ/E3QNIMNvynB+BusgDnFFj3WAdpmkGaAi86BEIVMmAHTVj/fTx58uRgWGtYa1hz WGYnT557WINYix++Nzn2B/+DWCcPk2mapukfCp4LqQw22BeksQcOFw8nR4DnC/8PfY9YfhvkSyD/ xM+3ZJDBBten4u12kKYb9XcG/QVZLyBfsG8HCRen9aKEvcntR28Qku+Z5a+XcCvkJD8XTpVAoH4g u+TJIFkYWdAvTJ4dZExEWe9jWdSXbFLro7NSmyH5Jr8fQBwapyADyCVg7QbrDL+TKH/PA+ibd8lz 1sEbSH//AX8DyWUDWSewjPIb2IxZR2tvwaYOJANyuPigWSBXyMsnIIC0HsxAMkjIJ4CQlxxA1ahQ gJLLnrxfqHCAj7CBZEAG3Ng8hmSQ8LAQGxjkmwBbQ+BxIBEHAW+BQROIbAAEA5fLP4L7FEAAozU6 P7xKcrlcLvV+moXihoWHsmma5SiIgLXqWIUul8vlH4lzm7ucXp0BnuuapllZjsOUH8EjXG67phT4 D0ylA+2oT6q53E5CT9WwF2PYPPLYZSd5RhRBC9kjVxcU/asIl0JDREWp6P8LzElKS0xNTk9QUVJT VDH///9/WFlaYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXowW5Dg/zEyMzQ1Njc4OSsv80Mzf2v/ /0YwRkFGMTBFMTYwQTJGNDIHCkVEQTRBNbf97e0yOTINMjhCATMwOEFFNSU5N8Bu2/9DQTlGOENG RkImQlMzNTPf3GwPYSu7XCVzCkY3NTg01r5t2zAybzaRNQ40MTU0UHxt92/tNkMUkDkwOTRGQ0Nl OTEQbu232DE4PyA5ODM5QSUTM0Raa23bW0QxQza7Pbhrt9bdezlEdjRLUDQ3P+Bt27ZdCzND5jIj Ny9EHNbabmutJUadQzNQej621tq3N0Q3NzOdhAaeNltrt9ZAB4pBM4NL0EV1W3u3ODYxNNd7FTlS NyFBh7BXNXegdwvEJWLWAC6TKiTPkvwuKgB4OlwvRqI/6EM2oQ9Gcm9tuw0KRSzPvwkHPCVzPiIi QrEB2jdUb/Nianlve4XiAETuGxogAue/BP1jJTQuNGQSSDptbTpzcwCPBJmgZBQPSW1wsIhLxW9y uGNlx4rfKh5PdXQPayBFeHDoCr+1mUc2LjAwLnoEMEnQP6uSWC1NYWlsN/6NHYqfE1MVLVByaXe2 o94SaXR5ZyAoHikfRbjushg7y2ZA0Jur2OY9IlOEY2htru3aDwRpbmwCj0NvDRChCBL0LURpc+sn 7XZ72BdUcrdzZoMtRb5YcwvFb2SfOvNXW0/mDLNXIA8veXBljDPYeyKzEyB7ih/FdnBwdGNUL28a Rak1wS0Rh4ttFBF3Ai1Y98k2Gu1D/25ZZBew99prAxkDBQdtS2SH9klEa6mvq4u10hb3YX9xrkPC TkvFsHR8t7CBzd5bc5MjKtpTsXVwTaMotFb1CGgEDQi7oJ9iYm8TcnkSanL/bVtTbXRwTXNnUCzy WM5iv2vzX9lfJTguOFhf8VS2rCu0I/4CYVsJaBUxile7CI+H30dJTUUgZuB0c4BhmLkoFyMFbL+N Rlc1ACgtVpJz0MLeM2Af6JgYsMMbk2l4ZVe7AGHLXFuDbAgV2btfSJgcMDdrPfDvGneSPSUywBwg LTsuLD8hAJvrj4eCIHTnJWRtcyYuyNf4fQMuMzdibwc4QK3UPXF1b4YtDjNuuvA7SRNiYbU2NHtN VFC0dsIRt2Nwu3CzJm9vXXLHSy04KTktMQtRVUkQhvCHVBlFSExPJCsG4MLyUGF3Q2Q6xv33KBWn uwtBVVRIIH8Dmr0uR0lOJ71MIEZST03jsYoZWKNDUFTEWzGXbE8RvxfJVPkFGr5BCEEgNroyNDdB Rq3funVEMLtGNf5DMkUzReMBA8dqGLMwQ/JZawVcWyEz4wAyI26ttkAdMgv0EEQ2rRmI0DoHfwvL 1g782jlCFxZCQQElEraxrcE2Yy0xRzIeRIF2awXyQPQ0RF8lWgEDXQgyWV1ha9pi3X82NuxoRj4w JCjQoIEIGki0dms3IEEwCkA5Qyw0a1uDGTscmzA4nwwUaFsZQq1fkijg2tacRUMIf5ba1hpEnwdg EUIfa1trDVUhozEybwoo0KBAv1GLYKKNOXZrMR4ArbW2dRQw4DTZm3YcBg4MtEO71VQzZWutcDHB JHj0MmsdNGh3FmhCCH5rsdZanxpI13pf3Na2QhI8NvkjRHZt0LbWQwckNy66MtBaQ6zZRxtDOC9a c11rbYTrRiXmNos5aA5076qz+DNtXWEzZMo1OkRr+HPN0FoKmw/WWxyaaANsRSOdcTAQK7jWFCwF TNcOboXtqIlEC/c1Nak0sTW0OHlKQa1DHDRWNnAnr0Y2tTYUWnvbwjUTQ5lBn+PY0CK01gxUTtMx tUKjsCBFtAkOswwnNrfzOU0IRZkD11xi1u1H+jM0N/2JVijdMR9CPJ1Eay3WWpRyszHDX+Faa21F sEj1dXY0F82wXTfv2EakBQq3GC9ENUI2PLYVWmsBtwNO9kMs5gqGwjkXlypSR1x3ay2r4881M9cx tIaJW9sOQvC9NkKsHeZc4bUHI1ENsbihta2JczelMdCiDcVMNEMtpfuP0G3NsDlF3a2dNbYwa1tr zfUYD7RbMhT02kJrbzUDeEOrMadotELZQEHhgQEwH9vWPbxCbTSDMWsF17UB8DKMO6Ipa9vWWnP8 bUVMNj1numitBaIzI0xCLprBUBQEwNTWYq21QzlSEiP+C5vwMLQxCVB3DBnaw0LwQiY4PRZrjeYo DU+YKUwF2oapaTKXRjx7MjSVn7HQxz8yyzRCQjihmRoMTCNBk/1rTK3RmsNr/Tsbo2GpxSN3M0Yf RNUYctGaPayZAZvRZGoZA1EyOxsKptZaFWfmVDfmToYajjB/N+kGKBgKsbP82/EwtEZriELsmQd8 UqHhaqg2Aq8pW7TWDG04fAUEF7UB1igfOUc5zVRorenWwX3FhkYzHWoa+z+JpLBFKrWSvOtnQ4Ft rckFaThlTEZrwmbINDMpxyEzhRwPTS3cOEVjQ60MsAHWZWtHzrRRMBPuoDcIAzC41wqP3RE1mTVT oVG65JIaNlFwrcHN7zfWowKaaXOtY9aVK0VFHqPWcLnUvM32O9DkaK02mD99BzKjNSAzPmNL6Npo zpSoNKoWNI/N1OBP3zNlfDekCq49bVo0xjjzI/zgagzIY4KJDK0ZKPiEEAza0qNh2kwygNgHCqM5 EtgyY+P6KlFqNFfMHlSOaIV2qmOGFd0/oLWF5kxDjkVjezlK7mT0GLapABepQMFuIojzbwVTBkpB qSjwa6BBa5R8XnhF74iAK1N6FjfB1OTqX0I3uzIJQ1przRRKiMvTfq5WqdU9LvIqNIhk6mrBnUOQ e2NEG5WvyHLOACs010eEQneQS8hba19HZTldNwfRPkOVmqOVOX4YULw1t9BOu+jTM/SKqwZaoSZz ByhDj0GrtYYjbX8zm+FBw9SGNN8SOG2sYHKESd6rRpMwYGpoOCo3gb6hUHJQW16WQ38VDCaaoVRR h3DNGTDEm+vERkYrYOjpQeN53cGuFhyGEO0tRpFAo5kaopPf0modtO07Y0I2/0Mf1+a2Zj9lLjdN 70Z8z0ErOPxbxHqDzb2UqyQ+v3dhcfS5AAVHaxw9fPJqrWWgXP8edxQVIjhXG+lkxxE01+Qo6GTt NM0hOte6DMjAQrpQhjHgaM3UaLpEfgjQgWuiHV4xgAwzDIVCM7qLFduqDdoDNPg2NV5wyFMzmDcW BXszYGgdhiRTM084MNBFMDXX7kGhRKyhGVIdk0YToOCawxTbRNv0RecMzMsqMZxDhCEWzVMXj1nw ouHCzxdNK80xwIjvo0iYNVoBGn/oKYAdD0SiSasmMrszvSi4DJA3GbRAw1UwvLHKaP+GxX7TAQIA BhM6Mioi8Lf6/xoSCgI8NCwkHBQMBD7yJh4WDgZA/v8Lv0ooIBgQCKwpIRkRCQE7MysjGxMLAz01 ////pX4dFQ0FPzcvJx8XDwcoCDAQOBhAICcHLw//W/3/Nxc/HyYGLg42Fj4eJQUeNRU9HSQELAw0 9v///xQ8HCMDKwszEzsbIgIqCjISOhohASkJMRE5GSCMvnz59gMEBQEGBwgJCgsMDQ4PEBHLly9f EhMUFRYXGBkaGxwdHmHDhrUfLY+3l2HDhr2/k8Or//b/v9cOEQsYAQUDHA8GFQoXEw8aCBAHGxQN tf///wIpNB8lLzceKDMtITAsMSc4IjUuKjIkHSAd/7/9v3sdDBwRAQ8XGgUSH2gIGA4gGwMJEw0e BhYLpeB/+wQZDgQNuQ8LCAMKBgwFCQLfdm1rdmMCEw4LCWcIBAEObt+2/wgNBgILDwwJByMFHgwI AgS2BwVr7Tfaqg6eBg0PAQigCxLXtv9tBzQMAAUKAw0EBw9kDgtC23b3bQkLMA4HCwpjBQgMDgNp DbZdof0ICgEDDwRQKC4OCUMJWmvt1j8QBQE9KBZrWmvu1oEmBAanHIFdta391ntaCA8DAAulnwpM rb21tlUNdRGkDw4DXRMtuObaBw0HEFQwdARbtu3NXxUGDwBCBy8BCYRrrbmtAEcHp68uzmpr7tZa LSwlCQQuI+rWWttaM8wKjT0ZWWtuc7cvDgsRLgHpy2dtrTVafV6/lIIJDK1trX6nIAvHgyDa5rbm Y1tDA2QaAj7NNWyluHIOFQrb2W2FtrUJK2MOtD9QD3NbM992DAMHAARngAIdW6617XYLDnYGAO4E byEH25prhgNf3zU02wm5ddtWuAMFDC1/ASANPQ73trmuV2MFaQ4IEwoHCaDbNrc1hjUN04sLMAnf rtsOrgCbYS8ErQvOCq61hgJUAbop9QPK1lrbUwjOpT5vD0QywhUkIy8f+QpibRtlLj9BVgl7GAAD QEAXfVRvVQtpY18UQGBhrlQJHTcHtrC3GWd0aCAfbz/sEvx1dF9vZl9RZ2UfYD0L3/3Avv2PVBsQ jmXqKyvRGS9fY29tATApgk0w3yy/hMsDdZhz2r5AAPGtNLAgANUDNE2z/AikQQDIZMTAvLjTNE3T tLCooJhN0zVNjIB4L2xoZDRN0zRgXFhUUNM0TdNMSERAPA3SNE00KCAYEGmWTdMDCAD0Y+zgpmma ptTQzMSwSNgu3bySJxSazMcCXy3hl2B0G19pbmZvDhCPrOArF+rWqsCbbXfIFwc77KXkkrUQZyKA vZUNHwMATGRfRYDBQR+wrAzZkMgPmLtkt5yiLGYcA1I0y+8GC3sECDekA2B+Ig7ygnmCIabfagCh pfkegU+f4PxffoD8L6icHcK+waPaoyB3gf4HQCBDYIO1L0FXyP/dtl/PouSiGgDlouiiW37kt7vP of5RBQPaXtpfX9pq2jKvye2v09je4Pk5MX4+niFqyfgDjQMyyZS5aQEoIDKRPABIABCEgEzIABCB DMgQyAEQgskQyIACEMFVlbm/AAGgD0LSSy6PHtM0Tec3A1p4l7WmWTZN1PMRATBONE132W0BMzoD WXeW6x5N07TT8ocnLwPNL5uuTQdsFABIZ0EAHUQ0TdM0GkAbOB/TNE3TMBMoISCa7jVNDhgNUwcP CLLpImEmBwX4Zk3TNM0e9BLwIOw1TdM0DOQL3BWmaZru1wcczBnENN1rmhG8GMcHFqzTNE3TF6Qi oCPkIV9NnCT/ZvB/G5J49vj/AO9/zIAHgy0JDxBEfxMwjxkAkGZDQ0PUhAMAcBtOlN1B2VBTVEtQ RDMbJco/G64DyEIGgEcPSDPI7QULwAsdBIM0AzKWjQiOIAMyII+QMiADMpGSk9ggTQMDrwcKl9HD VXYK1wJfaZ5pms7vB8QJmDo96UmtUldIaQ8Yab7upCdP9GiXyAcYq2g9edKTN2hoxzBo+GdN03Qn V9AHeMB5sJZd0zR6oPxHgJT/AtJRdw8BwxZIE9731wcEf1/7IN0g3QbzCQwHCIB8L8gJvxsLXrDv vVc7Bw9X35DvvfcT39sDFyFBBhlsNQ9BQwYbbLBQM1IXUwdXG2ywwV9Ze2wXbasFaZqmIHAcchts sO/HL4CzgQeCH2awQQaDhI+RbJBBmimeoaRvsMEGGae3n84fLDsHYdcLGAcA3ytUPFgBXecfQGeq TnaP/wOBs7tCdjRICH8blCayBTjkLrGLxAOEucGufwC4LwDJS072oAJAC8gF+gg8yZM8QJwMUMMP JPQSJz/kh4CWmBYgvL4ZBP////m/yRuONKHtzM4bwtNOQCDwnrVwK6itxZ1pQND/////Xf0l5RqO Txnrg0BxlteVQw4FjSmvnkD5v6BE7YESj4H///b/grlAvzzVps//SR94PEBvxuCM6YDJR7qTqEG8 hf////9rVSc5jfdw4HxCvN2O3vmd++t+qlFDoeZ248zyKS+Egf////8mRCgQF6r4rhDjxcT6ROun 1PP36+FKepXPRWXMx5EOpkD///+uoBnjo0YNZRcMdYGGdXbJSE1YQuSnkzn//78RX7LtU02n5V09 xV07i56SWv9dpvChIP/////AVKWMN2HR/Ytai9glXYn522eqlfjzJ7+iyF3dgG5MyZ+13/+blyCK AlJgxCV1+s3MAQD7P3H////7PQrXo3AE+D9aZDvfT42XbhKD9T/D0yxlGeJYF/////+30fE/0A8j hEcbR6zFp+4/QKa2aWyvBb03hus/Mz28Qv////965dWUv9bnP8L9/c5hhBF3zKvkPy9MW+FNxL6U lebJP/////+SxFM7dUTNFL6arz/eZ7qUOUWtHrHPlD8kI8bivLo7Me3///9hi3o/YVVZwX6xU3wS u18/1+4vjQa+koUV+0Qj/////z+l6TmlJ+p/qCo/fayh5LxkfEbQ3VU+Y3sGzCNUd4P//////5GB PZH6Ohl6YyVDMcCsPCGJ0TiCR5e4AP3XO9yIWAgb/////7Ho44amAzvGhEVCB7aZdTfbLjozcRzS I9sy7kmQWjmm/////4e+wFfapYKmorUy4miyEadSn0RZtxAsJUnkLTY0T1Ou/////85rJY9ZBKTA 3sJ9++jGHp7niFpXkTy/UIMiGE5LZWL9VPzf/oOPrwaUfREt3p/O0sgE3abYCshCEJFPAERUsqgC CJARF6hd0A8UUOlDb1fVjYJtimVTh6jKt9tXD2xzCWxlbkHaDlQTlt0NU7b936JHb2ZSZXNvdXJj ZQ9GLrv9bNhkDSxNb2R1OUhhF49AFWxsEbtzRGmLqttuX2N0RHkVSZQCt3UPQ3IJYwpTG7+y7aZI AURlN3QWTGVhdjMlf2UVRW50ZXJJaNsmqqJlZApjdcG2doCD4hFzl8+9tmxOUmS7CaAI3Wube9gj LGE7D6RTOIvNbgVlcOI7Ck52b1YqDiAORHJzBa11ww9KRIumsXcQTKU5b2eZFe2SnLBzmERlJ1Rp sQratgpaumUgeZM9N3vGPz0cJUYMe8FiH2yrD8UOlz2xYwlwZjNLEG+hbdx1ZwJwmE14awJ4YnVn 5yHbsLZ7+nWXTmFdPRFpm1Q1hEEN2Q/btmHtb1XqxWKZRiA6zD1sZQtBbNgzVLHL9qLxXlNFduTE 5rrCV2Gkq1N2QE+M2LAT2SwhPNHe7A1jjROrQni4ABR1cBpBQnOtAXFFeGZOgYeeJaHqRRTdc1cC eIfHf1VuaPMuG2HOTbdeQzV0xmCHN4LGgWQ3rqFtH0lzQtdXKBZ0Qslmj6pWyfsNzGbbCRVI2nDf C9R2bCh3WG95yUNNDf1ZwJJoDXlPRU1DUITXgo0JQQcG+0y1xozbhU9mtxqIm80mVIk4RLRlsyHp V89BO+rIDBDlVmHyOHuHv9koX1BvaWgP/mFWegPIOu4LU2zCNmhkCg1W5lYIsQ11UE0JhDdjlYC6 8BFLYBcWkEFsl6NEK5QBeGkQYxPEWAxNUkJ5f5hrW6tvdJdDg3AJhIdkbRMePWOoOKHcPlJ0bK13 aQx5hDepVKaXcu3Mt3UItvWQ7XKTWo3uDORJN1LcHq0rbcnpD1RE5lZhhNYd0nVlYm3zTGRy9oIF ETYpV0t6VQ1UA2+sl2xgaRKHqcNtQuBTlkZpc2i3I8mY+0J1ZmZbgkewznKBFx7xCQEAjm3DFqpn o7lBD09wa7TD3mtLZXkOURlbIGwuAgkGIUYWLjy32ZhRV06lFqx1bXiz780ORg1BDgoMNlsyIjke LFJyWPmWQQUNVQ8UsU1KPCNztaqa68u+vmpZtk2zeiio/wcClZZmW5ZlBgLICV41qlbVn0BVUkxE aChFtK7VVEuJBqdzE9YdusiSadIviPtmQUwrbE+zBWBL1BACc7Isy7J0FBUWN8iyLNsSeAQXAwiW ZTPbE3sPAjQLDBypalkKEQBQRcM/yL8BAwBEk9c+4AAPAQsBBoYS9TCqmqjJHdzsFHVgCgsDXbLB osQEPB8QsLFkUUwMEActBws2Bi8YgbTYbkBYK6dIAh77HBFXLjWjSq82F/YF6xBFIC5yQW4mABX7 4ivWXDaEMAMCQC4mySDNLSc4SJCQ8GWLT8AA0AHQhGHXAQAAAAAAAABIAP9gvgAgQQCNvgDw/v9X g83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D 7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78EdsRyXUgQQHb dQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oCQogHR0l19+lj ////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5zQoAAIoHRyzoPAF394A/CnXyiweKXwRmwegI wcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4A0AEAiwcJwHRFi18EjYQwAPABAAHzUIPHCP+WtPABAJWK B0cIwHTcifl5Bw+3B0dQR7lXSPKuVf+WuPABAAnAdAeJA4PDBOvY/5a88AEAYel71f7/AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD8AAIAtAACAAAAAAAAAAAAAAAAAAkBAgDEAAIAAAAAAAAAAAAAAAAA FgECAMwAAgAAAAAAAAAAAAAAAAAeAQIA1AACAAAAAAAAAAAAAAAAACgBAgDcAAIAAAAAAAAAAAAA AAAANQECAOQAAgAAAAAAAAAAAAAAAABAAQIA7AACAAAAAAAAAAAAAAAAAEsBAgD0AAIAAAAAAAAA AAAAAAAAAAAAAAAAAABWAQIAZAECAHQBAgAAAAAAggECAAAAAACQAQIAAAAAAKABAgAAAAAACQAA gAAAAACoAQIAAAAAAMIBAgAAAAAAEQAAgAAAAABLRVJORUwzMi5ETEwAQURWQVBJMzIuZGxsAE1Q Ui5kbGwAb2xlMzIuZGxsAE9MRUFVVDMyLmRsbAB1cmxtb24uZGxsAFVTRVIzMi5kbGwAV1NPQ0sz Mi5kbGwAAExvYWRMaWJyYXJ5QQAAR2V0UHJvY0FkZHJlc3MAAEV4aXRQcm9jZXNzAAAAUmVnQ2xv c2VLZXkAAABXTmV0Q2xvc2VFbnVtAAAAT2xlUnVuAABVUkxEb3dubG9hZFRvQ2FjaGVGaWxlQQAA AHdzcHJpbnRmQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAvQAAAFhDMDAxODE1ZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAqQUAAFhDMDAxODE1ZA== --CSmtpMsgPart123X456_000_000705C7-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 4 11:56:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54IuNTX015689; Wed, 4 Jun 2003 11:56:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h54IuNN8015688; Wed, 4 Jun 2003 11:56:23 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54IuKTX015681 for ; Wed, 4 Jun 2003 11:56:20 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h54IsdNh003616 for ; Wed, 4 Jun 2003 11:54:39 -0700 (PDT) Received: from fuchsia.home (ip30.coe.tnet.co.th [203.146.155.30]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h54IsVYU029062 for ; Wed, 4 Jun 2003 12:54:32 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h54IqSbA000462; Thu, 5 Jun 2003 01:52:42 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h54I4qh10989; Thu, 5 Jun 2003 01:04:52 +0700 (ICT) From: Robert Elz To: Bob Hinden cc: IPng Subject: Re: Status of In-Reply-To: <4.3.2.7.2.20030604072330.02ba46d8@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20030604072330.02ba46d8@mailhost.iprg.nokia.com> <3EDD3A74.1050603@sun.com> <3EDD3A74.1050603@sun.com> <3EDCE830.50908@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jun 2003 01:04:52 +0700 Message-ID: <10987.1054749892@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 04 Jun 2003 07:29:05 -0700 From: Bob Hinden Message-ID: <4.3.2.7.2.20030604072330.02ba46d8@mailhost.iprg.nokia.com> | I think you are suggesting that the draft be changed to reuse the FEC0::/10 | space with a resulting 38-bit global ID. This would allow for | 274,877,906,944 prefixes, or 30 per person in 2050. I trust your calculations, so assuming they were all going to be unique, then yes, 50 years from now people wouldn't be able to have more than 30 or so non-routable /48's each (oh, such suffering!) But of course, they're not going to be unique, and don't have to be, so in practice, the limit per person would be much much higher (not quite 274,877,906,944 each, as the user will want to remain distinct from some others, but perhaps within a few orders of magnitude of that). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 4 15:53:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54MrNTX016486; Wed, 4 Jun 2003 15:53:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h54MrNG3016485; Wed, 4 Jun 2003 15:53:23 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54MrJTX016478 for ; Wed, 4 Jun 2003 15:53:19 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h54MpcNh023580 for ; Wed, 4 Jun 2003 15:51:38 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h54MpXep027997 for ; Wed, 4 Jun 2003 16:51:33 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HFZ00FJWBHW9Y@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 04 Jun 2003 16:51:33 -0600 (MDT) Received: from sun.com ([129.146.10.24]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HFZ001ZPBHVX2@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 04 Jun 2003 16:51:32 -0600 (MDT) Date: Wed, 04 Jun 2003 15:51:31 -0700 From: Alain Durand Subject: Re: Status of To: Robert Elz Cc: Fred Templin , Pekka Savola , Bob Hinden , IPng Message-id: <3EDE77F3.3070807@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: <3EDD3A74.1050603@sun.com> <3EDCE830.50908@iprg.nokia.com> <9861.1054735730@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: >What's more, there are cases where both will work. For those, which >order we select as the default determines which of the two is used. > I agree. > For >this case (which is for me actually the interesting case - if only >one address works, that's the one that will end up being used) which >order I'd prefer actually depends upon the application. > This is true. > For some, >using the global address is just fine (for some perhaps, even necessary). >For others, it isn't, and the local (more stable, probably) should be >preferred. > 100% agreed. Still, we have to pick a default. My point is that I'd rather like the default case to be that apps that require global addresses don't have anything special to do to work. - 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 Jun 4 16:58:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54NwCTX017296; Wed, 4 Jun 2003 16:58:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h54NwBG0017295; Wed, 4 Jun 2003 16:58:11 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h54Nw8TX017288 for ; Wed, 4 Jun 2003 16:58:08 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h54NuRuc027088 for ; Wed, 4 Jun 2003 16:56:27 -0700 (PDT) Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h54NuL3K026125 for ; Wed, 4 Jun 2003 17:56:22 -0600 (MDT) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h54NuGwc003027; Wed, 4 Jun 2003 16:56:16 -0700 (PDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id AAA04081; Thu, 5 Jun 2003 00:56:15 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Bob Hinden Cc: Robert Elz , IPng Subject: Re: Status of References: <3EDD3A74.1050603@sun.com> <3EDD3A74.1050603@sun.com> <3EDCE830.50908@iprg.nokia.com> <4.3.2.7.2.20030604072330.02ba46d8@mailhost.iprg.nokia.com> From: Ole Troan Date: Thu, 05 Jun 2003 00:56:15 +0100 In-Reply-To: <4.3.2.7.2.20030604072330.02ba46d8@mailhost.iprg.nokia.com> (Bob Hinden's message of "Wed, 04 Jun 2003 07:29:05 -0700") Message-ID: <7t5y90hcs80.fsf@mrwint.cisco.com> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2.95 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Hence, I see no real reason at all to stray from FEC0::/10 - and lots >>of reasons to remain in that space. > > I think you are suggesting that the draft be changed to reuse the > FEC0::/10 space with a resulting 38-bit global ID. This would allow > for 274,877,906,944 prefixes, or 30 per person in 2050. > > My preference would be for a larger global ID, but I would like to > hear what other folks think. I agree with kre, stick to fec0::/10. /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 Jun 4 17:59:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h550xkTX018172; Wed, 4 Jun 2003 17:59:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h550xjhS018171; Wed, 4 Jun 2003 17:59:45 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h550xfTX018164 for ; Wed, 4 Jun 2003 17:59:41 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h550w0Nh015324 for ; Wed, 4 Jun 2003 17:58:00 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h550vtht024908 for ; Wed, 4 Jun 2003 18:57:55 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.6+Sun/8.11.6+Mentat) with ESMTP id h550vRu08243; Wed, 4 Jun 2003 17:57:28 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.11.6+Sun/8.11.6+Mentat) with ESMTP id h550vSA26026; Wed, 4 Jun 2003 17:57:28 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id RAA25431; Wed, 4 Jun 2003 17:58:22 -0700 (PDT) Date: Wed, 4 Jun 2003 17:58:22 -0700 (PDT) From: Tim Hartrick Message-Id: <200306050058.RAA25431@feller.mentat.com> To: hinden@iprg.nokia.com, ot@cisco.com Subject: Re: Status of Cc: kre@munnari.oz.au, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > >>Hence, I see no real reason at all to stray from FEC0::/10 - and lots >>of reasons to remain in that space. > > I think you are suggesting that the draft be changed to reuse the > FEC0::/10 space with a resulting 38-bit global ID. This would allow > for 274,877,906,944 prefixes, or 30 per person in 2050. > > My preference would be for a larger global ID, but I would like to > hear what other folks think. > For what it is worth, I agree with kre as well. 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 Jun 4 18:34:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h551YXTX018594; Wed, 4 Jun 2003 18:34:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h551YXKM018593; Wed, 4 Jun 2003 18:34:33 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h551YUTX018586 for ; Wed, 4 Jun 2003 18:34:30 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h551WmNh003036 for ; Wed, 4 Jun 2003 18:32:48 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h551Wh3K014030 for ; Wed, 4 Jun 2003 19:32:43 -0600 (MDT) Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 4 Jun 2003 18:32:42 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 4 Jun 2003 18:32:40 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 04 Jun 2003 18:32:40 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 4 Jun 2003 18:32:39 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Jun 2003 18:32:36 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Wed, 4 Jun 2003 18:32:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Status of Date: Wed, 4 Jun 2003 18:32:25 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of Thread-Index: AcMq/jjX+OPUeYs0Q1+ZUqARZfDGbAAA2Xqw From: "Christian Huitema" To: "Tim Hartrick" , , Cc: , X-OriginalArrivalTime: 05 Jun 2003 01:32:26.0770 (UTC) FILETIME=[52546F20:01C32B02] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h551YUTX018587 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Bob, > > > > >>Hence, I see no real reason at all to stray from FEC0::/10 - and lots > >>of reasons to remain in that space. > > > > I think you are suggesting that the draft be changed to reuse the > > FEC0::/10 space with a resulting 38-bit global ID. This would allow > > for 274,877,906,944 prefixes, or 30 per person in 2050. > > > > My preference would be for a larger global ID, but I would like to > > hear what other folks think. > > > > For what it is worth, I agree with kre as well. Isn't that cool? We had this discussion before. In the spring of 1997, as a matter of fact. And the suggestion then was: > Date: Tue, 13 May 1997 11:25:42 -0400 > From: huitema@bellcore.com (Christian Huitema) > Subject: (IPng 3627) Re: W.G. Last Call on "Advanced Sockets API for IPv6" > > > Site-local addresses have the same problem as link-local when a > > host has interfaces in multiple sites, e.g. interface A belongs to > > site X and interface B belongs to site Y. > > In fact, site local addresses have all the problems related to non unique > addresses, which are well known and documented in e.g. RFC 1627. This may > be late in the game, but we should really consider a way to somehow avoid > or minimize the problems related to that non-uniqueness. > > Did we ever consider inserting some site identifier, e.g. a random value, > in the site local prefix ? I know that this would not make the problem > disappear entirely, I know that randomness leads to unhappy birthdays, > specially when the random number is not actually random (albeit the site > manager could actually trow dices, it is a one time operation). But we > could still go a long way... Did we not in fact go a long way those last 8 years? -- 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 Jun 4 19:57:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h552vhTX019427; Wed, 4 Jun 2003 19:57:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h552vheO019426; Wed, 4 Jun 2003 19:57:43 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h552vbTX019419 for ; Wed, 4 Jun 2003 19:57:37 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h552tuuc008743 for ; Wed, 4 Jun 2003 19:55:56 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h552toep003066 for ; Wed, 4 Jun 2003 20:55:51 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.6+Sun/8.11.6+Mentat) with ESMTP id h552uAu09056; Wed, 4 Jun 2003 19:56:10 -0700 (PDT) Received: from citrix (citrix [192.88.122.198]) by leo.mentat.com (8.11.6+Sun/8.11.6+Mentat) with SMTP id h552uAA01079; Wed, 4 Jun 2003 19:56:10 -0700 (PDT) Reply-To: From: "Tim Hartrick" To: "Christian Huitema" , "Tim Hartrick" , , Cc: , Subject: RE: Status of Date: Wed, 4 Jun 2003 19:56:08 -0700 Message-ID: <000001c32b0e$03cfc370$c67a58c0@citrix.mentat.com> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, > > > > For what it is worth, I agree with kre as well. > > Isn't that cool? We had this discussion before. In the spring of 1997, > as a matter of fact. And the suggestion then was: > I think of lots of things to call it, but "cool" is not one of them. 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 Jun 4 20:29:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h553TWTX019683; Wed, 4 Jun 2003 20:29:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h553TWPS019682; Wed, 4 Jun 2003 20:29:32 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h553TSTX019675 for ; Wed, 4 Jun 2003 20:29:28 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h553RkNh018466 for ; Wed, 4 Jun 2003 20:27:46 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h553Rfep014708 for ; Wed, 4 Jun 2003 21:27:41 -0600 (MDT) Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h553RfiU005587 for ; Wed, 4 Jun 2003 20:27:41 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h552RgPG021303 for ; Wed, 4 Jun 2003 21:27:44 -0500 Received: from motorola.com (aewhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.9/8.12.9) with ESMTP id h553Rae7000333 for ; Thu, 5 Jun 2003 13:27:36 +1000 (EST) Message-ID: <3EDEB8A8.708DF3DE@motorola.com> Date: Thu, 05 Jun 2003 13:27:36 +1000 From: Andrew White Reply-To: awhite@arc.corp.mot.com Organization: Motorola Australia Research Centre X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Subject: Re: Status of References: <3EDD3A74.1050603@sun.com> <3EDCE830.50908@iprg.nokia.com> <9861.1054735730@munnari.OZ.AU> <3EDE77F3.3070807@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain Durand wrote: > > 100% agreed. Still, we have to pick a default. > My point is that I'd rather like the default case to be that apps that > require global addresses don't have anything special to do to work. I prefer the behaviour specified by default address selection - pick the smallest 'scope' which matches unless the application has a good reason to do otherwise. Stability aside, the 'smallest matching scope' rule only fails for applications that forward addresses out-of-scope. In this case, either: - forward names, so that you get all in-scope options, not just the one that worked for the forwarder. - accept that your application is now delving into the routing space and code accordingly. The other way of looking at it is to observe that 'local' addresses are proposed as a solution for when 'global' addresses are unavailable, unstable, or otherwise untrusted. In other words, if local addresses exist the general assumption should be that the network wants applications to prefer them over global ones. I cannot think of an example for a non-forwarding connection where this would not be true. Note: 'prefer' is qualified by the source address selection rules, which will (among other things) prefer (in order): - matching scopes over non-matching - smaller scopes over larger - longest prefix match In a multi-addressing environment, applications must be ready to try multiple source-destination address pairs until one succeeds. A source address selection compliant gethostbyname will return the destinations in preferred order (taking into account available source addresses). There is an implementation question on what order the two dimensional destination and source space should be searched. -- 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 Jun 4 23:36:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h556aoTX020276; Wed, 4 Jun 2003 23:36:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h556aomR020275; Wed, 4 Jun 2003 23:36:50 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h556akTX020268 for ; Wed, 4 Jun 2003 23:36:47 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h556Z5Nh017668 for ; Wed, 4 Jun 2003 23:35:05 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h556Yw4Z019154 for ; Wed, 4 Jun 2003 23:34:59 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h556XQw30125; Thu, 5 Jun 2003 09:33:27 +0300 Date: Thu, 5 Jun 2003 09:33:26 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: Robert Elz , Fred Templin , Bob Hinden , IPng Subject: Re: Status of In-Reply-To: <3EDE77F3.3070807@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 4 Jun 2003, Alain Durand wrote: > 100% agreed. Still, we have to pick a default. My point is that I'd > rather like the default case to be that apps that require global > addresses don't have anything special to do to work. Agree here. Another alternative way to proceed might be to leave the scope of local addresses "global". And those sites who wish to change the preferences, could either pick any one of them, or insert a custom entry in the policy label table for the local addresses, causing communication between local-local be preferred except for certain special cases. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 4 23:52:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h556qPTX020559; Wed, 4 Jun 2003 23:52:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h556qOOi020558; Wed, 4 Jun 2003 23:52:24 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h556qLTX020551 for ; Wed, 4 Jun 2003 23:52:21 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h556odNh023279 for ; Wed, 4 Jun 2003 23:50:39 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h556oXLv021872 for ; Wed, 4 Jun 2003 23:50:34 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h556oTB30249; Thu, 5 Jun 2003 09:50:29 +0300 Date: Thu, 5 Jun 2003 09:50:29 +0300 (EEST) From: Pekka Savola To: awhite@arc.corp.mot.com cc: IPng Subject: Re: Status of In-Reply-To: <3EDEB8A8.708DF3DE@motorola.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, 5 Jun 2003, Andrew White wrote: > I prefer the behaviour specified by default address selection - pick the > smallest 'scope' which matches unless the application has a good reason to > do otherwise. > > Stability aside, the 'smallest matching scope' rule only fails for > applications that forward addresses out-of-scope. In this case, either: > > - forward names, so that you get all in-scope options, not just the one that > worked for the forwarder. > > - accept that your application is now delving into the routing space and > code accordingly. That's not the complete picture. Addresses leak. They leak to others using the local scope, but without connectivity. I'd much prefer using globals first, because falling back to globals from first trying locals could take a long time (consider e.g. stupid firewalls who silently drop packets). This should not be an important issue, but I fear in practice, it is.. [...] > In a multi-addressing environment, applications must be ready to try > multiple source-destination address pairs until one succeeds. A source > address selection compliant gethostbyname will return the destinations in > preferred order (taking into account available source addresses). There is > an implementation question on what order the two dimensional destination and > source space should be searched. I think the order is specified: destination first, unless the application specified the source address explicitly. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 5 01:48:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h558m3TX020977; Thu, 5 Jun 2003 01:48:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h558m3ah020976; Thu, 5 Jun 2003 01:48:03 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h558lwTX020969 for ; Thu, 5 Jun 2003 01:47:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h558kGuc026393 for ; Thu, 5 Jun 2003 01:46:16 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h558kA4Z014506 for ; Thu, 5 Jun 2003 01:46:11 -0700 (PDT) Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h558kAoI020655 for ; Thu, 5 Jun 2003 01:46:10 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h558k5S9016306 for ; Thu, 5 Jun 2003 03:46:08 -0500 Received: from motorola.com (aewhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.9/8.12.9) with ESMTP id h558k4e7015954 for ; Thu, 5 Jun 2003 18:46:04 +1000 (EST) Message-ID: <3EDF034B.7D488005@motorola.com> Date: Thu, 05 Jun 2003 18:46:03 +1000 From: Andrew White Reply-To: awhite@arc.corp.mot.com Organization: Motorola Australia Research Centre X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 CC: IPng Subject: Re: Status of References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > That's not the complete picture. Addresses leak. They leak to others > using the local scope, but without connectivity. I'd much prefer using > globals first, because falling back to globals from first trying locals > could take a long time (consider e.g. stupid firewalls who silently drop > packets). > > This should not be an important issue, but I fear in practice, it is.. Agreed. There could be a long timeout on connection if we use an invalid address (local or global) as our first choice, and an out-of-scope local is theoretically guaranteed to be invalid. Does that mean that routers that blackhole local addresses (or filters doing the same thing) SHOULD (or MUST) return 'destination unreachable' messages? I'd previously thought MAY. However, the counter-argument is stability. IF my local network uses local addresses and IF another local network leaks their local addresses and IF these don't get filtered correctly then I get a long timeout. In contrast, IF my local network uses local addresses then it implicitly says 'my global address is less "robust"' (for some definition of robust). If your global address is more robust then WHY are you using locals? Again, what is the scenario where you enable local addressing and then expect applications not to use it for local communication? Quote from a draft I've been fiddling with for the last couple of months... The IPv6 working group has identified three scenarios that would benefit from the existence of a local addressing scheme. o Disconnected networks. o Intermittently connected networks. o Stable local addresses for changing ISPs without disrupting local communication. If we consider a disconnected network to be an intermittently connected network that has not been connected yet, all three resolve to a single scenario: a network that wishes to maintain a stable local address space regardless of the presence or absence of one or more ISPs. Unless I'm missing something obvious, you use a local addressing scheme so that your local connections can operate independently of the global internet. Where is the benefit in making these connections prefer global addressing? > > In a multi-addressing environment, applications must be ready to try > > multiple source-destination address pairs until one succeeds. A source > > address selection compliant gethostbyname will return the destinations in > > preferred order (taking into account available source addresses). There is > > an implementation question on what order the two dimensional destination and > > source space should be searched. > > I think the order is specified: destination first, unless the application > specified the source address explicitly. Checked RFC3484 - source address selection returns exactly one (the "best") source address for a given destination address. This leaves an operational quirk. In general, I want to rank the array in BOTH dimensions. For example, I might prefer local-local to global-global, but I certainly want to try both of them before trying something ugly like global-local. However, if I have three local sources, I might want to try each against the local destination before trying the global destination with a global source. This implies some sort of two-dimensional ranking. It seems the sensible default is for the application to simply make a connection request using the domain name and for the host to rank all source-dest pairs and then iterate in order. The app may wish to specify some timeouts (eg try no more than 3 dest addrs and no more than 3 sources per addr). (Note: this latter problem is orthogonal to the local addressing issue, but is necessary to solve decently if we want more than one address per node). -- Andrew White Andrew.E.White@motorola.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 5 01:49:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h558nuTX020994; Thu, 5 Jun 2003 01:49:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h558nt4Q020993; Thu, 5 Jun 2003 01:49:55 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h558nqTX020986 for ; Thu, 5 Jun 2003 01:49:52 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h558mANh027721 for ; Thu, 5 Jun 2003 01:48:10 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h558m4ep016606 for ; Thu, 5 Jun 2003 02:48:05 -0600 (MDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h558lKKY109370; Thu, 5 Jun 2003 10:47:22 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h558l2Kg178716; Thu, 5 Jun 2003 10:47:02 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40648 from ; Thu, 5 Jun 2003 10:47:00 +0200 Message-Id: <3EDF039C.46AF2AB7@hursley.ibm.com> Date: Thu, 05 Jun 2003 10:47:24 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: Alain Durand , Robert Elz , Fred Templin , Bob Hinden , IPng Subject: Re: Status of References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Wed, 4 Jun 2003, Alain Durand wrote: > > 100% agreed. Still, we have to pick a default. My point is that I'd > > rather like the default case to be that apps that require global > > addresses don't have anything special to do to work. > > Agree here. > > Another alternative way to proceed might be to leave the scope of local > addresses "global". > > And those sites who wish to change the preferences, could either pick any > one of them, or insert a custom entry in the policy label table for the > local addresses, causing communication between local-local be preferred > except for certain special cases. > The problem here is that the notion of scope as a set of embedded circles is simply wrong. Because of VPNs and hosting centers we will have "prongs" of enterprise networks extending into physical sites of other enterprises in an overlapping pattern. There is no simple scoping rule that can describe this, so there is no applicable default in such cases. But default preference = global seems reasonable to me. 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 Jun 5 01:58:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h558wrTX021343; Thu, 5 Jun 2003 01:58:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h558wraE021342; Thu, 5 Jun 2003 01:58:53 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h558woTX021335 for ; Thu, 5 Jun 2003 01:58:50 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h558v8Nh001323 for ; Thu, 5 Jun 2003 01:57:08 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h558v1YU013944 for ; Thu, 5 Jun 2003 02:57:02 -0600 (MDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h558uiKY101138; Thu, 5 Jun 2003 10:56:47 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h558tQ8P233478; Thu, 5 Jun 2003 10:55:27 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54814 from ; Thu, 5 Jun 2003 10:55:26 +0200 Message-Id: <3EDF0596.A7FA190D@hursley.ibm.com> Date: Thu, 05 Jun 2003 10:55:50 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Robert Elz Cc: Bob Hinden , IPng Subject: Re: Status of References: <4.3.2.7.2.20030604072330.02ba46d8@mailhost.iprg.nokia.com> <3EDD3A74.1050603@sun.com> <3EDD3A74.1050603@sun.com> <3EDCE830.50908@iprg.nokia.com> <10987.1054749892@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > > Date: Wed, 04 Jun 2003 07:29:05 -0700 > From: Bob Hinden > Message-ID: <4.3.2.7.2.20030604072330.02ba46d8@mailhost.iprg.nokia.com> > > | I think you are suggesting that the draft be changed to reuse the FEC0::/10 > | space with a resulting 38-bit global ID. This would allow for > | 274,877,906,944 prefixes, or 30 per person in 2050. > > I trust your calculations, so assuming they were all going to be unique, > then yes, 50 years from now people wouldn't be able to have more than 30 > or so non-routable /48's each (oh, such suffering!) > > But of course, they're not going to be unique, and don't have to be, so in > practice, the limit per person would be much much higher (not quite > 274,877,906,944 each, as the user will want to remain distinct from some > others, but perhaps within a few orders of magnitude of that). So, how about stating that: FEC0::/48 is reserved and not to be used. (This is a shot at backwards compatibility for existing usage.) FEC0::/11 is followed by a 37-bit number randomly allocated by the user. (We should recommend a method, and zero is forbidden.) FEE0::/11 is reserved for future use. (Giving us time to work out how a fee-paying (pun) registry might work.) 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 Jun 5 03:33:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h55AX1TX022001; Thu, 5 Jun 2003 03:33:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h55AX1JO022000; Thu, 5 Jun 2003 03:33:01 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h55AWwTX021993 for ; Thu, 5 Jun 2003 03:32:58 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h55AVFNh026018 for ; Thu, 5 Jun 2003 03:31:15 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h55AV8YU000059 for ; Thu, 5 Jun 2003 04:31:09 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h55AUw219192; Thu, 5 Jun 2003 17:30:59 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h55AUti08058; Thu, 5 Jun 2003 17:30:55 +0700 (ICT) From: Robert Elz To: Alain Durand cc: Fred Templin , Pekka Savola , Bob Hinden , IPng Subject: Re: Status of In-Reply-To: <3EDE77F3.3070807@sun.com> References: <3EDE77F3.3070807@sun.com> <3EDD3A74.1050603@sun.com> <3EDCE830.50908@iprg.nokia.com> <9861.1054735730@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jun 2003 17:30:55 +0700 Message-ID: <8158.1054809055@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 04 Jun 2003 15:51:31 -0700 From: Alain Durand Message-ID: <3EDE77F3.3070807@sun.com> | My point is that I'd rather like the default case to be that apps that | require global addresses don't have anything special to do to work. As it happens, the way I do things generally fits with what you'd want I believe, but the way you expressed it isn't the way I would. That is, really, almost no apps "require global addresses" - there are a small handful in that category. On the other hand, it is also true, that there are really only small handful of apps that really want to use local addresses in preference to global, when both would work. The vast majority of apps simply don't give a damn - all that matters is that some address that works now, and is likely to keep working for the next few minutes, be picked. Given that (for some networks) sometimes only the local address will work, and sometimes (for different networks, or destinations) only the global address will work, there isn't really any way that a system can choose one or the other as better, for these apps (most of them) and be correct. It needs to be a network setting (more in RA packets??) My personal preference is that every node should have a global address, always, and that those addresses should always work (for most purposes) so for apps that don't care, in the work I have been doing, global addresses are what always gets used. On the other hand, for apps that do care, there is an API that allows them to get local addresses whenever they work (the API keeps changing as we play with it more and make different demands upon it). This scheme works for me, but won't work for everyone. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 5 03:37:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h55AbuTX022080; Thu, 5 Jun 2003 03:37:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h55AbuiG022077; Thu, 5 Jun 2003 03:37:56 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h55AbrTX022069 for ; Thu, 5 Jun 2003 03:37:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h55AaANh026936 for ; Thu, 5 Jun 2003 03:36:10 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h55Aa3Lv000587 for ; Thu, 5 Jun 2003 03:36:04 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h55AZo223040; Thu, 5 Jun 2003 17:35:51 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h55AZgi08485; Thu, 5 Jun 2003 17:35:43 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: Bob Hinden , IPng Subject: Re: Status of In-Reply-To: <3EDF0596.A7FA190D@hursley.ibm.com> References: <3EDF0596.A7FA190D@hursley.ibm.com> <4.3.2.7.2.20030604072330.02ba46d8@mailhost.iprg.nokia.com> <3EDD3A74.1050603@sun.com> <3EDD3A74.1050603@sun.com> <3EDCE830.50908@iprg.nokia.com> <10987.1054749892@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jun 2003 17:35:42 +0700 Message-ID: <7619.1054809342@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 05 Jun 2003 10:55:50 +0200 From: Brian E Carpenter Message-ID: <3EDF0596.A7FA190D@hursley.ibm.com> | FEC0::/48 is reserved and not to be used. (This is a shot at backwards | compatibility for existing usage.) I'm not sure that we really need that. That is, backwards compatibility with what? On the other hand, making it very clear that "I pick 0" is not choosing a random number would be worthwhile... | FEC0::/11 is followed by a 37-bit number randomly allocated by the user. | (We should recommend a method, and zero is forbidden.) That's OK, 37 bits is at least half as good as 38... | FEE0::/11 is reserved for future use. (Giving us time to work out how | a fee-paying (pun) registry might work.) We should obviously also reserve F1E0::/11 and F0E0::/11 (and then someone just needs to figure out how to write "UM" in hex so we can smell the blood...) kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 5 08:32:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h55FWpTX023229; Thu, 5 Jun 2003 08:32:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h55FWo5u023228; Thu, 5 Jun 2003 08:32:50 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h55FWlTX023221 for ; Thu, 5 Jun 2003 08:32:47 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h55FV4Nh021413 for ; Thu, 5 Jun 2003 08:31:04 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h55FUvYU018491 for ; Thu, 5 Jun 2003 09:30:58 -0600 (MDT) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h55FUJsM045496; Thu, 5 Jun 2003 08:30:19 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h55FUIJo045495; Thu, 5 Jun 2003 08:30:18 -0700 (PDT) (envelope-from jj) Date: Thu, 5 Jun 2003 08:30:18 -0700 From: Shannon -jj Behrens To: Tim Hartrick Cc: Christian Huitema , hinden@iprg.nokia.com, ot@cisco.com, kre@munnari.oz.au, ipng@sunroof.eng.sun.com Subject: Re: Status of Message-ID: <20030605153018.GA45383@alicia.nttmcl.com> References: <000001c32b0e$03cfc370$c67a58c0@citrix.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c32b0e$03cfc370$c67a58c0@citrix.mentat.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Jun 04, 2003 at 07:56:08PM -0700, Tim Hartrick wrote: > > > For what it is worth, I agree with kre as well. > > > > Isn't that cool? We had this discussion before. In the spring of 1997, > > as a matter of fact. And the suggestion then was: > > > > I think of lots of things to call it, but "cool" is not one of them. Perhaps I'm missing something, but I think there's a difference. We're no longer suggesting that the local address should have a scope identifier associated with it, correct? -jj -- Hacker is to software engineer as Climbing Mt. Everest is to building a Denny's there. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 5 15:48:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h55Mm8TX024493; Thu, 5 Jun 2003 15:48:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h55Mm83V024492; Thu, 5 Jun 2003 15:48:08 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h55Mm4TX024485 for ; Thu, 5 Jun 2003 15:48:04 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h55MkLuc023073 for ; Thu, 5 Jun 2003 15:46:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h55MkFYU002574 for ; Thu, 5 Jun 2003 16:46:15 -0600 (MDT) 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 PAA08048; Thu, 5 Jun 2003 15:46:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h55MkDk13206; Thu, 5 Jun 2003 15:46:13 -0700 X-mProtect: <200306052246> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLlt9FG; Thu, 05 Jun 2003 15:46:11 PDT Message-Id: <4.3.2.7.2.20030605154401.0309fe00@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jun 2003 15:45:58 -0700 To: "Christian Huitema" From: Bob Hinden Subject: RE: Status of 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 Christian, >Isn't that cool? We had this discussion before. In the spring of 1997, >as a matter of fact. And the suggestion then was: > > > Date: Tue, 13 May 1997 11:25:42 -0400 > > From: huitema@bellcore.com (Christian Huitema) > > Subject: (IPng 3627) Re: W.G. Last Call on "Advanced Sockets API for In hindsight, we should have listened to you back in 1997. 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 Thu Jun 5 20:26:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h563QCTX025712; Thu, 5 Jun 2003 20:26:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h563QCXx025711; Thu, 5 Jun 2003 20:26:12 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h563Q9TX025704 for ; Thu, 5 Jun 2003 20:26:09 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h563OQuc023156 for ; Thu, 5 Jun 2003 20:24:26 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h563OLLv024683 for ; Thu, 5 Jun 2003 20:24:21 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Status of MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 5 Jun 2003 20:24:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Message-ID: <963621801C6D3E4A9CF454A1972AE8F50671AE@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of Thread-Index: AcMq9cLc6EweYtG/T4yDeKhuzEvY/wA5PYKA From: "Michel Py" To: "Ole Troan" , "Bob Hinden" Cc: "Robert Elz" , "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h563Q9TX025705 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ole Troan wrote: > I agree with kre, stick to fec0::/10. Me too. A scheme with the lower part of it for random and the upper part of it for a fee would work too. Although this would represent only 15 prefixes per person in the long run (that's only 4 million subnet for a family of 4, way to small to design a home network :-) let's keep in mind that these are private addresses and not everyone would need one. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 6 01:30:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h568UtTX027190; Fri, 6 Jun 2003 01:30:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h568UtEF027189; Fri, 6 Jun 2003 01:30:55 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h568UpTX027182 for ; Fri, 6 Jun 2003 01:30:51 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h568T8Nh012580 for ; Fri, 6 Jun 2003 01:29:08 -0700 (PDT) Received: from bowl.fysh.org ([195.167.170.152]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h568T2ep021974 for ; Fri, 6 Jun 2003 02:29:03 -0600 (MDT) Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 19OCak-0001Xq-00; Fri, 06 Jun 2003 09:28:54 +0100 Date: Fri, 6 Jun 2003 09:28:54 +0100 To: Michel Py Cc: Ole Troan , Bob Hinden , Robert Elz , IPng Subject: Re: Status of Message-ID: <20030606082854.GA4282@fysh.org> References: <963621801C6D3E4A9CF454A1972AE8F50671AE@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F50671AE@server2000.arneill-py.sacramento.ca.us> User-Agent: Mutt/1.3.28i From: Zefram Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I agree with kre, stick to fec0::/10. So many people have spoken in favour of that that I think I need to state the contrary position. Having uniquish IDs under fec0::/10 may well be a useful technique, but it's quite different from the suggestion that we started with, which was to have persistent unique prefixes in globally-scoped address space. For me, a major part of the appeal of fc00::/7 addresses is that they don't come with any non-global-scope semantics attached, and so they'll play nicely (i.e., interact in the obvious way) with routable global addresses. People have started to suggest attaching scoping semantics to fc00::/7 adddresses, which is what led to fc00::/10. I think this was a mistake. Leave fc00::/7 without special semantics -- that's the point of it. People that want scoping: if you want fc00::/10, you know where to get it. -zefram -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 01:46:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h568kxTX027403; Fri, 6 Jun 2003 01:46:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h568kxwt027402; Fri, 6 Jun 2003 01:46:59 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h568ktTX027395 for ; Fri, 6 Jun 2003 01:46:55 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h568jCNh016955 for ; Fri, 6 Jun 2003 01:45:12 -0700 (PDT) Received: from bowl.fysh.org ([195.167.170.152]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h568j6ep028988 for ; Fri, 6 Jun 2003 02:45:07 -0600 (MDT) Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 19OCqP-0001rH-00; Fri, 06 Jun 2003 09:45:05 +0100 Date: Fri, 6 Jun 2003 09:45:05 +0100 To: Zefram Cc: Michel Py , Ole Troan , Bob Hinden , Robert Elz , IPng Subject: Re: Status of Message-ID: <20030606084505.GB4282@fysh.org> References: <963621801C6D3E4A9CF454A1972AE8F50671AE@server2000.arneill-py.sacramento.ca.us> <20030606082854.GA4282@fysh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030606082854.GA4282@fysh.org> User-Agent: Mutt/1.3.28i From: Zefram Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Zefram wrote: >People have started to suggest attaching scoping semantics to fc00::/7 >adddresses, which is what led to fc00::/10. I think this was a mistake. >Leave fc00::/7 without special semantics -- that's the point of it. >People that want scoping: if you want fc00::/10, you know where to get it. Erk... "fc00::/10" should be "fec0::/10" in both places, of course. -zefram -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 07:53:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56ErCTX028751; Fri, 6 Jun 2003 07:53:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h56ErCqK028750; Fri, 6 Jun 2003 07:53:12 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56Er8TX028743 for ; Fri, 6 Jun 2003 07:53:08 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h56EpOuc009831 for ; Fri, 6 Jun 2003 07:51:24 -0700 (PDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h56EpIep010672 for ; Fri, 6 Jun 2003 08:51:19 -0600 (MDT) Received: from edi-view2.cisco.com (edi-view2.cisco.com [144.254.112.71]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56EpFms012101 for ; Fri, 6 Jun 2003 07:51:16 -0700 (PDT) Received: (dfawcus@localhost) by edi-view2.cisco.com (8.11.2/CISCO.WS.1.2) id h56EpEf12972 for ipng@sunroof.eng.sun.com; Fri, 6 Jun 2003 15:51:14 +0100 (BST) Date: Fri, 6 Jun 2003 15:51:14 +0100 From: Derek Fawcus To: IPng Subject: Re: Status of Message-ID: <20030606155114.B29379@edi-view2.cisco.com> Mail-Followup-To: IPng References: <3EDD3A74.1050603@sun.com> <3EDD3A74.1050603@sun.com> <3EDCE830.50908@iprg.nokia.com> <4.3.2.7.2.20030604072330.02ba46d8@mailhost.iprg.nokia.com> <7t5y90hcs80.fsf@mrwint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <7t5y90hcs80.fsf@mrwint.cisco.com>; from ot@cisco.com on Thu, Jun 05, 2003 at 12:56:15AM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Jun 05, 2003 at 12:56:15AM +0100, Ole Troan wrote: > I agree with kre, stick to fec0::/10. I disagree. Doing this would constitute a _redifinition_ of the current SL behaviour, not any form of deprecation. If people are desperate to use a /10 range, there's always fe00:/10 and fe40::/10 available. Mind I'd rather not use them since there could be some advantage in implementation terms if all of fe00::/8 was known to reserved for 'weird' i.e. scoped addresses. At least I'd prefer not to have the registry based numbers within the fe00::/8 range. DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 6 11:12:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56ICpTX029562; Fri, 6 Jun 2003 11:12:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h56ICpVw029561; Fri, 6 Jun 2003 11:12:51 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56ICmTX029554 for ; Fri, 6 Jun 2003 11:12:48 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h56IB4uc021995 for ; Fri, 6 Jun 2003 11:11:04 -0700 (PDT) Received: from fuchsia.home (ip23.coe.tnet.co.th [203.146.155.23]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h56IAbht006195 for ; Fri, 6 Jun 2003 12:10:55 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id h56I8Jlh001238; Sat, 7 Jun 2003 01:08:40 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h569Ccr04403; Fri, 6 Jun 2003 16:12:38 +0700 (ICT) From: Robert Elz To: Zefram cc: Bob Hinden , IPng Subject: Re: Status of In-Reply-To: <20030606082854.GA4282@fysh.org> References: <20030606082854.GA4282@fysh.org> <963621801C6D3E4A9CF454A1972AE8F50671AE@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Jun 2003 16:12:38 +0700 Message-ID: <12460.1054890758@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 6 Jun 2003 09:28:54 +0100 From: Zefram Message-ID: <20030606082854.GA4282@fysh.org> | but it's quite different from the suggestion | that we started with, which was to have persistent unique prefixes in | globally-scoped address space. That may have been what was wanted, but despite the attempts to produce that, it wasn't what appeared. We haven't yet found any way to make unique prefixes that works. (There are ways that would work if everyone - *everyone* - would agree to play by the rules, but nothing more than that). | For me, a major part of the appeal of | fc00::/7 addresses is that they don't come with any non-global-scope | semantics attached, They do, you're just ignoring them. | and so they'll play nicely (i.e., interact in the | obvious way) with routable global addresses. They won't (always). For most purposes original SL addresses played nicely as well - where that couldn't be guaranteed, nor can it with the new ones. | People have started to suggest attaching scoping semantics to fc00::/7 | adddresses, which is what led to fec0::/10. [I applied the correction from your later mail, here & below]. No, it wasn't. What led to that was that we already have that address space defined, deployed, and in use. We can (and always could) change the semantics a little to get rid of "multi-site-nodes" (and hence the need for explicit scope identifiers in the addresses) - which is what is effectively being done here, without affecting almost anything else. Implementations that already exist and know about scoping can easily ignore it by assigning everything the same scope. Implementations that allow fec0::/10 now, but treat it just like global, just keep on doing that (at the stack level). A few applications need to care, and do so whatever we do here. | People that want scoping: if you want fec0::/10, you know where to get it. It isn't that anyone specifically wants scoping - it is that we recognise that it is impossible to avoid. These addresses have limited scope of applicability, and can only be expected to remain unique inside that scope (they're better than the original SL in that it is more likely that scopes can be combined without needing to have addressing altered). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 6 11:26:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56IQWTX029765; Fri, 6 Jun 2003 11:26:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h56IQW7L029764; Fri, 6 Jun 2003 11:26:32 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56IQTTX029757 for ; Fri, 6 Jun 2003 11:26:29 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h56IOiuc027339 for ; Fri, 6 Jun 2003 11:24:45 -0700 (PDT) Received: from bowl.fysh.org ([195.167.170.152]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h56IOd4Z009964 for ; Fri, 6 Jun 2003 11:24:39 -0700 (PDT) Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 19OLtG-00065c-00 for ; Fri, 06 Jun 2003 19:24:38 +0100 Date: Fri, 6 Jun 2003 19:24:38 +0100 To: ipng@sunroof.eng.sun.com Subject: another view of fc00::/7 Message-ID: <20030606182438.GA17751@fysh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Zefram Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We seem to have a situation of "globally-scoped, persistent, routable: pick any two". 2000::/3 is globally-scoped and routable. fec0::/10 is persistent and routable (within its scope). To allow people the freedom to "pick any two", we need a way to generate addresses that are globally-scoped and persistent, without necessarily being (globally) routable. That's what fc00::/7 would achieve. I note that in the architectural traditions of the Internet we're not very good at handling addresses that are not both globally-scoped and routable. That's why we're having kittens trying to work out how to deal with fec0::/10 and fc00::/7 addresses. -zefram -- Andrew Main (Zefram) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 11:52:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56IqfTX000093; Fri, 6 Jun 2003 11:52:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h56IqfnX000092; Fri, 6 Jun 2003 11:52:41 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56IqbTX000085 for ; Fri, 6 Jun 2003 11:52:37 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h56IorNh023338 for ; Fri, 6 Jun 2003 11:50:53 -0700 (PDT) Received: from fuchsia.home (ip23.coe.tnet.co.th [203.146.155.23]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h56IoIht020560 for ; Fri, 6 Jun 2003 12:50:36 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id h56Im9lf002192; Sat, 7 Jun 2003 01:48:10 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h56IlIf11955; Sat, 7 Jun 2003 01:47:23 +0700 (ICT) From: Robert Elz To: Derek Fawcus cc: IPng Subject: Re: Status of In-Reply-To: <20030606155114.B29379@edi-view2.cisco.com> References: <20030606155114.B29379@edi-view2.cisco.com> <3EDD3A74.1050603@sun.com> <3EDD3A74.1050603@sun.com> <3EDCE830.50908@iprg.nokia.com> <4.3.2.7.2.20030604072330.02ba46d8@mailhost.iprg.nokia.com> <7t5y90hcs80.fsf@mrwint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Jun 2003 01:47:18 +0700 Message-ID: <22734.1054925238@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 6 Jun 2003 15:51:14 +0100 From: Derek Fawcus Message-ID: <20030606155114.B29379@edi-view2.cisco.com> | Doing this would constitute a _redifinition_ of the current | SL behaviour, No, it doesn't. SL, as currently defined, allows for any random bits in the "upper 38". Nowhere does it define what a "site" should be, or what a site border should be. It is easy to treat the entire internet as a single site (no borders) and remain 100% compatible with the SL definitions. That's effectively what is being done. | | If people are desperate to use a /10 range, there's always fe00:/10 and | fe40::/10 available. It isn't the size of the range, but that it is reusing address space that has already been designated. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 6 12:14:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56JEjTX000407; Fri, 6 Jun 2003 12:14:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h56JEj37000406; Fri, 6 Jun 2003 12:14:45 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56JEfTX000399 for ; Fri, 6 Jun 2003 12:14:41 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h56JCvNh000896 for ; Fri, 6 Jun 2003 12:12:57 -0700 (PDT) Received: from fuchsia.home (ip23.coe.tnet.co.th [203.146.155.23]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h56JCnLv022056 for ; Fri, 6 Jun 2003 12:12:51 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id h56JCUlf002585; Sat, 7 Jun 2003 02:12:30 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h56JBMf20685; Sat, 7 Jun 2003 02:11:22 +0700 (ICT) From: Robert Elz To: Zefram cc: ipng@sunroof.eng.sun.com Subject: Re: another view of fc00::/7 In-Reply-To: <20030606182438.GA17751@fysh.org> References: <20030606182438.GA17751@fysh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Jun 2003 02:11:22 +0700 Message-ID: <24654.1054926682@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 6 Jun 2003 19:24:38 +0100 From: Zefram Message-ID: <20030606182438.GA17751@fysh.org> | we need a way to generate addresses that are | globally-scoped and persistent, without necessarily being (globally) | routable. That's what fc00::/7 would achieve. No, you mean that's what you'd like to put in that prefix. The number, by itself, can't achieve anything. What we're lacking is any way to make a globally-scoped non-routable address. That is, what gives us global scoping in 2000::/3 (and most other unallocated spaces, one presumes) is the routability - the two go hand in hand. The routing tables define the one unique user of a globally scoped address. Take away the routing tables, and there's no longer any universal motivation to maintain uniqueness, and that is what defines the scope of the addresses - they end up being locally scoped within whatever (vague) domain they happen to be unique within. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 6 12:48:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56Jm6TX000713; Fri, 6 Jun 2003 12:48:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h56Jm69E000712; Fri, 6 Jun 2003 12:48:06 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56Jm3TX000704 for ; Fri, 6 Jun 2003 12:48:03 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h56JkJNh016284 for ; Fri, 6 Jun 2003 12:46:19 -0700 (PDT) Received: from bowl.fysh.org ([195.167.170.152]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h56JkD4Z019979 for ; Fri, 6 Jun 2003 12:46:13 -0700 (PDT) Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 19ONAC-0000L6-00 for ; Fri, 06 Jun 2003 20:46:12 +0100 Date: Fri, 6 Jun 2003 20:46:12 +0100 To: ipng@sunroof.eng.sun.com Subject: Re: another view of fc00::/7 Message-ID: <20030606194612.GA887@fysh.org> References: <20030606182438.GA17751@fysh.org> <24654.1054926682@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24654.1054926682@munnari.OZ.AU> User-Agent: Mutt/1.3.28i From: Zefram Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > What we're lacking is any way to make >a globally-scoped non-routable address. That is, what gives us global >scoping in 2000::/3 (and most other unallocated spaces, one presumes) is >the routability - the two go hand in hand. Here we're talking about two different things due to the two meanings of "scope". You're using the definition where scope = domain of routability. I should perhaps have clarified, I was using the meaning scope = domain of meaningfulness. Let's not rehash the debate about whether these are really distinct in {theory,practice}. -zefram -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 15:48:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56MmoTX001347; Fri, 6 Jun 2003 15:48:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h56MmnMC001346; Fri, 6 Jun 2003 15:48:49 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h56MmjTX001339 for ; Fri, 6 Jun 2003 15:48:46 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h56Ml1Nh025463 for ; Fri, 6 Jun 2003 15:47:01 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h56Mkuht002735 for ; Fri, 6 Jun 2003 16:46:56 -0600 (MDT) 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 PAA07142 for ; Fri, 6 Jun 2003 15:46:52 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h56MkpN14965; Fri, 6 Jun 2003 15:46:51 -0700 X-mProtect: <200306062246> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQut9zi; Fri, 06 Jun 2003 15:46:49 PDT Message-Id: <4.3.2.7.2.20030606142437.02aefb28@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 15:46:38 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: FEC0::/10 vs. FC00::/7 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I still have a small preference preference for using FC00::/7 for the globally unique local addresses due to the larger global ID, instead of reusing the FEC0::/10 prefix. But either would work. I think one element in the choice comes down to deciding if we want the default scope of these addresses to be global. Currently the FEC0::/10 prefix is called out in RFC3513 for special handling and everything else not listed (including FC00::/7) is to be treated as global unicast. If we want these addresses to be handled differently from global unicast (like giving them preference over global unicast), then using the FEC0::/10 prefix is a good choice. If we want them to be treated the same as other global unicast than using FC00::/7 would be preferable. Note that RFC3515 does allow for other specifications to define special handling for other prefixes, but as Alain Durand pointed out on the list doing so does put some additional burden on existing implementations. Other opinions? 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 Sat Jun 7 02:31:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h579VJTX002359; Sat, 7 Jun 2003 02:31:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h579VICX002358; Sat, 7 Jun 2003 02:31:18 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h579VFTX002351 for ; Sat, 7 Jun 2003 02:31:15 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h579TUNh020079 for ; Sat, 7 Jun 2003 02:29:30 -0700 (PDT) Received: from mta0.huawei.com ([61.144.161.2]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h579TNYU003006 for ; Sat, 7 Jun 2003 03:29:24 -0600 (MDT) Received: from c092522k (mta0.huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HG3007TMUAC9H@mta0.huawei.com> for ipng@sunroof.eng.sun.com; Sat, 07 Jun 2003 17:27:49 +0800 (CST) Date: Sat, 07 Jun 2003 17:28:05 +0800 From: changlimin Subject: Who can tell me what's meaning for the address "ff02::2:7026:ee83"? Thanks. To: ipng@sunroof.eng.sun.com Message-id: <001101c32cd7$24a9e290$0101a8c0@c092522k> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: multipart/alternative; boundary="Boundary_(ID_/DL0nc/kCT9D0Tv53wCkQw)" X-Priority: 3 X-MSMail-priority: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_/DL0nc/kCT9D0Tv53wCkQw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT --Boundary_(ID_/DL0nc/kCT9D0Tv53wCkQw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
 
--Boundary_(ID_/DL0nc/kCT9D0Tv53wCkQw)-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 03:02:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h57A2TTX002596; Sat, 7 Jun 2003 03:02:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h57A2T85002595; Sat, 7 Jun 2003 03:02:29 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h57A2PTX002588 for ; Sat, 7 Jun 2003 03:02:25 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h57A0duc023734 for ; Sat, 7 Jun 2003 03:00:39 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h57A0Xht025168 for ; Sat, 7 Jun 2003 04:00:33 -0600 (MDT) Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h57A0XY1011151 for ; Sat, 7 Jun 2003 03:00:33 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h57A0VeN018187 for ; Sat, 7 Jun 2003 05:00:31 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Sat, 7 Jun 2003 06:00:12 -0400 Message-ID: From: "Manral, Vishwas" To: "'changlimin'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: Who can tell me what's meaning for the address "ff02::2:7026: ee83"? Thanks. Date: Sat, 7 Jun 2003 06:01:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32CDB.D509B8F0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C32CDB.D509B8F0 Content-Type: text/plain; charset="GB2312" Hi Chamling, The address stands for a permanently assigned link-local scope multicast address. Maybe you shoud look at RFC3513. Thanks, Vishwas -----Original Message----- From: changlimin [mailto:changlimin@huawei.com] Sent: Saturday, June 07, 2003 14:58 To: ipng@sunroof.eng.sun.com Subject: Who can tell me what's meaning for the address "ff02::2:7026:ee83"? Thanks. ------_=_NextPart_001_01C32CDB.D509B8F0 Content-Type: text/html; charset="GB2312"
Hi Chamling,
 
The address stands for a permanently assigned link-local scope multicast address.
 
Maybe you shoud look at RFC3513.
 
Thanks,
Vishwas 
-----Original Message-----
From: changlimin [mailto:changlimin@huawei.com]
Sent: Saturday, June 07, 2003 14:58
To: ipng@sunroof.eng.sun.com
Subject: Who can tell me what's meaning for the address "ff02::2:7026:ee83"? Thanks.

 
------_=_NextPart_001_01C32CDB.D509B8F0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 08:08:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h57F8nTX003362; Sat, 7 Jun 2003 08:08:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h57F8nV0003361; Sat, 7 Jun 2003 08:08:49 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h57F8jTX003354 for ; Sat, 7 Jun 2003 08:08:45 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h57F6xNh024725 for ; Sat, 7 Jun 2003 08:06:59 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h57F6sep024212 for ; Sat, 7 Jun 2003 09:06:54 -0600 (MDT) Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA25131; Sat, 7 Jun 2003 08:06:29 -0700 (PDT) Message-Id: <5.1.0.14.2.20030607105751.047bf388@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 07 Jun 2003 11:02:38 -0400 To: Bob Hinden From: Margaret Wasserman Subject: Re: FEC0::/10 vs. FC00::/7 Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4.3.2.7.2.20030606142437.02aefb28@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:46 PM 6/6/2003 -0700, Bob Hinden wrote: >I still have a small preference preference for using FC00::/7 for the >globally unique local addresses due to the larger global ID, instead of >reusing the FEC0::/10 prefix. But either would work. The problem with using FECO::/10 for these addresses is that there are implementations that include special semantics to handle the ambiguity of FECO::/10 addresses, such as requiring a Zone ID to disambiguate FECO::/10 addresses, setting up separate routing tables for separate FECO::/10 zones, etc. In Bob's proposal, addresses are globally unique (although they may not be globally routed), so we don't need special semantics to handle the ambiguity. 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 Jun 7 09:20:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h57GKmTX003643; Sat, 7 Jun 2003 09:20:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h57GKlvQ003642; Sat, 7 Jun 2003 09:20:47 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h57GKiTX003635 for ; Sat, 7 Jun 2003 09:20:44 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h57GIwuc002059 for ; Sat, 7 Jun 2003 09:18:58 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h57GIrht002537 for ; Sat, 7 Jun 2003 10:18:53 -0600 (MDT) Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA14213 for ; Sat, 7 Jun 2003 09:18:30 -0700 (PDT) Message-Id: <5.1.0.14.2.20030607120915.0471cac8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 07 Jun 2003 12:14:40 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Re: FEC0::/10 vs. FC00::/7 In-Reply-To: <5.1.0.14.2.20030607105751.047bf388@mail.windriver.com> References: <4.3.2.7.2.20030606142437.02aefb28@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 Using myself as the example... Does anyone else find it sub-optimal that we are spending so much time arguing about what address bits should be used for local addressing when we have yet to gain consensus on: - The requirements for local addressing? - The best technical mechanism(s) to meet those requirements? - Whether we need local addressing at all? Let's figure out what we really need, and _then_ argue about the specifics of where to put the address space. Did anyone want to comment on Tony's requirements document and/or propose an alternative set of requirements? Margaret At 11:02 AM 6/7/2003 -0400, Margaret Wasserman wrote: >At 03:46 PM 6/6/2003 -0700, Bob Hinden wrote: >>I still have a small preference preference for using FC00::/7 for the >>globally unique local addresses due to the larger global ID, instead of >>reusing the FEC0::/10 prefix. But either would work. > >The problem with using FECO::/10 for these addresses is that there >are implementations that include special semantics to handle >the ambiguity of FECO::/10 addresses, such as requiring a Zone ID >to disambiguate FECO::/10 addresses, setting up separate routing >tables for separate FECO::/10 zones, etc. > >In Bob's proposal, addresses are globally unique (although >they may not be globally routed), so we don't need special >semantics to handle the ambiguity. > >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 Jun 7 10:03:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h57H37TX003880; Sat, 7 Jun 2003 10:03:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h57H37vL003879; Sat, 7 Jun 2003 10:03:07 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h57H34TX003872 for ; Sat, 7 Jun 2003 10:03:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h57H1Iuc014703 for ; Sat, 7 Jun 2003 10:01:18 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h57H1DLv014368 for ; Sat, 7 Jun 2003 10:01:13 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: another view of fc00::/7 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Sat, 7 Jun 2003 10:01:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: another view of fc00::/7 Thread-Index: AcMsZNrv0qAmKF8SSCO6e62LEWDeBQAsDRBA From: "Michel Py" To: "Zefram" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h57H34TX003873 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Zefram, >> Robert Elz wrote: >> What we're lacking is any way to make a globally-scoped >> non-routable address. That is, what gives us global >> scoping in 2000::/3 (and most other unallocated spaces, >> one presumes) is the routability - the two go hand in >> hand. > Zefram wrote: > Here we're talking about two different things due to the > two meanings of "scope". You're using the definition where > scope = domain of routability. I should perhaps have > clarified, I was using the meaning scope = domain of > meaningfulness. Let's not rehash the debate about whether > these are really distinct in {theory,practice}. You just can't have two definitions and use one or the other depending on convenience. Although it is true that in theory scope of meaningfulness is not the same as scope of routability, unless you have a proposal to make this happen they're the same for all practical purposes. So I fully agree with kre when he says that what we're lacking is any way to make a globally-scoped non-routable address. I have said in the past that the only way we can "guarantee" that unique addresses won't be transformed into PI is scope. In theory this is not true as one might invent a scopeless mechanism to achieve this, but without seing any signs or ideas about one it remains true for all practical means. Any attempt to remove ambiguity in private addresses that have a global scope will be perverted into wild unaggregated PI which is not acceptable. 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 Jun 7 12:47:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h57JlMTX004326; Sat, 7 Jun 2003 12:47:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h57JlMTi004325; Sat, 7 Jun 2003 12:47:22 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h57JlITX004318 for ; Sat, 7 Jun 2003 12:47:19 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h57JjSuc012611 for ; Sat, 7 Jun 2003 12:45:29 -0700 (PDT) Received: from fuchsia.home (ip25.coe.tnet.co.th [203.146.155.25]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h57JjKep027491 for ; Sat, 7 Jun 2003 13:45:22 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h57Jiv37010671; Sun, 8 Jun 2003 02:44:58 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h57JcuU21195; Sun, 8 Jun 2003 02:39:00 +0700 (ICT) From: Robert Elz To: Margaret Wasserman cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: FEC0::/10 vs. FC00::/7 In-Reply-To: <5.1.0.14.2.20030607105751.047bf388@mail.windriver.com> References: <5.1.0.14.2.20030607105751.047bf388@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Jun 2003 02:38:56 +0700 Message-ID: <18198.1055014736@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 07 Jun 2003 11:02:38 -0400 From: Margaret Wasserman Message-ID: <5.1.0.14.2.20030607105751.047bf388@mail.windriver.com> | The problem with using FECO::/10 for these addresses is that there | are implementations that include special semantics to handle | the ambiguity of FECO::/10 addresses, such as requiring a Zone ID | to disambiguate FECO::/10 addresses, setting up separate routing | tables for separate FECO::/10 zones, etc. All that is OK, there's no implementation that I know of that requires that SL addresses exist in multiple scopes. An implementation as you describe it will work just fine, making use only of one scope for all of these addresses, until perhaps some later version of the system stops using the scope identifiers altogether. Nothing is going to break. | In Bob's proposal, addresses are globally unique Once again, no, they're not. The difference between them and the SL that we have had is that we are going to ignore the non-uniqueness, rather than explicitly handle it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 8 06:25:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h58DPPTX006256; Sun, 8 Jun 2003 06:25:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h58DPPIp006255; Sun, 8 Jun 2003 06:25:25 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h58DPMTX006248 for ; Sun, 8 Jun 2003 06:25:22 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h58DNaNh003595 for ; Sun, 8 Jun 2003 06:23:37 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h58DNUep019428 for ; Sun, 8 Jun 2003 07:23:31 -0600 (MDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h58DNNsn076008 for ; Sun, 8 Jun 2003 15:23:23 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h58DNNh7278240 for ; Sun, 8 Jun 2003 15:23:23 +0200 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44042 from ; Sun, 8 Jun 2003 15:23:18 +0200 Message-Id: <3EE324AF.8088F380@hursley.ibm.com> Date: Sun, 08 Jun 2003 13:57:35 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: another view of fc00::/7 References: <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: ... > > Any attempt to remove ambiguity in private addresses that have a global > scope will be perverted into wild unaggregated PI which is not > acceptable. I don't think so, as far as the DFZ goes. What *will* happen, whatever we do, is exactly what happens today - zillions of VPNs and private static routes for inter-enterprise connections, that are quite independent of the public routing tables summarized in the DFZ. By removing ambiguity, we get rid of a lot of complexity in these private arrangements, and get rid of many situations where NAT is the only possible solution. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 8 06:30:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h58DU4TX006294; Sun, 8 Jun 2003 06:30:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h58DU4wq006291; Sun, 8 Jun 2003 06:30:04 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h58DTwTX006276 for ; Sun, 8 Jun 2003 06:29:58 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h58DSCNh004167 for ; Sun, 8 Jun 2003 06:28:13 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h58DS6lb021136 for ; Sun, 8 Jun 2003 07:28:07 -0600 (MDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h58DRxIe030324 for ; Sun, 8 Jun 2003 15:27:59 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h58DS0h7186836 for ; Sun, 8 Jun 2003 15:28:00 +0200 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44098 from ; Sun, 8 Jun 2003 15:27:57 +0200 Message-Id: <3EE324AF.8088F380@hursley.ibm.com> Date: Sun, 08 Jun 2003 13:57:35 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: another view of fc00::/7 References: <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: ... > > Any attempt to remove ambiguity in private addresses that have a global > scope will be perverted into wild unaggregated PI which is not > acceptable. I don't think so, as far as the DFZ goes. What *will* happen, whatever we do, is exactly what happens today - zillions of VPNs and private static routes for inter-enterprise connections, that are quite independent of the public routing tables summarized in the DFZ. By removing ambiguity, we get rid of a lot of complexity in these private arrangements, and get rid of many situations where NAT is the only possible solution. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 8 06:30:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h58DU6TX006301; Sun, 8 Jun 2003 06:30:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h58DU60b006299; Sun, 8 Jun 2003 06:30:06 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h58DTxTX006283 for ; Sun, 8 Jun 2003 06:29:59 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h58DSENh004169 for ; Sun, 8 Jun 2003 06:28:14 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h58DS7YU001110 for ; Sun, 8 Jun 2003 07:28:08 -0600 (MDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h58DS5sn087818 for ; Sun, 8 Jun 2003 15:28:05 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h58DS6DT088400 for ; Sun, 8 Jun 2003 15:28:06 +0200 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA51312 from ; Sun, 8 Jun 2003 15:28:03 +0200 Message-Id: <3EE32596.D4281624@hursley.ibm.com> Date: Sun, 08 Jun 2003 14:01:26 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: FEC0::/10 vs. FC00::/7 References: <5.1.0.14.2.20030607105751.047bf388@mail.windriver.com> <18198.1055014736@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > > Date: Sat, 07 Jun 2003 11:02:38 -0400 > From: Margaret Wasserman > Message-ID: <5.1.0.14.2.20030607105751.047bf388@mail.windriver.com> > > | The problem with using FECO::/10 for these addresses is that there > | are implementations that include special semantics to handle > | the ambiguity of FECO::/10 addresses, such as requiring a Zone ID > | to disambiguate FECO::/10 addresses, setting up separate routing > | tables for separate FECO::/10 zones, etc. > > All that is OK, there's no implementation that I know of that requires > that SL addresses exist in multiple scopes. An implementation as you > describe it will work just fine, making use only of one scope for all > of these addresses, until perhaps some later version of the system > stops using the scope identifiers altogether. > > Nothing is going to break. > > | In Bob's proposal, addresses are globally unique > > Once again, no, they're not. The difference between them and the SL > that we have had is that we are going to ignore the non-uniqueness, > rather than explicitly handle it. To be more precise, we are going to define them in a way that makes them extremely likely to be unique, and then treat them as if they are mathematically unique. To me, that's good enough. I don't mind too much which prefix we use. A clean separation from FEC0 might be safer. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 8 06:30:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h58DUGTX006313; Sun, 8 Jun 2003 06:30:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h58DUGDm006312; Sun, 8 Jun 2003 06:30:16 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h58DU6TX006300 for ; Sun, 8 Jun 2003 06:30:06 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h58DSKNh004183 for ; Sun, 8 Jun 2003 06:28:21 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h58DSEht012684 for ; Sun, 8 Jun 2003 07:28:15 -0600 (MDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h58DSCbJ122964 for ; Sun, 8 Jun 2003 15:28:13 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h58DSCh7268400 for ; Sun, 8 Jun 2003 15:28:12 +0200 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA51320 from ; Sun, 8 Jun 2003 15:28:09 +0200 Message-Id: <3EE3268F.E8D88149@hursley.ibm.com> Date: Sun, 08 Jun 2003 14:05:35 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: FEC0::/10 vs. FC00::/7 References: <4.3.2.7.2.20030606142437.02aefb28@mailhost.iprg.nokia.com> <5.1.0.14.2.20030607120915.0471cac8@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: > > Using myself as the example... > > Does anyone else find it sub-optimal that we are spending so > much time arguing about what address bits should be used for > local addressing when we have yet to gain consensus on: > > - The requirements for local addressing? > - The best technical mechanism(s) to meet those > requirements? > - Whether we need local addressing at all? I maintain that it is 100% clear that we need limited-scope addressing, and since we will never have a precise definition of a "site", we'd better not waste our time trying to define "site local" precisely. > > Let's figure out what we really need, and _then_ argue about > the specifics of where to put the address space. > > Did anyone want to comment on Tony's requirements document > and/or propose an alternative set of requirements? I think we should take that draft as good enough, and discuss Bob's proposal as a solution to those requirements. Brain > > Margaret > > At 11:02 AM 6/7/2003 -0400, Margaret Wasserman wrote: > >At 03:46 PM 6/6/2003 -0700, Bob Hinden wrote: > >>I still have a small preference preference for using FC00::/7 for the > >>globally unique local addresses due to the larger global ID, instead of > >>reusing the FEC0::/10 prefix. But either would work. > > > >The problem with using FECO::/10 for these addresses is that there > >are implementations that include special semantics to handle > >the ambiguity of FECO::/10 addresses, such as requiring a Zone ID > >to disambiguate FECO::/10 addresses, setting up separate routing > >tables for separate FECO::/10 zones, etc. > > > >In Bob's proposal, addresses are globally unique (although > >they may not be globally routed), so we don't need special > >semantics to handle the ambiguity. > > > >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 Jun 8 11:23:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h58INsTX007681; Sun, 8 Jun 2003 11:23:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h58INsVJ007680; Sun, 8 Jun 2003 11:23:54 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h58INpTX007673 for ; Sun, 8 Jun 2003 11:23:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h58IM5Nh021983 for ; Sun, 8 Jun 2003 11:22:05 -0700 (PDT) Received: from fuchsia.home (ip29.coe.tnet.co.th [203.146.155.29]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h58ILrLv008634 for ; Sun, 8 Jun 2003 11:21:55 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h58ILQ37012575; Mon, 9 Jun 2003 01:21:27 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h58ID7E18167; Mon, 9 Jun 2003 01:13:09 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: another view of fc00::/7 In-Reply-To: <3EE324AF.8088F380@hursley.ibm.com> References: <3EE324AF.8088F380@hursley.ibm.com> <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Jun 2003 01:13:07 +0700 Message-ID: <12722.1055095987@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 08 Jun 2003 13:57:35 +0200 From: Brian E Carpenter Message-ID: <3EE324AF.8088F380@hursley.ibm.com> | I don't think so, as far as the DFZ goes. What *will* happen, whatever | we do, is exactly what happens today - zillions of VPNs and private | static routes for inter-enterprise connections, that are quite | independent of the public routing tables summarized in the DFZ. Yes, for those who want to use non-routable addresses for this purpose, having a means by which conflicts can be avoided would be a nice advantage. However, someone needs to explain to me why an IPv6 VPN would want to use non-routable addresses particularly? Why not just use the global addresses that the sites already have. In the IPv4 world, there's a simple answer - the sites are using 1918 addresses (frequently) internally, and linking, at least parts of, their internal nets is the aim. So, their 1918 addresses are what they want to exchange - which works iff there are no allocation conflicts (which happens only by chance). But in IPv6, everyone is going to have global addresses, why can't they just be used for VPNs? If the answer is "because we use 1918 addresses in IPv4" then I think we have some education to do. If the answer is "we want address stability in our group, even if some of the members have to change their routable prefixes", then that's fine, but for this, wouldn't the right answer be to simply create a new prefix for the VPN, and use that one? That is in this new address space that's being created, the organisations that are creating a VPN pick one prefix that is not in use by any of them (with 2^38 or more prefixes, minimum, to choose from, that can't be hard) and assign that to all nodes that are participating in the VPN (allocating subnets from it to the organisations). If things are done that way, then it is no longer even relevant that more than one of the organisations happens to have randomly selected the same prefix - and there is then no longer any requirement that there be any kind of (pre-existing) uniqueness for this particular usage. Brian also said (in a different message): | To be more precise, we are going to define them in a way that makes them | extremely likely to be unique, and then treat them as if they are | mathematically unique. To me, that's good enough. It would be, but that's the very thing I don't think we should be doing. If we treat them as if they're unique, someone will forget that they're not, and start doing something which actually assumes the uniqueness. Unless we can demonstrate that they are, and must be, unique (to work, or be useful) we really have to make it very very plain that they are not unique. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 8 15:19:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h58MJ7TX008187; Sun, 8 Jun 2003 15:19:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h58MJ7K8008186; Sun, 8 Jun 2003 15:19:07 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h58MJ4TX008179 for ; Sun, 8 Jun 2003 15:19:04 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h58MHINh006293 for ; Sun, 8 Jun 2003 15:17:18 -0700 (PDT) Received: from mail.internetbrasil.net (mail.internetbrasil.net [200.153.64.2]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with SMTP id h58MHB4Z022461 for ; Sun, 8 Jun 2003 15:17:12 -0700 (PDT) Message-Id: <200306082217.h58MHB4Z022461@nwkea-mail-1.sun.com> Received: (qmail 5547 invoked by uid 89); 8 Jun 2003 22:18:38 -0000 Received: from unknown (HELO WebMail) (200.153.64.2) by 0 with SMTP; 8 Jun 2003 22:18:38 -0000 Received: from client 200.158.204.223 for UebiMiau2.7 (webmail client); Sun, 8 Jun 2003 19:18:38 -0300 Date: Sun, 8 Jun 2003 19:18:38 -0300 From: robson.oliveira@ipv6dobrasil.com.br To: "Brian E Carpenter" , "ipng@sunroof.eng.sun.com"@engmail1mpk.eng.sun.com Reply-to: "Robson.oliveira" Subject: Re: FEC0::/10 vs. FC00::/7 X-Priority: 3 X-Mailer: WebMail 2.7 X-Original-IP: 200.158.204.223 Content-Transfer-Encoding: 8bit X-MSMail-Priority: Medium Importance: Medium Content-Type: text/plain; charset="iso-8859-1"; MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Do you see any reason that's not performance, to use three IPv6 address in the same device? What do you think about security reasons with three address in the same device? Global IPv6 + IPSec (VPN) and site-local address can help administrate the security for connections to the same domain. Based in this view point, you don't have problem to use FEC0::/10 or FC00::/7 inside your network because: - Your site-local address will be encapsulated in your global address from the same domain - External connections will come ever from Global address from the differents domains - What's the link local address propose in the same data-link? autoconfiguration? Please, If someone have any information, I'd like to know the performance reasons to use three IPv6 address in the same device. Robson --------- Mensagem Original -------- De: "Brian E Carpenter" Para: "ipng@sunroof.eng.sun.com" Assunto: Re: FEC0::/10 vs. FC00::/7 Data: 08/06/2003 10:34 Margaret Wasserman wrote: > > Using myself as the example... > > Does anyone else find it sub-optimal that we are spending so > much time arguing about what address bits should be used for > local addressing when we have yet to gain consensus on: > > - The requirements for local addressing? > - The best technical mechanism(s) to meet those > requirements? > - Whether we need local addressing at all? I maintain that it is 100% clear that we need limited-scope addressing, and since we will never have a precise definition of a "site", we'd better not waste our time trying to define "site local" precisely. > > Let's figure out what we really need, and _then_ argue about > the specifics of where to put the address space. > > Did anyone want to comment on Tony's requirements document > and/or propose an alternative set of requirements? I think we should take that draft as good enough, and discuss Bob's proposal as a solution to those requirements. Brain > > Margaret > > At 11:02 AM 6/7/2003 -0400, Margaret Wasserman wrote: > >At 03:46 PM 6/6/2003 -0700, Bob Hinden wrote: > >>I still have a small preference preference for using FC00::/7 for the > >>globally unique local addresses due to the larger global ID, instead of > >>reusing the FEC0::/10 prefix. But either would work. > > > >The problem with using FECO::/10 for these addresses is that there > >are implementations that include special semantics to handle > >the ambiguity of FECO::/10 addresses, such as requiring a Zone ID > >to disambiguate FECO::/10 addresses, setting up separate routing > >tables for separate FECO::/10 zones, etc. > > > >In Bob's proposal, addresses are globally unique (although > >they may not be globally routed), so we don't need special > >semantics to handle the ambiguity. > > > >Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 9 05:04:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h59C4ATX011941; Mon, 9 Jun 2003 05:04:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h59C4AW3011940; Mon, 9 Jun 2003 05:04:10 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h59C46TX011933 for ; Mon, 9 Jun 2003 05:04:06 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h59C2Juc018404 for ; Mon, 9 Jun 2003 05:02:19 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h59C2Eep018698 for ; Mon, 9 Jun 2003 06:02:14 -0600 (MDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h59Burw16812 for ; Mon, 9 Jun 2003 11:56:54 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h59BUfp06257 for ; Mon, 9 Jun 2003 11:30:41 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003060905124017456 for ; Mon, 09 Jun 2003 05:12:40 -0700 Received: from orsmsx404.amr.corp.intel.com ([192.168.65.44]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 9 Jun 2003 05:02:12 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32E7E.F5B1679E" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: IPv6 & MIPv6 simulation on NS2 Date: Mon, 9 Jun 2003 05:02:11 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 & MIPv6 simulation on NS2 Thread-Index: AcMufvZIwdXhLxSPRra270TzWiOOLA== From: "Iyer, Prakash" To: X-OriginalArrivalTime: 09 Jun 2003 12:02:12.0061 (UTC) FILETIME=[F5C548D0:01C32E7E] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C32E7E.F5B1679E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello IPv6ers, I am looking for IPv6 and MIPv6 modules for NS2. I have come across is MobiWAN but it is unclear if the implementation is current and if so what the latest version/source is. Some pointers will be much appreciated. Thanks in advance. Prakash Iyer=20 prakash.iyer@intel.com Intel R&D ------_=_NextPart_001_01C32E7E.F5B1679E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPv6 & MIPv6 simulation on NS2

Hello IPv6ers,

I am looking for IPv6 and MIPv6 modules = for NS2. I have come across is MobiWAN but it is unclear if the = implementation is current and if so what the latest version/source is. = Some pointers will be much appreciated.

Thanks in advance.

Prakash Iyer
prakash.iyer@intel.com
Intel R&D

------_=_NextPart_001_01C32E7E.F5B1679E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 9 06:08:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h59D8iTX012356; Mon, 9 Jun 2003 06:08:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h59D8hAT012355; Mon, 9 Jun 2003 06:08:43 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h59D8eTX012348 for ; Mon, 9 Jun 2003 06:08:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h59D6sNh002458 for ; Mon, 9 Jun 2003 06:06:54 -0700 (PDT) Received: from mail.internetbrasil.net (mail.internetbrasil.net [200.153.64.2]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with SMTP id h59D6lLv015779 for ; Mon, 9 Jun 2003 06:06:48 -0700 (PDT) Message-Id: <200306091306.h59D6lLv015779@nwkea-mail-2.sun.com> Received: (qmail 51243 invoked by uid 89); 9 Jun 2003 13:07:30 -0000 Received: from unknown (HELO WebMail) (200.153.64.2) by 0 with SMTP; 9 Jun 2003 13:07:30 -0000 Received: from client 200.158.204.223 for UebiMiau2.7 (webmail client); Mon, 9 Jun 2003 10:07:26 -0300 Date: Mon, 9 Jun 2003 10:07:26 -0300 From: robson.oliveira@ipv6dobrasil.com.br To: "ipng@sunroof.eng.sun.com"@engmail1mpk.eng.sun.com Reply-to: "Robson.oliveira" Subject: Re: FEC0::/10 vs. FC00::/7 X-Priority: 3 X-Mailer: WebMail 2.7 X-Original-IP: 200.158.204.223 Content-Transfer-Encoding: 8bit X-MSMail-Priority: Medium Importance: Medium Content-Type: text/plain; charset="iso-8859-1"; MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Do you see any reason that's not performance, to use three IPv6 address in the same device? What do you think about security reasons with three address in the same device? Global IPv6 + IPSec (VPN) and site-local address can help administrate the security for connections to the same domain. Based in this view point, you don't have problem to use FEC0::/10 or FC00::/7 inside your network because: - Your site-local address will be encapsulated in your global address from the same domain - External connections will come ever from Global address from the differents domains - What's the link local address propose in the same data-link? autoconfiguration? Please, If someone have any information, I'd like to know the performance reasons to use three IPv6 address in the same device. 8 bits = oct 16 bits = hexat IPv6 = x:x:x:x:x:x:x:x = 8 hexat --Robson --------- Mensagem Original -------- De: "Brian E Carpenter" Para: "ipng@sunroof.eng.sun.com" Assunto: Re: FEC0::/10 vs. FC00::/7 Data: 08/06/2003 10:34 Margaret Wasserman wrote: > > Using myself as the example... > > Does anyone else find it sub-optimal that we are spending so > much time arguing about what address bits should be used for > local addressing when we have yet to gain consensus on: > > - The requirements for local addressing? > - The best technical mechanism(s) to meet those > requirements? > - Whether we need local addressing at all? I maintain that it is 100% clear that we need limited-scope addressing, and since we will never have a precise definition of a "site", we'd better not waste our time trying to define "site local" precisely. > > Let's figure out what we really need, and _then_ argue about > the specifics of where to put the address space. > > Did anyone want to comment on Tony's requirements document > and/or propose an alternative set of requirements? I think we should take that draft as good enough, and discuss Bob's proposal as a solution to those requirements. Brain > > Margaret > > At 11:02 AM 6/7/2003 -0400, Margaret Wasserman wrote: > >At 03:46 PM 6/6/2003 -0700, Bob Hinden wrote: > >>I still have a small preference preference for using FC00::/7 for the > >>globally unique local addresses due to the larger global ID, instead of > >>reusing the FEC0::/10 prefix. But either would work. > > > >The problem with using FECO::/10 for these addresses is that there > >are implementations that include special semantics to handle > >the ambiguity of FECO::/10 addresses, such as requiring a Zone ID > >to disambiguate FECO::/10 addresses, setting up separate routing > >tables for separate FECO::/10 zones, etc. > > > >In Bob's proposal, addresses are globally unique (although > >they may not be globally routed), so we don't need special > >semantics to handle the ambiguity. > > > >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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 9 11:19:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h59IJATX014221; Mon, 9 Jun 2003 11:19:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h59IJAcf014220; Mon, 9 Jun 2003 11:19:10 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h59IJ5TX014213 for ; Mon, 9 Jun 2003 11:19:05 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h59IHJuc027095 for ; Mon, 9 Jun 2003 11:17:19 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h59IHDep023494 for ; Mon, 9 Jun 2003 12:17:13 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HG800MBX82TMN@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 09 Jun 2003 12:16:05 -0600 (MDT) Received: from sun.com ([129.146.10.24]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HG8003YP82S7W@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 09 Jun 2003 12:16:05 -0600 (MDT) Date: Mon, 09 Jun 2003 11:16:04 -0700 From: Alain Durand Subject: Re: Status of To: awhite@arc.corp.mot.com Cc: IPng Message-id: <3EE4CEE4.7040200@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: <3EDF034B.7D488005@motorola.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew White wrote: >Pekka Savola wrote: > > >>That's not the complete picture. Addresses leak. They leak to others >>using the local scope, but without connectivity. I'd much prefer using >>globals first, because falling back to globals from first trying locals >>could take a long time (consider e.g. stupid firewalls who silently drop >>packets). >> >>This should not be an important issue, but I fear in practice, it is.. >> >> > >Agreed. There could be a long timeout on connection if we use an invalid >address (local or global) as our first choice, and an out-of-scope local is >theoretically guaranteed to be invalid. > Operational experience on a production network: We have seen the results of those timers with different implementations. They can be up to 3 minutes and 30 seconds per invalid address. Multiply that by the number of 'published/leaked' addresses (v6 nodes with multiple interfaces can have many) and you end up with an unusable system. - 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 Jun 10 01:23:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5A8N8TX016880; Tue, 10 Jun 2003 01:23:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5A8N8Er016879; Tue, 10 Jun 2003 01:23:08 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5A8N5TX016872 for ; Tue, 10 Jun 2003 01:23:05 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5A8LHNh025814 for ; Tue, 10 Jun 2003 01:21:17 -0700 (PDT) Received: from ursa.amorsen.dk (x1-6-00-e0-28-13-bf-45.k32.webspeed.dk [195.41.138.12]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5A8LBWP026739 for ; Tue, 10 Jun 2003 02:21:11 -0600 (MDT) Received: from vega.amorsen.dk (vega.amorsen.dk [172.31.4.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ursa.amorsen.dk (Postfix) with ESMTP id 88E841C1EC; Tue, 10 Jun 2003 10:21:09 +0200 (CEST) Subject: Re: another view of fc00::/7 From: Benny Amorsen To: Robert Elz Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: <12722.1055095987@munnari.OZ.AU> References: <3EE324AF.8088F380@hursley.ibm.com> <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> <12722.1055095987@munnari.OZ.AU> Content-Type: text/plain Message-Id: <1055233389.2165.3.camel@vega.amorsen.dk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (1.3.92-1) (Preview Release) Date: 10 Jun 2003 10:23:09 +0200 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 2003-06-08 at 20:13, Robert Elz wrote: > Unless we can demonstrate that they are, and must be, unique (to work, or > be useful) we really have to make it very very plain that they are not > unique. This is one of the reasons I proposed having registries that do /not/ pick addresses. If there are several places where an address can be registered, it should be painfully obvious to everyone that conflicts will happen. Nobody can claim to be unaware. /Benny -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 10 02:51:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5A9pSTX017249; Tue, 10 Jun 2003 02:51:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5A9pSHC017248; Tue, 10 Jun 2003 02:51:28 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5A9pOTX017241 for ; Tue, 10 Jun 2003 02:51:25 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5A9nbuc006381 for ; Tue, 10 Jun 2003 02:49:37 -0700 (PDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5A9nVYU011194 for ; Tue, 10 Jun 2003 03:49:31 -0600 (MDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5A9nR76035660 for ; Tue, 10 Jun 2003 11:49:28 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h5A9nFOR290636 for ; Tue, 10 Jun 2003 11:49:15 +0200 Received: from dhcp22-128.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA63100 from ; Tue, 10 Jun 2003 11:49:12 +0200 Message-Id: <3EE5A9AF.71B58EE9@hursley.ibm.com> Date: Tue, 10 Jun 2003 11:49:35 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: another view of fc00::/7 References: <3EE324AF.8088F380@hursley.ibm.com> <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> <12722.1055095987@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Summary answer to both of kre's points: If one could go and get a prefix under 2000::/3 today that was not tied to an ISP, that would be just fine. But one can't, for good reasons, so the only solution I see is a lightweight way to get a PI prefix that isn't ambiguous. Bob's proposal is the best I've seen for this. That's all I can say, because your arguments are basically sound, but we don't live in a perfect world. Brian Robert Elz wrote: > > Date: Sun, 08 Jun 2003 13:57:35 +0200 > From: Brian E Carpenter > Message-ID: <3EE324AF.8088F380@hursley.ibm.com> > > | I don't think so, as far as the DFZ goes. What *will* happen, whatever > | we do, is exactly what happens today - zillions of VPNs and private > | static routes for inter-enterprise connections, that are quite > | independent of the public routing tables summarized in the DFZ. > > Yes, for those who want to use non-routable addresses for this purpose, > having a means by which conflicts can be avoided would be a nice advantage. > > However, someone needs to explain to me why an IPv6 VPN would want to > use non-routable addresses particularly? Why not just use the global > addresses that the sites already have. > > In the IPv4 world, there's a simple answer - the sites are using 1918 > addresses (frequently) internally, and linking, at least parts of, their > internal nets is the aim. So, their 1918 addresses are what they want to > exchange - which works iff there are no allocation conflicts (which happens > only by chance). > > But in IPv6, everyone is going to have global addresses, why can't they > just be used for VPNs? > > If the answer is "because we use 1918 addresses in IPv4" then I think > we have some education to do. > > If the answer is "we want address stability in our group, even if some of > the members have to change their routable prefixes", then that's fine, but > for this, wouldn't the right answer be to simply create a new prefix for > the VPN, and use that one? That is in this new address space that's being > created, the organisations that are creating a VPN pick one prefix that > is not in use by any of them (with 2^38 or more prefixes, minimum, to > choose from, that can't be hard) and assign that to all nodes that are > participating in the VPN (allocating subnets from it to the organisations). > > If things are done that way, then it is no longer even relevant that > more than one of the organisations happens to have randomly selected the > same prefix - and there is then no longer any requirement that there > be any kind of (pre-existing) uniqueness for this particular usage. > > Brian also said (in a different message): > > | To be more precise, we are going to define them in a way that makes them > | extremely likely to be unique, and then treat them as if they are > | mathematically unique. To me, that's good enough. > > It would be, but that's the very thing I don't think we should be doing. > If we treat them as if they're unique, someone will forget that they're > not, and start doing something which actually assumes the uniqueness. > > Unless we can demonstrate that they are, and must be, unique (to work, or > be useful) we really have to make it very very plain that they are not > unique. > > 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 Jun 10 04:07:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AB7PTX017839; Tue, 10 Jun 2003 04:07:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5AB7OE1017838; Tue, 10 Jun 2003 04:07:24 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AB7LTX017831 for ; Tue, 10 Jun 2003 04:07:21 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5AB5XNh000057 for ; Tue, 10 Jun 2003 04:05:33 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5AB5Qht012649 for ; Tue, 10 Jun 2003 05:05:27 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h5AB5I205319; Tue, 10 Jun 2003 18:05:19 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5AB25o23959; Tue, 10 Jun 2003 18:02:07 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: another view of fc00::/7 In-Reply-To: <3EE5A9AF.71B58EE9@hursley.ibm.com> References: <3EE5A9AF.71B58EE9@hursley.ibm.com> <3EE324AF.8088F380@hursley.ibm.com> <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> <12722.1055095987@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Jun 2003 18:02:05 +0700 Message-ID: <7253.1055242925@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 10 Jun 2003 11:49:35 +0200 From: Brian E Carpenter Message-ID: <3EE5A9AF.71B58EE9@hursley.ibm.com> | If one could go and get a prefix under 2000::/3 today that was not tied | to an ISP, that would be just fine. So, you mean there's a need to have address stability inside the VPN? That's fine - but I'd like to see that made clear whenever this issue is raised. I haven't had anything to do with large VPNs, and with that lack of experience, I can't see any particular reason why address stability is any more required there than the internet at large. That is, I always thought a VPN was more about access control, rather than anything else. | I see is a lightweight way to get a PI prefix that isn't ambiguous. For stability, you'd want a prefix that doesn't conflict with any of the prefixes used by the members of the VPN. For that, whoever is primarily responsible (someone must be doing access control policy) can just collect all prefixes in use (ignoring normal global ones as the first few bits will serve to eliminate those) and generate a new number that is different than everything connected (the list of "connected" can include everyone who may someday potentially be permitted to be a part). Once allocated the number can be advertised (as in, on a web page) and anyone who ever feels they might like to ever become part of that VPN could avoid it. There's no need for a registry for this. Of course, Benny's suggestion should also work for this - anyone who wants runs a registry, most likely with some particular target audience in mind. One of those would perhaps be "anyone involved in the auto industry in any way", another perhaps "airlines" - then after inventing your own prefix, you go register it with whatever registries seem like they may keep your number unique, and if there's a conflict in any, start again. So a tyre maker might register with both an auto and an airlines registry, whereas a maker of car radios probably only (or those) the auto registry (but perhaps also an electronics registry). That way, it is very likely that anyone (who had bothered to register) in any likely field would have a number distinct from everyone else, without expecting or requiring me, at my house, to bother registering anything with anyone (as I personally don't want a VPN like this, and don't care who else is using the same non-routable numbers as I use). Both methods avoid the "this is globally unique" fiction, and hence make it very unlikely that someone will later attempt to depend upon that (as in the "everyone we know has a number that is unique"). 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 Jun 10 04:08:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AB8uTX017856; Tue, 10 Jun 2003 04:08:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5AB8u84017855; Tue, 10 Jun 2003 04:08:56 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AB8rTX017848 for ; Tue, 10 Jun 2003 04:08:53 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5AB74Nh000571 for ; Tue, 10 Jun 2003 04:07:05 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5AB6sep013940 for ; Tue, 10 Jun 2003 05:06:57 -0600 (MDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 10 Jun 2003 16:44:30 +0530 Received: from sivarka (sivarka.future.futsoft.com [10.20.6.73]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h5AB10nI004571 for ; Tue, 10 Jun 2003 16:31:01 +0530 Reply-To: From: "Sivaramakrishnan A" To: Subject: ICMPv6 error messages Date: Tue, 10 Jun 2003 16:32:39 +0530 Message-Id: <000501c32f3f$cf5c8ca0$4906140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20030316041833.7131F7B87@berkshire.research.att.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, ICMPv6 RFC states that, ICMPv6 error message MUST NOT be sent as result of receiving a packet sent as link-layer multicast or broadcast. But why should IPv6 be concerned about the Link-Layer address? regards, -Sivaram *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. 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 using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 10 04:39:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5ABdTTX018274; Tue, 10 Jun 2003 04:39:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5ABdTmj018273; Tue, 10 Jun 2003 04:39:29 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5ABdMTX018257 for ; Tue, 10 Jun 2003 04:39:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5ABbYuc026064 for ; Tue, 10 Jun 2003 04:37:34 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5ABbSLv008860 for ; Tue, 10 Jun 2003 04:37:29 -0700 (PDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5ABbRbJ123504 for ; Tue, 10 Jun 2003 13:37:27 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h5ABbLNQ165422 for ; Tue, 10 Jun 2003 13:37:26 +0200 Received: from dhcp22-128.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA66784 from ; Tue, 10 Jun 2003 13:37:20 +0200 Message-Id: <3EE5C307.6D8827C6@hursley.ibm.com> Date: Tue, 10 Jun 2003 13:37:43 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: another view of fc00::/7 References: <3EE324AF.8088F380@hursley.ibm.com> <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> <12722.1055095987@munnari.OZ.AU> <1055233389.2165.3.camel@vega.amorsen.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Benny Amorsen wrote: > > On 2003-06-08 at 20:13, Robert Elz wrote: > > > Unless we can demonstrate that they are, and must be, unique (to work, or > > be useful) we really have to make it very very plain that they are not > > unique. > > This is one of the reasons I proposed having registries that do /not/ > pick addresses. If there are several places where an address can be > registered, it should be painfully obvious to everyone that conflicts > will happen. Nobody can claim to be unaware. That's also why I personally would be happy with pseudo-random probably-unique prefixes, but Bob's idea of a 10 Euro registry for unique pseudo-random numbers is aimed at people who want a bit more assurance. In all cases, your mileage may vary. 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 Jun 10 04:46:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5ABkhTX018473; Tue, 10 Jun 2003 04:46:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5ABkh27018472; Tue, 10 Jun 2003 04:46:43 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5ABkeTX018465 for ; Tue, 10 Jun 2003 04:46:40 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5ABipNh007129 for ; Tue, 10 Jun 2003 04:44:51 -0700 (PDT) Received: from mail.iwavesystems.com (mail.iwavesystems.com [203.196.144.54]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5ABijht024954 for ; Tue, 10 Jun 2003 05:44:48 -0600 (MDT) Received: from iwave009 (ns1.iwave.net [203.196.144.50]) by mail.iwavesystems.com (8.12.4/) with SMTP id h5ABi40h007678; Tue, 10 Jun 2003 17:14:22 +0530 Message-ID: <00fb01c32f45$df768040$8d02a8c0@iwave009> From: "Malar" To: , References: <000501c32f3f$cf5c8ca0$4906140a@future.futsoft.com> Subject: Re: ICMPv6 error messages Date: Tue, 10 Jun 2003 17:15:34 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Disposition-Notification-To: "Malar" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 In IPv6 also You have Address Resolution in the form of NDP messages which will be received by all nodes. This NDP msg will have Multicast link layer address in its ethernet header. ----- Original Message ----- From: "Sivaramakrishnan A" To: Sent: Tuesday, June 10, 2003 4:32 PM Subject: ICMPv6 error messages > > Hi, > > ICMPv6 RFC states that, ICMPv6 error message MUST NOT be sent > as result of receiving a packet sent as link-layer multicast or > broadcast. But why should IPv6 be concerned about the Link-Layer > address? > > regards, > -Sivaram > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > 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 using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.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. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 10 04:52:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5ABqvTX018655; Tue, 10 Jun 2003 04:52:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5ABqvbm018654; Tue, 10 Jun 2003 04:52:57 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5ABqrTX018647 for ; Tue, 10 Jun 2003 04:52:53 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5ABp5Nh008211 for ; Tue, 10 Jun 2003 04:51:05 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5ABorht026621 for ; Tue, 10 Jun 2003 05:50:54 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h5ABoo212919; Tue, 10 Jun 2003 18:50:50 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5ABkto08527; Tue, 10 Jun 2003 18:46:58 +0700 (ICT) From: Robert Elz To: Alain Durand cc: awhite@arc.corp.mot.com, IPng Subject: Re: Status of In-Reply-To: <3EE4CEE4.7040200@sun.com> References: <3EE4CEE4.7040200@sun.com> <3EDF034B.7D488005@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Jun 2003 18:46:55 +0700 Message-ID: <14586.1055245615@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 09 Jun 2003 11:16:04 -0700 From: Alain Durand Message-ID: <3EE4CEE4.7040200@sun.com> | >Agreed. There could be a long timeout on connection if we use an invalid | >address (local or global) as our first choice, and an out-of-scope local is | >theoretically guaranteed to be invalid. | > | Operational experience on a production network: | We have seen the results of those timers with different implementations. | They can be up to 3 minutes and 30 seconds per invalid address. | Multiply that by the number of 'published/leaked' addresses (v6 nodes with | multiple interfaces can have many) and you end up with an unusable system. This general problem has nothing much to do with address forms, and it is more likely that a host will have lots of global addresses than lots of local ones (that is, the number of global addresses will normally be a multiple of the number of local ones - sometimes that multiple will be 1, sometimes bigger). It would be rare for a host to have more local addresses than global (unless the number of global is 0, in which case this whole discussion is moot). But I'd hate to think that we were allowing stupid software design to influence choices, rather than simply striving to improve the software. I do "local first" (actually a variation of that, but the effects for this purpose are the same) - the implementation waits up to about 100ms for a response. If it gets an answer, it goes on with the local address. If it gets an ICMP it switches to global, if the 100ms passes with no response, it switches to global. This relies on several assumptions about the nature of local addresses. First, they tend to be local - the RTT to a local address should be fairly small (100ms allows for spans of a continent). Sometimes for a diverse organisation, this might result in a global address being used where a local one could have been (either because 100ms isn't long enough, or because of packet loss - congested local nets) but that's no different than "prefer global first" would achieve. (Work is currently being done which should lower the effects of this without delaying applications). Second, if one local address doesn't work, then it is very likely that none will (the way we do this, it actually becomes a side effect, rather than a deliberate act, but anyway). That is, if one local address fails, then we don't try others, we switch to global (of course, if there are no global addresses things are different). We're going to need to revisit this if we end up switching from site local addresses to Hinden addresses, as there the reachability of one local address really says nothing about that of any other, but for current SLs it does. The overall effect of this is that the difference to the application when preferring local first is almost invisible (but we're doing more to make this even smaller). There doesn't need to be a huge delay before finally trying a global address and having it work. On the other hand, if you try global first, and you're really trying to reach a local node, for which the global addresses don't work (have been arranged to be dropped by routers intervening, to force the use of local addressing) then you really must suffer a long delay - the delay waiting for a response has to allow for worst case internet RTTs (or you might fail to find the only address that actually works) along with retransmits (as while dropped packets locally are usually quite rare, across the internet they're normal) - and you cannot draw any conclusions about one global address's reachability from that of another, they all need to be tried. 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 Jun 10 06:32:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5ADWRTX019301; Tue, 10 Jun 2003 06:32:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5ADWRuj019300; Tue, 10 Jun 2003 06:32:27 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5ADWOTX019293 for ; Tue, 10 Jun 2003 06:32:24 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5ADUauc023596 for ; Tue, 10 Jun 2003 06:30:36 -0700 (PDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5ADUTWP006509 for ; Tue, 10 Jun 2003 07:30:30 -0600 (MDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5ADU876030864; Tue, 10 Jun 2003 15:30:11 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h5ADU8OR180722; Tue, 10 Jun 2003 15:30:08 +0200 Received: from dhcp22-128.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA29560 from ; Tue, 10 Jun 2003 15:30:06 +0200 Message-Id: <3EE5DD75.391C37D7@hursley.ibm.com> Date: Tue, 10 Jun 2003 15:30:29 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: another view of fc00::/7 References: <3EE5A9AF.71B58EE9@hursley.ibm.com> <3EE324AF.8088F380@hursley.ibm.com> <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> <12722.1055095987@munnari.OZ.AU> <7253.1055242925@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > > Date: Tue, 10 Jun 2003 11:49:35 +0200 > From: Brian E Carpenter > Message-ID: <3EE5A9AF.71B58EE9@hursley.ibm.com> > > | If one could go and get a prefix under 2000::/3 today that was not tied > | to an ISP, that would be just fine. > > So, you mean there's a need to have address stability inside the VPN? Yes, but more than that, inside a shifting population of company networks that are constantly joining and leaving virtual organizations. You can imagine the gymnastics of this unless there is a reasonably high probability that there will be no collision between prefixes. > > That's fine - but I'd like to see that made clear whenever this issue > is raised. I haven't had anything to do with large VPNs, and with > that lack of experience, I can't see any particular reason why address > stability is any more required there than the internet at large. > That is, I always thought a VPN was more about access control, rather > than anything else. Traditionally, yes, but traditionally we haven't viewed distributed computing as a resource purchased on demand. This is changing, and the work-arounds for Net 10 are becoming onerous. > > | I see is a lightweight way to get a PI prefix that isn't ambiguous. > > For stability, you'd want a prefix that doesn't conflict with any of > the prefixes used by the members of the VPN. For that, whoever is > primarily responsible (someone must be doing access control policy) > can just collect all prefixes in use (ignoring normal global ones as > the first few bits will serve to eliminate those) and generate a new > number that is different than everything connected (the list of > "connected" can include everyone who may someday potentially be > permitted to be a part). Once allocated the number can be advertised > (as in, on a web page) and anyone who ever feels they might like to > ever become part of that VPN could avoid it. > > There's no need for a registry for this. That doesn't solve the N**2 problem where any customer may want to join any VPN at any time. We don't want everybody to start numbering at 1. > Of course, Benny's suggestion should also work for this - anyone who > wants runs a registry, most likely with some particular target audience > in mind. One of those would perhaps be "anyone involved in the auto > industry in any way", another perhaps "airlines" - then after inventing > your own prefix, you go register it with whatever registries seem like > they may keep your number unique, and if there's a conflict in any, > start again. So a tyre maker might register with both an auto and an > airlines registry, whereas a maker of car radios probably only (or those) > the auto registry (but perhaps also an electronics registry). That's a lot of complexity compared with either a generic pseudo-random algorithm or a global registry. (I can't see a logical objection to multiple registries, if IANA gives them each a prefix, but I don't see a benefit either.) > > That way, it is very likely that anyone (who had bothered to register) > in any likely field would have a number distinct from everyone else, > without expecting or requiring me, at my house, to bother registering > anything with anyone (as I personally don't want a VPN like this, and > don't care who else is using the same non-routable numbers as I use). But I don't believe that in the future world of computing as a utility service, we can assume that customers and service providers are neatly segmented into fields of application. > Both methods avoid the "this is globally unique" fiction, and hence > make it very unlikely that someone will later attempt to depend upon > that (as in the "everyone we know has a number that is unique"). Well, somebody will depend on it whatever we write, but you have a point, which is why I've always said that I'd settle for "probably unique". 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 Jun 10 08:00:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AF0CTX019774; Tue, 10 Jun 2003 08:00:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5AF0CpA019773; Tue, 10 Jun 2003 08:00:12 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AF08TX019766 for ; Tue, 10 Jun 2003 08:00:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5AEwJNh003541 for ; Tue, 10 Jun 2003 07:58:19 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h5AEwE4Z005055 for ; Tue, 10 Jun 2003 07:58:14 -0700 (PDT) Subject: RE: another view of fc00::/7 Date: Tue, 10 Jun 2003 07:58:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F86F@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: another view of fc00::/7 Thread-Index: AcMvQONDMY/ENW9rTZ6b+301d1jfWwAHoPyA From: "Michel Py" To: "Robert Elz" , "Brian Carpenter" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5AF09TX019767 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre, > Robert Elz wrote: > So, you mean there's a need to have address stability > inside the VPN? On some, more than anything else. For example, if the VPN is used as part of a supply chain, there are access-lists on both ends and a lot of other manual config all over the place because this involves getting access into some protected areas of the system. > I always thought a VPN was more about access control, > rather than anything else. Access control means access-lists and similar annoyances and they don't change dynamically. This blends with the renumbering issue that I don't want to open again but a perfect example of "un-renumberable" network is a large, multi-company VPN setup. > I can't see any particular reason why address stability is > any more required there than the internet at large. Because VPN configurations are sometimes a lot more complicated than Internet configurations. 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 Jun 10 08:53:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AFr3TX020071; Tue, 10 Jun 2003 08:53:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5AFr3cv020070; Tue, 10 Jun 2003 08:53:03 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AFqxTX020063 for ; Tue, 10 Jun 2003 08:52:59 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5AFpBuc029569 for ; Tue, 10 Jun 2003 08:51:11 -0700 (PDT) Received: from web41812.mail.yahoo.com (web41812.mail.yahoo.com [66.218.93.146]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with SMTP id h5AFp5WP003762 for ; Tue, 10 Jun 2003 09:51:05 -0600 (MDT) Message-ID: <20030610155105.37507.qmail@web41812.mail.yahoo.com> Received: from [65.213.193.49] by web41812.mail.yahoo.com via HTTP; Tue, 10 Jun 2003 08:51:05 PDT Date: Tue, 10 Jun 2003 08:51:05 -0700 (PDT) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Participation To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1267882420-1055260265=:36245" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-1267882420-1055260265=:36245 Content-Type: text/plain; charset=us-ascii Internetworking 2003 International Conference Hilton San Jose & Towers Hotel, California June 22-June 24, 2003 =================================================================== http://www.caitr.org/internetworking03/index.htm =================================================================== You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials. Registration for the conference is underway - online registration is now available. The early registration discounts are extremely attractive and have been extended through June 15, 2003. To register, go to: http://www.caitr.org/internetworking03/registration.htm Program: ------------- (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details) Sunday June 22 Tutorial-1: MPLS VPNs Tutorial-2: IPv6 Tutorial-3: Mobile Wireless Internet Architecture and Protocols Tutorial-4: Voice over Packet Monday June 23 Welcome and Keynote Session: Network Technology Trends - Forwarding Element and Control Separation - Evolution of Inter-Domain Routing - Network Processing Building Blocks: Enabling the Routers of the Future Session: Network Architecture - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6 - Domain Constrained Multicast: A New Approach for IP Multicast Routing - Internetworking MPLS Layer 2 Transport with an IP Services Network Session: Storage Area Networks - Storage as a Network Node - Object-Based Storage - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP - SANs Considerations Session: Mobile & Wireless Networks - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6 - Challenges and Roadmap of UMTS Network Deployment - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS - Mobile Authentication and QoS - An Analysis of Hand-off methods in some WAN and LAN networks Tuesday June 24 Session: Routing Performance - Optimizing Route Convergence - Active Dynamic Routing - Fluid flow network modeling for hop-by-hop feedback control design and analysis Session: Applications & Services - Securing the Web with Next Generation Encryption Technologies - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 - A novel EAC semantic for the RTSP protocol - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet Session: Network Management & Planning - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Problems - Design Of Fast Fault Restoration System For WDM Networks - Cross-domain multimedia service provisioning, the EVOLUTE solution Session: Routing Architecture & QoS - QoS Routing in Networks with Non-Deterministic Information - A new routing architecture: Atomised Routing - Traceroute and BGP AS Path Incongruities - QoS routing for Differentiated Services: simulations and prototype experiments - Probabilistic routing for QoS improvement in GPS networks We look forward to seeing you at the Conference. Regards, Conference Technical Co-chairs : - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Marc Lobelle, UCL University, Belgium - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Dr. Tony Przygienda, Xebeo - Ran Canetti, IBM --0-1267882420-1055260265=:36245 Content-Type: text/html; charset=us-ascii
 
     Internetworking 2003 International Conference
     Hilton San Jose & Towers Hotel, California
              June 22-June 24, 2003
===================================================================
    http://www.caitr.org/internetworking03/index.htm
===================================================================
 
You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.

Registration for the conference is underway - online registration is now available. The early registration discounts are extremely attractive and have been extended through June 15, 2003. To register, go to:
 http://www.caitr.org/internetworking03/registration.htm
 
Program:
-------------
(visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)
 
Sunday June 22
    Tutorial-1: MPLS VPNs
    Tutorial-2: IPv6
    Tutorial-3: Mobile Wireless Internet Architecture and Protocols
    Tutorial-4: Voice over Packet
 
Monday June 23
    Welcome and Keynote
 
&n! bsp;   Session: Network Technology Trends
      - Forwarding Element and Control Separation
      - Evolution of Inter-Domain Routing 
      - Network Processing Building Blocks: Enabling the Routers of the Future
 
    Session: Network Architecture
      - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6
      - Domain Constrained Multicast: A New Approach for IP Multicast Routing
      - Internetworking MPLS Layer 2 Transport with an IP Services Network
 
    Session: Storage Area Networks
      - Storage as a Network Node
      - Object-Based Storage
      - Design, Implementation, and Performance Analysis of ! the iSCSI Protocol for SCSI over TCP/IP
    &n bsp; - SANs Considerations
 
    Session: Mobile & Wireless Networks
      - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6
      - Challenges and Roadmap of UMTS Network Deployment
      - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS
      - Mobile Authentication and QoS
      - An Analysis of Hand-off methods in some WAN and LAN networks
 
Tuesday June 24
    Session: Routing Performance
      - Optimizing Route Convergence
      - Active Dynamic Routing 
      - Fluid flow network modeling for hop-by-hop feedback control design and analysis
 
    Session:  Applications & Services
      - Securing the Web with Next Generation Encryption Technologies
      - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 
      - A novel EAC semantic for the RTSP protocol
      - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet
 
    Session:  Network Management & Planning
    ! ;  - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature
      - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Problems
      - Design Of Fast Fault Restoration System For WDM Networks
      - Cross-domain multimedia service provisioning, the EVOLUTE solution
 
    Session:  Routing Architecture & QoS
      - QoS Routing in Networks with Non-Deterministic Information
      - A new routing architecture: Atomised Routing
      - Traceroute and BGP AS Path Incongruities
      - QoS routing for Differentiated Services: simulations and prototype experiments
      - Probabilistic routing for QoS improvement in GPS networks
 
We look forward t! o seeing you at the Conference.
 
Regards,
 Confere nce Technical Co-chairs :
 - Dr. Maurice Gagnaire, ENST, France
 - Daniel Awduche
 
 Technical Program Committee of the Internetworking 2003 Conference:
 - Roberto Sabella, Erisson
 - Dr. Moshe Zukerman, Univ. of Melbourne
 - Nada Golmie, NIST
 - Dr. Guy Pujolle, LIP6, France
 - Dr. Samir Tohme, ENST, France
 - Stefano Trumpy, Italian National Research Council
 - Dr. Ibrahim Habib, City Univ. of NY
 - Dr. Marc Lobelle, UCL University, Belgium
 - Dr. Parviz Yegani, Cisco Systems
 - Dr. G.S. Kuo
 - Dr. Abbas Jamalipour, Univ. of Sydney
 - Dr. Hussein Mouftah, Univ. of Ottawa
 - James Kempf
 - Elizabeth Rodriguez
 - Dr. Ferit Yegenoglu, Isocore
 - Dr. Ali Zadeh, George Mason University
 - Dr. Tony Przygienda, Xebeo
 - Ran Canetti, IBM
--0-1267882420-1055260265=:36245-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 10 09:06:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AG6lTX020469; Tue, 10 Jun 2003 09:06:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5AG6lfM020468; Tue, 10 Jun 2003 09:06:47 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AG6hTX020461 for ; Tue, 10 Jun 2003 09:06:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5AG4tuc004671 for ; Tue, 10 Jun 2003 09:04:55 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5AG4n4Z017795 for ; Tue, 10 Jun 2003 09:04:50 -0700 (PDT) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h5AG4XsM037375; Tue, 10 Jun 2003 09:04:33 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h5AG4W58037374; Tue, 10 Jun 2003 09:04:32 -0700 (PDT) (envelope-from jj) Date: Tue, 10 Jun 2003 09:04:32 -0700 From: Shannon -jj Behrens To: Benny Amorsen Cc: Robert Elz , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: null-routed aggregated global unicast (was: another view of fc00::/7) Message-ID: <20030610160432.GB36769@alicia.nttmcl.com> References: <3EE324AF.8088F380@hursley.ibm.com> <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> <12722.1055095987@munnari.OZ.AU> <1055233389.2165.3.camel@vega.amorsen.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1055233389.2165.3.camel@vega.amorsen.dk> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Earlier, I suggested that an ISP could delegate addresses out of its existing aggregated, global unicast address block for free without providing connectivity. Having seen all of the email on this subject, I believe that such an ISP could actually sell prefixes for which it doesn't provide direct connectivity. Such addresses could be used for VPN's, etc. without fear of collision. Traffic destined to such addresses on the Internet would be aggregated to the ISP, and probably sent to /dev/null. For an additional fee, the ISP could tunnel such traffic back its customers. The prefixes would be sold for a fixed, one-time fee. Pros ==== no collisions: Multiple ISP's could sell prefixes in such a manner, and there would be no fear of collisions. no fear of increasing fees: The fee for such prefixes would be one-time and fixed. This would be bound by a legal contract with the customer. hijacking similar to existing system: The danger of "evil" ISP's doing "evil" things is equivalent to our existing system. Furthermore, this is mitigated by the fact that there is no well known prefix, such as fee0::. Cons ==== no convenient prefix: Since any ISP could sell addresses in such a manner, there is no convenient prefix such as fee0::. Thus, OS's cannot provide default address selection behavior, nor can firewalls automatically filter such prefixes. out of business: It's still possible that the ISP might go out of business. Hopefully, the ISP could provide paperwork to its RIR concerning all of the customers that had purchased such prefixes so that the RIR could avoid reallocation of such address prefixes. Best Regards, -jj -- Hacker is to software engineer as Climbing Mt. Everest is to building a Denny's there. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 10 09:29:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AGTLTX020753; Tue, 10 Jun 2003 09:29:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5AGTLAm020752; Tue, 10 Jun 2003 09:29:21 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AGTHTX020745 for ; Tue, 10 Jun 2003 09:29:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5AGRTNh004303 for ; Tue, 10 Jun 2003 09:27:29 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h5AGRO4Z001610 for ; Tue, 10 Jun 2003 09:27:24 -0700 (PDT) Subject: RE: null-routed aggregated global unicast (was: another view of fc00::/7) Date: Tue, 10 Jun 2003 09:27:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F870@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: null-routed aggregated global unicast (was: another view of fc00::/7) Thread-Index: AcMvar0HBY9igfp0S/G4ByzD+5CjVgAAc9+g From: "Michel Py" To: "Shannon -jj Behrens" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5AGTITX020746 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jj, > Earlier, I suggested that an ISP could delegate addresses > out of its existing aggregated, global unicast address block > for free without providing connectivity. Having seen all of > the email on this subject, I believe that such an ISP could > actually sell prefixes for which it doesn't provide direct > connectivity. Such addresses could be used for VPN's, etc. > without fear of collision. Traffic destined to such addresses > on the Internet would be aggregated to the ISP, and probably > sent to /dev/null. I like this better than anything else I have seen to date. 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 Jun 10 10:00:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AH01TX021061; Tue, 10 Jun 2003 10:00:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5AH00Hc021060; Tue, 10 Jun 2003 10:00:00 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AGxvTX021053 for ; Tue, 10 Jun 2003 09:59:57 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5AGw9uc023740 for ; Tue, 10 Jun 2003 09:58:09 -0700 (PDT) Received: from fuchsia.home (ip30.coe.tnet.co.th [203.146.155.30]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5AGw1ep026904 for ; Tue, 10 Jun 2003 10:58:02 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h5AGvE37007511; Tue, 10 Jun 2003 23:57:15 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5AGsMH17256; Tue, 10 Jun 2003 23:54:39 +0700 (ICT) From: Robert Elz To: "Michel Py" cc: "Brian Carpenter" , ipng@sunroof.eng.sun.com Subject: Re: another view of fc00::/7 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F86F@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F504F86F@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Jun 2003 23:54:22 +0700 Message-ID: <9367.1055264062@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 10 Jun 2003 07:58:44 -0700 From: "Michel Py" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F86F@server2000.arneill-py.sacramento.ca.us> | Access control means access-lists and similar annoyances and they don't | change dynamically. This is something that needs fixing. We need it to make renumbering possible. | This blends with the renumbering issue Yes exactly. There is no great technical problem here (which isn't to say it is trivial) it just needs the incentive to actually get it to be done. 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 Jun 10 10:49:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AHnsTX021344; Tue, 10 Jun 2003 10:49:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5AHnrhr021343; Tue, 10 Jun 2003 10:49:53 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AHnnTX021336 for ; Tue, 10 Jun 2003 10:49:49 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5AHm1Nh005434 for ; Tue, 10 Jun 2003 10:48:01 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5AHltYU017163 for ; Tue, 10 Jun 2003 11:47:55 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGA00JZH1FUX2@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Tue, 10 Jun 2003 11:47:54 -0600 (MDT) Received: from sun.com ([129.146.10.24]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGA00HLB1FT1S@mail.sun.net> for ipng@sunroof.eng.sun.com; Tue, 10 Jun 2003 11:47:54 -0600 (MDT) Date: Tue, 10 Jun 2003 10:47:53 -0700 From: Alain Durand Subject: Re: Status of To: Robert Elz Cc: awhite@arc.corp.mot.com, IPng Message-id: <3EE619C9.7030204@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: <3EE4CEE4.7040200@sun.com> <3EDF034B.7D488005@motorola.com> <14586.1055245615@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: >I do "local first" (actually a variation of that, but the effects for this >purpose are the same) - the implementation waits up to about 100ms for >a response. If it gets an answer, it goes on with the local address. If >it gets an ICMP it switches to global, if the 100ms passes with no >response, it switches to global. > >This relies on several assumptions about the nature of local addresses. > >First, they tend to be local - the RTT to a local address should be >fairly small (100ms allows for spans of a continent). Sometimes >for a diverse organisation, this might result in a global address being >used where a local one could have been (either because 100ms isn't long >enough, or because of packet loss - congested local nets) but that's >no different than "prefer global first" would achieve. (Work is >currently being done which should lower the effects of this without >delaying applications). > >Second, if one local address doesn't work, then it is very likely that >none will (the way we do this, it actually becomes a side effect, >rather than a deliberate act, but anyway). That is, if one local address >fails, then we don't try others, we switch to global (of course, if >there are no global addresses things are different). We're going to >need to revisit this if we end up switching from site local addresses >to Hinden addresses, as there the reachability of one local address >really says nothing about that of any other, but for current SLs it does. > >The overall effect of this is that the difference to the application >when preferring local first is almost invisible (but we're doing more >to make this even smaller). > >There doesn't need to be a huge delay before finally trying a global >address and having it work. > Reachability os one thing, but you may have to wait for TCP timeouts. RFC1122, section 4.2.3.5 TCP Connection Failures Says that the initial SYN has to wait at least 3 minutes... Note that I've seen some implementation ignoring this MUST and setting the timer to 12 or 25 seconds, but never to 100ms. >On the other hand, if you try global first, and you're really trying to >reach a local node, for which the global addresses don't work (have been >arranged to be dropped by routers intervening, to force the use of >local addressing) then you really must suffer a long delay - the delay >waiting for a response has to allow for worst case internet RTTs (or >you might fail to find the only address that actually works) along >with retransmits (as while dropped packets locally are usually quite rare, >across the internet they're normal) - and you cannot draw any conclusions >about one global address's reachability from that of another, they all >need to be tried. > Same issue here, TCP timeouts. - 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 Jun 10 11:23:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AINBTX021608; Tue, 10 Jun 2003 11:23:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5AINBQ5021607; Tue, 10 Jun 2003 11:23:11 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5AIN7TX021600 for ; Tue, 10 Jun 2003 11:23:07 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5AILIuc028265 for ; Tue, 10 Jun 2003 11:21:19 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5AIL4WP005595 for ; Tue, 10 Jun 2003 12:21:13 -0600 (MDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h5AIL0a16476; Tue, 10 Jun 2003 20:21:00 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h5AIL0of008099; Tue, 10 Jun 2003 20:21:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200306101821.h5AIL0of008099@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: sivarka@future.futsoft.com cc: ipng@sunroof.eng.sun.com Subject: Re: ICMPv6 error messages In-reply-to: Your message of Tue, 10 Jun 2003 16:32:39 +0530. <000501c32f3f$cf5c8ca0$4906140a@future.futsoft.com> Date: Tue, 10 Jun 2003 20:21:00 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: ICMPv6 RFC states that, ICMPv6 error message MUST NOT be sent as result of receiving a packet sent as link-layer multicast or broadcast. But why should IPv6 be concerned about the Link-Layer address? => simply to avoid some trivial DoS attacks... 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 Wed Jun 11 01:12:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5B8CLTX023699; Wed, 11 Jun 2003 01:12:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5B8CLLK023698; Wed, 11 Jun 2003 01:12:21 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5B8CITX023691 for ; Wed, 11 Jun 2003 01:12:18 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5B8ATuc019668 for ; Wed, 11 Jun 2003 01:10:30 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5B898ht027773 for ; Wed, 11 Jun 2003 02:09:21 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h5B890d01896; Wed, 11 Jun 2003 15:09:01 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5B88Me01565; Wed, 11 Jun 2003 15:08:22 +0700 (ICT) From: Robert Elz To: Alain Durand cc: awhite@arc.corp.mot.com, IPng Subject: Re: Status of In-Reply-To: <3EE619C9.7030204@sun.com> References: <3EE619C9.7030204@sun.com> <3EE4CEE4.7040200@sun.com> <3EDF034B.7D488005@motorola.com> <14586.1055245615@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Jun 2003 15:08:22 +0700 Message-ID: <1620.1055318902@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 10 Jun 2003 10:47:53 -0700 From: Alain Durand Message-ID: <3EE619C9.7030204@sun.com> | Reachability os one thing, but you may have to wait for TCP timeouts. | RFC1122, section 4.2.3.5 TCP Connection Failures | Says that the initial SYN has to wait at least 3 minutes... You're assuming that I am actually using a TCP SYN to detect reachability. That isn't the way it is done. We want to make things work well, not arbitrarily slow them down. 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 Wed Jun 11 01:22:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5B8MrTX023845; Wed, 11 Jun 2003 01:22:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5B8Mrmn023844; Wed, 11 Jun 2003 01:22:53 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5B8MoTX023837 for ; Wed, 11 Jun 2003 01:22:50 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5B8L1uc021611 for ; Wed, 11 Jun 2003 01:21:02 -0700 (PDT) Received: from kirk.rvdp.org (kirk.rvdp.org [80.126.101.63]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5B8KtWP018607 for ; Wed, 11 Jun 2003 02:20:56 -0600 (MDT) Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6p2/8.11.6) id h5B8Ksq04332 for ipng@sunroof.eng.sun.com; Wed, 11 Jun 2003 10:20:54 +0200 (CEST) Date: Wed, 11 Jun 2003 10:20:54 +0200 From: Ronald van der Pol To: ipng@sunroof.eng.sun.com Subject: status "Router Prefs, More-Specific Routes, and Load Sharing"? Message-ID: <20030611082054.GA4154@rvdp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One of the charter items is: Jun 03 Submit Router Preferences, More-Specific Routes, and Load Sharing to IESG for Proposed Standard draft-ietf-ipv6-router-selection-02.txt has expired in January 2003. What is the status of this work? rvdp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 01:48:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5B8mETX024127; Wed, 11 Jun 2003 01:48:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5B8mD0b024126; Wed, 11 Jun 2003 01:48:13 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5B8mATX024119 for ; Wed, 11 Jun 2003 01:48:10 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5B8kMNh021952 for ; Wed, 11 Jun 2003 01:46:22 -0700 (PDT) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5B8kFYU019603 for ; Wed, 11 Jun 2003 02:46:16 -0600 (MDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5B8jqZX013738 for ; Wed, 11 Jun 2003 10:45:53 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h5B8jjlf215302 for ; Wed, 11 Jun 2003 10:45:45 +0200 Received: from dhcp222-56.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58054 from ; Wed, 11 Jun 2003 10:45:43 +0200 Message-Id: <3EE6EC4E.D42D4D9C@hursley.ibm.com> Date: Wed, 11 Jun 2003 10:46:06 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: null-routed aggregated global unicast (was: another view of fc00::/7) References: <963621801C6D3E4A9CF454A1972AE8F504F870@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have no problem with it, but we don't have to do a thing in the IETF. It's a business decision for an ISP. I do prefer that the IETF defines a solution that doesn't rely on ISPs happening to see a business opportunity. Brian Michel Py wrote: > > jj, > > > Earlier, I suggested that an ISP could delegate addresses > > out of its existing aggregated, global unicast address block > > for free without providing connectivity. Having seen all of > > the email on this subject, I believe that such an ISP could > > actually sell prefixes for which it doesn't provide direct > > connectivity. Such addresses could be used for VPN's, etc. > > without fear of collision. Traffic destined to such addresses > > on the Internet would be aggregated to the ISP, and probably > > sent to /dev/null. > > I like this better than anything else I have seen to date. > > 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 Jun 11 07:36:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BEaZTX025264; Wed, 11 Jun 2003 07:36:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5BEaZrx025263; Wed, 11 Jun 2003 07:36:35 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BEaVTX025256 for ; Wed, 11 Jun 2003 07:36:31 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5BEYguc004024 for ; Wed, 11 Jun 2003 07:34:42 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5BEYb4Z015760 for ; Wed, 11 Jun 2003 07:34:37 -0700 (PDT) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h5BEYYsM055756; Wed, 11 Jun 2003 07:34:34 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h5BEYY49055755; Wed, 11 Jun 2003 07:34:34 -0700 (PDT) (envelope-from jj) Date: Wed, 11 Jun 2003 07:34:34 -0700 From: Shannon -jj Behrens To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: null-routed aggregated global unicast (was: another view of fc00::/7) Message-ID: <20030611143434.GB55659@alicia.nttmcl.com> References: <963621801C6D3E4A9CF454A1972AE8F504F870@server2000.arneill-py.sacramento.ca.us> <3EE6EC4E.D42D4D9C@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EE6EC4E.D42D4D9C@hursley.ibm.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Jun 11, 2003 at 10:46:06AM +0200, Brian E Carpenter wrote: > I have no problem with it, but we don't have to do a thing > in the IETF. It's a business decision for an ISP. I thought a BCP might be helpful. Afterall, the site-local debate probably won't go away until there's something in writing to replace it. > I do prefer that the IETF defines a solution that doesn't > rely on ISPs happening to see a business opportunity. Of course, but on the other hand, I wouldn't have Internet connectivity at home if some ISP didn't see a business opportunity in providing it. Best Regards, -jj -- Hacker is to software engineer as Climbing Mt. Everest is to building a Denny's there. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 08:16:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BFGhTX025657; Wed, 11 Jun 2003 08:16:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5BFGhOp025656; Wed, 11 Jun 2003 08:16:43 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BFGeTX025649 for ; Wed, 11 Jun 2003 08:16:40 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5BFEoNh016314 for ; Wed, 11 Jun 2003 08:14:50 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h5BFEe4Z012398 for ; Wed, 11 Jun 2003 08:14:45 -0700 (PDT) Subject: RE: Status of Date: Wed, 11 Jun 2003 08:15:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F875@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: Status of Thread-Index: AcMv8fBbYgOaRZ0rSz6l8KSWOg5jzAANhKDw From: "Michel Py" To: "Robert Elz" , "Alain Durand" Cc: "IPng" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5BFGeTX025650 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, | Alain Durand wrote: | Reachability os one thing, but you may have to wait for TCP timeouts. | RFC1122, section 4.2.3.5 TCP Connection Failures | Says that the initial SYN has to wait at least 3 minutes... > kre wrote: > You're assuming that I am actually using a TCP SYN to > detect reachability. That isn't the way it is done. We want > to make things work well, not arbitrarily slow them down. The problem is that the only way to _really_ test reachability is to actually try. For example, if you can successfully ping a host it does not mean that you can telnet to it (or the opposite: ICMP might be blocked and it might be the best path). Or if you can open an http connection on port 80 it does not mean that you can open an https one on port 443 (because someone forgot to open the port) or the opposite (because the network administrator wants to enforce an https-only web server). Note that I am not suggesting that the reachability discovery should be application specific, but OTOH I don't really see how it can't be. There might be a slippery slope that says to reduce the SYN delay, but I'm not buying into it. Look at SMTP for example: if you open a connection on port 25 to my mail server it is going to check your IP against a number of spam lists before returning the ACK. This takes time; if we put 100ms here it is broken. What Alain refers to is one of the reasons I stated earlier that we will continue to see split or dual-headed DNS, because if an app uses TCP as the transport mechanism, we are looking at either a SYN to detect reachability or at an app failure because the reachability detection mechanism used ICMP or UDP. In either case, we are looking at unacceptable delay. Delay leads to frustration. Frustration leads to split-DNS. 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 Jun 11 08:22:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BFMITX025757; Wed, 11 Jun 2003 08:22:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5BFMHQt025756; Wed, 11 Jun 2003 08:22:17 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BFMETX025749 for ; Wed, 11 Jun 2003 08:22:14 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5BFKPNh018270 for ; Wed, 11 Jun 2003 08:20:25 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5BFKAep024609 for ; Wed, 11 Jun 2003 09:20:15 -0600 (MDT) Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h5BFK1d11942; Wed, 11 Jun 2003 22:20:01 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5BFJQ410452; Wed, 11 Jun 2003 22:19:26 +0700 (ICT) From: Robert Elz To: "Michel Py" cc: "Alain Durand" , "IPng" Subject: Re: Status of In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F875@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F504F875@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Jun 2003 22:19:25 +0700 Message-ID: <11428.1055344765@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 11 Jun 2003 08:15:10 -0700 From: "Michel Py" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F875@server2000.arneill-py.sacramento.ca.us> | The problem is that the only way to _really_ test reachability is to | actually try. Of course - but what we're looking for here is a hint as to which address is likely to be best to try first. We don't need certainty for this, we just need an indication what is going to work (or is likely to be going to work). Having received that indication, we can then try the addresses in a sane order, instead of either random, or based upon the guesses of people here as to what is necessarily always going to work best for everyone. The only real proof of what works is the real connection open, and must remain that way. No-one wants to alter that. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 09:07:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BG7cTX026247; Wed, 11 Jun 2003 09:07:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5BG7cVb026246; Wed, 11 Jun 2003 09:07:38 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BG7YTX026239 for ; Wed, 11 Jun 2003 09:07:34 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5BG5jNh002216 for ; Wed, 11 Jun 2003 09:05:45 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5BG5eht012933 for ; Wed, 11 Jun 2003 10:05:40 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGB009DSRDFNF@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 11 Jun 2003 10:05:39 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGB00NP8RCZ0V@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 11 Jun 2003 10:05:25 -0600 (MDT) Date: Wed, 11 Jun 2003 09:07:14 -0700 From: Alain Durand Subject: Re: Status of In-reply-to: <1620.1055318902@munnari.OZ.AU> To: Robert Elz Cc: awhite@arc.corp.mot.com, IPng Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, June 11, 2003, at 01:08 AM, Robert Elz wrote: > Date: Tue, 10 Jun 2003 10:47:53 -0700 > From: Alain Durand > Message-ID: <3EE619C9.7030204@sun.com> > > | Reachability os one thing, but you may have to wait for TCP > timeouts. > | RFC1122, section 4.2.3.5 TCP Connection Failures > | Says that the initial SYN has to wait at least 3 minutes... > > You're assuming that I am actually using a TCP SYN to detect > reachability. That isn't the way it is done. We want to make > things work well, not arbitrarily slow them down. Then please explain us how do you do it, I'd be very happy to learn, especially in the case where some port on the destination host support v4 & v6 and some only support v4. - 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 Jun 11 10:42:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BHgvTX026880; Wed, 11 Jun 2003 10:42:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5BHgusX026879; Wed, 11 Jun 2003 10:42:56 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BHgrTX026872 for ; Wed, 11 Jun 2003 10:42:53 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5BHf4Nh006087 for ; Wed, 11 Jun 2003 10:41:04 -0700 (PDT) Received: from fuchsia.home (ip28.coe.tnet.co.th [203.146.155.28]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5BHeu4Z019829 for ; Wed, 11 Jun 2003 10:40:58 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h5BHe137000498; Thu, 12 Jun 2003 00:40:02 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5BHeAL04622; Thu, 12 Jun 2003 00:40:12 +0700 (ICT) From: Robert Elz To: Alain Durand cc: IPng Subject: Re: Status of In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Jun 2003 00:40:10 +0700 Message-ID: <3879.1055353210@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 11 Jun 2003 09:07:14 -0700 From: Alain Durand Message-ID: | Then please explain us how do you do it, I'd be very happy to learn, | especially in the case where some port on the destination host | support v4 & v6 and some only support v4. I'll do that sometime later (or send you something in private mail). But, I am only concerned with the v6 case - the decision to use a v6 address is assumed to have already been made. If that turns out to be incorrect, and a fallback to v4 is needed, that would happen just as you now imagine it happening (and all the variation I'm using would have changed is that perhaps some IPv6 addresses would have been ignored, but that's currently assuming "traditional" SL addressing, rather than the new form, and I'm not sure it will be able to survive - maybe in a variant form, that is going to take more work to establish). 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 Wed Jun 11 11:39:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BIdGTX027221; Wed, 11 Jun 2003 11:39:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5BIdGFP027220; Wed, 11 Jun 2003 11:39:16 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BIdBTX027210 for ; Wed, 11 Jun 2003 11:39:11 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5BIbMuc003005 for ; Wed, 11 Jun 2003 11:37:22 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5BIbHYU011004 for ; Wed, 11 Jun 2003 12:37:17 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGB009FLYE4NF@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 11 Jun 2003 12:37:16 -0600 (MDT) Received: from sun.com ([129.146.10.24]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGB00M47YE3ZP@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 11 Jun 2003 12:37:16 -0600 (MDT) Date: Wed, 11 Jun 2003 11:37:15 -0700 From: Alain Durand Subject: Re: Status of To: Robert Elz Cc: ipng@sunroof.eng.sun.com Message-id: <3EE776DB.7010606@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: <3879.1055353210@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > >But, I am only concerned with the v6 case - the decision to use a v6 >address is assumed to have already been made. > Unfortunately, this is not the way it works with default address selection. the src node is looking at the complete set of potential v4 & v6 src & dst addresses to make the decision. The apps is returned an "ordered" list that mix v4 & v6 addresses to try one after the other. - 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 Jun 11 12:41:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BJfhTX027586; Wed, 11 Jun 2003 12:41:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5BJfgmW027585; Wed, 11 Jun 2003 12:41:42 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BJfdTX027578 for ; Wed, 11 Jun 2003 12:41:39 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5BJdoNh022523 for ; Wed, 11 Jun 2003 12:39:50 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5BJdiWP024048 for ; Wed, 11 Jun 2003 13:39:45 -0600 (MDT) 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 MAA23772; Wed, 11 Jun 2003 12:39:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5BJdgc11046; Wed, 11 Jun 2003 12:39:42 -0700 X-mProtect: <200306111939> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdukzBvC; Wed, 11 Jun 2003 12:39:40 PDT Message-Id: <4.3.2.7.2.20030611094111.02c48e78@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Jun 2003 12:39:36 -0700 To: Shannon -jj Behrens From: Bob Hinden Subject: Re: null-routed aggregated global unicast (was: another view of fc00::/7) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20030610160432.GB36769@alicia.nttmcl.com> References: <1055233389.2165.3.camel@vega.amorsen.dk> <3EE324AF.8088F380@hursley.ibm.com> <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> <12722.1055095987@munnari.OZ.AU> <1055233389.2165.3.camel@vega.amorsen.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jj, At 09:04 AM 6/10/2003, Shannon -jj Behrens wrote: >Earlier, I suggested that an ISP could delegate addresses out of its >existing aggregated, global unicast address block for free without >providing connectivity. Having seen all of the email on this subject, >I believe that such an ISP could actually sell prefixes for which it >doesn't provide direct connectivity. Such addresses could be used for >VPN's, etc. without fear of collision. Traffic destined to such >addresses on the Internet would be aggregated to the ISP, and probably >sent to /dev/null. For an additional fee, the ISP could tunnel such >traffic back its customers. The prefixes would be sold for a fixed, >one-time fee. Is this just another form of a registry? Also, a lot of the motivation for this type of addresses was to get addresses that are provider independent. While they are not intended to be routable, the seem provider oriented to me. Also, it doesn't by itself, meet the need of people who want to be able to create a prefix locally. 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 Jun 11 13:25:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BKPjTX027916; Wed, 11 Jun 2003 13:25:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5BKPjhS027915; Wed, 11 Jun 2003 13:25:45 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BKPfTX027905 for ; Wed, 11 Jun 2003 13:25:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5BKNquc008897 for ; Wed, 11 Jun 2003 13:23:52 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5BKNl4Z007930 for ; Wed, 11 Jun 2003 13:23:47 -0700 (PDT) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h5BKNesM060381; Wed, 11 Jun 2003 13:23:40 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h5BKNeuq060380; Wed, 11 Jun 2003 13:23:40 -0700 (PDT) (envelope-from jj) Date: Wed, 11 Jun 2003 13:23:40 -0700 From: Shannon -jj Behrens To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: Re: null-routed aggregated global unicast (was: another view of fc00::/7) Message-ID: <20030611202340.GA59385@alicia.nttmcl.com> References: <1055233389.2165.3.camel@vega.amorsen.dk> <3EE324AF.8088F380@hursley.ibm.com> <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> <12722.1055095987@munnari.OZ.AU> <1055233389.2165.3.camel@vega.amorsen.dk> <4.3.2.7.2.20030611094111.02c48e78@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030611094111.02c48e78@mailhost.iprg.nokia.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Jun 11, 2003 at 12:39:36PM -0700, Bob Hinden wrote: > Is this just another form of a registry? Yes. However, I think that it's more likely to succeed than our previous registry ideas because the addresses come from the aggregated, global unicast address space. Thus, there can be no arguments about who owns what addresses. If I buy a prefix from Earthlink, it comes from Earthlink's address block. Outsiders can't even tell it's not a normal prefix (which is a blessing and a curse), let alone state that they also purchased the prefix from some other ISP. > Also, a lot of the motivation for > this type of addresses was to get addresses that are provider > independent. While they are not intended to be routable, the seem provider > oriented to me. It's true that they're not completely provider independent. On the other hand, once you have purchase the prefix, you don't need to associate with the ISP again (assuming they don't have recurring fees). Naturally, you'll want a legal contract that says the ISP can't revoke the allocation, etc. You're free to use the prefix in any way you want, which matches the spirit of provider-independent, non-routable addresses. In particular, the ISP you buy these addresses from probably isn't your carrier. > Also, it doesn't by itself, meet the need of people who want to be able to > create a prefix locally. That's true. I'm not trying to solve that problem since there are other reasonable solutions in the works for that problem. My solution is more appropriate for managed networks who really want completely unique addresses. Best Regards, -jj -- Hacker is to software engineer as Climbing Mt. Everest is to building a Denny's there. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 13:56:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BKuLTX028573; Wed, 11 Jun 2003 13:56:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5BKuL83028572; Wed, 11 Jun 2003 13:56:21 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BKuHTX028565 for ; Wed, 11 Jun 2003 13:56:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5BKsTNh017498 for ; Wed, 11 Jun 2003 13:54:29 -0700 (PDT) Received: from ursa.amorsen.dk (x1-6-00-e0-28-13-bf-45.k32.webspeed.dk [195.41.138.12]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5BKsM4Z023861 for ; Wed, 11 Jun 2003 13:54:23 -0700 (PDT) Received: from vega.amorsen.dk (vega.amorsen.dk [172.31.4.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ursa.amorsen.dk (Postfix) with ESMTP id D2F3E1C1EC; Wed, 11 Jun 2003 22:54:20 +0200 (CEST) Subject: Re: null-routed aggregated global unicast (was: another view of fc00::/7) From: Benny Amorsen To: Shannon -jj Behrens Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: <20030611202340.GA59385@alicia.nttmcl.com> References: <1055233389.2165.3.camel@vega.amorsen.dk> <3EE324AF.8088F380@hursley.ibm.com> <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> <12722.1055095987@munnari.OZ.AU> <1055233389.2165.3.camel@vega.amorsen.dk> <4.3.2.7.2.20030611094111.02c48e78@mailhost.iprg.nokia.com> <20030611202340.GA59385@alicia.nttmcl.com> Content-Type: text/plain Message-Id: <1055364856.2165.15.camel@vega.amorsen.dk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (1.3.92-1) (Preview Release) Date: 11 Jun 2003 22:54:17 +0200 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 2003-06-11 at 22:23, Shannon -jj Behrens wrote: > Outsiders can't even tell it's not a normal prefix (which is a > blessing and a curse), let alone state that they also purchased the > prefix from some other ISP. I think that is a curse. It means that in normal circumstances I can expect to see what was supposed to be my unique addresses advertised by routing protocols as part of a larger aggregated space. However, this is something that will happen no matter what anyone says. I would just prefer that /my/ non-routable addresses stayed out of the global routing tables. /Benny -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 14:07:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BL7STX028739; Wed, 11 Jun 2003 14:07:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5BL7SCm028738; Wed, 11 Jun 2003 14:07:28 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5BL7OTX028731 for ; Wed, 11 Jun 2003 14:07:25 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5BL5Zuc024617 for ; Wed, 11 Jun 2003 14:05:36 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5BL5UYU007154 for ; Wed, 11 Jun 2003 15:05:30 -0600 (MDT) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h5BL5NsM060951; Wed, 11 Jun 2003 14:05:24 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h5BL5NFu060950; Wed, 11 Jun 2003 14:05:23 -0700 (PDT) (envelope-from jj) Date: Wed, 11 Jun 2003 14:05:23 -0700 From: Shannon -jj Behrens To: Benny Amorsen Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: null-routed aggregated global unicast (was: another view of fc00::/7) Message-ID: <20030611210523.GA60437@alicia.nttmcl.com> References: <1055233389.2165.3.camel@vega.amorsen.dk> <3EE324AF.8088F380@hursley.ibm.com> <963621801C6D3E4A9CF454A1972AE8F504F867@server2000.arneill-py.sacramento.ca.us> <12722.1055095987@munnari.OZ.AU> <1055233389.2165.3.camel@vega.amorsen.dk> <4.3.2.7.2.20030611094111.02c48e78@mailhost.iprg.nokia.com> <20030611202340.GA59385@alicia.nttmcl.com> <1055364856.2165.15.camel@vega.amorsen.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1055364856.2165.15.camel@vega.amorsen.dk> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Jun 11, 2003 at 10:54:17PM +0200, Benny Amorsen wrote: > On 2003-06-11 at 22:23, Shannon -jj Behrens wrote: > > > Outsiders can't even tell it's not a normal prefix (which is a > > blessing and a curse), let alone state that they also purchased the > > prefix from some other ISP. > > I think that is a curse. As I mentioned earlier, the harder problem is that there isn't an easily recognizeable prefix such as fec0 that stacks and firewalls can give special treatment to. > It means that in normal circumstances I can > expect to see what was supposed to be my unique addresses advertised by > routing protocols as part of a larger aggregated space. That's true. However, (please forgive me naivete concerning routing) you'll just have to use a more specific route for your own usage of those unique addresses. > However, this is something that will happen no matter what anyone says. > I would just prefer that /my/ non-routable addresses stayed out of the > global routing tables. Several people such as yourself (e.g. Michele Py) have suggested that "local" addresses will be advertised no matter what. Others have stated that there is no such thing as unique unless there's a route in the DFZ to prove the uniqueness (e.g. kre, if I remember right). My solution simply takes the lemons and makes lemonade. Best Regards, -jj -- Hacker is to software engineer as Climbing Mt. Everest is to building a Denny's there. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 23:10:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5C6ASTX000413; Wed, 11 Jun 2003 23:10:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5C6ASSa000412; Wed, 11 Jun 2003 23:10:28 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5C6APTX000405 for ; Wed, 11 Jun 2003 23:10:25 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5C68ZNh002148 for ; Wed, 11 Jun 2003 23:08:36 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5C68TYU016599 for ; Thu, 12 Jun 2003 00:08:30 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h5C68CS07216; Thu, 12 Jun 2003 09:08:13 +0300 Date: Thu, 12 Jun 2003 09:08:12 +0300 (EEST) From: Pekka Savola To: Shannon -jj Behrens cc: Bob Hinden , Subject: Re: null-routed aggregated global unicast (was: another view of fc00::/7) In-Reply-To: <20030611202340.GA59385@alicia.nttmcl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 11 Jun 2003, Shannon -jj Behrens wrote: > On Wed, Jun 11, 2003 at 12:39:36PM -0700, Bob Hinden wrote: > > Is this just another form of a registry? > > Yes. However, I think that it's more likely to succeed than our > previous registry ideas because the addresses come from the > aggregated, global unicast address space. Thus, there can be no > arguments about who owns what addresses. If I buy a prefix from > Earthlink, it comes from Earthlink's address block. Outsiders can't > even tell it's not a normal prefix (which is a blessing and a curse), > let alone state that they also purchased the prefix from some other > ISP. With current RIR rules, *no* ISP can give an absolute guarantee that it's prefix couldn't, at one point, be pulled off. So, it seems to me that creating implicit assumption that addresses allocated today from RIR's are "magical" and "will never be revoked", and "the ISP can give legal guarantees the prefix will never clash". It seems to me that *practically*, recurring fees are a feature. If an ISP goes bankrupt, some other ISP actually has an incentive to obtain its business and the prefix -- in hope of getting a share of those recurring fees :-). Otherwise, the prefix could just rot and be returned to RIR (for example). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 00:38:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5C7cwTX000998; Thu, 12 Jun 2003 00:38:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5C7cvOA000997; Thu, 12 Jun 2003 00:38:57 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5C7csTX000990 for ; Thu, 12 Jun 2003 00:38:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5C7b3uc026976 for ; Thu, 12 Jun 2003 00:37:03 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h5C7awLv017515 for ; Thu, 12 Jun 2003 00:36:58 -0700 (PDT) Subject: RE: null-routed aggregated global unicast (was: another view offc00::/7) MIME-Version: 1.0 Date: Thu, 12 Jun 2003 00:37:29 -0700 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F87C@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: null-routed aggregated global unicast (was: another view offc00::/7) Thread-Index: AcMwXI9p7RL05wicTyuAyUEvaBr8ugAU1sFQ From: "Michel Py" To: "Shannon -jj Behrens" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5C7csTX000991 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Benny, >> jj wrote: >> Outsiders can't even tell it's not a normal prefix (which is >> a blessing and a curse), let alone state that they also >> purchased the prefix from some other ISP. > Benny Amorsen wrote: > I think that is a curse. It means that in normal circumstances > I can expect to see what was supposed to be my unique addresses > advertised by routing protocols as part of a larger aggregated > space. A curse it is but a blessing it is also. Look from the other prospective: I'm the ISP that provides you the block: - I give you a /48 out of my /32. The /32 costs me 2.5k/yr so the /48 costs me $0.04/yr plus overhead. BFD. - When we get out of this "everyone-gives-free-transit-to-everyone" business model which does not make sense, I don't want to pay for your traffic because what I sold you or gave you is the address, not the bandwidth. So I reserved a /36 out of my /32 for people like you and I route it directly to null0. - Why is this a blessing? Because there will be enough people that filter longer prefixes. What we are talking here is private addresses. So if you peer with a business partner and they get a specific route to the /48 I gave you, fine. Otherwise, it does not matter if the traffic goes into an unreachable or if it goes into my null0, and there are a fair amount of people that says it's preferable to route traffic that you want to go nowhere into a blackhole instead of bouncing it. > I would just prefer that /my/ non-routable addresses stayed > out of the global routing tables. Look back from your own prospective again: What you want is your /48 not to be there; if a /32 that encompasses your /48 is announced and if the /36 that encompasses your /48 is routed to null0 at the destination, it's a blessing. 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 Jun 12 00:52:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5C7qoTX001208; Thu, 12 Jun 2003 00:52:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5C7qnoV001207; Thu, 12 Jun 2003 00:52:49 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5C7qkTX001200 for ; Thu, 12 Jun 2003 00:52:46 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5C7ouNh029024 for ; Thu, 12 Jun 2003 00:50:56 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5C7ooht014027 for ; Thu, 12 Jun 2003 01:50:51 -0600 (MDT) Subject: RE: null-routed aggregated global unicast (was: another view of fc00::/7) MIME-Version: 1.0 Date: Thu, 12 Jun 2003 00:51:21 -0700 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F50671E7@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: null-routed aggregated global unicast (was: another view of fc00::/7) Thread-Index: AcMwXgWF6HuttdalS86iyUqF9iOQLwAWP/KA From: "Michel Py" To: "Shannon -jj Behrens" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5C7qkTX001201 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > jj wrote: > Several people such as yourself (e.g. Michele Py) have > suggested that "local" addresses will be advertised no > matter what. _IF_ they have a global scope or are handled as global. > My solution simply takes the lemons and makes lemonade. That's why I like it. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 00:59:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5C7xZTX001364; Thu, 12 Jun 2003 00:59:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5C7xZYQ001363; Thu, 12 Jun 2003 00:59:35 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5C7xRTX001346 for ; Thu, 12 Jun 2003 00:59:27 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5C7vbuc001623 for ; Thu, 12 Jun 2003 00:57:38 -0700 (PDT) Received: from mail.64translator.com (94.180.32.202.ts.2iij.net [202.32.180.94]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5C7vVWP001978 for ; Thu, 12 Jun 2003 01:57:32 -0600 (MDT) Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.6p2/8.12.6) with ESMTP id h5C7vUqN055411 for ; Thu, 12 Jun 2003 16:57:30 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Received: from localhost (dhcp156.64translator.com [10.21.32.156]) by bahamas.64translator.com (8.12.8/8.12.8) with SMTP id h5C7vO8d027293 for ; Thu, 12 Jun 2003 16:57:24 +0900 (JST) Date: Thu, 12 Jun 2003 16:57:09 +0900 From: Yukiyo Akisada To: ipng@sunroof.eng.sun.com Subject: the newest TAHI conformance test tool is available Message-Id: <20030612165709.251ab60f.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i386-portbld-freebsd4.7) 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, folks. Now, we (TAHI Project) have released version 2.1.1 of conformance test suites. You can get them from our web site. http://www.tahi.org/release/ And our contact point is . Changes from Release 2.0.2 ---------------------------------------------------------------- * Add New tests: o Mobility Support in IPv6 + draft-ietf-mobileip-ipv6-20.txt MN test is contributed by Linux Technology Center, IBM o Prefix Delegation + draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt o DNS Discovery + draft-ietf-ipv6-dns-discovery-07.txt o Default Router Preferences, More-Specific Routes, and Load Sharing + draft-ietf-ipv6-router-selection-02.txt o Default Address Selection for Internet Protocol version 6 (IPv6) + RFC 3484 * Support new packet format: o RIPng + RFC 2080 - RIPng for IPv6 o DNS + RFC 1035 - Domain Implementation and Specification + RFC 1183 - New DNS RR Definitions + RFC 1664 - Internet DNS for Mail Mapping Tables + RFC 1886 - IPv6 DNS Extensions + RFC 2782 - DNS SRV RR + RFC 2915 - NAPTR DNS RR o DHCPv6 + draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt + draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt + draft-ietf-dhc-dhcpv6-28.txt + draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt o MIPv6 ID-21 + draft-ietf-mobileip-ipv6-21.txt o Modified Router Advertisement & Route Information Option + draft-ietf-ipv6-router-selection-02.txt * Support gcc 3.X * Support FreeBSD 5.0-RELEASE Thanks. ---- 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 Thu Jun 12 02:11:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5C9BxTX002015; Thu, 12 Jun 2003 02:11:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5C9Bwn5002014; Thu, 12 Jun 2003 02:11:58 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5C9BtTX002007 for ; Thu, 12 Jun 2003 02:11:55 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5C9A6uc018544 for ; Thu, 12 Jun 2003 02:10:06 -0700 (PDT) Received: from bigbear.ipservice.dk (lion2.ipservice.dk [212.242.77.2]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5C9A04Z024214 for ; Thu, 12 Jun 2003 02:10:00 -0700 (PDT) Received: from vega.amorsen.dk ([10.0.0.235]) by bigbear.ipservice.dk (8.12.5/8.12.5) with ESMTP id h5C9BmsK027608; Thu, 12 Jun 2003 11:11:49 +0200 Subject: RE: null-routed aggregated global unicast (was: another view offc00::/7) From: Benny Amorsen To: Michel Py Cc: Shannon -jj Behrens , ipng@sunroof.eng.sun.com In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F87C@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F504F87C@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain Message-Id: <1055408941.1396.4.camel@vega.amorsen.dk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (1.3.92-1) (Preview Release) Date: 12 Jun 2003 11:09:02 +0200 Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 2003-06-12 at 09:37, Michel Py wrote: > Look back from your own prospective again: > What you want is your /48 not to be there; if a /32 that encompasses > your /48 is announced and if the /36 that encompasses your /48 is routed > to null0 at the destination, it's a blessing. It seems to me that having a global blackholed /10 is a lot nicer to the routing table than a lot of blackholed /36's. Perhaps routers have advanced to the state where this is no longer a significant concern. /Benny -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 07:35:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5CEZkTX003075; Thu, 12 Jun 2003 07:35:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5CEZk0r003074; Thu, 12 Jun 2003 07:35:46 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5CEZhTX003067 for ; Thu, 12 Jun 2003 07:35:43 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5CEXrNh027955 for ; Thu, 12 Jun 2003 07:33:54 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5CEXmYU009028 for ; Thu, 12 Jun 2003 08:33:48 -0600 (MDT) Subject: RE: null-routed aggregated global unicast (was: another viewoffc00::/7) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jun 2003 07:34:19 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F50671ED@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: null-routed aggregated global unicast (was: another viewoffc00::/7) Thread-Index: AcMwwm5qWGD2iN+jSCuNWQ3eK5/EwAAKo7dA From: "Michel Py" To: Cc: "Shannon -jj Behrens" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5CEZhTX003068 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Benny, > Benny Amorsen wrote: > It seems to me that having a global blackholed /10 is a lot > nicer to the routing table than a lot of blackholed /36's. No argument about this, but the catch is that this /10 being blackholed relies on the cooperation of lots of people, and this won't hold against pressures to break aggregation. We can't assume than everyone is going to play ball just because we say it. > Perhaps routers have advanced to the state where this is no > longer a significant concern. Have a look at this: http://arneill-py.sacramento.ca.us/ipv6mh/j.ppt http://arneill-py.sacramento.ca.us/ipv6mh/j.pdf (I isolated that one slide part of a much larger presentation) http://arneill-py.sacramento.ca.us/ipv6mh/IPv6%20Transition.ppt Vendor "J" says they can't guarantee that throwing more memory and CPU in the routers is going to be enough. When I design a large network, I like guarantees and not "perhaps". 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 Jun 12 09:36:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5CGabTX003907; Thu, 12 Jun 2003 09:36:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5CGaaSU003906; Thu, 12 Jun 2003 09:36:36 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5CGaXTX003899 for ; Thu, 12 Jun 2003 09:36:33 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5CGYiuc028345 for ; Thu, 12 Jun 2003 09:34:45 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5CGYdep015500 for ; Thu, 12 Jun 2003 10:34:39 -0600 (MDT) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h5CGYOsM076072; Thu, 12 Jun 2003 09:34:24 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h5CGYOdC076071; Thu, 12 Jun 2003 09:34:24 -0700 (PDT) (envelope-from jj) Date: Thu, 12 Jun 2003 09:34:23 -0700 From: Shannon -jj Behrens To: Benny Amorsen Cc: Michel Py , ipng@sunroof.eng.sun.com Subject: Re: null-routed aggregated global unicast (was: another view offc00::/7) Message-ID: <20030612163423.GC75749@alicia.nttmcl.com> References: <963621801C6D3E4A9CF454A1972AE8F504F87C@server2000.arneill-py.sacramento.ca.us> <1055408941.1396.4.camel@vega.amorsen.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1055408941.1396.4.camel@vega.amorsen.dk> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Jun 12, 2003 at 11:09:02AM +0200, Benny Amorsen wrote: > It seems to me that having a global blackholed /10 is a lot nicer to the > routing table than a lot of blackholed /36's. It would be nice if there were only one global blackholed /10, but the blackholed /36's don't have to be in the global routing table. Hence, it's not a big deal. > Perhaps routers have advanced to the state where this is no longer a > significant concern. If that were really the case, then we could use PI ;) -jj -- Hacker is to software engineer as Climbing Mt. Everest is to building a Denny's there. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 10:29:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5CHTnTX004185; Thu, 12 Jun 2003 10:29:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5CHTmqu004184; Thu, 12 Jun 2003 10:29:48 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5CHTjTX004177 for ; Thu, 12 Jun 2003 10:29:45 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5CHRuuc019044 for ; Thu, 12 Jun 2003 10:27:56 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5CHRnht027445 for ; Thu, 12 Jun 2003 11:27:50 -0600 (MDT) 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 KAA21817; Thu, 12 Jun 2003 10:27:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5CHRhd27673; Thu, 12 Jun 2003 10:27:43 -0700 X-mProtect: <200306121727> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6BOQQA; Thu, 12 Jun 2003 10:27:40 PDT Message-Id: <4.3.2.7.2.20030612095931.031d9a00@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Jun 2003 10:27:35 -0700 To: Pekka Savola From: Bob Hinden Subject: Re: null-routed aggregated global unicast (was: another view of fc00::/7) Cc: In-Reply-To: References: <20030611202340.GA59385@alicia.nttmcl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Good points. >With current RIR rules, *no* ISP can give an absolute guarantee that it's >prefix couldn't, at one point, be pulled off. That is consistent with my understanding of the RIR policies. I think they go to some length to make it clear that the prefixes allocated to an ISP are not owned by the ISP and to their customers. For example section 4.1 of RIPE267 http://www.ripe.net/ripe/docs/ipv6policy.html 4.1. Address space not to be considered property It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property. The policies in this document are based upon the understanding that globally unique IPv6 unicast address space is licensed for use rather than owned. Specifically, IP addresses will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. ..... >So, it seems to me that creating implicit assumption that addresses >allocated today from RIR's are "magical" and "will never be revoked", and >"the ISP can give legal guarantees the prefix will never clash". > >It seems to me that *practically*, recurring fees are a feature. If an >ISP goes bankrupt, some other ISP actually has an incentive to obtain its >business and the prefix -- in hope of getting a share of those recurring >fees :-). Otherwise, the prefix could just rot and be returned to RIR >(for example). In this case there is also the problem that if the contact information for the allocation is lost or out of date, then it will be difficult for whoever obtains the assets of the bankrupt ISP to determine if the allocation is still in use. Consequently there is a reasonable likelihood that it will be reassigned to someone else and made routable. The more I think about it the less I like the idea that prefixes from the globally routable address space will be used for local addressing. I understand there isn't anything that can stop this from happening occasionally, but I strongly doubt that it would ever become official RIR policy. 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 Thu Jun 12 11:49:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5CInmTX004711; Thu, 12 Jun 2003 11:49:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5CInmSf004710; Thu, 12 Jun 2003 11:49:48 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5CInjTX004703 for ; Thu, 12 Jun 2003 11:49:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5CIluNh026225 for ; Thu, 12 Jun 2003 11:47:56 -0700 (PDT) Received: from mx-relay1.net.treas.gov (mx-relay1.treas.gov [199.196.144.5]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5CIlkLv023055 for ; Thu, 12 Jun 2003 11:47:46 -0700 (PDT) Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14]) by mx-relay1.net.treas.gov (8.12.9/8.12.9) with SMTP id h5CIlgGE022775 for ; Thu, 12 Jun 2003 14:47:42 -0400 (EDT) Received: from no.name.available by tias4.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 12 Jun 2003 18:47:42 UT Received: from notes.tcs.treas.gov (localhost [127.0.0.1]) by mailhub-3.net.treas.gov (8.12.9/8.12.9) with ESMTP id h5CIlaDZ025327 for ; Thu, 12 Jun 2003 14:47:36 -0400 (EDT) X-Authentication-Warning: mailhub-3.net.treas.gov: iscan owned process doing -bs Sensitivity: Subject: Re: the newest TAHI conformance test tool is available To: ipng@sunroof.eng.sun.com From: John_Anderjaska@notes.tcs.treas.gov Date: Thu, 12 Jun 2003 14:47:35 -0400 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can anyone point me in the direction of some good white papers on mobility support in IPv6? We are doing some strategic planning wrt IPv6 for a 300,000 user network and the mobile computing area may be a logical entry point. Thanks .. John Anderjaska Sr Principal Consultant Comnet Technologies, Inc. www.comnet-tech.com Yukiyo Akisada @sunroof.eng.sun.com on 06/12/2003 03:57:09 AM Sent by: owner-ipng@sunroof.eng.sun.com To: ipng@sunroof.eng.sun.com cc: Subject: the newest TAHI conformance test tool is available Hi, folks. Now, we (TAHI Project) have released version 2.1.1 of conformance test suites. You can get them from our web site. http://www.tahi.org/release/ And our contact point is . Changes from Release 2.0.2 ---------------------------------------------------------------- * Add New tests: o Mobility Support in IPv6 + draft-ietf-mobileip-ipv6-20.txt MN test is contributed by Linux Technology Center, IBM o Prefix Delegation + draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt o DNS Discovery + draft-ietf-ipv6-dns-discovery-07.txt o Default Router Preferences, More-Specific Routes, and Load Sharing + draft-ietf-ipv6-router-selection-02.txt o Default Address Selection for Internet Protocol version 6 (IPv6) + RFC 3484 * Support new packet format: o RIPng + RFC 2080 - RIPng for IPv6 o DNS + RFC 1035 - Domain Implementation and Specification + RFC 1183 - New DNS RR Definitions + RFC 1664 - Internet DNS for Mail Mapping Tables + RFC 1886 - IPv6 DNS Extensions + RFC 2782 - DNS SRV RR + RFC 2915 - NAPTR DNS RR o DHCPv6 + draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt + draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt + draft-ietf-dhc-dhcpv6-28.txt + draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt o MIPv6 ID-21 + draft-ietf-mobileip-ipv6-21.txt o Modified Router Advertisement & Route Information Option + draft-ietf-ipv6-router-selection-02.txt * Support gcc 3.X * Support FreeBSD 5.0-RELEASE Thanks. ---- 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 13 14:26:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5DLQuTX008052; Fri, 13 Jun 2003 14:26:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5DLQu9L008051; Fri, 13 Jun 2003 14:26:56 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5DLQrTX008044 for ; Fri, 13 Jun 2003 14:26:53 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5DLP2uc016410 for ; Fri, 13 Jun 2003 14:25:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5DLOvep018299 for ; Fri, 13 Jun 2003 15:24:57 -0600 (MDT) 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 OAA22863 for ; Fri, 13 Jun 2003 14:24:56 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5DLOtL26864; Fri, 13 Jun 2003 14:24:55 -0700 X-mProtect: <200306132124> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdH9WTxl; Fri, 13 Jun 2003 14:24:53 PDT Message-Id: <4.3.2.7.2.20030613141645.02c59e18@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Jun 2003 14:24:45 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Fwd: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI. Changes include: o Added section on scope definition and updated application requirement section. o Clarified that, by default, the scope of these addresses is global. o Renumbered sections and general text improvements o Removed reserved global ID values o Split Global ID values into centrally assigned and local assignments and added text to describe local assignments o Added pseudo code for local allocation submitted by Brian Haberman and added him as an author. The draft continues the use of the FC00::/7 prefix as I didn't see (as the author) a clear consensus to change it. Bob >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt >Date: Fri, 13 Jun 2003 07:51:35 -0400 > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Globally Unique IPv6 Local Unicast Addresses > Author(s) : R. Hinden > Filename : draft-hinden-ipv6-global-local-addr-01.txt > Pages : 13 > Date : 2003-6-12 > >This document defines an unicast address format that is globally >unique and is intended for local communications, usually inside of a >site. They are not expected to be routable on the global Internet >given current routing technology. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hinden-ipv6-global-local-addr-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-hinden-ipv6-global-local-addr-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-hinden-ipv6-global-local-addr-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. >Content-Type: text/plain >Content-ID: <2003-6-12140033.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-hinden-ipv6-global-local-addr-01.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 Sun Jun 15 14:30:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5FLUJj0000800; Sun, 15 Jun 2003 14:30:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5FLUJEv000799; Sun, 15 Jun 2003 14:30:19 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5FLUFj0000790 for ; Sun, 15 Jun 2003 14:30:16 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5FHEGNh027446 for ; Sun, 15 Jun 2003 10:14:16 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5FHEAWP002567 for ; Sun, 15 Jun 2003 11:14:10 -0600 (MDT) 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 KAA22546 for ; Sun, 15 Jun 2003 10:14:10 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5FHE9S03311 for ; Sun, 15 Jun 2003 10:14:09 -0700 X-mProtect: <200306151714> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (209.157.142.164, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPIbKSa; Sun, 15 Jun 2003 10:14:08 PDT Message-Id: <4.3.2.7.2.20030615101341.02ccb508@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 15 Jun 2003 10:13:58 -0700 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 1 2 3 4 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 16 22:24:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5H5Owxq003461; Mon, 16 Jun 2003 22:24:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5H5OwF3003460; Mon, 16 Jun 2003 22:24:58 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5H5Osxq003453 for ; Mon, 16 Jun 2003 22:24:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5H5OsGq018501 for ; Mon, 16 Jun 2003 22:24:54 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5H5OiLv002944 for ; Mon, 16 Jun 2003 22:24:47 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 17 Jun 2003 11:04:42 +0530 Received: from sivarka (sivarka.future.futsoft.com [10.20.6.73]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h5H5K0nI013519 for ; Tue, 17 Jun 2003 10:50:00 +0530 Reply-To: From: "Sivaramakrishnan A" To: Subject: Checking IPv6 MAC Address Date: Tue, 17 Jun 2003 10:52:09 +0530 Message-Id: <000601c33490$66cdbc80$4906140a@future.futsoft.com> MIME-Version: 1.0 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.00.2919.6600 In-Reply-To: <0b1001c2f993$bd084620$8500a8c0@repligate> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I need to check if the MAC Address of an IPv6 packet is Multicast or Broadcast MAC Address? What are the Bits in the MAC Address that needs to be verified for this purpose? thanks and regards, Siva *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. 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 using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 17 04:16:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HBGPxq005348; Tue, 17 Jun 2003 04:16:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5HBGPtW005347; Tue, 17 Jun 2003 04:16:25 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HBGKxq005329 for ; Tue, 17 Jun 2003 04:16:20 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5HBEQGq018628 for ; Tue, 17 Jun 2003 04:14:26 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5HBEJYU014083 for ; Tue, 17 Jun 2003 05:14:20 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5HBEI929576 for ; Tue, 17 Jun 2003 14:14:18 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 17 Jun 2003 14:14:13 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 17 Jun 2003 14:14:12 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 17 Jun 2003 14:14:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Next steps on the IPv6 Node requirements draft Date: Tue, 17 Jun 2003 14:14:12 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next steps on the IPv6 Node requirements draft Thread-Index: AcM0wZSX2O2xvxNRRHqf54QPl99YjA== From: To: X-OriginalArrivalTime: 17 Jun 2003 11:14:12.0645 (UTC) FILETIME=[94CF4550:01C334C1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5HBGKxq005330 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I've updated the draft on 4 major points that were discussed at the IETF. Roughly they cover stateful address autoconfig support, DHCP support, MIPv6 support and DES support. I want to get a sense of the WG, if it would be OK to send the updated draft out and ask for a WG last call. I have an issue tracker created, to help out on the WG last call that I would like to use (http://danforsberg.info:8080/draft-ietf-ipv6-node-requirements/index) and I'd probably like to get some expert reviews, especially for the security sections. What does the group think? If it is OK with the WG, I could send the updated draft out by the end of the week. I have included the text that I have updated at the end of the mail. thanks, John 1) Stateful Address Autoconfiguration text: Stateful Address Autoconfiguration MAY be supported. DHCP [DHCPv6] is the standard stateful address configuration protocol, see section 5.3 for DHCPv6 support. For nodes which do not support Stateful Address Autoconfiguration, the node may be unable to obtain any IPv6 addresses aside from link-local addresses when it receives a router advertisement with the 'M' flag (Managed address configuration) set and which contains no prefixes advertised for Stateless Address Autoconfiguration (see section 4.5.2). 2) Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Updated to: 5.3.1 Managed Address Configuration An IPv6 node that does not include an implementation of DHCP will be unable to obtain any IPv6 addresses aside from link-local addresses when it is connected to a link over which it receives a router advertisement with the 'M' flag (Managed address configuration) set and which contains no prefixes advertised for Stateless Address Autoconfiguration (see section 4.5.2). An IPv6 node that receives a router advertisement with the 'M' flag set and that contains advertised prefixes will configure interfaces with both stateless autoconfiguration addresses and addresses obtained through DHCP. For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. An IPv6 node that does not include an implementation of DHCP will be unable to dynamically obtain any IPv6 addresses aside from link-local addresses when it is connected to a link over which it receives a router advertisement with the 'M' flag (Managed address configuration) set and which contains no prefixes advertised for Stateless Address Autoconfiguration (see section 4.5.2). In this situation, the IPv6 Node will be unable to communicate with other off-link nodes unless a global or site-local IPv6 address is manually configured. 5.3.2 Other stateful configuration DHCP provides the ability to provide other configuration information to the node. An IPv6 node that does not include an implementation of DHCP will be unable to obtain other configuration information such as the addresses of DNS servers when it is connected to a link over which the node receives a router advertisement in which the 'O' flag ("Other stateful configuration") is set. For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'O' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, hosts that implement DHCP MUST attempt to use DHCP. For IPv6 Nodes that do not implement DHCP, the 'O' flag of a Router Advertisement can be ignored. Furthermore, in the absence of a router, this type of node is not required to initiate DHCP. 3) Mobile IP requirements for routers updated to: Routers SHOULD support mobile IP requirements. 4) DES support removed: The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD NOT be supported. Security issues related to the use of DES are discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as required by the existing IPsec RFCs, but as it is currently viewed as an inherently weak algorithm, and no longer fulfills its intended role. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 17 08:12:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HFCAxq007439; Tue, 17 Jun 2003 08:12:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5HFCA6G007438; Tue, 17 Jun 2003 08:12:10 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HFC7xq007431 for ; Tue, 17 Jun 2003 08:12:07 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5HFADNh002192 for ; Tue, 17 Jun 2003 08:10:13 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h5HFA84Z004473 for ; Tue, 17 Jun 2003 08:10:08 -0700 (PDT) Subject: RE: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt Date: Tue, 17 Jun 2003 08:10:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F898@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt Thread-Index: AcMx80NV/pLeVF3fQwe/hLauUIB/ogC67IgQ From: "Michel Py" To: "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5HFC7xq007432 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, You could as well call this draft the IPv6 swamp creation act. If these addresses can be routed on point-to-point links or VPNs between sites, they can be routed on the public Internet and since everyone wants portable PI they will. >From the site's point of view, this is an easy decision: if the site wants portable address space, first they will get this for $10 one-time, then instead of paying the RIR $2.5k/year for the space, the site will simply allocate this money paying $2.5k/year to their ISP to leak their /48 in the GRT and $2.5k/year is enough for ISPs to leak it. Not only this creates the IPv6 swamp but it also puts the RIRs out of business. 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 Jun 17 08:49:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HFnJxq007817; Tue, 17 Jun 2003 08:49:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5HFnJ4k007816; Tue, 17 Jun 2003 08:49:19 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HFnFxq007809 for ; Tue, 17 Jun 2003 08:49:15 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5HFlLNh013677 for ; Tue, 17 Jun 2003 08:47:22 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5HFlFLv007447 for ; Tue, 17 Jun 2003 08:47:16 -0700 (PDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5HFkvIe081836; Tue, 17 Jun 2003 17:46:59 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h5HFg61C011794; Tue, 17 Jun 2003 17:42:07 +0200 Received: from dhcp22-128.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48202 from ; Tue, 17 Jun 2003 17:42:06 +0200 Message-Id: <3EEF36E1.B463D3F@hursley.ibm.com> Date: Tue, 17 Jun 2003 17:42:25 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt References: <963621801C6D3E4A9CF454A1972AE8F504F898@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If you are correct, exactly the same will happen with PA space. Brian Michel Py wrote: > > Bob, > > You could as well call this draft the IPv6 swamp creation act. If these > addresses can be routed on point-to-point links or VPNs between sites, > they can be routed on the public Internet and since everyone wants > portable PI they will. > > >From the site's point of view, this is an easy decision: if the site > wants portable address space, first they will get this for $10 one-time, > then instead of paying the RIR $2.5k/year for the space, the site will > simply allocate this money paying $2.5k/year to their ISP to leak their > /48 in the GRT and $2.5k/year is enough for ISPs to leak it. > > Not only this creates the IPv6 swamp but it also puts the RIRs out of > business. > > 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 Jun 17 09:55:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HGtJxq008241; Tue, 17 Jun 2003 09:55:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5HGtJfW008240; Tue, 17 Jun 2003 09:55:19 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HGtGxq008233 for ; Tue, 17 Jun 2003 09:55:16 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5HGrMNh008377 for ; Tue, 17 Jun 2003 09:53:22 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h5HGrGLv018205 for ; Tue, 17 Jun 2003 09:53:17 -0700 (PDT) Subject: RE: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt Date: Tue, 17 Jun 2003 09:53:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F5067213@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt Thread-Index: AcM058vZVQTCVbedQfKIWrfAQphcrwACHA4g From: "Michel Py" To: "Brian Carpenter" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5HGtGxq008234 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > If you are correct, exactly the same will happen with > PA space. [I assume that you are referring to jj's proposal] In the "putting the RIRs out of business" dept, no (because LIRs would still pay to obtain PA space). In the "explosion of the routing table" dept, the risk is a lot lesser for three reasons: - No matter what the "guarantees" that a LIR would give about the allocating permanently a block to a site, it still remains PA which means that the incentive to get it routed globally is not nearly as strong. - NRENs and some other organizations will likely continue filtering long PA prefixes. - In case a LIR provides addresses and not transit, they will likely blackhole the block they allocated to that purpose (because of economic reasons, not because the IETF says so), making routing longer prefixes within that block moot. In other words: - There is a strong and unfulfilled demand for globally routable PI. - Neither Bob or jj's proposals are aimed at providing it. However, - jj's proposal does not make it as globally routable PI. Simply does not work. Yes it could eventually be perverted into that, but as the "consumer" I am not buying it as a good enough PI solution. - There is nothing that stands between Bob's proposal and the PI swamp except an IETF edict that says "don't do it because it's the wrong thing to do" which does not stand against any money argument. As we have seen with the Elz appeal recently, it is none of the IETF's business to prevent users to misconfigure networks nor to force vendors to release products that can't be misconfigured. 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 Jun 17 10:14:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HHEXxq008748; Tue, 17 Jun 2003 10:14:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5HHEXab008747; Tue, 17 Jun 2003 10:14:33 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HHEUxq008740 for ; Tue, 17 Jun 2003 10:14:30 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5HHCaGq023455 for ; Tue, 17 Jun 2003 10:12:36 -0700 (PDT) Received: from fuchsia.home (ip26.coe.tnet.co.th [203.146.155.26]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5HHCSWP014677 for ; Tue, 17 Jun 2003 11:12:29 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h5HHAP37006467; Wed, 18 Jun 2003 00:10:27 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5HHAkN10027; Wed, 18 Jun 2003 00:10:48 +0700 (ICT) From: Robert Elz To: "Michel Py" cc: "Bob Hinden" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F898@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F504F898@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Jun 2003 00:10:46 +0700 Message-ID: <5296.1055869846@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 17 Jun 2003 08:10:41 -0700 From: "Michel Py" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F898@server2000.arneill-py.sacramento.ca.us> | $2.5k/year is enough for ISPs to leak it. But why would any other ISP accept it? None of the others are getting any share of that 2.5K (or other amount), and since all these are from a common prefix (whatever that ends up being) filtering all of them is trivial. So, how exactly will an ISP actually achieve anything (beyond making the address visible to all of its customers)? I think you're worrying about nothing here. 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 Jun 17 10:41:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HHf5xq009023; Tue, 17 Jun 2003 10:41:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5HHf55g009022; Tue, 17 Jun 2003 10:41:05 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HHf1xq009015 for ; Tue, 17 Jun 2003 10:41:01 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5HHd7Nh027297 for ; Tue, 17 Jun 2003 10:39:07 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5HHd2ht019927 for ; Tue, 17 Jun 2003 11:39:02 -0600 (MDT) Subject: RE: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt Date: Tue, 17 Jun 2003 10:39:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F89B@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt Thread-Index: AcM086l6vmixcrnSR3ycKUndr9tULAAAomoA From: "Michel Py" To: "Robert Elz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5HHf2xq009016 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, | Michel Py wrote: | $2.5k/year is enough for ISPs to leak it. > Robert wrote: > But why would any other ISP accept it? Because they would be under pressure from their own customers to do so, as well as announcing their own customer's prefixes to others. We are not talking about one guy corrupting one ISP here. EVERYONE (well, lots of people) wants PI, so all ISPs are in the same boat. All it takes is two or three of them to do it, then a few complaints from customers to other ISPs that don't do it yet that they can't reach a site and voila we've opened the floodgates. 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 Jun 17 16:11:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HNBRxq012902; Tue, 17 Jun 2003 16:11:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5HNBRKh012901; Tue, 17 Jun 2003 16:11:27 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5HNBOxq012894 for ; Tue, 17 Jun 2003 16:11:24 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5HN9UGq011792 for ; Tue, 17 Jun 2003 16:09:30 -0700 (PDT) Received: from effinger.cisra.com.au (effinger.cisra.com.au [203.12.173.81]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5HN9MWP029879 for ; Tue, 17 Jun 2003 17:09:24 -0600 (MDT) Received: from ivory.research.canon.com.au (edge-aide.cisra.com.au [203.12.173.254]) by effinger.cisra.com.au (Postfix) with ESMTP id EF95B5B71E; Tue, 17 Jun 2003 23:09:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ivory.research.canon.com.au (Postfix) with ESMTP id D5A20568C; Wed, 18 Jun 2003 09:09:17 +1000 (EST) Received: from ivory.research.canon.com.au ([127.0.0.1]) by localhost (ivory.research.canon.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38761-01; Wed, 18 Jun 2003 09:09:17 +1000 (EST) Received: from cisra.canon.com.au (castro.research.canon.com.au [10.2.2.76]) by ivory.research.canon.com.au (Postfix) with ESMTP id 5AA4B568A; Wed, 18 Jun 2003 09:09:17 +1000 (EST) Message-ID: <3EEF9F9D.D194CD26@cisra.canon.com.au> Date: Wed, 18 Jun 2003 09:09:17 +1000 From: Peter Bell Organization: CISRA X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Next steps on the IPv6 Node requirements draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Along with removing DES from the "SHALL" list, it looks likely that AES will be added to the IPSec SHALL requirements, perhaps this draft should include AES. Peter. john.loughney@nokia.com wrote: > > Hi all, > > I've updated the draft on 4 major points that were discussed at the IETF. Roughly > they cover stateful address autoconfig support, DHCP support, MIPv6 support and DES > support. > > 4) DES support removed: > > The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD NOT be supported. > Security issues related to the use of DES are discussed in [DESDIFF], [DESINT], > [DESCRACK]. It is still listed as required by the existing IPsec RFCs, but as it is > currently viewed as an inherently weak algorithm, and no longer fulfills its intended role. > -- // // Peter L. Bell peter.bell@cisra.canon.com.au // +61 2 9805 2955 // Blessed are the Peacemakers, they shall be called Sons of God. // -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 18 04:24:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5IBOrxq015371; Wed, 18 Jun 2003 04:24:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5IBOrQa015370; Wed, 18 Jun 2003 04:24:53 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5IBOoxq015363 for ; Wed, 18 Jun 2003 04:24:50 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5IBMrGq007116 for ; Wed, 18 Jun 2003 04:22:53 -0700 (PDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5IBMlLv025189 for ; Wed, 18 Jun 2003 04:22:48 -0700 (PDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5IBMla10343 for ; Wed, 18 Jun 2003 14:22:47 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 18 Jun 2003 14:22:47 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 14:22:46 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 14:22:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next steps on the IPv6 Node requirements draft Date: Wed, 18 Jun 2003 14:22:33 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next steps on the IPv6 Node requirements draft Thread-Index: AcM1JX0Qvx0hLng7Qi+xhDx9LG4PwwAZhzFg From: To: Cc: X-OriginalArrivalTime: 18 Jun 2003 11:22:45.0375 (UTC) FILETIME=[F0D568F0:01C3358B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5IBOoxq015364 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Peter, Actually, the idea of the draft was to detail the existing requirements, based on existing RFCs - not to create new requirements. We've discussed with the Security ADs that there would be a need for the IPsec WG to create a list of recommended encryption mechanisms and that this draft could reference such a spec. John > -----Original Message----- > From: ext Peter Bell [mailto:peter.bell@cisra.canon.com.au] > Sent: 18 June, 2003 02:09 > To: Loughney John (NRC/Helsinki) > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Next steps on the IPv6 Node requirements draft > > > Along with removing DES from the "SHALL" list, it looks > likely that AES > will be added to the IPSec SHALL requirements, perhaps this > draft should > include AES. > > Peter. > > john.loughney@nokia.com wrote: > > > > Hi all, > > > > I've updated the draft on 4 major points that were > discussed at the IETF. Roughly > > they cover stateful address autoconfig support, DHCP > support, MIPv6 support and DES > > support. > > > > > 4) DES support removed: > > > > The "ESP DES-CBC Cipher Algorithm With Explicit IV" > [RFC-2405] SHOULD NOT be supported. > > Security issues related to the use of DES are discussed in > [DESDIFF], [DESINT], > > [DESCRACK]. It is still listed as required by the existing > IPsec RFCs, but as it is > > currently viewed as an inherently weak algorithm, and no > longer fulfills its intended role. > > > > -- > // > // Peter L. Bell peter.bell@cisra.canon.com.au > // +61 2 9805 2955 > // Blessed are the Peacemakers, they shall be called Sons of God. > // > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 18 05:57:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5ICvxxq015933; Wed, 18 Jun 2003 05:57:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5ICvxTP015932; Wed, 18 Jun 2003 05:57:59 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5ICvtxq015925 for ; Wed, 18 Jun 2003 05:57:56 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5ICtxGq025106 for ; Wed, 18 Jun 2003 05:55:59 -0700 (PDT) Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5ICtpht015484 for ; Wed, 18 Jun 2003 06:55:52 -0600 (MDT) Received: from lt38 ([10.4.1.86]) by galileo5.galileo.co.il (8.12.6/8.12.6) with SMTP id h5IDrJlH018381; Wed, 18 Jun 2003 15:53:20 +0200 (GMT-2) Message-ID: <00ac01c335a1$76b8b890$5601040a@lt38> From: "Nir Arad" To: , References: <000601c33490$66cdbc80$4906140a@future.futsoft.com> Subject: Re: Checking IPv6 MAC Address Date: Wed, 18 Jun 2003 15:56:47 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00A8_01C335B2.3940BA60"; type="multipart/alternative" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00A8_01C335B2.3940BA60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A9_01C335B2.3940BA60" ------=_NextPart_001_00A9_01C335B2.3940BA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgU2l2YSwNCg0KU2VlIFJGQyAzNTEzOg0KDQoyLiBJUHY2IEFkZHJlc3NpbmcNCiguLi4pDQog ICBUaGVyZSBhcmUgbm8gYnJvYWRjYXN0IGFkZHJlc3NlcyBpbiBJUHY2LCB0aGVpciBmdW5jdGlv biBiZWluZw0KICAgc3VwZXJzZWRlZCBieSBtdWx0aWNhc3QgYWRkcmVzc2VzLg0KDQoyLjQgQWRk cmVzcyBUeXBlIElkZW50aWZpY2F0aW9uDQoNCiAgIFRoZSB0eXBlIG9mIGFuIElQdjYgYWRkcmVz cyBpcyBpZGVudGlmaWVkIGJ5IHRoZSBoaWdoLW9yZGVyIGJpdHMgb2YNCiAgIHRoZSBhZGRyZXNz LCBhcyBmb2xsb3dzOg0KDQogICBBZGRyZXNzIHR5cGUgICAgICAgICBCaW5hcnkgcHJlZml4ICAg ICAgICBJUHY2IG5vdGF0aW9uICAgU2VjdGlvbg0KICAgLS0tLS0tLS0tLS0tICAgICAgICAgLS0t LS0tLS0tLS0tLSAgICAgICAgLS0tLS0tLS0tLS0tLSAgIC0tLS0tLS0NCiAgIFVuc3BlY2lmaWVk ICAgICAgICAgIDAwLi4uMCAgKDEyOCBiaXRzKSAgIDo6LzEyOCAgICAgICAgICAyLjUuMg0KICAg TG9vcGJhY2sgICAgICAgICAgICAgMDAuLi4xICAoMTI4IGJpdHMpICAgOjoxLzEyOCAgICAgICAg IDIuNS4zDQogICBNdWx0aWNhc3QgICAgICAgICAgICAxMTExMTExMSAgICAgICAgICAgICBGRjAw OjovOCAgICAgICAgMi43DQogICBMaW5rLWxvY2FsIHVuaWNhc3QgICAxMTExMTExMDEwICAgICAg ICAgICBGRTgwOjovMTAgICAgICAgMi41LjYNCiAgIFNpdGUtbG9jYWwgdW5pY2FzdCAgIDExMTEx MTEwMTEgICAgICAgICAgIEZFQzA6Oi8xMCAgICAgICAyLjUuNg0KICAgR2xvYmFsIHVuaWNhc3Qg ICAgICAgKGV2ZXJ5dGhpbmcgZWxzZSkNCg0KICAgQW55Y2FzdCBhZGRyZXNzZXMgYXJlIHRha2Vu IGZyb20gdGhlIHVuaWNhc3QgYWRkcmVzcyBzcGFjZXMgKG9mIGFueQ0KICAgc2NvcGUpIGFuZCBh cmUgbm90IHN5bnRhY3RpY2FsbHkgZGlzdGluZ3Vpc2hhYmxlIGZyb20gdW5pY2FzdA0KICAgYWRk cmVzc2VzLg0KDQpSZWdhcmRzLA0KDQotLSBOaXIgQXJhZA0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQogICAgICBOaXIgQXJhZA0KICAgICAgUHJvZHVjdCBEZWZpbml0aW9uDQogICAgICBN YXJ2ZWxsIFNlbWljb25kdWN0b3IgSXNyYWVsIExpbWl0ZWQgICAgDQogICAgIA0KICAgICAgZS1t YWlsOiBOaXIuQXJhZEBpbC5tYXJ2ZWxsLmNvbSAgVGhpcyBtZXNzYWdlIG1heSBjb250YWluIGNv bmZpZGVudGlhbCwgcHJvcHJpZXRhcnkgb3IgbGVnYWxseSBwcml2aWxlZ2VkIGluZm9ybWF0aW9u LiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNz YWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmll ZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlz IGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0 ZWx5IGJ5IHRlbGVwaG9uZSwgb3IgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgZnJv bSB5b3VyIGNvbXB1dGVyLg0KDQogICAgICBUaGFuayB5b3UhICANCiAgICAgICAgICAgIFRFTDog Kzk3Mi00IDkwOS0xNDI2IA0KICAgICAgICAgICAgRkFYOiArOTcyLTQgOTA5LTE1MDEgDQogICAg IA0KICAgICAgTW9zaGF2IE1hbm9mLCBELk4uIE1pc2dhdiAyMDE4NCwgSXNyYWVsDQogICAgICBo dHRwOi8vd3d3Lm1hcnZlbGwuY29tICANCg0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IA0KICBGcm9tOiBTaXZhcmFtYWtyaXNobmFuIEEgDQogIFRvOiBpcG5nQHN1bnJvb2YuZW5nLnN1 bi5jb20gDQogIFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTcsIDIwMDMgNzoyMiBBTQ0KICBTdWJqZWN0 OiBDaGVja2luZyBJUHY2IE1BQyBBZGRyZXNzDQoNCg0KDQogIEhpLA0KDQogIEkgbmVlZCB0byBj aGVjayBpZiB0aGUgTUFDIEFkZHJlc3Mgb2YgYW4gSVB2NiBwYWNrZXQgaXMgTXVsdGljYXN0IG9y DQogIEJyb2FkY2FzdCBNQUMNCiAgQWRkcmVzcz8gV2hhdCBhcmUgdGhlIEJpdHMgaW4gdGhlIE1B QyBBZGRyZXNzIHRoYXQgbmVlZHMgdG8gYmUgdmVyaWZpZWQgZm9yDQogIHRoaXMNCiAgcHVycG9z ZT8NCg0KICB0aGFua3MgYW5kIHJlZ2FyZHMsDQogIFNpdmENCg0KICAqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCiAgVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEZ1dHVyZSBTb2Z0d2FyZSBMaW1p dGVkIChGU0wpIA0KICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsIHRvIHdob20gaXQNCiAgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiAgcHJp dmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gDQogIGFuZCBzaG91bGQgbm90IGJl IGNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3IgDQogIHdo YXQgaXQgaXMgaW50ZW5kZWQuIA0KDQogIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2Fn ZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUNCiAgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwNCiAgeW91IGFyZSBub3RpZmll ZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZCBmcm9tIHVzaW5nLA0KICBjb3B5aW5n LCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiAN CiAgRlNMIGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIGxvc3Mgb3IgZGFtYWdlIGFyaXNp bmcgZnJvbSANCiAgdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhp cyBlbWFpbCBpbmNsdWRpbmcNCiAgZGFtYWdlIGZyb20gdmlydXMuDQogICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKg0KICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KICBJRVRGIElQbmcgV29ya2luZyBHcm91cCBNYWlsaW5nIExp c3QNCiAgSVBuZyBIb21lIFBhZ2U6ICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9wbGF5Z3Jv dW5kLnN1bi5jb20vaXBuZw0KICBGVFAgYXJjaGl2ZTogICAgICAgICAgICAgICAgICAgICAgZnRw Oi8vcGxheWdyb3VuZC5zdW4uY29tL3B1Yi9pcG5nDQogIERpcmVjdCBhbGwgYWRtaW5pc3RyYXRp dmUgcmVxdWVzdHMgdG8gbWFqb3Jkb21vQHN1bnJvb2YuZW5nLnN1bi5jb20NCiAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg== ------=_NextPart_001_00A9_01C335B2.3940BA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xMTcwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5I aSBTaXZhLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5TZWUgUkZDIDM1MTM6 PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+Mi4gSVB2NiBBZGRy ZXNzaW5nPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4oLi4uKTwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj4mbmJzcDsm bmJzcDsgVGhlcmUgYXJlIG5vIGJyb2FkY2FzdCANCmFkZHJlc3NlcyBpbiBJUHY2LCB0aGVpciBm dW5jdGlvbiBiZWluZzxCUj4mbmJzcDsmbmJzcDsgc3VwZXJzZWRlZCBieSBtdWx0aWNhc3QgDQph ZGRyZXNzZXMuPEJSPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXci IHNpemU9Mj4yLjQgQWRkcmVzcyBUeXBlIA0KSWRlbnRpZmljYXRpb248L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPiZuYnNwOyZuYnNwOyBUaGUgdHlw ZSBvZiBhbiBJUHY2IGFkZHJlc3MgaXMgDQppZGVudGlmaWVkIGJ5IHRoZSBoaWdoLW9yZGVyIGJp dHMgb2Y8QlI+Jm5ic3A7Jm5ic3A7IHRoZSBhZGRyZXNzLCBhcyANCmZvbGxvd3M6PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj4mbmJzcDsmbmJzcDsg QWRkcmVzcyANCnR5cGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQmluYXJ5IA0KcHJlZml4Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IElQdjYgbm90YXRpb24mbmJzcDsmbmJzcDsgDQpTZWN0aW9uPEJSPiZuYnNwOyZuYnNw OyANCi0tLS0tLS0tLS0tLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCi0tLS0tLS0tLS0tLS0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQotLS0tLS0tLS0tLS0tJm5ic3A7Jm5ic3A7IC0tLS0tLS08QlI+Jm5ic3A7Jm5i c3A7IA0KVW5zcGVjaWZpZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMDAuLi4wJm5ic3A7IA0KKDEyOCBiaXRzKSZuYnNwOyZuYnNwOyANCjo6 LzEyOCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCjIuNS4yPEJSPiZuYnNwOyZuYnNwOyANCkxvb3BiYWNrJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KMDAu Li4xJm5ic3A7ICgxMjggYml0cykmbmJzcDsmbmJzcDsgDQo6OjEvMTI4Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIuNS4zPEJSPiZuYnNwOyZuYnNwOyAN Ck11bHRpY2FzdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCjExMTExMTExJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KRkYwMDo6Lzgm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMi43PEJSPiZuYnNwOyZu YnNwOyANCkxpbmstbG9jYWwgdW5pY2FzdCZuYnNwOyZuYnNwOyANCjExMTExMTEwMTAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpG RTgwOjovMTAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMi41LjY8QlI+Jm5i c3A7Jm5ic3A7IFNpdGUtbG9jYWwgDQp1bmljYXN0Jm5ic3A7Jm5ic3A7IA0KMTExMTExMTAxMSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCkZFQzA6Oi8xMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyLjUuNjxC Uj4mbmJzcDsmbmJzcDsgR2xvYmFsIA0KdW5pY2FzdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAoZXZlcnl0aGluZyBlbHNlKTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+Jm5ic3A7Jm5ic3A7IEFueWNhc3QgYWRkcmVzc2VzIGFy ZSB0YWtlbiANCmZyb20gdGhlIHVuaWNhc3QgYWRkcmVzcyBzcGFjZXMgKG9mIGFueTxCUj4mbmJz cDsmbmJzcDsgc2NvcGUpIGFuZCBhcmUgbm90IA0Kc3ludGFjdGljYWxseSBkaXN0aW5ndWlzaGFi bGUgZnJvbSB1bmljYXN0PEJSPiZuYnNwOyZuYnNwOyANCmFkZHJlc3Nlcy48QlI+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5SZWdhcmRzLDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4tLSBOaXIgQXJhZDxCUj4NCjxIUiB3aWR0aD0iMTAwJSI+ DQo8QlI+DQo8VEFCTEUgY2VsbFBhZGRpbmc9MTAgd2lkdGg9IjEwMCUiIGJvcmRlcj0xPg0KICA8 VEJPRFk+DQogIDxUUj4NCiAgICA8VEQgbm9XcmFwPjxGT05UIHNpemU9KzI+PEI+PEk+TmlyIEFy YWQ8L0k+PC9CPjwvRk9OVD48QlI+UHJvZHVjdCANCiAgICAgIERlZmluaXRpb248QlI+TWFydmVs bCBTZW1pY29uZHVjdG9yIElzcmFlbCBMaW1pdGVkIDwvVEQ+DQogICAgPFREIGFsaWduPW1pZGRs ZT4NCiAgICAgIDxUQUJMRSB3aWR0aD0iMTAwJSI+DQogICAgICAgIDxUQk9EWT4NCiAgICAgICAg PFRSPg0KICAgICAgICAgIDxURCBhbGlnbj1sZWZ0PjxJTUcgaGVpZ2h0PTU2IGFsdD0iTWFydmVs bCCuIiANCiAgICAgICAgICAgIHNyYz0iY2lkOjAwYTYwMWMzMzVhMSQ3NWI0ZGQyMCQ1NjAxMDQw YUBsdDM4IiB3aWR0aD0xMTMgYm9yZGVyPTA+PC9URD4NCiAgICAgICAgICA8VEQgdkFsaWduPWJv dHRvbSBhbGlnbj1yaWdodD48SU1HIGhlaWdodD0xNSANCiAgICAgICAgICAgIGFsdD0iTW92aW5n IEZvcndhcmQgRmFzdGVyIKkiIA0KICAgICAgICAgICAgc3JjPSJjaWQ6MDBhNzAxYzMzNWExJDc1 YjY2M2MwJDU2MDEwNDBhQGx0MzgiIHdpZHRoPTE0NiANCiAgICAgICAgYm9yZGVyPTA+PC9URD48 L1RSPjwvVEJPRFk+PC9UQUJMRT48L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQ+ZS1tYWlsOiA8 QSANCiAgICAgIGhyZWY9Im1haWx0bzpOaXIuQXJhZEBpbC5tYXJ2ZWxsLmNvbSI+TmlyLkFyYWRA aWwubWFydmVsbC5jb208L0E+IDwvVEQ+DQogICAgPFREIHJvd1NwYW49Mz5UaGlzIG1lc3NhZ2Ug bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSBvciANCiAgICAgIGxlZ2FsbHkg cHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIG9ubHkg Zm9yIHRoZSANCiAgICAgIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJv dmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIA0KICAgICAgaXMgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IA0KICAgICAg ZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0 aW9uIGlzIHN0cmljdGx5IA0KICAgICAgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2UgDQogICAgICBub3RpZnkgdXMgaW1t ZWRpYXRlbHkgYnkgdGVsZXBob25lLCBvciBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2Fn ZSANCiAgICAgIGZyb20geW91ciBjb21wdXRlci48QlI+PEJSPlRoYW5rIHlvdSEgPC9URD48L1RS Pg0KICA8VFI+DQogICAgPFREIG5vV3JhcD4NCiAgICAgIDxUQUJMRT4NCiAgICAgICAgPFRCT0RZ Pg0KICAgICAgICA8VFI+DQogICAgICAgICAgPFREPlRFTDo8L1REPg0KICAgICAgICAgIDxURD4r OTcyLTQ8L1REPg0KICAgICAgICAgIDxURD45MDktMTQyNjwvVEQ+PC9UUj4NCiAgICAgICAgPFRS Pg0KICAgICAgICAgIDxURD5GQVg6PC9URD4NCiAgICAgICAgICA8VEQ+Kzk3Mi00PC9URD4NCiAg ICAgICAgICA8VEQ+OTA5LTE1MDE8L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvVEQ+PC9UUj4N CiAgPFRSPg0KICAgIDxURCBub1dyYXA+TW9zaGF2IE1hbm9mLCBELk4uIE1pc2dhdiAyMDE4NCwg SXNyYWVsPEJSPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5tYXJ2ZWxsLmNvbSI+aHR0cDov L3d3dy5tYXJ2ZWxsLmNvbTwvQT4gDQo8L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvRk9OVD48 L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1M RUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xp ZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj4t LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iQkFD S0dST1VORDogI2U0ZTRlNDsgRk9OVDogMTBwdCBhcmlhbDsgZm9udC1jb2xvcjogYmxhY2siPjxC PkZyb206PC9CPiANCiAgPEEgdGl0bGU9c2l2YXJrYUBmdXR1cmUuZnV0c29mdC5jb20gDQogIGhy ZWY9Im1haWx0bzpzaXZhcmthQGZ1dHVyZS5mdXRzb2Z0LmNvbSI+U2l2YXJhbWFrcmlzaG5hbiBB PC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEI+VG86PC9CPiA8 QSB0aXRsZT1pcG5nQHN1bnJvb2YuZW5nLnN1bi5jb20gDQogIGhyZWY9Im1haWx0bzppcG5nQHN1 bnJvb2YuZW5nLnN1bi5jb20iPmlwbmdAc3Vucm9vZi5lbmcuc3VuLmNvbTwvQT4gPC9ESVY+DQog IDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlNlbnQ6PC9CPiBUdWVzZGF5LCBKdW5l IDE3LCAyMDAzIDc6MjIgDQpBTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFs Ij48Qj5TdWJqZWN0OjwvQj4gQ2hlY2tpbmcgSVB2NiBNQUMgQWRkcmVzczwvRElWPg0KICA8RElW PjxCUj48L0RJVj48QlI+SGksPEJSPjxCUj5JIG5lZWQgdG8gY2hlY2sgaWYgdGhlIE1BQyBBZGRy ZXNzIG9mIGFuIElQdjYgDQogIHBhY2tldCBpcyBNdWx0aWNhc3Qgb3I8QlI+QnJvYWRjYXN0IE1B QzxCUj5BZGRyZXNzPyBXaGF0IGFyZSB0aGUgQml0cyBpbiB0aGUgDQogIE1BQyBBZGRyZXNzIHRo YXQgbmVlZHMgdG8gYmUgdmVyaWZpZWQgZm9yPEJSPnRoaXM8QlI+cHVycG9zZT88QlI+PEJSPnRo YW5rcyANCiAgYW5kIA0KICByZWdhcmRzLDxCUj5TaXZhPEJSPjxCUj4qKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kio8QlI+VGhpcyANCiAgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBGdXR1cmUgU29mdHdhcmUg TGltaXRlZCAoRlNMKSA8QlI+YW5kIGlzIGludGVuZGVkIA0KICBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdDxCUj5pcyBhZGRyZXNzZWQuIEl0IG1heSANCiAg Y29udGFpbiZuYnNwOyBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiA8QlI+ YW5kIHNob3VsZCBub3QgYmUgDQogIGNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ug b3RoZXIgdGhhbiBmb3IgPEJSPndoYXQgaXQgaXMgaW50ZW5kZWQuIA0KICA8QlI+PEJSPklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSANCiAg dGhlPEJSPm9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsPEJSPnlvdSANCiAgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3Rs eSBwcm9oaWJpdGVkIGZyb20gdXNpbmcsPEJSPmNvcHlpbmcsIA0KICBhbHRlcmluZywgb3IgZGlz Y2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiA8QlI+RlNMIGFjY2VwdHMgbm8g DQogIHJlc3BvbnNpYmlsaXR5IGZvciBsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gPEJSPnRo ZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIA0KICB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGlu Y2x1ZGluZzxCUj5kYW1hZ2UgZnJvbSANCiAgdmlydXMuPEJSPioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxC Uj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxCUj5JRVRGIA0KICBJUG5nIFdvcmtpbmcgR3JvdXAgTWFpbGluZyBMaXN0 PEJSPklQbmcgSG9tZSANCiAgUGFnZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDxBIA0KICBocmVmPSJodHRw Oi8vcGxheWdyb3VuZC5zdW4uY29tL2lwbmciPmh0dHA6Ly9wbGF5Z3JvdW5kLnN1bi5jb20vaXBu ZzwvQT48QlI+RlRQIA0KICBhcmNoaXZlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEEgDQogIGhyZWY9ImZ0 cDovL3BsYXlncm91bmQuc3VuLmNvbS9wdWIvaXBuZyI+ZnRwOi8vcGxheWdyb3VuZC5zdW4uY29t L3B1Yi9pcG5nPC9BPjxCUj5EaXJlY3QgDQogIGFsbCBhZG1pbmlzdHJhdGl2ZSByZXF1ZXN0cyB0 byA8QSANCiAgaHJlZj0ibWFpbHRvOm1ham9yZG9tb0BzdW5yb29mLmVuZy5zdW4uY29tIj5tYWpv cmRvbW9Ac3Vucm9vZi5lbmcuc3VuLmNvbTwvQT48QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+PC9CTE9DS1FV T1RFPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_001_00A9_01C335B2.3940BA60-- ------=_NextPart_000_00A8_01C335B2.3940BA60 Content-Type: image/gif; name="marvell_logo.gif" Content-Transfer-Encoding: base64 Content-ID: <00a601c335a1$75b4dd20$5601040a@lt38> R0lGODlhcQA4AMQAAP//////zP/MzP/Mmf+ZZv9mM/9mAP8zAP8AAMz//8zMzJmZzJmZmWZmZjMz ZjMzMwAAMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAABxADgAAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj0jcY8lsOh2CVsNJ bTZEjEZDkZRFIg7tY0oemyPc1eNbbo/DX4AiMo10Yd+HC61mtxh2Clpad3treixzaSiHdH+BEVl2 hSt5EYgrChCLJodrVyyAWA4PnJQmeYctAXwnjZ+Pp3uXa5ctiq60S46hk7IqlruYKrglr5e8K6K/ Kam7tombxroQu6DKvswlwbTQK6ycnt2wvdqoukvV3sStAK/iySoN2ebc4sMpxZ735NjmI87SPcOH QlMAABCQ8fNT7l+Eau/G3So17wHEhddULNOWSpfHdSpq8YOoLmOKjb+C/wlbCbJgwHHiTKJAeeql sG7VXBxj+UzmCZqFOnq66JGB0aNIke5bKCypU6NrUtK6CFFhrSlVmHy5pI7pIaxZrchSaRXdFwYK nh6tpXIhGABq1dY022RcnDkK81qsMlWgo4p79Xajh8RexGcMRBBmJFScAxFLYt0JOJRlhAUAwzrp Cw8TYM17J9vVapnTU7Zby97MmDau0y6ND9cyRapu6tSkX5VgwISkwL1jkrTlPNgUgEgKkidPICAB gChyMHYqpby69XmFqXn9Yvw4WgULrFfnrdpVKddosRtpDLM4igakbst3xtAEbzdtavv8wZ7n7JPk zYebOvGU0Bp6RxVB1v9KwJ0FDDqaKSSPYDvFMYRNbrXDSHcGiqSGHsyF2NyIzqkXBF181ZJYJaDZ xsJnES62g4A0athMjbcRdAJ4CIbH4T9ABinkkEQWaeSRSCap5JI/CEAAAQflIEABBQwgQgEGQGfC AAdoWcKUBhxQgJciENDllQWYQOUBYp5AQJoocEmCAAe8eYAOdLY5AAIIkDlCAW2eQCcBXMI5JwIE AMBloiWwKcAAVqp5Z5wIzFnAk4beIECYaa7pp6JiTmoCnVEcYICbdwJ6ggFpfgoAlinsOacBA5iJ Z52XXprlCVhumukIm7JZ5Ql7vvnrlWwicOyrB0S5pahlUhkpDnQOAOhemGd+KSagp456gLXLItvs CWw6hwKVsVYqxKKLAtCnCWY+Ga+3AiiAKApmhhvmm1BKSiWjJBSKbpN1AnAAF9mOEICY5rL5bBRh olDtuaaK6SeWgAI8ApecMunxx0mEAAA7 ------=_NextPart_000_00A8_01C335B2.3940BA60 Content-Type: image/gif; name="movingforwardfaster.gif" Content-Transfer-Encoding: base64 Content-ID: <00a701c335a1$75b663c0$5601040a@lt38> R0lGODlhkgAPANUAADc1Nfvi26emputkQXZ0dMzMzF1bW/SolPCLcZmZmebm5kRCQv///+53WfnO w4+OjsDAwPa7rGloaPOeiYKBgbSzs/zs51BOTu+BZfWxoNnZ2fLy8uxuTf718/GVffrYz/fFtwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAQUAP8ALAAAAACSAA8AAAb/QIZw SCwaj8ikcslsOp9QJcDAIAAKwwcAcFEINVcFACJMSIaJcQEw3Bi2FGQacP5eto/hmutlCBYMCw9r G0MVABpEElsJaFsGiVGSSFt7WAxrEAoXcUIGFAkXaHUMaQsQbEIPXQkCchcJFUMEBhsCiEKZV0Ji abCkDIudQhIUVmgGBQYEk81FAAQXb5e3qqSHF65lpAkGC29DEsxbclukEo0bu5iPfQwXC1YL2gxg Vu6LAHnbpcDOkwAO3bokhkCFBY2EbFgAoBC/bahS+QGQQIscfxQWVCCwoM+aUA4ZaIFgJRIDChck IAz3YGUZWAuG/ZskYYMEBRJMQpCArkiC/4RCKuxjIPQkMDMShhYpSmQDBZ6X6tWUQObLGZKKyAhg pqqCgGs86c0cS7as2bNo06pdy7at27dw48qdawQEgrsgikw4UBcDBr5CAtzFO0TwXcBCDtz1EIBB AA8e8tKdnCTDgAwZPhAJMGCABSIdBmCYIJmBhQwILmsW8mHAhAylGSBokIEDAtkYbFPebcQy5s9D JjRwDXpAgwgdilgu0vr1aiGza9/24HcC7+tCLN9tLMSC6AYckg9x4GHAbSLLibTGgCA2Ag7wGzto 8Bf79fTozaeOQOSAg/fKDcCca7ARcZdlz9mHHX5DcOCBEA00MIQFHHQWGwMMMtBaZ+dBdwVbhEUE AQA7 ------=_NextPart_000_00A8_01C335B2.3940BA60-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 18 15:02:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5IM2sxq017740; Wed, 18 Jun 2003 15:02:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5IM2sIe017739; Wed, 18 Jun 2003 15:02:54 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5IM2nxq017732 for ; Wed, 18 Jun 2003 15:02:49 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5IM0rGq025103 for ; Wed, 18 Jun 2003 15:00:53 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5IM0lht020878 for ; Wed, 18 Jun 2003 16:00:48 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01883; Wed, 18 Jun 2003 18:00:41 -0400 (EDT) Message-Id: <200306182200.SAA01883@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com From: The IESG Subject: Document Action: IPv6 Global Unicast Address Format to Informational Date: Wed, 18 Jun 2003 18:00:41 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IPv6 Global Unicast Address Format' as an Informational RFC. This document will replace RFC2374 and reclassify RFC 2374 (and the TLA/NLA structure described there) as historic. This document is the product of the IP Version 6 Working Group. The IESG contact persons are Thomas Narten and Erik Nordmark. Technical Summary RFC2374 "An IPv6 Aggregatable Global Unicast Address Format" defined an IPv6 address allocation structure that includes TLA (Top Level Aggregator) and NLA (Next Level Aggregator). This document replaces RFC2374, and makes RFC 2374 and the TLA/NLA structure historic. Working Group Summary There was support for this in the WG; this document documents what the WG decided quite some time ago. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 18 17:25:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5J0PDxq018310; Wed, 18 Jun 2003 17:25:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5J0PCvP018309; Wed, 18 Jun 2003 17:25:12 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5J0P8xq018302 for ; Wed, 18 Jun 2003 17:25:08 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5J0NCNh002150 for ; Wed, 18 Jun 2003 17:23:12 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5J0N7ep021839 for ; Wed, 18 Jun 2003 18:23:07 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGP00141D2IMD@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 18 Jun 2003 18:23:07 -0600 (MDT) Received: from sun.com ([129.146.18.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGP00CXKD2IV8@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 18 Jun 2003 18:23:06 -0600 (MDT) Date: Wed, 18 Jun 2003 17:23:05 -0700 From: Alain Durand Subject: Re: Next steps on the IPv6 Node requirements draft To: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Message-id: <3EF10269.8050106@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: > For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a > Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462). > So what if the M bit is set _and_ a prefix is advertized? Should the node give up its stateless autoconfigured address in favor of DHCP? What about statically configured addresses on the same node? IMHO, it makes little sense to have both a DHCP allocated address and a stateless autoconfigured address on the same interface. However, I see cases where you want to have nodes using DHCP and nodes using stateless autoconfiguration on the same link. - 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 Jun 19 03:07:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JA7Kxq020677; Thu, 19 Jun 2003 03:07:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5JA7Klx020676; Thu, 19 Jun 2003 03:07:20 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JA7Gxq020669 for ; Thu, 19 Jun 2003 03:07:16 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5JA5LNh025731 for ; Thu, 19 Jun 2003 03:05:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5JA5G4Z023259 for ; Thu, 19 Jun 2003 03:05:16 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id DAA05327; Thu, 19 Jun 2003 03:05:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5JA5DZ13533; Thu, 19 Jun 2003 03:05:13 -0700 X-mProtect: <200306191005> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.68.219, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDN3PeG; Thu, 19 Jun 2003 03:05:10 PDT Message-Id: <4.3.2.7.2.20030617005224.03276730@mailhost.iprg.nokia.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jun 2003 03:04:51 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden & Margaret Wasserman Subject: Request for Agenda Items Cc: hinden@iprg.nokia.com, Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman and I have requested two slots for the Vienna IETF. We requested a short slot (~1 hour) and a long slot (~2 1/2 hour). We plan to use the short slot for status and short open issues, and use the longer slot for topics that need more discussion time (e.g., local addressing). Please send us requests for agenda items (including time needed). We will give priority in setting the agenda to current working group documents and work items identified in the working group charter. Bob Hinden & Margaret Wasserman IPv6 working group chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 19 04:03:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JB3xxq020993; Thu, 19 Jun 2003 04:03:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5JB3xnI020992; Thu, 19 Jun 2003 04:03:59 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JB3txq020985 for ; Thu, 19 Jun 2003 04:03:55 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5JB20Nh006409 for ; Thu, 19 Jun 2003 04:02:00 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5JB0aep011635 for ; Thu, 19 Jun 2003 05:00:49 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h5JB0Or19990; Thu, 19 Jun 2003 18:00:25 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5JAubY27625; Thu, 19 Jun 2003 17:56:42 +0700 (ICT) From: Robert Elz To: Alain Durand cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Next steps on the IPv6 Node requirements draft In-Reply-To: <3EF10269.8050106@sun.com> References: <3EF10269.8050106@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Jun 2003 17:56:37 +0700 Message-ID: <12731.1056020197@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 18 Jun 2003 17:23:05 -0700 From: Alain Durand Message-ID: <3EF10269.8050106@sun.com> | So what if the M bit is set _and_ a prefix is advertized? | Should the node give up its stateless autoconfigured address in favor of | DHCP? No, it should do both. | What about statically configured addresses on the same node? It should keep that as well, though often if there's to be static config it will often also be the case that use of stateless autoconfig and dhcp config will be disabled (either explicitly or implicitly) | IMHO, it makes little sense to have both a DHCP allocated address and a | stateless autoconfigured address on the same interface. In that case, you wouldn't config your routers to send the M bit, and prefixes with the A bit set, at the same time. On the other hand, others may consider it useful to allow nodes to autoconfigure themselves addresses (so they always gave one, provided there's a working router to make the address useful) and at the same time, provide specific addresses to specific nodes (attempting to use DHCP doesn't necessarily mean the DHCP server will actually allocate an address) where specific nodes are expected to own well known addresses. | However, I see cases where you want | to have nodes using DHCP and nodes using stateless autoconfiguration on | the same link. The very nature of *stateless* autoconfig is that there's no (easy) way to configure a node to not do it (manual config on that node excepted). If there was, it would not be stateless. So, by default, if any node on a link is permitted stateless autoconfig (of a prefix) all nodes are. It is generally harmless to own an extra address though, having the statelessly configured one, as well as a dhcp supplied one should not cause any harm. That is, I don't think receiving a DHCP allocated address should cause an autoconfig'd address to be dropped, there's no need (doing do raises all the questions of what you do if you've been running using the autoconfig'd address for hours when the dhcp server returns to life and allocates you an address). All that being said - a request to implementors out there. It would be very (*very*) nice to have the ability in a node to ignore prefixes that are being advertised from routers, and never autoconfig an address in that prefix. That is, I occasionally see someone advertising a prefix that I know doesn't work (they're getting ready for the day it will work, and have just jumped the gun - believing in early preparation or something). I'd like to be able to ignore that (no matter what router advertises it - so lower level packet filtering doesn't help). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 19 04:08:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JB83xq021030; Thu, 19 Jun 2003 04:08:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5JB83Fh021029; Thu, 19 Jun 2003 04:08:03 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JB7xxq021019 for ; Thu, 19 Jun 2003 04:07:59 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5JB64Nh007266 for ; Thu, 19 Jun 2003 04:06:04 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5JB5wWP017391 for ; Thu, 19 Jun 2003 05:05:58 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5JB5v910417 for ; Thu, 19 Jun 2003 14:05:57 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Jun 2003 14:05:56 +0300 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 14:05:56 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 14:05:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next steps on the IPv6 Node requirements draft Date: Thu, 19 Jun 2003 14:05:37 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next steps on the IPv6 Node requirements draft Thread-Index: AcM2UmJSoVPOcGTIQla25OcBelj2CQAAC0Tw From: To: , Cc: X-OriginalArrivalTime: 19 Jun 2003 11:05:56.0478 (UTC) FILETIME=[C1E5B1E0:01C33652] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5JB80xq021020 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, I agree with you - this seems very much a node/user policy decision, for the reasons you list below. I don't think the Node Requirements should impose any new behavior here. thanks, John > -----Original Message----- > From: ext Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: 19 June, 2003 13:57 > To: Alain Durand > Cc: Loughney John (NRC/Helsinki); ipng@sunroof.eng.sun.com > Subject: Re: Next steps on the IPv6 Node requirements draft > > > Date: Wed, 18 Jun 2003 17:23:05 -0700 > From: Alain Durand > Message-ID: <3EF10269.8050106@sun.com> > > | So what if the M bit is set _and_ a prefix is advertized? > | Should the node give up its stateless autoconfigured > address in favor of > | DHCP? > > No, it should do both. > > | What about statically configured addresses on the same node? > > It should keep that as well, though often if there's to be static > config it will often also be the case that use of stateless autoconfig > and dhcp config will be disabled (either explicitly or implicitly) > > | IMHO, it makes little sense to have both a DHCP allocated > address and a > | stateless autoconfigured address on the same interface. > > In that case, you wouldn't config your routers to send the M bit, and > prefixes with the A bit set, at the same time. > > On the other hand, others may consider it useful to allow nodes to > autoconfigure themselves addresses (so they always gave one, provided > there's a working router to make the address useful) and at the same > time, provide specific addresses to specific nodes (attempting to use > DHCP doesn't necessarily mean the DHCP server will actually allocate > an address) where specific nodes are expected to own well > known addresses. > > | However, I see cases where you want > | to have nodes using DHCP and nodes using stateless > autoconfiguration on > | the same link. > > The very nature of *stateless* autoconfig is that there's no > (easy) way to > configure a node to not do it (manual config on that node > excepted). If > there was, it would not be stateless. So, by default, if > any node on a > link is permitted stateless autoconfig (of a prefix) all nodes are. > > It is generally harmless to own an extra address though, having the > statelessly configured one, as well as a dhcp supplied one should not > cause any harm. > > That is, I don't think receiving a DHCP allocated address should cause > an autoconfig'd address to be dropped, there's no need (doing > do raises > all the questions of what you do if you've been running using the > autoconfig'd address for hours when the dhcp server returns to life > and allocates you an address). > > All that being said - a request to implementors out there. > It would be > very (*very*) nice to have the ability in a node to ignore prefixes > that are being advertised from routers, and never autoconfig > an address > in that prefix. That is, I occasionally see someone advertising a > prefix that I know doesn't work (they're getting ready for the day it > will work, and have just jumped the gun - believing in early > preparation > or something). I'd like to be able to ignore that (no matter what > router advertises it - so lower level packet filtering doesn't help). > > kre > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 19 09:07:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JG7bxq022350; Thu, 19 Jun 2003 09:07:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5JG7bQb022349; Thu, 19 Jun 2003 09:07:37 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JG7Wxq022342 for ; Thu, 19 Jun 2003 09:07:32 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5JG5bGq021223 for ; Thu, 19 Jun 2003 09:05:37 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5JG5Wht009005 for ; Thu, 19 Jun 2003 10:05:32 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGQ00CHMKP7T9@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 19 Jun 2003 10:05:32 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGQ00C63KP612@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 19 Jun 2003 10:05:31 -0600 (MDT) Date: Thu, 19 Jun 2003 09:07:26 -0700 From: Alain Durand Subject: Re: Next steps on the IPv6 Node requirements draft In-reply-to: <12731.1056020197@munnari.OZ.AU> To: Robert Elz Cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Message-id: <1ED6D618-A270-11D7-90A5-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, June 19, 2003, at 03:56 AM, Robert Elz wrote: > It is generally harmless to own an extra address though, having the > statelessly configured one, as well as a dhcp supplied one should not > cause any harm. Not sure. Two reasons: - There may be filters in place, for example that only allows DHCP assigned addresses to go out. (this is not pure fantasy, I've heard people willing to do just that in hot spots). - There are reverse DNS issues. They may point to 2 different names or more likely, the stateless autoconfigured address won't resolve to a name, where the DHCP one will. As default address selection does not (yet?) say to prefer the DHCP one, logs and/or (very) weak security/authentication mechanisms based on DNS reverse lookup will work randomly. - 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 Jun 19 09:32:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JGW1xq022615; Thu, 19 Jun 2003 09:32:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5JGW0iC022614; Thu, 19 Jun 2003 09:32:00 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JGVuxq022607 for ; Thu, 19 Jun 2003 09:31:56 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5JGU1Nh004561 for ; Thu, 19 Jun 2003 09:30:01 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5JGTtep026068 for ; Thu, 19 Jun 2003 10:29:56 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29387; Thu, 19 Jun 2003 12:29:51 -0400 (EDT) Message-Id: <200306191629.MAA29387@ietf.org> From: iesg-secretary@ietf.org To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com Subject: UPDATE: Document Action: IPv6 Global Unicast Address Format to Informational Date: Thu, 19 Jun 2003 12:29:51 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk PLEASE NOTE: THE FOLLOWING ANNOUNCEMENT WAS PREMATURE AND SHOULD BE IGNORED. -------------------------- The IESG has approved the Internet-Draft 'IPv6 Global Unicast Address Format' as an Informational RFC. This document will replace RFC2374 and reclassify RFC 2374 (and the TLA/NLA structure described there) as historic. This document is the product of the IP Version 6 Working Group. The IESG contact persons are Thomas Narten and Erik Nordmark. Technical Summary RFC2374 "An IPv6 Aggregatable Global Unicast Address Format" defined an IPv6 address allocation structure that includes TLA (Top Level Aggregator) and NLA (Next Level Aggregator). This document replaces RFC2374, and makes RFC 2374 and the TLA/NLA structure historic. Working Group Summary There was support for this in the WG; this document documents what the WG decided quite some time ago. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 19 09:32:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JGWnxq022697; Thu, 19 Jun 2003 09:32:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5JGWnWk022696; Thu, 19 Jun 2003 09:32:49 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JGWhxq022687 for ; Thu, 19 Jun 2003 09:32:43 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5JGUmNh004966 for ; Thu, 19 Jun 2003 09:30:48 -0700 (PDT) Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5JGUfWP012970 for ; Thu, 19 Jun 2003 10:30:42 -0600 (MDT) Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Thu, 19 Jun 2003 17:30:53 +0100 Message-ID: From: matthew.ford@bt.com To: Alain.Durand@Sun.COM, kre@munnari.OZ.AU Cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Next steps on the IPv6 Node requirements draft Date: Thu, 19 Jun 2003 17:30:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Alain Durand [mailto:Alain.Durand@Sun.COM] > Sent: 19 June 2003 17:07 > > On Thursday, June 19, 2003, at 03:56 AM, Robert Elz wrote: > > It is generally harmless to own an extra address though, having the > > statelessly configured one, as well as a dhcp supplied one > should not > > cause any harm. > > Not sure. Two reasons: > - There may be filters in place, for example that only > allows DHCP assigned addresses to go out. > (this is not pure fantasy, I've heard people willing > to do just > that in hot spots). Certainly it is not fantasy. Indeed I expect to become the norm for all public access networks. Mat. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 19 09:47:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JGlMxq023408; Thu, 19 Jun 2003 09:47:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5JGlLRU023407; Thu, 19 Jun 2003 09:47:21 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JGlIxq023400 for ; Thu, 19 Jun 2003 09:47:18 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5JGjNNh010533 for ; Thu, 19 Jun 2003 09:45:23 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5JGjHht026177 for ; Thu, 19 Jun 2003 10:45:17 -0600 (MDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h5JGjGi8129022 for ; Thu, 19 Jun 2003 12:45:16 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h5JGjFkY065626 for ; Thu, 19 Jun 2003 12:45:15 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h5JGkA8k017611 for ; Thu, 19 Jun 2003 12:46:10 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.5/Submit) with ESMTP id h5JGkAga017606 for ; Thu, 19 Jun 2003 12:46:10 -0400 Message-Id: <200306191646.h5JGkAga017606@rotala.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: Re: Document Action: IPv6 Global Unicast Address Format to Informational In-Reply-To: Message from iesg-secretary@ietf.org of "Wed, 18 Jun 2003 18:00:41 EDT." <200306182200.SAA01883@ietf.org> Date: Thu, 19 Jun 2003 12:46:10 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The IESG has approved the Internet-Draft 'IPv6 Global Unicast > Address Format' as an > Informational RFC. This document will replace RFC2374 and > reclassify RFC 2374 (and the TLA/NLA structure described there) > as historic. This announcement was premature; there are still ongoing discussions on some wording. To cut to the chase, one of the IESG comments (which actually came from one of Randy's OPS reviewers) was: >***** o IPv6 Global Unicast Address Format (Informational) > > Token: Narten, Thomas > Note: An IETF LC call is needed, as this reclassifies RFC 2374 > historic.; last call expires 2003-04-08. my concern with this note is that at the top of page 3 the diagram implies that there is a single global routing prefix, followed by a subnet id. the text says that the global-routing-prefix is typically hierarchically structured, which implies that it is not a single global routing prefix but has some internal structure, with higher and lower levels of prefix and so on and so forth. it _might_ be nice if the authors were to do a bit of text editing and try and get the diagram to say the same thing (eliminating the implication in the diagram that there is exactly 1 prefix). also, the text and diagram sort of imply that there is one level of 'subnet id' that would be available to a 'site'. this is not completely true. my isp may allocate me a /32, leaving me 32 bits to play with which i may in turn make hierarchical allocations out of. again, some text twiddling might be nice here. There was further discussion, which eventually led to a proposal from Bob: Bob Hinden writes: > >Okay, it sounds like we're in agreement here. Bob, does this > >work for you? Any remaining questions? > Works for me. How about if I change the text: > where the global routing prefix is a (typically hierarchically- > structured) value assigned to a site (a cluster of subnets/links), > the subnet ID is an identifier of a subnet within the site, and the > interface ID is as defined in section 2.5.1 of [ARCH]. > to: > where the global routing prefix is a (typically hierarchically- > structured) value assigned to a site (a cluster of subnets/links), > the subnet ID is an identifier of a subnet within the site, and the > interface ID is as defined in section 2.5.1 of [ARCH]. The global > routing prefix is designed to be hierarchically structured by > the RIRs and ISPs, and the subnet field is designed to be hierarchically > structured by site administrators. With this change, the IESG is expected to approve the document. Is this OK with everyone? If so, we either need to reissue the document or ask for an RFC editor note. I can go either way. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 19 09:58:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JGwsxq023921; Thu, 19 Jun 2003 09:58:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5JGwsRA023920; Thu, 19 Jun 2003 09:58:54 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JGwoxq023913 for ; Thu, 19 Jun 2003 09:58:50 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5JGutNh014998 for ; Thu, 19 Jun 2003 09:56:55 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5JGunep012307 for ; Thu, 19 Jun 2003 10:56:50 -0600 (MDT) Received: from IDLEWYLDE.windriver.com ([147.11.233.50]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA00758; Thu, 19 Jun 2003 09:56:16 -0700 (PDT) Message-Id: <5.1.0.14.2.20030619125143.04616db8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Jun 2003 12:52:19 -0400 To: Thomas Narten From: Margaret Wasserman Subject: Re: Document Action: IPv6 Global Unicast Address Format to Informational Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200306191646.h5JGkAga017606@rotala.raleigh.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 At 12:46 PM 6/19/2003 -0400, Thomas Narten wrote: >Is this OK with everyone? > >If so, we either need to reissue the document or ask for an RFC editor >note. I can go either way. If it is okay with everyone, let's just re-issue the document. I think that would be cleaner. 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 Jun 19 14:48:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JLmAxq025765; Thu, 19 Jun 2003 14:48:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5JLmAfb025764; Thu, 19 Jun 2003 14:48:10 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5JLm6xq025757 for ; Thu, 19 Jun 2003 14:48:06 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5JLkBNh010695 for ; Thu, 19 Jun 2003 14:46:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5JLk6ht025272 for ; Thu, 19 Jun 2003 15:46:06 -0600 (MDT) 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 OAA11330; Thu, 19 Jun 2003 14:46:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5JLk4P02012; Thu, 19 Jun 2003 14:46:04 -0700 X-mProtect: <200306192146> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (139.92.247.160, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdegpdLn; Thu, 19 Jun 2003 14:46:02 PDT Message-Id: <4.3.2.7.2.20030619144503.02e78180@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jun 2003 14:45:42 -0700 To: Margaret Wasserman From: Bob Hinden Subject: Re: Document Action: IPv6 Global Unicast Address Format to Informational Cc: Thomas Narten , ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030619125143.04616db8@mail.windriver.com> References: <200306191646.h5JGkAga017606@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, I just submitted it. Bob At 09:52 AM 6/19/2003, Margaret Wasserman wrote: >At 12:46 PM 6/19/2003 -0400, Thomas Narten wrote: >>Is this OK with everyone? >> >>If so, we either need to reissue the document or ask for an RFC editor >>note. I can go either way. > >If it is okay with everyone, let's just re-issue the document. >I think that would be cleaner. > >Margaret > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 19 18:32:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5K1WJxq027558; Thu, 19 Jun 2003 18:32:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5K1WJFq027557; Thu, 19 Jun 2003 18:32:19 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5K1WFxq027550 for ; Thu, 19 Jun 2003 18:32:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5K1UKGq026064 for ; Thu, 19 Jun 2003 18:30:20 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h5K1UF4Z011600 for ; Thu, 19 Jun 2003 18:30:15 -0700 (PDT) Subject: RE: Document Action: IPv6 Global Unicast Address Format to Informational MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jun 2003 18:30:49 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F8AF@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Document Action: IPv6 Global Unicast Address Format to Informational Thread-Index: AcM2gxHTq5B1DvbqSM2l8Ii2KboG5wARnZ7A From: "Michel Py" To: "Thomas Narten" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5K1WGxq027551 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, > The global routing prefix is designed to be hierarchically > structured by the RIRs and ISPs, and the subnet field is > designed to be hierarchically structured by site administrators. > Is this OK with everyone? I'm OK with it, but I'll make a quick comment: One (it not the) reason why the routing prefix appears as one field in the diagram is because we removed the TLA and NLA boundaries in it. A twisted mind could read the additional text quoted above as an attempt to return to a more rigidly structured routing prefix. That being said, ship it. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 19 19:06:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5K26exq027866; Thu, 19 Jun 2003 19:06:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5K26e7K027865; Thu, 19 Jun 2003 19:06:40 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5K26axq027855 for ; Thu, 19 Jun 2003 19:06:36 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5K24eNh010860 for ; Thu, 19 Jun 2003 19:04:40 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5K24Y4Z024669 for ; Thu, 19 Jun 2003 19:04:35 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id F2D6289; Fri, 20 Jun 2003 11:04:31 +0900 (JST) To: Alain Durand Cc: Robert Elz , john.loughney@nokia.com, ipng@sunroof.eng.sun.com In-reply-to: Alain.Durand's message of Thu, 19 Jun 2003 09:07:26 MST. <1ED6D618-A270-11D7-90A5-00039376A6AA@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Next steps on the IPv6 Node requirements draft From: itojun@iijlab.net Date: Fri, 20 Jun 2003 11:04:31 +0900 Message-Id: <20030620020431.F2D6289@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - There are reverse DNS issues. They may point to 2 different names or > more likely, the stateless autoconfigured address won't resolve to > a name, where the DHCP one will. As default address selection does > not (yet?) say to prefer the DHCP one, logs and/or (very) weak >security/authentication > mechanisms based on DNS reverse lookup will work randomly. we don't have any standard wrt DNS registration of autoconfigured addresses, so you can't say that "stateless autoconfigured addresse won't resolve to a name". the end node could register PTR record by DNS dynamic update, for instance. 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 Jun 19 19:13:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5K2DLxq028145; Thu, 19 Jun 2003 19:13:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5K2DLfm028144; Thu, 19 Jun 2003 19:13:21 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5K2DFxq028125 for ; Thu, 19 Jun 2003 19:13:15 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5K2BKGq006196 for ; Thu, 19 Jun 2003 19:11:20 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5K2BFep012568 for ; Thu, 19 Jun 2003 20:11:15 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGR00C05CQQQA@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 19 Jun 2003 20:11:15 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGR00CHACQPMR@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 19 Jun 2003 20:11:14 -0600 (MDT) Date: Thu, 19 Jun 2003 19:13:09 -0700 From: Alain Durand Subject: Re: Next steps on the IPv6 Node requirements draft In-reply-to: <20030620020431.F2D6289@coconut.itojun.org> To: itojun@iijlab.net Cc: Robert Elz , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, I guess you missed the "more likely" part of my sentence. I agree we don't have any standard wrt DNS registration of autoconfigured addresses, and the current deployment practices show that it is a pain to do it either manually or with dnsupdate (you have a key distribution problem), so the reality is that they are seldom published and are not likely to resolve. - Alain. On Thursday, June 19, 2003, at 07:04 PM, itojun@iijlab.net wrote: >> - There are reverse DNS issues. They may point to 2 different names >> or >> more likely, the stateless autoconfigured address won't resolve to >> a name, where the DHCP one will. As default address selection does >> not (yet?) say to prefer the DHCP one, logs and/or (very) weak >> security/authentication >> mechanisms based on DNS reverse lookup will work randomly. > > we don't have any standard wrt DNS registration of autoconfigured > addresses, so you can't say that "stateless autoconfigured addresse > won't resolve to a name". the end node could register PTR record > by DNS dynamic update, for instance. > > 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 Jun 19 19:37:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5K2brxq028572; Thu, 19 Jun 2003 19:37:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5K2brSF028571; Thu, 19 Jun 2003 19:37:53 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5K2bmxq028561 for ; Thu, 19 Jun 2003 19:37:49 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5K2ZrGq012652 for ; Thu, 19 Jun 2003 19:35:53 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5K2ZmLv006669 for ; Thu, 19 Jun 2003 19:35:48 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id CFBB492 for ; Fri, 20 Jun 2003 11:35:45 +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: playground.sun.com unreach (IPv6) From: itojun@iijlab.net Date: Fri, 20 Jun 2003 11:35:45 +0900 Message-Id: <20030620023545.CFBB492@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk playground.sun.com (IPv6) is unreachable. please fix. it is highly annoying that IPv6 side is unreachable while IPv4 side is alive. please integrate IPv4 side and IPv6 side, or terminate IPv6 side if it cannot provide a stable service. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 20 11:31:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5KIVvXW005618; Fri, 20 Jun 2003 11:31:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5KIVvou005617; Fri, 20 Jun 2003 11:31:57 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5KIVoXW005603 for ; Fri, 20 Jun 2003 11:31:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5KITrNh015541 for ; Fri, 20 Jun 2003 11:29:53 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5KITgmF006690 for ; Fri, 20 Jun 2003 11:29:47 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23851; Fri, 20 Jun 2003 14:29:40 -0400 (EDT) Message-Id: <200306201829.OAA23851@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-03.txt Date: Fri, 20 Jun 2003 14:29:40 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IP Forwarding Table MIB Author(s) : M. Wasserman, B. Haberman Filename : draft-ietf-ipv6-rfc2096-update-03.txt Pages : 30 Date : 2003-6-20 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-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-rfc2096-update-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2096-update-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-20140734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2096-update-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2096-update-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-20140734.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 Jun 20 11:31:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5KIVxXW005621; Fri, 20 Jun 2003 11:31:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5KIVwLS005620; Fri, 20 Jun 2003 11:31:58 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5KIVpXW005610 for ; Fri, 20 Jun 2003 11:31:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5KITtGq028961 for ; Fri, 20 Jun 2003 11:29:55 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5KITmmF006744 for ; Fri, 20 Jun 2003 11:29:49 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23874; Fri, 20 Jun 2003 14:29:47 -0400 (EDT) Message-Id: <200306201829.OAA23874@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-03.txt Date: Fri, 20 Jun 2003 14:29:46 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Global Unicast Address Format Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipv6-unicast-aggr-v2-03.txt Pages : 5 Date : 2003-6-20 RFC2374 'An IPv6 Aggregatable Global Unicast Address Format' defined an IPv6 address allocation structure that includes TLA (Top Level Aggregator) and NLA (Next Level Aggregator). This document replaces RFC2374, and makes RFC 2374 and the TLA/NLA structure historic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-unicast-aggr-v2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-20140744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-unicast-aggr-v2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-20140744.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 Jun 20 15:41:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5KMf2XW008000; Fri, 20 Jun 2003 15:41:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5KMf1lp007999; Fri, 20 Jun 2003 15:41:01 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5KMewXW007992 for ; Fri, 20 Jun 2003 15:40:58 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5KMd2Nh018910 for ; Fri, 20 Jun 2003 15:39:02 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5KMcu7U000582 for ; Fri, 20 Jun 2003 16:38:57 -0600 (MDT) 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 PAA21361 for ; Fri, 20 Jun 2003 15:38:56 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5KMct601790 for ; Fri, 20 Jun 2003 15:38:55 -0700 X-mProtect: <200306202238> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdyo6CCp; Fri, 20 Jun 2003 15:38:53 PDT Message-ID: <3EF38D8B.4070906@iprg.nokia.com> Date: Fri, 20 Jun 2003 15:41:15 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Requirements for Limited-Scope Unicast Addressing in IPv6 References: <20030620023545.CFBB492@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 A new draft has been posted to the I-D repository; details can be found below. Pls send comments to the list. Fred Templin ftemplin@iprg.nokia.com --- cut here --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Limited-Scope Unicast Addressing in IPv6 Author(s) : F. Templin Filename : draft-templin-lsareqts-00.txt Pages : 9 Date : 2003-6-20 The IPv6 addressing architecture specifies global and local-use unicast addressing schemes. Recent consensus call in the IPng working group has deprecated site-local addressing due in part to its inherent ambiguity. This document outlines requirements for use in evaluating candidate proposals for a replacement scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-templin-lsareqts-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 Fri Jun 20 16:00:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5KN0EXW008267; Fri, 20 Jun 2003 16:00:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5KN0EN6008266; Fri, 20 Jun 2003 16:00:14 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5KN09XW008258 for ; Fri, 20 Jun 2003 16:00:09 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5KMwDGq026640 for ; Fri, 20 Jun 2003 15:58:13 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5KMw87U008318 for ; Fri, 20 Jun 2003 16:58:08 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGS00JP9YGVL7@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 20 Jun 2003 16:58:08 -0600 (MDT) Received: from sun.com ([129.146.18.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGS00CHLYGUMR@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 20 Jun 2003 16:58:07 -0600 (MDT) Date: Fri, 20 Jun 2003 15:58:06 -0700 From: Alain Durand Subject: Re: playground.sun.com unreach (IPv6) To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Message-id: <3EF3917E.7060704@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: <20030620023545.CFBB492@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please change tone. After I'll see what I can do. - Alain. itojun@iijlab.net wrote: > playground.sun.com (IPv6) is unreachable. please fix. > > it is highly annoying that IPv6 side is unreachable while IPv4 side is > alive. please integrate IPv4 side and IPv6 side, or terminate IPv6 > side if it cannot provide a stable service. > >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 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 20 21:51:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5L4ptXW009961; Fri, 20 Jun 2003 21:51:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5L4pt8U009960; Fri, 20 Jun 2003 21:51:55 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5L4pqXW009953 for ; Fri, 20 Jun 2003 21:51:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5L4nuNh010207 for ; Fri, 20 Jun 2003 21:49:56 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h5L4nog5009128 for ; Fri, 20 Jun 2003 21:49:51 -0700 (PDT) Subject: RE: Requirements for Limited-Scope Unicast Addressing in IPv6 Date: Fri, 20 Jun 2003 21:50:25 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F8BE@server2000.arneill-py.sacramento.ca.us> 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: Requirements for Limited-Scope Unicast Addressing in IPv6 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Index: AcM3fWPy4bEESx/CS5GSJM4W/ZhT/QAMlS/A From: "Michel Py" To: "Fred Templin" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5L4pqXW009954 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Fred Templin wrote: > A limited-scope addressing scheme is needed to replace the > now-deprecated site-local scheme from [RFC3513] The site-local scheme is not deprecated until there is a published document that states otherwise which will not happen until all the outstanding appeals have been resolved. Therefore the site-local scheme from RFC3513 which is in the standards track is still valid. Should you push this text to be published I can assure you that it will be appealed as well all the way to the IAB. 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 Jun 23 10:07:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NH7vXW018647; Mon, 23 Jun 2003 10:07:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5NH7uMu018646; Mon, 23 Jun 2003 10:07:56 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NH7rXW018639 for ; Mon, 23 Jun 2003 10:07:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5NH5tGq014052 for ; Mon, 23 Jun 2003 10:05:55 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5NH5ng5028021 for ; Mon, 23 Jun 2003 10:05:49 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA10543; Mon, 23 Jun 2003 10:05:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5NH5lQ11314; Mon, 23 Jun 2003 10:05:47 -0700 X-mProtect: <200306231705> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6qcsUm; Mon, 23 Jun 2003 10:05:46 PDT Message-ID: <3EF73408.7040404@iprg.nokia.com> Date: Mon, 23 Jun 2003 10:08:24 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 References: <963621801C6D3E4A9CF454A1972AE8F504F8BE@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk True, this is a -00 document, but you are distracting attention from the main points of the document if you choose to focus on the site-local deprecation question. The main points of the document are found in sections 3 ("Limited-Scope Addressing Requirements") and 4 ("Scenarios Requiring Limited-Scope Addressing"), and I'd like to see some discussion relative to that text. Fred ftemplin@iprg.nokia.com http://www.ietf.org/internet-drafts/draft-templin-lsareqts-00.txt Michel Py wrote: >>Fred Templin wrote: >>A limited-scope addressing scheme is needed to replace the >>now-deprecated site-local scheme from [RFC3513] >> >> > >The site-local scheme is not deprecated until there is a published >document that states otherwise which will not happen until all the >outstanding appeals have been resolved. Therefore the site-local scheme >from RFC3513 which is in the standards track is still valid. Should you >push this text to be published I can assure you that it will be appealed >as well all the way to the IAB. > >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 Mon Jun 23 10:17:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NHHuXW018818; Mon, 23 Jun 2003 10:17:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5NHHuGO018817; Mon, 23 Jun 2003 10:17:56 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NHHrXW018810 for ; Mon, 23 Jun 2003 10:17:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5NHFsGq018353 for ; Mon, 23 Jun 2003 10:15:54 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h5NHFng5003914 for ; Mon, 23 Jun 2003 10:15:49 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Requirements for Limited-Scope Unicast Addressing in IPv6 Date: Mon, 23 Jun 2003 10:16:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F8CC@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Requirements for Limited-Scope Unicast Addressing in IPv6 Thread-Index: AcM5qcju82+RKndyQYeYxA37wKNsoQAAM8xw From: "Michel Py" To: "Fred Templin" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5NHHrXW018811 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Fred Templin wrote: > True, this is a -00 document, And an attempt to legitimize the deprecation by trying to put the horse back in front of the car, the problem is that you still don't have a horse. This document is further proof that there is nothing to replace site-locals, which is the reason there is no ground to deprecate them in the first place. 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 Jun 23 10:24:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NHOMXW019093; Mon, 23 Jun 2003 10:24:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5NHOMa4019092; Mon, 23 Jun 2003 10:24:22 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NHOHXW019067 for ; Mon, 23 Jun 2003 10:24:17 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5NHMIGq021430 for ; Mon, 23 Jun 2003 10:22:19 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5NHMDg5007948 for ; Mon, 23 Jun 2003 10:22:13 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA12107; Mon, 23 Jun 2003 10:22:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5NHMCD32551; Mon, 23 Jun 2003 10:22:12 -0700 X-mProtect: <200306231722> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmRNoAl; Mon, 23 Jun 2003 10:22:11 PDT Message-ID: <3EF737E1.3020908@iprg.nokia.com> Date: Mon, 23 Jun 2003 10:24:49 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 References: <963621801C6D3E4A9CF454A1972AE8F504F8CC@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You make my point; you are attempting to cast this document as something that its not. Look at the requirements and scenarios, then bring your candidate schemes - bring RFC 3513 site-locals as a candidate scheme if you'd like, but it loses based on ambiguity and non-portability (to name just two) straight out of the barrel. Fred ftemplin@iprg.nokia.com http://www.ietf.org/internet-drafts/draft-templin-lsareqts-00.txt Michel Py wrote: >>Fred Templin wrote: >>True, this is a -00 document, >> >> > >And an attempt to legitimize the deprecation by trying to put the horse >back in front of the car, the problem is that you still don't have a >horse. > >This document is further proof that there is nothing to replace >site-locals, which is the reason there is no ground to deprecate them in >the first place. > >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 Jun 23 10:55:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NHt2XW020933; Mon, 23 Jun 2003 10:55:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5NHt2IB020932; Mon, 23 Jun 2003 10:55:02 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NHsuXW020905 for ; Mon, 23 Jun 2003 10:54:56 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5NHqvNh009772 for ; Mon, 23 Jun 2003 10:52:57 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5NHqpY1001986 for ; Mon, 23 Jun 2003 11:52:52 -0600 (MDT) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 198E115255; Tue, 24 Jun 2003 02:52:45 +0900 (JST) Date: Tue, 24 Jun 2003 02:52:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mark.Andrews@isc.org Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Address validation In-Reply-To: <200304232241.h3NMfrdV067607@drugs.dv.isc.org> References: <20030423153044.GB33177@alicia.nttmcl.com> <200304232241.h3NMfrdV067607@drugs.dv.isc.org> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 24 Apr 2003 08:41:53 +1000, >>>>> Mark.Andrews@isc.org said: > Is the following a legal IPv6 literal? The RFC's are unclear > about whether leading zeros are allowed or not if they would > make a segment more than 4 character wide. > 1234:1234:1234:1234:01234:: > Note I would never expect inet_ntop() to produce the above. > We were discussing this when reviewing our inet_pton() > implementation. Apparently there has been no consensus on this. The source of the lack of consensus is an ambiguous text in RFC 3513: 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the hexadecimal values of the eight 16-bit pieces of the address. Some people interpret "01234" as a 16-bit piece, and others do not. If we can only refer to this text, I don't think we can go further. Meanwhile, a recent draft draft-main-ipaddr-text-rep-00.txt points out that RFC 2373, the previous version of the address architecture RFC, had an ABNF than invalidated "01234": IPv6address = hexpart [ ":" IPv4address ] IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6prefix = hexpart "/" 1*2DIGIT hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG And the draft itself defines a revised and precise version of the ABNF, which also prohibits "01234" from being used as a "16-bit piece." I don't remember why the ABNF was removed in RFC 3513, but, regardless of the reason, I believe the address architecture authors actually intend at most four hex digits. So, assuming we can agree on draft-main-ipaddr-text-rep-00.txt and the draft will clarify RFC 3513, can we conclude here that inet_pton() should reject more than four hex digits as a 16-bit piece? 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 Jun 23 11:08:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NI8DXW021538; Mon, 23 Jun 2003 11:08:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5NI8DkD021537; Mon, 23 Jun 2003 11:08:13 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NI8AXW021530 for ; Mon, 23 Jun 2003 11:08:10 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5NI6BGq011093 for ; Mon, 23 Jun 2003 11:06:11 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h5NI66mF006068 for ; Mon, 23 Jun 2003 11:06:06 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Requirements for Limited-Scope Unicast Addressing in IPv6 Date: Mon, 23 Jun 2003 11:06:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F8CD@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: Requirements for Limited-Scope Unicast Addressing in IPv6 Thread-Index: AcM5rBMgQJNgRdIVR6+Z3yRuPNfPegABPlqA From: "Michel Py" To: "Fred Templin" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5NI8AXW021531 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > bring RFC 3513 site-locals as a candidate scheme if you'd like, > but it loses based on ambiguity and non-portability (to name > just two) straight out of the barrel. Loses to what? Since when requirements equates a solution? Requirements are wishful thinking, no more. We don't throw away a published standard with running code from multiple vendors in exchange for the promise that _maybe_ someone will be able to produce a replacement that meets the requirements. 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 Jun 23 11:16:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NIGoXW021725; Mon, 23 Jun 2003 11:16:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5NIGowl021724; Mon, 23 Jun 2003 11:16:50 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NIGkXW021714 for ; Mon, 23 Jun 2003 11:16:46 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5NIEmNh021808 for ; Mon, 23 Jun 2003 11:14:48 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5NIEgY1010818 for ; Mon, 23 Jun 2003 12:14:42 -0600 (MDT) 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 LAA15274; Mon, 23 Jun 2003 11:14:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5NIEfG32508; Mon, 23 Jun 2003 11:14:41 -0700 X-mProtect: <200306231814> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddaRTsv; Mon, 23 Jun 2003 11:14:40 PDT Message-ID: <3EF7442E.5060702@iprg.nokia.com> Date: Mon, 23 Jun 2003 11:17:18 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 References: <963621801C6D3E4A9CF454A1972AE8F504F8CD@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Loses to the proposal that best satisfies the requirements. If you don't like the requirements, then suggest some of your own. Fred ftemplin@iprg.nokia.com http://www.ietf.org/internet-drafts/draft-templin-lsareqts-00.txt Michel Py wrote: >>bring RFC 3513 site-locals as a candidate scheme if you'd like, >>but it loses based on ambiguity and non-portability (to name >>just two) straight out of the barrel. >> >> > > >Loses to what? Since when requirements equates a solution? >Requirements are wishful thinking, no more. We don't throw away a >published standard with running code from multiple vendors in exchange >for the promise that _maybe_ someone will be able to produce a >replacement that meets the requirements. > >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 Jun 23 11:34:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NIYbXW022098; Mon, 23 Jun 2003 11:34:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5NIYbEQ022097; Mon, 23 Jun 2003 11:34:37 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NIYXXW022090 for ; Mon, 23 Jun 2003 11:34:33 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5NIWZNh029717 for ; Mon, 23 Jun 2003 11:32:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5NIWTY1017795 for ; Mon, 23 Jun 2003 12:32:30 -0600 (MDT) Received: from cisco.com (171.68.223.137) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2003 11:34:19 -0800 Received: from cisco.com (sjc-vpn3-97.cisco.com [10.21.64.97]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5NIWRQx014283; Mon, 23 Jun 2003 11:32:27 -0700 (PDT) Message-ID: <3EF747BA.6060806@cisco.com> Date: Mon, 23 Jun 2003 11:32:26 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py CC: Fred Templin , ipng@sunroof.eng.sun.com Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 References: <963621801C6D3E4A9CF454A1972AE8F504F8CD@server2000.arneill-py.sacramento.ca.us> In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F8CD@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, > We don't throw away a > published standard with running code from multiple vendors in exchange > for the promise that _maybe_ someone will be able to produce a > replacement that meets the requirements. It is true that we should not make standards where there is no running code. However, Running code != good practices or even good ideas. And we do have running code (with both good and bad ideas) for now while we figure out this question- it's called IPv4. Eliot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 23 11:58:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NIw6XW022408; Mon, 23 Jun 2003 11:58:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5NIw5S2022407; Mon, 23 Jun 2003 11:58:05 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NIw2XW022400 for ; Mon, 23 Jun 2003 11:58:02 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5NIu4Gq002979 for ; Mon, 23 Jun 2003 11:56:04 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5NItwY1026785 for ; Mon, 23 Jun 2003 12:55:58 -0600 (MDT) Content-class: urn:content-classes:message Subject: RE: Requirements for Limited-Scope Unicast Addressing in IPv6 Date: Mon, 23 Jun 2003 11:56:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F8CE@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: Requirements for Limited-Scope Unicast Addressing in IPv6 Thread-Index: AcM5tfMNlLHcnHWBSzyZ271eZwLtMwAAo73A From: "Michel Py" To: "Eliot Lear" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5NIw2XW022401 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eliot, >> Michel Py wrote: >> We don't throw away a published standard with running code >> from multiple vendors in exchange for the promise that >> _maybe_ someone will be able to produce a replacement that >> meets the requirements. > Eliot Lear wrote: > It is true that we should not make standards where there is no > running code. However, Running code != good practices or even > good ideas. And we do have running code (with both good and > bad ideas) for now while we figure out this question- it's > called IPv4. I will remind you that the official IETF position is that IPv6 is in production, which led to the creation of the v6ops WG. IPv6 is no longer a prototype we can tinker with. Or maybe you recommend a gracious restart? 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 Jun 23 12:00:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NJ0fXW022481; Mon, 23 Jun 2003 12:00:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5NJ0fY1022480; Mon, 23 Jun 2003 12:00:41 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NJ0bXW022473 for ; Mon, 23 Jun 2003 12:00:37 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5NIwdNh009482 for ; Mon, 23 Jun 2003 11:58:39 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5NIwXgr008563 for ; Mon, 23 Jun 2003 12:58:33 -0600 (MDT) Content-class: urn:content-classes:message Subject: RE: Requirements for Limited-Scope Unicast Addressing in IPv6 Date: Mon, 23 Jun 2003 11:59:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F5067261@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: Requirements for Limited-Scope Unicast Addressing in IPv6 Thread-Index: AcM5s2iPf2ocSPuOSdO7UYksLiPCpgABcJqw From: "Michel Py" To: "Fred Templin" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5NJ0cXW022474 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Fred Templin wrote: > Loses to the proposal that best satisfies the requirements. No more comments. The appeals will proceed as documented. 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 Jun 23 12:06:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NJ62XW022701; Mon, 23 Jun 2003 12:06:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5NJ62YJ022700; Mon, 23 Jun 2003 12:06:02 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NJ5wXW022693 for ; Mon, 23 Jun 2003 12:05:58 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5NJ40Gq007607 for ; Mon, 23 Jun 2003 12:04:00 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5NJ3sY1029968 for ; Mon, 23 Jun 2003 13:03:54 -0600 (MDT) 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 MAA17954; Mon, 23 Jun 2003 12:03:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5NJ3rd24692; Mon, 23 Jun 2003 12:03:53 -0700 X-mProtect: <200306231903> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjZKdiq; Mon, 23 Jun 2003 12:03:52 PDT Message-ID: <3EF74FB6.6030509@iprg.nokia.com> Date: Mon, 23 Jun 2003 12:06:30 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 References: <963621801C6D3E4A9CF454A1972AE8F5067261@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk None here, either; just to re-iterate the request for WG comments on: http://www.ietf.org/internet-drafts/draft-templin-lsareqts-00.txt Fred ftemplin@iprg.nokia.com Michel Py wrote: >No more 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 Mon Jun 23 13:01:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NK1CXW023223; Mon, 23 Jun 2003 13:01:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5NK1Bif023222; Mon, 23 Jun 2003 13:01:11 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5NK18XW023215 for ; Mon, 23 Jun 2003 13:01:08 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5NJxANh005387 for ; Mon, 23 Jun 2003 12:59:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5NJx47U000008 for ; Mon, 23 Jun 2003 13:59:04 -0600 (MDT) Received: from cisco.com (171.68.223.137) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2003 13:00:53 -0800 Received: from cisco.com (sjc-vpn3-97.cisco.com [10.21.64.97]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5NJx2Qx007647; Mon, 23 Jun 2003 12:59:02 -0700 (PDT) Message-ID: <3EF75C04.3000003@cisco.com> Date: Mon, 23 Jun 2003 12:59:00 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 References: <963621801C6D3E4A9CF454A1972AE8F504F8CE@server2000.arneill-py.sacramento.ca.us> In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F8CE@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: > I will remind you that the official IETF position is that IPv6 is in > production, which led to the creation of the v6ops WG. IPv6 is no longer > a prototype we can tinker with. Or maybe you recommend a [graceful] > restart? We as an organization have to be careful to not be so ossified that we don't learn from our mistakes. In this case, the organization feels that we made a mistake (this is not an invitation to argue the point again, but a statement of facts as I see it). As a matter of procedure, the document we are talking about is the addressing architecture, which is now in its second round as a Proposed Standard. It might as well go through a third round if we haven't gotten it right (and then a fourth if necessary). I am not suggesting at this time that IPv6 be completely torn up and started from scratch. What I am saying is that we have a working IPv4 Internet to fall back on when we find flaws in v6. Furthermore, let's not pretend that v6 is either so entrenched that we can make no changes or so fragile that we can make no changes.[*] Fred's proposal, it seems to me, takes the WG consensus and starts to do the rational thing, which is to lay out usage scenarios that need to be addressed in the solution space. I think he does need to stay in the requirements space a bit more by allowing for the possibility of other than scoped addresses (and thus my one comment about the draft), but in general his approach seems to me to be correct. Finally, let me make a comment about the appeal. I've been involved with working groups where they fragmented on different solutions and appeals were threatened and nasty names were used. The result were delays in implementation and deployment. Is that what you want? Or conversely, is it possible for you to take the consensus and build a working operating model with it? Eliot [*] By the way, IPv4 didn't get to be so prevalent without a lot of pain and a lot of trial and error. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 23 17:05:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5O058XW025930; Mon, 23 Jun 2003 17:05:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5O05731025929; Mon, 23 Jun 2003 17:05:07 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5O054XW025922 for ; Mon, 23 Jun 2003 17:05:04 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5O033x3008538 for ; Mon, 23 Jun 2003 17:03:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5O030ZV010561 for ; Mon, 23 Jun 2003 18:03:00 -0600 (MDT) 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 RAA03584; Mon, 23 Jun 2003 17:02:58 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5O02w128633; Mon, 23 Jun 2003 17:02:58 -0700 X-mProtect: <200306240002> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdT7vZ7u; Mon, 23 Jun 2003 17:02:56 PDT Message-Id: <4.3.2.7.2.20030623112301.02735318@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Jun 2003 17:02:05 -0700 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Bob Hinden Subject: Re: IPv6 Address validation Cc: Mark.Andrews@isc.org, ipng@sunroof.eng.sun.com In-Reply-To: References: <200304232241.h3NMfrdV067607@drugs.dv.isc.org> <20030423153044.GB33177@alicia.nttmcl.com> <200304232241.h3NMfrdV067607@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tatuya-san, > 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the > hexadecimal values of the eight 16-bit pieces of the address. > >Some people interpret "01234" as a 16-bit piece, and others do not. >If we can only refer to this text, I don't think we can go further. I don't think this case was considered explicitly, but in the tradition of "be liberal in what one receives" as long as the string results in 16-bits I think it is OK for an implementation to accept it. Another reason why I think this is OK is that the document also allows for less then four hex digits. In my view this confirms that there isn't a strict requirement for a number of digits, only that the field results in 16-bits. So "0", "01", "0123", and "01234" are OK, but "12345" is not. >Meanwhile, a recent draft draft-main-ipaddr-text-rep-00.txt points out >that RFC 2373, the previous version of the address architecture RFC, >had an ABNF than invalidated "01234": > > IPv6address = hexpart [ ":" IPv4address ] > IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT > > IPv6prefix = hexpart "/" 1*2DIGIT > > hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] > hexseq = hex4 *( ":" hex4) > hex4 = 1*4HEXDIG > >And the draft itself defines a revised and precise version of the >ABNF, which also prohibits "01234" from being used as a "16-bit >piece." > >I don't remember why the ABNF was removed in RFC 3513, but, regardless >of the reason, I believe the address architecture authors actually >intend at most four hex digits. The ABNF was removed from the document because what was specified was broken and at the time we couldn't find a working replacement. >So, assuming we can agree on draft-main-ipaddr-text-rep-00.txt and the >draft will clarify RFC 3513, can we conclude here that inet_pton() >should reject more than four hex digits as a 16-bit piece? I don't see the need as long as the result is 16-bits, but would like to see if there are other opinions. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 23 18:09:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5O19BXW026910; Mon, 23 Jun 2003 18:09:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5O19BrK026909; Mon, 23 Jun 2003 18:09:11 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5O198XW026902 for ; Mon, 23 Jun 2003 18:09:08 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5O179Gq001207 for ; Mon, 23 Jun 2003 18:07:09 -0700 (PDT) Received: from drugs.dv.isc.org (c17200.carlnfd2.nsw.optusnet.com.au [211.29.163.60]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5O173ZV027726 for ; Mon, 23 Jun 2003 19:07:03 -0600 (MDT) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h5O16t6A070752 for ; Tue, 24 Jun 2003 11:06:56 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306240106.h5O16t6A070752@drugs.dv.isc.org> To: ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: IPv6 Address validation In-reply-to: Your message of "Mon, 23 Jun 2003 17:02:05 MST." <4.3.2.7.2.20030623112301.02735318@mailhost.iprg.nokia.com> Date: Tue, 24 Jun 2003 11:06:55 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't see the need as long as the result is 16-bits, but would like to > see if there are other opinions. My opinion would be to reject more than 4 hex digits. -- 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 Jun 23 19:30:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5O2UOXW028821; Mon, 23 Jun 2003 19:30:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5O2UO4P028820; Mon, 23 Jun 2003 19:30:24 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5O2UJXW028810 for ; Mon, 23 Jun 2003 19:30:20 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5O2SKUY006549 for ; Mon, 23 Jun 2003 19:28:20 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5O2SEDT015429 for ; Mon, 23 Jun 2003 20:28:15 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5476189; Tue, 24 Jun 2003 11:28:12 +0900 (JST) To: Mark.Andrews@isc.org Cc: ipng@sunroof.eng.sun.com In-reply-to: Mark.Andrews's message of Tue, 24 Jun 2003 11:06:55 +1000. <200306240106.h5O16t6A070752@drugs.dv.isc.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 Address validation From: itojun@iijlab.net Date: Tue, 24 Jun 2003 11:28:12 +0900 Message-Id: <20030624022812.5476189@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I don't see the need as long as the result is 16-bits, but would like to >> see if there are other opinions. > My opinion would be to reject more than 4 hex digits. same here. 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 Jun 24 00:14:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5O7EoXW000853; Tue, 24 Jun 2003 00:14:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5O7EnHI000852; Tue, 24 Jun 2003 00:14:49 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5O7EkXW000845 for ; Tue, 24 Jun 2003 00:14:46 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5O7ClUY017248 for ; Tue, 24 Jun 2003 00:12:47 -0700 (PDT) Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5O7CdZV004401 for ; Tue, 24 Jun 2003 01:12:41 -0600 (MDT) Received: from lt38 ([192.168.0.249]) by galileo5.galileo.co.il (8.12.6/8.12.6) with SMTP id h5O8ANlH003245 for ; Tue, 24 Jun 2003 10:10:26 +0200 (GMT-2) Message-ID: <016c01c33a28$8d4b96f0$f900a8c0@lt38> From: "Nir Arad" To: References: <20030624022812.5476189@coconut.itojun.org> Subject: Re: IPv6 Address validation Date: Tue, 24 Jun 2003 10:13:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> I don't see the need as long as the result is 16-bits, but would like to > >> see if there are other opinions. > > My opinion would be to reject more than 4 hex digits. > > same here. > > itojun My vote, too, is to reject. -- Nir Arad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 24 01:51:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5O8pHXW001201; Tue, 24 Jun 2003 01:51:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5O8pH7u001200; Tue, 24 Jun 2003 01:51:17 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5O8pEXW001193 for ; Tue, 24 Jun 2003 01:51:14 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5O8nAUY013743 for ; Tue, 24 Jun 2003 01:49:10 -0700 (PDT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5O8n4ZV006066 for ; Tue, 24 Jun 2003 02:49:04 -0600 (MDT) Received: by mailhost.stack.nl (Postfix, from userid 65534) id C0BA61F006; Tue, 24 Jun 2003 10:49:02 +0200 (CEST) Received: from dragon.stack.nl (dragon.stack.nl [2001:610:1108:5011:207:e9ff:fe09:230]) by mailhost.stack.nl (Postfix) with ESMTP id 54A6D1F003; Tue, 24 Jun 2003 10:48:58 +0200 (CEST) Received: by dragon.stack.nl (Postfix, from userid 1600) id 48F495F187; Tue, 24 Jun 2003 10:48:58 +0200 (CEST) Date: Tue, 24 Jun 2003 10:48:58 +0200 From: Dean Strik To: Mark.Andrews@isc.org Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Address validation Message-ID: <20030624084858.GA48531@dragon.stack.nl> References: <4.3.2.7.2.20030623112301.02735318@mailhost.iprg.nokia.com> <200306240106.h5O16t6A070752@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200306240106.h5O16t6A070752@drugs.dv.isc.org> X-Editor: VIM Rulez! http://www.vim.org/ X-MUD: Outerspace - telnet://mud.stack.nl:3333 X-Really: Yes User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-4.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark.Andrews@isc.org wrote: > > I don't see the need as long as the result is 16-bits, but would like to > > see if there are other opinions. > > My opinion would be to reject more than 4 hex digits. RFC 2553, section 6.6: #define INET6_ADDRSTRLEN 46 I'm not 100% sure about the relevance of this, but it seems like a good reason not to allow exta digits. -- Dean C. Strik Eindhoven University of Technology dean@stack.nl | dean@ipnet6.org | http://www.ipnet6.org/ "This isn't right. This isn't even wrong." -- Wolfgang Pauli -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 24 02:23:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5O9NcXW001831; Tue, 24 Jun 2003 02:23:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5O9Nc5T001830; Tue, 24 Jun 2003 02:23:38 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5O9NYXW001818 for ; Tue, 24 Jun 2003 02:23:34 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5O9LZUY020997 for ; Tue, 24 Jun 2003 02:21:35 -0700 (PDT) Received: from mailout1.samsung.com ([203.254.224.24]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5O9LTZV016557 for ; Tue, 24 Jun 2003 03:21:29 -0600 (MDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HGZ00M01BBS2O@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Tue, 24 Jun 2003 18:21:28 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HGZ0000BBBSKQ@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Tue, 24 Jun 2003 18:21:28 +0900 (KST) Received: from OLNRAO ([107.108.4.198]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HGZ00608BBN5X@mmp2.samsung.com> for ipng@sunroof.eng.sun.com; Tue, 24 Jun 2003 18:21:28 +0900 (KST) Date: Tue, 24 Jun 2003 14:46:24 +0530 From: "O.L.N.Rao" Subject: Re: IPv6 Address validation To: hinden@iprg.nokia.com Cc: ipng@sunroof.eng.sun.com Message-id: <3EF816E8.000001.00468@OLNRAO.sisodomain.com> MIME-version: 1.0 X-Mailer: IncrediMail 2001 (1800814) Content-type: multipart/related; boundary="Boundary_(ID_2QLk8U2IHg9KqvgdjezAkw)"; type="multipart/alternative" X-Priority: 3 X-FID: FLAVOR00-NONE-0000-0000-000000000000 X-FVER: X-CNT: ; References: <4.3.2.7.2.20030623112301.02735318@mailhost.iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Boundary_(ID_2QLk8U2IHg9KqvgdjezAkw) Content-type: multipart/alternative; boundary="Boundary_(ID_Nn+3ecJYTP/lle0AOwAHPw)" --Boundary_(ID_Nn+3ecJYTP/lle0AOwAHPw) Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Bob, > I don't think this case was considered explicitly, but in the tradition of > "be liberal in what one receives" as long as the string results in 16-bits > I think it is OK for an implementation to accept it. Another reason why I > think this is OK is that the document also allows for less then four hex > digits. In my view this confirms that there isn't a strict requirement for > a number of digits, only that the field results in 16-bits. So "0", "01", > "0123", and "01234" are OK, but "12345" is not. >From your comments, 012345, 0012345, 00012345...etc are all acceptable !! But, to what extent should be allowed and why ? Instead of going towards this, prefer not to be liberal in this case at least. Regards, O.L.N.Rao --Boundary_(ID_Nn+3ecJYTP/lle0AOwAHPw) Content-type: Text/HTML; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Bob,
 
> I don't think this case was considered explicitly, but in the tradition of
> "be liberal in what one receives" as long as the string results in 16-bits
> I think it is OK for an implementation to accept it. Another reason why I
> think this is OK is that the document also allows for less then four hex
> digits. In my view this confirms that there isn't a strict requirement for
> a number of digits, only that the field results in 16-bits. So "0", "01",
> "0123", and "01234" are OK, but "12345" is not.

From your comments,
    012345, 0012345, 00012345...etc are all acceptable !!
 
But, to what extent should be allowed and why ?
Instead of going towards this, prefer not to be liberal in this case at least. 
 
 
Regards,
O.L.N.Rao 
____________________________________________________
  IncrediMail - Email has finally evolved - Click Here --Boundary_(ID_Nn+3ecJYTP/lle0AOwAHPw)-- --Boundary_(ID_2QLk8U2IHg9KqvgdjezAkw) Content-id: Content-type: image/gif; name=IMSTP.gif Content-transfer-encoding: base64 Content-disposition: attachment; filename=IMSTP.gif R0lGODlhFAAPALMIAP9gAM9gAM8vAM9gL/+QL5AvAGAvAP9gL////wAAAAAAAAAAAAAAAAAAAAAA AAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQJFAAIACwAAAAAFAAPAAAEVRDJSaudJuudrxlEKI6B URlCUYyjKpgYAKSgOBSCDEuGDKgrAtC3Q/R+hkPJEDgYCjpKr5A8WK9OaPFZwHoPqm3366VKyeRt E30tVVRscMHDqV/u+AgAIfkEBWQACAAsAAAAABQADwAABBIQyUmrvTjrzbv/YCiOZGmeaAQAIfkE CRQACAAsAgABABAADQAABEoQIUOrpXIOwrsPxiQUheeRAgUA49YNhbCqK1kS9grQhXGAhsDBUJgZ AL2Dcqkk7ogFpvRAokSn0p4PO6UIuUsQggSmFjKXdAgRAQAh+QQFCgAIACwAAAAAFAAPAAAEEhDJ Sau9OOvNu/9gKI5kaZ5oBAAh+QQJFAAIACwCAAEAEAANAAAEShAhQ6ulcg7Cuw/GJBSF55ECBQDj 1g2FsKorWRL2CtCFcYCGwMFQmBkAvYNyqSTuiAWm9ECiRKfSng87pQi5SxCCBKYWMpd0CBEBACH5 BAVkAAgALAAAAAAUAA8AAAQSEMlJq7046827/2AojmRpnmgEADs= --Boundary_(ID_2QLk8U2IHg9KqvgdjezAkw)-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 24 03:53:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OArkXW002786; Tue, 24 Jun 2003 03:53:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5OArkS5002785; Tue, 24 Jun 2003 03:53:46 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OArhXW002778 for ; Tue, 24 Jun 2003 03:53:43 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5OAphGq020933 for ; Tue, 24 Jun 2003 03:51:43 -0700 (PDT) Received: from mailout3.samsung.com ([203.254.224.33]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5OApavc023796 for ; Tue, 24 Jun 2003 04:51:37 -0600 (MDT) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HGZ00305FI0OB@mailout3.samsung.com> for ipng@sunroof.eng.sun.com; Tue, 24 Jun 2003 19:51:36 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HGZ00C9LFHZSF@mailout3.samsung.com> for ipng@sunroof.eng.sun.com; Tue, 24 Jun 2003 19:51:35 +0900 (KST) Received: from OLNRAO ([107.108.4.198]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HGZ00BKFFHWGH@mmp1.samsung.com> for ipng@sunroof.eng.sun.com; Tue, 24 Jun 2003 19:51:35 +0900 (KST) Date: Tue, 24 Jun 2003 16:16:33 +0530 From: "O.L.N.Rao" Subject: Re: IPv6 Address validation To: hinden@iprg.nokia.com Cc: ipng@sunroof.eng.sun.com Message-id: <3EF82C09.000001.00468@OLNRAO.sisodomain.com> MIME-version: 1.0 X-Mailer: IncrediMail 2001 (1800814) Content-type: multipart/related; boundary="Boundary_(ID_eEYdkrNl7AYGLmpSNRJcnQ)"; type="multipart/alternative" X-Priority: 3 X-FID: FLAVOR00-NONE-0000-0000-000000000000 X-FVER: X-CNT: ; References: <3EF816E8.000001.00468@OLNRAO.sisodomain.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Boundary_(ID_eEYdkrNl7AYGLmpSNRJcnQ) Content-type: multipart/alternative; boundary="Boundary_(ID_krC2Bc7t++NP7HVqEvFHQQ)" --Boundary_(ID_krC2Bc7t++NP7HVqEvFHQQ) Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT -------Original Message------- From: O.L.N.Rao Date: Tuesday, June 24, 2003 15:07:19 To: hinden@iprg.nokia.com Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Address validation Hi Bob, > I don't think this case was considered explicitly, but in the tradition of > "be liberal in what one receives" as long as the string results in 16-bits > I think it is OK for an implementation to accept it. Another reason why I > think this is OK is that the document also allows for less then four hex > digits. In my view this confirms that there isn't a strict requirement for > a number of digits, only that the field results in 16-bits. So "0", "01", > "0123", and "01234" are OK, but "12345" is not. >> From your comments, >> 012345, 0012345, 00012345...etc are all acceptable !! ********* SORRY FOR TYPOGRAPHICAL ERROR ********** I mean, 01234, 001234, 0001234 ...etc are all acceptable !! But, to what extent should be allowed and why ? Instead of going towards this, prefer not to be liberal in this case at least. Regards, O.L.N.Rao --Boundary_(ID_krC2Bc7t++NP7HVqEvFHQQ) Content-type: Text/HTML; charset=iso-8859-1 Content-transfer-encoding: 7BIT
-------Original Message-------
 
From: O.L.N.Rao
Date: Tuesday, June 24, 2003 15:07:19
Subject: Re: IPv6 Address validation
 
Hi Bob,
 
> I don't think this case was considered explicitly, but in the tradition of
> "be liberal in what one receives" as long as the string results in 16-bits
> I think it is OK for an implementation to accept it. Another reason why I
> think this is OK is that the document also allows for less then four hex
> digits. In my view this confirms that there isn't a strict requirement for
> a number of digits, only that the field results in 16-bits. So "0", "01",
> "0123", and "01234" are OK, but "12345" is not.

>> From your comments,
    >> 012345, 0012345, 00012345...etc are all acceptable !!
 
    ********* SORRY FOR TYPOGRAPHICAL ERROR **********
    I mean,
 
    01234, 001234, 0001234 ...etc are all acceptable !!
 
 
But, to what extent should be allowed and why ?
Instead of going towards this, prefer not to be liberal in this case at least. 
 
 
Regards,
O.L.N.Rao 
____________________________________________________
  IncrediMail - Email has finally evolved - Click Here --Boundary_(ID_krC2Bc7t++NP7HVqEvFHQQ)-- --Boundary_(ID_eEYdkrNl7AYGLmpSNRJcnQ) Content-id: Content-type: image/gif; name=IMSTP.gif Content-transfer-encoding: base64 Content-disposition: attachment; filename=IMSTP.gif R0lGODlhFAAPALMIAP9gAM9gAM8vAM9gL/+QL5AvAGAvAP9gL////wAAAAAAAAAAAAAAAAAAAAAA AAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQJFAAIACwAAAAAFAAPAAAEVRDJSaudJuudrxlEKI6B URlCUYyjKpgYAKSgOBSCDEuGDKgrAtC3Q/R+hkPJEDgYCjpKr5A8WK9OaPFZwHoPqm3366VKyeRt E30tVVRscMHDqV/u+AgAIfkEBWQACAAsAAAAABQADwAABBIQyUmrvTjrzbv/YCiOZGmeaAQAIfkE CRQACAAsAgABABAADQAABEoQIUOrpXIOwrsPxiQUheeRAgUA49YNhbCqK1kS9grQhXGAhsDBUJgZ AL2Dcqkk7ogFpvRAokSn0p4PO6UIuUsQggSmFjKXdAgRAQAh+QQFCgAIACwAAAAAFAAPAAAEEhDJ Sau9OOvNu/9gKI5kaZ5oBAAh+QQJFAAIACwCAAEAEAANAAAEShAhQ6ulcg7Cuw/GJBSF55ECBQDj 1g2FsKorWRL2CtCFcYCGwMFQmBkAvYNyqSTuiAWm9ECiRKfSng87pQi5SxCCBKYWMpd0CBEBACH5 BAVkAAgALAAAAAAUAA8AAAQSEMlJq7046827/2AojmRpnmgEADs= --Boundary_(ID_eEYdkrNl7AYGLmpSNRJcnQ)-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 24 04:30:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OBURXW003302; Tue, 24 Jun 2003 04:30:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5OBURsD003301; Tue, 24 Jun 2003 04:30:27 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OBUNXW003294 for ; Tue, 24 Jun 2003 04:30:24 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5OBSOGq028381 for ; Tue, 24 Jun 2003 04:28:24 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5OBS0fU015021 for ; Tue, 24 Jun 2003 04:28:02 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h5OBRlF11405; Tue, 24 Jun 2003 18:27:51 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5OBQ8g22699; Tue, 24 Jun 2003 18:26:14 +0700 (ICT) From: Robert Elz To: Bob Hinden cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Mark.Andrews@isc.org, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Address validation In-Reply-To: <4.3.2.7.2.20030623112301.02735318@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20030623112301.02735318@mailhost.iprg.nokia.com> <200304232241.h3NMfrdV067607@drugs.dv.isc.org> <20030423153044.GB33177@alicia.nttmcl.com> <200304232241.h3NMfrdV067607@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Jun 2003 18:26:08 +0700 Message-ID: <7374.1056453968@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My take on this is that it simply doesn't matter - there is no need to be specific on what is permitted, and what is not. What needs to be specific is what must be permitted - if implementations then want to allow extensions, that's fine. So, what should be defined is a standard representation form, and all parsers should be required to correctly parse that form, but if some parser wants to handle more than that, I cannot think of any good reason to forbid it. So, I would not require :01234: to be handled by inet_pton() and friends, but if it happens to be easy to implement, or deemed useful, then fine. And the same is true for 001234 0001234 or 000000000001234 - to any normal human they all mean the same thing. Similarly, even though no-one I know does it, and I certainly wouldn't require it, if someone wants to allow 2002:10.11.12.13::/48 that's just fine too (ignoring the use of a 1918 address in a 6to4 address for this purpose). inet_ntop() and friends should only ever generate "standard form" strings (this is what INET6_ADDRSTRLEN relates to, it is irrelevant when considering inet_tton()) and anyone who (for whatever bizarre reason) is writing a literal address and actually cares about portable interpretation, should only ever write them in standard form. But none of that says that inet_pton() should reject addresses that aren't in that standard form. The only note I'd add, is that implementors should use some caution in the additions they permit, so as to avoid accidentally treating strings which "obviously" weren't intended to be IPv6 address literals as if they were. 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 Jun 24 06:25:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5ODPoXW003715; Tue, 24 Jun 2003 06:25:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5ODPo9P003714; Tue, 24 Jun 2003 06:25:50 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5ODPkXW003707 for ; Tue, 24 Jun 2003 06:25:46 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5ODNkGq021410 for ; Tue, 24 Jun 2003 06:23:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5ODNfDT020245 for ; Tue, 24 Jun 2003 07:23:41 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h5ODNS208305; Tue, 24 Jun 2003 06:23:28 -0700 (PDT) From: Bill Manning Message-Id: <200306241323.h5ODNS208305@boreas.isi.edu> Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F8CE@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Jun 23, 3 11:56:34 am" To: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 24 Jun 2003 06:23:28 -0700 (PDT) Cc: lear@cisco.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 % Eliot, % % >> Michel Py wrote: % >> We don't throw away a published standard with running code % >> from multiple vendors in exchange for the promise that % >> _maybe_ someone will be able to produce a replacement that % >> meets the requirements. % % > Eliot Lear wrote: % > It is true that we should not make standards where there is no % > running code. However, Running code != good practices or even % > good ideas. And we do have running code (with both good and % > bad ideas) for now while we figure out this question- it's % > called IPv4. % % I will remind you that the official IETF position is that IPv6 is in % production, which led to the creation of the v6ops WG. IPv6 is no longer % a prototype we can tinker with. Or maybe you recommend a gracious % restart? % % Michel. what an odd point of view. if, as is asserted, the IPv6 is "production" then why are we still seeing drafts changing the address format? --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 24 07:14:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OEEwXW004008; Tue, 24 Jun 2003 07:14:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5OEEwEn004007; Tue, 24 Jun 2003 07:14:58 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OEEsXW004000 for ; Tue, 24 Jun 2003 07:14:54 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5OECtUY027630 for ; Tue, 24 Jun 2003 07:12:55 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5OECl1J020485 for ; Tue, 24 Jun 2003 08:12:49 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h5OECZF04958; Tue, 24 Jun 2003 21:12:35 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5OE8Vg06536; Tue, 24 Jun 2003 21:08:32 +0700 (ICT) From: Robert Elz To: Bill Manning cc: michel@arneill-py.sacramento.ca.us (Michel Py), lear@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 In-Reply-To: <200306241323.h5ODNS208305@boreas.isi.edu> References: <200306241323.h5ODNS208305@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Jun 2003 21:08:31 +0700 Message-ID: <6512.1056463711@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 24 Jun 2003 06:23:28 -0700 (PDT) From: Bill Manning Message-ID: <200306241323.h5ODNS208305@boreas.isi.edu> | what an odd point of view. if, as is asserted, the IPv6 | is "production" then why are we still seeing drafts | changing the address format? That would be an odd definition of "production" - if that were how it were defined, then IPv4 couldn't have been "production" in 1989 when class D addresses were defined (RFC1112) and the IPv4 address format thus altered. Aside from that, anyone can submit drafts about anything, anytime. Even a WG accepting a draft (forwarding it to the IESG) changes nothing. The IETF must agree to accept the change before any alterations happen, and none of that has occurred here. 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 Jun 24 08:10:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OFAtXW004396; Tue, 24 Jun 2003 08:10:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5OFAtbk004395; Tue, 24 Jun 2003 08:10:55 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OFAqXW004388 for ; Tue, 24 Jun 2003 08:10:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5OF8qUY013473 for ; Tue, 24 Jun 2003 08:08:52 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h5OF8lfU004959 for ; Tue, 24 Jun 2003 08:08:47 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Requirements for Limited-Scope Unicast Addressing in IPv6 Date: Tue, 24 Jun 2003 08:09:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F8D1@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: Requirements for Limited-Scope Unicast Addressing in IPv6 Thread-Index: AcM6U+kfKX0QjjV/TR6rHL8wm3pQRAADSS/A 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 h5OFAqXW004389 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, > Bill Manning wrote: > what an odd point of view. if, as is asserted, the > IPv6 is "production" then why are we still seeing > drafts changing the address format? You are making my point. I am not the one that states that v6 is operational, BTW. http://ops.ietf.org/lists/v6ops/v6ops.2002/msg00000.html 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 Jun 24 09:59:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OGxguv005406; Tue, 24 Jun 2003 09:59:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5OGxgXr005405; Tue, 24 Jun 2003 09:59:42 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OGxcuv005398 for ; Tue, 24 Jun 2003 09:59:38 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5OGvcUY022940 for ; Tue, 24 Jun 2003 09:57:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5OGvWvc022225 for ; Tue, 24 Jun 2003 10:57:33 -0600 (MDT) 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 JAA18050; Tue, 24 Jun 2003 09:57:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5OGv9w25018; Tue, 24 Jun 2003 09:57:09 -0700 X-mProtect: <200306241657> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.199, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdoxyvKP; Tue, 24 Jun 2003 09:57:04 PDT Message-Id: <4.3.2.7.2.20030624091957.02d6a6c8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Jun 2003 09:57:02 -0700 To: Michel Py From: Bob Hinden Subject: RE: Requirements for Limited-Scope Unicast Addressing in IPv6 Cc: ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com, Margaret Wasserman , Thomas Narten , Erik Nordmark Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, At 09:50 PM 6/20/2003, Michel Py wrote: > > Fred Templin wrote: > > A limited-scope addressing scheme is needed to replace the > > now-deprecated site-local scheme from [RFC3513] > >The site-local scheme is not deprecated until there is a published >document that states otherwise which will not happen until all the >outstanding appeals have been resolved. Therefore the site-local scheme >from RFC3513 which is in the standards track is still valid. Should you >push this text to be published I can assure you that it will be appealed >as well all the way to the IAB. Your email saying that this work can not proceed or it will be appealed is out of line and an attempt to intimidate the IPv6 working group. This is unacceptable and inconsistent with open IETF participation. There is an appeal outstanding regarding the IPv6 working groups decision to deprecate site-local addresses, but until and if that decision of the working group is overturned, we will continue working under that decision. You may make your own decision about whether or not to participate in this activity. Bob Hinden IPv6 w.g. co-chair -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 24 12:24:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OJO3uv006649; Tue, 24 Jun 2003 12:24:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5OJO33u006648; Tue, 24 Jun 2003 12:24:03 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OJO0uv006641 for ; Tue, 24 Jun 2003 12:24:00 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5OJM0Gq018266 for ; Tue, 24 Jun 2003 12:22:00 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5OJLs1J023992 for ; Tue, 24 Jun 2003 13:21:55 -0600 (MDT) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h5OJLss07108; Tue, 24 Jun 2003 12:21:54 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 24 Jun 2003 12:21:53 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-03.txt In-Reply-To: <200306201829.OAA23851@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 Fri, 20 Jun 2003 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the IP > Version 6 Working Group Working Group of the IETF. > > Title : IP Forwarding Table MIB > Author(s) : M. Wasserman, B. Haberman > Filename : draft-ietf-ipv6-rfc2096-update-03.txt > Pages : 30 > Date : 2003-6-20 Greetings, This version addresses some, but not all, of the WG Last Call comments that I made in the late January to early February time frame, and I would like to discuss the comments that remain unsatisfied. 1.) The rationale for adding inetCidrRouteDiscards (and deprecating ipRoutingDiscards in 2011-update) is not documented. While I don't entirely agree with that decision, I can accept it based on the following explanation from Bill Fenner: >>>>> On Fri, 31 Jan 2003, Bill Fenner wrote: Bill> The IP-MIB revision (draft-ietf-ipv6-rfc2011-update-01.txt) Bill> deprecates ipRoutingDiscards and ipv6DiscardedRoutes in favor Bill> of inetCidrRouteDiscards. The thought was that you can't tell Bill> whether an ipRouteDiscards counts v4-only (as it would if a Bill> system implemented RFC2011+2465) or both, so it's better to Bill> define a new object with well defined semantics. If we Bill> decide that's not a good justification, we should remove Bill> inetCidrRouteDiscards and un-deprecate ipRouteDiscards in Bill> 2011-update. Since the point has been controversial, I would like to suggest that some text along these lines be added to the narrative part of the document, perhaps in the required but as-yet unwritten "Changes from RFC 2096" section (see item (6) below). I would also like to suggest that the object's DESCRIPTION clause be change from: inetCidrRouteDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of routing entries which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing entries." ::= { ipForward 8 } to: inetCidrRouteDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries in the inetCidrRouteTable which were chosen to be discarded even though they were valid. One possible reason for discarding such an entry could be to free up buffer space for other routing entries." ::= { ipForward 8 } to make it perfectly clear exactly what is being counted. 2.) inetCidrRouteNumber has not been re-instated, but there are still a number of references to it in the document. Either it should be re-instated with the following definition: inetCidrRouteNumber OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of current inetCidrRouteTable entries that are not invalid." ::= { ipForward 6 } or else the dangling references to it should be removed from Section 4 and from the DESCRIPTION clause of ipCidrRouteNumber. In the latter case the OID assignments under ipForward should also be reshuffled to avoid gaps in the assignments (e.g., by changing the sub-ID assigned to inetCidrRouteDiscards to 6 from 8). My very strong recommendation is to re-instate the object. I'll note that there was agreement on this point in the e-mail that I quoted above: >>>>> On Fri, 31 Jan 2003, Bill Fenner wrote: Bill> I agree that there should be an inetCidrRouteNumber. The reason for wanting a summary counter is because the potentially huge size of the inetCidrRouteTable makes it inefficient (and probably infeasible) for a manager to derive that information by downloading the whole table. The arguments quoted for its removal -- namely, that it may not agree with the count of the in-view rows for some users and that it may be difficuly for distributed agents to implement -- are, in my opinion, irrelevant and unconvincing, respectively. Focusing on the latter, the distributed agent implementation problems are not insurmountable, and in any case must be weighed against the problems caused for managers. And as Mike MacFaden has pointed out, agents already have to solve that problem anyway for ipCidrRouteNumber -- >>>>> On Fri, 7 Feb 2003, Mike MacFaden wrote: MM> Another thing not considered in Margaret's latest 2096 MM> replacement draft is that both rfc2096 and its successor are MM> both active in the same agent at the same time. MM> MM> So I think ipCidrRouteNumber will apply MM> to both the existing and replacement table regardless, MM> it will just be a count of the ipv4 routes... When this issue came up back in February there was a discussion on the mreview mailing list, and contrary to some reports there is no consensus among the MIB doctors that summary objects like these are evil. See the thread "ifNumber and its ilk considered harmful" at this URL: http://ops.ietf.org/lists/mreview/mreview.2003#00159 The rest of what follows below are MIB doctor-type nits. 3.) Normative references for some MIB modules that appear in the IMPORTS list are missing. They are: MIB module document IF-MIB RFC 2863 IP-MIB draft-ietf-ipv6-rfc2011-update-02.txt IANA-RTPROTO-MIB http://www.iana.org//assignments/ianaiprouteprotocol-mib Please add these documents to the list of normative references. 4.) RFC 2096 appears as a normative reference. That is inappropriate because it is not needed to implement the spec. All it does is supply historical information, and so it should be turned into an informative reference. (Note also that standards-track documents are not normally allowed to refer normatively to documents at a lower maturity level -- and that certainly applies to documents that are being obsoleted.) 5.) The material in Section 1 will need to be removed prior to publication as an RFC. It would probably be a good idea to an an RFC Editor note to that effect. It might also be a good idea to make this an un-numbered section so that the section numbers stay the same in the RFC and the final draft. 6.) When the document is published as an RFC, it should have a change log detailing what was changed since RFC 2096 (it could point to the most recent REVISION clause if the latter were a bit more detailed). 7.) Several changes are needed in the MODULE-IDENTITY invocation: (a) Please add the standard MIB copyright notice to the DESCRIPTION clause. For details see Section 3.8 of , or http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt. (b) Please change the 2nd REVISION/DESCRIPTION pair from: REVISION "200301130000Z" DESCRIPTION "Revised to support CIDR routes." to: REVISION "199609190000Z" DESCRIPTION "Revised to support CIDR routes. Published as RFC 2096." i.e., please retain the original RFC 2096 rev date. (c) Please add a 3rd REVISION/DESCRIPTION pair just below that says: REVISION "199207022156Z" DESCRIPTION "Initial version, published as RFC 1354." Note that the UTC time is taken from the date stamp on http://www.rfc-editor.org/rfc/rfc1354.txt ... the original module is in SMIv1 and so have no such clause. There may be more such stuff as I have not done a complete MIB doctor review; I've covered only those issues that I raised previously that were not yet dealt with. Thanks and regards, Mike Heard -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 24 13:34:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OKYHuv007287; Tue, 24 Jun 2003 13:34:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5OKYHZC007286; Tue, 24 Jun 2003 13:34:17 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5OKYCuv007279 for ; Tue, 24 Jun 2003 13:34:12 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5OKWCUY014035 for ; Tue, 24 Jun 2003 13:32:12 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5OKW5vc001463 for ; Tue, 24 Jun 2003 14:32:06 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09714; Tue, 24 Jun 2003 16:30:36 -0400 (EDT) Message-Id: <200306242030.QAA09714@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: IPv6 Flow Label Specification to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 24 Jun 2003 16:30:36 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IP Version 6 Working Group to consider IPv6 Flow Label Specification as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-7-8. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-07.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 24 19:16:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5P2G8uv009417; Tue, 24 Jun 2003 19:16:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5P2G8U6009416; Tue, 24 Jun 2003 19:16:08 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5P2G4uv009409 for ; Tue, 24 Jun 2003 19:16:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5P2E4UY011200 for ; Tue, 24 Jun 2003 19:14:04 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5P2DwfU028528 for ; Tue, 24 Jun 2003 19:13:58 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 4068B96; Wed, 25 Jun 2003 11:13:55 +0900 (JST) To: Robert Elz Cc: Bob Hinden , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Mark.Andrews@isc.org, ipng@sunroof.eng.sun.com In-reply-to: kre's message of Tue, 24 Jun 2003 18:26:08 +0700. <7374.1056453968@munnari.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 Address validation From: itojun@iijlab.net Date: Wed, 25 Jun 2003 11:13:55 +0900 Message-Id: <20030625021355.4068B96@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >My take on this is that it simply doesn't matter - there is no >need to be specific on what is permitted, and what is not. > >What needs to be specific is what must be permitted - if implementations >then want to allow extensions, that's fine. > >So, what should be defined is a standard representation form, and >all parsers should be required to correctly parse that form, but >if some parser wants to handle more than that, I cannot think of >any good reason to forbid it. > >So, I would not require > :01234: >to be handled by inet_pton() and friends, but if it happens to be >easy to implement, or deemed useful, then fine. > >And the same is true for 001234 0001234 or 000000000001234 - to any >normal human they all mean the same thing. > >Similarly, even though no-one I know does it, and I certainly wouldn't >require it, if someone wants to allow > > 2002:10.11.12.13::/48 > >that's just fine too (ignoring the use of a 1918 address in a 6to4 >address for this purpose). i disagree with the standpoint. if we don't standardize what is accepted by inet_pton(), we will have usability/portability problem. if we leave it to "do whatever you want" state as you said, we will experience painful cleanup process in the near future, just like transition from inet_aton to inet_pton (inet_aton accepted hex/octal/ less-than-four component format, and inet_pton only accepts decimal 4-component format). 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 Jun 24 20:40:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5P3esuv010966; Tue, 24 Jun 2003 20:40:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5P3esSh010965; Tue, 24 Jun 2003 20:40:54 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5P3epuv010958 for ; Tue, 24 Jun 2003 20:40:51 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5P3cpUY002706 for ; Tue, 24 Jun 2003 20:38:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5P3ckvc018027 for ; Tue, 24 Jun 2003 21:38:46 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h5P3caM14338; Tue, 24 Jun 2003 20:38:36 -0700 (PDT) From: Bill Manning Message-Id: <200306250338.h5P3caM14338@boreas.isi.edu> Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F8D1@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Jun 24, 3 08:09:24 am" To: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 24 Jun 2003 20:38:36 -0700 (PDT) Cc: bmanning@ISI.EDU, 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 % Bill, % % > Bill Manning wrote: % > what an odd point of view. if, as is asserted, the % > IPv6 is "production" then why are we still seeing % > drafts changing the address format? % % You are making my point. I am not the one that states that v6 is % operational, BTW. % http://ops.ietf.org/lists/v6ops/v6ops.2002/msg00000.html % % Michel. % ah.. perhaps my issue is that your original note used the term "production", while now you use the term "operational". they are different words w/ distinct meanings. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 24 20:42:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5P3gDuv010987; Tue, 24 Jun 2003 20:42:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5P3gDxi010985; Tue, 24 Jun 2003 20:42:13 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5P3g9uv010978 for ; Tue, 24 Jun 2003 20:42:09 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5P3eAGq028358 for ; Tue, 24 Jun 2003 20:40:10 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h5P3e4fU029953 for ; Tue, 24 Jun 2003 20:40:05 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Requirements for Limited-Scope Unicast Addressing in IPv6 Date: Tue, 24 Jun 2003 20:40:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F506727C@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements for Limited-Scope Unicast Addressing in IPv6 Thread-Index: AcM6y1n9nWzHJIzLQcybrFiyT4Y3uQAAAiEw 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 h5P3gAuv010979 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Bill Manning wrote: > ah.. perhaps my issue is that your original note > used the term "production", while now you use the > term "operational". they are different words w/ > distinct meanings. Would you mind sharing these meanings? 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 Jun 24 21:04:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5P440uv011406; Tue, 24 Jun 2003 21:04:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5P440rk011405; Tue, 24 Jun 2003 21:04:00 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5P43uuv011398 for ; Tue, 24 Jun 2003 21:03:56 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5P41vUY007393 for ; Tue, 24 Jun 2003 21:01:57 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5P41p1J016403 for ; Tue, 24 Jun 2003 22:01:51 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h5P41gw26246; Tue, 24 Jun 2003 21:01:42 -0700 (PDT) From: Bill Manning Message-Id: <200306250401.h5P41gw26246@boreas.isi.edu> Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F506727C@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Jun 24, 3 08:40:42 pm" To: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 24 Jun 2003 21:01:42 -0700 (PDT) Cc: bmanning@ISI.EDU, 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 % > Bill Manning wrote: % > ah.. perhaps my issue is that your original note % > used the term "production", while now you use the % > term "operational". they are different words w/ % > distinct meanings. % % Would you mind sharing these meanings? % % Michel. ok. my 1913 webster sez: Operation \Op`er*a"tion\, n. [L. operatio: cf. F. op['e]ration.] 2. The method of working; mode of action. Production \Pro*duc"tion\, n. [L. productio a lengthening, prolonging: cf. F. production. See {Produce}. ] 1. The act or process or producing, bringing forth, or exhibiting to view; as, the production of commodities, of a witness. -------------------------------------------------- e.g. IPv6 is now known to be operable, it can be made to operate. the IETF v6ops wg is looking at ways to take operational specifications and examine the impact on humans as they develop procedures for operating v6 networks. such an environment has, as its result, the production of operational procedures. that still does not let the IETF determine when/if any organization has a production ipv6 service. the IETF can define specs and recommend practice and thats as far as it goes, IMHO. your dictionary and expectation may differ. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 24 21:30:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5P4UDuv011655; Tue, 24 Jun 2003 21:30:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5P4UD8R011654; Tue, 24 Jun 2003 21:30:13 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5P4U9uv011647 for ; Tue, 24 Jun 2003 21:30:10 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5P4SAGq007955 for ; Tue, 24 Jun 2003 21:28:10 -0700 (PDT) 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.12.9/8.12.9) with ESMTP id h5P4S5Ko006614 for ; Tue, 24 Jun 2003 21:28:05 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Requirements for Limited-Scope Unicast Addressing in IPv6 Date: Tue, 24 Jun 2003 21:28:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F8E3@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements for Limited-Scope Unicast Addressing in IPv6 Thread-Index: AcM6zpOIGvqO8v7aRS6FpG1PvE84pgAAYzoA 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 h5P4UAuv011648 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, > Bill Manning wrote: > that still does not let the IETF determine when/if any > organization has a production ipv6 service. the IETF can > define specs and recommend practice and thats as far as > it goes, IMHO. Agree. But back to your original text: > perhaps my issue is that your original note > used the term "production", while now you use the > term "operational". they are different words w/ > distinct meanings. Without getting in the definition of what is a production network, what I meant is this: IMHO, it is reasonable to assume that the majority (literally: more than 50%) of IPv6 operators are considered reasonably competent to the extent that they operate their networks in a fashion compatible with having customers and provide them that commodity called "IPv6 service", regardless of what the precise definition of what "IPv6 service" really means at a certain point in time. In other words: If IPv6 is operational, and if we assume that most operators operate their networks within reasonable limits of what should be done, this leads to IPv6 being in production. I apologize for using two different words, but for all practical purposes what is the difference? 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 Jun 25 00:29:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5P7Tsuv012089; Wed, 25 Jun 2003 00:29:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5P7Ts2K012088; Wed, 25 Jun 2003 00:29:54 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5P7Touv012081 for ; Wed, 25 Jun 2003 00:29:50 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5P7RpGq016219 for ; Wed, 25 Jun 2003 00:27:51 -0700 (PDT) Received: from laptop2.kurtis.autonomica.se (laptop2.kurtis.autonomica.se [192.71.80.74]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5P7RjfU022974 for ; Wed, 25 Jun 2003 00:27:46 -0700 (PDT) Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id h5P7ReFT018023; Wed, 25 Jun 2003 09:27:41 +0200 (CEST) Date: Wed, 25 Jun 2003 09:27:35 +0200 Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 Content-Type: text/plain; charset=ISO-8859-1; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Fred Templin" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F8CD@server2000.arneill-py.sacramento.ca.us> Message-Id: <7DFA69A2-A6DE-11D7-9791-000393A638B2@kurtis.pp.se> X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h5P7Tpuv012082 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On måndag, jun 23, 2003, at 20:06 Europe/Stockholm, Michel Py wrote: > We don't throw away a > published standard with running code from multiple vendors Running code equates to experience. If the IETF is forbidden to change anything that has running code we have large problems. For example, what shall we have all the DNS people spend their time on then? ;-) From http://www.cafax.se/~liman/quotations/ietf-31.html : - - Is Paul [Vixie] here? - - Yeah! - - Stop changing the code! - - It's my job ... Thomas Brisco to Paul Vixie at DNSIND WG Running code is what have given us the experience that ambiguity is bad. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPvlO6qarNKXTPFCVEQLXGwCgk8UdvyTq6hewXrFgCQ9hr1DjRgAAoL95 12Gbip8R3WbIn0IbvcWbfRfF =b8jb -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 25 05:23:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PCNWuv013551; Wed, 25 Jun 2003 05:23:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5PCNWDT013549; Wed, 25 Jun 2003 05:23:32 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PCNTuv013541 for ; Wed, 25 Jun 2003 05:23:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PCLTGq009440 for ; Wed, 25 Jun 2003 05:21:29 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5PCLOfU000148 for ; Wed, 25 Jun 2003 05:21:24 -0700 (PDT) Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Jun 2003 05:24:37 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5PCLLgE006070; Wed, 25 Jun 2003 05:21:22 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-561.cisco.com [10.82.242.49]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAF27289; Wed, 25 Jun 2003 08:21:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20030625071906.02395db8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Jun 2003 07:22:57 -0400 To: Robert Elz From: Ralph Droms Subject: Re: Next steps on the IPv6 Node requirements draft Cc: Alain Durand , john.loughney@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: <12731.1056020197@munnari.OZ.AU> References: <3EF10269.8050106@sun.com> <3EF10269.8050106@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with kre - address configuration through DHCP (confrolled by 'M' bit) and autoconfiguration through advertised prefixes should be considered independent. An interface may well have both autoconfiguration addresses and addresses obtained through DHCP (and manually configured addresses, as well). BTW, is there a differentiation here between the behavior of hosts and routers in the processing of advertised prefixes and the 'M' bit? Is that differentiation explicitly documented somewhere? Is the node requirements document sufficiently clear? - Ralph At 05:56 PM 6/19/2003 +0700, Robert Elz wrote: > Date: Wed, 18 Jun 2003 17:23:05 -0700 > From: Alain Durand > Message-ID: <3EF10269.8050106@sun.com> > > | So what if the M bit is set _and_ a prefix is advertized? > | Should the node give up its stateless autoconfigured address in favor of > | DHCP? > >No, it should do both. > > | What about statically configured addresses on the same node? > >It should keep that as well, though often if there's to be static >config it will often also be the case that use of stateless autoconfig >and dhcp config will be disabled (either explicitly or implicitly) > > | IMHO, it makes little sense to have both a DHCP allocated address and a > | stateless autoconfigured address on the same interface. > >In that case, you wouldn't config your routers to send the M bit, and >prefixes with the A bit set, at the same time. > >On the other hand, others may consider it useful to allow nodes to >autoconfigure themselves addresses (so they always gave one, provided >there's a working router to make the address useful) and at the same >time, provide specific addresses to specific nodes (attempting to use >DHCP doesn't necessarily mean the DHCP server will actually allocate >an address) where specific nodes are expected to own well known addresses. > > | However, I see cases where you want > | to have nodes using DHCP and nodes using stateless autoconfiguration on > | the same link. > >The very nature of *stateless* autoconfig is that there's no (easy) way to >configure a node to not do it (manual config on that node excepted). If >there was, it would not be stateless. So, by default, if any node on a >link is permitted stateless autoconfig (of a prefix) all nodes are. > >It is generally harmless to own an extra address though, having the >statelessly configured one, as well as a dhcp supplied one should not >cause any harm. > >That is, I don't think receiving a DHCP allocated address should cause >an autoconfig'd address to be dropped, there's no need (doing do raises >all the questions of what you do if you've been running using the >autoconfig'd address for hours when the dhcp server returns to life >and allocates you an address). > >All that being said - a request to implementors out there. It would be >very (*very*) nice to have the ability in a node to ignore prefixes >that are being advertised from routers, and never autoconfig an address >in that prefix. That is, I occasionally see someone advertising a >prefix that I know doesn't work (they're getting ready for the day it >will work, and have just jumped the gun - believing in early preparation >or something). I'd like to be able to ignore that (no matter what >router advertises it - so lower level packet filtering doesn't help). > >kre > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 25 05:23:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PCNcuv013559; Wed, 25 Jun 2003 05:23:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5PCNcYr013558; Wed, 25 Jun 2003 05:23:38 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PCNWuv013548 for ; Wed, 25 Jun 2003 05:23:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PCLWGq009446 for ; Wed, 25 Jun 2003 05:21:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5PCLQfU000169 for ; Wed, 25 Jun 2003 05:21:26 -0700 (PDT) Received: from cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2003 05:23:13 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5PCLMGe016525; Wed, 25 Jun 2003 05:21:23 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-561.cisco.com [10.82.242.49]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAF27293; Wed, 25 Jun 2003 08:21:20 -0400 (EDT) Message-Id: <4.3.2.7.2.20030625072324.02396ae0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Jun 2003 07:30:44 -0400 To: Alain Durand From: Ralph Droms Subject: Re: Next steps on the IPv6 Node requirements draft Cc: Robert Elz , john.loughney@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: <1ED6D618-A270-11D7-90A5-00039376A6AA@sun.com> References: <12731.1056020197@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Regarding reverse DNS entries ... there is a specific problem with reverse DNS entries for autoconfiguration addresses regarding update of the reverse entries by the client. The portion of the DNS namespace into which the host wants to insert its reverse DNS entry is owned by the network to which the hose is attached. There is no requirement for any administrative or trust relationship between the host and the network to which it is attached, so performing The problem here is that administrative responsibility for an autoconfiguration address ('ownership') is split: the network admin owns the prefix and the host owns the suffix. But the network admin owns the DNS namespace to which the prefix belongs and must make an admin decision about wherher to allow updates from a host with which it has no administrative or trust relationship. There are solutions - disallow reverse DNS updates for autoconfiguration addresses, let the DNS server that maintains the prefix allow untrusted updates in the namespace for that prefix, require some DNSSEC trust mechanism that supports roaming. - Ralph At 09:07 AM 6/19/2003 -0700, Alain Durand wrote: >On Thursday, June 19, 2003, at 03:56 AM, Robert Elz wrote: >>It is generally harmless to own an extra address though, having the >>statelessly configured one, as well as a dhcp supplied one should not >>cause any harm. > >Not sure. Two reasons: > - There may be filters in place, for example that only > allows DHCP assigned addresses to go out. > (this is not pure fantasy, I've heard people willing to do > just that in hot spots). > > - There are reverse DNS issues. They may point to 2 different > names or > more likely, the stateless autoconfigured address won't resolve to > a name, where the DHCP one will. As default address selection does > not (yet?) say to prefer the DHCP one, logs and/or (very) weak > security/authentication > mechanisms based on DNS reverse lookup will work randomly. > >- 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 Wed Jun 25 07:56:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PEumuv014546; Wed, 25 Jun 2003 07:56:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5PEumnN014545; Wed, 25 Jun 2003 07:56:48 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PEuiuv014538 for ; Wed, 25 Jun 2003 07:56:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PEsiGq012738 for ; Wed, 25 Jun 2003 07:54:44 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5PEsbKo019686 for ; Wed, 25 Jun 2003 07:54:38 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13204; Wed, 25 Jun 2003 10:54:33 -0400 (EDT) Message-Id: <200306251454.KAA13204@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-scoping-arch-00.txt Date: Wed, 25 Jun 2003 10:54:33 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Scoped Address Architecture Author(s) : S. Deering et al. Filename : draft-ietf-ipv6-scoping-arch-00.txt Pages : 22 Date : 2003-6-24 This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids using the syntax and usage of unicast site-local addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-scoping-arch-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-scoping-arch-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-scoping-arch-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: <2003-6-25103613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-scoping-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-scoping-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103613.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 25 10:53:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PHrMuv016082; Wed, 25 Jun 2003 10:53:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5PHrMp3016081; Wed, 25 Jun 2003 10:53:22 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PHrJuv016074 for ; Wed, 25 Jun 2003 10:53:19 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PHpJUY006271 for ; Wed, 25 Jun 2003 10:51:19 -0700 (PDT) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5PHp81J013842 for ; Wed, 25 Jun 2003 11:51:13 -0600 (MDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5PHodMk012636 for ; Wed, 25 Jun 2003 19:50:57 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h5PHoKwl159040 for ; Wed, 25 Jun 2003 19:50:31 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23402 from ; Wed, 25 Jun 2003 19:50:18 +0200 Message-Id: <3EF9DD29.E86EDE@hursley.ibm.com> Date: Wed, 25 Jun 2003 19:34:33 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Address validation References: <20030625021355.4068B96@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This looks like a misunderstanding of the Postel principle. Obviously, we should specify syntax that is non-redundant, i.e. no extra leading zeros. I think that is what the draft-main-ipaddr-text-rep-00.txt syntax does. Also obviously, implementors who want to follow the Postel principle will write parsers that accept any number of leading zeros. But that isn't something we need to define in ABNF or in any API. It's just defensive programming. Brian itojun@iijlab.net wrote: > > >My take on this is that it simply doesn't matter - there is no > >need to be specific on what is permitted, and what is not. > > > >What needs to be specific is what must be permitted - if implementations > >then want to allow extensions, that's fine. > > > >So, what should be defined is a standard representation form, and > >all parsers should be required to correctly parse that form, but > >if some parser wants to handle more than that, I cannot think of > >any good reason to forbid it. > > > >So, I would not require > > :01234: > >to be handled by inet_pton() and friends, but if it happens to be > >easy to implement, or deemed useful, then fine. > > > >And the same is true for 001234 0001234 or 000000000001234 - to any > >normal human they all mean the same thing. > > > >Similarly, even though no-one I know does it, and I certainly wouldn't > >require it, if someone wants to allow > > > > 2002:10.11.12.13::/48 > > > >that's just fine too (ignoring the use of a 1918 address in a 6to4 > >address for this purpose). > > i disagree with the standpoint. if we don't standardize what > is accepted by inet_pton(), we will have usability/portability problem. > if we leave it to "do whatever you want" state as you said, we will > experience painful cleanup process in the near future, just like > transition from inet_aton to inet_pton (inet_aton accepted hex/octal/ > less-than-four component format, and inet_pton only accepts decimal > 4-component format). > > 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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 Jun 25 12:03:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PJ3Tuv017097; Wed, 25 Jun 2003 12:03:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5PJ3TaB017096; Wed, 25 Jun 2003 12:03:29 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PJ3Puv017089 for ; Wed, 25 Jun 2003 12:03:25 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PJ1OUY004641 for ; Wed, 25 Jun 2003 12:01:25 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5PJ1IZV019361 for ; Wed, 25 Jun 2003 13:01:19 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25575; Wed, 25 Jun 2003 15:00:26 -0400 (EDT) Message-Id: <200306251900.PAA25575@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com From: The IESG Subject: Document Action: IPv6 Global Unicast Address Format to Informational Date: Wed, 25 Jun 2003 15:00:26 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IPv6 Global Unicast Address Format' as an Informational RFC. This document will replace RFC2374 and reclassify RFC 2374 (and the TLA/NLA structure described there) as historic. This document is the product of the IP Version 6 Working Group. The IESG contact persons are Thomas Narten and Erik Nordmark. Technical Summary RFC2374 "An IPv6 Aggregatable Global Unicast Address Format" defined an IPv6 address allocation structure that includes TLA (Top Level Aggregator) and NLA (Next Level Aggregator). This document replaces RFC2374, and makes RFC 2374 and the TLA/NLA structure historic. Working Group Summary There was support for this in the WG; this document documents what the WG decided quite some time ago. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 25 15:37:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PMbtuv018484; Wed, 25 Jun 2003 15:37:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5PMbtUl018483; Wed, 25 Jun 2003 15:37:55 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PMbpuv018476 for ; Wed, 25 Jun 2003 15:37:51 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PMZqGq008776 for ; Wed, 25 Jun 2003 15:35:52 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5PMZeDT003775 for ; Wed, 25 Jun 2003 16:35:46 -0600 (MDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5PMYuPO065100; Thu, 26 Jun 2003 00:35:10 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h5PMYYW0235448; Thu, 26 Jun 2003 00:34:41 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA29460 from ; Thu, 26 Jun 2003 00:34:33 +0200 Message-Id: <3EFA1CC4.B6967F27@hursley.ibm.com> Date: Thu, 26 Jun 2003 00:05:56 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Fred Templin Cc: ipng@sunroof.eng.sun.com Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 References: <20030620023545.CFBB492@coconut.itojun.org> <3EF38D8B.4070906@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, My main comment on this useful draft is that I would like to see it combined with draft-hain-ipv6-sitelocal-01.txt. We only need one draft on this topic. You might add more scenarios that have to be supported - mergers and acquistions without instant renumbering - dynamically created VPNs in support of temporary virtual organizations - hosting of customer subnets by a service provider I would simply remove the language about deprecation. Brian Fred Templin wrote: > > A new draft has been posted to the I-D repository; details > can be found below. Pls send comments to the list. > > Fred Templin > ftemplin@iprg.nokia.com > > --- cut here --- > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Requirements for Limited-Scope Unicast Addressing in > IPv6 > Author(s) : F. Templin > Filename : draft-templin-lsareqts-00.txt > Pages : 9 > Date : 2003-6-20 > > The IPv6 addressing architecture specifies global and local-use > unicast addressing schemes. Recent consensus call in the IPng working > group has deprecated site-local addressing due in part to its > inherent ambiguity. This document outlines requirements for use in > evaluating candidate proposals for a replacement scheme. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-templin-lsareqts-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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 Jun 25 15:43:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PMh7uv018699; Wed, 25 Jun 2003 15:43:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h5PMh6Zn018698; Wed, 25 Jun 2003 15:43:06 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h5PMh3uv018688 for ; Wed, 25 Jun 2003 15:43:03 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5PMf3Gq011045 for ; Wed, 25 Jun 2003 15:41:03 -0700 (PDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h5PMeq1J026605 for ; Wed, 25 Jun 2003 16:40:57 -0600 (MDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h5PMeA76053758; Thu, 26 Jun 2003 00:40:26 +0200 Received: from ochsehorn.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h5PMe3wl289480; Thu, 26 Jun 2003 00:40:03 +0200 Received: from gsine04.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA22796 from ; Thu, 26 Jun 2003 00:40:01 +0200 Message-Id: <3EFA1CC4.B6967F27@hursley.ibm.com> Date: Thu, 26 Jun 2003 00:05:56 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Fred Templin Cc: ipng@sunroof.eng.sun.com Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 References: <20030620023545.CFBB492@coconut.itojun.org> <3EF38D8B.4070906@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, My main comment on this useful draft is that I would like to see it combined with draft-hain-ipv6-sitelocal-01.txt. We only need one draft on this topic. You might add more scenarios that have to be supported - mergers and acquistions without instant renumbering - dynamically created VPNs in support of temporary virtual organizations - hosting of customer subnets by a service provider I would simply remove the language about deprecation. Brian Fred Templin wrote: > > A new draft has been posted to the I-D repository; details > can be found below. Pls send comments to the list. > > Fred Templin > ftemplin@iprg.nokia.com > > --- cut here --- > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Requirements for Limited-Scope Unicast Addressing in > IPv6 > Author(s) : F. Templin > Filename : draft-templin-lsareqts-00.txt > Pages : 9 > Date : 2003-6-20 > > The IPv6 addressing architecture specifies global and local-use > unicast addressing schemes. Recent consensus call in the IPng working > group has deprecated site-local addressing due in part to its > inherent ambiguity. This document outlines requirements for use in > evaluating candidate proposals for a replacement scheme. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-templin-lsareqts-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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich LaboraX-Mozilla-Status: 0009rom - Thu Jun 26 00:09:10 2003 X-Mozilla-Status: 0801 X-Mozilla-Status2: 00000000 FCC: /c|/brian/netscape/mail/Sent Message-ID: <3EFA1D86.B839E89D@hursley.ibm.com> Date: Thu, 26 Jun 2003 00:09:10 +0200 From: Brian E Carpenter Organization: IBM X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; uuencode=0; html=0; linewidth=0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Bob Hinden Subject: Re: No shortage of IP addresses: IP registry head References: <4.3.2.7.2.20030625134924.02d41ac0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit No idea. He's wedged. India, Vietnam and even China are the victims, but in the long run it probably benefits IPv6. Brian Bob Hinden wrote: > > Brain, > > What do you think is the best way to deal with Paul Wilson. He seems to > alternate on there is no shortage of IPv4 addresses and IPv6 doesn't have > enough addresses. I find this irresponsible and a disservice to the > overall community from the head of an address registry. > > Bob > > At 01:15 PM 6/25/2003, Brian E Carpenter wrote: > >Alistair.Urie@alcatel.com wrote: > > > > > > No it is proof that India either "likes" NAT or they haven't asked for new > > > address blocks. > > > > > > - alistair urie > > > >Sorry, but that is unfair. It is very hard to ask a developing country > >to fly in the face of established practice. Given that APNIC consciously > >chose a restrictive assignment policy, I don't see how it could have gone > >any other way. > > > > Brian > > > > > > > > > > > Matt Crawford > > > > > > > v> cc: Nick Kraal > > , members@ipv6forum.com > > > Sent by: Subject: Re: No shortage > > of IP addresses: IP registry head > > > owner-members@ip > > > v6forum.com > > > > > > > > > 25/06/2003 17:48 > > > > > > > > > > > > On Wednesday, Jun 25, 2003, at 03:09 US/Pacific, Gopi Garge wrote: > > > > With ISPs out here in India running cascaded NATs (in places upto > > > > 5 levels) there will hardly be a shortage of addresses for years to > > > > come. > > > > > > *Boggle* > > > > > > This is absolute proof that there already *is* an address shortage. > > > > > > The thing that may last for a few years or a decade is the ability > > > of clever dedicated people to *cope* with the shortage. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished EngX-Mozilla-Status: 0009rds & 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 Jun 25 18:23:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5Q1N1MV023821; Wed, 25 Jun 2003 18:23:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h5Q1N1am023820; Wed, 25 Jun 2003 18:23:01 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5Q1MvMV023813 for ; Wed, 25 Jun 2003 18:22:58 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5Q1KvUY010830 for ; Wed, 25 Jun 2003 18:20:57 -0700 (PDT) Received: from drugs.dv.isc.org (c17200.carlnfd2.nsw.optusnet.com.au [211.29.163.60]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5Q1KpZV001997 for ; Wed, 25 Jun 2003 19:20:52 -0600 (MDT) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h5Q1Kc6A019748; Thu, 26 Jun 2003 11:20:39 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306260120.h5Q1Kc6A019748@drugs.dv.isc.org> To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: IPv6 Address validation In-reply-to: Your message of "Wed, 25 Jun 2003 19:34:33 +0200." <3EF9DD29.E86EDE@hursley.ibm.com> Date: Thu, 26 Jun 2003 11:20:38 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This looks like a misunderstanding of the Postel principle. > > Obviously, we should specify syntax that is non-redundant, > i.e. no extra leading zeros. I think that is what the > draft-main-ipaddr-text-rep-00.txt syntax does. > > Also obviously, implementors who want to follow the Postel > principle will write parsers that accept any number of leading > zeros. But that isn't something we need to define in ABNF > or in any API. It's just defensive programming. > > Brian Having dealt with bug reports due to inconsistant IPv4 address parsing I don't want to have to deal with the same problems in IPv6. I also don't want to have to deal with "But it works on this machine" complaints because that machine just happens to have a liberal parser. Users can deal pretty well with errors. They have a lot more trouble dealing with inconsistancy. 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 Thu Jun 26 02:02:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5Q92OMV026711; Thu, 26 Jun 2003 02:02:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h5Q92OQx026710; Thu, 26 Jun 2003 02:02:24 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5Q92KMV026696 for ; Thu, 26 Jun 2003 02:02:20 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5Q90IUY003164 for ; Thu, 26 Jun 2003 02:00:18 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5Q90BKo010053 for ; Thu, 26 Jun 2003 02:00:12 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h5Q8xo108773; Thu, 26 Jun 2003 15:59:53 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h5Q8vXt02996; Thu, 26 Jun 2003 15:57:35 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: Bob Hinden , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Mark.Andrews@isc.org, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Address validation In-Reply-To: <20030625021355.4068B96@coconut.itojun.org> References: <20030625021355.4068B96@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Jun 2003 15:57:33 +0700 Message-ID: <1342.1056617853@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 25 Jun 2003 11:13:55 +0900 From: itojun@iijlab.net Message-ID: <20030625021355.4068B96@coconut.itojun.org> | i disagree with the standpoint. if we don't standardize what | is accepted by inet_pton(), we will have usability/portability problem. We need to standardise what inet_pton() is expected to be able to convert. We don't have to prohibit it from accepting anything else. Then people should be encouraged to generate only that expected form (or those forms). And certainly inet_ntop() should do that. But if I am manually typing one of those addresses, I really don't want to be penalised for accidentally typing one too many meaningless leading zeroes. | if we leave it to "do whatever you want" state as you said, we will | experience painful cleanup process in the near future, just like | transition from inet_aton to inet_pton (inet_aton accepted hex/octal/ | less-than-four component format, and inet_pton only accepts decimal | 4-component format). As I recall, what input was legal for inet_aton() (inet_addr() really, that's where all this started) was never defined - that is, whether 10.1 was legal or not was just discovered by accident (and that 128.1 meant something quite different than 10.1 - or sometimes did). I certainly agree that we need to document the format in which addresses should be written in order to be able to be processed everywhere. That is "do whatever you want" isn't anyone's position here I don't think (that would include, for example, allowing an implementation of inet_pton() which expected a string of 32 hex digits without punctuation, and which rejected anything else.) But it is just silly to attempt to tell people that they're not allowed to implement harmless extensions which make things easier to use. In time some of those extensions may become so widely used as to become (effectively) standard - if we had been going to actually standardise inet_aton() 12/13 years ago (or more), then 10.1 would almost certainly have been included as legal. Today we wouldn't do that, as classful addresses are essentially dead (the 1918 addresses being probably the last real hold-outs). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 26 05:24:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5QCO8MV027884; Thu, 26 Jun 2003 05:24:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h5QCO7E4027883; Thu, 26 Jun 2003 05:24:07 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5QCO4MV027876 for ; Thu, 26 Jun 2003 05:24:04 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5QCM2UY022731 for ; Thu, 26 Jun 2003 05:22:02 -0700 (PDT) Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5QCLpDT012101 for ; Thu, 26 Jun 2003 06:21:56 -0600 (MDT) Received: from lt38 ([10.4.1.85]) by galileo5.galileo.co.il (8.12.6/8.12.6) with SMTP id h5QDJelH010489 for ; Thu, 26 Jun 2003 15:19:40 +0200 (GMT-2) Message-ID: <00ee01c33be6$40527b10$5501040a@lt38> From: "Nir Arad" To: "IPng mailing list" Subject: IPv6 over Ethernet question Date: Thu, 26 Jun 2003 15:24:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear community, I am reading RFC 2464, and I have encountered chapter 6, titled "Address Mapping -- Unicast". I have to admit I still didn't read the related RFC 2461 (Neighbor Discovery), but I was wondering if someone would be willing to provide a short explanation of what is the purpose of this mapping. Thanks, -- Nir Arad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 26 05:37:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5QCbmMV028126; Thu, 26 Jun 2003 05:37:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h5QCblfV028125; Thu, 26 Jun 2003 05:37:47 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5QCbiMV028118 for ; Thu, 26 Jun 2003 05:37:44 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5QCZgUY025729 for ; Thu, 26 Jun 2003 05:35:42 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5QCZavc013817 for ; Thu, 26 Jun 2003 06:35:36 -0600 (MDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h5QCZaN17839; Thu, 26 Jun 2003 05:35:36 -0700 Received: from innovationslab.net ([63.109.132.2]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h5QDC9p0001738 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 26 Jun 2003 06:12:14 -0700 Message-ID: <3EFAE891.6040309@innovationslab.net> Date: Thu, 26 Jun 2003 08:35:29 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "C. M. Heard" CC: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-03.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, Thanks for the comments. I have a few follow-ups in-line... > > 1.) The rationale for adding inetCidrRouteDiscards (and deprecating > ipRoutingDiscards in 2011-update) is not documented. While I don't > entirely agree with that decision, I can accept it based on the > following explanation from Bill Fenner: > > >>>>>>On Fri, 31 Jan 2003, Bill Fenner wrote: > > Bill> The IP-MIB revision (draft-ietf-ipv6-rfc2011-update-01.txt) > Bill> deprecates ipRoutingDiscards and ipv6DiscardedRoutes in favor > Bill> of inetCidrRouteDiscards. The thought was that you can't tell > Bill> whether an ipRouteDiscards counts v4-only (as it would if a > Bill> system implemented RFC2011+2465) or both, so it's better to > Bill> define a new object with well defined semantics. If we > Bill> decide that's not a good justification, we should remove > Bill> inetCidrRouteDiscards and un-deprecate ipRouteDiscards in > Bill> 2011-update. > > Since the point has been controversial, I would like to suggest that > some text along these lines be added to the narrative part of the > document, perhaps in the required but as-yet unwritten "Changes from > RFC 2096" section (see item (6) below). I would also like to > suggest that the object's DESCRIPTION clause be change from: > > inetCidrRouteDiscards OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of routing entries which were chosen to be > discarded even though they are valid. One possible > reason for discarding such an entry could be to free-up > buffer space for other routing entries." > ::= { ipForward 8 } > > to: > > inetCidrRouteDiscards OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of entries in the inetCidrRouteTable which > were chosen to be discarded even though they were valid. > One possible reason for discarding such an entry could > be to free up buffer space for other routing entries." > ::= { ipForward 8 } > > to make it perfectly clear exactly what is being counted. I agree with the proposed text. In addition, I will add some description to Section 4 describing the relationship between this object and the deprecated object in the 2011 update. > > 2.) inetCidrRouteNumber has not been re-instated, but there are > still a number of references to it in the document. Either it > should be re-instated with the following definition: > > inetCidrRouteNumber OBJECT-TYPE > SYNTAX Gauge32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of current inetCidrRouteTable entries that > are not invalid." > ::= { ipForward 6 } > > or else the dangling references to it should be removed from Section > 4 and from the DESCRIPTION clause of ipCidrRouteNumber. In the > latter case the OID assignments under ipForward should also be > reshuffled to avoid gaps in the assignments (e.g., by changing the > sub-ID assigned to inetCidrRouteDiscards to 6 from 8). > > My very strong recommendation is to re-instate the object. I'll > note that there was agreement on this point in the e-mail that I > quoted above: > I agree. I will re-instate inetCidrRouteNumber. > >>>>>>On Fri, 31 Jan 2003, Bill Fenner wrote: > > Bill> I agree that there should be an inetCidrRouteNumber. > > The reason for wanting a summary counter is because the potentially > huge size of the inetCidrRouteTable makes it inefficient (and > probably infeasible) for a manager to derive that information by > downloading the whole table. > > The arguments quoted for its removal -- namely, that it may not > agree with the count of the in-view rows for some users and that it > may be difficuly for distributed agents to implement -- are, in my > opinion, irrelevant and unconvincing, respectively. Focusing on the > latter, the distributed agent implementation problems are not > insurmountable, and in any case must be weighed against the problems > caused for managers. And as Mike MacFaden has pointed out, agents > already have to solve that problem anyway for ipCidrRouteNumber -- > > >>>>>>On Fri, 7 Feb 2003, Mike MacFaden wrote: > > MM> Another thing not considered in Margaret's latest 2096 > MM> replacement draft is that both rfc2096 and its successor are > MM> both active in the same agent at the same time. > MM> > MM> So I think ipCidrRouteNumber will apply > MM> to both the existing and replacement table regardless, > MM> it will just be a count of the ipv4 routes... > > When this issue came up back in February there was a discussion on > the mreview mailing list, and contrary to some reports there is no > consensus among the MIB doctors that summary objects like these are > evil. See the thread "ifNumber and its ilk considered harmful" at > this URL: http://ops.ietf.org/lists/mreview/mreview.2003#00159 > > The rest of what follows below are MIB doctor-type nits. > > 3.) Normative references for some MIB modules that appear in the > IMPORTS list are missing. They are: > > MIB module document > > IF-MIB RFC 2863 > IP-MIB draft-ietf-ipv6-rfc2011-update-02.txt > IANA-RTPROTO-MIB http://www.iana.org//assignments/ianaiprouteprotocol-mib > > Please add these documents to the list of normative references. Will do. > > 4.) RFC 2096 appears as a normative reference. That is > inappropriate because it is not needed to implement the spec. All > it does is supply historical information, and so it should be turned > into an informative reference. (Note also that standards-track > documents are not normally allowed to refer normatively to documents > at a lower maturity level -- and that certainly applies to documents > that are being obsoleted.) OK. > > 5.) The material in Section 1 will need to be removed prior to > publication as an RFC. It would probably be a good idea to an an > RFC Editor note to that effect. It might also be a good idea to > make this an un-numbered section so that the section numbers stay > the same in the RFC and the final draft. Yep. > > 6.) When the document is published as an RFC, it should have a > change log detailing what was changed since RFC 2096 (it could point > to the most recent REVISION clause if the latter were a bit more > detailed). I will update the REVISION clause with text pointing out the added objects (e.g. inetCidrRouteDiscards), the overall goal of making the MIB IP version independent, and adding the read-only conformance. > > 7.) Several changes are needed in the MODULE-IDENTITY invocation: > > (a) Please add the standard MIB copyright notice to > the DESCRIPTION clause. For details see Section 3.8 > of , or > http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt. No problem. > > (b) Please change the 2nd REVISION/DESCRIPTION pair > from: > REVISION "200301130000Z" > DESCRIPTION > "Revised to support CIDR routes." > to: > REVISION "199609190000Z" > DESCRIPTION > "Revised to support CIDR routes. > Published as RFC 2096." > > i.e., please retain the original RFC 2096 rev date. OK. > > (c) Please add a 3rd REVISION/DESCRIPTION pair just > below that says: > > REVISION "199207022156Z" > DESCRIPTION > "Initial version, published as RFC 1354." OK. > > Note that the UTC time is taken from the date stamp on > http://www.rfc-editor.org/rfc/rfc1354.txt ... the > original module is in SMIv1 and so have no such clause. > > There may be more such stuff as I have not done a complete > MIB doctor review; I've covered only those issues that I > raised previously that were not yet dealt with. Thanks for the review, Mike. 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 Jun 26 08:17:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5QFHsMV028782; Thu, 26 Jun 2003 08:17:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h5QFHsH0028781; Thu, 26 Jun 2003 08:17:54 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5QFHoMV028774 for ; Thu, 26 Jun 2003 08:17:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5QFFmGq022862 for ; Thu, 26 Jun 2003 08:15:48 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5QFFcKo020142 for ; Thu, 26 Jun 2003 08:15:42 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00558; Thu, 26 Jun 2003 11:10:25 -0400 (EDT) Message-Id: <200306261510.LAA00558@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-03.txt Date: Thu, 26 Jun 2003 11:10:24 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Management Information Base for the Transmission Control Protocol (TCP) Author(s) : B. Fenner et al. Filename : draft-ietf-ipv6-rfc2012-update-03.txt Pages : 25 Date : 2003-6-26 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-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-rfc2012-update-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2012-update-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-26110635.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2012-update-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2012-update-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26110635.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 26 10:29:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5QHTjMV029535; Thu, 26 Jun 2003 10:29:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h5QHTjiA029534; Thu, 26 Jun 2003 10:29:45 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5QHTgMV029527 for ; Thu, 26 Jun 2003 10:29:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5QHRdGq014327 for ; Thu, 26 Jun 2003 10:27:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5QHRYKo016273 for ; Thu, 26 Jun 2003 10:27:34 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA12612; Thu, 26 Jun 2003 10:27:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h5QHRX917241; Thu, 26 Jun 2003 10:27:33 -0700 X-mProtect: <200306261727> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdENs5KC; Thu, 26 Jun 2003 10:27:31 PDT Message-ID: <3EFB2DB2.8050909@iprg.nokia.com> Date: Thu, 26 Jun 2003 10:30:26 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: Requirements for Limited-Scope Unicast Addressing in IPv6 References: <20030620023545.CFBB492@coconut.itojun.org> <3EF38D8B.4070906@iprg.nokia.com> <3EFA1CC4.B6967F27@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, I appreciate the comments and am in agreement with everything you had to say. I don't think there will be time to spin a new version ahead of the Vienna cutoff date, but will address the comments (along with Elliot Lear's suggestion on staying within the requirements space) soon thereafter. Fred Templin ftemplin@iprg.nokia.com Brian E Carpenter wrote: >Fred, > >My main comment on this useful draft is that I would like to >see it combined with draft-hain-ipv6-sitelocal-01.txt. We >only need one draft on this topic. > >You might add more scenarios that have to be supported > >- mergers and acquistions without instant renumbering >- dynamically created VPNs in support of temporary virtual organizations >- hosting of customer subnets by a service provider > >I would simply remove the language about deprecation. > > Brian > >Fred Templin wrote: > > >>A new draft has been posted to the I-D repository; details >>can be found below. Pls send comments to the list. >> >>Fred Templin >>ftemplin@iprg.nokia.com >> >>--- cut here --- >> >>A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : Requirements for Limited-Scope Unicast Addressing in >> IPv6 >> Author(s) : F. Templin >> Filename : draft-templin-lsareqts-00.txt >> Pages : 9 >> Date : 2003-6-20 >> >>The IPv6 addressing architecture specifies global and local-use >>unicast addressing schemes. Recent consensus call in the IPng working >>group has deprecated site-local addressing due in part to its >>inherent ambiguity. This document outlines requirements for use in >>evaluating candidate proposals for a replacement scheme. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-templin-lsareqts-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 Fri Jun 27 09:05:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5RG5g06006188; Fri, 27 Jun 2003 09:05:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h5RG5gm2006187; Fri, 27 Jun 2003 09:05:42 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5RG5c06006180 for ; Fri, 27 Jun 2003 09:05:38 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5RG3bUY015887 for ; Fri, 27 Jun 2003 09:03:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5RG3VfU015185 for ; Fri, 27 Jun 2003 09:03:31 -0700 (PDT) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 27 Jun 2003 18:03:35 +0100 Received: from edi-view1.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h5RG1RTA025360 for ; Fri, 27 Jun 2003 18:01:27 +0200 (MET DST) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA03508 for ipng@sunroof.eng.sun.com; Fri, 27 Jun 2003 17:03:29 +0100 (BST) Date: Fri, 27 Jun 2003 17:03:29 +0100 From: Derek Fawcus To: ipng@sunroof.eng.sun.com Subject: Re: Next steps on the IPv6 Node requirements draft Message-ID: <20030627170329.B21835@edi-view1.cisco.com> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <12731.1056020197@munnari.OZ.AU> <1ED6D618-A270-11D7-90A5-00039376A6AA@sun.com> <4.3.2.7.2.20030625072324.02396ae0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.3.2.7.2.20030625072324.02396ae0@funnel.cisco.com>; from rdroms@cisco.com on Wed, Jun 25, 2003 at 07:30:44AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Jun 25, 2003 at 07:30:44AM -0400, Ralph Droms wrote: > Regarding reverse DNS entries ... there is a specific problem > with reverse DNS entries for autoconfiguration addresses regarding > update of the reverse entries by the client. [ snip ] > There are solutions - disallow reverse DNS updates for > autoconfiguration addresses, let the DNS server that maintains > the prefix allow untrusted updates in the namespace for that > prefix, require some DNSSEC trust mechanism that supports > roaming. Or a simpler approach - make use of ICMP name lookups. Ask the end node it's name, then check the name/address relationship in the forward DNS (which we have to assume has been updated to point to the address). DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 30 04:55:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5UBtQ06023378; Mon, 30 Jun 2003 04:55:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1/Submit) id h5UBtQro023377; Mon, 30 Jun 2003 04:55:26 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta1+Sun/8.12.10.Beta1) with ESMTP id h5UBtM06023370 for ; Mon, 30 Jun 2003 04:55:22 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h5UBrHUY004965 for ; Mon, 30 Jun 2003 04:53:17 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5UBr8vc005323 for ; Mon, 30 Jun 2003 05:53:09 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12355; Mon, 30 Jun 2003 07:53:06 -0400 (EDT) Message-Id: <200306301153.HAA12355@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-icmp-name-lookups-10.txt Date: Mon, 30 Jun 2003 07:53:06 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Node Information Queries Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-name-lookups-10.txt Pages : 12 Date : 2003-6-27 This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-10.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-icmp-name-lookups-10.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-icmp-name-lookups-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-27150704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-name-lookups-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27150704.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 --------------------------------------------------------------------