From owner-ipng@sunroof.eng.sun.com Mon Jul 1 00:46:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g617khk7017802; Mon, 1 Jul 2002 00:46:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g617khm4017801; Mon, 1 Jul 2002 00:46:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g617kek7017794 for ; Mon, 1 Jul 2002 00:46:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08178 for ; Mon, 1 Jul 2002 00:46:45 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28060 for ; Mon, 1 Jul 2002 01:46:28 -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 g617jaV11740; Mon, 1 Jul 2002 14:45:36 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g617iZf24222; Mon, 1 Jul 2002 14:44:43 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: Brian E Carpenter , Keith Moore , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <20020701060247.19AB44B2B@coconut.itojun.org> References: <20020701060247.19AB44B2B@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jul 2002 14:44:35 +0700 Message-ID: <24220.1025509475@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 01 Jul 2002 15:02:47 +0900 From: itojun@iijlab.net Message-ID: <20020701060247.19AB44B2B@coconut.itojun.org> | it think i have already answered that question in the past: | draft-itojun-ipv6-local-experiment-02.txt Hmm - this is the (relevant) answer from your draft ... 2.4. Completely disconnected site If the site has no external IP connectivity, the site may use site local address space. What such a site would do if it there were no site local addresses isn't answered. But this is not really relevant, as it is already quite clear from this discussion that site local addresses are not going away. At most they may be modified a little. wrt your draft, in advising against site local addresses, you make three points ... o Site-local addresses are "scoped" address, while global addresses are not. o Configuration must correctly identify site border routers. This is an additional requirement. o There are proposals on scoped routing exist [Deering, 2000] , however, implementation status is still rather disappointing. For a disconnected site, the fact that site locals are scoped isn't really very important, as there's only one scope (the site itself). That is, for this purpose, a SL addr is the same as a global (which also has one scope). There are no site border routers for a disconnected site. Routing of SL's in a disconnected site is identical to routing globals. Where your draft is offering advice on how to get addresses, for a site that can get some kind of connectivity, it is fine, and I certainly agree that such sites should use global addresses - but it offers nothing much useful at all as regards site local addresses, and certainly provides no answers at all for how to handle a world in which SL's did not exist. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 01:20:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g618Kck7017875; Mon, 1 Jul 2002 01:20:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g618Kbft017874; Mon, 1 Jul 2002 01:20:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g618KYk7017867 for ; Mon, 1 Jul 2002 01:20:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA05132 for ; Mon, 1 Jul 2002 01:20:40 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA12997 for ; Mon, 1 Jul 2002 02:20:35 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g618KVC24652; Mon, 1 Jul 2002 10:20:31 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA01781; Mon, 1 Jul 2002 10:20:31 +0200 (MET DST) 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 g618KUGF001563; Mon, 1 Jul 2002 10:20:30 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207010820.g618KUGF001563@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Richard Draves" Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: Your message of Sun, 30 Jun 2002 19:28:59 +0200. <200206301728.g5UHSxGF099731@givry.rennes.enst-bretagne.fr> Date: Mon, 01 Jul 2002 10:20:30 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In my previous mail I wrote: Rule 8: Use longest matching prefix. If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB. => this rule has no meaning when CommonPrefixLen is not bound to 0..64. => I've changed a bit my mind about this: in fact the 64 boundary works only for IPv6 addresses, not for IPv4 addresses where the right boundary is between 96 and 128 (exclusive). So the right implementation of the CommonPrefixLen() function must include a sound maximal value for each prefix of the policy table. (BTW are there common cases where D8 is not overruled by D6 for not twisted policy tables?) => multicasts... I still wonder if the D8 is useful. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 03:38:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61Ac3k7018419; Mon, 1 Jul 2002 03:38:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61Ac3ZG018418; Mon, 1 Jul 2002 03:38:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61Abwk7018405 for ; Mon, 1 Jul 2002 03:37:58 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05871 for ; Mon, 1 Jul 2002 03:38:03 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15556 for ; Mon, 1 Jul 2002 04:38:03 -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 GAA21924; Mon, 1 Jul 2002 06:37:14 -0400 (EDT) Message-Id: <200207011037.GAA21924@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-savola-ipv6-127-prefixlen-04.txt Date: Mon, 01 Jul 2002 06:37:14 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use of /127 Prefix Length Between Routers Considered Harmful Author(s) : P. Savola Filename : draft-savola-ipv6-127-prefixlen-04.txt Pages : 6 Date : 28-Jun-02 In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This draft discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-04.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-savola-ipv6-127-prefixlen-04.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-savola-ipv6-127-prefixlen-04.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: <20020628142339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-savola-ipv6-127-prefixlen-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-savola-ipv6-127-prefixlen-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628142339.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 05:16:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61CGck7018753; Mon, 1 Jul 2002 05:16:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61CGcWf018752; Mon, 1 Jul 2002 05:16:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61CGZk7018745 for ; Mon, 1 Jul 2002 05:16:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00155 for ; Mon, 1 Jul 2002 05:16:41 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01456 for ; Mon, 1 Jul 2002 06:13:10 -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 g61BxqV00876; Mon, 1 Jul 2002 18:59:52 +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 g61BxGf25143; Mon, 1 Jul 2002 18:59:16 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Michel Py" cc: ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-Reply-To: <2B81403386729140A3A899A8B39B046405E170@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E170@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jul 2002 18:59:16 +0700 Message-ID: <25141.1025524756@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 28 Jun 2002 18:56:57 -0700 From: "Michel Py" Message-ID: <2B81403386729140A3A899A8B39B046405E170@server2000.arneill-py.sacramento.ca.us> | One of the drafts is ready | http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt Sorry, "ready" isn't an adjective I'd use to describe that draft. I've been trying to follow it over the weekend, and the best I've been able to do so far is to guess at what it is trying to describe. As best I can tell, this is a rehash of the old idea to separate the endpoint ID from the address (basically) - that is, there's the stable ID, which is constant, and the address, which is topology sensitive (just the same address that we have today). In this version those are both taken from the same address space (though different chunks of it) and constrained so that the numbering within a site is identical (the ID prefix will differ from the address prefix, but the rest of the bits will always be the same). Then, rather that simply carry both values in packets, a weird perversion of NAT is done, which flips from one value to the other in the packets while in transit. But I couldn't figure out exactly when that was supposed to happen exactly. I did understand that it is supposed to be invertible, so the endpoints don't ever know it happened (removing the worst effect of NAT). That is, the method described, as best I can understand it (which isn't much), isn't about geographic (or any other) PI addressing at all, it is about PI identification, and a method to allow that identification to be shoved into what is currently defined to be the address field of the packets. I would strongly suggest that this doc be seriously revised - as a first step, take what is in section 5, and move it somewhere down nearer the end. This is the section which contains all of the alternative methods that were considered but not adopted, and some reasons. While that kind of thing is valuable to keep, it isn't directly relevant to the protocol being described, and where it is at the minute, it just gets in the way. Replace that with a brief, non-technical, overview of the problem that is being solved, and how the protocol solves it. That is, something like Multihomed nodes need addresses which do not depend upon any one of their providers, so packets can reach them over any available path. This protocol designates identifiers to be used for that purpose, and details how they are to be used. (Here could be a bit about the two different kinds of PI "addressing" that are being proposed, but I don't think it is necessary). Then When a packet is addressed to a PI identifier, it will ... (and I can't supply any more, as I don't have the vaguest idea how it is supposed to actually work). But, in this section, please leave out "alias", "MHAP", and most of the rest of the stuff that appears in section 6. After reading this section, people should have a pretty good idea of what is being done, if not exactly how it all works, and then can attack section 6, with some kind of idea what all that is in there is attempting to achieve. Note, that when this has been explored before, the chief problem has been security. That is, we rely a lot upon the fact that routing and identification are tied together, for low level security. That is, if A receives a packet from B, sends a reply back, and gets a response to the reply, it can be fairly confident in most circumstances, that it really is B with which it is communicating. When using separate IDs for identification, all of that vanishes, and I don't see anything in your draft to address that problem. Certainly the security considerations section isn't useful as it is. It considers one particular problem, and (as best I can tell) offers as a solution for that "stick a random number in the packet, use that as a password, so anyone who can snoop it can do what they like". Of course, that might just be me failing to understand how any of this is intended to work. | Feel free to ask any questions you wish on ipv6mh. Sorry, I've forgotten where that list is, and I'm too busy/lazy at the minute to go hunting - if you want to move the discussion to some other place, give the complete address... | > The aim is a /48 for everyone (who requests one), right? | | At this point the aim is at multihomers only. That isn't exactly what I was referring to - the "/48 to everyone" was meant as a general reference - that is, all sites (large and small) receive /48 allocations (from somewhere), always, if they want one (that isn't to say that a single host can't just be given a /128 if that's all it requests .. in fact, the vast majority of hosts on the vast majority of networks will get exactly that). However, if you succeed in creating a PI address space that is available, you can be sure that it will be used by *everybody*. Pretending that only some subset of the internet will desire one of these PI addresses, or that there's any way to restrict their use is silly. Were you to try, I can see a nice business for someone as a "multihoming provider", who offers prefixes to people, but provides no connectivity at all, but with every appearance of being an alternate point of connectivity from the outside (one that just happens to be down a lot when people attempt to test it...). Then of course, once the PI address is obtained, the contract with that provider will be allowed to lapse - it isn't needed for anything any more. Your scheme is even worse than that though, as you have two types of PI addresses, geographic (which ties people to one area) and the other kind "for large multi-nationals". The latter is the kind I'll be applying for for my laptop, after all, it is multi-national (connects to the net in lots of different nations), and I am large... The draft claims that it solves scaling by reducing the size of the tables by a factor of 100 (which seems to come from nowhere, but for now let's just accept it). Sorry - linear factor reductions are useless for this purpose, even large ones. Exponential growth, divided by 100, is still exponential growth. To solve the scaling problems, you need to do something to change the exponential growth, to at least linear, and preferably less than that. Before I finish, in the revised draft, you will also need to say a lot more about the "local aggregation authority" - where it comes from, what it does, etc. At one point the draft suggests that it could be "one of the ISPs", but with no suggestion on how that ISP is selected, or what it means to be the one who is blessed (or not to be). This is another area that needs lots of work, as creating lots of new authorities, without some method for determining just who they are, and how they are controlled, is a sure recipe for disaster. | > It isn't possible to enforce anything by relying upon protocols, | > we have to depend upon agreements, and when appropriate "it is | > the only possible way". | | I have to disagree with this. If by _design_ these geo prefixes are not | in the global routing table, the only leaks could be because of | configuration snafus. Huh? All prefixes are just numbers. They're all being taken from the same number space. How can they possibly "by design" not all fit in the same routing table. You're relying on people filtering these particular numbers, which they will do, only while there some incentive to do that, and no incentive to do otherwise. kre ps: I am still looking for a proposal that uses geographic *addresses* and can work without connectivity/transit requirements being imposed upon the ISPs that claim to offer service in that geographic area. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 05:17:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61CHNk7018765; Mon, 1 Jul 2002 05:17:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61CHNPp018764; Mon, 1 Jul 2002 05:17:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61CHIk7018757 for ; Mon, 1 Jul 2002 05:17:19 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00395 for ; Mon, 1 Jul 2002 05:17:25 -0700 (PDT) Received: from relay.mail.bg (host.cyberbg.com [212.91.166.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA03402 for ; Mon, 1 Jul 2002 06:17:23 -0600 (MDT) Received: (qmail 21847 invoked from network); 1 Jul 2002 12:16:44 -0000 Received: from web1.mail.bg (212.91.166.100) by host.cyberbg.com with QMQP; 1 Jul 2002 12:17:06 -0000 To: IPng Discussion Subscribers Subject: IP grand-Next Generation addressing Message-ID: <1025525841.3d204851c0d24@mail.bg> Date: Mon, 01 Jul 2002 15:17:21 +0300 (EEST) From: Toni Stoev MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit User-Agent: mail.bG web interface 2.22 X-Originating-IP: 212.116.128.16 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, everybody. I propose a grand-next generation addressing approach: – Hierarchical levels in a certain unicast type of addresses to represent actual connectivity: A node is elected to be a starting node. Every node's neighbors are identified uniquely to that node. A node's connectivity address (location) from a starting node is a sequence of neighbor identifications representing a path from the starting node to the node having the address. Consequences: Nodes with addresses from the same starting node (root) form a routing domain (tree; may be called also a site, if this concept is unoccupied). There is more. The following information is appended by dispatch service provider for this message. __________________________________ 12MB-POP3-WAP-SMS---TOBA-E-mail.bG ---------------------------------- " Ako uckame u Bue agpec B mail.bg ugeme myk: http://www.mail.bg/new/ " -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 06:39:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61Dd0k7018872; Mon, 1 Jul 2002 06:39:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61Dd0SZ018871; Mon, 1 Jul 2002 06:39:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61Dcvk7018864 for ; Mon, 1 Jul 2002 06:38:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15088 for ; Mon, 1 Jul 2002 06:39:02 -0700 (PDT) Received: from gateus.nmss.com (gateus.nmss.com [208.236.204.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA12784 for ; Mon, 1 Jul 2002 07:39:01 -0600 (MDT) Received: from NAMASMTP02 by gateus.nmss.com via smtpd (for kathmandu.sun.com [192.18.98.36]) with SMTP; 1 Jul 2002 08:34:53 UT Subject: RE: Stateful Address Config - I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt To: Cc: Adam_Machalek@nmss.com, ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Adam Machalek" Date: Mon, 1 Jul 2002 08:15:01 -0500 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.10 |March 22, 2002) at 07/01/2002 09:35:12 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g61Dcvk7018865 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, I was hoping for something a little more specific, helping to clear up just what an implementation needs in order to be conformant. How does something like the following sound? 4.4.5 Stateful Address Autoconfiguration Stateful Address Autoconfiguration is conditionally mandatory. For those IPv6 Nodes that implement a stateful configuration mechanism such as [DHCPv6], those nodes SHOULD/MUST initiatiate stateful address autoconfiguration upon the reciept of a Router Advertisement with the Managed address flag set. In addition, as defined in [RFC2462], in the absence of a router, hosts that implement a stateful configuration mechanism such as [DHCPv6] MUST attempt to use stateful address autoconfiguration. For IPv6 Nodes that do not implement the optional stateful configuration mechanisms such as [DHCPv6], the Managed Address flag of a Router Advertisement can be ignored. Furthermore, in the absensce of a router, this type of node is not required to initiate stateful address autoconfiguration as specified in [RFC2462]. Adam Machalek To: , cc: 06/28/2002 05:54 Subject: RE: Stateful Address Config - I-D AM ACTION:draft-ietf-ipv6-node-requirements-00.txt Hi Adam, Very good point.  I have added the following text: 4.5.5 Stateful Address Autoconfiguration IPv6 Stateless Address Autoconfiguration [RFC2462] defines stateless address autoconfiguation.  However, it does state that in the absence of routers, hosts must perform host MUST attempt to use stateful autoconfiguration.  There is also reference to stateful address autoconfiguration being defined elsewhere. Additionally, DHCP [DHCP] states that it is on option for stateful address autoconfiguation. >From the current set of specification, it is not clear the level of support that is needed for statefull Address Autoconfiguration. -----Original Message----- From: ext Adam Machalek [mailto:Adam_Machalek@nmss.com] Sent: 21 June, 2002 18:52 To: ipng@sunroof.eng.sun.com Subject: Stateful Address Config - I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt John, Section 5.4 on DHCPv6 states that DHCPv6 is unconditionally optional, which today implicitly makes Stateful Address config optional. However, I'd like to see some direct clarification in this document on Stateful Address config, probably directly after Section 4.5.2 discussing Stateless Address config. RFC2462 has some ambiguities, in particular, it states "a managed address configuration flag indicates whether hosts should use stateful autoconfiguration", not SHOULD.   Later in 2462 in section 5.2 it continues this ambiguity by never explicitly using MAY/SHOULD/MUST anywhere. Still later in section RFC2462 5.5.2 Absence of Router Advertisements, it finally states that in the absence of a router, a host MUST attempt to use stateful autoconfiguration. And lastly, the DHCPv6 draft states "DHCP is one vehicle to perform stateful autoconfiguration", implying that there may be others. So in the end, even with DHCPv6 optional, this doesn't clarify exactly what a host should do about Stateful Address autoconfiguration. Adam Machalek -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 07:04:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61E4Ok7018947; Mon, 1 Jul 2002 07:04:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61E4NTu018946; Mon, 1 Jul 2002 07:04:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61E4Kk7018939 for ; Mon, 1 Jul 2002 07:04:20 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19448 for ; Mon, 1 Jul 2002 07:04:25 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24610 for ; Mon, 1 Jul 2002 08:04:24 -0600 (MDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g61E3l2F087250; Mon, 1 Jul 2002 16:03:47 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g61E3hu129362; Mon, 1 Jul 2002 16:03:43 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38764 from ; Mon, 1 Jul 2002 16:03:12 +0200 Message-Id: <3D206152.853BE628@hursley.ibm.com> Date: Mon, 01 Jul 2002 16:04:02 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Alain Durand Cc: Margaret Wasserman , hinden@iprg.nokia.com, deering@cisco.com, Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt References: <0C47439E-8AF8-11D6-A4F4-00039376A6AA@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree that this is probably better as a BCP. Brian Alain Durand wrote: > > On Thursday, June 27, 2002, at 09:41 PM, Margaret Wasserman wrote: > > > The Default Address Selection document has been out for months, has > > been reviewed several times by the WG, has undergone a WG last call and > > has been reviewed by the IESG. It doesn't seem right to delay this > > draft indefinitely waiting for another draft, especially when we haven't > > been told about any specific problems that this draft will cause. > > > > If there are specific, technical objections to this draft, please state > > them clearly on the mailing list. It would also be helpful to suggest > > specific text changes to the draft. This will give others and > > opportunity > > to agree or disagree about whether the issues should block the > > publication > > of this draft. > > Margaret, > > Publishing this draft will have the effect to stop any further discussion > on who should be responsible to make the choice of SL vs GL > when both are available: is it a kernel function by default or > an well understood application choice. > > I'm not sure about which is best at this point of the discussion. > Keith has arguments that I would like to understand better. > Too bad he couldn't publish a draft before the cut-off date... > > In particular, I would like to understand what would be the impact > on applications that are not SL aware the day the site admin decides > to turn on SL by publishing them in the internal view of the DNS... > > I'm not a SIP expert, so I may be wrong, but I'm worried about > what will happen to a SIP gateway when all the sudden it will receive > a request originating from Site Local scope for an external address? > > I'm concerned that the only API required by the draft is about > reversing the public vs temporary rule and that nothing is require > to enable applications to reverse the other rules. > > I will have much less concern if the draft was to be published as BCP, > as it is easy to change if proven wrong. I'm concerned it would be more > difficult to change in the Standard Track. > > So I have 2 suggestions: > a) leave the text as it is but publish it as BCP. As there are things we > do not clearly > understand now, it would be easier to change later. > > b) or reverse rule 2 by default and require an API to enable application > to request SL when available. > > - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 07:16:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61EGlk7018970; Mon, 1 Jul 2002 07:16:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61EGksD018969; Mon, 1 Jul 2002 07:16:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61EGhk7018962 for ; Mon, 1 Jul 2002 07:16:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19224 for ; Mon, 1 Jul 2002 07:16:48 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02035 for ; Mon, 1 Jul 2002 08:16:47 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g61EGd226327; Mon, 1 Jul 2002 10:16:40 -0400 (EDT) Message-Id: <200207011416.g61EGd226327@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Vijay Amrit Agrawal" cc: "Keith Moore" , ipng@sunroof.eng.sun.com Subject: Re: Maybe: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Mon, 01 Jul 2002 11:16:01 +0530.") <002201c220c2$95179490$9704120a@in.huawei.com> Date: Mon, 01 Jul 2002 10:16:38 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hi, > The disadvantages of NAT is pretty well known but I was trying to see if I > can extract any feature of NAT that is useful. I am not saying that use NAT > as it is, but see if we can learn any thing positive from it, beside saying > it has problems. These are the two things which I think we can learn from > NAT: I'm replying to this privately so as not to burden the list with a discussion of NAT. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 07:31:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61EV4k7019020; Mon, 1 Jul 2002 07:31:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61EV4cX019019; Mon, 1 Jul 2002 07:31:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61EV0k7019012 for ; Mon, 1 Jul 2002 07:31:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26363 for ; Mon, 1 Jul 2002 07:31:06 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13456 for ; Mon, 1 Jul 2002 07:31:05 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g61EMd227132; Mon, 1 Jul 2002 10:22:40 -0400 (EDT) Message-Id: <200207011422.g61EMd227132@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: itojun@iijlab.net, Brian E Carpenter , Keith Moore , Michael Thomas , Michel Py , ipng@sunroof.eng.sun.com Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols In-reply-to: (Your message of "Mon, 01 Jul 2002 14:44:35 +0700.") <24220.1025509475@munnari.OZ.AU> Date: Mon, 01 Jul 2002 10:22:39 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For a disconnected site, the fact that site locals are scoped isn't really > very important, as there's only one scope (the site itself). That is, for > this purpose, a SL addr is the same as a global (which also has one scope). it's almost the same. first, completely isolated sites aren't as interesting as sites that do have some connection to other sites - just not to the public Internet. and the other sites might have external connections...) as we learned with RFC 1918, sooner or later many isolated nets will want to connect to other sites. the second difference with SLs is in application policy - an application that is written to avoid use of SLs (because they are ambiguous) may not work on a net that uses only SLs. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 08:52:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61Fqdk7019425; Mon, 1 Jul 2002 08:52:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61Fqcjw019424; Mon, 1 Jul 2002 08:52:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61FqYk7019417 for ; Mon, 1 Jul 2002 08:52:34 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16313 for ; Mon, 1 Jul 2002 08:52:40 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20189 for ; Mon, 1 Jul 2002 09:52:39 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g61FpxA25625; Tue, 2 Jul 2002 00:52:09 +0900 (JST) Date: Tue, 02 Jul 2002 00:51:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: "Richard Draves" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-Reply-To: <200206301728.g5UHSxGF099731@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200206301728.g5UHSxGF099731@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 54 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 30 Jun 2002 19:28:59 +0200, >>>>> Francis Dupont said: > Rule 7: Prefer public addresses. > If SA is a public address and SB is a temporary address, then prefer > SA. Similarly, if SB is a public address and SA is a temporary > address, then prefer SB. > => even if I believe this is the right choice I don't know there is > a strong consensus. > An implementation MUST support a per-connection configuration > mechanism (for example, a socket option) to reverse the sense of > this preference and prefer temporary addresses over public > addresses. > => again this is inadequate and stresses the previous issue. > This MUST must not move to the standard track part. > Note my environment suggestion works well for this case because > daemons (which want the public address) run with another userID > than applications of physical users (which want a temporary address). > We really need soemthing tunable from the outside, not a new switch > in every applications... I tend to agree. I previously said a per-node switch is better for privacy purposes (though some disagreed), but more accurately, a per-user switch is better. > PS: about KAME implementation, what about: (We may change the place to discuss the implementation-specific issues, but I'll reply to them here for now.) > - move the policy table rules just after the common sense rules We can but I'm not sure if it is appropriate to do so before making a consensus. > - put the policy table in a per-process space (u-area)? It's a good idea. However, I don't know a good API for this. As you mentioned in the public vs temporary case, a socket option is not suitable. > - limit in6_matchlen() to 64 for address selection. I agree that full-128bit comparison does usually not make much sense, but I'm not sure if the assumption of the fixed prefix length is a good idea... 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 Jul 1 09:17:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61GHJk7019494; Mon, 1 Jul 2002 09:17:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61GHJOH019493; Mon, 1 Jul 2002 09:17:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61GHEk7019486 for ; Mon, 1 Jul 2002 09:17:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21635 for ; Mon, 1 Jul 2002 09:17:21 -0700 (PDT) Received: from esunmail ([129.147.58.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07479 for ; Mon, 1 Jul 2002 10:17:21 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GYK00DJWVWUE9@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 01 Jul 2002 10:17:21 -0600 (MDT) Received: from localhost ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GYK00AC0VWTSP@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 01 Jul 2002 10:17:18 -0600 (MDT) Date: Mon, 01 Jul 2002 09:17:16 -0700 From: Alain Durand Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Cc: Francis Dupont , Richard Draves , ipng@sunroof.eng.sun.com Message-id: <02D145FF-8D0E-11D6-B7BB-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=ISO-2022-JP; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Monday, July 1, 2002, at 08:51 AM, JINMEI Tatuya / $B?@L@C#:H(B wrote: > >> => again this is inadequate and stresses the previous issue. >> This MUST must not move to the standard track part. >> Note my environment suggestion works well for this case because >> daemons (which want the public address) run with another userID >> than applications of physical users (which want a temporary address). >> We really need soemthing tunable from the outside, not a new switch >> in every applications... > > I tend to agree. I previously said a per-node switch is better for > privacy purposes (though some disagreed), but more accurately, a > per-user switch is better. The same user may want to use privacy when browsing the wild wild web and application robustness when accessing data on a file server. I like Francis suggestion of an environment switch. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 10:21:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61HLtk7019737; Mon, 1 Jul 2002 10:21:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61HLtF6019736; Mon, 1 Jul 2002 10:21:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61HLqk7019729 for ; Mon, 1 Jul 2002 10:21:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13686 for ; Mon, 1 Jul 2002 10:21:58 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04155 for ; Mon, 1 Jul 2002 10:21:57 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g61HM3124031; Mon, 1 Jul 2002 12:22:04 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 12:21:50 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E04703A07@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Michel Py , ipng@sunroof.eng.sun.com Subject: RE: Site Locals and the DFZ Date: Mon, 1 Jul 2002 12:21:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22123.C6D97FF0" 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_01C22123.C6D97FF0 Content-Type: text/plain; charset="iso-8859-1" Michel, While I definitely agree with the statement, "If there is a place where you would find disparate routing policies, that is the DFZ.", I'm not sure if this should be used to conclude that there is no use of thinking of the DFZ as some sort of logical site with a site local address space. Glenn ------_=_NextPart_001_01C22123.C6D97FF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Site Locals and the DFZ

Michel,

While I definitely agree with the statement, "If = there is a place where you would find disparate routing policies, that = is the DFZ.", I'm not sure if this should be used to conclude that = there is no use of thinking of the DFZ as some sort of logical site = with a site local address space.

 

Glenn



------_=_NextPart_001_01C22123.C6D97FF0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 10:42:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61Hg3k7019820; Mon, 1 Jul 2002 10:42:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61Hg2Om019819; Mon, 1 Jul 2002 10:42:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61Hfwk7019812 for ; Mon, 1 Jul 2002 10:41:58 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20065 for ; Mon, 1 Jul 2002 10:42:04 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08066 for ; Mon, 1 Jul 2002 10:42:03 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g61Hfp225660; Mon, 1 Jul 2002 13:41:51 -0400 (EDT) Message-Id: <200207011741.g61Hfp225660@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Alain Durand cc: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= , Francis Dupont , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Mon, 01 Jul 2002 09:17:16 PDT.") <02D145FF-8D0E-11D6-B7BB-00039376A6AA@sun.com> Date: Mon, 01 Jul 2002 13:41:51 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The same user may want to use privacy when browsing > the wild wild web and application robustness when > accessing data on a file server. indeed, and that's assuming the user actually understands the implications of the privacy vs. robustness decision - which seems like a big stretch. the only party who is really in a position to make a good choice for address selection policy is the application writer. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 10:51:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61Hphk7019845; Mon, 1 Jul 2002 10:51:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g61HpgvV019844; Mon, 1 Jul 2002 10:51:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g61Hpck7019837 for ; Mon, 1 Jul 2002 10:51:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22954 for ; Mon, 1 Jul 2002 10:51:44 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11678 for ; Mon, 1 Jul 2002 11:51:43 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g61Hpb225922; Mon, 1 Jul 2002 13:51:37 -0400 (EDT) Message-Id: <200207011751.g61Hpb225922@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Francis Dupont , "Richard Draves" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Tue, 02 Jul 2002 00:51:57 +0900.") Date: Mon, 01 Jul 2002 13:51:37 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > - limit in6_matchlen() to 64 for address selection. > > I agree that full-128bit comparison does usually not make much sense, > but I'm not sure if the assumption of the fixed prefix length is a > good idea... I'm reasonably certain it's a bad idea - I fully expect that some sites will need to have prefixes > 64 bits, either because the ISP didn't follow the rules or they really need to subnet something hanging off a /64. I'm starting to think that rather than having all of these (address prefix and length) constants wired in to code, there might need to be a couple of configurable tables somewhere: one table might map prefixes onto address classes another table might be a matrix of source vs. destination address classes, mapping those to preference values for each of several conditions to be supplied by the app (does the app prefer privacy, address stability, proximity, global addresses, or what?) then the app would call a sort_addresses routine that ordered the various possible (source, destination) address pairs according to which ones seemed to best fit that app's requirements. but this is a huge mess. even if we might end up needing something like this, we really ought to work on reducing the number of addresses that an app is expected to deal with. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 17:26:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g620Qik7020691; Mon, 1 Jul 2002 17:26:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g620QiYk020690; Mon, 1 Jul 2002 17:26:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g620Qfk7020683 for ; Mon, 1 Jul 2002 17:26:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19571 for ; Mon, 1 Jul 2002 17:26:49 -0700 (PDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21399 for ; Mon, 1 Jul 2002 18:26:48 -0600 (MDT) content-class: urn:content-classes:message Subject: RE: Site Locals and the DFZ MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 1 Jul 2002 17:26:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046406C8D6@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Site Locals and the DFZ Thread-Index: AcIhXyamDL19PjT9SoioU4PfN3JliA== From: "Michel Py" To: "Glenn Morrow" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g620Qgk7020684 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Glenn, > While I definitely agree with the statement, "If there is a place > where you would find disparate routing policies, that is the DFZ.", > I'm not sure if this should be used to conclude that there is no > use of thinking of the DFZ as some sort of logical site with a site > local address space. I don't see how. First, a site to me is under one administration, which is not the case of the DFZ. Second, having site local addresses in the DFZ would make troubleshooting difficult. 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 Jul 1 22:07:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6257Qk7021788; Mon, 1 Jul 2002 22:07:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6257QfL021787; Mon, 1 Jul 2002 22:07:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6257Mk7021777 for ; Mon, 1 Jul 2002 22:07:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA04809 for ; Mon, 1 Jul 2002 22:07:29 -0700 (PDT) Received: from web13102.mail.yahoo.com (web13102.mail.yahoo.com [216.136.174.147]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA05948 for ; Mon, 1 Jul 2002 23:07:28 -0600 (MDT) Message-ID: <20020702050728.83352.qmail@web13102.mail.yahoo.com> Received: from [198.62.10.2] by web13102.mail.yahoo.com via HTTP; Tue, 02 Jul 2002 06:07:28 BST Date: Tue, 2 Jul 2002 06:07:28 +0100 (BST) From: =?iso-8859-1?q?jaganbabu=20rajamanickam?= Subject: regarding ipv6 - ipv4 router configuration To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have a basic question on configuring IPV6 router with IPV4 peer. +--------+ +--------+ | | | | | |IF1 | | | R1 |<----------->| R2 | | | IF2 | | +--------+ +--------+ If R1 is router which supports both IPV6 and IPV4 stack. If R2 is simple IPV4 router. so in the above case, should the interface address at R1 (IF1) be of IPV4 address, since it is connecting to another router "R2" which is an IPV4 router. Thanx, Jags ________________________________________________________________________ Want to sell your car? advertise on Yahoo Autos Classifieds. It's Free!! visit http://in.autos.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 1 22:16:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g625Gkk7021837; Mon, 1 Jul 2002 22:16:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g625GkSh021836; Mon, 1 Jul 2002 22:16:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g625Ghk7021829 for ; Mon, 1 Jul 2002 22:16:43 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA27646 for ; Mon, 1 Jul 2002 22:16:50 -0700 (PDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA21101 for ; Mon, 1 Jul 2002 23:16:50 -0600 (MDT) Received: from intpmail.iprc.lucent.com (h135-254-249-250.lucent.com [135.254.249.250]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g625GlC25390 for ; Tue, 2 Jul 2002 01:16:48 -0400 (EDT) Received: from VIKRAM by intpmail.iprc.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA19965; Tue, 2 Jul 2002 10:46:46 +0530 (IST) From: "Vikram Shekhar" To: Subject: RE: regarding ipv6 - ipv4 router configuration Date: Tue, 2 Jul 2002 10:46:43 +0530 Message-ID: <004501c22187$a8795260$2bd5fe87@VIKRAM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <20020702050728.83352.qmail@web13102.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The interface for the router R1 will still be with the ipv6 addressing since, ipv6 also supports ipv4. Whenever it receives a packet of type ipv4, it should be encapsulated into ipv6 at the IF1. To transmit a packet out for ipv4, the ipv6 packet from IF1 will again be transmitted as an ipv4 packed instead of ipv6. The ipv6 provides compatibility between the other version, and hence should not pose any conflict. Vikram Shekhar -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of jaganbabu rajamanickam Sent: Tuesday, July 02, 2002 10:37 AM To: ipng@sunroof.eng.sun.com Subject: regarding ipv6 - ipv4 router configuration Hi, I have a basic question on configuring IPV6 router with IPV4 peer. +--------+ +--------+ | | | | | |IF1 | | | R1 |<----------->| R2 | | | IF2 | | +--------+ +--------+ If R1 is router which supports both IPV6 and IPV4 stack. If R2 is simple IPV4 router. so in the above case, should the interface address at R1 (IF1) be of IPV4 address, since it is connecting to another router "R2" which is an IPV4 router. Thanx, Jags ________________________________________________________________________ Want to sell your car? advertise on Yahoo Autos Classifieds. It's Free!! visit http://in.autos.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 2 01:00:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6280Uk7022029; Tue, 2 Jul 2002 01:00:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6280U41022028; Tue, 2 Jul 2002 01:00:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6280Pk7022021 for ; Tue, 2 Jul 2002 01:00:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA05962 for ; Tue, 2 Jul 2002 01:00:30 -0700 (PDT) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25952 for ; Tue, 2 Jul 2002 02:00:29 -0600 (MDT) Received: from jpxiong (infonet.ipv6.ustc.edu.cn [202.38.75.75]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id PAA12864 for ; Tue, 2 Jul 2002 15:53:40 +0800 Message-Id: <200207020753.PAA12864@mx1.ustc.edu.cn> Date: Tue, 2 Jul 2002 15:57:32 +0800 From: jpxiong To: "ipng@sunroof.eng.sun.com" Subject: [help]About windowsXP,HP-UN and Solaris's IPv6 X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="US_ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk When I use those os'IPv6 stack to communication,I wonder weather the IPv4 stack is necessary exist.That is to say,can i uninstall the ipv4 stack and remain the ipv6's ability? Thank in advance. joe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 2 01:30:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g628USk7022108; Tue, 2 Jul 2002 01:30:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g628USQY022107; Tue, 2 Jul 2002 01:30:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g628UPk7022100 for ; Tue, 2 Jul 2002 01:30:25 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13684 for ; Tue, 2 Jul 2002 01:30:30 -0700 (PDT) Received: from relay.mail.bg (host.cyberbg.com [212.91.166.121]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA26076 for ; Tue, 2 Jul 2002 01:30:28 -0700 (PDT) Received: (qmail 18811 invoked from network); 2 Jul 2002 08:29:45 -0000 Received: from web1.mail.bg (212.91.166.100) by host.cyberbg.com with QMQP; 2 Jul 2002 08:29:45 -0000 To: IPng Discussion Subscribers Subject: IP grand-Next Generation addressing Message-ID: <1025598625.3d2164a1f10fd@mail.bg> Date: Tue, 02 Jul 2002 11:30:25 +0300 (EEST) From: Toni Stoev MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit User-Agent: mail.bG web interface 2.22 X-Originating-IP: 195.34.98.139 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, everybody. I propose another grand-next generation addressing approach: – A certain type of addresses, inicast, to represent connectivity-address cognition: Certain nodes are elected to be initial nodes. Nodes use to mutually know connectivity addresses with other nodes (acquaintances). Every node's such mutually known nodes are identified uniquely to that node. A node's connectivity-address cognition address (definition) from an initial node is a sequence of mutual-cognition node identifications representing a cognition path from the initial node to the node having the address. Consequences: Nodes are uniquely identified by connectivity cognition and are reachable through connectivity-knowing nodes. Yet there is more. The following information is appended by dispatch service provider for this message. __________________________________ 12MB-POP3-WAP-SMS---TOBA-E-mail.bG ---------------------------------- " Ako uckame u Bue agpec B mail.bg ugeme myk: http://www.mail.bg/new/ " -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 2 01:35:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g628Z6k7022147; Tue, 2 Jul 2002 01:35:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g628Z6cA022146; Tue, 2 Jul 2002 01:35:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g628Z3k7022138 for ; Tue, 2 Jul 2002 01:35:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14521 for ; Tue, 2 Jul 2002 01:35:09 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14277 for ; Tue, 2 Jul 2002 02:35:08 -0600 (MDT) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id KAA07746; Tue, 2 Jul 2002 10:35:06 +0200 (MET DST) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA17189; Tue, 2 Jul 2002 10:34:07 +0200 (CEST) Date: Tue, 2 Jul 2002 10:34:07 +0200 From: Ignatios Souvatzis To: jpxiong Cc: "ipng@sunroof.eng.sun.com" Subject: Re: [help]About windowsXP,HP-UN and Solaris's IPv6 Message-ID: <20020702103407.B17129@tarski.cs.uni-bonn.de> References: <200207020753.PAA12864@mx1.ustc.edu.cn> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="5I6of5zJg18YgZEa" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200207020753.PAA12864@mx1.ustc.edu.cn>; from xjping@mail.ustc.edu.cn on Tue, Jul 02, 2002 at 03:57:32PM +0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --5I6of5zJg18YgZEa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 02, 2002 at 03:57:32PM +0800, jpxiong wrote: > When I use those os'IPv6 stack to communication,I wonder weather the > IPv4 stack is necessary exist.That is to say,can i uninstall the ipv4 > stack and remain the ipv6's ability? In theory, yes. However, depending on the internal structure of the networking stacks in the products you mentioned, this might be different. Please ask the respective vendors for information about this. Regards, -is --5I6of5zJg18YgZEa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPSFlezCn4om+4LhpAQH6Awf/dQb7l8mfaYpTiBYcqpIYY6OX3ioVCmSd h9EDAxaun3wKtpnp1MUaMYIusTmUdL+m2qAAF591WYYYGnuU/YHNZidRV18m3orb s6Zb0zpXtv2Whmx+RGh/GLwrJTk7mXrRdw58Uo7jy5H2JC7Krfa8Z+xzkMO1Ppzy Fw7diD45sRdLVDfGjQFkNVF6ISfaFq4NyFkH/eUNQ5cwP6MGgSxXcY53Hs3hsWtF AkCwtuQQduMUU4KbooCq8ThDE1wU4mKEXYhV35A5XKXAmwsW9KNRUtK9FLOhe0SD odfDtrrk0tXuz5gFY/eftXZZAxnf++qEpQ0BHyMbFAfa70GTPzjLLg== =t6dD -----END PGP SIGNATURE----- --5I6of5zJg18YgZEa-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 2 01:41:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g628f2k7022165; Tue, 2 Jul 2002 01:41:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g628f2e2022164; Tue, 2 Jul 2002 01:41:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g628ewk7022157 for ; Tue, 2 Jul 2002 01:40:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13031 for ; Tue, 2 Jul 2002 01:41:04 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17192 for ; Tue, 2 Jul 2002 02:41:03 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g628epC14917; Tue, 2 Jul 2002 11:40:51 +0300 Date: Tue, 2 Jul 2002 11:40:51 +0300 (EEST) From: Pekka Savola To: Toni Stoev cc: IPng Discussion Subscribers Subject: Re: IP grand-Next Generation addressing In-Reply-To: <1025598625.3d2164a1f10fd@mail.bg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2 Jul 2002, Toni Stoev wrote: > I propose another grand-next generation addressing approach: > – A certain type of addresses, inicast, to represent connectivity-address > cognition: > Certain nodes are elected to be initial nodes. > Nodes use to mutually know connectivity addresses with other nodes > (acquaintances). Every node's such mutually known nodes are identified > uniquely to that node. > A node's connectivity-address cognition address (definition) from an > initial node is a sequence of mutual-cognition node identifications > representing a cognition path from the initial node to the node having > the address. > Consequences: > Nodes are uniquely identified by connectivity cognition and are reachable > through connectivity-knowing nodes. This does not belong to addressing. See http://www.ietf.org/html.charters/manet-charter.html for more ideas. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 2 02:05:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6295Lk7022261; Tue, 2 Jul 2002 02:05:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6295L74022260; Tue, 2 Jul 2002 02:05:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6295Ik7022253 for ; Tue, 2 Jul 2002 02:05:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28100 for ; Tue, 2 Jul 2002 02:05:24 -0700 (PDT) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13927 for ; Tue, 2 Jul 2002 02:05:22 -0700 (PDT) Received: from jpxiong (infonet.ipv6.ustc.edu.cn [202.38.75.75]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id RAA20482; Tue, 2 Jul 2002 17:01:23 +0800 Message-Id: <200207020901.RAA20482@mx1.ustc.edu.cn> Date: Tue, 2 Jul 2002 17:5:16 +0800 From: jpxiong To: Ignatios Souvatzis , jpxiong CC: "ipng@sunroof.eng.sun.com" Subject: Re: Re: [help]About windowsXP,HP-UN and Solaris's IPv6 X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="US_ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6295Ik7022254 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for your reply. So do i think,but i do not try to practise :( at 2002-7-2 10:34:00 you wrote£º >On Tue, Jul 02, 2002 at 03:57:32PM +0800, jpxiong wrote: > >> When I use those os'IPv6 stack to communication,I wonder weather the >> IPv4 stack is necessary exist.That is to say,can i uninstall the ipv4 >> stack and remain the ipv6's ability? > >In theory, yes. However, depending on the internal structure of the networking >stacks in the products you mentioned, this might be different. Please ask >the respective vendors for information about this. > >Regards, > -is > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.i > >iQEVAgUBPSFlezCn4om+4LhpAQH6Awf/dQb7l8mfaYpTiBYcqpIYY6OX3ioVCmSd >h9EDAxaun3wKtpnp1MUaMYIusTmUdL+m2qAAF591WYYYGnuU/YHNZidRV18m3orb >s6Zb0zpXtv2Whmx+RGh/GLwrJTk7mXrRdw58Uo7jy5H2JC7Krfa8Z+xzkMO1Ppzy >Fw7diD45sRdLVDfGjQFkNVF6ISfaFq4NyFkH/eUNQ5cwP6MGgSxXcY53Hs3hsWtF >AkCwtuQQduMUU4KbooCq8ThDE1wU4mKEXYhV35A5XKXAmwsW9KNRUtK9FLOhe0SD >odfDtrrk0tXuz5gFY/eftXZZAxnf++qEpQ0BHyMbFAfa70GTPzjLLg== >=t6dD >-----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 Tue Jul 2 06:16:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62DGbk7023251; Tue, 2 Jul 2002 06:16:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62DGaZl023248; Tue, 2 Jul 2002 06:16:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62DGVk7023234 for ; Tue, 2 Jul 2002 06:16:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29350 for ; Tue, 2 Jul 2002 06:16:37 -0700 (PDT) Received: from web13106.mail.yahoo.com (web13106.mail.yahoo.com [216.136.174.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA03870 for ; Tue, 2 Jul 2002 07:16:36 -0600 (MDT) Message-ID: <20020702131635.12137.qmail@web13106.mail.yahoo.com> Received: from [198.62.10.2] by web13106.mail.yahoo.com via HTTP; Tue, 02 Jul 2002 14:16:35 BST Date: Tue, 2 Jul 2002 14:16:35 +0100 (BST) From: =?iso-8859-1?q?jaganbabu=20rajamanickam?= Subject: RE: regarding ipv6 - ipv4 router configuration To: Vikram Shekhar , ipng@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: <004501c22187$a8795260$2bd5fe87@VIKRAM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, If we have just ipv6 address configured at the router R1 interface (IF1), then if i need to have a BGP peering sesssion between IPV6 router and an IPV4 router, then how the IPV4 socket will get connected to the IPV6 router (R1), because in the case of IPV4 router, while creating the socket we need to give the negibouring ip address(only IPV4 address), since my neighboring interface IP address is of IPV6 address it won't be possible for me to create an socket from IPV4 router to the IPV6 router. so my utlimate question is that it necessery to have an IPV4 address at the interface IF1 (IPV4 to IPV6 translated address). Thanx, Jags --- Vikram Shekhar wrote: > The interface for the router R1 will still be with > the ipv6 addressing > since, ipv6 also supports ipv4. > > Whenever it receives a packet of type ipv4, it > should be encapsulated > into ipv6 at the IF1. > To transmit a packet out for ipv4, the ipv6 packet > from IF1 will again be > transmitted > as an ipv4 packed instead of ipv6. > > The ipv6 provides compatibility between the other > version, and hence should > not pose any conflict. > > Vikram Shekhar > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of > jaganbabu rajamanickam > Sent: Tuesday, July 02, 2002 10:37 AM > To: ipng@sunroof.eng.sun.com > Subject: regarding ipv6 - ipv4 router configuration > > Hi, > I have a basic question on configuring IPV6 router > with IPV4 peer. > > +--------+ +--------+ > | | | | > | |IF1 | | > | R1 |<----------->| R2 | > | | IF2 | | > +--------+ +--------+ > > > If R1 is router which supports both IPV6 and IPV4 > stack. > If R2 is simple IPV4 router. > > so in the above case, should the interface > address > at R1 (IF1) be of IPV4 address, since it is > connecting > to another router "R2" which is an IPV4 router. > > Thanx, > Jags > > ________________________________________________________________________ > Want to sell your car? advertise on Yahoo Autos > Classifieds. It's Free!! > visit http://in.autos.yahoo.com > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 > -------------------------------------------------------------------- ________________________________________________________________________ Want to sell your car? advertise on Yahoo Autos Classifieds. It's Free!! visit http://in.autos.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 2 06:16:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62DGak7023249; Tue, 2 Jul 2002 06:16:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62DGaeZ023247; Tue, 2 Jul 2002 06:16:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62DGVk7023233 for ; Tue, 2 Jul 2002 06:16:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29349 for ; Tue, 2 Jul 2002 06:16:37 -0700 (PDT) Received: from web13106.mail.yahoo.com (web13106.mail.yahoo.com [216.136.174.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA03869 for ; Tue, 2 Jul 2002 07:16:36 -0600 (MDT) Message-ID: <20020702131635.12137.qmail@web13106.mail.yahoo.com> Received: from [198.62.10.2] by web13106.mail.yahoo.com via HTTP; Tue, 02 Jul 2002 14:16:35 BST Date: Tue, 2 Jul 2002 14:16:35 +0100 (BST) From: =?iso-8859-1?q?jaganbabu=20rajamanickam?= Subject: RE: regarding ipv6 - ipv4 router configuration To: Vikram Shekhar , ipng@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: <004501c22187$a8795260$2bd5fe87@VIKRAM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, If we have just ipv6 address configured at the router R1 interface (IF1), then if i need to have a BGP peering sesssion between IPV6 router and an IPV4 router, then how the IPV4 socket will get connected to the IPV6 router (R1), because in the case of IPV4 router, while creating the socket we need to give the negibouring ip address(only IPV4 address), since my neighboring interface IP address is of IPV6 address it won't be possible for me to create an socket from IPV4 router to the IPV6 router. so my utlimate question is that it necessery to have an IPV4 address at the interface IF1 (IPV4 to IPV6 translated address). Thanx, Jags --- Vikram Shekhar wrote: > The interface for the router R1 will still be with > the ipv6 addressing > since, ipv6 also supports ipv4. > > Whenever it receives a packet of type ipv4, it > should be encapsulated > into ipv6 at the IF1. > To transmit a packet out for ipv4, the ipv6 packet > from IF1 will again be > transmitted > as an ipv4 packed instead of ipv6. > > The ipv6 provides compatibility between the other > version, and hence should > not pose any conflict. > > Vikram Shekhar > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of > jaganbabu rajamanickam > Sent: Tuesday, July 02, 2002 10:37 AM > To: ipng@sunroof.eng.sun.com > Subject: regarding ipv6 - ipv4 router configuration > > Hi, > I have a basic question on configuring IPV6 router > with IPV4 peer. > > +--------+ +--------+ > | | | | > | |IF1 | | > | R1 |<----------->| R2 | > | | IF2 | | > +--------+ +--------+ > > > If R1 is router which supports both IPV6 and IPV4 > stack. > If R2 is simple IPV4 router. > > so in the above case, should the interface > address > at R1 (IF1) be of IPV4 address, since it is > connecting > to another router "R2" which is an IPV4 router. > > Thanx, > Jags > > ________________________________________________________________________ > Want to sell your car? advertise on Yahoo Autos > Classifieds. It's Free!! > visit http://in.autos.yahoo.com > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 > -------------------------------------------------------------------- ________________________________________________________________________ Want to sell your car? advertise on Yahoo Autos Classifieds. It's Free!! visit http://in.autos.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 2 09:45:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62GjCk7023968; Tue, 2 Jul 2002 09:45:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62GjCn3023967; Tue, 2 Jul 2002 09:45:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62Gj8k7023960 for ; Tue, 2 Jul 2002 09:45:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24293 for ; Tue, 2 Jul 2002 09:45:15 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14228 for ; Tue, 2 Jul 2002 10:45:14 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g62GiMA37017; Wed, 3 Jul 2002 01:44:22 +0900 (JST) Date: Wed, 03 Jul 2002 01:42:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Keith Moore Cc: Francis Dupont , "Richard Draves" , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-Reply-To: <200207011751.g61Hpb225922@astro.cs.utk.edu> References: <200207011751.g61Hpb225922@astro.cs.utk.edu> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 22 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 01 Jul 2002 13:51:37 -0400, >>>>> Keith Moore said: >> > - limit in6_matchlen() to 64 for address selection. >> >> I agree that full-128bit comparison does usually not make much sense, >> but I'm not sure if the assumption of the fixed prefix length is a >> good idea... > I'm reasonably certain it's a bad idea - I fully expect that some sites > will need to have prefixes > 64 bits, either because the ISP didn't > follow the rules or they really need to subnet something hanging > off a /64. Though I really hope the former will never be the case, I'm basically on the same side as yours in the sense that assuming a fixed prefix length for all addresses is a bad idea. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 2 09:45:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62GjNk7023978; Tue, 2 Jul 2002 09:45:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62GjNbU023977; Tue, 2 Jul 2002 09:45:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62GjIk7023970 for ; Tue, 2 Jul 2002 09:45:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13202 for ; Tue, 2 Jul 2002 09:45:24 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00041 for ; Tue, 2 Jul 2002 09:45:24 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g62GhrA37014; Wed, 3 Jul 2002 01:43:54 +0900 (JST) Date: Wed, 03 Jul 2002 01:34:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Alain Durand Cc: Francis Dupont , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-Reply-To: <02D145FF-8D0E-11D6-B7BB-00039376A6AA@sun.com> References: <02D145FF-8D0E-11D6-B7BB-00039376A6AA@sun.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 01 Jul 2002 09:17:16 -0700, >>>>> Alain Durand said: >>> => again this is inadequate and stresses the previous issue. >>> This MUST must not move to the standard track part. >>> Note my environment suggestion works well for this case because >>> daemons (which want the public address) run with another userID >>> than applications of physical users (which want a temporary address). >>> We really need soemthing tunable from the outside, not a new switch >>> in every applications... >> >> I tend to agree. I previously said a per-node switch is better for >> privacy purposes (though some disagreed), but more accurately, a >> per-user switch is better. > The same user may want to use privacy when browsing > the wild wild web and application robustness when > accessing data on a file server. > I like Francis suggestion of an environment switch. But in my understanding the environment switch can be inherited to "descendents" (e.g. child processes). (If the understanding of the switch on this point is the same between us) so the switch has basically the same defect as the per-node switch; we cannot perfectly prevent a user from creating an "environment" from which a user's application may suffer. I don't get why you like the environment switch while you (probably) dislike the per-node switch... Anyway...I still believe if I were a privacy conscious user (who needs a RFC3041-like privacy mechanism) I would rather choose the possible pitfalls than the leakage of privacy. However, I know some other guys disagree on this view and I actually do not have a strong opinion on the switch, I'll not insist on this point. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 2 10:30:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62HUvk7024097; Tue, 2 Jul 2002 10:30:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62HUvea024096; Tue, 2 Jul 2002 10:30:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62HUsk7024089 for ; Tue, 2 Jul 2002 10:30:54 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08853 for ; Tue, 2 Jul 2002 10:30:59 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22388 for ; Tue, 2 Jul 2002 10:30:58 -0700 (PDT) Received: (from jj@localhost) by alicia.nttmcl.com (8.10.1/8.10.1) id g62HUOK23643; Tue, 2 Jul 2002 10:30:24 -0700 (PDT) Date: Tue, 2 Jul 2002 10:30:24 -0700 From: Shannon -jj Behrens To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" , Alain Durand , Francis Dupont , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt Message-ID: <20020702103024.B22661@alicia.nttmcl.com> References: <02D145FF-8D0E-11D6-B7BB-00039376A6AA@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Wed, Jul 03, 2002 at 01:34:03AM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >>>>> Alain Durand said: > >>> => again this is inadequate and stresses the previous issue. > >>> This MUST must not move to the standard track part. > >>> Note my environment suggestion works well for this case because > >>> daemons (which want the public address) run with another userID > >>> than applications of physical users (which want a temporary address). > >>> We really need soemthing tunable from the outside, not a new switch > >>> in every applications... > >> > >> I tend to agree. I previously said a per-node switch is better for > >> privacy purposes (though some disagreed), but more accurately, a > >> per-user switch is better. > > > The same user may want to use privacy when browsing > > the wild wild web and application robustness when > > accessing data on a file server. > > I like Francis suggestion of an environment switch. > > But in my understanding the environment switch can be inherited to > "descendents" (e.g. child processes). (If the understanding of the > switch on this point is the same between us) so the switch has > basically the same defect as the per-node switch; we cannot perfectly > prevent a user from creating an "environment" from which a user's > application may suffer. I don't get why you like the environment > switch while you (probably) dislike the per-node switch... A per-node switch probably doesn't make sense because it would have an affect on both the "server-like" applications as well as the "client-like" applications. However, an environmental switch could make more sense because each user could throw that environmental setting into their .shellrc file and be assured that no application that they launch from that shell would ever use a non-temporary address by default. I.e., the inheritance is a feature. > Anyway...I still believe if I were a privacy conscious user (who needs > a RFC3041-like privacy mechanism) I would rather choose the possible > pitfalls than the leakage of privacy. However, I know some other guys > disagree on this view and I actually do not have a strong opinion on > the switch, I'll not insist on this point. Similarly, I'm just clarifying the argument, without necessarily trying to express an opinion. Best Regards, -jj -- Real programmers don't draw flowcharts. Flowcharts are, after all, the illiterate's form of documentation. Cavemen drew flowcharts; look how much good it did them. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 2 10:37:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62Hb5k7024130; Tue, 2 Jul 2002 10:37:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62Hb5sI024129; Tue, 2 Jul 2002 10:37:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62Hb1k7024122 for ; Tue, 2 Jul 2002 10:37:01 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10552 for ; Tue, 2 Jul 2002 10:37:06 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11726 for ; Tue, 2 Jul 2002 11:37:05 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 631E14B24; Wed, 3 Jul 2002 02:37:01 +0900 (JST) To: Shannon -jj Behrens Cc: ipng@sunroof.eng.sun.com In-reply-to: jj's message of Tue, 02 Jul 2002 10:30:24 MST. <20020702103024.B22661@alicia.nttmcl.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt From: itojun@iijlab.net Date: Wed, 03 Jul 2002 02:37:01 +0900 Message-Id: <20020702173701.631E14B24@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >A per-node switch probably doesn't make sense because it would have an affect >on both the "server-like" applications as well as the "client-like" >applications. However, an environmental switch could make more sense because >each user could throw that environmental setting into their .shellrc file >and be assured that no application that they launch from that shell would >ever use a non-temporary address by default. I.e., the inheritance is a >feature. maybe a bit off-topic of the discussion, but i think this thread is assuming too much about underlying operating system - that they are unix-ish design. default-addr-select is a protocol document, as far as i understand. 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 Jul 2 14:34:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62LYDk7024720; Tue, 2 Jul 2002 14:34:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62LYDrp024719; Tue, 2 Jul 2002 14:34:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62LYAk7024712 for ; Tue, 2 Jul 2002 14:34:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19487 for ; Tue, 2 Jul 2002 14:34:16 -0700 (PDT) Received: from Thor.Adtech-Inc.COM (Thor.Adtech-Inc.COM [63.165.80.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA10692 for ; Tue, 2 Jul 2002 15:34:15 -0600 (MDT) Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.12.4/8.12.4) with ESMTP id g62LY889024161 for ; Tue, 2 Jul 2002 11:34:09 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Jul 2002 11:40:46 -1000 Message-ID: <8AC36D3167EED41184C800508BD9540502CA97F1@apollo.adtech-inc.com> From: "Chang, Ellen" To: "'ipng@sunroof.eng.sun.com'" Subject: Need clarification on some of the IPv6 requirements Date: Tue, 2 Jul 2002 11:40:45 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello: I have few questions related to IPv6 specs. Can anyone please help me to clarify them? 1. If a IPv6 node A send an Echo Request with destination option or hop-by-hop option to IPv6 node B, should the node B respond an Echo Reply with the options OR without the options? 2. If a IPv6 node A send a Packet with multiple same routing headers to IPv6 node C through IPv6 node B, should the node B only process the first routing header (update the dst address, routing segments left and address) before it propagate the packet to IPV6 node C, OR should the node B process all the routing headers? If the node only process one of the routing header, would it cause interoperability problem ? 3. If a IPv6 node A send an Echo Request with unrecognized options( and their highest-order two bits set to 00) to IPv6 node B, should the node B respond an Echo Reply without the unrecognized options from the Echo Request, OR should the node B respond an Echo Reply with the unrecognized options? Or are both ways acceptable? 4. If the neighbor solicitation message has the global address as its source address, does it consider to be an valid message ? 5. If a NPv6 node A send an Router solicitation message to IPv6 node B, should the node B respond an Router advertisement with invoking router solicitation message's source address as it's destination address, OR the node B allow to send Router advertisement with multicast destination address. Thank you Ellen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 2 15:35:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62MZIk7024843; Tue, 2 Jul 2002 15:35:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g62MZIG9024842; Tue, 2 Jul 2002 15:35:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g62MZFk7024835 for ; Tue, 2 Jul 2002 15:35:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05038 for ; Tue, 2 Jul 2002 15:35:21 -0700 (PDT) Received: from relay.mail.bg (host.cyberbg.com [212.91.166.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA07190 for ; Tue, 2 Jul 2002 16:35:19 -0600 (MDT) Received: (qmail 13667 invoked from network); 2 Jul 2002 22:34:44 -0000 Received: from web1.mail.bg (212.91.166.100) by host.cyberbg.com with QMQP; 2 Jul 2002 22:34:34 -0000 To: IPng Discussion Subscribers Subject: Connectivity cognition belonging to addressing Message-ID: <1025649316.3d222aa47c537@mail.bg> Date: Wed, 03 Jul 2002 01:35:16 +0300 (EEST) From: Toni Stoev MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit User-Agent: mail.bG web interface 2.22 X-Originating-IP: 193.200.15.129 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How do you do, Pekka. Thank you for minding my proposal. I am arguing: Unique identification by connectivity cognition is bound to addressing in the Domain Name System. Elucidating: Reachability through connectivity-knowing nodes is usable on initiation of connections. Hence the term I propose: "inicast". Quoting: > On Tue, 2 Jul 2002, Toni Stoev wrote: > > I propose another grand-next generation addressing approach: > > – A certain type of addresses, inicast, to represent > connectivity-address > > cognition: > > Certain nodes are elected to be initial nodes. > > Nodes use to mutually know connectivity addresses with other nodes > > (acquaintances). Every node's such mutually known nodes are identified > > > uniquely to that node. > > A node's connectivity-address cognition address (definition) from an > > initial node is a sequence of mutual-cognition node identifications > > representing a cognition path from the initial node to the node having > > > the address. > > Consequences: > > Nodes are uniquely identified by connectivity cognition and are > reachable > > through connectivity-knowing nodes. > > This does not belong to addressing. > > See http://www.ietf.org/html.charters/manet-charter.html for more ideas. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > The following information is appended by dispatch service provider for this message. __________________________________ 12MB-POP3-WAP-SMS---TOBA-E-mail.bG ---------------------------------- " Ako uckame u Bue agpec B mail.bg ugeme myk: http://www.mail.bg/new/ " -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 2 18:16:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g631GSk7024967; Tue, 2 Jul 2002 18:16:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g631GS8U024966; Tue, 2 Jul 2002 18:16:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g631GOk7024959 for ; Tue, 2 Jul 2002 18:16:24 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05523 for ; Tue, 2 Jul 2002 18:16:11 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09507 for ; Tue, 2 Jul 2002 18:16:05 -0700 (PDT) Received: from localhost ([2001:3e8:302:f006:d41e:e203:a59a:43e2]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g631FwA40258; Wed, 3 Jul 2002 10:15:58 +0900 (JST) Date: Wed, 03 Jul 2002 10:16:02 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: itojun@iijlab.net Cc: Shannon -jj Behrens , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-Reply-To: <20020702173701.631E14B24@coconut.itojun.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <20020702173701.631E14B24@coconut.itojun.org> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 03 Jul 2002 02:37:01 +0900, >>>>> itojun@iijlab.net said: >> A per-node switch probably doesn't make sense because it would have an affect >> on both the "server-like" applications as well as the "client-like" >> applications. However, an environmental switch could make more sense because >> each user could throw that environmental setting into their .shellrc file >> and be assured that no application that they launch from that shell would >> ever use a non-temporary address by default. I.e., the inheritance is a >> feature. > maybe a bit off-topic of the discussion, but i think this thread > is assuming too much about underlying operating system - that > they are unix-ish design. That's because I wrote "*e.g.* child processes", but perhaps I was not clear enough to distinguish particular implementation from general issues. Thanks for the clarification (though I think examples from the real world help the discussion if we are clear on the limitation). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 2 20:30:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g633UYk7025066; Tue, 2 Jul 2002 20:30:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g633UYqo025065; Tue, 2 Jul 2002 20:30:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g633UVk7025058 for ; Tue, 2 Jul 2002 20:30:31 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA20729 for ; Tue, 2 Jul 2002 20:30:38 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA20477 for ; Tue, 2 Jul 2002 21:30:28 -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 g633TpI26121; Wed, 3 Jul 2002 10:29: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 g633T1f02689; Wed, 3 Jul 2002 10:29:04 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: Shannon -jj Behrens , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-Reply-To: <20020702173701.631E14B24@coconut.itojun.org> References: <20020702173701.631E14B24@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jul 2002 10:29:01 +0700 Message-ID: <2687.1025666941@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 03 Jul 2002 02:37:01 +0900 From: itojun@iijlab.net Message-ID: <20020702173701.631E14B24@coconut.itojun.org> | maybe a bit off-topic of the discussion, but i think this thread | is assuming too much about underlying operating system - that | they are unix-ish design. default-addr-select is a protocol document, | as far as i understand. Not off topic at all, it was a point that needed to be made. The doc says that applications get to override the default, that's all that is needed. The mechanism by which the application decides it should make that decision (and whether it occurs in the app code itself, or in some provided library routine) are way beyond the scope 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 Jul 2 20:50:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g633oqk7025125; Tue, 2 Jul 2002 20:50:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g633oqA8025124; Tue, 2 Jul 2002 20:50:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g633onk7025117 for ; Tue, 2 Jul 2002 20:50:49 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA23988 for ; Tue, 2 Jul 2002 20:50:56 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18738 for ; Tue, 2 Jul 2002 21:50:43 -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 g633nrI28010; Wed, 3 Jul 2002 10:49:54 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g633nEf02720; Wed, 3 Jul 2002 10:49:19 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Chang, Ellen" cc: "'ipng@sunroof.eng.sun.com'" Subject: Re: Need clarification on some of the IPv6 requirements In-Reply-To: <8AC36D3167EED41184C800508BD9540502CA97F1@apollo.adtech-inc.com> References: <8AC36D3167EED41184C800508BD9540502CA97F1@apollo.adtech-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jul 2002 10:49:14 +0700 Message-ID: <2718.1025668154@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 2 Jul 2002 11:40:45 -1000 From: "Chang, Ellen" Message-ID: <8AC36D3167EED41184C800508BD9540502CA97F1@apollo.adtech-inc.com> | I have few questions related to IPv6 specs. Can anyone please help me to | clarify them? These are just my opinions, but by offering them, if they're wrong, someone who knows better will contradict, and probably even supply references to the specs... | 1. If a IPv6 node A send an Echo Request with destination option or | hop-by-hop option to IPv6 node B, should the node B respond an Echo Reply | with the options OR without the options? I think that very much depends upon the options. Options get processed by the IP stack, regardless of the upper protocol selected (including the special case of echo). Whatever they indicate should be done, should be done - if that means sending something back in the next packet that goes back to the source, then that's what would happen. Certainly there's no rule that says that options have to be sent back as they were received, in any packet, including echo reply - for some options that might exist, that would be incorrect. | 2. If a IPv6 node A send a Packet with multiple same routing headers to | IPv6 node C through IPv6 node B, should the node B only process the first | routing header (update the dst address, routing segments left and address) | before it propagate the packet to IPV6 node C, OR should the node B process | all the routing headers? If the node only process one of the routing | header, would it cause interoperability problem ? Just the first. As soon as a node receives a packet (by which I mean, the dest address in the IPv6 header is the node's address, rather than just "it appeared at my interface") and finds a routing header that isn't exhausted, it does the routing header address swap, and forwards the packet (or decides that forwarding packets isn't its function in life, and discards the packet, of course). It never looks beyond that routing header, so would never see a later one. As I understand it, including multiple routing headers is still something of a "who knows what that might be useful for or what it means" area - that is, nodes would be strongly advised not to do that. My take on what to do if a node receives a packet with an exhausted routing header, is just to go on to look at later headers (that I think is clear). If it then finds another routing header, which isn't exhausted, it would just process it as normal (that is, the already exhausted routing header it passed over wouldn't alter things at all - that part is my opinion). The effect would be that two consecutive routing headers would be just the same as one larger one that is the concatenation of the two (which might be useful occasionally if one is needed that is bigger than is possible, which isn't very likely one hopes). A more likely reason would be when one desires to include options to be processed at some routers along a path. An options header between routing headers would get processed only by routers after the first routing header is exhausted (but then by all after that). It isn't beyond the bounds of possibility that someone might create an option which says "remove this option and all before it in this header, then skip any other options in this header". With an option like that more selective processing of other options could be managed. (The "remove" could be done by overwriting with NOOP of course). | 3. If a IPv6 node A send an Echo Request with unrecognized options( and | their highest-order two bits set to 00) to IPv6 node B, should the node B | respond an Echo Reply without the unrecognized options from the Echo | Request, OR should the node B respond an Echo Reply with the unrecognized | options? Or are both ways acceptable? Without I'd say. | 4. If the neighbor solicitation message has the global address as its source | address, does it consider to be an valid message ? No. NS packets come from LL addresses. Anything from any other kind of address is an error, and should be ignored. | 5. If a NPv6 node A send an Router solicitation message to IPv6 node B, | should the node B respond an Router advertisement with invoking router | solicitation message's source address as it's destination address, OR the | node B allow to send Router advertisement with multicast destination | address. The multicast address. And I think it isn't "allowed" but must. That's what prevents RS/R Astorms when a labfull of nodes all boot. They all delay their RS by a random interval. One of them (naturally) has the shortest random interval. That one sends its RS (assuming chance hasn't caused a RA to appear in the meantime). Routers that receive it all send RA's to the multicast addr. All the other nodes receive those RAs and so never send an RS. 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 Jul 2 21:51:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g634pJk7025169; Tue, 2 Jul 2002 21:51:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g634pJkQ025168; Tue, 2 Jul 2002 21:51:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g634pFk7025161 for ; Tue, 2 Jul 2002 21:51:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10148 for ; Tue, 2 Jul 2002 21:51:21 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11556 for ; Tue, 2 Jul 2002 22:51:20 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g634hc201562; Wed, 3 Jul 2002 00:43:38 -0400 (EDT) Message-Id: <200207030443.g634hc201562@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: itojun@iijlab.net, Shannon -jj Behrens , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Wed, 03 Jul 2002 10:29:01 +0700.") <2687.1025666941@munnari.OZ.AU> Date: Wed, 03 Jul 2002 00:43:38 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The doc says that applications get to override the default, that's all > that is needed. The mechanism by which the application decides it should > make that decision (and whether it occurs in the app code itself, or in > some provided library routine) are way beyond the scope here. > I don't think this is way beyond the scope here at all - this is fundamentally an API issue, and it seems like it would actually be useful and appropriate to talk about it in those terms. Granted there are multiple APIs in use. But the point is that either having different implementations of the same API do the address selection/ordering in different ways, or having new implementations of an API do it differently than old versions, will degrade interoperability. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 3 02:03:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6393Vk7025646; Wed, 3 Jul 2002 02:03:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6393VPN025645; Wed, 3 Jul 2002 02:03:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6393Sk7025638 for ; Wed, 3 Jul 2002 02:03:28 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23448 for ; Wed, 3 Jul 2002 02:03:34 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01498 for ; Wed, 3 Jul 2002 02:03:07 -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 g6392MI01607; Wed, 3 Jul 2002 16:02:24 +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 g63905f03686; Wed, 3 Jul 2002 16:00:05 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Keith Moore cc: itojun@iijlab.net, Shannon -jj Behrens , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-Reply-To: <200207030443.g634hc201562@astro.cs.utk.edu> References: <200207030443.g634hc201562@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jul 2002 16:00:05 +0700 Message-ID: <3684.1025686805@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 03 Jul 2002 00:43:38 -0400 From: Keith Moore Message-ID: <200207030443.g634hc201562@astro.cs.utk.edu> | I don't think this is way beyond the scope here at all - this is | fundamentally an API issue, Which makes it beyond the scope of the address selection doc. If you want to suggest that something about it be added to one of the API docs, then go ahead (and good luck). 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 Jul 3 03:28:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63ASsk7025775; Wed, 3 Jul 2002 03:28:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63ASsOT025774; Wed, 3 Jul 2002 03:28:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63ASnk7025767 for ; Wed, 3 Jul 2002 03:28:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04236 for ; Wed, 3 Jul 2002 03:28:54 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA08438 for ; Wed, 3 Jul 2002 04:28:53 -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 GAA03304; Wed, 3 Jul 2002 06:28:04 -0400 (EDT) Message-Id: <200207031028.GAA03304@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-addr-arch-v3-08.txt Date: Wed, 03 Jul 2002 06:28:03 -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 Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-08.txt Pages : 26 Date : 02-Jul-02 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-v3-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020702151015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v3-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702151015.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 Jul 3 03:29:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63AT1k7025785; Wed, 3 Jul 2002 03:29:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63AT193025784; Wed, 3 Jul 2002 03:29:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63AStk7025777 for ; Wed, 3 Jul 2002 03:28:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA24529 for ; Wed, 3 Jul 2002 03:28:59 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA08453 for ; Wed, 3 Jul 2002 04:28:59 -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 GAA03351; Wed, 3 Jul 2002 06:28:09 -0400 (EDT) Message-Id: <200207031028.GAA03351@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-00.txt Date: Wed, 03 Jul 2002 06:28:09 -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-00.txt Pages : 28 Date : 02-Jul-02 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-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-rfc2012-update-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-rfc2012-update-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: <20020702151029.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2012-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2012-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702151029.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 Jul 3 03:28:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63ASmk7025765; Wed, 3 Jul 2002 03:28:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63ASm5U025764; Wed, 3 Jul 2002 03:28:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63ASik7025757 for ; Wed, 3 Jul 2002 03:28:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04224 for ; Wed, 3 Jul 2002 03:28:49 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA08408 for ; Wed, 3 Jul 2002 04:28: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 GAA03289; Wed, 3 Jul 2002 06:27:59 -0400 (EDT) Message-Id: <200207031027.GAA03289@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-00.txt Date: Wed, 03 Jul 2002 06:27:58 -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 Filename : draft-ietf-ipv6-rfc2096-update-00.txt Pages : 30 Date : 02-Jul-02 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-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-rfc2096-update-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-rfc2096-update-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: <20020702151005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2096-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2096-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702151005.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 Jul 3 05:37:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63Cbak7026691; Wed, 3 Jul 2002 05:37:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63CbapR026690; Wed, 3 Jul 2002 05:37:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63CbXk7026683 for ; Wed, 3 Jul 2002 05:37:33 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA27880 for ; Wed, 3 Jul 2002 05:37:39 -0700 (PDT) From: lanapoli@us.ibm.com Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07695 for ; Wed, 3 Jul 2002 05:37:38 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g63CbbRY149210 for ; Wed, 3 Jul 2002 08:37:37 -0400 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g63CbbJ133530 for ; Wed, 3 Jul 2002 08:37:37 -0400 Importance: Normal Sensitivity: Subject: Re: Need clarification on some of the IPv6 requirements To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 3 Jul 2002 08:33:00 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M13TT_06122002 Pre-release 2|June 12, 2002) at 07/03/2002 08:37:52 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE178DFD7174E8f9e8a93df938690918c0ABBE178DFD7174E" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=0ABBE178DFD7174E8f9e8a93df938690918c0ABBE178DFD7174E Content-type: text/plain; charset=US-ASCII | 4. If the neighbor solicitation message has the global address as its source | address, does it consider to be an valid message ? | No. NS packets come from LL addresses. Anything from any other kind of | address is an error, and should be ignored. Why do you say this? In RFC 2461 in the Sending Neighbor Solicitation section it states: If the source address of the packet prompting the solicitation is the same as one of the addresses assigned to the outgoing interface, that address SHOULD be placed in the IP Source Address of the outgoing solicitation. So if the packet prompting the solicitation had its global address as the source address, and the global address was an address on the outbound interface, I would expect the solicitation to have the global address as its source address. Right? Lori --0__=0ABBE178DFD7174E8f9e8a93df938690918c0ABBE178DFD7174E Content-type: text/html; charset=US-ASCII Content-Disposition: inline
| 4. If the neighbor solicitation message has the global address as its source
|    address, does it consider to be an valid message ?
    | No.  NS packets come from LL addresses.  Anything from any other kind of
    | address is an error, and should be ignored.

    Why do you say this? In RFC 2461 in the Sending Neighbor Solicitation section it states:
        If the source address of the packet prompting the solicitation is the
        same as one of the addresses assigned to the outgoing interface, that
        address SHOULD be placed in the IP Source Address of the outgoing
        solicitation.
    So if the packet prompting the solicitation had its global address as the source address, and the global address was an address on the outbound interface, I would expect the solicitation to have the global address as its source address. Right?

    Lori
    --0__=0ABBE178DFD7174E8f9e8a93df938690918c0ABBE178DFD7174E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 3 06:19:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63DJlk7026741; Wed, 3 Jul 2002 06:19:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63DJlNp026740; Wed, 3 Jul 2002 06:19:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63DJik7026733 for ; Wed, 3 Jul 2002 06:19:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08175 for ; Wed, 3 Jul 2002 06:19:50 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28916 for ; Wed, 3 Jul 2002 06:19:49 -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 g63DJ7I21665; Wed, 3 Jul 2002 20:19:08 +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 g63DHJf04605; Wed, 3 Jul 2002 20:17:20 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: lanapoli@us.ibm.com cc: ipng@sunroof.eng.sun.com Subject: Re: Need clarification on some of the IPv6 requirements In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jul 2002 20:17:19 +0700 Message-ID: <4603.1025702239@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 3 Jul 2002 08:33:00 -0400 From: lanapoli@us.ibm.com Message-ID: | Why do you say this? Because it gets someone who is able & willing to read the spec to correct me ... | So if the packet prompting the solicitation had its global address as the | source address, and the global address was an address on the outbound | interface, I would expect the solicitation to have the global address as | its source address. Right? Yes, that sounds right.... 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 Jul 3 07:04:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63E4Uk7026963; Wed, 3 Jul 2002 07:04:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63E4U3l026962; Wed, 3 Jul 2002 07:04:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63E4Qk7026955 for ; Wed, 3 Jul 2002 07:04:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17910 for ; Wed, 3 Jul 2002 07:04:25 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02722 for ; Wed, 3 Jul 2002 08:04:25 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g63Dui200727; Wed, 3 Jul 2002 09:56:44 -0400 (EDT) Message-Id: <200207031356.g63Dui200727@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , itojun@iijlab.net, Shannon -jj Behrens , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Wed, 03 Jul 2002 16:00:05 +0700.") <3684.1025686805@munnari.OZ.AU> Date: Wed, 03 Jul 2002 09:56:44 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | I don't think this is way beyond the scope here at all - this is > | fundamentally an API issue, > > Which makes it beyond the scope of the address selection doc. The *entire* address selection doc is about API issues. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 3 10:24:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63HOik7027563; Wed, 3 Jul 2002 10:24:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g63HOhuc027562; Wed, 3 Jul 2002 10:24:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g63HOek7027555 for ; Wed, 3 Jul 2002 10:24:40 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02828 for ; Wed, 3 Jul 2002 10:24:45 -0700 (PDT) Received: from Thor.Adtech-Inc.COM (Thor.Adtech-Inc.COM [63.165.80.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19929 for ; Wed, 3 Jul 2002 11:24:44 -0600 (MDT) Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.12.4/8.12.4) with ESMTP id g63HNu89029505; Wed, 3 Jul 2002 07:24:37 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 07:30:34 -1000 Message-ID: <8AC36D3167EED41184C800508BD9540502CA97F9@apollo.adtech-inc.com> From: "Chang, Ellen" To: "'Robert Elz'" , "'lanapoli@us.ibm.com'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: Need clarification on some of the IPv6 requirements Date: Wed, 3 Jul 2002 07:30:33 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Robert Elz [mailto:kre@munnari.OZ.AU] Sent: Tuesday, July 02, 2002 5:49 PM To: Chang, Ellen Cc: 'ipng@sunroof.eng.sun.com' Subject: Re: Need clarification on some of the IPv6 requirements | 3. If a IPv6 node A send an Echo Request with unrecognized options( and | their highest-order two bits set to 00) to IPv6 node B, should the node B | respond an Echo Reply without the unrecognized options from the Echo | Request, OR should the node B respond an Echo Reply with the unrecognized | options? Or are both ways acceptable? Without I'd say. ######## 4.2 Options The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type: 00 - skip over this option and continue processing the header. Does this requirement mean the node B should remove the option and respond with an Echo Reply to node A? or should it not remove the option from its response?. In my opinion, the term Skip means that node B should not process or remove the option. So node B should really send back a response with the option unchanged and intact. However, I have seen different responses from 2 different routers. one of them removes the option, while the other does not, and I am not sure which one is behaving as it should as per this requirement ########## | 5. If a IPv6 node A sends an Router solicitation message to IPv6 node B, | should the node B respond to node A with an Router advertisement with invoking router | solicitation message's source address as its destination address, OR should the | node B be allowed to respond back with Router advertisement with multicast destination | address. The multicast address. And I think it isn't "allowed" but must. That's what prevents RS/R Astorms when a labfull of nodes all boot. They all delay their RS by a random interval. One of them (naturally) has the shortest random interval. That one sends its RS (assuming chance hasn't caused a RA to appear in the meantime). Routers that receive it all send RA's to the multicast addr. All the other nodes receive those RAs and so never send an RS. ######## 4.2. Router Advertisement Message Format Routers send out Router Advertisement message periodically, or in response to a Router Solicitation. Source Address MUST be the link-local address assigned to the interface from which this message is sent. Destination Address Typically the Source Address of an invoking Router Solicitation or the all-nodes multicast address. There are two possibilities for the destination address as indicated in the spec, so if what you say is correct as stated in your email, then under what circumstances would router B be using the Source Address of an invoking Router Solicitation? ######## Ellen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 3 23:16:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g646Ggk7029346; Wed, 3 Jul 2002 23:16:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g646GgS2029345; Wed, 3 Jul 2002 23:16:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g646Gdk7029338 for ; Wed, 3 Jul 2002 23:16:39 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03351 for ; Wed, 3 Jul 2002 23:16:46 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05818 for ; Wed, 3 Jul 2002 23:16:45 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g646HEi20145 for ; Thu, 4 Jul 2002 09:17:15 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Jul 2002 09:16:43 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 09:17:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Updated Node Requirements draft Date: Thu, 4 Jul 2002 09:16:43 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65619@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need clarification on some of the IPv6 requirements Thread-Index: AcIiwBdzqCzcjyDATYmohNgKA5YsngAYiVyw To: X-OriginalArrivalTime: 04 Jul 2002 06:17:09.0451 (UTC) FILETIME=[6D9AB1B0:01C22322] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g646Gdk7029339 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I made some changes to the Node Requirements draft, based on initial feedback received from the WG. Until it is announced, it can be found here: http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-01.txt Thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 4 01:20:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g648KSk7029933; Thu, 4 Jul 2002 01:20:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g648KS1d029932; Thu, 4 Jul 2002 01:20:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g648KOk7029925 for ; Thu, 4 Jul 2002 01:20:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04109 for ; Thu, 4 Jul 2002 01:20:30 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10583 for ; Thu, 4 Jul 2002 01:20:29 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g648Kxi14630 for ; Thu, 4 Jul 2002 11:20:59 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 4 Jul 2002 11:20:28 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Jul 2002 11:20:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Stateful Address Config - I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt Date: Thu, 4 Jul 2002 11:20:20 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65627@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateful Address Config - I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt Thread-Index: AcIhBLTW4ygugKsgTEmvll94QH4qyQCLrSNQ To: Cc: X-OriginalArrivalTime: 04 Jul 2002 08:20:28.0756 (UTC) FILETIME=[A7EF0940:01C22333] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g648KPk7029926 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Adam, Thanks for the text, unfortunately, I received this mail after I sent out the update. It seems that you are suggesting Stateful Address Config is conditionally mandatory, and I think that I can agree with that. John > I was hoping for something a little more specific, helping to clear up just > what an implementation needs in order to be conformant. How does something > like the following sound? > > 4.4.5 Stateful Address Autoconfiguration > > Stateful Address Autoconfiguration is conditionally mandatory. For those > IPv6 Nodes that implement a stateful configuration mechanism such as > [DHCPv6], those nodes SHOULD/MUST initiatiate stateful address > autoconfiguration upon the reciept of a Router Advertisement with the > Managed address flag set. In addition, as defined in [RFC2462], in the > absence of a router, hosts that implement a stateful configuration > mechanism such as [DHCPv6] MUST attempt to use stateful address > autoconfiguration. > > For IPv6 Nodes that do not implement the optional stateful configuration > mechanisms such as [DHCPv6], the Managed Address flag of a Router > Advertisement can be ignored. Furthermore, in the absensce of a router, > this type of node is not required to initiate stateful address > autoconfiguration as specified in [RFC2462]. > > > Adam Machalek > > > > > > > > > > kia.com> To: > , > > cc: > > 06/28/2002 05:54 Subject: RE: > Stateful Address Config - I-D > > AM > ACTION:draft-ietf-ipv6-node-requirements-00.txt > > > > > > > > > > > > > Hi Adam, > > Very good point.  I have added the following text: > > > > 4.5.5 Stateful Address Autoconfiguration > > IPv6 Stateless Address Autoconfiguration [RFC2462] defines stateless > address autoconfiguation.  However, it does state that in > the absence of > routers, hosts must perform host MUST attempt to use stateful > autoconfiguration.  There is also reference to stateful address > autoconfiguration being defined elsewhere. Additionally, DHCP [DHCP] > states that it is on option for stateful address autoconfiguation. > > From the current set of specification, it is not clear the level of > support that is needed for statefull Address Autoconfiguration. > > > -----Original Message----- > From: ext Adam Machalek [mailto:Adam_Machalek@nmss.com] > Sent: 21 June, 2002 18:52 > To: ipng@sunroof.eng.sun.com > Subject: Stateful Address Config - I-D > ACTION:draft-ietf-ipv6-node-requirements-00.txt > > > > John, > > Section 5.4 on DHCPv6 states that DHCPv6 is unconditionally optional, > which today implicitly makes Stateful Address config optional. > > However, I'd like to see some direct clarification in this > document on > Stateful Address config, probably directly after Section > 4.5.2 discussing > Stateless Address config. > > RFC2462 has some ambiguities, in particular, it states "a > managed address > configuration flag indicates whether hosts should use stateful > autoconfiguration", not SHOULD.   Later in 2462 in section 5.2 it > continues this ambiguity by never explicitly using MAY/SHOULD/MUST > anywhere. > > Still later in section RFC2462 5.5.2 Absence of Router > Advertisements, it > finally states that in the absence of a router, a host MUST > attempt to use > stateful autoconfiguration. > > And lastly, the DHCPv6 draft states "DHCP is one vehicle to perform > stateful autoconfiguration", implying that there may be others. > > So in the end, even with DHCPv6 optional, this doesn't > clarify exactly > what a host should do about Stateful Address autoconfiguration. > > Adam Machalek > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 4 04:19:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g64BJuk7000270; Thu, 4 Jul 2002 04:19:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g64BJtoS000269; Thu, 4 Jul 2002 04:19:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g64BJqk7000261 for ; Thu, 4 Jul 2002 04:19:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA02951 for ; Thu, 4 Jul 2002 04:19:58 -0700 (PDT) From: Robert.Peschi@alcatel.be Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19351 for ; Thu, 4 Jul 2002 04:19:57 -0700 (PDT) Received: from bemail01.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g64BFxE15437; Thu, 4 Jul 2002 13:15:59 +0200 Subject: Re: IPv6 MIBs - internet draft status To: Margaret Wasserman , fenner@research.att.com Cc: ipng@sunroof.eng.sun.com Date: Thu, 4 Jul 2002 13:19:34 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/04/2002 13:19:40 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret and Bill, On 05/30/02, Margaret Wasserman wrote : > The IPv6 MIB Design Team has been meeting regularly, and > we are planning to provide updates to all four of the > drafts you have mentioned by the Yokohama draft cut-off. In draft-ietf-ipngwg-rfc2011-update-00.txt, ipv6InterfaceAdminStatus and ipv6InterfaceOperStatus are questionned for their usefullness. Independently controlling the adminstatus of IPv4 and IPv6 interface on a given L2 interface looks reasonable to me. Keeping IPv4 and IPv6 interface adminstatus in MIB would allow this. Further, isn't the efficiency reason not strong enough to keep the notion of operational state of IPv6 interface ? Thanks, Kind regards, Robert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 5 02:34:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g659Y7k7002266; Fri, 5 Jul 2002 02:34:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g659Y6wS002265; Fri, 5 Jul 2002 02:34:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g659Y3k7002258 for ; Fri, 5 Jul 2002 02:34:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22811 for ; Fri, 5 Jul 2002 02:34:10 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28229 for ; Fri, 5 Jul 2002 03:33:59 -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 g659X9I10825; Fri, 5 Jul 2002 16:33: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 g659WTf12932; Fri, 5 Jul 2002 16:32:34 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Keith Moore cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-Reply-To: <200207031356.g63Dui200727@astro.cs.utk.edu> References: <200207031356.g63Dui200727@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jul 2002 16:32:29 +0700 Message-ID: <12930.1025861549@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 03 Jul 2002 09:56:44 -0400 From: Keith Moore Message-ID: <200207031356.g63Dui200727@astro.cs.utk.edu> | The *entire* address selection doc is about API issues. Which doc are you reading? Maybe we're talking about different ones. The draft-ietf-ipv6-default-addr-select-08.txt that I am looking at has nothing to do with APIs at all. Or perhaps we have a different definition of what is an API? To me, that's the method by which the application interfaces with the stack/ kernel/library/... That is, it contains function definitions, data types, and all of that stuff (just as the API docs do, with specs on data types for args for various system calls, etc). The addr-select doc I'm reading contains protocol specification - that is, if the destination address is X, and A, B C are possible source addresses, which one should be used. (And of also of course, when there are multiple destination addresses, ...) That's not API - it doesn't say a word about where in the stack all of this should be done, nor does it say anything about the mechanisms that might be used to influence the choices, where such influence is possible. 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 Jul 5 03:34:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65AYVk7002593; Fri, 5 Jul 2002 03:34:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g65AYUCs002592; Fri, 5 Jul 2002 03:34:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65AYPk7002585 for ; Fri, 5 Jul 2002 03:34:25 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05354 for ; Fri, 5 Jul 2002 03:34:31 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06717 for ; Fri, 5 Jul 2002 03:34:30 -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 GAA16986; Fri, 5 Jul 2002 06:33:40 -0400 (EDT) Message-Id: <200207051033.GAA16986@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-ipv6-anycast-analysis-01.txt Date: Fri, 05 Jul 2002 06:33:39 -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 : An analysis of IPv6 anycast Author(s) : J. Hagino, K.Ettikan Filename : draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt Pages : 11 Date : 03-Jul-02 The memo tries to identify the problems and issues in the use of IPv6 anycast [Hinden, 1998] defined as of today. The goals of the draft are (1) to understand the currently-defined IPv6 anycast better, (2) to provide guidelines for people trying to deploy anycast services, and (3) to suggest updates to IPv6 anycast protocol specification. The document was made possible by input from ipngwg DNS discovery design team. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020703131748.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703131748.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 Jul 5 03:34:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65AYuk7002610; Fri, 5 Jul 2002 03:34:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g65AYuWb002609; Fri, 5 Jul 2002 03:34:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65AYok7002602 for ; Fri, 5 Jul 2002 03:34:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13933 for ; Fri, 5 Jul 2002 03:34:56 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06927 for ; Fri, 5 Jul 2002 03:34:55 -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 GAA17052; Fri, 5 Jul 2002 06:34:05 -0400 (EDT) Message-Id: <200207051034.GAA17052@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-kitamura-ipv6-name-auto-reg-02.txt Date: Fri, 05 Jul 2002 06:34:05 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Domain Name Auto-Registration for Plugged-in IPv6 Nodes Author(s) : H. Kitamura Filename : draft-kitamura-ipv6-name-auto-reg-02.txt Pages : 21 Date : 03-Jul-02 This document describes a scheme of 'Domain Name Auto-Registration for Plugged-in IPv6 Nodes' mechanism that makes it possible to register both regular and inverse domain name information of plugged- in IPv6 nodes to DNS servers automatically. Since IPv6 addresses are too long to remember and EUI64-based addresses are too complicated to remember, there are strong requirements to use logical names that are easy to remember instead of IPv6 addresses to specify IPv6 nodes and to register domain name information of plugged-in IPv6 nodes automatically. In order to meet the requirements, a mechanism is proposed as one of the IPv6 auto-configuration (plug and play) functions. After the Address Autoconfiguration [ADDR-AUTO] has been executed, it works as a succeeding plug and play mechanism. This document clarifies problems that we meet when we apply the Dynamic Updates in the DNS [DYN-DNS] to automatic domain name information registration mechanisms. This document proposes the Domain Name Auto-Registration mechanism as a solution to these problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kitamura-ipv6-name-auto-reg-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kitamura-ipv6-name-auto-reg-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kitamura-ipv6-name-auto-reg-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020703131841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kitamura-ipv6-name-auto-reg-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-kitamura-ipv6-name-auto-reg-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703131841.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 Jul 5 03:38:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65AcJk7002776; Fri, 5 Jul 2002 03:38:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g65AcIKp002775; Fri, 5 Jul 2002 03:38:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65AcEk7002762 for ; Fri, 5 Jul 2002 03:38:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06340 for ; Fri, 5 Jul 2002 03:38:20 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25169 for ; Fri, 5 Jul 2002 04:38: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 GAA17779; Fri, 5 Jul 2002 06:37:29 -0400 (EDT) Message-Id: <200207051037.GAA17779@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2011-update-00.txt Date: Fri, 05 Jul 2002 06:37:29 -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 Internet Protocol (IP) Author(s) : S. Routhier Filename : draft-ietf-ipv6-rfc2011-update-00.txt Pages : 82 Date : 03-Jul-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-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-rfc2011-update-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-rfc2011-update-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: <20020703142312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2011-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2011-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703142312.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 Jul 5 07:13:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65EDpk7003253; Fri, 5 Jul 2002 07:13:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g65EDpZH003252; Fri, 5 Jul 2002 07:13:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65EDlk7003245 for ; Fri, 5 Jul 2002 07:13:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22426 for ; Fri, 5 Jul 2002 07:13:54 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23941 for ; Fri, 5 Jul 2002 07:13:54 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g65E8kZ04099; Fri, 5 Jul 2002 10:08:47 -0400 (EDT) Message-Id: <200207051408.g65E8kZ04099@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Fri, 05 Jul 2002 16:32:29 +0700.") <12930.1025861549@munnari.OZ.AU> Date: Fri, 05 Jul 2002 10:08:46 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The addr-select doc I'm reading contains protocol specification - that > is, if the destination address is X, and A, B C are possible source > addresses, which one should be used. (And of also of course, when there > are multiple destination addresses, ...) That's not API - it doesn't say > a word about where in the stack all of this should be done, nor does > it say anything about the mechanisms that might be used to influence > the choices, where such influence is possible. One reason I say that this is an API issue is that (at least the destination address selection stuff) is really a mechanism for encouraging or defaulting the binding of the destination address to a socket. But the application is going to need to be able to explictly choose a specific destination address in any case, so this is just a way to help the application choose the "right" answer. Another reason I say this is an API issue is that a good choice of destination address (and therefore source address) cannot be made without explicit knowledge of the application's requirements. One application wishes to maximize privacy by using temporary addresses, another wishes to maximize address stability, another needs global addresses to maximize its potential for access by/to peers. Another reason I say that this is an API issue is that we really need all platforms that currently provide the same API to implement this address selection procedure in such a way that they still provide the same API- e.g. we don't need one socket-based system doing it via a new version of gethostbyname() or whatever it is this week, and and another socket-based system trying to do it via a new version of bind(), and another one writing an explicit select_dest_address() routine. This cannot be a protocol issue except in a few specific cases, because there are very few (approaching zero) protocols that explicitly and exhaustively define the mechanisms by which addresses are advertised to potential peers. e.g. We cannot assume that all addresses in all (or even most) protocols are obtained exclusively through DNS. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 5 07:57:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65Evsk7003295; Fri, 5 Jul 2002 07:57:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g65Evsqd003294; Fri, 5 Jul 2002 07:57:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65Evok7003287 for ; Fri, 5 Jul 2002 07:57:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02714 for ; Fri, 5 Jul 2002 07:57:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14789 for ; Fri, 5 Jul 2002 08:57:57 -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 KAA28164; Fri, 5 Jul 2002 10:57:05 -0400 (EDT) Message-Id: <200207051457.KAA28164@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com, namedropper@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kitamura-ipv6-name-auto-reg-02.txt Date: Fri, 05 Jul 2002 10:57:05 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Domain Name Auto-Registration for Plugged-in IPv6 Nodes Author(s) : H. Kitamura Filename : draft-kitamura-ipv6-name-auto-reg-02.txt Pages : 21 Date : 03-Jul-02 This document describes a scheme of 'Domain Name Auto-Registration for Plugged-in IPv6 Nodes' mechanism that makes it possible to register both regular and inverse domain name information of plugged- in IPv6 nodes to DNS servers automatically. Since IPv6 addresses are too long to remember and EUI64-based addresses are too complicated to remember, there are strong requirements to use logical names that are easy to remember instead of IPv6 addresses to specify IPv6 nodes and to register domain name information of plugged-in IPv6 nodes automatically. In order to meet the requirements, a mechanism is proposed as one of the IPv6 auto-configuration (plug and play) functions. After the Address Autoconfiguration [ADDR-AUTO] has been executed, it works as a succeeding plug and play mechanism. This document clarifies problems that we meet when we apply the Dynamic Updates in the DNS [DYN-DNS] to automatic domain name information registration mechanisms. This document proposes the Domain Name Auto-Registration mechanism as a solution to these problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kitamura-ipv6-name-auto-reg-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kitamura-ipv6-name-auto-reg-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kitamura-ipv6-name-auto-reg-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020703131841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kitamura-ipv6-name-auto-reg-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-kitamura-ipv6-name-auto-reg-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703131841.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 Jul 5 15:45:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65Mjsk7003969; Fri, 5 Jul 2002 15:45:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g65MjsmC003968; Fri, 5 Jul 2002 15:45:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g65Mjpk7003961 for ; Fri, 5 Jul 2002 15:45:51 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06484 for ; Fri, 5 Jul 2002 15:45:58 -0700 (PDT) Received: from ieee.nccu.edu.tw (ieee.nccu.edu.tw [140.119.81.235]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05635 for ; Fri, 5 Jul 2002 16:45:53 -0600 (MDT) Received: from ieee.nccu.edu.tw ([140.119.81.236]) by ieee.nccu.edu.tw (8.9.3/8.9.3) with SMTP id GAA02720; Sat, 6 Jul 2002 06:41:45 +0800 (CST) Date: Sat, 6 Jul 2002 06:41:45 +0800 (CST) Message-Id: <200207052241.GAA02720@ieee.nccu.edu.tw> FROM: Geng-Sheng Kuo SUBJECT: Midori-cho, Musashino-shi, Tokyo,. X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Outlook Express 4.72.3612.1700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0052_0133E531.53E53170" Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0052_0133E531.53E53170 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The method allows dynamic optical network management and photonic signal recovery, such as regeneration and reshaping etc., to be realized adaptively. Wavelength conversion is also adaptive which reduces network cost. Multi-layer traffic engineering, which yields the dynamic cooperation of IP and photonic layers, is described to provide IP services cost-effectively. ------=_NextPart_000_0052_0133E531.53E53170 Content-Type: application/octet-stream; name="extended.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="extended.pif" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA0AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAACBWW/BxTgBksU4AZLFOAGSxTgAkv44AZKcGxKSwjgBksU4AZKAOAGS7zAH ksQ4AZItJwuSxDgBklJpY2jFOAGSAAAAAAAAAAAAAAAAAAAAAFBFAABMAQMA+R33OSCwAADVwwAA 4AAHAQsBBQwAbAAAAFgAAAAAAADgJgAAABAAAACAAAAAAAABABAAAAACAAAFAAAABQAAAAQAAAAA AAAA7YMBAAAEAABxfwIAAwAAAAAABAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA3HUAAFAA AAAA4AAA8AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAABUAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA LnRleHQAAACyawAAABAAAABsAAAABAAAAAAAAAAAAAAAAAAAIAAAYC5kYXRhAAAAOFIAAACAAAAA PAAAAHAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAO2jAAAA4AAAAHoAAACsAAAAAAAAAAAAAAAA AABAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFh5 AAA0dwAAQHcAAFJ3AABqdwAAencAAIh3AACUdwAApncAAL53AADQdwAA3ncAAOx3AAAAeAAAFHgA ADB4AABGeAAAYHgAAHZ4AACQeAAAqHgAAMJ4AADYeAAA5HgAAO54AAD6eAAADHkAABx5AAAqeQAA PHkAAEp5AAAkdwAAZnkAAHJ5AAB+eQAAinkAAJZ5AACmeQAAtnkAAMh5AADaeQAA6nkAAPx5AAAM egAAGnoAACh6AAA6egAATnoAAF56AABqegAAAAAAAB57AACoegAAxHoAAOR6AAAAewAAiHoAAEJ7 AABaewAAAAAAAIB7AAAAAAAAAAAAAAAAAAAAAAAA+R33OQAAAAABAAAAkG0AAAAAAAAAsAAAAAAA APkd9zkAAAAABAAAABABAAAAAAAAkB0BAAAAAAD5Hfc5AAAAAAMAAADwBQAAAAAAAKAeAQAlcyBG QUlMVVJFOiAoMHglMDh4KQoAAAAlcyBGQUlMVVJFOiAlcwoALmxvZwAAAAB3Mmt1cGRhdGUAAABh KwAAXAAAAEdldERldmljZVJlZ2lzdHJ5UHJvcGVydHkAAABSZWxvYWRpbmcgZHJpdmVyIGZvciAl cwoAAAAARXJyb3IgJXMgZGV2aWNlAHVubG9hZGluZwAAAGxvYWRpbmcAU2V0dXBEaUdldERldmlj ZVJlZ2lzdHJ5UHJvcGVydHkgSEFSRFdBUkVJRCA9ICVzCgAAAFNldHVwRGlHZXREZXZpY2VSZWdp c3RyeVByb3BlcnR5IERFVklDRV9ERVNDID0gJXMKAABTZXR1cERpR2V0RGV2aWNlUmVnaXN0cnlQ cm9wZXJ0eSBEUklWRVIgPSAlcwoAAABHZXRDbGFzc0RldnMoQWxsIFByZXNlbnQgRGV2aWNlcykA AABEZXZpY2UgWyVzXSBub3QgZm91bmQAAABGb3VuZCEgWyVzXQoAAAAAQ29tcGFyZSBkZXZpY2Ug SUQ6IFslc10KAAAAAFNlYXJjaGluZyBmb3IgRGV2aWNlIElEOiBbJXNdCgAARHJpdmVyIGluc3Rh bGxlZCBzdWNjZXNzZnVsbHkgZm9yIGRldmljZSAlcy4KAAAAVXBkYXRlRHJpdmVyRm9yUGx1Z0Fu ZFBsYXlEZXZpY2VzAAAAVXNpbmcgJXMKAAAAQ3VycmVudFBhdGggPSAlcwoAAABDYW5ub3QgZmlu ZCBmaWxlCgAAAFNlYXJjaGluZyBmb3IgSU5GIGluICVzCgAAAABJbmZQYXRoID0gJXMKAAAAR2V0 RGVmYXVsdEluZk5hbWUKAAAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVmYXVsdCA9 IE5vIGRyaXZlciByZWxvYWQgLSByZXF1aXJlcyByZWJvb3QKAAAAACAgICAgICAgICAgICAgICAg LXUgICAgICAgICAgPSB1bmxvYWQgYW5kIHJlbG9hZCBkcml2ZXIKAAAAACAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBkZWZhdWx0ID0gYWxsIGtub3duIG5ldHdvcmsgZGV2aWNlcwoAICAg ICAgICAgICAgICAgICBIYXJkd2FyZV9JRCA9IFBDSVxWRU5fWFhYWCZERVZfWFhYWCZTVUJTWVNY WFhYWVlZWQoAAAAAICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlZmF1bHQgPSBjdXJy ZW50IGRpcmVjdG9yeQoAICAgICAgIHdoZXJlICAgICBJTkZfRmlsZSAgICA9IGZ1bGx5IHF1YWxp ZmllZCBmaWxlIG5hbWUgb2YgdGhlIFBuUCBJTkYKAAAAAFVzYWdlOiBXMktVcGRhdGUgLWlbSU5G X0ZpbGVdIC1oW0hhcmR3YXJlX0lEXSAtdQoAAABDdXJyZW50UGF0aDogJXMKAAAAAGFyZ3ZbMF06 ICVzCgAAAABORVQqLklORgAAAABJZ25vcmluZyB1bmtub3duIG9wdGlvbiBbJXNdCgAAAD8AAABW ZXJib3NlTW9kZSBpcyBPTgoAAC1lAAAtdQAALXkAAC1kAAAtbgAALXYAAC1oAAAtaQAAKFJlYm9v dCBSZXF1aXJlZCkKAABBZmZlY3RlZCBEZXZpY2VbJWRdID0gJXMKAAAASGFyZHdhcmVJZDogJXMK AEluZk5hbWU6ICVzCgAAAAAAAAAAAAAAAP/////BJwAB1icAAXJ1bnRpbWUgZXJyb3IgAAANCgAA VExPU1MgZXJyb3INCgAAAFNJTkcgZXJyb3INCgAAAABET01BSU4gZXJyb3INCgAAUjYwMjgNCi0g dW5hYmxlIHRvIGluaXRpYWxpemUgaGVhcA0KAAAAAFI2MDI3DQotIG5vdCBlbm91Z2ggc3BhY2Ug Zm9yIGxvd2lvIGluaXRpYWxpemF0aW9uDQoAAAAAUjYwMjYNCi0gbm90IGVub3VnaCBzcGFjZSBm b3Igc3RkaW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNQ0KLSBwdXJlIHZpcnR1YWwgZnVuY3Rp b24gY2FsbA0KAAAAUjYwMjQNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgX29uZXhpdC9hdGV4aXQg dGFibGUNCgAAAABSNjAxOQ0KLSB1bmFibGUgdG8gb3BlbiBjb25zb2xlIGRldmljZQ0KAAAAAFI2 MDE4DQotIHVuZXhwZWN0ZWQgaGVhcCBlcnJvcg0KAAAAAFI2MDE3DQotIHVuZXhwZWN0ZWQgbXVs dGl0aHJlYWQgbG9jayBlcnJvcg0KAAAAAFI2MDE2DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIHRo cmVhZCBkYXRhDQoADQphYm5vcm1hbCBwcm9ncmFtIHRlcm1pbmF0aW9uDQoAAAAAUjYwMDkNCi0g bm90IGVub3VnaCBzcGFjZSBmb3IgZW52aXJvbm1lbnQNCgBSNjAwOA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBhcmd1bWVudHMNCgAAAFI2MDAyDQotIGZsb2F0aW5nIHBvaW50IG5vdCBsb2FkZWQN CgAAAABNaWNyb3NvZnQgVmlzdWFsIEMrKyBSdW50aW1lIExpYnJhcnkAAAAACgoAAFJ1bnRpbWUg RXJyb3IhCgpQcm9ncmFtOiAAAAAuLi4APHByb2dyYW0gbmFtZSB1bmtub3duPgAAAAAAAAYAAAYA AQAAEAADBgAGAhAERUVFBQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBg YAAAcHB4eHh4CAcIAAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAAAAA AAAAAABHZXRMYXN0QWN0aXZlUG9wdXAAAEdldEFjdGl2ZVdpbmRvdwBNZXNzYWdlQm94QQB1c2Vy MzIuZGxsAABy6TZNJePOEb/BCAAr4QMYAAAAAAAAAABVi+yB7AwBAABTVlf/FRAQAAGDZfwAiUX4 jYX0/v//aAQBAABQ/xUMEAABg8r/v5QRAAGLyjPA8q730Sv5jZ30/v//i/eL+4vZi8ryrovLT8Hp AvOli8uNnfT+//+D4QNokBEAAfOkv4QRAAGLyvKu99Er+Yv3i/uL2YvK8q6Ly0/B6QLzpYvLjZ30 /v//g+ED86S/fBEAAYvK8q730Sv5i/eL+4vZi8ryrovLT8HpAvOli8uNhfT+//+D4QNQ86Toqw0A AFkz9lmL+FaNRfxWUGgABAAA/3X4VmgAEQAA/xUIEAABhcB0Df91/P91CGhsEQAB6wv/dfj/dQho VBEAAVfo+QwAAIPEEDl1/F9eW3QJ/3X8/xUEEAAB/3X4/xV8EAABM8DJwgQAVYvsuEBBAADoiQ4A AFNWVzP/agJXV2hIGgABiX38iX34iX30/xXoEAABi/CD/v91D2iMEgAB6Jv+///pCgIAAI1F1MdF 1BwAAABQV1b/FeQQAAGFwA+E7AEAAIs9zBAAAbsAEAAA/0X0agCNhcC+//9TUI1F1FBW/xXcEAAB agCNhcC+//9TUI1F8FCNRdRqCVBW/9eDPdi7AAEAdBONhcC+//9QaFwSAAHopw0AAFlZagCNhcC+ //9TUI1F8FCNRdRqAFBW/9eDPdi7AAEAdBONhcC+//9QaCgSAAHodA0AAFlZjUX4UP91+P91/I1F 8FCNRdRqAVBW/9eFwHU2/xUQEAABg/h6D4VDAQAAg338AHQJ/3X8/xUEEAAB/3X4akD/FRQQAAGN TfiJRfxR/3X4UOu5gz3YuwABAHQP/3X8aPQRAAHoCw0AAFlZi0X8gDgAD4TKAAAAi034A8g7wQ+D vQAAAIN9DAC47BEAAXUFuOARAAFQjYXA/v//aNARAAFQ6F4MAAD/dQj/dfzo0wsAAIPEFIXAD4SF AAAAgz3YuwABAHQP/3X8aLQRAAHoogwAAFlZjUXUUFb/FdgQAAGFwHRHM8BqFDlFDMdFwAgAAADH RcQSAAAAx0XMBAAAAA+UwECJRciNRcBQjUXUUFb/FdQQAAGFwHQRjUXUUFZqEv8V0BAAAYXAdReN hcD+//9Q6L78//+F9nQHVv8V4BAAAVb/FeAQAAGNRdTHRdQcAAAAUP919Fb/FeQQAAGFwA+FH/7/ /2oBWF9eW8nCCABomBEAAeh7/P//M8Dr61WL7IHslAAAAFcz/2oCV1doSBoAAf8V6BAAAYP4/4lF /HUPaIwSAAHoSvz//+m6AQAAOT3YuwABdA//dQho9BIAAeiwCwAAWVlTjUXQVlCJffDHRdAcAAAA iX30V/91/P8V5BAAAYXAD4QoAQAAjUX4izXMEAABUFeNRexXUI1F0GoBUP91/DPbiX34/9aFwHVJ /xUQEAABg/gNdD7/FRAQAAGD+HoPheMAAAA733QHU/8VBBAAAf91+GpA/xUUEAABi9iNRfhQjUXs /3X4U1CNRdBqAVD/dfzrsf8VEBAAAYP4DQ+ElgAAAIA7AIvzdH+LRfgDwzvwc3Y5Pdy7AAF0DVZo 2BIAAejqCgAAWVn/dQhW6O8JAABZhcBZdRRW/xUYEAABgHwGAQCNdAYBdcHrPjk92LsAAXQNVmjI EgAB6LIKAABZWYv7g8n/M8DHRfABAAAA8q730Sv5i8GL94t9DMHpAvOli8iD4QPzpDP/O990B1P/ FQQQAAE5ffB1Fv9F9I1F0FD/dfTpzv7//2iYEQAB6zD/FRAQAAGFwHQrOT3YuwABdCP/dQiNhWz/ //9osBIAAVDoywkAAIPEDI2FbP///1DorPr///8VEBAAAf91/Ivw/xXgEAABVv8VfBAAATPAO/de Ww+UwF/JwggAVYvs/3UQ/3UM6AH+//+FwHQ+jUUUUGoB/3UI/3UQagDo11UAAIXAdQ9oRBMAAehT +v//agJY6xqDPdi7AAEAdA//dRBoFBMAAei4CQAAWVkzwF3CEACB7EQCAACDPdi7AAEAdAtoyBMA AeiXCQAAWVNVVrvgvwABg83/V4v7i80zwI1UJBDyrvfRK/mLwYv3i/rB6QLzpYvIM8CD4QPzpIv7 i83yrvfRSYC5378AAVx0Kr+UEQABi83yrvfRK/mNVCQQi/eL+ovRi83yrovKT8HpAvOli8qD4QPz pIu8JFgCAACLzTPAjVQkEPKu99Er+Yv3i/qL0YvN8q6Lyk/B6QLzpYvKg+EDOQXYuwAB86R0HY1E JBBQaLgTAAHo5QgAAFNonBMAAejaCAAAg8QQjYQkFAEAAFCNRCQUUP8VHBAAATvFdSK+iBMAAVbo Nfn//4M92LsAAQB0B1bopggAAFlqMunEAAAAi/uLzTPA8q730Sv5i8GL94u8JFgCAADB6QLzpYvI g+ED86SDPdi7AAEAdA1TaHQTAAHoZwgAAFlZi/uLzTPA8q730UmAud+/AAFcdCu/lBEAAYvN8q73 0Sv5i/eLvCRYAgAAi9GLzfKui8pPwekC86WLyoPhA/OkjbwkQAEAAIvNM8DyrvfRK/mL94u8JFgC AACL0YvN8q6Lyk/B6QLzpYvKg+ED86Q5Bdi7AAF0E/+0JFgCAABoaBMAAejeBwAAWVlqAVhfXl1b gcREAgAAwgQAaHwVAAHowgcAAMcEJDAVAAHotgcAAMcEJPQUAAHoqgcAAMcEJKwUAAHongcAAMcE JGgUAAHokgcAAMcEJCwUAAHohgcAAMcEJNwTAAHoegcAAFnDg+xoU1WLXCR4VldqAV85fCR8iXwk EA+OpgEAAI1rBGoCXlZoNBYAAf91AOi4CAAAg8QMhcB1K4t9AIPJ/wP+8q730Sv5i/eLwb8wgAAB wekC86WLyIPhA/OkagFf6UsBAABWaDAWAAH/dQDoeAgAAIPEDIXAdS+LfQCDyf8D/vKu99Er+YvB i/e/MIgAAcHpAvOli8iD4QPzpMcFMJMAAQEAAADrtFZoLBYAAf91AOg0CAAAg8QMhcB1HIt9AIPJ /wP+8q730Sv5i/eLwb/IuwAB6Xf///9WaCgWAAH/dQDoAwgAAIPEDIXAdQshBTSTAAHptgAAAFZo JBYAAf91AOjjBwAAg8QMhcB1C4k91LsAAemWAAAAVmggFgAB/3UA6MMHAACDxAyFwHUIiT3cuwAB 63lWaBwWAAH/dQDopgcAAIPEDIXAdQiJPeC7AAHrXFZoGBYAAf91AOiJBwAAg8QMhcB1E2gEFgAB iT3YuwAB6AIGAABZ6zRXaAAWAAH/dQDoYQcAAIPEDIXAdGD/dQCNRCQYaOAVAAFQ6GgFAACDxAyN RCQUUOhL9v///0QkEIPFBItEJBA7RCR8D4xd/v//vtQVAAG4MIAAAYoQiso6FnUmhMl0EopQAYrK OlYBdRhAQEZGhMl14jPA6xHouf3//2oF6e8AAAAbwIPY/4XAD4XgAAAAOQXYuwABdA7/M2jEFQAB 6F0FAABZWWpc/zPokgYAAFmFwFl0KoBgAQCLO4PJ/zPA8q730Sv5veC/AAGLwYv3i/3B6QLzpYvI g+ED86Trb2o6/zPomQUAAFmFwFl0T4BgAQCLO4PJ/zPA8q730Sv5veC/AAGLwYv3i/3B6QLzpYvI M8CD4QPzpL+UEQABg8n/8q730Sv5i/eL0Yv9g8n/8q6Lyk/B6QLzpYvK65u94L8AAVVoBAEAAP8V IBAAAYM92LsAAQB0DVVosBUAAeifBAAAWVloMIAAAejj+v//6wNqAVhfXl1bg8RowggAVYvsgewE AgAAihWIFgABVldqP1kzwI29/f3//4iV/P3///OrZquqaj8zwFmNvf3+////dQyIlfz+///zq/91 CDP2ZquqiXX86L/8//+D+AF0B2oC6RcBAAA5Ndi7AAF0I2gwgAABaHgWAAHoFAQAAI2F/P3//1Bo aBYAAegDBAAAg8QQOTUwkwABU4l1DH5ouzCIAAGAOwB0Xov7g8n/M8CNlfz9///yrvfRK/mLwYv3 i/rB6QLzpYvIg+EDgz00kwABAPOkdByNRfxQjYX8/v//UI2F/P3//1BoMIAAAeia+f///0UMgcMA AQAAi0UMOwUwkwABfJ0z2zkd1LsAAXQ2OJ38/v//jbX8/v//dCiLw1ZQaEwWAAFD6GUDAACL/oPJ /zPAg8QM8q730Uk4RA4BjXQOAXXYM/aNhfz+//9WUOjn9P//jYX8/v//agFQ6Nn0//85dfxbdBg5 Ndi7AAF0C2g4FgAB6BcDAABZagFY6wIzwF9eycPMzMzMzMzMzMzMzFWL7MHAakgbxQ8xK8RAuGYw AQYPAur4clrWG8a4SjcBBhvFJQE5AQb5cwqDwCD4JV89AQZduHA+AQboCgAAADPC1ukGAAAAMQqL xcPW1uiRAAAAA8RA6A8AAAALw/npDgAAADEvPRNPAQb5cx3Di8X4I8Xo7f///wUHVQEGK/ZmY8kP hOVYAYboCgAAAEjpDQAAADE5E8Q9b14BBsNIE8QLxegNAAAAi8f86QwAAAAxC/gbwDPC1sMbw/mD 4GOhHHYAAYvI6AgAAADpDAAAADEL+T1pcwEGwzPAkDVmdgEGi8H/4DPAZP8wi8RkZ6MAADPAgRAc fAGG6ItF4FDobgQAAIPEBMdF/P////+LTfBkiQ0AAAAAX15bi+Vdw5CQkIM97LsAAQJ0BejCFAAA i0QkBFDo+BQAAIPEBGj/AAAA/xU4kwABg8QEw5CQkJCQkIM97LsAAQJ0BeiSFAAAi0QkBFDoyBQA AIPEBGj/AAAA/xUsEAABw5CQkJCQkJCQkFNWi3QkDFdW6IMWAACLTCQYg8QEi/iNRCQYUFFW6I4X AACDxAyL2FZX6CIXAACDxAiLw19eW8OQkJCQkJCQkJDo+yMAAIXAdQHDi0wkCItUJARQi0QkEFBR UugRIgAAg8QQw5CQkJCQkJCQkJCQkJCLRCQIi0wkBGpAUFHov////4PEDMOQkJCQkJCQkJCQkItM JAhXU1aKEYt8JBCE0nRpinEBhPZ0T4v3i0wkFIoHRjjQdBWEwHQLigZGONB0CoTAdfVeW18zwMOK BkY48HXrjX7/imEChOR0KIoGg8YCOOB1xIpBA4TAdBiKZv+DwQI44HTf67EzwF5bX4rC6QMBAACN R/9eW1/Di8deW1/Dg+wgi0QkJItMJCiJRCQIiUQkAI1EJCxWUI1UJAhRUsdEJBxCAAAAx0QkFP// /3/obBYAAIvwi0QkFIPEDEiJRCQIeA6LRCQExgAAi8Zeg8Qgw41MJARRagDoYiMAAIPECIvGXoPE IMOQkJCQkJCQkFZXaJiVAAHoBBUAAItMJBCDxASL8I1EJBBQUWiYlQAB6AsWAACDxAyL+GiYlQAB VuibFQAAg8QIi8dfXsOQkJBRPQAQAACNTCQIchSB6QAQAAAtABAAAIUBPQAQAABz7CvIi8SFAYvh iwiLQARQw8yNQv9bwy6LwC6LwC6LwIvAM8CKRCQIU4vYweAIi1QkCPfCAwAAAHQTigpCONl00YTJ dFH3wgMAAAB17QvYV4vDweMQVgvYiwq///7+fovBi/czywPwA/mD8f+D8P8zzzPGg8IEgeEAAQGB dRwlAAEBgXTTJQABAQF1CIHmAAAAgHXEXl9bM8DDi0L8ONh0NoTAdO843HQnhOR058HoEDjYdBWE wHTcONx0BoTkdNTrll5fjUL/W8ONQv5eX1vDjUL9Xl9bw41C/F5fW8PMzMzMVYvsV4t9CDPAg8n/ 8q5B99lPikUM/fKuRzgHdAQzwOsCi8f8X8nDzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiL fQyNBYi/AAGDeAgAdUO3QbNatiAui8CKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLG OMR1CUl11zPJOMR0S7n/////ckT32etAM8Az24vAigYLwIofdCML23QfRkdRUFPobiMAAIvYg8QE 6GQjAACDxARZO8N1CUl11TPJO8N0Cbn/////cgL32YvBW15fycPMzMyhMNIAAYXAdAL/0GgQgAAB aAiAAAHoBgEAAIPECGgEgAABaACAAAHo9AAAAIPECMOLRCQEagBqAFDoMgAAAIPEDMOQkJCQkJCQ kJCQkJCQkItEJARqAGoBUOgSAAAAg8QMw5CQkJCQkJCQkJCQkJCQoTi8AAFTVYtsJAyD+AFWdQ5V /xU0EAABUP8VMBAAAYtEJBSLXCQYhcDHBTS8AAEBAAAAiB0wvAABdT6LDSzSAAGFyXQiizUo0gAB g+4EO/FyFYsGhcB0CP/Qiw0s0gABg+4EO/Fz62gcgAABaBSAAAHoOgAAAIPECGgkgAABaCCAAAHo KAAAAIPECIXbdRFVxwU4vAABAQAAAP8VLBAAAV5dW8OQkJCQkJCQkJCQkJBWi3QkCFeLfCQQO/dz D4sGhcB0Av/Qg8YEO/dy8V9ew4tEJARTVVZQ6DMBAACDxASFwA+EFwEAAItYCIXbD4QMAQAAg/sF dRDHQAgAAAAAuAEAAABeXVvDg/sBdQeDyP9eXVvDi0wkFIstPLwAAYkNPLwAAYtIBIP5CA+FtQAA AIs1uJMAAYsVvJMAAQPWO/J9GI0MdivWjQyNSJMAAccBAAAAAIPBDEp19IsAiw3EkwABPY4AAMCL 8XUHuYMAAADrUj2QAADAdQe5gQAAAOtEPZEAAMB1B7mEAAAA6zY9kwAAwHUHuYUAAADrKD2NAADA dQe5ggAAAOsaPY8AAMB1B7mGAAAA6ww9kgAAwHULuYoAAACJDcSTAAFRagj/04PECIk1xJMAAYkt PLwAAYPI/15dW8NRx0AIAAAAAP/Tg8QEiS08vAABg8j/Xl1bw4tUJBRS/xU4EAABXl1bw5CQi1Qk BIsNQJMAAVaLNcCTAAE7yrhAkwABdBWNDHaNDI1AkwABg8AMO8FzBDkQdfWNDHaNDI1AkwABO8Fz BDkQdAIzwF7DkJCQkJCQkJCQkJBRixXkuwABU1VWigIz9oTAV3QdPD10AUaL+oPJ/zPA8q730UmK RAoBjVQKAYTAdeONBLUEAAAAUOiDIQAAi/CDxASF9ol0JBCJNRi8AAF1CmoJ6Nn4//+DxASLLeS7 AAGKVQCE0nRji/2Dyf8zwPKu99FJi9lDgPo9dEVT6D8hAACDxASJBoXAdQpqCeif+P//g8QEi/2D yf8zwPKui0QkEPfRK/mL0Yv3izjB6QLzpYvKg+EDg8AE86SJRCQQi/CKVB0AA+uE0nWdoeS7AAFQ 6JsgAACDxATHBeS7AAEAAAAAxwYAAAAAX15dW1nDkJCD7AhWV2gEAQAAaEC8AAFqAP8VPBAAAYs9 NNIAAccFKLwAAUC8AAGAPwB1Bb9AvAABjUQkDI1MJAhQUWoAagBX6FsAAACLVCQgi0QkHIPEFI0M glHodyAAAIvwg8QEhfZ1CmoI6Nf3//+DxASLTCQIjVQkDFKNRCQMjRSOUFJWV+gbAAAAi0QkHIPE FEiJNRC8AAFfowy8AAFeg8QIw5CQi0QkEFNVi2wkEFaLdCQYV4t8JCSF7ccHAAAAAMcAAQAAAItE JBS7BAAAAHQJiXUAA+uJbCQYgDgidVaKSAFAgPkidDiEyXQ0geH/AAAAhJlRvQABdA+LF0KF9okX dAaKCIgORkCLF0KF9okXdAWKEIgWRopIAUCA+SJ1yIsXQoX2iRd0BMYGAEaAOCJ1VkDrU4sXQoX2 iRd0BYoIiA5GighAiEwkJItUJCSB4v8AAACEmlG9AAF0D4sXQoX2iRd0BYoQiBZGQID5IHQJhMl0 CYD5CXW8hMl1A0jrCIX2dATGRv8AM9KJVCQkgDgAD4QDAQAAigiA+SB0BYD5CXUDQOvxgDgAD4Tr AAAAhe10CYl1AAPriWwkGItMJCD/AYoYM8mA+1y9AQAAAHUKilgBQEGA+1x09oA4InUl9sEBdR6F 0nQJgHgBInUDQOsCM+2LXCQkM9KF2w+UwolUJCTR6YvZSYXbdBFBhfZ0BMYGXEaLH0NJiR918IoI hMl0XYXSdQqA+SB0VID5CXRPhe10RYX2dCqL2YHj/wAAAPaDUb0AAQR0CYgOiw9GQEGJD4oIiA6L D0ZBiQ9A6WD///+B4f8AAAD2gVG9AAEEdAaLD0BBiQ//B0DpQ////4X2dATGBgBGiw+LbCQYQbsE AAAAiQ/p9P7//4XtdAfHRQAAAAAAi0QkIF9eXYsIW0GJCMOQoUi9AAFTVYstTBAAAVYz9jPbV4s9 UBAAAYXAdSX/14vwhfZ0B7gBAAAA6xH/1YvYhdsPhBcBAAC4AgAAAKNIvQABg/gBD4WXAAAAhfZ1 DP/Xi/CF9g+E9AAAAGaDPgCLxnQSg8ACZoM4AHX3g8ACZoM4AHXuK8ZqANH4QGoAi+hqAGoAVVZq AGoA/xVUEAABi/iF/3Q+V+iEHQAAi9iDxASF23QvagBqAFdTVVZqAGoA/xVUEAABhcB1C1PoDx0A AIPEBDPbVv8VSBAAAYvDX15dW8NW/xVIEAABM8BfXl1bw4P4AnVohdt1CP/Vi9iF23RciguLw4TJ dBCKSAFAhMl1+IpIAUCEyXXwK8NAi/BW6AodAACL6IPEBIXtdQ5T/xVAEAABM8BfXl1bw4vOi/OL wYv9wekC86WLyFOD4QPzpP8VQBAAAYvFX15dW8NfXl0zwFvDkJCQkJCQkJCQkItEJASD7BRTVVZX UOj/AQAAi8ihWL8AAYPEBDvIiUwkKHUKM8BfXl1bg8QUw4XJdRToigIAAOjFAgAAM8BfXl1bg8QU wzPSuNCTAAE5CA+EBwEAAIPAMEI9wJQAAXLtjVQkEFJR/xVYEAABvgEAAAA7xg+FuwAAALlAAAAA M8C/UL0AAfOri0wkEKqLfCQoM8A7zok9WL8AAaNcvwABdm6KRCQWhMB0N41UJBeKCoTJdC0zwIHh /wAAAIpC/zvBdxSKmFG9AAGAywSImFG9AAFAO8F27IpCAYPCAoTAdc2LxoqYUb0AAYDLCIiYUb0A AUA9/wAAAHLpV+hiAQAAg8QEo1y/AAGJNSTSAAHrBaMk0gABM8CjYL8AAaNkvwABo2i/AAHo1wEA ADPAX15dW4PEFMOhbL8AAYXAdBTofwEAAOi6AQAAM8BfXl1bg8QUw4PI/19eXVuDxBTDuUAAAAAz wL9QvQABjRxS86uqM//B4wSNq+CTAAGKRQCL9YTAdDCKTgGEyXQpM8CB4f8AAACKBjvBdxGKl8iT AAEIkFG9AAFAO8F29YpGAoPGAoTAddBHg8UIg/8Ecr6LRCQoxwUk0gABAQAAAFCjWL8AAeiNAAAA i4vUkwABi5PYkwABo1y/AAGNg9STAAGDxASJDWC/AAGLQAiJFWS/AAGjaL8AAej6AAAAX15dM8Bb g8QUw4tEJATHBWy/AAEAAAAAg/j+dRDHBWy/AAEBAAAA/yVgEAABg/j9dRDHBWy/AAEBAAAA/yVc EAABg/j8dQ+hoL8AAccFbL8AAQEAAADDkJCQi0QkBAVc/P//g/gSdyczyYqIfDYAAf8kjWg2AAG4 EQQAAMO4BAgAAMO4EgQAAMO4BAQAAMMzwMNNNgABUzYAAVk2AAFfNgABZTYAAQAEBAQBBAQEBAQE BAQEBAQEAgOQV7lAAAAAM8C/UL0AAfOrqjPAX6NYvwABoyTSAAGjXL8AAaNgvwABo2S/AAGjaL8A AcOQkJCQkJCQkJCQkJCQkIsNWL8AAYHsFAUAAI1EJABTUFH/FVgQAAGD+AEPhVIBAABXVjPAiEQE IEA9AAEAAHL0ikQkEsZEJCAghMB0NY1UJBMzySX/AAAAigo7wXcaK8iNfAQgQbggICAgi/HB6QLz q4vOg+ED86qKQgGDwgKEwHXPixVcvwABoVi/AAFqAFKNjCQoAwAAUFGNVCQwaAABAABSagHoNBwA AKFYvwABg8QcjYwkIAEAAI1UJCBqAFChXL8AAWgAAQAAUWgAAQAAUmgAAQAAUOiiGQAAiw1YvwAB g8QgjZQkIAIAAI1EJCBqAFGLDVy/AAFoAAEAAFJoAAEAAFBoAAIAAFHobhkAAIPEIDPAjZQkIAMA ALMQZosK9sEBdB2KiFG9AAEKy4iIUb0AAYqMBCABAACIiFi+AAHrKvbBAnQeiohRvQABgMkgiIhR vQABiowEIAIAAIiIWL4AAesHxoBYvgABAECDwgI9AAEAAHKmXl9bgcQUBQAAwzPAsxCD+EFyIIP4 WncbipBRvQABCtOIkFG9AAGK0IDCIIiQWL4AAestg/hhciGD+Hp3HIqIUb0AAYDJIIiIUb0AAYrI gOkgiIhYvgAB6wfGgFi+AAEAQD0AAQAAcqZbgcQUBQAAw5CQkJCQkGr96Bn7//+DxATDkJCQkJCD 7EhTVVZXaAABAADovxcAAIvwg8QEhfZ1Cmob6B/v//+DxASNhgABAACJNSDRAAE78McFINIAASAA AACzCnMgxkYEAMcG/////4heBYsNINEAAYPGCIHBAAEAADvxcuCNVCQUUv8VcBAAAWaDfCRGAA+E 8gAAAItEJEiFwA+E5gAAAIsIjXgEgfkACAAAiUwkEI0sD3wIx0QkEAAIAACLRCQQiw0g0gABO8h9 ab4k0QABaAABAADoFBcAAIPEBIXAdEmLDSDSAAGJBoPBIIkNINIAAY2IAAEAADvBcxzGQAQAxwD/ ////iFgFixaDwAiBwgABAAA7wnLkoSDSAAGLTCQQg8YEO8F8qOsKiw0g0gABiUwkEItEJBAz9oXA fkmLTQCD+f90NIoHqAF0LqgIdQtR/xVsEAABhcB0H4vWi8bB+gWD4B+LDJUg0QABi1UAiRTBjQTB ig+ISASLRCQQRkeDxQQ78Hy3iy1oEAABM9uLFSDRAAGLBNqNNNqD+P91VIXbxkYEgXUHuPb////r CovDSPfYG8CDwPVQ/9WL+IP//3QqV/8VbBAAAYXAdB8l/wAAAIk+g/gCdQeKRgQMQOsYg/gDdRaK RgQMCOsMikYEDEDrBYpGBAyAiEYEQ4P7A3yNoSDSAAFQ/xVkEAABX15dW4PESMOQkJCQkJCQkGoA aAAQAABqAf8VeBAAAYXAowTRAAF1AcPoAhoAAIXAdQ+hBNEAAVD/FXQQAAEzwMO4AQAAAMOQkJCQ kJCQkJBVi+xTVldVagBqAGgYOwAB/3UI6Lg6AABdX15bi+Vdw4tMJAT3QQQGAAAAuAEAAAB0D4tE JAiLVCQQiQK4AwAAAMNTVleLRCQQUGr+aCA7AAFk/zUAAAAAZIklAAAAAItEJCCLWAiLcAyD/v90 Ljt0JCR0KI00dosMs4lMJAiJSAyDfLMEAHUSaAEBAACLRLMI6EAAAAD/VLMI68NkjwUAAAAAg8QM X15bwzPAZIsNAAAAAIF5BCA7AAF1EItRDItSDDlRCHUFuAEAAADDU1G7zJQAAesKU1G7zJQAAYtN CIlLCIlDBIlrDFlbwgQAzMxWQzIwWEMwMFWL7IPsCFNWV1X8i10Mi0UI90AEBgAAAA+FggAAAIlF +ItFEIlF/I1F+IlD/ItzDIt7CIP+/3RhjQx2g3yPBAB0RVZVjWsQ/1SPBF1ei10MC8B0M3g8i3sI U+ip/v//g8QEjWsQVlPo3v7//4PECI0MdmoBi0SPCOhh////iwSPiUMM/1SPCIt7CI0Mdos0j+uh uAAAAADrHLgBAAAA6xVVjWsQav9T6J7+//+DxAhduAEAAABdX15bi+Vdw1WLTCQIiymLQRxQi0EY UOh5/v//g8QIXcIEAKHsuwABg/gBdA2FwHUugz08kwABAXUlaPwAAADoHwAAAKFwvwABg8QEhcB0 Av/QaP8AAADoBwAAAIPEBMOQkJCLTCQEgeyoAQAAuOCUAAFTVVZXM+07CHQLg8AIRT1wlQABcvE7 DO3glAABD4WaAQAAoey7AAGD+AEPhE4BAACFwHUNgz08kwABAQ+EPQEAAIH5/AAAAA+EbwEAAI2E JLQAAABoBAEAAFBqAP8VPBAAAYXAdRa5BQAAAL50GQABjbwktAAAAPOlZqWkjbwktAAAAIPJ/zPA jZwktAAAAPKu99GD+Tx2LY28JLQAAACDyf/yrvfRSWoDi9mNjCS4AAAAg+k7aHAZAAED2VPorx4A AIPEDLkGAAAAvlQZAAGNfCQUM8DzpWalg8n/i/vyrvfRK/mNVCQUi9mL94PJ/4v68q6Ly0/B6QLz pYvLjVQkFIPhA2gQIAEA86S/UBkAAYPJ//Ku99Er+WgoGQABi/eL2Yv6g8n/8q6Ly0/B6QLzpYvL jVQkHIPhA/Okizzt5JQAAYPJ//Ku99Er+Yv3i9mL+oPJ//Kui8tPwekC86WLy41EJByD4QNQ86To cR0AAIPEDF9eXVuBxKgBAADDoSDRAAGFwHQIi3AQg/7/dQpq9P8VaBAAAYvwixTt5JQAAY1MJBBq AFGL+oPJ/zPA8q730UlRUlb/FYQQAAFfXl1bgcSoAQAAw5CQkJCQkJCQkJBWi3QkCFeLRhBQ6JEe AACDxASFwA+EmQAAAIH+mJUAAXUEM//rEYH+uJUAAQ+FgQAAAL8BAAAAiw2AvwABQYkNgL8AAYtG DKkMAQAAdWWLBL14vwABhcB1LWgAEAAA6D0RAACDxASJBL14vwABhcB1FY1GFIlGCIkGuAIAAACJ RhiJRgTrGos8vXi/AAHHRhgAEAAAiX4IiT7HRgQAEAAAi0YMDQIRAACJRgy4AQAAAF9ew18zwF7D kJCQkJCQkJCLRCQEVoXAdDSLdCQMi0YM9sQQdD1W6EUeAACLRgyDxASA5O7HRhgAAAAAiUYMxwYA AAAAx0YIAAAAAF7Di0QkDItIDPbFEHQJUOgRHgAAg8QEXsOQkJCQkJCQkJCQkJCB7EwCAABTVVZX i7wkZAIAADPJM+2JTCQcih9HhNuIXCRAibwkZAIAAA+EKAgAAIt0JCjrCIt0JCiLTCQ8i0QkHDPS O8IPjAwIAACA+yB8E4D7eH8OD77DioBwGQABg+AP6wIzwA++hMGQGQABwfgEg/gHiUQkPA+HvQcA AP8khYxIAAGJVCREiVQkNIlUJCiJVCQkiVQkEMdEJBj/////iVQkLOmRBwAAD77Dg8Dgg/gQD4eC BwAAM8mKiMRIAAH/JI2sSAABi0QkEAwEiUQkEOlkBwAAi0QkEAwBiUQkEOlVBwAAi0QkEAwCiUQk EOlGBwAAi0QkEAyAiUQkEOk3BwAAi0QkEAwIiUQkEOkoBwAAgPsqdTKNlCRoAgAAUug8CQAAg8QE iUQkKIXAD40HBwAAi1QkEIPKBPfYiVQkEIlEJCjp8QYAAA++y40Eto1UQdCJVCQo6d4GAACJVCQY 6dUGAACA+yp1KY2EJGgCAABQ6OkIAACDxASJRCQYhcAPjbQGAADHRCQY/////+mnBgAAi0QkGA++ 040MgI1EStCJRCQY6ZAGAAAPvsODwLeD+C4Ph4EGAAAzyYqI7EgAAf8kjdhIAAGLRCQQDBCJRCQQ 6WMGAACAPzZ1IIB/ATR1GotEJBCDxwKAzICJvCRkAgAAiUQkEOk+BgAAiVQkPKE4uAABiVQkLItU JECB4v8AAAD2RFABgHQji5QkYAIAAI1MJBwPvsNRUlDoYAcAAIofg8QMR4m8JGQCAACLlCRgAgAA jUwkHA++w1FSUOg9BwAAg8QM6d8FAACLRCQQDCCJRCQQ6dAFAACLRCQQgMwIiUQkEOnABQAAD77D g8C9g/g1D4eXBAAAM8mKiGBJAAH/JI0cSQABi0QkEKkwCAAAdQeAzAiJRCQQ90QkEBAIAAB0OY2U JGgCAABS6N8HAACDxARQjUQkYFDoMRwAAIvog8QIhe19Lo1UJFzHRCQ0AQAAAIlUJBTpMwQAAI2M JGgCAABR6GYHAACDxASIRCRcvQEAAACNVCRciVQkFOkNBAAAjYQkaAIAAFDoQAcAAIPEBIXAdDqL SASFyXQzi1QkEPbGCHQWD78oiUwkFMdEJCwBAAAA0e3p0wMAAA+/KMdEJCwAAAAAiUwkFOm/AwAA iz1wlQABg8n/M8CJfCQU8q730UmL6emkAwAAi0QkEKkwCAAAdQeAzAiJRCQQi0QkGL7///9/g/j/ dAKL8I2MJGgCAABR6LUGAACLyItEJBSDxASJTCQUqRAIAAB0OoXJdQqLDXSVAAGJTCQUi9ZOhdLH RCQsAQAAAIvBdBBmgzgAdAqDwAKL1k6F0nXwK8HR+Ivo6ScDAACFyXUKiw1wlQABiUwkFIvWToXS i8F0DYA4AHQIQIvWToXSdfMrwYvo6foCAACNhCRoAgAAUOgtBgAAikwkFIPEBPbBIHQVZotMJBzH RCQ0AQAAAGaJCOnMAgAAi1QkHMdEJDQBAAAAiRDpuQIAAMdEJEQBAAAAgMMgi1QkEI1EJFyJRCQU i0QkGIPKQIXAiVQkEH0Kx0QkGAYAAADrD3UNgPtndQjHRCQYAQAAAIuEJGgCAACLfCQYg8AIiYQk aAIAAItI+IlMJEyLUPyLRCREiVQkUA++y1BXjVQkZFGNRCRYUlD/FSC4AAGLdCQkg8QUgeaAAAAA dBKF/3UOjUwkXFH/FSy4AAGDxASA+2d1EoX2dQ6NVCRcUv8VJLgAAYPEBIB8JFwtdROLRCQQgMwB iUQkEI1EJF2JRCQUi3wkFIPJ/zPA8q730UmL6enWAQAAi0QkEMdEJDAKAAAADECJRCQQ62nHRCQw CgAAAOtfx0QkGAgAAADHRCQ4BwAAAOsIx0QkOCcAAACKRCQQx0QkMBAAAACogHQ1ikwkOMZEJCIw gMFRx0QkJAIAAACITCQj6xuKRCQQx0QkMAgAAACogHQLi0QkEIDMAolEJBCLXCQQ9seAdBKNlCRo AgAAUuijBAAAg8QE62L2wyB0M/bDQHQWjYQkaAIAAFDoZwQAAA+/wIPEBJnrQo2MJGgCAABR6FEE AACDxAQl//8AAJnrKvbDQHQTjZQkaAIAAFLoNAQAAIPEBJnrEo2EJGgCAABQ6CEEAACDxAQz0vbD QHQehdJ/GnwEhcBzFPfYg9IAi/D32oDPAYv6iVwkEOsEi/CL+vbHgHUDg+cAi0wkGIXJfQe5AQAA AOsHg+P3iVwkEIvWC9d1CMdEJCQAAAAAjYQkWwIAAIlEJBSL0UmF0olMJBh/BovOC890RItEJDCZ i+hSVVdWiVQkaOgpGQAAi1QkWIvYUlVXVoPDMOinGAAAg/s5i/CL+n4EA1wkOItEJBSLTCQYiBhI iUQkFOuri0wkEI2sJFsCAAAr6ED2xQKJRCQUdBKAODB1BIXtdQlIRYlEJBTGADCLRCQ0hcAPhQ4B AACLXCQQ9sNAdCr2xwF0B8ZEJCIt6xb2wwF0B8ZEJCIr6wr2wwJ0DcZEJCIgx0QkJAEAAACLfCQo i1QkJCv6K/32wwx1Gou0JGACAACNRCQcUFZXaiDoWwIAAIPEEOsHi7QkYAIAAItUJCSNTCQcUVaN RCQqUlDoegIAAIPEEPbDCHQW9sMEdRGNTCQcUVZXajDoHwIAAIPEEItEJCyFwA+ElgAAAIXtD46O AAAAi3QkFI1d/2aLBo1UJEhQUoPGAugQFwAAg8QIhcB+IouUJGACAACNTCQcUVJQjUQkVFDoEQIA AIPEEIvLS4XJdcaLXCQQ9sMEdBiLlCRgAgAAjUwkHFFSV2og6KkBAACDxBCLvCRkAgAAih9HhNuI XCRAibwkZAIAAA+F3vf//4tEJBxfXl1bgcRMAgAAw4tEJBSNVCQcUlZVUOipAQAAg8QQ66EQQgAB lEAAAblAAAEiQQABbEEAAXVBAAG6QQABikIAAfVAAAEEQQAB5kAAAddAAAETQQABSkgAAQAFBQEF BQUFBQUFAgUDBQUEjUkA50EAAWtCAAHYQQABekIAAUpIAAEABAQEBAQEBAQEBAQEBAQEBAQEBAQE BAQEBAQEBAQEAQQEBAIEBAQEBAQEBAQEA5CoQgABd0QAAXdEAAGMQwABgEUAASNDAAG6QgABWkUA AYJEAAFaRQABNkQAAbxFAAF4RQABnkMAAW5FAAGKRQABMEcAAQAQARACEBAQEBAQEBAQEBADEBAQ EAQQBRAQEBAQEBAQBgcICAgQCRAQEBAKCwwQEA0QDhAQD5CQkJCQkJCQkJCLTCQIi0EESIlBBHgU ixGLRCQEiAKLESX/AAAAQokR6w6LRCQEUVDoZAMAAIPECIP4/3UHi0wkDIkBw4tEJAz/AMOQkJCQ kJCQkJCQkJCQkFNVi2wkEFaLxU2FwFd+JYt0JCCLfCQci1wkFFZXU+iN////iwaDxAyD+P90B4vN TYXJf+dfXl1bw5CQkJCQkJBTVYtsJBBWi8VNhcBXfimLfCQgi1wkHIt0JBQPvgZXU1BG6En///+L B4PEDIP4/3QHi81Nhcl/419eXVvDkJCQi0QkBIsIg8EEiQiLwYtA/MOQkJCQkJCQkJCQkJCQkJCL RCQEiwiDwQiJCItB+ItR/MOQkJCQkJCQkJCQkJCQkItEJASLCIPBBIkIi8Fmi0D8w5CQkJCQkJCQ kJCQkJCQi0wkCFNVVooBM9Iz7VeLPcS/AAE8YXQdPHJ0Ejx3dAczwF9eXVvDuAEDAADrDDPAg88B 6wi4CQEAAIPPAkG+AQAAAIlMJBiKCYTJD4SwAAAAhfYPhKgAAAAPvsmDwdWD+UkPh4QAAAAz24qZ VEwAAf8knSxMAAGoAnVxJP6D5/wMAoHPgAAAAOtk9sTAdV2AzIDrWvbEwHVTgMxA61CF0nVKugEA AACBzwBAAADrP4XSdTm6AQAAAIHn/7///+suhe11KL0BAAAADCDrIYXtdRu9AQAAAAwQ6xT2xBB1 DYDMEOsKqEB1BAxA6wIz9otMJBhBiUwkGIoJhMkPhVD///+LTCQci1QkFGikAQAAUVBS6JoUAACL yIPEEIXJfQczwF9eXVvDoYC/AAFAo4C/AAGLRCQgiXgMX15dx0AEAAAAAMcAAAAAAMdACAAAAADH QBwAAAAAiUgQW8OQR0sAAbRLAAGdSwABkEsAAapLAAFaSwABbksAAX9LAAFkSwABvEsAAQAJCQkJ CQkJCQkJCQkJCQkJCQkJCQkJCQkBCQkJCQkJCQkJCQkJCQIDBAkJCQkJCQkJCQkJCQkFBgkJCQkJ CQkJCQkHCQkJCQkIkJBTVVaLNQDRAAFXM+0z/zPJO/V+UIsV5MAAAbODiwI7xXQZhFgMdApBg8IE O8587eszoeTAAAGLPIjrKWogjTSNAAAAAOinAwAAiw3kwAABg8QEiQQxixXkwAABizQyO/V0Aov+ O/10FYlvBIlvDIlvCIkviW8cx0cQ/////4vHX15dW8OQkJCQkJCQkJCQkJBTVVaLdCQUV4tGDItu EKiCD4QKAQAAqEAPhQIBAAAz26gBdBWoEIleBA+E8QAAAItOCCT+iQ6JRgyLRgyJXgQk7wwCqQwB AACJRgx1JoH+mJUAAXQIgf64lQABdQ1V6P0PAACDxASFwHUJVuiAGQAAg8QE90YMCAEAAHRsi0YI iz6LThgr+I1QAUk7+4kWiU4EfhhXUFXoNRcAAItWCIvYikQkIIPEDIgC61OD/f90FovVi8XB+gWD 4B+LDJUg0QABjQTB6wW4wJQAAfZABCB0DGoCU1XoNhYAAIPEDItWCIpEJBSIAusWvwEAAACNTCQU V1FV6NcWAACDxAyL2DvfdBCLRgwMIIlGDIPI/19eXVvDi0QkFCX/AAAAX15dW8MMIF+JRgxeXYPI /1vDkJCQoQDRAAFWhcB1B7gAAgAA6wqD+BR9CrgUAAAAowDRAAFqBFDo+BgAAIPECKPkwAABhcB1 LmoEahTHBQDRAAEUAAAA6NkYAACDxAij5MAAAYXAdQ9qGuhG2f//oeTAAAGDxAQz0rl4lQAB6wWh 5MAAAYkMEIPBIIPCBIH5+JcAAXzqM8C6iJUAAYvIi/DB+QWD5h+LDI0g0QABiwzxg/n/dASFyXUG xwL/////g8IgQIH66JUAAXzRXsOQkJCQkJCQ6FsPAACgMLwAAYTAdAXp7RgAAMOQkJCQkJCQkJCQ kJChkL8AAYPsCIXAU3Uei0QkEIP4QQ+M3wAAAIP4Wg+P1gAAAIPAIFuDxAjDi1wkEIH7AAEAAH0s gz1QugABAX4NagFT6AgZAACDxAjrC6E4uAABigRYg+ABhcB1B4vDW4PECMOLFTi4AAGLw8H4CIvI geH/AAAA9kRKAYB0FIhEJBCIXCQRxkQkEgC4AgAAAOsOiFwkEMZEJBEAuAEAAABqAWoAjUwkDGoD UY1UJCBQoZC/AAFSaAABAABQ6EABAACDxCCFwHUHi8Nbg8QIw4P4AXUOi0QkBCX/AAAAW4PECMOL RCQFi0wkBCX/AAAAgeH/AAAAweAIC8Fbg8QIw5CQUVaLdCQMhfZ0PY1EJAyNTCQEUFFW6CYHAACD xAyFwHQWi1QkDFCLRCQIUlDobwcAAIPEDF5Zw4sNBNEAAVZqAFH/FYgQAAFeWcOQkJCQkJChyL8A AYtMJARQUegQAAAAg8QIw5CQkJCQkJCQkJCQkFaLdCQIg/7gV3c0hfZ1Bb4BAAAAi3wkEIP+4HcL VugtAAAAg8QE6wIzwIXAdROF/3QPVuhIGAAAg8QEhcB12TPAX17DkJCQkJCQkJCQkJCQi0QkBFaN cA+hHLgAAYPm8DvwdxKLzsHpBFHoIQcAAIPEBIXAdRCLFQTRAAFWagBS/xWMEAABXsOQkJCQkJCQ kKGovwABU4sdkBAAAVVWV4XAdUlqAGoAagFoCBoAAWgAAQAAagD/FZQQAAGFwHQHuAEAAADrIWoA agBqAWgEGgABaAABAABqAP/ThcAPhMwBAAC4AgAAAKOovwABi3QkIIX2fheLfCQcVlfowQEAAIvw oai/AAGDxAjrBIt8JByD+AJ1HYtEJCiLTCQki1QkGFCLRCQYUVZXUlD/019eXVvDg/gBD4XdAAAA i2wkLMdEJCAAAAAAhe11DIsNoL8AAYlMJCyL6YtUJDBqAPfaG9JqAIPiCFZCV1JV/xVEEAABi/iF /3UFX15dW8ONBD9Q6Fz+//+L2IPEBIXbdQVfXl1bw4tMJBxXU1ZRagFV/xVEEAABhcAPhO0AAACL bCQYi1QkFGoAagBXU1VS/xWUEAABi/CF9g+EzQAAAPfFAAQAAHRJi0QkKIXAdCQ78A+PtQAAAItM JBRQi0QkKFBXU1VR/xWUEAABhcAPhJkAAABT6Iv9//+LVCQkg8QEUuh+/f//g8QEi8ZfXl1bw40U NlLou/3//4PEBIlEJCCFwHRoi0wkFFZQV1NVUf8VlBAAAYXAdFSLRCQoagCFwGoAdSKLVCQoi0Qk NGoAagBWUmggAgAAUP8VVBAAAYvwhfZ0KOuNi0wkLItUJChQi0QkOFFWUmggAgAAUP8VVBAAAYvw hfYPhWf///9T6PL8//+LTCQkg8QEUejl/P//g8QEX15dM8Bbw5CQkJCQkJCQkJCQi1QkCFaLdCQI hdJXi8aNSv90DYA4AHQIQIv5SYX/dfOAOAB1BSvGX17DX16LwsOQUaGwvwABU1VWizWYEAABVzP/ O8d1Jo1EJBJQagFoCBoAAWoB/xWcEAABhcAPhNoAAAC4AQAAAKOwvwABg/gCdSqLRCQsO8d1BaGQ vwABi1QkJItMJCBSi1QkIFGLTCQgUlFQ/9ZfXl1bWcOD+AEPhZIAAACLXCQoiXwkLDvfdQaLHaC/ AAGLRCQwi2wkIItUJBxX99gbwFeD4AhVQFJQU/8VRBAAAYvwhfZ0S1ZqAugsEwAAi/iDxAiF/3Q6 i0wkHFZXVVFqAVP/FUQQAAGFwHQli1QkJFJQi0QkIFdQ/xWcEAABV4vw6LT7//+DxASLxl9eXVtZ w4t0JCxX6J/7//+DxASLxl9eXVtZw41MJBJRagFoBBoAAWoBV//WhcB0D7gCAAAAo7C/AAHpDP// /19eXTPAW1nDkJCQkJCQkJChCJgAAVVWg/j/V3UHvfiXAAHrHaEE0QABaCAgAABqAFD/FYwQAAGL 6IXtD4QrAQAAiz2gEAABagRoACAAAGgAAEAAagD/14vwhfYPhPQAAABqBGgAEAAAaAAAAQBW/9eF wA+EzwAAAIH9+JcAAXUoofiXAAGFwHUKxwX4lwAB+JcAAaH8lwABhcB1J8cF/JcAAfiXAAHrG8dF APiXAAGLDfyXAAGJTQSJLfyXAAGLVQSJKo2GAABAAI1NGI2VmAAAAIlFFIl1EIlNCIlVDDPAv/EA AAAz0oP4EA+dwkqDwQgj10pAiVH4iXn8PQAEAAB847kAQAAAM8CL/vOri0UQBQAAAQA78HMoufAA AACw/41WCIlOBIkWiIb4AAAAi1UQgcYAEAAAgcIAAAEAO/Jy34vFX15dw2gAgAAAagBW/xUAEAAB gf34lwABdA+hBNEAAVVqAFD/FYgQAAFfXjPAXcOQkJCQkJCQkJCQkJCQkFaLdCQIaACAAABqAItG EFD/FQAQAAE5NRi4AAF1CYtOBIkNGLgAAYH++JcAAXQgi1YEiwZWagCJAosOi1YEiVEEoQTRAAFQ /xWIEAABXsPHBQiYAAH/////XsOQkJCQkFNVVleLPfyXAAGDfxD/D4SgAAAAM+2NtxAgAAC7APA/ AIE+8AAAAHVHi0cQaABAAAADw2gAEAAAUP8VABAAAYXAdC3HBv////+LFbS/AAFKiRW0vwABi0cM hcB0BDvGdgOJdwyLRCQURUiJRCQUdA2B6wAQAACD7giF232ki9eLfwSF7XQug3oY/3UouAEAAACN SiCDOf91C0CDwQg9AAQAAHzwPQAEAAB1CVLo7/7//4PEBDs9/JcAAXQMi0QkFIXAD49C////X15d W8OQkJCLTCQEuPiXAAE7SBB2BTtIFHILiwA9+JcAAXQ66+v2wQ91M4vRgeL/DwAAgfoAAQAAciOL VCQIiQKLVCQMi8ElAPD//yvIiQKB6QABAADB+QSNRAEIwzPAw5CQkJCQkJCLRCQEi0wkCFYz0itI EMH5DIt0yBiNRMgYi0wkEIoRA/KJMMYBAIsIx0AE8QAAAIH58AAAAHUaobS/AAFAg/ggo7S/AAF1 CmoQ6IL+//+DxARew5CQkJCQkJCQkJCQkJBRiw0YuAABU4tcJAxVVleJTCQQi0EQg/j/D4SFAAAA i3kIjakYIAAAi/cr8YPuGMH+A8HmDAPwO/1zLosHO8N8GzlfBHYWU1BW6PIBAACDxAyFwHVji0wk EIlfBIPHCIHGABAAADv9ctKLaQiLeRCNcRg79XMuiwY7w3wbOV4EdhZTUFfotwEAAIPEDIXAdUGL TCQQiV4Eg8YIgccAEAAAO/Vy0osJoRi4AAE7yIlMJBB0N+lb////i0wkEIkNGLgAAYsXK9OJF4l5 CF9eXVtZw4tMJBCJDRi4AAGLFivTiRaJcQhfXl1bWcO9+JcAAYPJ/zlNEHQHi0UMhcB1EYttAIH9 +JcAAQ+E4AAAAOvji0UMi3UQi/iJRCQYK/2LEIPvGMH/A8HnDAP+M/Y70XUQg/4QfQuLUAiDwAhG O9F08IvGagTB4AxoABAAAFBXiUQkIP8VoBAAATvHD4XLAAAAi1QkGItEJBAzyYX2i8p+Mo1HBI1Q BMcA8AAAAIlQ/MaA9AAAAP/HAfAAAADHQQTxAAAABQAQAACDwQhOddWLVCQYjYUYIAAAiS0YuAAB O8hzDoM5/3QHg8EIO8hy9DvIG8AjwYlFDIhfCIlVCIsKK8uJCotHBCvDjUwfCIlHBIkPjYcAAQAA X15dW1nD6K76//+FwHQ1i0gQiFkIjVQZCKMYuAABiRG68AAAACvTgeP/AAAAiVEEi1AYK9OJUBiN gQABAABfXl1bWcNfXl0zwFtZw5CQkJCQkJCQkJCQkJCLVCQMU1VWV4t8JBSLRwSLDzvCiUwkFIvx jZ/4AAAAcjqNBBGIETvDcxCLN4tHBAPyK8KJN4lHBOsMjVcIx0cEAAAAAIkXjQR/jQSAi9CNQQjB 4AQrwl9eXVvDA8GAOAB0AovwjQQWO8OLXCQYc3WKBoTAdTyAfgEAjUYBuQEAAAB1B0BBgDgAdPk7 ynM5i2wkFDv1dQmJTwSL8IvN6xkr2TvaD4LCAAAAi0wkFIvw6wcl/wAAAAPwjSwWjYf4AAAAO+hy qusdjQQWjZ/4AAAAO8NzCSvKiQeJTwTreY1PCIkP62uNbwiL9Tvxc36NDBaNh/gAAAA7yHNxigaE wHUjgH4BAI1GAbkBAAAAdQdAQYA4AHT5O8pzHivZO9pyTIvw6wcl/wAAAAPwO3QkFHK9M8BfXl1b w40EFo2f+AAAADvDcwkryokHiU8E6wmJL8dHBAAAAACNBH+IFo0UgI1GCMHgBCvCX15dW8NfXl0z wFvDkJCQkJCQkJCQkJCQkJChuL8AAVMz21aFwFd1Qmg8GgAB/xWoEAABi/CF9nRqiz2kEAABaDAa AAFW/9eFwKO4vwABdFNoIBoAAVb/12gMGgABVqO8vwAB/9ejwL8AAaG8vwABhcB0BP/Qi9iF23QO ocC/AAGFwHQFU//Qi9iLRCQYi0wkFItUJBBQUVJT/xW4vwABX15bw19eM8Bbw5CLTCQMV4XJdHpW U4vZi3QkFPfGAwAAAIt8JBB1B8HpAnVv6yGKBkaIB0dJdCWEwHQp98YDAAAAdeuL2cHpAnVRg+MD dA2KBkaIB0eEwHQvS3Xzi0QkEFteX8P3xwMAAAB0EogHR0kPhIoAAAD3xwMAAAB17ovZwekCdWyI B0dLdfpbXotEJAhfw4kXg8cESXSvuv/+/n6LBgPQg/D/M8KLFoPGBKkAAQGBdN6E0nQshPZ0HvfC AAD/AHQM98IAAAD/dcaJF+sYgeL//wAAiRfrDoHi/wAAAIkX6wQz0okXg8cEM8BJdAozwIkHg8cE SXX4g+MDdYWLRCQQW15fw8zMi0QkBIsNINIAATvBcgMzwMOLyIPgH8H5BYsUjSDRAAGKRMIEg+BA w5CQkJCQkJCQVot0JAiF9nULVujBAAAAg8QEXsNW6DYAAACDxASFwHQFg8j/XsOLRgz2xEB0EotG EFDomQ4AAIPEBPfYG8BewzPAXsOQkJCQkJCQkJCQkJBTVot0JAwz21eLRgyLyIPhA4D5AnVGqQgB AAB0P4tGCIs+K/iF/340i1YQV1BS6L0GAACDxAw7x4tGDHUXqIB0GyT9iV4EiUYMi0YIiQaLw19e W8MMIIPL/4lGDItGCMdGBAAAAACJBl+Lw15bw5CQagHoCQAAAIPEBMOQkJCQkKEA0QABU4tcJAhV Vlcz7TP/M/aFwH5NoeTAAAGLBLCFwHQ3i0gM9sGDdC+D+wF1EVDo+v7//4PEBIP4/3QcResZhdt1 FfbBAnQQUOjg/v//g8QEg/j/dQIL+KEA0QABRjvwfLOD+wGLxXQCi8dfXl1bw5CQkJCQkJCQkJCQ kJCQi0QkBIXAdQHDiw2QvwABhcl1FGaLTCQIZoH5/wB3RIgIuAEAAADDixVQugABjUwkBFGLDaC/ AAFqAFJQjUQkGGoBUGggAgAAUcdEJCQAAAAA/xVUEAABhcB0CItMJASFyXQNxwXwuwABKgAAAIPI /8OQkJCQkJCQkJCQkJCQkJBTVotEJBgLwHUYi0wkFItEJBAz0vfxi9iLRCQM9/GL0+tBi8iLXCQU i1QkEItEJAzR6dHb0erR2AvJdfT384vw92QkGIvIi0QkFPfmA9FyDjtUJBB3CHIHO0QkDHYBTjPS i8ZeW8IQAMzMzMzMzMzMU4tEJBQLwHUYi0wkEItEJAwz0vfxi0QkCPfxi8Iz0utQi8iLXCQQi1Qk DItEJAjR6dHb0erR2AvJdfT384vI92QkFJH3ZCQQA9FyDjtUJAx3CHIOO0QkCHYIK0QkEBtUJBQr RCQIG1QkDPfa99iD2gBbwhAAzMzMzMzMzMzMzMyD7BSLTCQcU1VWsoAz9oTKV8dEJBgMAAAAiXQk HHQLiXQkIMZEJBMQ6w3HRCQgAQAAAMZEJBMA9sWAdRX2xUB1DIE90L8AAQCAAAB0BAhUJBOLwYPg AyvGdB5IdBFID4XtAgAAx0QkFAAAAMDrEsdEJBQAAABA6wjHRCQUAAAAgItEJDCDwPCD+DAPh8EC AAAz24qYAGQAAf8knexjAAEz2+sTuwEAAADrDLsCAAAA6wW7AwAAAIvBJQAHAAA9AAEAAH8SdAk7 xnQ86YICAAC9BAAAAOtVPQADAAB/FXQMPQACAAB0QOlmAgAAvQIAAADrOT0ABQAAfxR0JD0ABAAA D4VLAgAAvQMAAADrHj0ABgAAdBI9AAcAAA+FMgIAAL0BAAAA6wW9BQAAAPbFAb+AAAAAdBeLNfi7 AAGLRCQ099YjxoTCdQW/AQAAAPbBQHQTi0QkFIHPAAAABA0AAAEAiUQkFPbFEHQGgc8AAQAA9sEg dAiBzwAAAAjrC/bBEHQGgc8AAAAQ6LQPAACL8IP+/3UexwXwuwABGAAAAMcF9LsAAQAAAAALwF9e XVuDxBTDi1QkFItEJChqAFeNTCQgVVFTUlD/FbAQAAGL+IP//3UZ/xUQEAABUOjCEQAAg8QEC8df Xl1bg8QUw1f/FWwQAAGFwHUhV/8VrBAAAf8VEBAAAVDolxEAAIPEBIPI/19eXVuDxBTDg/gCdQiK RCQTDEDrC4P4A3UKikQkEwwIiEQkE1dW6MYPAACKXCQbi86AywGL/sH5BYhcJBuD5x+KRCQbixSN INEAAY0cjSDRAAGKyIPECMHnA4DhSIhEFwSITCQoD4WvAAAAqIAPhKcAAAD2RCQsAg+EnAAAAGoC av9W6CkBAACL6IPEDIP9/3UfgT30uwABgwAAAHR8VuitDQAAg8QEC8VfXl1bg8QUw41EJDBqAVBW xkQkPADoLgsAAIPEDIXAdSqAfCQwGnUjVVbomQkAAIPECIP4/3UUVuhrDQAAg8QEg8j/X15dW4PE FMNqAGoAVuizAAAAg8QMg/j/dRRW6EUNAACDxASDyP9fXl1bg8QUw4pEJCiEwHUW9kQkLAh0D4sL jUQPBIpMDwSAySCICIvGX15dW4PEFMOJNfS7AAFfXl3HBfC7AAEWAAAAg8j/W4PEFMMfYQABI2EA ASphAAExYQAB0WMAAQAEBAQEBAQEBAQEBAQEBAQBBAQEBAQEBAQEBAQEBAQEAgQEBAQEBAQEBAQE BAQEBAOQkJCQkJCQkJCQkJCQkJCLRCQEiw0g0gABU1Y7wVcPg40AAACLyIvwwfkFg+YfixSNINEA AY0cjSDRAAHB5gP2RDIEAXRrUOhTDwAAg8QEg/j/dRDHBfC7AAEJAAAAC8BfXlvDi0wkGItUJBRR agBSUP8VtBAAAYv4g///dQj/FRAQAAHrAjPAhcB0EFDoXQ8AAIPEBIPI/19eW8OLA4pMMASNRDAE gOH9iAiLx19eW8NfXscF8LsAAQkAAADHBfS7AAEAAAAAg8j/W8OQkJCLRCQEiw0g0gABgewcBAAA O8FTVVZXD4ORAQAAi8iL8MH5BYPmH4sUjSDRAAGNPI0g0QABweYDiXwkJIl0JBSKTBYE9sEBD4Rh AQAAi5wkOAQAADPtO92JbCQQiWwkIHUNM8BfXl1bgcQcBAAAw/bBIHQMagJVUOjE/v//g8QMiwcD xvZABIAPhFEBAACLrCQ0BAAAx0QkGAAAAACF24v9D4aDAAAAjUQkKIvPK807y3Moig9HgPkKdQ2L dCQgxgANRkCJdCQgiAhAi9CNTCQoK9GB+gAEAAB80IvwjVQkKI1EJBwr8otUJCRqAFCNTCQwiwJW UYtMJCSLFAFS/xWEEAABhcAPhMQAAACLRCQci1QkEAPQO8aJVCQQfAiLxyvFO8NygYt0JBSLRCQQ hcB1bYtEJBiFwHQ5g/gFdR2j9LsAAccF8LsAAQkAAACDyP9fXl1bgcQcBAAAw1Dovw0AAIPEBIPI /19eXVuBxBwEAADDi0wkJIsR9kQWBEB0E4B9ABp1DTPAX15dW4HEHAQAAMPHBfC7AAEcAAAA6xkr RCQgX15dW4HEHAQAAMPHBfC7AAEJAAAAX15dxwX0uwABAAAAAIPI/1uBxBwEAADD/xUQEAABiUQk GOlH////ixCNTCQcVYusJDgEAABRU1VS/xWEEAABhcB0FYtEJBzHRCQYAAAAAIlEJBDpGv////8V EBAAAYlEJBjpC////5CQoYC/AAFoABAAAECjgL8AAehb6f//i0wkCIPEBIXAiUEIi0EMdBmLUQgM CIlBDMdBGAAQAACJEcdBBAAAAADDDATHQRgCAAAAiUEMjUEUi9CJQQiJEcdBBAAAAADDkJCQU1VW i3QkFA+vdCQQg/7gV3cRhfZ2CIPGD4Pm8OsFvhAAAACLHYwQAAEz0oP+4HdCOzUcuAABdyiLxsHo BFDoffD//4vQg8QEhdJ0GIvOM8CL6Yv6wekC86uLzYPhA/OqhdJ1LYsNBNEAAVZqCFH/04vQhdJ1 G6HIvwABhcB0ElboKwEAAIPEBIXAdZ1fXl1bw19eXYvCW8OQkJCQkJCQkKEA0QABVle+AwAAADP/ O8Z+UVOzg6HkwAABiwSwhcB0N4RYDHQPUOhEDAAAg8QEg/j/dAFHg/4UfB6LDeTAAAGLFLFS6Nfn //+h5MAAAYPEBMcEsAAAAAChANEAAUY78HyzW4vHX17DkJCQkJCQkJBRi0wkCFaNQQE9AAEAAHcV ixU4uAABM8BmiwRKi0wkECPBXlnDizU4uAABi8HB+AiL0IHi/wAAAPZEVgGAdBSIRCQMiEwkDcZE JA4AuAIAAADrDohMJAzGRCQNALgBAAAAagFqAI1MJAxqAFGNVCQcUFJqAeiX6v//g8QchcB1A15Z w4tEJASLTCQQJf//AABeI8FZw5CQkJCQkJCQkJCQocy/AAGFwHQUi0wkBFH/0IPEBIXAdAa4AQAA AMMzwMNVi+xXVot1DItNEIt9CIvBi9EDxjv+dgg7+A+CeAEAAPfHAwAAAHUUwekCg+IDg/kIcinz pf8klZhqAAGLx7oDAAAAg+kEcgyD4AMDyP8khbBpAAH/JI2oagABkP8kjSxqAAGQwGkAAexpAAEQ agABI9GKBogHikYBiEcBikYCwekCiEcCg8YDg8cDg/kIcszzpf8klZhqAAEui8Aj0YoGiAeKRgHB 6QKIRwGDxgKDxwKD+QhypvOl/ySVmGoAAZAj0YoGiAdGwekCR4P5CHKM86X/JJWYagABLovAj2oA AXxqAAF0agABbGoAAWRqAAFcagABVGoAAUxqAAGLRI7kiUSP5ItEjuiJRI/oi0SO7IlEj+yLRI7w iUSP8ItEjvSJRI/0i0SO+IlEj/iLRI78iUSP/I0EjQAAAAAD8AP4/ySVmGoAAYvAqGoAAbBqAAG8 agAB0GoAAYtFCF5fycOQigaIB4tFCF5fycOQigaIB4pGAYhHAYtFCF5fycMui8CKBogHikYBiEcB ikYCiEcCi0UIXl/Jw5CNdDH8jXw5/PfHAwAAAHUkwekCg+IDg/kIcg3986X8/ySVMGwAAYvA99n/ JI3gawABLovAi8e6AwAAAIP5BHIMg+ADK8j/JIU4awAB/ySNMGwAAZBIawABaGsAAZBrAAGKRgMj 0YhHA07B6QJPg/kIcrb986X8/ySVMGwAAS6LwIpGAyPRiEcDikYCwekCiEcCg+4Cg+8Cg/kIcoz9 86X8/ySVMGwAAZCKRgMj0YhHA4pGAohHAopGAcHpAohHAYPuA4PvA4P5CA+CWv////3zpfz/JJUw bAABLovA5GsAAexrAAH0awAB/GsAAQRsAAEMbAABFGwAASdsAAGLRI4ciUSPHItEjhiJRI8Yi0SO FIlEjxSLRI4QiUSPEItEjgyJRI8Mi0SOCIlEjwiLRI4EiUSPBI0EjQAAAAAD8AP4/ySVMGwAAYvA QGwAAUhsAAFYbAABbGwAAYtFCF5fycOQikYDiEcDi0UIXl/Jwy6LwIpGA4hHA4pGAohHAotFCF5f ycOQikYDiEcDikYCiEcCikYBiEcBi0UIXl/Jw8zMzMzMzMzMzMzMi0QkBIsNINIAATvBcz+LyIvQ wfkFg+IfiwyNINEAAfZE0QQBdCdQ6BQHAACDxARQ/xW4EAABhcB1CP8VEBAAAesCM8CFwHQSo/S7 AAHHBfC7AAEJAAAAg8j/w5CQkJCQagLoCbv//4PEBMOQkJCQkLgEEAAA6Ba9//+hINIAAVOLnCQM EAAAVTPtVjvYVw+DPgEAAIvDi8vB+AWD4R+LFIUg0QAB9kTKBAEPhCIBAABqAVVT6Pf2//+L+IPE DIP//4l8JBAPhBEBAABqAlVT6Nz2//+DxAyD+P8PhPwAAACLjCQcEAAAi/Er8IX2D46FAAAAuQAE AAAzwI18JBRoAIAAAPOrU+h1BwAAg8QIi/iB/gAQAAC4ABAAAH0Ci8ZQjUQkGFBT6EX3//+DxAyD +P90CCvwhfZ+GOvVgz30uwABBXUKxwXwuwABDQAAAIPN/1dT6CgHAACLfCQYg8QIagBXU+hI9v// g8QMi8VfXl1bgcQEEAAAw30/agBRU+gt9v//g8QMU+i0BQAAg8QEUP8VvBAAAYvo990b7ffdTYP9 /3UVxwXwuwABDQAAAP8VEBAAAaP0uwABagBXU+ju9f//g8QMi8VfXl1bgcQEEAAAw8cF8LsAAQkA AABfXl2DyP9bgcQEEAAAw5CQkJCQkKEg0gABg+wMU4tcJBRVVjvYVw+DHQIAAIvDg+MfwfgFweMD iwyFINEAAY00hSDRAAGJdCQUjQQLiUQkEIpQBPbCAQ+E7QEAAItMJCiLfCQkM+2Lx4XJD4TPAQAA 9sICD4XGAQAA9sJIdB6LVCQQilIFgPoKdBKIF4sWjUcBvQEAAABJxkQTBQqNVCQQagBSUVCLBosM A1H/FcAQAAGFwHVI/xUQEAABg/gFdRqj9LsAAccF8LsAAQkAAACDyP9fXl1bg8QMw4P4bXUKM8Bf Xl1bg8QMw1DoxQQAAIPEBIPI/19eXVuDxAzDiwaLVCQQA+qNTAMEikQDBKiAD4QgAQAAhdJ0CYA/ CnUEDATrAiT7iAGLRCQkA+iL9zvFiWwkGA+D9QAAAIoHPBoPhNUAAAA8DXQJiAZGR+msAAAATTv9 cxuAfwEKdQuDxwLGBgrplQAAAMYGDUZH6YwAAACLRCQUM+2NTCQQVVGLCI1UJDBqAVKLFAtSR/8V wBAAAYXAdQj/FRAQAAGL6IXtdViLRCQQhcB0UItMJBSLAfZEAwRIdBiKRCQoPAp1BIgG6zrGBg2L CUaIRAsF6y87dCQkdQyAfCQoCnUFxgYK6xyLVCQgagFq/1Lo5vP//4pEJDSDxAw8CnQExgYNRots JBg7/Q+CMf///yt0JCSL7ovFX15dW4PEDMOLRCQUiwiKRAsEqECNXAsEdQQMAogDK3QkJIvui8Vf Xl1bg8QMwzPAX15dW4PEDMNfXl3HBfC7AAEJAAAAxwX0uwABAAAAAIPI/1uDxAzDkJCQkJCQkJCQ kJCQoSDSAAFTVVaLdCQQVzvwD4OhAAAAi8aL/sH4BYPnH4sMhSDRAAGNLIUg0QABwecD9kQ5BAF0 f1boswIAAIPEBIP4/3RCg/4BdAWD/gJ1GmoC6JoCAACDxASL2GoB6I4CAACDxAQ7w3QeVuiBAgAA g8QEUP8VrBAAAYXAdQr/FRAQAAGL2OsCM9tW6MEBAACLVQCDxASF28ZEOgQAdBFT6JwCAACDxASD yP9fXl1bwzPAX15dW8NfXl3HBfC7AAEJAAAAxwX0uwABAAAAAIPI/1vDkJCQkJCQkJCQkJCQkJBT VVZXg83/M/Yz/7kg0QABswGLAYXAdESNkAABAAA7wnMfhFgEdAmDwAg7wnL06xHHAP////+LESvC wfgDA8eL6IP9/3Vvg8EERoPHIIH5INIAAXy9i8VfXl1bw2gAAQAA6Gre//+DxASFwHRIiz0g0gAB jYgAAQAAg8cgO8GJBLUg0QABiT0g0gABcyOxCsZABADHAP////+ISAWLFLUg0QABg8AIgcIAAQAA O8Jy38HmBYvuX4vFXl1bw5CQkJCLRCQEiw0g0gABU1Y7wVdzd4vIi/DB+QWD5h+LFI0g0QABjTyN INEAAcHmA4M8Mv91VosNPJMAAYtcJBSD+QF1PIPoAHQuSHQXSHUxU2r0/xXEEAABiweJHDAzwF9e W8NTavX/FcQQAAGLB4kcMDPAX15bw1Nq9v8VxBAAAYsHiRwwM8BfXlvDX17HBfC7AAEJAAAAxwX0 uwABAAAAAIPI/1vDkJCQkJCQkJCQkJCQkItEJASLDSDSAAFTVjvBV3Noi8iL8MH5BYPmH4sUjSDR AAGNPI0g0QABweYDilwyBI0MMroBAAAAhNp0PYM5/3Q4ORU8kwABdSGD6AB0Ekh0CUh1FmoAavTr CmoAavXrBGoAavb/FcQQAAGLB8cEMP////8zwF9eW8NfXscF8LsAAQkAAADHBfS7AAEAAAAAg8j/ W8OQkJCQkJCQkJCQkJCLRCQEiw0g0gABO8FzHovIg+AfwfkFixSNINEAAYpMwgT2wQGNBMJ0A4sA w8cF8LsAAQkAAADHBfS7AAEAAAAAg8j/w5CQkJCQkJCQkJCQkItUJASJFfS7AAEzybhgugABOxB0 RYPACEE9yLsAAXLxg/oTchCD+iR3C8cF8LsAAQ0AAADDgfq8AAAAchKB+soAAADHBfC7AAEIAAAA dgrHBfC7AAEWAAAAw4sEzWS6AAGj8LsAAcOQkJCQkJCQkJBWi3QkCFeDz/+LRgyoQHQNx0YMAAAA AIPI/19ew6iDdEpW6Fnp//+DxASL+FbozgAAAItGEIPEBFDoEvz//4PEBIXAfQ+Dz//HRgwAAAAA i8dfXsOLRhyFwHQQUOhP2///g8QEx0YcAAAAAIvHx0YMAAAAAF9ew5CQkJCQkJCQkItEJASLDSDS AAE7wVZzYIvIg+AfwfkFixSNINEAAYpMwgT2wQGNVMIEdESLdCQMisElgAAAAIH+AIAAAHUFgOF/ 6wuB/gBAAAB1FYDJgPfYG8CICiUAwP//BQCAAABew8cF8LsAARYAAACDyP9ew8cF8LsAAQkAAACD yP9ew5CQVot0JAiLRgyog3QlqAh0IYtGCFDol9r//4tGDIPEBCX3+///iUYMM8CJBolGCIlGBF7D kJCQkJCQkJCQkJCQkP8lgBAAAf8l8BAAASx2AAAAAAAAAAAAAHp6AAAAEAAA+HYAAAAAAAAAAAAA cnsAAMwQAAAcdwAAAAAAAAAAAACmewAA8BAAAAAAAAAA5AABAAAAAAAAAAAAAAAAWHkAADR3AABA dwAAUncAAGp3AAB6dwAAiHcAAJR3AACmdwAAvncAANB3AADedwAA7HcAAAB4AAAUeAAAMHgAAEZ4 AABgeAAAdngAAJB4AACoeAAAwngAANh4AADkeAAA7ngAAPp4AAAMeQAAHHkAACp5AAA8eQAASnkA ACR3AABmeQAAcnkAAH55AACKeQAAlnkAAKZ5AAC2eQAAyHkAANp5AADqeQAA/HkAAAx6AAAaegAA KHoAADp6AABOegAAXnoAAGp6AAAAAAAAHnsAAKh6AADEegAA5HoAAAB7AACIegAAQnsAAFp7AAAA AAAAgHsAAAAAAACeAlNldExhc3RFcnJvcgAA6QFMb2NhbEZyZWUAvgBGb3JtYXRNZXNzYWdlQQAA lwFHZXRXaW5kb3dzRGlyZWN0b3J5QQAALQFHZXRMYXN0RXJyb3IAAOUBTG9jYWxBbGxvYwAAPgNs c3RybGVuQQAAowBGaW5kRmlyc3RGaWxlQQAABwFHZXRDdXJyZW50RGlyZWN0b3J5QQAA2gBHZXRD b21tYW5kTGluZUEAjgFHZXRWZXJzaW9uAACMAEV4aXRQcm9jZXNzAM0CVGVybWluYXRlUHJvY2Vz cwAACQFHZXRDdXJyZW50UHJvY2VzcwDdAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAOAFHZXRN b2R1bGVGaWxlTmFtZUEAAMEARnJlZUVudmlyb25tZW50U3RyaW5nc0EAAwJNdWx0aUJ5dGVUb1dp ZGVDaGFyAMIARnJlZUVudmlyb25tZW50U3RyaW5nc1cAGQFHZXRFbnZpcm9ubWVudFN0cmluZ3MA GwFHZXRFbnZpcm9ubWVudFN0cmluZ3NXAAAIA1dpZGVDaGFyVG9NdWx0aUJ5dGUAzwBHZXRDUElu Zm8AyQBHZXRBQ1AAAEYBR2V0T0VNQ1AAAJoCU2V0SGFuZGxlQ291bnQAAGgBR2V0U3RkSGFuZGxl AAAoAUdldEZpbGVUeXBlAGYBR2V0U3RhcnR1cEluZm9BALgBSGVhcERlc3Ryb3kAtgFIZWFwQ3Jl YXRlAAD1AlZpcnR1YWxGcmVlAFkCUnRsVW53aW5kABUDV3JpdGVGaWxlALoBSGVhcEZyZWUAALQB SGVhcEFsbG9jANwBTENNYXBTdHJpbmdBAADdAUxDTWFwU3RyaW5nVwAAaQFHZXRTdHJpbmdUeXBl QQAAbAFHZXRTdHJpbmdUeXBlVwAA8QJWaXJ0dWFsQWxsb2MAAFMBR2V0UHJvY0FkZHJlc3MAAN8B TG9hZExpYnJhcnlBAAAeAENsb3NlSGFuZGxlADcAQ3JlYXRlRmlsZUEAlwJTZXRGaWxlUG9pbnRl cgAAuQBGbHVzaEZpbGVCdWZmZXJzAACOAlNldEVuZE9mRmlsZQAAPQJSZWFkRmlsZQAAqgJTZXRT dGRIYW5kbGUAAEtFUk5FTDMyLmRsbAAAOgFTZXR1cERpRGVzdHJveURldmljZUluZm9MaXN0AAAf AVNldHVwRGlDYWxsQ2xhc3NJbnN0YWxsZXIAigFTZXR1cERpU2V0Q2xhc3NJbnN0YWxsUGFyYW1z QQCSAVNldHVwRGlTZXRTZWxlY3RlZERldmljZQAAWQFTZXR1cERpR2V0RGV2aWNlSW5zdGFuY2VJ ZEEAXgFTZXR1cERpR2V0RGV2aWNlUmVnaXN0cnlQcm9wZXJ0eUEAPQFTZXR1cERpRW51bURldmlj ZUluZm8ASgFTZXR1cERpR2V0Q2xhc3NEZXZzQQAAU0VUVVBBUEkuZGxsAAALAFVwZGF0ZURyaXZl ckZvclBsdWdBbmRQbGF5RGV2aWNlc0EAAG5ld2Rldi5kbGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAGBOAAEAAAAAAAAAACBPAAEAAAAAAAAAAAAAAAAAAAAAAAAAAE5FVCouSU5G AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUENJXFZFTl84MDg2 JkRFVl8xMjI5JkNDXzAyMDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAFBDSVxWRU5fODA4NiZERVZfMTAyOSZDQ18wMjAwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQQ0lcVkVOXzgwODYm REVWXzI0NDkmQ0NfMDIwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAUENJXFZFTl84MDg2JkRFVl8xMjA5JkNDXzAyMDAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBDSVxWRU5fODA4NiZE RVZfNTIwMSZDQ18wMjAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABQQ0lcVkVOXzgwODYmREVWXzEwMzAmQ0NfMDIwMAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUENJXFZFTl84MDg2JkRF Vl8xMDAwJkNDXzAyMDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAFBDSVxWRU5fODA4NiZERVZfMTAwMSZDQ18wMjAwAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQQ0lcVkVOXzgwODYmREVW XzEwMDMmQ0NfMDIwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAUENJXFZFTl84MDg2JkRFVl8xMDA0JkNDXzAyMDAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABAAAAAAQAAAFAsAAEBAAAABQAAwAsAAAAAAAAAHQAAwAQAAAAAAAAAlgAAwAQA AAAAAAAAjQAAwAgAAAAAAAAAjgAAwAgAAAAAAAAAjwAAwAgAAAAAAAAAkAAAwAgAAAAAAAAAkQAA wAgAAAAAAAAAkgAAwAgAAAAAAAAAkwAAwAgAAAAAAAAAAwAAAAcAAAAKAAAAjAAAAAECBAgAAAAA pAMAAGCCeYIhAAAAAAAAAKbfAAAAAAAAoaUAAAAAAACBn+D8AAAAAEB+gPwAAAAAqAMAAMGj2qMg AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACB/gAAAAAAAED+AAAAAAAAtQMAAMGj2qMgAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACB/gAAAAAAAEH+AAAAAAAAtgMAAM+i5KIaAOWi6KJbAAAAAAAAAAAAAAAA AAAAAACB/gAAAAAAAEB+of4AAAAAUQUAAFHaXtogAF/aatoyAAAAAAAAAAAAAAAAAAAAAACB09je 4PkAADF+gf4AAAAA/////wAKAAAAEAAAIAWTGQAAAAAAAAAAAAAAAAAAAAACAAAAABkAAQgAAADU GAABCQAAAKgYAAEKAAAAhBgAARAAAABYGAABEQAAACgYAAESAAAABBgAARMAAADYFwABGAAAAKAX AAEZAAAAeBcAARoAAABAFwABGwAAAAgXAAEcAAAA4BYAAXgAAADQFgABeQAAAMAWAAF6AAAAsBYA AfwAAACsFgAB/wAAAJwWAAH8GQAB7BkAAQDBAAEAAAAAAMEAAQEBAAAAAAAAAAAAAAAQAAAAAAAA AAAAAAAAAAAAAAAAAgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4lwAB+JcAARCYAAEQmAAB//// ///////wAAAA8QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+JcA AeABAADwbAAB8GwAAfBsAAHwbAAB8GwAAfBsAAFCuAABQrgAAQAAIAAgACAAIAAgACAAIAAgACAA KAAoACgAKAAoACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQ ABAAEAAQABAAEAAQABAAEAAQABAAhACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEA gQCBAIEAgQCBAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQ ABAAEACCAIIAggCCAIIAggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIA EAAQABAAEAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAu AAAAAQAAAAAAAAABAAAAFgAAAAIAAAACAAAAAwAAAAIAAAAEAAAAGAAAAAUAAAANAAAABgAAAAkA AAAHAAAADAAAAAgAAAAMAAAACQAAAAwAAAAKAAAABwAAAAsAAAAIAAAADAAAABYAAAANAAAAFgAA AA8AAAACAAAAEAAAAA0AAAARAAAAEgAAABIAAAACAAAAIQAAAA0AAAA1AAAAAgAAAEEAAAANAAAA QwAAAAIAAABQAAAAEQAAAFIAAAANAAAAUwAAAA0AAABXAAAAFgAAAFkAAAALAAAAbAAAAA0AAABt AAAAIAAAAHAAAAAcAAAAcgAAAAkAAAAGAAAAFgAAAIAAAAAKAAAAgQAAAAoAAACCAAAACQAAAIMA AAAWAAAAhAAAAA0AAACRAAAAKQAAAJ4AAAANAAAAoQAAAAIAAACkAAAACwAAAKcAAAANAAAAtwAA ABEAAADOAAAAAgAAANcAAAALAAAAGAcAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAQAAAAGAAAgAAAAAAA AAAAAAAAAAAAAQABAAAAMAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAASAAAAGDgAACQAgAAAAAAAAAA AAAAAAAAAAAAAJB5NAAAAFYAUwBfAFYARQBSAFMASQBPAE4AXwBJAE4ARgBPAAAAAAC9BO/+AAAB AAEAAQAAAAAACAADAAAAAAA/AAAAAAAAAAQABAABAAAAAAAAAAAAAAAAAAAANAIAAAEAUwB0AHIA aQBuAGcARgBpAGwAZQBJAG4AZgBvAAAAEAIAAAEAMAA0ADAAOQAwADQAYgAwAAAAIAAAAAEAQwBv AG0AcABhAG4AeQBOAGEAbQBlAAAAAACOADMAAQBGAGkAbABlAEQAZQBzAGMAcgBpAHAAdABpAG8A bgAAAAAAVQBuAGEAdAB0AGUAbgBkAGUAZAAgAFUAcABkAGEAdABlACAAUAByAG8AZwByAGEAbQAg AGYAbwByACAAVwBpAG4AZABvAHcAcwAgADIAMAAwADAAIABEAHIAaQB2AGUAcgBzAAAAAAA6AA0A AQBGAGkAbABlAFYAZQByAHMAaQBvAG4AAAAAADEALgAwADEALgAwADAALgAwADAAMAAwAAAAAAA8 AA4AAQBJAG4AdABlAHIAbgBhAGwATgBhAG0AZQAAAFcAMgBrAFUAcABkAGEAdABlAC4AZQB4AGUA AABEAA4AAQBPAHIAaQBnAGkAbgBhAGwARgBpAGwAZQBuAGEAbQBlAAAAVwAyAGsAVQBwAGQAYQB0 AGUALgBlAHgAZQAAAF4AHwABAFAAcgBvAGQAdQBjAHQATgBhAG0AZQAAAAAAVwBpAG4AZABvAHcA cwAgADIAMAAwADAAIABVAG4AYQB0AHQAZQBuAGQAZQBkACAAVQBwAGQAYQB0AGUAAAAAACwABAAB AFAAcgBvAGQAdQBjAHQAVgBlAHIAcwBpAG8AbgAAADMALgA4AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADW6AsAAACLxOkLAAAAMSkzwtYjxcMbxEAlJ0lyBejt ////6A0AAAATxpjpCQAAADEvA8FIK8RAw5gzxOjx////6ARyAAAg7aeF9QWnjn1KT/0nxXc/WQXK 3xTLeUF5ieWSA6TUxQMHkZqgdV7G8bWx7pNBw3Vp938vJf7WDC1KxGlU0LGUxZ0Dx7927XSRnkKb 5cA4/grbYQHygd901p7KlqOOwLX2pAJLuL6IYJpjSy+Xpx0VnivItFMM+6RGN3/2P6tDBV6IUSyT G+gk1aNEzqCjCBWiJpMbdgN+R9vDuOMdRyN/HBcLswpurONepLqZ87XxiSe+A59mRCDxhyzMltW1 SQkue+jCM3frc1AhbEMsKdOcmr/jKz8ByGPYpkEdl5kVILlXS2u3g7xuafh21HN/moj6z/8rokWe pkg5AQr7vu1ADP/aLECaltztDhMfhz0loGVbs3t8MvQ03rrRFo7h7bC7hiQrbFQNgYNsdglTrUf5 pHYV8Z1pWrrdMwtyAtBpae3uBMi4Njpxiq7qXl+JECALnkOZSmpMjd6votfIxM6zQb5sDAnuycb2 f7Man0SNhdRwiFRtH5op8sOnS7qk3/dgSn5s/Ko0XzbaRQTYzuASYOJUaPgVVU/D+pKSxqWHPEET no3y2iuQaZF+IqE7xopwUe4n2TC24QJv+SwemARmjDLpDt4EmHEOxWnF3WKYXCemacpE1/NgCGWA NQerZujo/oKim57WP3g8Vvsp1V1eHcPa2lXFJj0TRkFgYb1An6iTxGx/8DhCI/y2CfIV2w2l+jP8 iTvIcMEtSGoMv68fBYO9g8MRQK8ocYRRKhVdDNmGHdilkA5q4U4DiED4hVj+GUAHdDL4W7aucg0C 5ppbqg6WvXDMYlU9XB2+4bpqeIHo6ixn7Dlm+RNEJiuGUkYH39fLLCmlQmlTC3UiuJY4hvwLaFUl WCfels4fUtbgKrjCrEOLy+DUshiKWLYfuwEBfb4ErpJu5+Cy9morOUuDSONIxanwFJa9V7DYVmh3 XDagwsMWeudIL84Ob0BTVWRHVX5m+Y7m4D3NSpVDMQRdk91CSln2tPvFC4B+bN7cs3IcWoJIheO+ kiZ6FaNSfCHaWC9sV447ojMK+js00y7FtWlJVriCujApH26yCEFP9IcfhhvX/eQLxJ8Fb9S6KUPe 7zar2Ls15hzE+HvDqcJ1WKxkh1jSvcm0weePuEMjqQWJURnQaT4Nvy50a50M5pOyoGd1m0ZVBpbH 6Vp650T4maUHvdRyKV3opBTsh1ITeYw4zC6P6YmgvzOao7xUVs8JUeRcezIGzjMA4vU36TnGHXw5 kGHJaaKo1WeqTL86ARTqGIUEb9S0rZ2qtdPq5/0gkzzhhd/WtgdoCfBQH4dYsdY0UkGZZp5DBo5R wx0CRofzqL0ynEEbBZT9rhVRhk77AG7KafD0bgMQenn25GjBnffxNsqvdlNDEE4vpYIrxXnadqUh HJfvg1VOkITjhkwKw4v4Ax+NNeH2QQN9ihrelVA/u4K7B8gQpz5cFXhNY2qizCCbUeifoJ/v4qL/ KNZAk0spIth/ETJvtk1ZdNVk+x8aVhfXTIQAC9bU1LEWR1TWRiP9blcIhx9+DTUSiqQ4Ethe24Ee RuvhzmHnApX9sqQCyfnrNLUY2dQY5Yo3rtvtW1pxf4JFKhPiYA+nnMkImJNkiI96Ssf3npWOwE9l 3m7Y34veD/7Z1B9Xa8UC69tSlKCC3QFVq/kBGOT9N31lQGFdbcQYCuv5/Ecd6kkzs8BoccLMOn+R uShwOaoQaueueboJI4t/uNTI3K+a1i8BIj2w0pgGbATyf3mM65ZoxknyMr+fAM+sZsGUYnkyOTAL KW0izcfISI1eKrFQheAEhe/GDNt9cJtWJT+4frdOWbk2wxu3h1H61RF9oRxDc1a+WCj9nbgfv7/j F0P/qml8YpXDM+Fd8htNvw2jwI38xk8II8tADizX0G7HD00S7x2U2pr1LmhTCiBCt74i5MgsHW26 GUmZNRWXV44xC0nkTo+QxYPmqOPu5ijj2Kn8lPCKz97tzcNcM66NBDRN1T8x1Q7i7J742uIe21aT tNz/kG7Q3L1ftSpmKFchcJfLpJ9nXwNDav60vY6ojdhkA6Ctxs/yZGOfPcSyj4rdA5QRNfKyVno0 RVO9B55XKYC/vdoCbo9CSFwVW0+Ir47i8XQsp3qldLa0JOpo8nDQet0pKvlqnCewdLtYUH5HbPSW pg39L9JMopg/sVBTT+k5RKiT1gr8AwucpHeJyC3C3SXkNL8/1zjAsCS9A7tjI61hmGgmz3qXVQg8 DbgQR49wK5syjX+UdoDB+4oaWVmqTRwZJJqevCEIbnRYbHlXz/0lYk9phd+1dDAq6woOz5rWJsGq 3JA50mWOaDIoOjhhPdcoIYfRpbh7eI8oeeByVBSAwNzuYJm9jCNAdSgiMA84zRvKlZkok7VxK+uD w9AGBhmRqiyVENDg3TyzzRNe8ww9ryYoA91EEPRt2xBwIyyC/sBSA/tFTu4f1Dds4zha6UHar5YW /TMaCHrsxIBzf8/0FH33CabOJ6cuU0WZhHa6/5K8+uAxvMKhsfjWdWRRORUIm6w6fkbbjtzz+niu XN6Dvn8k72j03gpeeYKGABvg+ekD3m16j7HK4Q4NITYzSZrIt9edpfns7dLhIWSx7BN9zX1YqxKG T+p+KgSlCmDf5lemthVhmoAGt0Ug2K19VeHYuULE/ETrm1/JgoVwUDMLpY1DRpBXGFkrNaO+CjdA GLHdm/swEfAp9tGyUkOM6DdR9subhT3ldjFhnt4apMA7JHrBwoxoi6zRdhbKpiZYPU9PxGmZvoa7 eao7ksBnrBhNhuy8Wk5TlK26MyOKUPtMZV3r14R7tsPwkCTzD8BF8xTIwrWLdkgQEcCYy/en4MVr r5Xb7gY18N1m0dISAyZJp4C8AZrwXS+f07i0JmI9Umn/zkq/+/0w7sEjoHxEyVYaDcVj2J0YuRZA ZQhAfnk1Qbyywgii14Wcofxq6fFe45TSqUYorezJuNwwjBfUImbgdk5CT/yfYlyg6uU5ATCOLudQ h9ZoWe5Xriw9voGNiQU2U7HITK9ZIlGBdOr8LY00ax4AKLbyMf54S+Zg5WbSxRLdia3UzZ26J+/F chz30oKblGpSPffJXSr1Djz+4ZqyLWYIDQuPh4fC6iSvrR+45x8iqF12vPRPAq1f6KZ6DXGumy3i IphoYwnQe2qk1waGw6fpajvcpC+SxDciorgjbpmQGMqAclfIbwk7AMGWi6Rq4izjC1pib2VUHwbc gULX3PaqwHKwpbhBIUNyLvG6CiDCs7uVP0B5r9ToxF73nMKd7+gw4GNn4Mr0dhWG1w4Wf/qYptst cTsrhI+vOEKVUl6S1tCD89DDArU6Yj3Xfhwjgd5pNg+AosM0VcRvZBzVFLCuO5dFJ9iXaXCckplP am5+GHf+oxzvzESg7Yq3JNe7PC560ljevE40POnyXJwsM8hU9hGfwKbEpUsEf6etzsgA8CNg4Fos B/mQPaEjfVz3Evgo8MTjmeCEtfU912dyuzTeQsAJT8k41mx9ihwVwVdtHLb93RU40Ob5gkrWUh75 UNs1e/pHTTo8A3GynXqp+FYtaKI0TTrEVGmCZYIE2NcpohZiViSKvFHsqffJ58zMybb7su/lOKAO /YTJ1btPwhTIxZbA5+K8cWYVk37SiEqrvz0nJpCsyZV6O7t1Wd2QSnbHDHGksBGX6ZlxLjhp8TW1 1qfFGwLRq9RZtW7J/6JcRf9lL8fkDaGP9fKyKSM5cHNPJ9W9M6ubjtIlrx2H9g4al8QcxEEV2AIj zVlCDiJ7ylLapBfi2uL5jgCiGxCR/8mWhiDGYY3HTghYc2GClWMJbLfE2IXGnmBzJjCvjlU2y0ew bpoQGfHPe3YzGJ6c717D86aRXz+mgBpFJLEgl6gyokNwURPrvLcJc/6rI9kRpP+3BcjxkT6P2uXN /dGDpojvnCABIdLPV9P3M19rETWSVHYpHMnv2FW70RWzyNGX+Np4VMV07/elAxirsSPsDT8UJtpS iNXIz+7mLa0cVLxdC7w4MVLRPyTHfYkv50riSfMTl2gaCp5H7G6TG8Cdv21GYYaWceTjOp+rr8ra AIK91ycvc4wlOM9CpCx3MWzlBpcVZNYHtB5JWFFCGRTadqTcQIG5X5tKlcpXjfJAWlIT/XIinbAl aT4SEjTJKlH0KUq40KZvfvOUhop12/dtHvhHyvXS61lAjs0gkW3EG2oZINJiKwLgBqh3nPILN6YZ Jp4P0syfJO6SkaMyYn6V0Cg4fpFKS6/23NhBkNbzwZk2/gJrbIKNynk8pp7r9c99nZDGSLJIMCPo p2G0iiJWmXdT4OVA6yrrlr+HLmQHoqRFQNcRt/eml2kyxQWl9tPnCM1EvEYwPZBTl6StCnYEZwKF QLkzCh71T+dl8AqV6qmsQ8RwpC9LB0eUJSLPaQNwnRGOFftMfvicvP2UUdTwR15iT0vPYUm4j2Q2 7rsrNHKLrcqRZg43d9nkDPqZyBWIzVca3j901e03GB44+lkdxb3gn2/JSC/84NV9ew+cPEssdctE Aw+IKOCMRjxTKIfjo/QXmCvqqNMQ55Tmzl+DRchTTLGIGWpKTJ3qnduuxm8kDnTATAs8fG0EtDjA I72lfVWq/ugUJPEifqaOoe3ImxtQyEgu9PWFqhh/jNGogxtmG2StsDHRZHAF0N4LkhxlJRu10dhO f3xDFuBNuupUd+Og21Ktozc/H48rr7AnTuAPK6dtKJZyfvZgMoDaIMskOlVJS0OWpy3TitSS/W2b iHNAqYfGLuk324SiKvwFIK5gExuW745Ae0yk3k8dVs9g96kJVeLXY2PRZMtrKVKjvYhpQw0Ss2bl BwnN8ojrXmDZXbn2KojSgjB0TfbS7rZwyWHL0jr5h+EfMy2eM0p0AXg65ghTQb3BbadddVvndNco W0b2bfRrBsnhsCqhdr1QrTCD0cW8vYofjIVbBQz3D9EbbN4AKsTwPjqsMzbpLhCjDTI3Qoh9QNDo cfkCmfqFuCsDAeedLEulJ4uf5bK/1JMQYEl8hUAyEq31S2lp1IvINMmm5PVAQyp7wMKxXJzDn/W5 bJ1iqmSygXbXpTALXI27iSWssUHcdh+CRPn2jw8CN0QvMDrynpTSqiEeLk+c3QE01d+5lX3/+LVI SnW77rtZw++AFL4j40PD7/+CeY8Iia2p1wWG7IqrP4CAjasWB5ceWXE1/t6R7WVi7IUlmA2Z8hWk qJ5O+9zyW94k82DcRQY/gSMvZDNv0nYghhKFILcmXVjcw3nL+zHFEnn1Rc2bCXPJB+6aJFRDsxhf mkKH46MzG/mXKwHtRoK29HTNrlFxjEFjQG5DvVhsZYqRy0rK4fH4ZXtdkUvuuQ0f+s6t4vukTVAO H/xwsHxs7B0C7dZUr1alnGuuT69P8/M8cE9C6IXWJIWvFifWTAcsgQMcFyi1DZ9gUlLe/zs0z/sT 8pcaxMnVrkW+3SJNxjwkfcc8WcCePJH/GYbuLD2ZAi3bz+zmpJdJAeMhtikYERdKQGUM0xJIWWVM HCtUT2JNdQaZQETZMrpBAnMzouyMtkmpDiwRYyYz/Y2K4ANLxULpddn/aWSvXYR2tYy2+AZcv1iI CLljRTJXnZuZxdqN4LkXnWDyMewPGncJsFojokheBSA+U1Mn99yKuWpX0vnweY6dlwwmezKlgjIP Ev2aIakRac8h/1J7NBAt7QpWMJVN6LGb9O08YMfYbJU+NqOBpBb1JJoEFrfmok0RAKY+k3yGwXlc BkTGFfu3khhd/mNtqDSkZ8RF6kj12AYVy1oHkW7Dp8HvzGUGljKOQBcgs2cYn09/iYcRj0bkpus+ JRaHHKXKa5I5KB5eN6OzE8b9/N8UJSg8YF1Vis1j4EtLUcBr5nPzT3QhuT6t6aS3AspksYpSKbpY lj/bmHZs3PA9P8zlW7yXdvjnInfSMM0ROePLdra5dKDChRu6yBAyu2d2qW+iyFSs9nzD0WmHqKPK jQvjAK7dmKXrr83nbJHQmp6RvXBH2ccpjCOyA7VKyHS/zT2uHPIDMM3Qfm0WWW88nafHD3FFXZHH 59Qg1Z3lCoPWSU+XXD0Y+Crj6CrvjVdR0hH8iWdiZmpDcs8zzi7v4ANgW2OLROzwlZKC0GqoLw+o Qgr2pckSDBxe/MUOvy3SX8CQU5h3saIWTexHzhmDiTO1X8Y76icZRX4/37KDaO8E9ymElIfB3QfW xTeQWS6lmNksx+hc1s2Za5uSPiYZFsWQsHGnfkA102V/eSvjVx9juWftGddwgKZG5F0AVuw2PbtB xc/Gr+giWX1rqcmfq3633BJFbX4OjFD6V9MjNB8W8yXH6ml1hZzGIGDS5qM/rwWsEy/ClchC0rkp mo9hBNcMDYzsJpb1NSmOJg1db81lm8tTszbRAmHVscPzEfItM43fOfs9ELjdecntxjEGuPg7kPqF V42mNJt7xKoeztBaCGYdK86i5oFt4Vqt9KY7+K+HEMJSEKUfXxeedhsNxb6CN9pxFGGYke4+Eqr2 hExuw7X781HEq4lmxKx5ch4pcF+BNhounA+YFUKX4bSaq810JulXsQkvN9vPwT6qE4gTlnguyjCO c9U/9CIqlCEg8NthA1I0k/manZrOIHcvp8P+XIqxIPBgLOHkYbQJ9EuJFi1yH1GlTQMtZwES+iTI rRINtMWnBSLlJcKJfMZKunb9Yw/qy+QLF+eKF1+3FrzUbQgxtiaPJH9nJO6RyxtO0KTXnnn+p9Gd OaGymVz5mOoYrxc45451SW+P/7zIMDvg0no3XmGpW51dXeyXHHCsYjg/OpOuCHZI8a/vVF/w10ys K4FSekew4ota2KLcfsgDsYJ57aCrNBH6vxDh6DPu8IZmTZsv/av3Hlg+/zTJIs9c/FCya4yKWJP1 yGMi+5Y915jF4L/zM/bNVLk80EvIAhv0QbVB7XrF1r/RsXGnY2Uyb0G6P5eRB83EDNXSKb8E+TM+ pIDg36znOAXyRfwD8crFCW+wAitHrcMfSbpgypZ9DYzlPpAA4h/iA2ZVkn7zWTHmvj0iRXpSrx6B VQ1AiW5XS4JntfA5S5QXTwlR/rIRrx868J5vnkKNNjSWJR+4iUPFJ0JFa691UxoK7zbFRvFOW03L yxII88MnXlQEIfZ4lRIDAPYN/zAXGM4H543Lpl7kBvcg/IYa5uN/H6yU+1UerCp2J7BrN6zXm9jI ZtzwFW0TX3rmqLLLplyVnKyniDQWE5cxSjJlknmSnyTer1pB1UleruHyg/7E4LoN6vPZhWIsDwaG 8XpljzBhJfmsidgRQW/NGD5x53lQ31y6tuXD7Cww+8p6fjya4/A4GDDKe3ApA7dJj0Pk5gWsyAGh H0BSH24EUvVOQiGzjnIPhoRinS4vqWAhO2HNfm+Rxjq6mIZphZQwxsYtZHd65fikQslpYVLMMz4J iXNQCYacGkvCxnr33AaacN0Rdl6NdkbfQ9ODtxfl/Szdon/Bk9G+D1AAK1qGkQZ3iCMOimKL8RaN YuzlpzGrpcKf+IaspLJYYqodIyAgiaIzmZ9ZAZhXakjnM3YU/oZfdKfAuELW/1ddW2tOh8L8V8VM ud7jn9Kuu6HjKDZ1LfJH6O8KXMrKooFAH4kbYpbGbWU5PNuYqLRAFOGnyYCOhlOHM/TSKkcFNAus oIwXJts54GbqsE7GmBNngrj/yb5jJBPBvtsBF/b7UB/LJL/iQ8LykeRaiG3fjpXHvwoBT05z347X 5GbQSK8nIcAxiGODjhH35vfE9s6T9+zfjXp/Ze/u9t7L1ZnNODyZnKi5vxxXtpJfwMDHIS+kXRvI NbJ/ZtykG7TJAlmoPcrAtiGhD6lQWHrdCLqsZzgg2046hRw57LgBW5P5UiEEtHfsmpHYcI/k8EUt EjMErCJ9XPpGN8g3rMm4h4Ov80JZEJXI5c7p70vDIYXv+zud8p57KVoNSQlDB0xwMFDctCVGBmuU wKlc9MsDUhraKPziXeZ/tPttolQsrLth8NHHdCcO+N6iEDNbn7MJNZ4WaaisJtCttTplhaphgH46 iIuK5tb0p7W0rQZWHi+3PYPNfUO/4lS9yJhgHpEdV1iPlzn8m6Mq7I5apjKTbFt7sGabiAW4r+mo aOfU4kAawd7aPwcmfkn0lzgeIqf5sxMGIEIPeuw5zULhJBvTPVQys/va3MWXIzcO5Uj50o2dL56U 3bik6l0RBT0uEoLXNI5C/GyXo/ZK3yJYVc4433uBL6yWnuyyeNDgcY1wHfB/lkcZG9+We5vaaMuG JSNjKgnX1zXbq2SvWyAgJ6v+tctpAcU4SRv7GoT86j8qrZjblIjBXVvkvnX8pybbKMknbI3HZ7YY UReAe/xpuPgtoC6ZNKHxln4l3ANLb2Xq4fRD6xeMlJAKDFH25UqNqc+vrWgieoBXannjiboARgET zdcCrj3cLMwsxO1iTdabPCP5nPxlGXIiopruYw4y7ROEiDH130Rptx1VNC2AaKrjMKp4PyaF0Pmf oh2l1t2Cl2itmOSCUeQdByeRTeo0HngRTfG3oy4a5F+sj20OWgcE3AFgjVZG988P2rOUs0ISGBJE xbHtvNdvD96Z9Sol8VgX04nog6RDAkHnNpfgJkc+pqt6/wXqm1SJjH/n1eOZGbwBSeW5h5zStpin YTQ8YBz6Z5vQ2Z4h2tQV8nVd3AScYugQDh93pzLxp+pIqxOn9fWTx3978A/h5SwvaKjTOIo9lKhx 3I7tM0F7P921gVs5CPnNW9w05vtw3jFKq+HCR3w5NSies3NPh55TthKitBXtuVi4+JnswVazp8nR 4H3h0G/1THIGf18TomliMR6tzVyZ0FWdqcDkqZn5wSNgzsSatwOD2KWNPQubH3Kxdz5P5VkRyZ4L zVaJsKK7v02vYMJEQCDuc4VUprZLCUBHhRnPDi4Zfomsz5/I+E0t1Utrx8lTDF5XkdFeMmDktqeQ ligrb1YdC2eXKoNqw1DCQ3fTQodrqqLQpQrPUlJK6B/JsrD1nIaesdYaUhcfPw3w9bwbn2KkauAm 6ANoY3xHFragIf2bFopzXEqnTlgQjwQqg8MAMtfBK17WMTKhRfORtg47G5XxG7bXbuwXYy9RqJ7T 70NgoY//uKf62xZw9lmHO68otnGUStHmjGLM8CTZfmnCR7fzTkk1vG+Q9GmIfEo/A14PFYs3CBYO ZfkfVQmdEoyE6ursY2BdP3GjnRNZWNvvaE27/jSAqpEuBWCUoKsG1f+cVbl1EVHWWYOW8s9ibwZ8 Mo5otA3mLQ6vBMMGd9ycrEAX/e/xamQAjU34MQwNL6hCvs+7zL6WIvGchBHsSuyDPfbkY3QUC14r Ueg/yr0YdEgLIq1BLukkOqK92iJxowoAETuf7u9mWZM4SLnArQB/vV7o02jGp74iw7kGQeic9C+6 OUCBS7sWYZkJlKd3OuuUW85Zyd5CdIibo0E027Ir1fFTft8dCAtU6ovAZgHNSGkXqQimNI8jnp9Q NqIzbHvZn+vFhpwxbzLORzZhaN5Kr+t3QQjkU9xlrBMWyMZ9oEFhWoK7+EscsUPF22eC3+CkE5GZ b0RBPNMtspcaxbgi7gq5sWc+rAlfPDp09S/M6XSbioNMD2zkLTfMqb0y58wSY+NQN6Q0jBqKzpl9 Gc4/NCN8AQNDgV39g8bXAt/7J/5xkV7/Ye9N24iQyjJf8S0hg5JHFOS5tKEI05PTk10o7mwwZvfr zPZ7TkDR/bvndHm1ARNVzprU85DBWzSQL5Cxl13Y/mQsY9wE6Jmjecj50hGfA8BcQTUzAuigm9gh gK8og2c49LGr+mLVVwoS8J86g2v266Tc1JtcWA3y282oIkva8xelBW1g98CGgl5M2gkGnasH5ss5 3H37A/iox+s+QHhj3N+HV/BAUd7KU8uvjvnAUUfaDLIj12fX2RCig1iEsvMXFXXO7y/AivtVAcJS fJ+DLDRJrCneAIj9qAFzTRbMzDl9nAXLTIXSE13LpGk4g7PRn5xRTlxZlRJ78k4NiBlVvE3O9Nj5 NqaUrnWA/FUURmTJkY9axRxIgtAn0wZFKOIzWEyaW9ZlXS5MiEaq06w2YGCMlLApHkJCayO4SnjT whOr2AOE7cCi+3fFfbjGxogpoZiPNVnPs6U4Lz5HhTLCdMc0OhtCxAU4DfAfPDjN3me9gsgDrZMs ogwJud7qvTwpHW1v4ALA5qoqSHC8G6bTUnSCNpChZBMkaT93gsmD5OH6DkTQh9nGFTERj1HDpdxP NRC3DirySvrNjb532b/9GKvKppax/lKfu8nl2rUSyxfmNGCXwddHKE/n2bMPCVIecHdFfk5Io4/2 XuoElYnKkzqw1UlYnUUaW858tNL2gd3cxzjYGmr+2B9UKA9CVMbM9IiMUY1FRy0wpzeY/lgZ8LES 63MecE16+Gw8yS2cwYQ8jUsw8YrQ7btzkD6SkUpuc9VozkiBEuOZ4zuqxe/6jT8XKb1n2XY2u0io TOfC7Clz8075YrCigVgw1YsZn3xmyTF8JBYe9dGL6+A84INnP3R0GR9Cca71RM4cOplVzYPdseya iZmocFHNOBJ3ndr8C3mii7jd9eusoJPZQd89Hs9zQflLfByqOyH35b4K9wTkuYnH6QNYgDDgoarN KsZM7Cm/tIgytfIGX6g2hG1nyo2gJF9o85+MPUQn9RdgocN7aFVOrnz847wKX4NLvWeZEA2xb3g+ 14g34H1u1UnH5GYdTBogBTG7RKCoWH8j9mG5+GycY3BM64Q8I06BHF2iGDKZzU6hC7mBO6jgc6j3 PuQEUg9IpcqF+uQ3yuI+4j8tdAudSJSy/tNX6Kx34TevXe1juGju7APiX+kQuZsCLL7KvFhfk6g+ 0rB0WLdamDq00FzrWQ5Y7zlSWFxLNIm0+Hr+FR08ivy8D6go5BqHQDw0EAn6efEVuqQt1ol3LFdz GjVFyqH4gdL3RHR1BpiZ862Zu41fWugoH0JURHC1NZ6h1rMgowLuMTMtDU15vqL8i8Ha+jP2q95x 9yxzMJE9X84TcTU3aFYogYdM6kpp0Low76tD2v+9teDSrCKZOEmzNpzB29MLFiP7Qxnq3YK3EUtu VmR1k3xzSRC3UU45UbzXQhWoekwy+gt4kSrYhd1FD4T5Sn//VlYlp8q13kPy8Dj3F9rrg8TuYm3+ 1lQWcJ8raJBajeJB5UrrqxoJ5o7G7Xz1tAxVhEdO6JujMx4W0mn341ZLzz0R0nDs1K2bBjauorIP A5hcAXOpcFjZ+hOUoA/Gf1Y7zoFoS/YLPxpJQlsWs9SdV24vEBVumm965pkEpSE++4dakNRpy5Zl Eyl0apU2sPz7Eie7RpwpCR9RALW1qHoXsZB5wRPhU5OGPQa90MjlJAp2cr+qJ9UMccbKeLz3jeZf 3DlyNTaOwIt4y2K+QsFz6tkf+ooWsrqYvrlBSZjPLgAdVNkwncNsgeFRB5iTzXn3Bqx9q+XogfOX bkCb/7E7OYY0Lg2GJG6ni7RKmwI5gm0drKsMhnvPAm0h3DLMY3I/1pP0kyrfquGlvE2EDsE9OUa8 g0vbhwucFiLENZTeVU9/+8owuqUE7Hi1TvSGSpMdn+17rBdj4SfgJbmzc2+1s8VHtEMQ+H8JedXR Gq49fwSGzKyXz1icKLWXaqnQk5tdz1Pcg/qqMD2QKeIxAvwJ2Wafu/yoCnygrn6hcg07LXAuRW6M 1KXNYBLXJWpKbaOlNt+Yzxo67waNP37ZNx0t/7Cphc4lUOVKkfDVbcZhaBW9xar9NQDr/grNrW1j U507q67WeSn4tloyWJGz/Bv55QyHOOBDX868ws7/67fg/sCVWzO+YRJARIV4rjfrCDcEFQV5ZzWs Qoh/+3L6ga460s8r9ste8XjFhqxMUIlIndtgBhd2A//qcxFgLNS6d6/qKiAar6Jgl/I/4ryic/jm kZkJqVVNxGD6tKv3z4oPjNepMpJ3GDiXuAfkQy+LKtNDwi5cLQmXOKDcqhFvU3gQSp34CEyzmMV6 OA9rGJ1ypflx8GCqCYMy3w0+qGGOPY6AlvfNIVIGeDNGhhTj5KXZtivBnRFL5QJZBGY6O2shbr+p l/YqBNoc55iSlj7DpKVOfMlXfU1YMlc3K5IxumV6NRqwhTpD3/wnyXG+yc8+3KoEH0y9oUtF7g/s 1gnbP9I/bUj5g7b6Dai6fNnrYGju6yBogKTEndprOs9AZ5hjVjjYYkGM5Ik6arVQFkZEtMgW3WCY 1McvwDAzDdgUeZOCO8nyvip15Zsx1oOOYDQGQvFQjRZw1Mg2JkG1rHXomhJFM/I8/tn5Mf7i+nV+ Mvt3esqqjGMoM3nQyCV8YB3iUrD59dDmy28iDseqj9U5ejy4KK2moBkIB1KJgBroEbZimxNm1PDV fABgK76/4sthSf0jwLJfW0a/yCajKaUxmY2BchAoeuSKdocEHywaLW7sZD0u6EObaSmUddAb7ZkP 6rnfmsogAieFWkULrXSQr/Q3qSm0mwZg/w1MxwvV3kRm0WTQzWeiu4QvqQ6GNJTEbnoCoqgGNi5J Y46HjNKm3B+jSc/OkBNHVMAvuPQ5zen3y6z9Ny3iwCcd4pPTRN1CDnjZ4NCK2IdxFnULRWut74zz EzXiKlI1RKDuW7ZrieOs5h7A6boD12WMbEu6TrvCvuVhb3PM3QqQRSzOSYpQnW4pgrUWFY3JeNdb HYwU5nl7tH20p2E7D8d1ZjOLbltam+8Zxkzf+9x3+SedlXquQhPObS597nDtwgsTReRdbbspcGKo 6HR5HTxisUsIP+wg+MJBNcKyJLMj+m9m8qIF0ZiM7cQGsImaYhHN96krjUOMsU8A2/UL6fohrhgI S/4VRF5zk+8Stj19Mr5YopXB9s3cTFkrD99Nq4uQIOTeap80wJCsVm8uJd83CwmNOr0u3Gfeg0YO ijWzTar+TabMg/SohiqQs7K33EvKXzAVU24cXfkNOj1SHN+1QmwT6fnKfKp7bOHIqwG1ME7KVnMX 44fMztj+o5MPlFgg9iF4K3ZwVewXsSiv2DSlK5CZ3d/scag/hVd3/DCwbOy00RdC9TQ5K0DjFDvf 33inhfeTb/KRbG9grK28jCHvJo2lQCdF6zMI1daVFXb3iVh+dE9jcxqWj130KFXw9bwAIT+M82n0 rTpN+M3RQx5VaR30SsBHFnwDAHrRkgZxR3adug6MNzIvrD5uqPo2q0OuPMrBs9/GN6FJuRDaQfXt 0N5fn/IB7jzT2k6BZVDjwYY6gcBxl/Rm3eCN7+nMQFmSEUW68+czjV5h2sAE6VoLlbumAJsxSqFj jvBmNLPjsqCdlGgnJz4PlJS3apkOmqzBKiXwnSGUK5hJERT/R6tSicMkQOC/XCPZGMp0QOVfaJDT Y4ln1Y1rediDLj995I4KzfxTETqW4GG65RKokLIK5n2Sc3JMmMwjYeM838K7imGE+dGP12gKpVZ6 QP4NwNVifMjIE5yQT1RwXmvVfvmukJUUOBcKCOilh98N+Nu1abeRPThFj6HwMqF1QOBv6E8JoRxp 9k8POVu9y6To2MuTJzmr1PZTXxvy1haoDFHi6r59Id99w9dbthYB4z6omJT7mpkz4H8agcUvjJPa sdWsPlhimZBxFA1RQVyZzZtX6zZl64hqLjZaOM4OXS34Zl4fdbnFCcSgUxnaRWP1KgiotvsGOeSl x6kny+NcKC1hdncoA0iiAlXPcJAROneBJEtqLq6h427MyV2oSR1uPPi8a8Q85k0gq+L4c5a2MAQC htlqkrFv6tg0jF4oRJMMs7woBa7o/fbWoPBXRc/vxew0LIbyMPzVcg5b0dOdP8SF6DNoMdp/dMfc sYAwEOyL+Ynm6Xq6/TrtD+kueBVcBjkRbUuv5TB/y46JrWcNGB1ZPSmrQ+05G7127BjcspAKUmm+ bPb+rYI6dQGOdqSlzl1dtOlHe75XMrulqzzKIQM1AJ6pOZKL4Ek3jlO7lh6qTo4q4Ka+7xi4kJlv avQqE9a11KK4tGDfAxD00Zaz1+LS4xTsS0zwVcOLDkQN/bbUXgrjeffhQqARG77sfH3u8/tpTNwp Fd6pmEYOE2g52VA05Ag21fDPOBQgLKi23DPm42o991pgczPRdnPEOnmvxdL7ixBhHjBAQFswwQKE //R5H2fJsVlk5SUwsITxfVfcHLmdiW1KSrPeO9ocN3V3i7lYguKmdTAJgrr/lZm1rbBrvLlxj66F kF9M9gCMtNi2NcYB7TQ1AqxtdY8e9VIH4i16083y/XxIMEhl2aOt3EjzYhGAakShTbHHEQzRSrlf OdfOEG0nyeEqaNW2Gg+VCsqEsU0GsBVouH3o4gocwYLyTwORgwCyEPzVJq02LW2ldDxi0JMvIAR7 L9LWWZbRqo0iqKKFs5yna8gGbq747x5X/UApVwALYk2nJabjWFpmiqdeXlMf3NjMPyo30tP53h/n klb8G/LnuQcXRWYwHvDc782tCISida6D3Y4Xy7mXmOZHhkCxhhcPAW06nHXMIvoL8wTzv7cpn9da MUZEErnX3IM83Bdg9PDXiGbLYJCkUM7v36bFO9lbe/zvISQa7UT1ok63IO/WFbpnPaw90D6Sf3xQ kX391E1i20Oq2Tq1qVrSy8fwri5KyR0TfbCtn+THIw3oBCT6MAX1jJoJiRxsvPI+VTBIcRH5bMKm 1S86q4XEFKIbvSXFMXM5Lt9pqWPbHuc80fT+g80ygdNgSu++XvOw/USY54lKOav/3clPP6CL8dwt isQVTAr95Ynvvref4eAcpZ8AHE4f3uLYt2PQP2NiRPRILZbidrQnOxPBckJdzwKK3G2ZXo3dcX+d oSggSvfhCjy0khiGWlDwCgkNfOthhOq0lhzu35NLNYmjMNUFTQfrQg8fOa7s+2ZDE0U5DXvYPZC/ 7HLiLGEl9KV9PuHkQBm2RbEzLhGNnGih5WZv7vhQEVBSwA9fQkYpbbXiazu7fJKx+OlJLazKDL/r jnA07We6/nK0GGoWgddI/iEWndsS9oqHkE0oREKKYp5XyIf6a91VZiUM/q5oNb1Bq0bejgEz8vef 7tIMRXA57tFpoVVDUnFuKUO8PvIu//92wbOFgjyKn6bV4xv58oRPWFVmTaTPKQhhwaG+KSEpXe+g VKePFS513DiSFeAC2e/l6W0WcS+CmrYBH9/OKZWXzBMnCVYASOBi4WHc//v2dzacA34hpisPJhs+ HQPlx4MAtVXOqFgzyfQ5V0rFA733buUjAjw1x5uREudIF/MbGfjZX6sK5AFxjNlmhI22uXaHHlw3 gqexbXpVe+gMdOBdVfor92exhjVLnq3b1y1GB3zrf1KMeQdJy69s2S46aNp431BMHehGhHV36wTx 19hRAWg8cGc8H1nDXvv7n38M4EXEwitXhcxv8u/BI/55AfCMBwP5DF6A4Y2jg9JaIAs3/a8YMDHs WM/gVWMBtbxEPJSEvG7KTQRs6ni2HMADdivVh9xRYMHN5Z0omx1DTURAZ6cKvUSMdgZSTmb8VQ+A uAuetPWF6W8PPhJehR0NtNPKWFyq7pazMKVwzltSwE95Bdx9yvIDHX6oG9t2gVP1DbJGnmiQUa1r 0AK70K5becAwr+vh7cJupT8YMz5/Q6OIPWR9HaZzT0TRva0qY9HCSbVnvugpUbav0rZgxZ8vU3li LFovNwg9u5MWMtsIMsMKTwXEjXdHHkqsUacSH6JDgNYZ8PzWlowBnaITt6ZYAISKlJnhFiLosNZz UISqrQRdBMcOhqiG0J2UBciXQ28vZRBmGafeDgZXMDjJOWBxlZqXh3L82huqgA3zVD5N9l2RitGo vkAy6PcjIqDsTR2dKYkH/DkMMoqe/iqu1xAQbtw/HizcaTDeQ8C8C0pgAgkdpfBWrHyLF2wwLJZd oqjSgCipEpZUfF1gRqUR/b3S8sfNxPRBKjPBgCf7ub2+KZAy3yL/fxZqf3ucOSUhul0SBqmp9IIO 23HoenYVkghatlB5BtqDXKkrebEBtenWfPqpoPVMkuCjBpDGNsHFTqTBNt/NdIIo01hcGmVsswlL A85ljgEsHC/JhuhOb/XqgQpkFU97aMJKaZk3rFiBHQiFbkDBPINR6DERqREqm7YmyjkP09Lwx31F Rt7ImG1lcwW46y/iAW+fz3h61YAnPpYaRkIKFDrKYf4wuXSU6O+cREg5tJYk1rzchPsbuvzQLUmr bSX1nftBGcpirphPqoQb1ZQHDK51cbvp3f+dOGOEgXkbdMcvK0YiSgja8s2P2BwNu15S1OzTQH0f coOptPvoOPEGLC5C4jVQpgk/vEU8wFdEhecyNQDOYks8CaMu64Q3dk42bWgGKbv88E7g8wU1f20C Z9K7dl+yzw3Bfd4fPzWdPiETQJIk2UDZ/7wVHC1nCUMI8nq9Mp7dLyrnPcXpVK+VCwctaMroV04l lq8PCd69wEo81Ec29q+PE6bIME/PD5DDWVVD5YkYuc8BWj66qMAG6TTL5kdMKtDDObJH/4ESLyzv as0gxyqI66V7SNYqMlgjJaFYO6KMrCSt97XrD2OMM1rrQ+ViEvxxN35ELaJwZ6Sr+zkBcEUKoglu P3Cr0D5362yBp43W2v/tD+L8M3HWo7pYMe0OFWKm5lkg74G+pZWzBFhQshb5sLvFcYPXCYd5/5FZ JZjhtWYYG0pAu5/XVaQRXLUR3ePeaVmzWiA+ODKB8dhlVRl0e7x+/MLGc8g4Ox8c/YPgwPf62PfD wHc27S4kMoORn6tu3YBa50qBvTHOxY6x4JYG24aen0sTDGz5rMrxYfBdueeHj0MLSCQaOe3jBB2O vDIWj+uNAu4wsshlxtXWn4CmLPIdWE6fy2AMLN0ppci+MBQaB35WcTU3Lz0pyPa494i0siB4U+9/ GB6W34RVIoFbXwPcPcV/I5PZ6p6haVF6vxGu6l8LsgEJ6Gm0PqI+NPNdrA7dHvct979oQHnka8Vi YJlWLup9bMiCHM82xpun0S8ZK4yKEMCoTGuwJBuw0+WGVwkkQvaeQ12dUo2mAoa9g6WyslZKK6xD /eGo2E1YMwHxAplNMS11BbhPa/1YCt3Rhcvd3ycCjSZt7D7rFpE1aV+bVas6nTzmMUw5ONTb81W7 BibeorphhZKnojEk3AhnTOCupJcPOkkGNMeP3quibrQWYGCeLpb1Ktu//OwrOsmxeV/I6usH7ZIO jL5BRU4VUL0Du9SNsTB6DZ4mpH1sCcVlhHQWHzYoZkwAUWUCW4L2ygXpxzyiGetG27MiOF6BvjLz dS2KUYoGf3YaR/Z3noaIPk75Mq6oGtylr6s3THCDIekZ/gOg0SRBCCDFwEQfjyKiQQYCQzUPDwXC 4zeD7mikUociXmK6oRdgoxQKrkjStmEj9PexUjgShrUQFBbwo4NSfApHvfM+QckzEVJJI950pzta E5Svnh8A1kad0Ws8oFbuB+ND4qZ1ZmMCTzyWPBImJDJT7bHOFqUz28pWAPPCZ1YLh9RmziFdMNPe ZbUoRiJPHhSZZhTBj+tXIATqvKYXl5pRIBES45vB79982wpWhWX/N7GvbeX+xXhIF1BBOgmxEMdt h9XKodE43l4Ez8oKuCAZrrrwhQZuPP1Ib9rAXFzlBls7ZgvWZip1k6WE1ywqP/Yly6MuuB0Oscvg 1ks5wxFHgfN2Y6UWaMOBs4fpClHOFy/ei0YCxYWA8lLcY+dXvQUTiLrjVGrqPOO/Rd1Db3+FJmFx IW+hjLXgiqNNyA0TSFZjgy30X24iISozphoF6aKFR2ycmK7h0gMvFtTWx5HSvxl+KLkmsq7z0FqT ELwtiSd+9P4Vp5F6Bc+os53zOhJ3gmgSJhefyvazvee9moqXyNAc8WIvuUEUM5Vl1hIGU7uW03Na a/mGR6cbMn23b564qksEVucXDgAD3rPy8wBCfbE9EyAkD1uPpYbp9NiNj1YUqAKK8ioUOduGWOLY 3KhPplZIWnwa0hYP+jaWpIel//cLRFfno+JRNVYjc+Bq2ye5vhMqocdsZoZOn2Dhy5+q2ZBoGrJQ P9wl8lCyFiz8yiS8pUvfTpQZycn6lleMcECYHuE9i7qHkBRmeCsD503HiMBhZbqfLfZHII0z0ItH VpR5yEKdIaLzXXcCZh2dIHgmp6kj3h8eLI4v1gdfClAYZRJXMeeh41F3unBeMWcwYhE2f1k/VPpz Hp+CIyD5ys1EHpiivEL/Osx1mLlTmMXbfFYHTdslL6qSKDrxa5yDchFWBIK0P5zhHpBEUGa48R/j wB7oCFV6jxqJxqcbmp/hhEgMQuRIKPbK76QC9/RWAMn1Yz632HvezczGDb8RZV7YKkRao3/sXjNm LTtrV2RsclCiuyyKoBcmn4PjJJfYMnCHgGf4zD+pzW2Y+SBMU0CZNys/MauhjhmhEubXisllZy5E rKPMeA3nHF2K6/f0V+THXMBFm/Ym4es6o9tdpHQXZ8oDOPnbgbpWT4GMAUMLhfykuLXOyinRNRTK SQwQC0gHLlbdRQAlj5XSIC+FpKLqhLlKaHWhHaoZcqctdvKDlZDgaQAtIvzIVuOTdE17P4jRyaGr rR4xOfly50prb2ORtAprvmJlMNvVweM0EpOylgl8LzlqK1kHJw3osKxYy+RqwfvwZrK5LGugnzXY 5DP+fKK/ySwp64YmvfAhMWf0fGm0APxLiTkYpGpmCVkpnvgASS1d++xJTqMz6eRFxFI4Vh3nfHg0 zsekvmUBBMp7WZNx8lwvhArazvfu9or95Liqe2kqcIVfdcIEQzPhU9n4bn0jpiTM2ggruz2KG6n+ +/3IH6yy4ZkkMG5vMqODTGSjsaR8tYZReDCtAj23QI0a/jXJFIR+ugt2NtQz5VdRwUVUAVOnTErZ amqa588r14vKXRDOpbDnXWXAAOH7KvH0Y5lNLXQXBV7P8OMGqBZNft4231laf9GCpCINtXnR8Y4W 0NIn00dOGH4k2/KngtfbfafuwA/05BoRphTxmVFr9NPbp8QNzOp0z5JmIR02XVIBjqmSK1BbgjHv 2jP0515r3rxWJ2wzmtdMtLj4y5gK4DNmdrdMZGeny8rdbCxjaenGxw8DmJwGx1nTZs3eWK42zG9T 1DvwR7NJBwujlmz32CJU8B3wcx3g5DjTlqTm9vjDpwPtNzRoT+GjXPkZnoryI2vgawnjM8pCIfFR ZV1WnHjUpN5mNSsPIZcJMVXt/k0zYKVp7LIy1QUqQLjeKTYL8363pQwk/TdBQM3qPmPSjCWZ98S2 66yGOA8mPS6amVRzhANEC9lWGYrGQ8yW8eApaZIO1ix4b02Oa5RqZcdnZBLGUhY/9PMiIXTEYb7c VpaVTDf56hWjDM8bpyWBJs8gAQw0IG64DQxM9jpU7dWjGXkZijwZMUovi+zyxLeADXvEynw9aWae WHIfTCUyoDMeH43n2i/2Y7nTUJdqbpuzoMWL70Tch1Gk9w1Ns0Faq/5cU1rCPO4clDjNYuWdNtM4 CXslFlI0Jak4btA8eb9HBGMyPV7wAkj31AAuVBfiDVDouzUQLkQU9V2SJQhAWz8L8fYXGIq+3i6l +6tutvoAHatA1qzFKbku3b838G2W/yWLjP5azbsAH3TmLtITPhymPz1UlSOfpgbhdKGRWestqSlA TNk9EAIiJedXqc4hU91WeXZZQPJfzcJ95Rt2pFnfNlqKoYUIyy+nYPkUeJEfar1utEVaCWHxqXap A+67ZWGeseEYfEbp4/hVDdmOdk3/eDypRhDbu5Qzvg8AP9ap91gvPumaSZT4a6cjb6SUx4jXIFDL lWIgiLk2q6ZkSMg4nyKmWJwf/E6N6N/F+xYztXdodEvBWyvFCXxabKCepcTLO6+9GzWxWfB87sfQ Wn93qCl2VUgjz2Qv/Qe6MB1s97bR55imvjhekehw+FvRYvm2ZwvxhWwrioTnFZ/grqKfYRXB0ZxI INFUjAENZey5dvitizMUxGBrJbEvbXUyASAi6QmY+Q5l1wJ45ei6gzpuh2dFAUlSu0+JsnJBoAIq XTUxRRePT+e+CWeiX65oaDsowku2gmk6+/nOqxIjqlOxoFERG58LIi3tpvN3+1YiIN3j2nZ4CwvQ Skzo4880zf/DHUhrpaEU+RczAuHPVeh1GBCElA5sdoyhXa/3jrdN8eqjz9wcWzNEHWD6ecIXjjJA La6jlBJ4Dig12silY7IBXakV/vopT/qtnNWaPiS/jmegk2qjwTyYKszMiu/YSISIVXLpnO8rhUTu 1cnXl4SFy5XvE6vZiB+zeNKZZw6Wu1Csr4uGim/yv5TSiFWCc7HTXVRdY0VnvfrHJ2GQPWzCvpYY 76h8SCf5ApHaJ5nJ0zAFDueWzLA7bCLdUYMER5Zm6DPbDt/l7y1UA6qLwND+Ai8ybcYEmHO+RafC dhKCGvkdukD+BKTMW4aWBq+eHVDMP3/nZ8TJ4Pab8WMXxDrpFlUJA0poI+IOqhguG17lV7fAg/gH lC9HC3Cixnq6QCW83pHUkb1zS2BPQF+Bsj4inIVw5zMNN+HHWGb0txrK3uw5fQBo8xa5HBBdUxx/ tcsoldSvqaKQo9ah0hBodeUq/PIb1QahFAvL5cqfk2S3G1VlxOfjSSATdwqn9udb7DFCjuLQspXG br3lWkfKS2tE+wpJvgDUv3Vaq9+pNC7Ur6ykikx3FVh77AzMCOGbKCmOByvvl6SffN0keGreJMKX dm+DHvUa/d2knC4RwMR0mZZ2iaD+J6JFciHpC06hrw/3NzshOs0N/WHhM2ciere+uEQMaXKpyJkk LshtB3sXFC0FN3lQmGg2Re3Xsatf1NRRm3rhRdpPv08Msgtzz98A/LQapkktYQ1jqgtW0vv3wsIA tunQle2QUIpOhKU0TA4rltmuqLDfellB+od7/0kFrEn1BxrdnD8dsVPL0zSKjqC1MK2mfeTxI753 LeqqeAXKxuJ31ZqBwTBS/oT4gAKCDJfuM6kj5+/tVdNZN1FKSuGydLT6sZiiP6a07VT7+kBGOkRU v7Mo9eur4x0rnMBnbk5nEJOhVhUBW4+J3T0iSlxS/zR9aJsUjhnwPGzW2sS/7ZJdo8BOS7u58Ui6 yy8n6lApjzQkiWWDVOd2FrwCPY8fgcY3/QcME1v6BBKyc54JXtUcYL8u1N/LBVOsWmZrq5JTHxeu ImvQb8UNqHQlKhU5bGCKKSCQs5koavwCP1KUcHxyJMLcjwO7WhW2xUHIu92VS+5Kr4rX2kYadCVQ 0Q6zDG63zQNfebrVhr+52SuxUmAyDsNXcTRO/HphV4pkeUZsDv0WoSpNLZpb59TPbTET2Z4YzYr+ x5DUKERcCkPnZylmTyEnVAqPA8TWOd08vSdDK20HnqOJYs+l/AYb9UvItYmY1xvA0tFKkH9sOQbj DBZShkcKjJiTeu8HFTYsZKr6+l6mC7mZL5gZ+rywRFSIEMgbE32qnWPOD/wtGwn+kF0HX9tnQNwd dpRuSeofuXSx9sUnF+FPpEdZFpkDLYB6+u4VM1epnX+c1CtQvdX0H/8TtprSQOEFbAlWiXH62i4S HYv26J8rUTMJhJTveLK+8Z7s2BOKOJnhmaRdNcmeYyuCawW+MeGPCQQFbT65dCtWXikrmBmlacJ9 TxaiCPZ8AlqIpq2v/Q1vzqnqn6hzAraPNeJOO9ebhB5UctT+QMP5LrO+CUYj4U0UGXrf3gnZ19pU iXeqvi8F+axsmSeCklNOmU9MNwL/y0YmAGXqQRJcVYS+wgB3iQsF2WH944UdEc0JdkIe+K8KfXqT cHPdmrFSier807h1yF9BNs4772cYYtv9IeFkIUgmDuQXyuD9oiW8slvODy8jdk0zOc0SovduZnhb GSYzeeqAcdTcG96gp6QobQR54bYhaEZ3hgyE0dNxJGMi6YJq1T8Oz4QtK2msUrJaYN288Qwml561 dy6Mty4af9cG+HXRakOS6ozQDUYCmEnJJ+AsXMonA3RVwWyVvavMRndPkJRXJihh24iXPZb1FxDK PGZCPPMMZhwzzaMtetNOaBfL2CRVdnrmEZU2c86lY9bzaBTm9AbzFr3seldUg9iRuL6WAKHtE9JO B8E62NQMfAwwBLpEh+/m43GM7J7gXud9DGLivwlaYlrjwRm53qzIBY2tWqcNI7dgP0TveHVnFGyS tk8lPiuvugcFfqKsKMJL+geGhNaXAeN27YQovfLNnJC+bqYW/oukcYtk8Vv83X6ivfHnJT7vrkzI IMFCumSmMevGu897VvWUR290AX5a7GzRZbTw2OOjXG/VaK9wljxoxhCdGQAHC7Y4e5scDFYXdeEl t4xhvkUxsfJU7ilHfDuQpRZKX3sVmF53KXorxZAKH9mXcvV/YD2NS7ILshlM+E2F7ySnPLD4Ka6r 9Vkl+ueFE3zTdHqa96gK0Hs7PvZ6dVsKLF48ZRfFtQe6jGomVsalgDtv6eVQGLHoTyikfEyfxSPR 7jex+x3nfuY8cGwvJsyHWB/kL0HE+3rA1EQ4LfSAYGly4dOjj/BRRy5sdKOkWgLh/5ckGIxn+O+C HKfw6LAe5Rykt2yb6UZIQwZCTagn7iq5TPH2yZ7AlkQM51BydvmTSI/ayqFUCHMehc6j6p00d28h 7+nPcLhHh9f+7uS4j0+O2HoCLKaroJVjPXQRs9kOqy46OHXL18eqVnNgkens4E5Oandld1l0RBg3 7ekyWn5NAIweHuJPRfsq/aaoSqdEsh648jDKiqCBO2f/zdHSa0tOPGBFomGqbnorFuSbWM/H2Obd b1coA7djx0niC2QR7+WCOWtX2QNiPnSnqIg4TnJtvTL8Ex/6znLCV3W2WG8BNNNxWStfjkbdClTn +hPZHFd853xjr4V9rIPb5MsmU2pgGau4ozmskxLxYwhM1QxAgHt9zfS995ME8lTykNSsrIX+wk+g K6uEPEb7RuGYsThVHv7ymslHee22g3WB+uHz1f44C7fyuiI29K0jxjK311XXajXSFpt/WtFBe7Zy rbhD05KfpvBWArkvvKuimHO9XJOOn8aA7ozT+h1vJ8o1gmDZNm44cMuodlT+qBKo1NJ+uHP0vmeh VoHm+QFlS84Rrl4jsKXLQ7lR6XL89+vJqS3mjjxt9C/NbKJ0/yO8Onu2JYHr3NOVyWmkn/3P78GG MnF1rexeeFpOMtda1e+BHn9tZoH6YxNGxo2rxEGeTiUBNqoJjYPhstuKfJWqsU4c5zazar+24VGb NuD+eMKxPyM/OdFRtC0+SkYfvH3Sktn7XjkHPAWUg9qi/mHQN1Q/BQwQbWuJYzxX4vXihS0Pk3Ka 1U1vyHP/i/toKYbF8bxTy14IhsjxSyRiD6duVh27qN86Rx2C83IzXGYD2aqvyfGXboEqbkaoQ6T/ 4riIL3zTyh2VUIghMTmtLAaMsejIW2B5NADKmhCc2BGM7/OyM8hgmrvXIwK9TDQKVRRNni/LvAgM ah1LqVSBgphqLdTDDD9Y9X86UiC3XYChhs333HkaYjbRt5iKCSJP/er96z60vPpwLz5QSnebWtfY vW9Q4bgbhzDK7QnW0cb3ORFfKFxCjlUP+efOI6JEDh+ZpYJEAQ8AH0LoEKbyaKsKIxallJ2qNm0v xX/82nSt9OVzsfFcPjtGeSSUOzRGRNN+Er7duWI6HSl3X/vj9eKfc6zvmpgEwvJ3trfnvgqr6/Ib 0q2rRnoyqBdEWSw8ldKTdSVlGzuQaltTReuk167ERI8DUS1vi6965SCxs2tkmo0w/6oZPn5j52bV xcyJH4xdmsgI0vuiZFNNxuEQ8W3ABCa5KaSHBFqqJImiP0D4xau2AckHwNt7AzKUtfN3MEXtlAxl Wf5RInq8S9AAaW6Rcsi3dLT8VB2AzoheITQtMxF8Nsw8XojABfnfbKtQsF9+vGUqlSjDpp3+Ngk6 ytDpYdgVpb5MMBP98V75g/UbWGP9ZCEpuVYxkuGOk2v3CUGYu0zQkW+UUAnscbETTiwRtCKATzma PImdTkzWPZFHIZf8klFJ3tAFM8g1JLVq/N6H0seqTLQtX7z4TwZKmYiUqpajRTYQ8kxManX1vDiA BvyqSux2z90NIRwRuhjwy3k/dFQW9ASsuWUQheMoO35zT+8uT+44FlOJbN2UM4L3VRNAxuqnPKY8 mR9sxODt6zByvM7fF7pl5vqO7DtPcx2P0NRQOAsXKXN9PT0UKw+hE+uoVLcCEACM1n7ZyDQxt7EL lwq8OUrqfhjw7B1xdtaxtuznI3lNYyYJxEanJflsxPzsGpg5jL3PbltRbDRUMXM0goEmr0ZF6JfP uHjonMoyZgw4PD5LH1W04J1hxYsTgrmRUiak7a8fcvdOfR3e7oMuiEv236HSUwK2dTnREm6OS0LU qjCWu2fZJDq+x/F/w3Jv9/2PYfWPRoUCxlDqpe+ORQbI942BQurDCEJ8yQndRD2G9NDy/784geY3 YO3NrutoMOK8ZMAW2y9AhIY/c1igjkB6gNt0u86J9ojINqxYYflASCkbLS4w6N7KNVM5i2U9I78w 08l5ZglF6T1t3WW2NTkbBeF3AvbBo5mVVgfSrbRK8QW4AOrNHYG8jjgeaF7cStIAayJzthGzy9zz G8qb3ywgY8it1rXCfOli2zEGSZxgBag+VtlygWF6TkXpybMM+aC4p/Q9IvV14jZIAv36y83igGVN LGHzb1h1EzJFAPx/aDvmAPa4IcUnkUqnTjbOMB2Chwq+2HQfAA4maQXcm/wY4YsuDWfTIrIyMbJb DzQSLJ86WcMlBYFOel0EAWo0AfUJ8aiFiwWAsgNecJ+KT9H91hlqXiypC3Cu4HsHJQhvoTTgrP4M dUmMsnVssyB4V1mm3u3UVPGGR3uzTmZHPwXCFXtDJikXz4Gq0BTNL7CGTj9shvWhAcmhDb/83zmV Nn/tcv1olXLIxH22QPMV/aoKn1187bKRmWLn+Ie8Jq7L1uHutXpNVQqDvEA5402BnPLHdpYhFK5R f1nSTTLAZy7A+zmpv1yU2H7SkneGb/ZDfgxExKBEXWMfMA1gxtTESWcHRMGGSeejGpKUJuI7OEUg mFflekTL3IuHPU/rJW13LiUbdsGSCBetraMljU5eEIAcKijgWkhh3aZmNHVNbyt4SIlFTJOppB5p HfCYGYu2UHw22Jr3qbbMJBhBgmGTWGSik0M/6KyMqR6wrVEWc/BQvLthngbY9B3WgZhVLIurGBja fw+YnDWM936ub+ZItEUn4oewLTpJrcBpaOv6Mwgpu+/BW/CRUDaaA3wfZfqwdJm7TnzXNQef/qlT FnnNS+3BG2jZJbqLsfgglOaw8oDEdmjIsIIoYvfxdAipkCNIWvCaLGroLXmjhFJDqeDMAP2ljWMx iJvZNIItsJdRo4d4mFxpLHIWRUBg5IouTiOZcKqsCrWDKwZzfiatymUZiltcxol97wP8XTv0E201 6xXBt1kldc7+5jgWEjLXhaPIrd6xn89BftN2thhwzSMxZF0iiO52FAXDP9BmRvhibXYieFddGr8u 5O67acI3waWHCgOuKbzr3vGuiMg8u5tGPkEXDPDcAcuY8SJG8ivsNTP+122/oxDC66iUdq/gD/0e W6bHIZIUvA653WoDVNxXI9MDM7RNkbf1EoijBCtrz9cv9rdNddJC+wHa/zxPR7szPxd4H7WEDbiv IwAe+Lha50jKtBVcZZkfXcv70/T3/7ODk6gk4SdpLbIAgzirLFU1HMdodkncXusFzu+TI/hoiLTj +M4k3xFooy+/3Ci4m5LRKMcpotdT3hBrbva9EGxIMHq02hoWV89U5yz/r1jKNr+W0vLRMsnLqRMT wDZMOeuxSQByJ8sQaPMZdp3IKBqGXgXUjSaDQoJQuyy2GAHBijVU+gAlEPFsEfOQqbtCnpfCSVq/ henJ2/q2HnIQ4lAz2t6TS9AIBda8PN3fTb0xBI82TMnrvAbIXsv0Eps2xv4+1ys6ssChLMQKed77 WpMHhqBRvK5hVTfEbQIz+jPr0W92p8q4mXs/rHdS+yEXWWKME6KQWKkGCDHkU7uI51cTzv9fQFEl bXlwResTFv95ZJ4o1iLGiRKrEzgWuDuYEDbc9jRvVB77GZzWR2Cfw2qP0UUbKRehqun3K/rxADjI 5oHwa9VQz+7D2n2B1LwsSCkmmbL/AB24S9F4lwQQFFyrrB577/SiK/WxaP10cJTH7YLm4C0jbMZL hw5DVZw5zRAXcHnS+f+lk7jl7EVgKnveJZ3CjyW0ej+7uJUHdm9wvN2xoXBLifwbx0+5f0YJwXBe HSUR9/fY7yczcgm5bRJmfLrQhj0CC3R1oQBU8d3+P/oN+YJiFWQquS29j8Y9Rc1nSTIZjJHwghkF eRvdcPrQ/nQqiwfSSB6tXxX+Vv+DpUCRtUxuTJjtKrZSsP2xxMCu10n6q57rDH4ScaldpSphuI+P CrpMlYVnbor9NbHZx90QmJM8/41icuMYIrqAQ9A6PIdtP+Ct3nmaI8ACd44Awofcpqf4chu5qcrO q+kZhohKSnYPsQrKi0wS9f2wnpdSkHT8ZXRO9y3D0/X+42ZCXlonQPSw3AzPjuGVRpYusHvThwtS r9wLLKjysKv5Sjzj3l3lXHbso4wMDNaeBIvLiv1GqE5kUkF7pJNoxyZj7K+8rgJI2Wi9e6z88AXz +jsER70f7Rd1ZWXtIpzIXRzBlSxqyhxfc2zeTu5c4HxhV7QNEvwLG/sqq/gz7Za+hMpbYNc3/0DE y5amgTggQyy1ukebY8hsqfq028rq2HEAbPNf/0Zh+FmsIgbEZWZjw9CBspuaB2r0V0Ous5BvaQRC UFysz0bWQhdCp9aA/aIv5pWLI/uct/kPf/Kbi0mFzOz4F/Fgsq08vlNDgLjjrKAoG1aQr+GLg4I2 Mg9HiwAJx+wJK87KcBKuTv7j0U1mWGWCzYpcyiJS8e5e82HC9CPzZH72kOQ+xjH5ls5kTJWmWJn3 lTMa0yHd18XZhyDk6GCJox8yFduWB7+A06OgRDZn5AiwnIbgi68ACNj2jZ8pRo9ej3vAljuwaGdu 9OFFMw2uV9peu2Ry2aKmHfsfIUrHI3Tfp8wNIUH4Ze2t5t4WJ6o0O6PNJGivugOG+5MrOIsLqGmg 1BfBox1HfpWQUCXVfMdbkF4UCkm+EqDx+6vohSEkYDjRvhrRsim5lHHn92htgLMtQLlj/9x8J8we f73EkOGFD+iY0G+ah57H+iI/jSwWXAX4vg4PZXHAGyPQ6cpmZJU6oKfEvFG+3x6DWHjLcr/yp/2+ EQEvURfgjY6ClgZqAv/e7R/fbRePdrdmOtPhzmHfqDhJgZ5VlX2x0Y5gfxvaLidgiKZfDbxChHrt /rmLMRV670JFgNhNBDhNs9s6pV3vhJapnGXLQvcNljFgMbb5SX9JDPitBqGO7ZlK1Hl7i8LLkMXO 9vRW6dZrc8I7oJRZW5xzitV4+DCQ8dibfvJ0p4f/KzwzStZMnw0h9+wT5k1yCN24fQ6dEAFHauP4 XKEDNnxt0t/t3nbtrI9Y00SGCP82eCctyh/nBtU7wkocjI0cqLsmLw/qPeu1tcCEaMOY4qESE+nP IcV8SVga1Xc5iUgC7R7IslWBPsxbZjEQPkhY0++ArWsZKDoZQ44q+W3r0PjS2+F1zN+q4jwwtITi w6MIKXVfVj3Z2QKskWYitHa1rBAM8Jh3ye33QF6l0MszZW5uQbGd/el+XXNCekP4v0AXrHHbM2HD xMTKIOkCgKBcroa6M9kS5br+RUmcZZAiuD62UKgfZIYaeABFX+AU0cz76ldDY4Ngl6P0imE4nB6k 0nLdL1ujzfh+CcOOlskM84HdtYlHTsjEychDvcdxDrim4LvqwYL1ujSapgfYbL3OsDTHb2IAihN0 qfigJON1Rra/kctRt9WX3A2DQpXu5BGfb10VGZ/0sAjpMHJY8jdD91qsLlkvHxDpCyrsTX9Qz+A5 J266sJvBdB34dnjInXa4WeZvEC74XvEYygBRb7SVTbo34se1gcZPkcZWZB9N5E2a3pJXOvYILgxe UbI8ZWlQLkcp9ht0/XRy+ao6M3xACR34OBK4T/hJwYs/6ZpwttU6rtcDeokiNUro280Y3Zjci9r9 ixRWsUVRW3KP0sYpQOYOASHd+LHW13q5ygcQwoEyqoZWvWAtEeOC30lFYOcaNS49Tt5rhxbCBZzw Garby0r94vpsWyPLdaHCjJU6XnD0aoLzU39mFMd7/1IwYdYG9CBVmq6ROA8CGhN1Jf5kCV5QXQZP pu4t2nKLtPCnbVpiqrglCuizQRsSHzqYvvM8GvzDEOhH4AXtVENzRW+Y1EOlSYv6da/Nt9sQkalz ASL/MBWDIMshl9PUwNNlOCLJgChYudrt/1BFpIzrDFLsABrQ9AAth2hDxuZaYQcdKAlzqr3GTmJd cSic70j07J5mECD29jVCjbj7CYDbPSN3ejyl374bAVjKXNVAD+FQ5QIugXrUAcltC499iBm/P3Lt 9N/hEn+eKy1ztXJlN2mNm4XAtv6MVqfJSPoYeo1WWJaDbe4F5Xekz7zTo8tjGurcWLIWc8ZlvUWD hIHusy0tEgShtrVFYZWb0WqTo/b9CBs9lo19ttjhMXLI65JDgynCF1NXNGEsOWr1szbT7E+oTzM+ AkY3nECR6UtShbA2crOJD2Cg/uoajBbWhA7gpk2gkpodXqmkRn6eU7JqMOx61dYrQV02EJVWHqsy 0nThLDNWS5BieP9oFUZv94fx4Qz2rRMmMlhFqozDGBObSoPiW6gfIIXEJbHv7pTBmXVe69nXPAaf hNd92C+7/KQu+ui4DVs0H1SGOxaDfeOcNSlj86THbWxd6LTmhU2TDY2DmPMwlmeVIbAtwAG96DGJ mgP0E7LlSZGWVr1s90HgMedZHiUeidN2yrrgzK0zWh/1dTHaqNSBct1g1E0AvksMb0CHPQW2ZeJl tq6wFNGOyu8wG+iiHkWWKg1wCpdTuvS8GMWBzcV29OGGdLN9gduslATXgJcskiHUXr5Z1dXtcwps yNr3Ka/JbqIlr+/FygsBPrm/52PKqETNJh1uA9bwJoD7FDAwYJckfWnoX2r70UQyOrsLpwhXbkrH PjCGbqRkq33caJKQpZG8tvr+AYc+hnXxhAhgyy+/lYdyc6Dip4gtwo5/L22B2S4KCOMK+wXaaI8s 7Egdn0Oqpi4gt4hW6SZ6Gwu9mqjZtqtddCeOTxBOwG04tUxQrx8iQ3QwZnJqoBcvM7Bg3xbEDvSd AWMchMUhXByiZyT3jQ6eUuj0hrChCzZ1aSYmxYc+WF7tNa1KH2T5If/lkdyaqhGPOLY3R9SAu8hV gh7Sk/Op8hWOg4GXDguUUuTmN+W1hvlx4aIcdg9Lw+2ummjalacYsgYaC5A0ait/QfP7C7cJsxce a0Cop3e6TVvspRSMwIZj5PqCYixmFV+YZFeaKeMMjjSMHojF2/7BTTGKys0ie7bfwk4Vemqo/E6Z NQBnrXTjfrdCLZNteNCuboEpWdF6Y55QJHdxYpufDbCzVfJ1XqngHGjs/1AtjfESw1/9p0s5r6A5 z3MqvL4wz+wrognU89Knd3MeNmovf3YC73aQ0Jz+XMvNUU3vZW+GOytDzuKDaZn6vIGM8njReXHc NaxsScRl1pX09csWT9TEepo610PXPkcMzqLfQC7gZqhPpxY3i7FTtjp0AEn+wj4hhJUvg70SPqqj 5M5nf8eCiKGn6w+JD92oaNJuEtAp1D4ozKkZ2HdQQXAeoDhcjqoDZ/D5MkslzyVaWyHImEq6BuTR pwno35asXtUQ5wCY8Qx2QQR85v1u7h7j+heq7FE/Ldb6PyItVh/2k9EW0EYcbulw9/K7ERJDnfsh rGXTi4Ainr4evC4eeo0Zsl9fstE0Eq9NKmpvhaT68+nV3fXkP+ft2ijyoiaa+qTAgA89/kp3ynHN NuyLx6DMWInzy6XxQij935ovyZPQ9i0Y+z/YzpZvzf54c5VVEo/GgmVfb+h27M02vsuIPg6oqSRL 2gIED/8j/dGhG91nnp1Y9Auo4jakR7JM624Zz3dsASrv2GlcKbEDgqh4LiHTBC4DOnwem57sfTee PpZhWTbh4djZ5AgwC9UgesuhaEeXXMu0KBJfScggJ9h1Aznn7BUMFUY4r75KD1iw0xWMI/mdzPuM ge07qHEoPlGtZsBw+yWVpr0GtfkBQr3rdf1Xhph0jPup77iMaAaIOOqt6WRktO+lgermPAlrQI/y 5gmHaoH8ijoNpbql/eSUumWRW+283IHAC66vJa3vTTvDnV4CEaGpZ/pYHXctjX5+vBNISra99AEC f0D/1MCT8+oR1p8srqAjkeRcqYOfs7A5FWZxEnhYQ2QQU7np9wi1/N/nIH4lykKDxLMXAUrSZC8d VgNnxiJ61NAvLq21Sh6GwONGB6ncjNiiLMgQ/mN7XJu9nLa2Ix1Zw1NJVV+oixkP7OsC6MNLc9SW lAvGLDGTjiMLbqkj05eYJo3aevIUIXuzviGo3KKHjDXCg+RrMMSb3L+VdyXAaAb8ERI/wnODIuQg G32U2AdKoGeRlr+VE6sjm+nGKuUN+Gi0+sIXJHXvVNkv32PmXEKpYxPu3G7UlcrTmc3G7u5W51Ur gIUdPM0bdtsBEKqGG6e3nWcfeulvmDIfFs6waP7c2y/HXgyref1ROHmzquqfCpF7vCTTwsUgG5Q4 PtVCVo9mwfxoDANclhg91Rr5nlXIku9GwriQwEFLzwafc6No3kufs1NubbJD4x7zY34znyeRVFFx k8bFD8avMfnG87x6d9Lh7YC8jWgjJmEbbuzqzREAhtY1ciBTZ+C+UwqDU4AjsClTvZpnlyfTn6tH +pNhDkTvr7iUVgErRRb+S+BYANmC2W9W2tMc3bxto/vsjMqkVcZzHptPOxuhxwqbR9098a9xl79B eaxIU7oNp5RCJmct4q5rjtEWn2PoKrMx3bJgezI/a7fwcy0TsWiB4otrd5GDn8dyx/nMgl+yEMPo w/N/ddNP3n1rOBXNCruZkjp32NULdT5Dl6vGUlIetT1fMZeNdpsDtK2w/R3q1lB/ccIuEdn5RDiB PMcLu1t4yv40BvdLqH94o7bU7a7pNm6d1dNUccuc6nbEaEVTxXbv/zEl+FN7F9DxXsmkesFtdU3H DwLzuPpNke6dwXJmi0DCttv+UQiRwp8FfZ4+SOpNJ0YmpNtDRamdxvXHbGVuAHv+Nqo3byJ46+hO LxDUv89WMYbIpiK+jaJTSYlvzxhJSEivUBGapoxumYo8vNnNfiTA1enEfzLRpR/55tI7fkgAKH3L AnhuPPs69/XlpHM+ZYxMnJJPjC/MEyn3DuWsXIjRTcUu++fhJUpezyM6Veu5SB2qPcD2So8L7Qhc BL8PHqw1xKwZTdDj/bB5mkG/azqdjBRxT6E3DRmdB+a9Wy/IKUAxqfKnd7R8jiXEROwxmnCfFcft /s+/GRGTmCSA8ubtfZEQ/iHNYBibOAOEBa58lm11A1qyD7HIxUxqAPAESChST3pR5wMcO24KpoUe Lsf1zEzXrtTDLzRZNSyGQMa8HngR0/8cKNo8egx/a/tLt2SCRUsgQ+31VIXlfuZcr0wQ7DuICsKU cnHMr5HQc7vTsEss12tP6iGmYEebOk2Tsvp4Frr/uCy3Tanl3wMivGB0w/skYFxmud4VpS33X90B DWzriAsn3VPCB4By0irbdLVQiI7tP0pm+izwnpXj9A9TsQfPhQf0iPWCdCBsppUyxIj96pnLRaig GiPEU2UH3hZLrqeUw8mSeiGQKAqP31LBoBJg31yrnH5DGWan0umsChWMsAeotU4kRYNyTs8VdqdC 63nXz6LUba7DIlfT2N033DYIFXb0k80PVnmX+u1VKFdhf8U/ZsnaJHPk8EY4eEVWMLoiIGH4tGF5 YKspWgPiGSttzJhFGmU0C4loX0h7AezCo6xBdyr70RHqpaFvbZfn7cNXseyuTQUBnAK9wczAnTyR t7gGfIwl9xIMbp0LT2i8EmJ5N69CkcEdNVF+jrr8OU6jwYXAO9YEHxkWwMvR/tqfNTQkY3eTWSNz K6JeGBxhUpdu1znGiyCqtv9woYJwwcgmCYZunacScolfa5l+UgmbHZmKkXx6AXAKWgU77zp1r0b7 YGes1Y0tghvuImgzIIeHnxjlxz4j1rWQdWWFoPIIVxnNLNmnI3WWZvnlwlYyRVYAuoZRxpOJPJ6Z Udpcc5DIWApK+C5x/B0QlPYo5ptaXrBcx5SJdh4gYPXN0oBaXAXbLdm/ZJSowUyThpYnldDQMbvQ gMiYtqB7KX0Z/rRRbo23X4LNNI2fEhU6yLs+mi3gsQmgNtSlOeoP9LAAVIi9BmOXo6k9expIc0t3 /iKqEGW8J9kcdAkjemXwQ7G8ShboYPpYZ0HGNm4oFZiszAXGQfsFhdzBOIauz0BnKY2Hmmev899r 7SnyVfWshbitl8U4NOuLcgjOesdpZRQAfKMoHrWfeWNzHi2CU+FZFHHar5fMxeYhlRdSg5Ajjb7t 7rYugCj9n9XSgObk2eiQShenbwJBjHMW5wJrYwfjlA/w3+ImpriZuCuOB+NNF5Wln34yd2QXldls LyzScBg2/qRX19hlm+3isVRbezZRcBvHTmSchbF0JaVTPDDN5oejWL4i+pYhqS/3F37UQLD9f4xn xywkdmJfxSeHXuAoeLW8SBgcaanhcI2ELLtALUxr2N+hKORZTv96l5mpGGLgZBKEdcvWhe20GXu1 ZBDwewnRDgsRqcmCoQz5kbuiH/gMRrgOZE4m4Ucm04H7Unjghprgfijx3a4UGS9Yc4hDhQJyAQ4B e9bBlRwIjeDUzfMTbheOhg7JoUnp6mAf1jJtQT0y35WQKSNWyIiRcGEd0ldJs1PbtrsSa46M/rhk eUfvkTfK4Pkt1JKJb9ksyHVyeS9rdrQmpZyS2iHjdJdnXQKNw2THLB65JMV17hbrZGCAINFcDQcB b88Nz10r25LvnxCo6YHdbskjfiJY4bqLnWuteHBjscGwu7kh8k6pYV7ZetWH/bbWRlFy1ekAc10p 1ZLjuqfAy6e5wA3bbl2CGpdt+oP96SgPoYQcxSFJDFbOKwtHD3re8BYU0yEVm8m78dJDulzfoM3Z oXzZfCFz4W0SqkCHcvChOV4vCuzjWtx44Y+wlfo9hjWS0YZrtVI1iGtUBbe/+XdqcG5M2vjZ8+b6 5/wkilKB7aUZNl/UapgJV4lbrQh8gSlfX2IusEannPv1n7TJ/sRzyndmlhWNltybI5CC0GAly8um 4qZUN5O0J4aGzE9HRbkGXCF3ciENOHhH/33Ad+ZZgZTbOyF6AhEL75rAqMw3iwIyotdJcR3B63PT G5cSsH9jV2tjLq+GuMJFD+8pBaPegJAwfHUmB0SzaYNWAXRZCg7tOhGKqUAoW7lyonvrMgpMjhz0 IlOBerrDYTzVvF6KMWexJvYwSN5e/ADEZJvGkQ2N/N8BdfqjErlWnK+3WGuhDr1Ul7Lf8uf3QLWe ei/qrrF8zeQv6qX4GbIEvh8Whw1iBM2RF1Fj4IHb4uAw8dB5MZS3qdbG9yg71j7Jouv6NgGCZ2/t zgIpB8oy5o75lY8/wYYeQLtzjyzBB9rIHtkUBSDzLAo+rl+NtULqVDjVqkaLPMR4Lv1CzMQ9NEqD 8U3jauFY3Zv/oLHrZnC6PLz8qpTGvLjtokpeyv/mImMhSWgNtIC5llhtjephZLWTyx15iF5goT7x tb2hrE05dl9rGn+thkafkP1jOCKcZNGrUKnrsRtmxA3ejKAVKXCTIP9bKvLni8eLZXtCPMmaFdFD 1P5OJvExML4h7l6je1H1j6FpHSmMuPboLQ7AwHc7UE4cDaXeSb67YlXJIAeZcog9lRLp0GMEiqaL g73X6WGvRuUqBBTzuaDeGp12djg70Tvfa5vMp2FEWDSB6bJVvgDyWuLjaPjD/Fn0J6Hoj44q+7cV R3F7yftIgcfE9+ynqbI/U7KVmKVlgqgl1X9eYULmDBJzrDxhHeOWHU2A4zKxjDL0JPj31c4qtiGl 6Y+/T6LHakgALRTqWBaLgvUakpzkbh+zJS1X/fmP/eJfTb3sqETJvwjl0rqiRUgj8l80CbHzBTuk C3lvp5x4ON9a0+CfjLtiLoJOh1laNvL4+SXQW8stcca029mr2c6269Cpfx1n4W3XGEtCP552eCB+ 7LGIPxN/NDofcNcq+8BoItG8OIAnc9uTcdmBtB7H58QWe/srGjmdt2WZfSrnnfvTjdDFEWuia7W4 qQLIDoqNpurwdK8uGRSTubfEB1ysSMEF3yXumzAw0l4B511H2tr996HeuQpLs6D1nW7ee9WHwVAr hBtkAOs1DrmHswuBmaZRiKFqht7h5+C3yxhdzdS+Pm5fcb6LmKTyDr+XczywQa4+L8Jm3iNbN/aH ZigRxi5IOtej5MkiCKFzVmWy8OXf4pjoDcAI45eEcVnSxK5tiOko1byus7srBuh/iP7qlynAHJ7U /TGZE64B06jkRU7+Tc8IVjR70Q4mut15pdv0ihdpfeXG+mzswYEbIB2mPVxrdkEiBCRSVAjO56Qw pSIA0TTvEdQEJQ6g8BpowUM9GNrBGS+kGyQDXp1FOz1uhrVyI5WYy6bXbzKEHCBXIJd25F6BHKkr m4IIaKQdYHS+XkbPBADZJ066F/j+Vfnq7j2GKN4mW92vZ9LK0MDtiX6rWJOWAKsP/2Ln4PrNPQCN myOGxhx2wy82zVOudVsBvdPGrFCNeJk5op09eXkGBgf3VTAWief2OpzyGLsPmcUHWwjG7aGootTa +SyIsUhiCTv9KEs4cxcf0itoFxoEL/XDQMGTNW3RbKJPyxHGPlibLMhX7T4TNu6Z9yiBgb5yYMXY cTsH3hKTw+riCifUYzXbUmZb5m0G4xaR+8NaYH5P7OFQTmUoM3+6bghzlqzJVvkT5ljmwRqgTQJ0 Q9CC99VR9nOdGRvWQ33ZbQyG6CiLUZO2okL2LVYM3sw+q7Y9uyk1O7nfVJBXzyPSQW6cGNrC1fLc zEfBK0YI2RKw2aLRZTL8ZoEcJ139BhT6gqaeex1DlPEwlYZRGMUmvUEnPWZOVoDGWwMTVQ9LCJkg k/BTnyb1ILSdiBusSH5E33vvx/LoXSWj6BPEVQfQrUHjpT/11qygyma/ArRRpk1udYbx3vXUnD8l PRZU6Cj26aY+0a4vtDZymdV6ilBCDIfR65Ku70+s1KQ1yCLLmUCVp7M1AIlvrb8WrAcQM7jhJyko mNMrvRxX9yLvZPLQ5Jt9LpBwMcNKhNYxatc7k8yK3/w8S/xQvfIqtTudjK4NeagcGTt96JpcOrkf GReZyPu+Kmj+bNwYRoXZ18oYadimPEh46g4azvGcD9iT582d5NPYU+Q5UnzID4cdvIaIFG/b+vhh HtVlFNWYt/DZYcDx5fMJmE1mDFN2ltqafXuhthEaDObbJ53AWKOrrKjPgWXQf0/8LuAtTFJK/E/H qRhVIuK/DADSPsIAqrulmzDH1profE5ONeO2FEyZDe5Ff/UrHeLLp9JU7tivUbUo7ZwI63A+7T+S 3RiWCcIQxJyrZCekkNbGiqymXVRK933vzoOBmfQuMgWrsb0ugsPLFhW7/pOGlb90XEburgdYJ2MP 88Ru8V6tm/4YgtHN03J33TjhcZtnm03bKmsxHZQbqbYhTT2AYKsdfYugt33UyubnXmxQbmeWc0MF 0WPQKEIuPopsfI8GbIe/PFfDqcdWPF/1oSicTEj0sAtyKhdF4wdEFgnaRFGwLwJjvYBU8YzNsvZ9 YjUVvHhPuaoRxCAUEQFIHX5xtypVi1/O+2qzGs4z+GP1iQfKvGt0WyofNaVtRYdf8nk9HkaPUoam Xtp74nXhASmcjOhDCf43V5tTWpZNT2ovauW3S9lgo4Mf0QWcs5Zx5tqbrNl8Ox5NVGSftknfXtil IHRZiIDtwn6fLvp6lY+HjAHsHgriVkCJhVrSoo1aHE2cibwqHdrB2p08vj2AxA3plezd0QRjg8MG xKSmZbNptGfc9dPP0U7xiEJ1+v73oOAWrCwgpNT3tDPjYu8L5ByLWGZ9dsWkJhxQsX1wfaUEihFN hKoWEHq/mER1rTSzNlwK+t+0RwoZpxbXfKk3ZlJ9bdK3sdrf3mJhahaDLHkYXwJvc27n3zLNOb8Q TmB/XW8aO5OHgIITHK96K0Mzu/RGUxni4QaOGokS4XhCLTLaIQZYtMlOpvVjfCYdjjpPHmGbGHX8 o/6CqFiOHFZlPOs14+IXiInzaT/8ag4zE/6qKsH4kmN05QeE4dR4cOgPuPvFF2m1QtTXNhyKwZEG AajFiFJIr1hQ94oXu8A7BUG/+7qqQ8kimVDppU7wuP6hR4w+pHF/ODty9EHwWyaUEZv4nLwsf8G7 lz4Hjr1h0d1L0yarECwfE2rNvv/3oGOM5KyHZ7mY7DEYuF4NrPDoNm+8HfLn9F0uvnY5pAj3WOJi fq/y2ztlnSf3ALveZ2CeQLewkUhmgqFBZW9ZJp/ro5twUTxLZ/3mFMZcs2lUvxTK2A1ouNRaOnwk QSvahyKba2/DPaWUHUOlz6Lm6YUcEMJ/+c3RFWuEUCFPeCTThImFP+YwRFTjqM9PrrdBQqzZ39z8 SmdkyD9j+gDvkbI53u8Whva/vg3qqaqVT56oQECIauDIs89sQ+P1fekHyTWgb+TiIuHnh4CbOEfY FGWnrrascCtAIvzrSIuKojRwDNvCj0qkc2jbsCKKWvxveh5eHvOSb2zeGOO2mRSdEaE5ICaEhNSs oUlaP8ZjgukuXmETRHbEHvkyZlJmpb47MLZlZpUitCY3YHNSmiLhRXGkGWGhbX0GR9KPrkEqXbd1 GvwziUWHfHc7FifbKfKe+hlQSEtQYP2P+xZnVaxjM+2RJySELq4hwhYZ4WUe//9Qbdtbbx1d8FKO rLg0GmeGIwiiOWXnhkYJNuAHwslTIObxdlxqAy+Yuv1vFAHL0hmIrMLjgD1pCLBIKbslzdLLc1fE +hlNdtxfbp6j+7I3kewBjjguqowBHBWWjcJvHnXCRXtYR5P8WXLMXb31uModb1uksog66ORwDjxx +I3/aVVthbvBUnuqLQ4295JstDmpNFsFzrmN7eKaW33IM7gXBjV/LEu28RUw3ftwl+yvMkUdfJdq Ff6iY7WqD51//BJF3zqNrxlZYPffifTccqPpSTN54dJaI7m/j1Nz00CG2VoubPouj9Dd7CajUee3 gwTnogIjFN7Hc/wFbSlsa7oOV5iumWTkEyqt7Ky7awelj1YOvbi+GTJMSVLBOsQfFnPfNUTx/Ecv l4BTchyVtigWqddE/Ayrjz7lanDwJw/vFSsozG80/vodYDGXnAvTu9NXxnCPftorJk4Jn3zV7RMB rj8PvcDip0yGByur55Aj31dBRqMPuS/+KXNXuu5nyUjjK5nE8vj84VQFlpAEY70nX5xCgW2eOUY7 0k5v7fumDDAD2dHK6qL09NXlQ4xVK91VF1h69ZRhoih74/aLeol9qQ0u0baKwcnhu4slH3Wz4GpV RHbzXtJE8gFyEGzwjxwPw4xwtO50ioCN6USN/S80JeYKLtBZwnWTRKnEm0wgoj7QuYp9VnIKuq+R tRn3gsbwOXw1vuFuWfgmSlkKyw+9mcp+NgFfOw+JWmVdI+oDJHbskvpVbZt50lR6LoJqMLpNYg5I N6F4LkWvznaxTlKUziSlWGK++SFsJ8oZDd2abe24ehdKBvyDD/d/USrlxTaZif+EXzJSTsMCL2Rl 3Sa/JHWWHM80bYBYtFHloRIAnNVMvz0jqECzCQaD2wJhTF2orP0NXN3H5g34TOb3/3s5mC75lVM5 FhDH7WE+OY8mqVZL197XQnzELrcx9HDExF/HMMwU4v5L1vPW0IwLhfUfa7p3GliByeYcjBW7qqw0 fWoZ74ckadSu3/TRwcgRMZUKEF2Uwt1Skf21Ef1tt5YIyTdPpLetFMqgd8VRA+qc6yGFd6g0QcuO F0Ltn3j3Fxs9w7GK8smSQ9DGnNrIEykkJKFYU9xn7lPuiA/O6YtNnKHV46tpgaPNCWnM/A6Iwrzg XHBD+B3djfkQgWUSpt+21pJkboqROEHTkEmZo+MBafy1nQy/fLT0nJHewalWIzF2jehlOTmHYX9/ 29fhQgKUuxC1S7vcYCGt9IM2FZSNctprR1TyP34VtjEnXH3/7/OBh7WREy9rzNhVYmg1e2AWNWnb J6xjiAUbDJzd7HZDOYjasU1wZHEmbvqP4ulfUEq2JeY8grrSPU07Nv5hxmiuhRS3exkiTY5vJEc8 NtXVV/pybtONLcQKDREuA2zwvUaJYY9BXCB5BkaJXajuf08Vc3+iL5XZv/RVO0HM8Fs9IpIfoTdc UVzCMzlP513VbnKuMCfL2E/uVfzrTjsY+bfzgCqELh59NhBZmnxlTP5fSzhtZzc8tbTzNEzc3e1N iF2bs+0VEUJbJlyQE/K3CzgpFi29nro2Nhyy6hk1qsZtqZF4hOtNJh3/P2oxI0dA3Eb7czEJIOvA +eTCq2t2PaUd2Wa1b1TOXSJln1BtoEIaISt1redgBf+zwfK1HawTIEWeiYSnSnpfPcN5Z4hIfgYq 73VeE+SiQqCHtLQ8OiZhppJz9eshYRAdD2zlZWK2EC7yceGoPsemj2W4tvAmgqQOhYmLdAP+FFbB HHCpK/VkSG4axbqJzuufk7IOnfXeJGScSYq7uRZHuBU2yeQEYsBasw5d2LiApMYw397TO/mgrW8s 1zIXa9Rf05MUUp/AcxAyHGCXv8C/xXTM4NaY5usjx7xZM6pIBufhBpTME3D9438L48zUMN3R+ode nvHIj68c64wq4Dib6Ntm0hrRah1u9apwPH2dspY0yKyxP97gnnlr7FxzFPxuvd/CSPJDwIgBHL4h YxhrbIlbuOmClVlxy7kn+uJnE/WtcosV03ek5p6wMdEiJV5a81izJiGQ3LNPd8GuMqhgQ2zRmVTo sofJ4+WsCSO+4DKTEemRliceU7WaMI1A2ftmD0he46ZyZvWbBNenpFmt6AwAAAAzwOkMAAAAMQoz w/kzxEDDM8aY1ugNAAAAkBvG6QsAAAAxOfgzwCPCw4PYfCvH/Ojv////6AwAAAADxPjpCAAAADEZ G8ELwsNIC8Do8////2D4cnkPMZATxoPQcA8C0QPEBUsBeQVAK8eYE8EzxED4cnWY/IvFE8ctewt5 BYPIAvwbwugMAAAAC8FI6Q0AAAAxHSvADTMUeQXDSIvE6PD////oUgAAAPjoCwAAAMHYE+kGAAAA MTr5wxvF+CvAi8YPAvnoBwAAAOkIAAAAMTk9ISp5BcMDxpjoDwAAAKkyL3kF6QoAAAAxGfgTwNbD kBvDM8X46SIAAACpEjh5BWRnoQAAg+wEiQQki8RkZ6MAALgAAAAAgRh9u/mFE8FIi0QkCIvguQAA AABkjwFZ6AAAAADoCwAAACvF6QoAAAAxOSvBM8bDI8aYg+B86PD///+LDCRYgemAc/gN6AoAAABI 6QkAAAAxHTPEmMNIE8f5I8bo8f///zPSgfI52fmFgcIMJ/6Hg/BCA9G4Ydv5hYv4ge/gvvmFu8jV 8oU9R2F5BTEal0iXDTdjeQWLwgUEAAAAkpgzxcHYN8HD8ivGmLgq1vKFA9jB2Bm4AAAAAEgDx3gF 6cn///8zxWE9NW55BcMAAzBzAACUAAAAAAAAAAEAAAPQcwAARAAAAAAAAAABAAAAIHQAAGcAAAAA AAAAAQAAAZB0AAB3AAAAAAAAAAEAAAIQdQAAfgAAAAAAAAACAAABkHUAADMAAAAAAAAAAQAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0052_0133E531.53E53170 Content-Type: image/gif; name="EASUSSM.GIF" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="EASUSSM.GIF" R0lGODlhQgA9AOYAAP////7+/v39/fz8/Pv7+/r6+vn5+fj4+Pf39/b29vX19fT09PPz8/Ly8vHx 8fDw8O/v7+7u7u3t7ezs7Ovr6+rq6unp6ejo6Ofn5+bm5uXl5eTk5OPj4+Li4uHh4eDg4N/f397e 3t3d3dzc3Nvb29ra2tnZ2djY2NfX19bW1tXV1dTU1NPT09LS0tHR0dDQ0M/Pz87Ozs3NzczMzMvL y8rKysnJycjIyMfHx8bGxsXFxcTExMPDw8LCwsHBwcDAwL+/v76+vr29vby8vLu7u7q6urm5ubi4 uLe3t7a2trW1tbS0tLOzs7KysgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwA AAAAQgA9AAAH/4AAgoOEhYaHiImKi4yNjo+QkZKGAgSTl5iCASRDRjgeA5miji1NJxs8TUEWo62H ASxNJYICHDtLMQ6uuwExTSGGGDxKNKy7mb1JFIkYOks6F8eXpcu0BYcQO007utKPIU0ggwo7SDox Ky41IdcCIUVKLg/ei7C/hB47P0JKTf5KEAYVONFEiQl6iALACIdIAhB/RSYUItCPCQOEhmAoqWYo QhF/ROYVWuGvyUGMg1A02YBIARF/SSQWwlByG6YGJEYEVESCIQABJkZcA8DgYZMjxghVQFJzichI HZQIEcJEB0dCm2QN+uAPCIgKQ/zx6KaUac0mKCSBQCtAAAYcTf9wVCjkwd9JAAU6/Dh7w4AhCmbP CrH0aK2MQhs+uiDLw8heGAkEvujXhAnLQh7P1vzwqEMTGAIMFRBBREkMBhKaaBgQQggSFk8dqDhS uUaGUACWaq7ZIzQjz7MAGKiQgQKCQQM0+EByRMcgAq2XzNgJYAGLJE1+HNe9u+bTRBy0DlhhpCQS GhwDaOihRO4gtzyWyIgwqIEIv9y7++txYNGFJinQQlATQxjFRFqDBLDBSzYcNwgGH3FDCASB6UcD Ycyc55sgH4BAgAAQ6OCPCIUssMRnhRxgwhBKwCDBcELoVxIP/SkSHg0bHmJBSdQBMMGJSUQ20Qcx UiZjEzQu4gH/EymE1taTbRGAgAXa+DOXIPmReMgAHtB2ZJKKcBVgbj78YKaZQMBTUwy+MeClP84l IqKMQdSYyANIzBAaAmGVpAQTNTFRxAqEHdDDWUooIIgBIKDAgV8AVNkdDxcpIkF5NQ7QgaQ5dDDB BBZUAMFQAChwqGYnECWEET0cYYQIBeSgH5iJCAAEoDaQFUAz/hzBQqWEKLDXbkgNoUN/CKRwRBFv nkVrIhmsZIEP8l0pyAQy+CMdBgEIAsGw+uGAIQAHlPCRZvw1UsMQTp7QDwsOCoKBUTWE5tKRQthJ SAIuVFgEsIqYiAEhCIgwxBEoxAudCZYIe6QOwBJwgAEbMsAC/1NMDNwIC0J0O1EIBy9WiMMy1kBY BDkcsQQTQKhAFgMuJEEECZAmYgAS4iAC3Q9KyGBBaA8YpZ/JgxywQhJB4FCeafE2oAKBHigCQhKk JgRhE0DoUOFuO4wryId4ZRuXx4KIaFEiOMzgyAEobL1bEAsY8sAFuK3lz1MGxNiEloY4kAR9jzhg 5G5AXATBBgZ02wBTQqzQgllGCCnADDMiMkEScT9iAHbdNSiIL0ekSsAGkiZRRA2AFwBXTR0cIgAO R2TwCAKca5YDhguhOIgvQiyAYQA3aMYDIgjAZYPGi9De3WWC7NhEEReEloCsTXA2CEmaKZH5IRc4 wwPyxNde0v8SSQzBAYYL+vNDDoHJLgj2uwWXCAQzLMFDBl4PovxZMjAAQxJGKAGkDOABHQCqMkKI 2vtk9IMcIYJ+BAKBAwGwv5IwQSYMQIGrSIChBFCgAhEgTAFecKQmXEURFdDGDnpEQfFhjWylsgHW KgBDQpCwhOBjxAVuQQNrVXBEh5jADZbwAw44EH4yWsEEGYGBW3wPAATgnBGIMISadWQyXvGLAXIn oyWkChMPiMEzSNCPI3zACMxLBANewARz9KmLHGiFBYJQkg1gQAlVU8QE5lTCL7ZCUyrQAABmoDZI mKCEK8BIDl4QCbvpJ5EYuYASaiCTRoDjkSgRhAQ+YoPtKeJukrsZQSYHYQARFAEJCVsEKM8CyVEK ZAREOILIELHKkrTSlYQowAiCYBqyEKKWTVABLmulnCW84DsAqKUfh4kIAbirCfAaxCphwMxGKAAF sUxlXfyxzGouQpexPEEsTOHNSICTm+WcBAFEwDdJBAIAOw== ------=_NextPart_000_0052_0133E531.53E53170-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 02:36:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g669aMk7005263; Sat, 6 Jul 2002 02:36:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g669aMEa005262; Sat, 6 Jul 2002 02:36:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g669aJk7005255 for ; Sat, 6 Jul 2002 02:36:19 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29857 for ; Sat, 6 Jul 2002 02:36:25 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23690 for ; Sat, 6 Jul 2002 02:35:49 -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 g669ZCI15599; Sat, 6 Jul 2002 16:35:12 +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 g669YZf16466; Sat, 6 Jul 2002 16:34:35 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Keith Moore cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-Reply-To: <200207051408.g65E8kZ04099@astro.cs.utk.edu> References: <200207051408.g65E8kZ04099@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 Jul 2002 16:34:35 +0700 Message-ID: <16464.1025948075@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 05 Jul 2002 10:08:46 -0400 From: Keith Moore Message-ID: <200207051408.g65E8kZ04099@astro.cs.utk.edu> | One reason I say that this is an API issue is that (at least the destination | address selection stuff) is really a mechanism for encouraging or defaulting | the binding of the destination address to a socket. That is what it is, but that isn't API. | But the application is going to need to be able to explictly choose a | specific destination address in any case, I'm not sure I agree with that in all cases, an application might want to choose - for the vast majority of applications, anything that works will do - regardless of which is best. | so this is just a way to help the application choose the "right" | answer. Yes, but affecting (or even being) the application doesn't make it API. | Another reason I say this is an API issue is that a good choice of | destination address (and therefore source address) cannot be made | without explicit knowledge of the application's requirements. Sure, it can affect the application, and be affected by it, so an API is needed - but what's in this draft isn't that. | Another reason I say that this is an API issue is that we really need | all platforms that currently provide the same API to implement this Here you're saying that there needs to be a standard API, and I don't disagree, and I doubt anyone does (or not anyone who agrees with having the API docs) - but this doc isn't that API. | This cannot be a protocol issue except in a few specific cases, because | there are very few (approaching zero) protocols that explicitly and | exhaustively define the mechanisms by which addresses are advertised to | potential peers. e.g. We cannot assume that all addresses in all (or even | most) protocols are obtained exclusively through DNS. It isn't a protocol issue, in the sense that things will break if you don't pick the "right" addresses, no more than there is a protocol issue in the sense that things will break if you don't do a random delay before sending a RS packet - but doing these kinds of things properly improves the overall operation of the net, using the right addresses can get packets though better. It may be true now that nothing much in this doc will actually achieve that, but if we know which addresses will be selected by apps, we can engineer things so those work best. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 6 06:51:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g66DpUk7005495; Sat, 6 Jul 2002 06:51:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g66DpTLl005494; Sat, 6 Jul 2002 06:51:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g66DpPk7005487 for ; Sat, 6 Jul 2002 06:51:26 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05869 for ; Sat, 6 Jul 2002 06:51:32 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05060 for ; Sat, 6 Jul 2002 07:51:31 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g66DkOZ03427; Sat, 6 Jul 2002 09:46:24 -0400 (EDT) Message-Id: <200207061346.g66DkOZ03427@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt In-reply-to: (Your message of "Sat, 06 Jul 2002 16:34:35 +0700.") <16464.1025948075@munnari.OZ.AU> Date: Sat, 06 Jul 2002 09:46:24 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, I agree of course that the document isn't trying to define an API in any kind of detail, nor (mostly) does it describe what an API needs to do. I'm arguing that it *should* be written in those terms, because there's no right address selection algorithm that works for all cases, and any assumptions about what constitues the majority of cases are fairly dubious. Also, the big issue about e.g. privacy/temporary addresses vs. stable addresses is best looked at as a backward compatibility issue - new or revised apps can be encouraged to specify which they want in any case, but we can't change existing binaries. > It isn't a protocol issue, in the sense that things will break if you > don't pick the "right" addresses, no more than there is a protocol issue > in the sense that things will break if you don't do a random delay before > sending a RS packet - but doing these kinds of things properly improves > the overall operation of the net, using the right addresses can get > packets though better. It may be true now that nothing much in this > doc will actually achieve that, but if we know which addresses will be > selected by apps, we can engineer things so those work best. I don't think it's reasonable to expect apps in general to be predictable in that way - the needs of apps vary from one app to another and the behavior of a typical app (if there is such a thing) will vary over time and from one place to another. Or to put it another way, if you try to engineer the network by first defining how apps behave w.r.t address selection and then basing other design/configuration decisions on that, you end up making the network design/configuration favor that kind of apps (and penalize others) - without any regard for whether this is a reasonable or desirable compromise. e.g. the inability of the network to support distributed apps, or apps that run for a long time, or apps that need privacy (to give three examples of potential outcomes) becomes an 'unintended consequence'. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 6 07:26:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g66EQ6k7005534; Sat, 6 Jul 2002 07:26:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g66EQ5U7005533; Sat, 6 Jul 2002 07:26:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g66EQ2k7005526 for ; Sat, 6 Jul 2002 07:26:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23031 for ; Sat, 6 Jul 2002 07:26:09 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14721 for ; Sat, 6 Jul 2002 08:26:05 -0600 (MDT) Received: from libero.it (193.70.192.37) by smtp2.libero.it (6.5.015) id 3D009B170032C7F9 for ipng@sunroof.eng.sun.com; Sat, 6 Jul 2002 16:26:04 +0200 Date: Sat, 6 Jul 2002 16:26:04 +0200 Message-Id: Subject: =?iso-8859-1?Q?Mabye_OT_:_IPv6_and_Routing_Security?= MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: "=?utf-8?Q?ando@libero.it?=" To: ipng@sunroof.eng.sun.com X-XaM3-API-Version: 3.0.1build13 R13 X-type: 0 X-SenderIP: 80.105.2.203 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g66EQ3k7005527 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, i'm a university student, for my degree thesis i have to investigate Routing Security Problem in IPv6. After Reading RFCs about RIPng and OSPF for IPv6 all i found is that to secure routing protocols IPSec will be used. Well i couldn't find any details about HOW ipsec will be used. So my question is:is this a vendor/implementation issue? If you have links/pointers to documents which deals with this problem please tell me!!! Thanx id advance, Alessandro P.s: sorry for my english. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 00:15:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g677F3k7006342; Sun, 7 Jul 2002 00:15:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g677F2rK006341; Sun, 7 Jul 2002 00:15:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g677Exk7006334 for ; Sun, 7 Jul 2002 00:14:59 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23623 for ; Sun, 7 Jul 2002 00:15:05 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA16327 for ; Sun, 7 Jul 2002 01:15:04 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id JAA22278; Sun, 7 Jul 2002 09:15:02 +0200 (MET DST) Date: Sun, 7 Jul 2002 09:15:02 +0200 From: Ignatios Souvatzis To: "ando@libero.it" Cc: ipng@sunroof.eng.sun.com Subject: Re: Mabye OT : IPv6 and Routing Security Message-ID: <20020707091502.A22006@theory.cs.uni-bonn.de> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ando@libero.it on Sat, Jul 06, 2002 at 04:26:04PM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Sat, Jul 06, 2002 at 04:26:04PM +0200, ando@libero.it wrote: > i'm a university student, for my degree thesis i have to investigate > Routing Security Problem in IPv6.=20 > After Reading RFCs about RIPng and OSPF for IPv6 all i found is that > to secure routing protocols IPSec will be used. Well i couldn't find=20 > any details about HOW ipsec will be used.=20 >=20 > So my question is:is this a vendor/implementation issue? I'd think, configuration issue. Both protocols you mention are interiour routing protocols, so it might even be feasible to set the routers up with a small number of pre-shared keys us= ed to authenticate the routing messages to one another. See the relevant documents for details. -is --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPSfqcjCn4om+4LhpAQGWfAf/RcOoJmw2Zu4tV25ZBrQ2A2uMk3ITBfKP 8UWIopiNGJJCYbj+X2krBZjjt7JChvfvu5DLB4cwhQEQQTmbscYJEKGTnzbD2ggj d7YFlUg29ZV2aYy6oh93tlsjoQD4aKvn11wmk1B3qbMocNSiUHFTdGPxvdAY5Ep+ pEfD4udhzJ3CMO67NuBuXQV/XXDAaFXKlQ5EUXE2GpXb1+5g0YFYNyPqasOaV97N R/J0eBACkNmBp+W4fY/dz3bzTtUe4/qRJb+rWDi0b0UF7aZ8pPBD1WT85iLT8DpZ 0tiyRGOOMFYS7XmNvg3OdvH7lF9HHSCBPUmNijGwmBUnUcx0tbpVLg== =Gnw7 -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 01:34:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g678Ykk7006402; Sun, 7 Jul 2002 01:34:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g678YkUS006401; Sun, 7 Jul 2002 01:34:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g678Ygk7006394 for ; Sun, 7 Jul 2002 01:34:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14966 for ; Sun, 7 Jul 2002 01:34:49 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13070 for ; Sun, 7 Jul 2002 01:34:48 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0DD814B22; Sun, 7 Jul 2002 17:34:41 +0900 (JST) To: Ignatios Souvatzis Cc: "ando@libero.it" , ipng@sunroof.eng.sun.com In-reply-to: ignatios's message of Sun, 07 Jul 2002 09:15:02 +0200. <20020707091502.A22006@theory.cs.uni-bonn.de> 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: Mabye OT : IPv6 and Routing Security From: itojun@iijlab.net Date: Sun, 07 Jul 2002 17:34:40 +0900 Message-Id: <20020707083441.0DD814B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> i'm a university student, for my degree thesis i have to investigate >> Routing Security Problem in IPv6.=20 >> After Reading RFCs about RIPng and OSPF for IPv6 all i found is that >> to secure routing protocols IPSec will be used. Well i couldn't find >> any details about HOW ipsec will be used. >> So my question is:is this a vendor/implementation issue? > >I'd think, configuration issue. > >Both protocols you mention are interiour routing protocols, so it might even >be feasible to set the routers up with a small number of pre-shared keys used >to authenticate the routing messages to one another. > >See the relevant documents for details. my take is that RIPng and OSPFv3 spec should be revised to talk more about how they should interact with IPsec. since these protocols use link-local multicast (as well as link-local unicast), - IPsec implementation must have a proper scope support - IKE implementation must have a proper scope support (ID payload handling gets very tricky) - automatic keying with IKE is impossible for multicast case! to summarize, just saying "use IPsec" is not enough. 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 Sun Jul 7 09:08:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67G80k7006963; Sun, 7 Jul 2002 09:08:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g67G7x96006959; Sun, 7 Jul 2002 09:07:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67G7pk7006942 for ; Sun, 7 Jul 2002 09:07:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24845 for ; Sun, 7 Jul 2002 09:07:57 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26860 for ; Sun, 7 Jul 2002 10:07: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 MAA23823; Sun, 7 Jul 2002 12:07:03 -0400 (EDT) Message-Id: <200207071607.MAA23823@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-node-requirements-01.txt Date: Sun, 07 Jul 2002 12:07:03 -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 Requirements Author(s) : J. Loughney Filename : draft-ietf-ipv6-node-requirements-01.txt Pages : 24 Date : 05-Jul-02 This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-node-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-node-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020705141526.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-node-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-node-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705141526.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 Sun Jul 7 09:08:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67G82k7006966; Sun, 7 Jul 2002 09:08:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g67G82pE006965; Sun, 7 Jul 2002 09:08:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g67G7rk7006952 for ; Sun, 7 Jul 2002 09:07:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02213 for ; Sun, 7 Jul 2002 09:07:59 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04852 for ; Sun, 7 Jul 2002 10:07:58 -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 MAA23834; Sun, 7 Jul 2002 12:07:05 -0400 (EDT) Message-Id: <200207071607.MAA23834@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-link-scoped-mcast-01.txt Date: Sun, 07 Jul 2002 12:07:05 -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 : Link Scoped IPv6 Multicast Addresses Author(s) : J. Park, M. Shin, Y. Kim Filename : draft-ietf-ipv6-link-scoped-mcast-01.txt Pages : 6 Date : 05-Jul-02 This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of interface-ID to allocate multicast addresses. When the link-local unicast address is configured at each interface of host, interface ID is uniquely determined. By delegating multicast addresses at the same time as interface ID, each host can identify their multicast addresses automatically at Layer 1 without running an intra- or inter-domain allocation protocol in the serverless environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-link-scoped-mcast-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-link-scoped-mcast-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020705141536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-link-scoped-mcast-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-link-scoped-mcast-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705141536.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 8 01:38:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g688crk7008829; Mon, 8 Jul 2002 01:38:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g688crQN008828; Mon, 8 Jul 2002 01:38:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g688cnk7008821 for ; Mon, 8 Jul 2002 01:38:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26448 for ; Mon, 8 Jul 2002 01:38:56 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23782 for ; Mon, 8 Jul 2002 02:38:55 -0600 (MDT) Received: from server2000 (151.37.36.137) by smtp1.libero.it (6.5.015) id 3CFC3E5B00E5B0C0 for ipng@sunroof.eng.sun.com; Mon, 8 Jul 2002 10:38:53 +0200 From: "Alessandro Giacometti" To: Subject: R: Mabye OT : IPv6 and Routing Security Date: Mon, 8 Jul 2002 10:39:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <20020707091502.A22006@theory.cs.uni-bonn.de> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > i'm a university student, for my degree thesis i have to investigate > > Routing Security Problem in IPv6. > > After Reading RFCs about RIPng and OSPF for IPv6 all i found is that > > to secure routing protocols IPSec will be used. Well i couldn't find > > any details about HOW ipsec will be used. > > > > So my question is:is this a vendor/implementation issue? > > I'd think, configuration issue. > > Both protocols you mention are interiour routing protocols, so it Thanx. And what can you tell me about security,IPv6 and BGP4+? I found something, but it was about IPv4 and BGP. Alessandro -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 8 07:23:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68ENVk7009385; Mon, 8 Jul 2002 07:23:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g68ENVDi009384; Mon, 8 Jul 2002 07:23:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g68ENRk7009377 for ; Mon, 8 Jul 2002 07:23:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04396 for ; Mon, 8 Jul 2002 07:23:34 -0700 (PDT) Received: from web13106.mail.yahoo.com (web13106.mail.yahoo.com [216.136.174.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA07923 for ; Mon, 8 Jul 2002 08:23:33 -0600 (MDT) Message-ID: <20020708142332.94089.qmail@web13106.mail.yahoo.com> Received: from [198.62.10.2] by web13106.mail.yahoo.com via HTTP; Mon, 08 Jul 2002 15:23:32 BST Date: Mon, 8 Jul 2002 15:23:32 +0100 (BST) From: =?iso-8859-1?q?jaganbabu=20rajamanickam?= Subject: Re: R: Mabye OT : IPv6 and Routing Security To: Alessandro Giacometti , ipng@sunroof.eng.sun.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, All carier class routers are supose to support all kinds of IPSec pay loads , it is all the ipsec configurations which makes a vendor to select a particular method of authentications for their pay loads. As you said it is correct, IPSec is the one which does the real security for any IP data, it is all the routing protcol how it adopts (supports) it. Jags --- Alessandro Giacometti wrote: > > > > > > i'm a university student, for my degree thesis i > have to investigate > > > Routing Security Problem in IPv6. > > > After Reading RFCs about RIPng and OSPF for IPv6 > all i found is that > > > to secure routing protocols IPSec will be used. > Well i couldn't find > > > any details about HOW ipsec will be used. > > > > > > So my question is:is this a > vendor/implementation issue? > > > > I'd think, configuration issue. > > > > Both protocols you mention are interiour routing > protocols, so it > > Thanx. > And what can you tell me about security,IPv6 and > BGP4+? > I found something, but it was about IPv4 and BGP. > > Alessandro > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: > http://playground.sun.com/ipng > FTP archive: > ftp://playground.sun.com/pub/ipng > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- ________________________________________________________________________ Want to sell your car? advertise on Yahoo Autos Classifieds. It's Free!! visit http://in.autos.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 9 02:15:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g699Fmk7012620; Tue, 9 Jul 2002 02:15:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g699FmTV012619; Tue, 9 Jul 2002 02:15:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g699Fik7012612 for ; Tue, 9 Jul 2002 02:15:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14752 for ; Tue, 9 Jul 2002 02:15:50 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA15104 for ; Tue, 9 Jul 2002 02:15:46 -0700 (PDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jmd3d2abfee; Tue, 9 Jul 2002 09:15:38 -0000 Received: from loki.ietf.org([132.151.1.177]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm233d261320; Fri, 5 Jul 2002 15:14:25 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA15812 for ietf-123-outbound.01@ietf.org; Fri, 5 Jul 2002 10:35:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA13063 for ; Fri, 5 Jul 2002 06:34:54 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17052; Fri, 5 Jul 2002 06:34:05 -0400 (EDT) Message-Id: <200207051034.GAA17052@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kitamura-ipv6-name-auto-reg-02.txt Date: Fri, 05 Jul 2002 06:34:05 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Domain Name Auto-Registration for Plugged-in IPv6 Nodes Author(s) : H. Kitamura Filename : draft-kitamura-ipv6-name-auto-reg-02.txt Pages : 21 Date : 03-Jul-02 This document describes a scheme of 'Domain Name Auto-Registration for Plugged-in IPv6 Nodes' mechanism that makes it possible to register both regular and inverse domain name information of plugged- in IPv6 nodes to DNS servers automatically. Since IPv6 addresses are too long to remember and EUI64-based addresses are too complicated to remember, there are strong requirements to use logical names that are easy to remember instead of IPv6 addresses to specify IPv6 nodes and to register domain name information of plugged-in IPv6 nodes automatically. In order to meet the requirements, a mechanism is proposed as one of the IPv6 auto-configuration (plug and play) functions. After the Address Autoconfiguration [ADDR-AUTO] has been executed, it works as a succeeding plug and play mechanism. This document clarifies problems that we meet when we apply the Dynamic Updates in the DNS [DYN-DNS] to automatic domain name information registration mechanisms. This document proposes the Domain Name Auto-Registration mechanism as a solution to these problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kitamura-ipv6-name-auto-reg-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kitamura-ipv6-name-auto-reg-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kitamura-ipv6-name-auto-reg-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020703131841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kitamura-ipv6-name-auto-reg-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-kitamura-ipv6-name-auto-reg-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703131841.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 9 04:16:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69BGek7013224; Tue, 9 Jul 2002 04:16:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g69BGeX0013223; Tue, 9 Jul 2002 04:16:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69BGXk7013213 for ; Tue, 9 Jul 2002 04:16:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28849 for ; Tue, 9 Jul 2002 04:16:40 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA14194 for ; Tue, 9 Jul 2002 05:16:39 -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 HAA19513; Tue, 9 Jul 2002 07:15:46 -0400 (EDT) Message-Id: <200207091115.HAA19513@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-multilink-subnets-00.txt Date: Tue, 09 Jul 2002 07:15:45 -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 : Multi-link Subnet Support in IPv6 Author(s) : D. Thaler, C. Huitema Filename : draft-ietf-ipv6-multilink-subnets-00.txt Pages : 16 Date : 08-Jul-02 Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. This document introduces the concept of a 'multilink subnet', defined as a collection of independent links, connected by routers, but sharing a common subnet prefix. It then specifies the behavior of multilink subnet routers so that no changes to host behavior are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-multilink-subnets-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-multilink-subnets-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-multilink-subnets-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: <20020708101121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-multilink-subnets-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-multilink-subnets-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020708101121.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 9 04:16:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69BGck7013221; Tue, 9 Jul 2002 04:16:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g69BGc7d013220; Tue, 9 Jul 2002 04:16:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69BGWk7013206 for ; Tue, 9 Jul 2002 04:16:32 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09998 for ; Tue, 9 Jul 2002 04:16:38 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18157 for ; Tue, 9 Jul 2002 04:16:34 -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 HAA19500; Tue, 9 Jul 2002 07:15:41 -0400 (EDT) Message-Id: <200207091115.HAA19500@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-rfc2013-update-00.txt Date: Tue, 09 Jul 2002 07:15:41 -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 User Datagram Protocol (UDP) Author(s) : B. Fenner Filename : draft-ietf-ipv6-rfc2013-update-00.txt Pages : 21 Date : 08-Jul-02 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 User Datagram Protocol (UDP) [4] in an IP version independent manner. It is intended to obsolete RFC 2013 and RFC 2454. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2013-update-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-rfc2013-update-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-rfc2013-update-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: <20020708101109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2013-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2013-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020708101109.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 9 05:35:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69CZmk7013366; Tue, 9 Jul 2002 05:35:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g69CZmla013365; Tue, 9 Jul 2002 05:35:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69CZik7013358 for ; Tue, 9 Jul 2002 05:35:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28995 for ; Tue, 9 Jul 2002 05:35:50 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24641 for ; Tue, 9 Jul 2002 06:35:49 -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 IAA22091; Tue, 9 Jul 2002 08:34:55 -0400 (EDT) Message-Id: <200207091234.IAA22091@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com From: The IESG Subject: Document Action: IPv6 for Some Second and Third Generation Cellular Hosts to Informational Date: Tue, 09 Jul 2002 08:34:55 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IPv6 for Some Second and Third Generation Cellular Hosts' as an Informational RFC. This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Erik Nordmark and 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 Tue Jul 9 14:24:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69LOkk7014357; Tue, 9 Jul 2002 14:24:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g69LOj3T014356; Tue, 9 Jul 2002 14:24:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g69LOgk7014349 for ; Tue, 9 Jul 2002 14:24:42 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25914 for ; Tue, 9 Jul 2002 14:24:49 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23565 for ; Tue, 9 Jul 2002 15:24:49 -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 OAA09906; Tue, 9 Jul 2002 14:24:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g69LOlo01439; Tue, 9 Jul 2002 14:24:47 -0700 X-mProtect: <200207092124> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnDWNTh; Tue, 09 Jul 2002 14:24:46 PDT Message-Id: <4.3.2.7.2.20020709142221.02704ff8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Jul 2002 14:24:24 -0700 To: IPv6 List From: Bob Hinden Subject: Draft Agenda for Yokohama IETF IPv6 W.G. Sessions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the draft agenda for the IPv6 sessions at the Yokohama IETF. In putting together the agenda we gave priority to items that are urgent for IPv6 deployment, completing current work, longer term w.g. goals, new individual submissions, and last to status reports. It was not possible to honor all requests for agenda items. Suggest that these topics be brought to the mailing list. Please send comments and corrections to the w.g. chairs. Thanks, Bob Hinden, Steve Deering, Margaret Wasserman IPv6 chairs ----------------------------------------------------------------------- Internet Protocol version 6 WG (ipv6) Thursday, July 18th, 0900-1130 & 1300-1500 (Room 301/302) ========================================================= CHAIRS: Steve Deering Bob Hinden Margaret Wasserman AGENDA: Morning Session 0900-1130 (Room 301/302) ======================================== Introduction & Agenda Bashing (5 min) Priorities and Status -- Bob Hinden (30 min) - Presentation of current priorities and status - Discussion of WG priorities moving forward Prefix Delegation Requirements -- Shin Miyakawa (15 min) IPv6 MIBs Status and Open Issues -- Margaret Wasserman (10 min) IPv6 Node Requirements -- John Loughney (20 min) DAD vs. DIID Discussion -- Chairs (20 min) - Including DAD-related changes, if any, required to: Addressing Architecture Open Issues -- Bob Hinden (10 min) DNS Discovery Status and Next Steps -- Chairs and Erik Nordmark (20 min) Afternoon Session 1300-1500 (Room 301/302) ========================================== Default Address Selection Open Issues -- Rich Draves (20 min) Node Information Queries IESG Feedback -- Thomas Narten (20 min) Flow Label -- Jarno Rajahalme (10 min) Scoped Address Architecture -- Tatuya Jinmei (15 min) IPv6 Anycast Architecture -- Jun-ichiro itojun Hagino (15 min) A Protocol for Anycast Address Resolving -- Shingo Ata (10 min) Unidentified Issues in IPv6 Deployment/Operation -- Jun-ichiro itojun Hagino or Tatuya Jinmei (10 min) http://www.ietf.org/internet-drafts/draft-itojun-jinmei-ipv6-issues-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 Tue Jul 9 22:19:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6A5Jik7015054; Tue, 9 Jul 2002 22:19:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6A5JirT015053; Tue, 9 Jul 2002 22:19:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6A5Jek7015046 for ; Tue, 9 Jul 2002 22:19:41 -0700 (PDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6A5Jig10099; Wed, 10 Jul 2002 07:19:45 +0200 (MEST) Date: Wed, 10 Jul 2002 01:39:41 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Draft Agenda for Yokohama IETF IPv6 W.G. Sessions To: IPv6 List Cc: erik.nordmark@Sun.COM In-Reply-To: "Your message with ID" <4.3.2.7.2.20020709142221.02704ff8@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 > A Protocol for Anycast Address Resolving -- Shingo Ata (10 min) > The security considerations in the draft are quite weak. Perhaps we can start a discussion about this on the list. Since an anycast address is not syntactically distriguishable from a unicast address, a client of a unicast service can be spoofed using AARP to send packets to some other unicast address. This sounds very similar to the "remote redirect" aspect of binding updates in Mobile IPv6, thus I think very similar security requirements should apply. It might even be that some of the Mobile IPv6 security solutions (e.g. using return routability checks) can be reused for the anycast case. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 02:51:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6A9psk7015291; Wed, 10 Jul 2002 02:51:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6A9ps1X015290; Wed, 10 Jul 2002 02:51:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6A9pok7015283 for ; Wed, 10 Jul 2002 02:51:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08575 for ; Wed, 10 Jul 2002 02:51:56 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18984 for ; Wed, 10 Jul 2002 03:51:55 -0600 (MDT) Received: from kenawang ([192.168.1.46]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id CAA01676; Wed, 10 Jul 2002 02:49:26 -0700 (PDT) Message-Id: <4.2.2.20020709201635.017365a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 09 Jul 2002 20:28:53 -0400 To: jarno.rajahalme@nokia.com, Steve Deering , Alex Conta , Brian Carpenter From: Margaret Wasserman Subject: IPv6 Flow Label Specification Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jarno, Steve, Alex and Brian, I have a couple of questions about the latest IPv6 Flow Label Specification . First, do you intend this specification to be mandatory for all IPv6 nodes? I would prefer a statement that nodes SHOULD implement this specification, and that nodes that do not implement this specification MUST set the flow label in all originated packets to zero. Also, should we define a default timeout for cached flow information (i.e. 10 minutes)? This would allow nodes to free information on "recent" flows in a consistent fashion, when no signalling or other mechanisms are available to indicate how long a flow could live. Could you also indicate whether the information about previous flows needs to survive TCP/IP restarts and/or node reboots? Previous discussions of the flow label have centered around its potential use for load sharing -- allowing a router to keep flows together when choosing between alternate paths. Is that still an expected use of this mechanism? How does this fit with the requirement in section 5, bullet (1): "The flow state establishment mechanism MUST covey this classifying information to the IPv6 nodes that need to perform the classification". Is a load sharing router a degenerate case where the information only needs to be conveyed to the router itself? Could you maybe add this example to the document, and explain how it fits into each area of requirement? Will hosts reuse a flow label if an application indicates that they shoud? I'm still concerned about how/if routers may cache forwarding information based on the flow label. Is it you intention that this would be an acceptable use? What about security information? It still seems to me that acceptable uses of the flow label are tied to just how certain we can be that the flow triplet (label, src address and dest address) will actually identify a single flow. And, this means that we would have to have some detailed requirements for how/if flow labels are reused. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 04:37:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ABb9k7015417; Wed, 10 Jul 2002 04:37:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ABb9s4015416; Wed, 10 Jul 2002 04:37:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ABb6k7015409 for ; Wed, 10 Jul 2002 04:37:06 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10965 for ; Wed, 10 Jul 2002 04:37:13 -0700 (PDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13677 for ; Wed, 10 Jul 2002 04:37:12 -0700 (PDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6ABauIB072564; Wed, 10 Jul 2002 13:36:57 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with SMTP id g6ABasg140224; Wed, 10 Jul 2002 13:36:54 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA33998 from ; Wed, 10 Jul 2002 13:36:41 +0200 Message-Id: <3D2C1C79.8BD41844@hursley.ibm.com> Date: Wed, 10 Jul 2002 13:37: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: Margaret Wasserman Cc: jarno.rajahalme@nokia.com, Steve Deering , Alex Conta , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification References: <4.2.2.20020709201635.017365a0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My opinions (not checked with the co-authors): Margaret Wasserman wrote: > > Hi Jarno, Steve, Alex and Brian, > > I have a couple of questions about the latest IPv6 Flow Label > Specification . > > First, do you intend this specification to be mandatory for all > IPv6 nodes? I would prefer a statement that nodes SHOULD > implement this specification, and that nodes that do not implement > this specification MUST set the flow label in all originated > packets to zero. > I thought that was in effect what it did say (i.e. setting the label to zero does conform to the spec). Do you want to suggest a precise wording change? > Also, should we define a default timeout for cached flow information > (i.e. 10 minutes)? This would allow nodes to free information on > "recent" flows in a consistent fashion, when no signalling or other > mechanisms are available to indicate how long a flow could live. I suggested that but was overruled by my co-authors. It's not obvious that we can define a one-size-fits-all default. > > Could you also indicate whether the information about previous > flows needs to survive TCP/IP restarts and/or node reboots? I'd say that the Flow Label Aassignment Process (FLAP, but again I was overruled on the grounds of too many acronyms :-) should survive reboots, i.e. the same label should not be assigned again even after a reboot. I don't see that it matters if the same label is assigned to the "same" flow after a TCP reset and reconnect, but normally I'd expect it to be a different label, because there is no way for the assignment process to know it's the "same" flow back again. So I think it would be useful to add a note that the assignment process should survive reboots. > > Previous discussions of the flow label have centered around its > potential use for load sharing -- allowing a router to keep > flows together when choosing between alternate paths. No, only *some* previous discussions have centered around that. Others have centered around its use of Intserv and/or Diffserv. > Is that > still an expected use of this mechanism? How does this fit with > the requirement in section 5, bullet (1): "The flow state establishment > mechanism MUST covey this classifying information to the IPv6 nodes > that need to perform the classification". Is a load sharing router > a degenerate case where the information only needs to be conveyed > to the router itself? Could you maybe add this example to the > document, and explain how it fits into each area of requirement? I certainly see nothing in the spec that prevents such use. But after discussion between the authors, we decided to cut down on the use cases since this is supposed to be a spec. If we were going to add this use case, I'd want to add back in the material about the other use cases that we removed. My preference is not to do this, and leave the description of the various use cases for possible future informational documents. > > Will hosts reuse a flow label if an application indicates that they > shoud? That would be an API issue within the host. I don't think it affects the protocol spec. Are you suggesting a change to the text? > > I'm still concerned about how/if routers may cache forwarding > information based on the flow label. Is it you intention that this > would be an acceptable use? If a label truly characterizes a flow, I see no reason why the routing system shouldn't make use of it. But again, it's a use case not part of the spec. > What about security information? Don't understand the question. > It still seems to me that acceptable uses of the flow label are > tied to just how certain we can be that the flow triplet (label, > src address and dest address) will actually identify a single flow. I don't think we should get into the business of what's "acceptable". Let's just concentrate on defining the minimum conditions a node must meet. That is what is holding up implementors. > And, this means that we would have to have some detailed requirements > for how/if flow labels are reused. No. That will vary from one use case to another. So we definitely *should not* try to specify the reuse rules in the general spec. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 04:47:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ABltk7015472; Wed, 10 Jul 2002 04:47:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ABltB1015471; Wed, 10 Jul 2002 04:47:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ABlqk7015464 for ; Wed, 10 Jul 2002 04:47:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA07193 for ; Wed, 10 Jul 2002 04:47:59 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA21649 for ; Wed, 10 Jul 2002 05:47:58 -0600 (MDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6ABkQd01335 for ; Wed, 10 Jul 2002 14:46:26 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Jul 2002 14:47:56 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 14:47:56 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 Flow Label Specification X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Jul 2002 14:47:55 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB5@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Flow Label Specification Thread-Index: AcIn98Wy7ccfxNTHR6aEFwKyCeVKpQADzT2w To: , , , , Cc: X-OriginalArrivalTime: 10 Jul 2002 11:47:56.0080 (UTC) FILETIME=[A1987300:01C22807] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6ABlqk7015465 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret & authors, A high-level question - I think that many of your comments could/should be handled by applications which use the flowspec. I am not so sure that the draft, draft-ietf-ipv6-flow-label-02.txt, should define these things. For example, I much prefer that the application (or signaling protocol) set the following: 1) cached flow info timeout 2) re-use of flow label values Additionally, signaling protocols making use of the flow spec should (must?) define how routers are expected to use the flow label. In NSIS, we are starting to discuss these issues, and I would worry if the IPv6 WG goes into too much detail with regards of how the flow label is used, etc. thanks, John > -----Original Message----- > From: ext Margaret Wasserman [mailto:mrw@windriver.com] > Sent: 10 July, 2002 03:29 > To: Rajahalme Jarno (NRC/Helsinki); Steve Deering; Alex Conta; Brian > Carpenter > Cc: ipng@sunroof.eng.sun.com > Subject: IPv6 Flow Label Specification > > > > Hi Jarno, Steve, Alex and Brian, > > I have a couple of questions about the latest IPv6 Flow Label > Specification . > > First, do you intend this specification to be mandatory for all > IPv6 nodes? I would prefer a statement that nodes SHOULD > implement this specification, and that nodes that do not implement > this specification MUST set the flow label in all originated > packets to zero. > > Also, should we define a default timeout for cached flow information > (i.e. 10 minutes)? This would allow nodes to free information on > "recent" flows in a consistent fashion, when no signalling or other > mechanisms are available to indicate how long a flow could live. > > Could you also indicate whether the information about previous > flows needs to survive TCP/IP restarts and/or node reboots? > > Previous discussions of the flow label have centered around its > potential use for load sharing -- allowing a router to keep > flows together when choosing between alternate paths. Is that > still an expected use of this mechanism? How does this fit with > the requirement in section 5, bullet (1): "The flow state > establishment > mechanism MUST covey this classifying information to the IPv6 nodes > that need to perform the classification". Is a load sharing router > a degenerate case where the information only needs to be conveyed > to the router itself? Could you maybe add this example to the > document, and explain how it fits into each area of requirement? > > Will hosts reuse a flow label if an application indicates that they > shoud? > > I'm still concerned about how/if routers may cache forwarding > information based on the flow label. Is it you intention that this > would be an acceptable use? What about security information? > It still seems to me that acceptable uses of the flow label are > tied to just how certain we can be that the flow triplet (label, > src address and dest address) will actually identify a single flow. > And, this means that we would have to have some detailed requirements > for how/if flow labels are reused. > > 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 Wed Jul 10 05:40:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ACekk7015546; Wed, 10 Jul 2002 05:40:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ACekJt015545; Wed, 10 Jul 2002 05:40:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ACegk7015538 for ; Wed, 10 Jul 2002 05:40:42 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17809 for ; Wed, 10 Jul 2002 05:40:48 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18230 for ; Wed, 10 Jul 2002 06:40:47 -0600 (MDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6ACeXIS080372; Wed, 10 Jul 2002 14:40:34 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with SMTP id g6ACeVg154512; Wed, 10 Jul 2002 14:40:31 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA13886 from ; Wed, 10 Jul 2002 14:40:29 +0200 Message-Id: <3D2C2B6D.CB139092@hursley.ibm.com> Date: Wed, 10 Jul 2002 14:41:17 +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: john.loughney@nokia.com Cc: mrw@windriver.com, jarno.rajahalme@nokia.com, deering@cisco.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB5@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, I agree. The basic spec should be lean and mean. Do you see anywhere that we have over-defined things? Brian john.loughney@nokia.com wrote: > > Hi Margaret & authors, > > A high-level question - I think that many of your comments could/should > be handled by applications which use the flowspec. I am not so sure > that the draft, draft-ietf-ipv6-flow-label-02.txt, should define > these things. > > For example, I much prefer that the application (or signaling > protocol) set the following: > > 1) cached flow info timeout > 2) re-use of flow label values > > Additionally, signaling protocols making use of the flow spec should (must?) > define how routers are expected to use the flow label. > > In NSIS, we are starting to discuss these issues, and I would worry if > the IPv6 WG goes into too much detail with regards of how the flow label > is used, etc. > > thanks, > John > > > -----Original Message----- > > From: ext Margaret Wasserman [mailto:mrw@windriver.com] > > Sent: 10 July, 2002 03:29 > > To: Rajahalme Jarno (NRC/Helsinki); Steve Deering; Alex Conta; Brian > > Carpenter > > Cc: ipng@sunroof.eng.sun.com > > Subject: IPv6 Flow Label Specification > > > > > > > > Hi Jarno, Steve, Alex and Brian, > > > > I have a couple of questions about the latest IPv6 Flow Label > > Specification . > > > > First, do you intend this specification to be mandatory for all > > IPv6 nodes? I would prefer a statement that nodes SHOULD > > implement this specification, and that nodes that do not implement > > this specification MUST set the flow label in all originated > > packets to zero. > > > > Also, should we define a default timeout for cached flow information > > (i.e. 10 minutes)? This would allow nodes to free information on > > "recent" flows in a consistent fashion, when no signalling or other > > mechanisms are available to indicate how long a flow could live. > > > > Could you also indicate whether the information about previous > > flows needs to survive TCP/IP restarts and/or node reboots? > > > > Previous discussions of the flow label have centered around its > > potential use for load sharing -- allowing a router to keep > > flows together when choosing between alternate paths. Is that > > still an expected use of this mechanism? How does this fit with > > the requirement in section 5, bullet (1): "The flow state > > establishment > > mechanism MUST covey this classifying information to the IPv6 nodes > > that need to perform the classification". Is a load sharing router > > a degenerate case where the information only needs to be conveyed > > to the router itself? Could you maybe add this example to the > > document, and explain how it fits into each area of requirement? > > > > Will hosts reuse a flow label if an application indicates that they > > shoud? > > > > I'm still concerned about how/if routers may cache forwarding > > information based on the flow label. Is it you intention that this > > would be an acceptable use? What about security information? > > It still seems to me that acceptable uses of the flow label are > > tied to just how certain we can be that the flow triplet (label, > > src address and dest address) will actually identify a single flow. > > And, this means that we would have to have some detailed requirements > > for how/if flow labels are reused. > > > > Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 05:46:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ACkjk7015587; Wed, 10 Jul 2002 05:46:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ACkiZa015586; Wed, 10 Jul 2002 05:46:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ACkfk7015579 for ; Wed, 10 Jul 2002 05:46:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22911 for ; Wed, 10 Jul 2002 05:46:48 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11038 for ; Wed, 10 Jul 2002 05:46:47 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6AClHi13483 for ; Wed, 10 Jul 2002 15:47:17 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Jul 2002 15:46:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 15:46:45 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 Flow Label Specification X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Jul 2002 15:46:45 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC656E2@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Flow Label Specification Thread-Index: AcIoDv/BVq9MH54US3aVVB2IRKa1YwAAJE1Q To: Cc: , , , , X-OriginalArrivalTime: 10 Jul 2002 12:46:45.0957 (UTC) FILETIME=[D990EF50:01C2280F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6ACkgk7015580 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, > I agree. The basic spec should be lean and mean. Do you see > anywhere that we have over-defined things? I just did a quick re-read of the the draft, and I think it looks good. I'll do a more thorough review of it, however. Also, I have forwarded a request that people in the NSIS WG review it to see if they have problems. I will summarize the results. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 06:22:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ADMKk7015637; Wed, 10 Jul 2002 06:22:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ADMKc9015636; Wed, 10 Jul 2002 06:22:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ADMHk7015629 for ; Wed, 10 Jul 2002 06:22:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25869 for ; Wed, 10 Jul 2002 06:22:24 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27142 for ; Wed, 10 Jul 2002 06:22:23 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6ADLsc09348; Wed, 10 Jul 2002 16:21:54 +0300 Date: Wed, 10 Jul 2002 16:21:54 +0300 (EEST) From: Pekka Savola To: john.loughney@nokia.com cc: mrw@windriver.com, , , , , Subject: RE: IPv6 Flow Label Specification In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB5@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 10 Jul 2002 john.loughney@nokia.com wrote: [...] > For example, I much prefer that the application (or signaling > protocol) set the following: [...] > 2) re-use of flow label values (Hopefully I didn't misunderstand this point.) The flow label space is far from infinite. It's hypocritical to believe a node would not need to consider a case when it needs to start using some flow labels that may have been previously used. This is especially important if the implementation should keep track of flow labels across reboots. I see no good way of doing this except writing the labels in some kind persistent storage. And consider operating system crashes etc. where this may not be possible. The only sane way seems to be to use random flow labels (or at least randomize the point where to begin using flow labels after a reboot); there are no problems if one does not have too high expectations of the lifetime of the uniqueness. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 06:26:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ADQck7015664; Wed, 10 Jul 2002 06:26:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ADQbZX015663; Wed, 10 Jul 2002 06:26:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ADQXk7015656 for ; Wed, 10 Jul 2002 06:26:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04281 for ; Wed, 10 Jul 2002 06:26:40 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01096 for ; Wed, 10 Jul 2002 07:26:38 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 2FFBB4B26; Wed, 10 Jul 2002 22:26:26 +0900 (JST) To: Pekka Savola Cc: john.loughney@nokia.com, mrw@windriver.com, jarno.rajahalme@nokia.com, deering@cisco.com, aconta@txc.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Wed, 10 Jul 2002 16:21:54 +0300. 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 Flow Label Specification From: itojun@iijlab.net Date: Wed, 10 Jul 2002 22:26:25 +0900 Message-Id: <20020710132626.2FFBB4B26@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This is especially important if the implementation should keep track of >flow labels across reboots. I see no good way of doing this except >writing the labels in some kind persistent storage. And consider >operating system crashes etc. where this may not be possible. The only >sane way seems to be to use random flow labels (or at least randomize the >point where to begin using flow labels after a reboot); there are no >problems if one does not have too high expectations of the lifetime of the >uniqueness. i completely agree with this statement. can't always reliably keep flow label value into persistent store, so something like "start from random number on reboot, and monotonically increase value" makes more sense. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 07:56:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AEumk7015787; Wed, 10 Jul 2002 07:56:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AEumwe015786; Wed, 10 Jul 2002 07:56:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AEujk7015779 for ; Wed, 10 Jul 2002 07:56:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20904 for ; Wed, 10 Jul 2002 07:56:53 -0700 (PDT) Received: from mail.n.info.eng.osaka-cu.ac.jp (mail.n.info.eng.osaka-cu.ac.jp [160.193.163.111]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26167 for ; Wed, 10 Jul 2002 07:56:53 -0700 (PDT) Received: from [127.0.0.1] (h218159.ppp.asahi-net.or.jp [61.114.218.159]) by mail.n.info.eng.osaka-cu.ac.jp (Postfix) with ESMTP id 7E1F157D58; Wed, 10 Jul 2002 23:56:51 +0900 (JST) Date: Wed, 10 Jul 2002 23:56:45 +0900 From: "Ata, Shingo" To: Erik Nordmark Subject: Re: Draft Agenda for Yokohama IETF IPv6 W.G. Sessions Cc: IPv6 List In-Reply-To: References: <4.3.2.7.2.20020709142221.02704ff8@mailhost.iprg.nokia.com> Message-Id: <20020710231714.3CCB.ATA@info.eng.osaka-cu.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.03 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thank you for your comments for our draft. > The security considerations in the draft are quite weak. Perhaps we can start > a discussion about this on the list. Exactly. The weakness of the current AARP is that the AARP trusts the receipt packet from the host (it might be out of anycast group). As a result, there is a possibility that the anycast client may become an unexpected attacker of denial of service. As you described, we need more discussions how to verify the receipt packet from the anycast host. I will list some security problems on AARP at Yokohama meeting. regrads, --- Shingo Ata -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 08:27:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AFROk7015950; Wed, 10 Jul 2002 08:27:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AFRN92015949; Wed, 10 Jul 2002 08:27:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AFRKk7015942 for ; Wed, 10 Jul 2002 08:27:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08916 for ; Wed, 10 Jul 2002 08:27:27 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13796 for ; Wed, 10 Jul 2002 08:27:26 -0700 (PDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6AFQh2F033544; Wed, 10 Jul 2002 17:26:44 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with SMTP id g6AFQfd116598; Wed, 10 Jul 2002 17:26:41 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA33400 from ; Wed, 10 Jul 2002 17:26:36 +0200 Message-Id: <3D2C525C.C5A48819@hursley.ibm.com> Date: Wed, 10 Jul 2002 17:27: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: itojun@iijlab.net Cc: Pekka Savola , john.loughney@nokia.com, mrw@windriver.com, jarno.rajahalme@nokia.com, deering@cisco.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification References: <20020710132626.2FFBB4B26@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >This is especially important if the implementation should keep track of > >flow labels across reboots. I see no good way of doing this except > >writing the labels in some kind persistent storage. And consider > >operating system crashes etc. where this may not be possible. The only > >sane way seems to be to use random flow labels (or at least randomize the > >point where to begin using flow labels after a reboot); there are no > >problems if one does not have too high expectations of the lifetime of the > >uniqueness. > > i completely agree with this statement. can't always reliably keep > flow label value into persistent store, so something like "start from > random number on reboot, and monotonically increase value" makes > more sense. I don't see that. Transaction processing systems and databases have this requirement too, and in "normal" crashes they have no problem, because a transaction ID is always saved in stable storage before it's used. (I agree that if you do have to restart the allocation process for some reason, a pseudo-random seed is good.) But in any case, IMHO we have no business specifying any of this in a basic protocol spec. As John said, it depends on the application scenario. I can well imagine a case where an application might want to use the same flow label for a consecutive flow; there's nothing in the spec to forbid that, I hope. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 08:48:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AFmjk7016125; Wed, 10 Jul 2002 08:48:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AFmjB9016124; Wed, 10 Jul 2002 08:48:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AFmfk7016117 for ; Wed, 10 Jul 2002 08:48:42 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24928 for ; Wed, 10 Jul 2002 08:48:48 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25397 for ; Wed, 10 Jul 2002 09:48:47 -0600 (MDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6AFojW01893 for ; Wed, 10 Jul 2002 18:50:45 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Jul 2002 18:48:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 18:48:46 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 Flow Label Specification X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 10 Jul 2002 18:48:45 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB7@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Flow Label Specification Thread-Index: AcIoFMO57B10+f3ET8emeyS8JVf81gAE74AQ To: Cc: , , , , , X-OriginalArrivalTime: 10 Jul 2002 15:48:46.0306 (UTC) FILETIME=[4699F420:01C22829] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6AFmgk7016118 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, > [...] > > For example, I much prefer that the application (or signaling > > protocol) set the following: > [...] > > 2) re-use of flow label values > > (Hopefully I didn't misunderstand this point.) > > The flow label space is far from infinite. It's hypocritical > to believe a node would not need to consider a case when it needs to start > using some flow labels that may have been previously used. I don't disagree with you - however my point was I thought that the application should be involved in what value of the flow label is used. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 09:04:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AG4ik7016188; Wed, 10 Jul 2002 09:04:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AG4i2o016187; Wed, 10 Jul 2002 09:04:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AG4fk7016180 for ; Wed, 10 Jul 2002 09:04:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01285 for ; Wed, 10 Jul 2002 09:04:47 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17748 for ; Wed, 10 Jul 2002 10:04:46 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 10 Jul 2002 12:02:44 -0400 Message-ID: <3D2C59FA.1500BEE7@nc.rr.com> Date: Wed, 10 Jul 2002 11:59:54 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: pekkas@netcore.fi, mrw@windriver.com, jarno.rajahalme@nokia.com, deering@cisco.com, aconta@txc.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB7@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John, john.loughney@nokia.com wrote: > > I don't disagree with you - however my point was I thought that the > application should be involved in what value of the flow label is used. Is it really the case that the application needs to be involved in choosing the flow label value? Or is it more reasonable to say that the app needs to be able to indicate that it wants to use *a* flow label? I can see the flow label management issue being more efficient in the IPv6 stack itself. Of course, there is also an issue of whether two applications on the same machine communicating with the same peer machine would want to share a flow label. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 10:30:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AHUUk7016398; Wed, 10 Jul 2002 10:30:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AHUTwD016397; Wed, 10 Jul 2002 10:30:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AHUQk7016384 for ; Wed, 10 Jul 2002 10:30:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25798 for ; Wed, 10 Jul 2002 10:30:34 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21261 for ; Wed, 10 Jul 2002 10:30:33 -0700 (PDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 41119198D for ; Wed, 10 Jul 2002 13:30:31 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 8C0F44F for ; Wed, 10 Jul 2002 17:30:28 +0000 (GMT) Date: Wed, 10 Jul 2002 13:30:14 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification In-Reply-To: References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB5@esebe004.NOE.Nokia.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020710173028.8C0F44F@thangorodrim.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Wed, 10 Jul 2002 16:21:54 +0300 (EEST), Pekka Savola wrote: > > This is especially important if the implementation should keep track of > flow labels across reboots. I see no good way of doing this except > writing the labels in some kind persistent storage. And consider > operating system crashes etc. where this may not be possible. The only > sane way seems to be to use random flow labels (or at least randomize the > point where to begin using flow labels after a reboot); there are no > problems if one does not have too high expectations of the lifetime of the > uniqueness. I agree with Pekka and itojun. Please also recall that there exist toaster-class devices whose only persistant storage is flash RAM or some similar technology that has a finite number of write cycles before becoming, well, toast. In such environments preserving frequently-changing data across reboots is not a trivial matter, and I'm not convinced that flow labels pass the cost/benefit test. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 11:59:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AIx4k7017222; Wed, 10 Jul 2002 11:59:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AIx3in017221; Wed, 10 Jul 2002 11:59:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AIx0k7017214 for ; Wed, 10 Jul 2002 11:59:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03706 for ; Wed, 10 Jul 2002 11:59:06 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15627 for ; Wed, 10 Jul 2002 12:59:05 -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 LAA01569; Wed, 10 Jul 2002 11:59:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AIx2p07506; Wed, 10 Jul 2002 11:59:02 -0700 X-mProtect: <200207101859> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvFX7la; Wed, 10 Jul 2002 11:59:00 PDT Message-Id: <4.3.2.7.2.20020710115105.0271a198@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Jul 2002 11:58:38 -0700 To: Rob Austein From: Bob Hinden Subject: Re: IPv6 Flow Label Specification Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20020710173028.8C0F44F@thangorodrim.hactrn.net> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB5@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob, I think something with similar properties to TCP's initial sequence number selection would be about right. A toaster-class device will have to deal with that as well. Bob >Please also recall that there exist toaster-class devices whose only >persistant storage is flash RAM or some similar technology that has a >finite number of write cycles before becoming, well, toast. In such >environments preserving frequently-changing data across reboots is not >a trivial matter, and I'm not convinced that flow labels pass the >cost/benefit test. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 13:24:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AKOCk7017291; Wed, 10 Jul 2002 13:24:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AKOCIm017290; Wed, 10 Jul 2002 13:24:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AKO9k7017283 for ; Wed, 10 Jul 2002 13:24:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05398; Wed, 10 Jul 2002 13:24:15 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA26320; Wed, 10 Jul 2002 14:24:14 -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 NAA06361; Wed, 10 Jul 2002 13:23:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6AKNg222329; Wed, 10 Jul 2002 13:23:42 -0700 X-mProtect: <200207102023> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAPWHJG; Wed, 10 Jul 2002 13:23:37 PDT Message-Id: <4.3.2.7.2.20020710131951.0271a198@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Jul 2002 13:23:14 -0700 To: Erik.Nordmark@eng.sun.com, Thomas Narten From: Bob Hinden Subject: Request to Advance "Default Router Preferences, More-Specific Routes and Load Sharing" Cc: ipng@sunroof.eng.sun.com, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title: Default Router Preferences, More-Specific Routes and Load Sharing Author(s): R. Draves, B. Hinden Filename: draft-ietf-ipv6-router-selection-02.txt Pages: 13 Date: 10-Jun-02 A working group last call for this document was completed on July 4, 2002. Bob Hinden / Steve Deering / Margaret Wasserman IPv6 Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 13:32:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AKWbk7017317; Wed, 10 Jul 2002 13:32:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AKWaJ4017316; Wed, 10 Jul 2002 13:32:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AKWXk7017309 for ; Wed, 10 Jul 2002 13:32:33 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04936 for ; Wed, 10 Jul 2002 13:32:39 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18385 for ; Wed, 10 Jul 2002 14:32:38 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 6739A4B28; Thu, 11 Jul 2002 05:32:31 +0900 (JST) To: Brian Haberman Cc: john.loughney@nokia.com, pekkas@netcore.fi, mrw@windriver.com, jarno.rajahalme@nokia.com, deering@cisco.com, aconta@txc.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com In-reply-to: bkhabs's message of Wed, 10 Jul 2002 11:59:54 -0400. <3D2C59FA.1500BEE7@nc.rr.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 Flow Label Specification From: itojun@iijlab.net Date: Thu, 11 Jul 2002 05:32:31 +0900 Message-Id: <20020710203231.6739A4B28@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I don't disagree with you - however my point was I thought that the >> application should be involved in what value of the flow label is used. > >Is it really the case that the application needs to be involved in >choosing the flow label value? Or is it more reasonable to say that >the app needs to be able to indicate that it wants to use *a* flow >label? > >I can see the flow label management issue being more efficient in >the IPv6 stack itself. FYI, draft-itojun-ipv6-flowlabel-api-01.txt provides no way to set flowlabel value from the userland. the (sending) kernel decides the value. receiver apps can inspect the value. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 13:40:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AKemk7017380; Wed, 10 Jul 2002 13:40:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AKem0g017379; Wed, 10 Jul 2002 13:40:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AKejk7017372 for ; Wed, 10 Jul 2002 13:40:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06491 for ; Wed, 10 Jul 2002 13:40:51 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA04276 for ; Wed, 10 Jul 2002 14:40:50 -0600 (MDT) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id CD86218CD for ; Wed, 10 Jul 2002 16:40:48 -0400 (EDT) Date: Wed, 10 Jul 2002 16:40:48 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification In-Reply-To: <4.3.2.7.2.20020710115105.0271a198@mailhost.iprg.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB5@esebe004.NOE.Nokia.com> <20020710173028.8C0F44F@thangorodrim.hactrn.net> <4.3.2.7.2.20020710115105.0271a198@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020710204048.CD86218CD@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Wed, 10 Jul 2002 11:58:38 -0700, Bob Hinden wrote: > > I think something with similar properties to TCP's initial sequence number > selection would be about right. A toaster-class device will have to deal > with that as well. I agree that the constraints seem similar. ISN selection is another one of those cases where stable storage vs (good) random numbers is a tricky question, at least in the toaster universe. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 14:03:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AL3ak7017443; Wed, 10 Jul 2002 14:03:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6AL3aQk017442; Wed, 10 Jul 2002 14:03:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6AL3Xk7017435 for ; Wed, 10 Jul 2002 14:03:33 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18368 for ; Wed, 10 Jul 2002 14:03:40 -0700 (PDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06315 for ; Wed, 10 Jul 2002 15:03:40 -0600 (MDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 10 Jul 2002 16:51:24 -0400 Message-ID: <3D2C9DA2.3BCEB075@nc.rr.com> Date: Wed, 10 Jul 2002 16:48:34 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: john.loughney@nokia.com, pekkas@netcore.fi, mrw@windriver.com, jarno.rajahalme@nokia.com, deering@cisco.com, aconta@txc.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification References: <20020710203231.6739A4B28@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >> I don't disagree with you - however my point was I thought that the > >> application should be involved in what value of the flow label is used. > > > >Is it really the case that the application needs to be involved in > >choosing the flow label value? Or is it more reasonable to say that > >the app needs to be able to indicate that it wants to use *a* flow > >label? > > > >I can see the flow label management issue being more efficient in > >the IPv6 stack itself. > > FYI, draft-itojun-ipv6-flowlabel-api-01.txt provides no way to > set flowlabel value from the userland. the (sending) kernel decides > the value. receiver apps can inspect the value. Exactly. I prefer that rather than one that requires the apps to make a decision on the value. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 10 22:58:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B5w8k7018631; Wed, 10 Jul 2002 22:58:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6B5w8mF018630; Wed, 10 Jul 2002 22:58:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B5w5k7018623 for ; Wed, 10 Jul 2002 22:58:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA20485 for ; Wed, 10 Jul 2002 22:58:13 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA21119 for ; Wed, 10 Jul 2002 23:58:12 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6B5w3o16835; Thu, 11 Jul 2002 08:58:03 +0300 Date: Thu, 11 Jul 2002 08:58:02 +0300 (EEST) From: Pekka Savola To: Bob Hinden cc: Rob Austein , Subject: Re: IPv6 Flow Label Specification In-Reply-To: <4.3.2.7.2.20020710115105.0271a198@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 10 Jul 2002, Bob Hinden wrote: > I think something with similar properties to TCP's initial sequence number > selection would be about right. A toaster-class device will have to deal > with that as well. Exactly (to the latter sentence). HOWEVER, note that TCP ISN is not conserved across reboots. So, in practise, a toaster-class device deals with it by not dealing with it. The same would be good for flow labels. I agree 100% with Rob that we have to justify flow label storage __really__ hard to make it something that must be conserved across boots. Actually I don't recall anything in the current IPv4 base TCP/IP specification which requires storage (apart from addresses etc. which are a non-issue). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 11 00:13:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B7DAk7018733; Thu, 11 Jul 2002 00:13:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6B7DAU1018732; Thu, 11 Jul 2002 00:13:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B7D6k7018725 for ; Thu, 11 Jul 2002 00:13:06 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA00202 for ; Thu, 11 Jul 2002 00:13:12 -0700 (PDT) Received: from cisco.com (edinburgh.cisco.com [144.254.112.76]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24638 for ; Thu, 11 Jul 2002 00:13:11 -0700 (PDT) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id IAA04798; Thu, 11 Jul 2002 08:12:23 +0100 (BST) Date: Thu, 11 Jul 2002 08:12:23 +0100 From: Derek Fawcus To: Brian Haberman Cc: john.loughney@nokia.com, pekkas@netcore.fi, mrw@windriver.com, jarno.rajahalme@nokia.com, deering@cisco.com, aconta@txc.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification Message-ID: <20020711081222.A1531@edinburgh.cisco.com> Mail-Followup-To: Brian Haberman , john.loughney@nokia.com, pekkas@netcore.fi, mrw@windriver.com, jarno.rajahalme@nokia.com, deering@cisco.com, aconta@txc.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB7@esebe004.NOE.Nokia.com> <3D2C59FA.1500BEE7@nc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3D2C59FA.1500BEE7@nc.rr.com>; from bkhabs@nc.rr.com on Wed, Jul 10, 2002 at 11:59:54AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Jul 10, 2002 at 11:59:54AM -0400, Brian Haberman wrote: > Hi John, > > john.loughney@nokia.com wrote: > > > > I don't disagree with you - however my point was I thought that the > > application should be involved in what value of the flow label is used. > > Is it really the case that the application needs to be involved in > choosing the flow label value? Or is it more reasonable to say that > the app needs to be able to indicate that it wants to use *a* flow > label? I see it more of a case of being able to apply more than one use to a labeled flow. i.e. say you want intserve and some other processing to happen on a particular flow. This basically requires that the signalling protocols simply communicate the value, not be involved in choosing the value. Well strictly _one_ signalling app/protocol could choose the value, but then two such apps/processes would have trouble being applied at the same time. Hence referring to the following text in section 4: (2) to assign a specific Flow Label for a new flow, and assuming this means 'assign a specific Flow Label value', and not simply a specific Flow Label, I think the text should be deleted. Similarly the text: With [RSVP] or [SDP] either the source or the destination of the flow could have a preference for the Flow Label value to be used. For example, a destination with multiple sources sending packets to it could require all the sources to use the same Flow Label value in order to collapse the classifier state to a single flow state entry, instead of having separate classifier state for each source (ref. the Wildcard-Filter reservation style in [RSVP]). Therefore the source SHOULD honor the destination's request to mark the packets with the Flow Label value specified. should also be changed. First it refers to the destination requiring a specific flow label value, I don't buy that. Why would the destination care about the flow label, it's the end node, and as such has access to all infomation in the packet. Secondly, it is again requiring that a specific value be able to be chosen / forced by the destination, this again could interfere with some other processing/handling also being applied at the same time to the specified flow (as mentioned above). I would also remove 'or requested' from the next paragraph. 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 Thu Jul 11 01:29:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B8Tlk7018862; Thu, 11 Jul 2002 01:29:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6B8TkGJ018861; Thu, 11 Jul 2002 01:29:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B8Thk7018854 for ; Thu, 11 Jul 2002 01:29:43 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22391 for ; Thu, 11 Jul 2002 01:29:50 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23104 for ; Thu, 11 Jul 2002 01:29:49 -0700 (PDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6B8VlW23486 for ; Thu, 11 Jul 2002 11:31:48 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 11 Jul 2002 11:29:48 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 11:29:47 +0300 content-class: urn:content-classes:message Subject: RE: IPv6 Flow Label Specification MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 11 Jul 2002 11:29:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EBB@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Flow Label Specification Thread-Index: AcIoK4TsKaBUIWLMS2W8E2GNZV/0GwAiH+bw To: Cc: , , , , , , X-OriginalArrivalTime: 11 Jul 2002 08:29:47.0821 (UTC) FILETIME=[1E0DD5D0:01C228B5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6B8Thk7018855 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, > Is it really the case that the application needs to be involved in > choosing the flow label value? Or is it more reasonable to say that > the app needs to be able to indicate that it wants to use *a* flow > label? I could see cases where it might want to use a 'new' flow label, an existing flow label, sharing a flow label with another application, etc. > I can see the flow label management issue being more efficient in > the IPv6 stack itself. Well, in anycase, applications (upper layer protocols) may need to manage flow labels as well. One example would be if a user has an existing flow but wants to modify the properties of the flow in some way (higher level of QoS or something). > Of course, there is also an issue of whether two applications on > the same machine communicating with the same peer machine would want > to share a flow label. Exactly. I would suggest that we may not yet know how protocols above IPv6 may want to use the flow label, so over specification of the flow label by this community may not be the way to go. Perhaps it might be somewhat more useful to query TSVWG (for example) to see if they have opinions on this. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 11 01:58:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B8wmk7019064; Thu, 11 Jul 2002 01:58:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6B8wliA019063; Thu, 11 Jul 2002 01:58:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B8wik7019056 for ; Thu, 11 Jul 2002 01:58:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07142 for ; Thu, 11 Jul 2002 01:58:52 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA28566 for ; Thu, 11 Jul 2002 02:58:50 -0600 (MDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6B8wh2Q035118; Thu, 11 Jul 2002 10:58:44 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with SMTP id g6B8wfj90258; Thu, 11 Jul 2002 10:58:41 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA19450 from ; Thu, 11 Jul 2002 10:58:40 +0200 Message-Id: <3D2D48EF.416A46DC@hursley.ibm.com> Date: Thu, 11 Jul 2002 10:59:27 +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: Rob Austein Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB5@esebe004.NOE.Nokia.com> <20020710173028.8C0F44F@thangorodrim.hactrn.net> <4.3.2.7.2.20020710115105.0271a198@mailhost.iprg.nokia.com> <20020710204048.CD86218CD@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob Austein wrote: > > At Wed, 10 Jul 2002 11:58:38 -0700, Bob Hinden wrote: > > > > I think something with similar properties to TCP's initial sequence number > > selection would be about right. A toaster-class device will have to deal > > with that as well. > > I agree that the constraints seem similar. ISN selection is another > one of those cases where stable storage vs (good) random numbers is a > tricky question, at least in the toaster universe. All of which tells me that if we define a requirement for the flow label allocation process to survive reboots, it will be a SHOULD not a MUST. A toaster would provide a compelling argument for overriding the SHOULD. But right now we have enough dispute about it that I'd rather leave it open in the spec, i.e. no change to the draft. 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 Jul 11 02:11:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B9BLk7019139; Thu, 11 Jul 2002 02:11:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6B9BKqT019138; Thu, 11 Jul 2002 02:11:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B9BHk7019131 for ; Thu, 11 Jul 2002 02:11:17 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10285 for ; Thu, 11 Jul 2002 02:11:23 -0700 (PDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA07680 for ; Thu, 11 Jul 2002 03:11:22 -0600 (MDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6B9AhDX029606; Thu, 11 Jul 2002 11:10:43 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with SMTP id g6B9AfT125430; Thu, 11 Jul 2002 11:10:41 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55216 from ; Thu, 11 Jul 2002 11:10:39 +0200 Message-Id: <3D2D4BBE.945E549@hursley.ibm.com> Date: Thu, 11 Jul 2002 11:11: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: Derek Fawcus Cc: Brian Haberman , john.loughney@nokia.com, pekkas@netcore.fi, mrw@windriver.com, jarno.rajahalme@nokia.com, deering@cisco.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB7@esebe004.NOE.Nokia.com> <3D2C59FA.1500BEE7@nc.rr.com> <20020711081222.A1531@edinburgh.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Strong disagreement below... Derek Fawcus wrote: > > On Wed, Jul 10, 2002 at 11:59:54AM -0400, Brian Haberman wrote: > > Hi John, > > > > john.loughney@nokia.com wrote: > > > > > > I don't disagree with you - however my point was I thought that the > > > application should be involved in what value of the flow label is used. > > > > Is it really the case that the application needs to be involved in > > choosing the flow label value? Or is it more reasonable to say that > > the app needs to be able to indicate that it wants to use *a* flow > > label? > > I see it more of a case of being able to apply more than one use to > a labeled flow. i.e. say you want intserve and some other processing > to happen on a particular flow. This basically requires that the > signalling protocols simply communicate the value, not be involved > in choosing the value. > > Well strictly _one_ signalling app/protocol could choose the value, > but then two such apps/processes would have trouble being applied > at the same time. > > Hence referring to the following text in section 4: > > (2) to assign a specific Flow Label for a new flow, and > > assuming this means 'assign a specific Flow Label value', and not > simply a specific Flow Label, I think the text should be deleted. Absolutely not. This is text is essential to include certain possible ways of using the Flow Label. It allows a host (quite likely an application) to assign a specific, pre-defined, Flow Label value to a new flow that needs that particular value (which might for example be an IANA-defined value, or a value defined in a specific SLA). This sentence absolutely has to stay in. > > Similarly the text: > > With [RSVP] or [SDP] either the source or the destination of the flow > could have a preference for the Flow Label value to be used. For > example, a destination with multiple sources sending packets to it > could require all the sources to use the same Flow Label value in > order to collapse the classifier state to a single flow state entry, > instead of having separate classifier state for each source (ref. the > Wildcard-Filter reservation style in [RSVP]). Therefore the source > SHOULD honor the destination's request to mark the packets with the > Flow Label value specified. > > should also be changed. No it shouldn't... > > First it refers to the destination requiring a specific flow label value, > I don't buy that. Why would the destination care about the flow label, > it's the end node, and as such has access to all infomation in the packet. The text says why: it wants to treat multiple flows from multiple sources alike. It don't want to have to peek into every packet. > > Secondly, it is again requiring that a specific value be able to be > chosen / forced by the destination, this again could interfere with > some other processing/handling also being applied at the same time to > the specified flow (as mentioned above). When we understand all the use cases, ten years from now, maybe we can use that argument. But today we need to ensure that we don't accidentally exclude use cases. > > I would also remove 'or requested' from the next paragraph. No, for the same reasons. It isn't appropriate for us to exclude future options. 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 Jul 11 02:14:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B9Eok7019165; Thu, 11 Jul 2002 02:14:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6B9EoM9019164; Thu, 11 Jul 2002 02:14:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B9Elk7019157 for ; Thu, 11 Jul 2002 02:14:47 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00803 for ; Thu, 11 Jul 2002 02:14:53 -0700 (PDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09076 for ; Thu, 11 Jul 2002 03:14:52 -0600 (MDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6B9EG2F066528; Thu, 11 Jul 2002 11:14:16 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with SMTP id g6B9EET45754; Thu, 11 Jul 2002 11:14:14 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA71496 from ; Thu, 11 Jul 2002 11:14:12 +0200 Message-Id: <3D2D4C93.C12EE1DF@hursley.ibm.com> Date: Thu, 11 Jul 2002 11:14:59 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Brian Haberman Cc: itojun@iijlab.net, john.loughney@nokia.com, pekkas@netcore.fi, mrw@windriver.com, jarno.rajahalme@nokia.com, deering@cisco.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: draft-itojun-ipv6-flowlabel-api-01.txt [Re: IPv6 Flow Label Specification] References: <20020710203231.6739A4B28@coconut.itojun.org> <3D2C9DA2.3BCEB075@nc.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Haberman wrote: > > itojun@iijlab.net wrote: > > > > >> I don't disagree with you - however my point was I thought that the > > >> application should be involved in what value of the flow label is used. > > > > > >Is it really the case that the application needs to be involved in > > >choosing the flow label value? Or is it more reasonable to say that > > >the app needs to be able to indicate that it wants to use *a* flow > > >label? > > > > > >I can see the flow label management issue being more efficient in > > >the IPv6 stack itself. > > > > FYI, draft-itojun-ipv6-flowlabel-api-01.txt provides no way to > > set flowlabel value from the userland. the (sending) kernel decides > > the value. receiver apps can inspect the value. > > Exactly. I prefer that rather than one that requires the apps to make > a decision on the value. We certainly shouldn't *require* apps to make a decision, but (see my previous message) we must make it possible for them. Therefore, the API must provide an option for the sender to set the value. In any case, draft-itojun-ipv6-flowlabel-api-01.txt will have to be reviewed after we reach consensus on draft-ietf-ipv6-flow-label 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 Jul 11 02:16:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B9Gmk7019182; Thu, 11 Jul 2002 02:16:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6B9GmSS019181; Thu, 11 Jul 2002 02:16:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B9Gik7019174 for ; Thu, 11 Jul 2002 02:16:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24263 for ; Thu, 11 Jul 2002 02:16:50 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27033 for ; Thu, 11 Jul 2002 02:16:49 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3E24B4B29; Thu, 11 Jul 2002 18:16:39 +0900 (JST) To: Brian E Carpenter Cc: Brian Haberman , john.loughney@nokia.com, pekkas@netcore.fi, mrw@windriver.com, jarno.rajahalme@nokia.com, deering@cisco.com, aconta@txc.com, ipng@sunroof.eng.sun.com In-reply-to: brian's message of Thu, 11 Jul 2002 11:14:59 +0200. <3D2D4C93.C12EE1DF@hursley.ibm.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-flowlabel-api-01.txt [Re: IPv6 Flow Label Specification] From: itojun@iijlab.net Date: Thu, 11 Jul 2002 18:16:39 +0900 Message-Id: <20020711091639.3E24B4B29@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >We certainly shouldn't *require* apps to make a decision, but (see my >previous message) we must make it possible for them. Therefore, >the API must provide an option for the sender to set the value. the problem is, we need to provide a way for apps to pick a non- conflicting value to do that, and it gets very messy. that is the reason why my draft does not provide ways for apps to pick the value. >In any case, >draft-itojun-ipv6-flowlabel-api-01.txt will have to be reviewed after we >reach consensus on draft-ietf-ipv6-flow-label yes, that is why it is expired state. 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 Jul 11 02:38:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B9c7k7019236; Thu, 11 Jul 2002 02:38:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6B9c76X019235; Thu, 11 Jul 2002 02:38:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6B9c3k7019228 for ; Thu, 11 Jul 2002 02:38:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA17011 for ; Thu, 11 Jul 2002 02:38:09 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA13970 for ; Thu, 11 Jul 2002 03:38:08 -0600 (MDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6B9bV2Q035122; Thu, 11 Jul 2002 11:37:31 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with SMTP id g6B9bSj89830; Thu, 11 Jul 2002 11:37:29 +0200 Received: from dhcp222-45.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55198 from ; Thu, 11 Jul 2002 11:37:26 +0200 Message-Id: <3D2D5205.AF13C5FC@hursley.ibm.com> Date: Thu, 11 Jul 2002 11:38:13 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: itojun@iijlab.net Cc: Brian Haberman , john.loughney@nokia.com, pekkas@netcore.fi, mrw@windriver.com, jarno.rajahalme@nokia.com, deering@cisco.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: Re: draft-itojun-ipv6-flowlabel-api-01.txt [Re: IPv6 Flow Label Specification] References: <20020711091639.3E24B4B29@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >We certainly shouldn't *require* apps to make a decision, but (see my > >previous message) we must make it possible for them. Therefore, > >the API must provide an option for the sender to set the value. > > the problem is, we need to provide a way for apps to pick a non- > conflicting value to do that, and it gets very messy. that is the > reason why my draft does not provide ways for apps to pick the value. That is unavoidable, and not so messy if the current draft-ietf-ipv6-flow-label is followed (IMHO). Brian > > >In any case, > >draft-itojun-ipv6-flowlabel-api-01.txt will have to be reviewed after we > >reach consensus on draft-ietf-ipv6-flow-label > > yes, that is why it is expired state. > > itojun -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 Thu Jul 11 03:07:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BA7Wk7019262; Thu, 11 Jul 2002 03:07:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BA7WMP019261; Thu, 11 Jul 2002 03:07:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BA7Sk7019254 for ; Thu, 11 Jul 2002 03:07:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA24455 for ; Thu, 11 Jul 2002 03:07:34 -0700 (PDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA24092 for ; Thu, 11 Jul 2002 04:07:33 -0600 (MDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6BA7UDX037360 for ; Thu, 11 Jul 2002 12:07:31 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with SMTP id g6BA7Uj09920 for ; Thu, 11 Jul 2002 12:07:30 +0200 Received: from dhcp222-45.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA62460 from ; Thu, 11 Jul 2002 12:07:28 +0200 Message-Id: <3D2D5910.E0286B51@hursley.ibm.com> Date: Thu, 11 Jul 2002 12:08:16 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng Subject: [Fwd: RE: [NSIS] IPv6 Flow Label] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Forwarded with permission... -------- Original Message -------- Subject: RE: [NSIS] IPv6 Flow Label Date: Thu, 11 Jul 2002 11:34:13 +0300 From: john.loughney@nokia.com To: , , , CC: , Hi, Here are some comments on the flow label draft. John > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 11 July, 2002 02:04 > To: Loughney John (NRC/Helsinki); nsis@ietf.org > Subject: RE: [NSIS] IPv6 Flow Label > > > John, > > Interesting draft. I have tried to think it through from a > purely NSIS perspective. > > 1) Nowhere does it say if routers (or even sources) should > send packets from the same flow along the same path. Is that > because it's (a) the wrong place to say so or (b) obvious or > (c) impossible to mandate? In particular, it does say that a > node not carrying out flow specific treatment MUST ignore the > field on forwarding - maybe 'keeping packets together' could > be regarded as flow specific treatment (and made mandatory). > (If we could rely on this it would be a powerful weapon in > the signalling/data path divergence issue, but see next point.) > > 2) The draft seems to encourage (SHOULD) a highly granular > assignment of flow labels (e.g. section 4 rules 3 & 4). On > the other hand, there may be good reasons to use the same > label for a sequence of 'microflows' (e.g. successive files > in a bulk ftp transfer; the same point has been made on the > v6 list). Encouraging this granularity directly increases the > signalling burden. How strong is SHOULD? > > 3) Fortunately, I think most of the agonies about flow label > re-use don't have to worry us, they're end-system internal. > However, there are two points: > a) Do we need to strengthen our requirement for a TEAR > message to flush flow label state? > b) If a TEAR isn't possible (e.g. a route flap means some > routers wouldn't see it), do we need to allow the end system > to control the soft state timeout so they can be assured of > when flow label state has been purged? I don't think our > current requirements give this level of control to end hosts, > and I'm not sure they should. > > 4) I don't see why the flow state establishment method (i.e. > NSIS for example) needs to be able to manage flow label > agreement between end systems (end of section 4). After all, > it doesn't handle port number agreement. Such information > would need to be end-to-end secured, which (IMHO) is a poor > match to the security capabilities we are currently assuming for NSIS. > > 5) I'm seriously concerned about rule (6) of section 5. I > don't see it has anything to do with a standard on flow label > definition. If it does, then the rest of the draft has to be > clarified so whenever it refers to address it is clear if it > means home or care of address (e.g. on reception at the end > system, does a node check the combination of flow label with > HA or CoA to work out which flow something belongs to), and > the security considerations section might need something on > validating ownership of the home address as well. Better I > think would be to point out that something like the second > sentence of rule (6) applies in mobile environments, and that > flow state establishment methods should handle this how best > they can. (We have this requirement in NSIS anyway.) > > So, there might be some options for making the draft leaner > and meaner. > > Cheers, > > Robert > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: 10 July 2002 13:43 > > To: nsis@ietf.org > > Subject: [NSIS] IPv6 Flow Label > > > > > > Hi all, > > > > One tool we may want to use is the IPv6 flow label. There is some > > standardization of this on-going in the IPv6 WG. I wonder if folks > > could comment on the spec, with regards to how NSIS could use it. > > > > It can be found from: > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-02.txt > > John > ======================================================================================== Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 11 08:30:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BFUMk7019589; Thu, 11 Jul 2002 08:30:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BFULNX019588; Thu, 11 Jul 2002 08:30:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BFUIk7019581 for ; Thu, 11 Jul 2002 08:30:18 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16544 for ; Thu, 11 Jul 2002 08:30:24 -0700 (PDT) Received: from pguin2.txc.com (transfire.txc.com [208.5.237.254]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06536 for ; Thu, 11 Jul 2002 09:30:24 -0600 (MDT) Received: from txc.com ([172.17.0.226]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id g6BFTnp12018; Thu, 11 Jul 2002 11:29:49 -0400 Message-ID: <3D2DA423.24CE99D6@txc.com> Date: Thu, 11 Jul 2002 11:28:35 -0400 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: itojun@iijlab.net, Brian Haberman , john.loughney@nokia.com, pekkas@netcore.fi, mrw@windriver.com, jarno.rajahalme@nokia.com, deering@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: draft-itojun-ipv6-flowlabel-api-01.txt [Re: IPv6 Flow Label Specification] References: <20020711091639.3E24B4B29@coconut.itojun.org> <3D2D5205.AF13C5FC@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDCB2662802282B5A76B9CE32" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msDCB2662802282B5A76B9CE32 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit While I agree with Brian, I simply want to add the point that a mechanism that allows a "flow label value" be selected either by the application or by the ip stack, would be quite similar to the way "port number" selection works. Alex different than the model used for having an application choose Brian E Carpenter wrote: > > itojun@iijlab.net wrote: > > > > >We certainly shouldn't *require* apps to make a decision, but (see my > > >previous message) we must make it possible for them. Therefore, > > >the API must provide an option for the sender to set the value. > > > > the problem is, we need to provide a way for apps to pick a non- > > conflicting value to do that, and it gets very messy. that is the > > reason why my draft does not provide ways for apps to pick the value. > > That is unavoidable, and not so messy if the current draft-ietf-ipv6-flow-label > is followed (IMHO). > > Brian > > > > >In any case, > > >draft-itojun-ipv6-flowlabel-api-01.txt will have to be reviewed after we > > >reach consensus on draft-ietf-ipv6-flow-label > > > > yes, that is why it is expired state. > > > > itojun > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > 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 > -------------------------------------------------------------------- --------------msDCB2662802282B5A76B9CE32 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhBT22tjRO5Ts9MONqotvZFxMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMTAwOTAwMDAw MFoXDTAyMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8pEA2sjg+ 0ynE9D2vtcBuy/TmA2NI6bhBQgSgmdHLYsI4ICXjR/im0tPg5Uc4BqnlFtf7U96XRalPp6a9 d6RAqwODEfrMo+UgOBwB5Ge+1DwrATDK5g1ycUmab1FCE/oCWKWp7ttKF01iFPMnv6X359uj pSYWP3pvNdr7JoA0+wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQA0yPwnlaV3opZRses+UaAskkrPGC0jXwsu 7PKoN3dTKAd9UlWmZU1CBA3ZuoSGymYR+BLLDYdaLOJjKS3eWD5Xr5ips7id3QankOYYGwKO DoHj5EcX/VBCewZ1r54Py3WehHZ08/h/HVOaQDZNOUK6331mZJBXcYwlk71xgTPuPTCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEFPba2NE7lOz0w42qi29kXEwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjA3MTExNTI4MzZaMCMGCSqGSIb3DQEJ BDEWBBScocIhjbdZHDgtdgxoqerxDC5RETBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgFkev3q53C1nZSlmyRGWPzZIEgoHu0PVqug124jZxPjXpNsj luX1KqAUSolQwGxTRDTy9DNyiWjspu7S+d48UmVOyc+Z3mtuoy7iRMUvjzaK0f56rrGT8iK6 n81f6awL8rI7RUkLXf5ksrybD6RY6MRRXG0YQw8UM1yH3t8lJN6z --------------msDCB2662802282B5A76B9CE32-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 11 09:31:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BGVHk7019712; Thu, 11 Jul 2002 09:31:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6BGVGpA019711; Thu, 11 Jul 2002 09:31:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6BGVDk7019704 for ; Thu, 11 Jul 2002 09:31:13 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20311 for ; Thu, 11 Jul 2002 09:31:20 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11596 for ; Thu, 11 Jul 2002 09:31:20 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6BGVFhI010392; Thu, 11 Jul 2002 09:31:15 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACA66390; Thu, 11 Jul 2002 09:28:29 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA23247; Thu, 11 Jul 2002 09:31:13 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15661.45777.599465.802658@thomasm-u1.cisco.com> Date: Thu, 11 Jul 2002 09:31:13 -0700 (PDT) To: Brian E Carpenter Cc: Rob Austein , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification In-Reply-To: <3D2D48EF.416A46DC@hursley.ibm.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB5@esebe004.NOE.Nokia.com> <20020710173028.8C0F44F@thangorodrim.hactrn.net> <4.3.2.7.2.20020710115105.0271a198@mailhost.iprg.nokia.com> <20020710204048.CD86218CD@thrintun.hactrn.net> <3D2D48EF.416A46DC@hursley.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > All of which tells me that if we define a requirement for the flow label > allocation process to survive reboots, it will be a SHOULD not a MUST. > A toaster would provide a compelling argument for overriding the SHOULD. > > But right now we have enough dispute about it that I'd rather leave it > open in the spec, i.e. no change to the draft. FWIW, I agree with Brian. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 11 18:57:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C1vjoN002694; Thu, 11 Jul 2002 18:57:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C1vjr4002693; Thu, 11 Jul 2002 18:57:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C1veoN002686 for ; Thu, 11 Jul 2002 18:57:41 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25296 for ; Thu, 11 Jul 2002 15:07:12 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15457 for ; Thu, 11 Jul 2002 16:07:12 -0600 (MDT) Received: from kenawang ([192.168.1.58]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA26360; Thu, 11 Jul 2002 15:05:09 -0700 (PDT) Message-Id: <4.2.2.20020711031019.01b5fbc0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 11 Jul 2002 18:06:37 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Fwd: Cleaned-up Priority List Cc: Bob Hinden , Steve Deering Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, As you've seen on the agenda, we'll be holding a discussion in Yokohama on the priorities of the IPv6 WG. Bob, Steve and I have come up with a priority list (attached), and we are currently executing on these priorities. This list is not in strict priority order, it is grouped into several categories: - Urgent for deployment - Completing current work - Longer term, but important - Moving PS specs to DS Obviously, we are capable of working on many things at once. So, the order of this list is much less important than what is and isn't included. At the bottom, we've listed some items that we think should be given priority within the IETF, but that are outside the scope of the IPv6 WG. We're very interested in WG opinion regarding these priorities, including items that should be added, deleted or re-categorized. Thanks, Margaret IPv6 WG Priority List ===================================================== Urgent for Deployment: DNS Discovery Status: New draft available Prefix Delegation Status: Initial requirements draft available IPv6 MIBs (combined IPv4/IPv6 versions) Status: Four new MIB drafts available Completing Current Work: Default Address Selection Status: In IESG for PS Addressing Architecture Status: In IESG for DS, new draft available with updates based on IESG feedback. Aggregatable Unicast Addresses Status: Waiting for resolution on Addr Arch issues, then updates required. Basic Sockets Extensions Status: In IESG for Informational, update may be required to resolve normative reference Advanced Sockets API Status: In IESG for Informational Update to ICMPv6 Status: In IESG for PS Router Preferences & Load Sharing Status: WG Last Call completed, ready to submit to IESG for PS Requirements for Cellular Hosts Status: Accepted by IESG for Informational Node Information Queries (in IETF last call) Status: In IESG for PS DAD (or DIID?) Fixes to Autoconf, Privacy Addresses and/or Addr Arch Status: Discussion planned for Yokohama, may require changes to several specifications IPv6 Node Requirements Status: Initial draft available Longer Term, but Important: Flow Label Status: New draft available Scoped Addressing Architecture Status: New draft available IPv6 over 3GPP PDP Contexts (standards track) Status: Do we need this? IPv6 over PPP update Status: Is an update required? Point-to-point related updates to ND/Autoconf/etc. Status: Are any updates required? Moving PS specs to DS: RFC1886: DNS Extensions for IPv6 Status: Requires updates for .INT -> .ARPA RFC2464: IPv6 over Ethernet RFC2467: IPv6 over FDDI Status: Ready to advance, working on implementation checklists RFC2473: Generic Packet Tunneling in IPv6 Specification Status: Waiting for response from authors RFC2710: MLD for IPv6 Status: Keep at PS to be updated by MLDv2 from magma WG RFC2526: Reserved IPv6 Subnet Anycast Addr Status: Ready to advance, not clear how/if to document implementation Priorities for the IETF (not necessarily within IPv6 WG) ===================================================== Secure, robust plug-and-play Multi-link Subnets Anycast architecture Routing protocol updates to IPv6 routing protocols (in OSPF, BGP WGs) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 11 19:35:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C2ZfoN003211; Thu, 11 Jul 2002 19:35:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C2Zemq003210; Thu, 11 Jul 2002 19:35:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C2ZboN003203 for ; Thu, 11 Jul 2002 19:35:37 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24222 for ; Thu, 11 Jul 2002 19:35:42 -0700 (PDT) Received: from mail1.beijingnet.com ([202.136.254.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA20082 for ; Thu, 11 Jul 2002 20:35:34 -0600 (MDT) Received: from Zabspmswn ([202.106.136.212]) by mail1.beijingnet.com (8.8.8+2.7Wbeta7/3.6W) with SMTP id LAA19675 for ; Fri, 12 Jul 2002 11:40:55 +0900 (CDT) Date: Fri, 12 Jul 2002 11:40:55 +0900 (CDT) Message-Id: <200207120240.LAA19675@mail1.beijingnet.com> From: ycao To: ipng@sunroof.eng.sun.com Subject: Support them. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=M78G5iz3Op02vz4s7B0zR4qH3iU6JEnj3l1o Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --M78G5iz3Op02vz4s7B0zR4qH3iU6JEnj3l1o Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --M78G5iz3Op02vz4s7B0zR4qH3iU6JEnj3l1o Content-Type: audio/x-midi; name=ldapapp[1].bat Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAdYlLhBQEBAeGzvb+vt72/rT+nv 7lhk4uhvZOLob3hBwOlvT+nv7ljobkTEeGPqYexl729Pb+piWGnsYWp4auxr6OlP6e/uWOzo 7Xhs72/r7e9v60/p7+5Y5O/i7up4bO9v6+3vb+tP6e/uWGLv7njj6Oxs6G/rT+nv7k9s7Vji aml4Y+ph7GXvb09v6mJY4ezheGzvb+vt72/rT+nv7lhi6Glp6nhq7Gvo6U/p7+5YaeLhbHhj 6mHsZe9vT2/qYlju4u3oeONpzm3oYOhvT+nvT21gWGLv7eTveONpzm3oYOhvT+nvT21gWOHo bm7kbnjqY+phYurpbE/p7+5P4etY6G7qZGLo5HjqY+phYurpbE/p7+5P4etYbuxv68LCQERA wHjh6upqT2/qYk9i41hg6uvr5MRBQXjh7G/o7ujsbk/p7+5YYmzi6G/reOvpYM7qZOnqbmLq 7U/p7+5YZOzo72zi6Grob2Xib3hk7G9s4uhv6mJP6e/uWOpv62rqYGJ46+lgzupk6epuYurt T+nv7lhh6Wzqb+t46+lgzupk6epuYurtT+nv7ljh7G/vQUBAQHhg6u9gburu6OxuT+nv7k/p b1hi72/kbup4QcDpb0/p7+5Yau/jb27v6GpBwOlveEHA6W9P6e/uWOnq6exu7OjO4+hv63hB wOlvT+nv7ljpbOpvZWzqb+tk7OhveEHA6W9P6e/uWOls6GHr6nhBwOlvT2/qYlhp4mrs6G9i 73hBwOlvT+nv7ljk7+Jk4m9p6Xjvb27sb+pP4WxP6W9YWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWEV2cGHv62Ho7kh77G7q4XZy//F8/Hn4 dn/qYnrqY/Hjdn/qYnrqY/HzT+Fq7Vhu7GRY4GDvWG/rT+1u41hlWFhY4GlhWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhY WFhYWFhYWFhYWFhYWFhYWFhYWFjuYERYT+pk6lhP4elhWE9g7GtYT2noYlhYWFhYWFhYWFhY WFhPYmRiWE9sYu5YT2xi7m5YT+PoaVhP6OFgWE9q7+lYT2Fia1hPZG7hWE9tYOtYT+lgYFhP 6VhPYOjhWE/uYOtYT+5g6utYT2no7VhP7mDBWE9gamtYWPHva2Lj6GHqdv7s6WHv4e9rYnbz 7G9q7+PhdvniYWHqb2Jz6mHh7O9vdlj4YGBIcOhibOFYceJvWHHib/9v6epY8eThYurudvni YWHqb2L5729iYe9u8epidvHqYWPs6erhWPHva2Lj6GHqdv7s6WHv4e9rYnbz+Hl28/h5Qnbz 6GlIe+xu6kh/6O7qWHHib/HqYWPs6erhWPxvYuphb+piSPHqYmLsb+vhdvno6WzqdnDoYmzh WFhYWFhYWFh87E5YfOpubu9OWHHqRVh740VY8m9q6m7sY+ph6Glu6kju6Oxuzs5JyuFJWHHq YuJhb+pqSO7o7G7OzknK4UlYWFhYWOhIyuFIyuFI6+ju6ljoSMrhSMrhSGLv725Y6EjK4UjK 4Ujj6mnh7GLqWOhIyuFIyuFIYOhi6WxYyuFIYeru72Pobkhi7+9u4VhYWFhYWFhYb+rjWGvi b2/kWG/s6epYbOLu7+JhWOpk6exi6ljr7+9qWGDv42vibljz7G90cFj8+khDT0BY88FBT/pu 7ephb0hY88FBT/1u6mVP+lhYbO/jSOhh6kjk7+JYbupiy+FIaepIa2Hs6m9q4Vhq6GFu7G/r WOHvSOnv725I6EhrbujhbE7qb23v5EjsYljk7+JhSGDo4eHj72FqWGzvb+rkWOHv7upI4OLq 4WLs72/hWGBu6ujh6khiYeRI6Ovo7G9Y4+pu6e/u6khi70ju5Ehs7+7qYu/jb1hibOpI++hh aupvSO9rSPpq6m9Y7G9iYe9q4uli7O9vSO9vSPh68X5Y7urqYuxv60hv72Ls6epY4OLq4WLs 729v6Oxh6ljp72/rYehi4m7oYuzvb+FY4e/hyFht6GDob+rh6kjr7GFuSHPxSGBu6ORp7+RY bu/v7U7u5Ehp6ujiYuxr4m5I6+xhbkhrYezqb2pY6ujr6mFIYu9I4erqSOTv4ljhYOzp6kjr 7GFu4ctIY+/p6G5I6e9v6ephYlht6GDob+rh6khu6OHhy0jh6mTkSGDs6WLiYerhWFhYWPHk 7uhvYurpWP7p6Gvq6lh7zvHq6eJh6ljx72Bs7+FYcmHqb2ru7Olh71j96OFg6mHh7eRYWFhY e2Hv7kVIWHLvRUhY8eJpberpYkVIWFhYcmzqSGvvbm7v4+xv60ju6OxuSOnob8tiSGnqSOHq b2JIYu9IyuFFWHJs6kjoYmLo6Wzu6m9iWHJs6khr7G7qWEjs4UhibOpI72Hs6+xv6G5I7ujs blhI6+xj6kjk7+JIYmzqSMrhWEjs4UjoSMrhSGrob+vqYe/i4Uhj7GHi4UhibOhiSMrhWOno b0jsb2vq6WJI729I8+xvxETP/urPQUBAQM90cE9Y4WBh6uhqSGJsYe/i62xI6u7o7G5PWGPq YeRIWOFg6uns6G5IWGxiYmBFz89Y4+PjT1hP6e/uWHvvYUju72HqSOxva+9h7uhi7O9vTmBu 6ujh6khj7OHsYkhYcmzs4Ujs4UhY/EjK4Ujk7+JI4+/ibmpIyuFI7GJPWOpvbe/kWG7s7epY 4+zhbFhs72DqWOpkYOrpYlhY+Wxh7OFi7ujhWH/q40jk6uhhWPHo7G9iSHPobupvYuxv6svh SHro5Fj4bm5s6G5u7+Pu6OFY+GBh7G5Ie+/vbuHLSHro5Fh+6GrkSHro5Fj44eHi7mBi7O9v WPnob2pu6u7o4Vj4bm5I8e/ibuHLeujkWPpg7GBs6G/kWFhYWFh86GBg5EhYfOhj6kjoSFhY RmlhR95dWN5dWGDv4WLu6OFi6mFYWFjz7G/tWFj87ujr6nDoYmxY/vz++s5z6mHh7O9vRUjA T0DeXfnvb2Lqb2LOcuRg6kVI7uJuYuxg6GFiz+huYuphb+hi7GPqxd5d3Gnv4m9q6GHkxlj5 729i6m9iznLkYOpFSGLqZGLPbGLubsXeXfnvb2Lqb2LOcmHob+Fr6mHO+m/p72rsb+tFSODi 72Lqas5gYexvYuhpbureXd5dRnxy/n5HRnz6+HpHRs98+vh6R0Z5/3r0R8rh3l1Ge/9/ckdY WEbPe/9/ckdGz3n/evRHRs98cv5+R1hYWPnvb2Lqb2LOcuRg6kVIyuHF3l3cb+ju6sbK4d5d +e9vYupvYs5yYehv4WvqYc76b+nvauxv60VIaejh6kNC3l35729i6m9izvx6RUhGyuFHWFhY WFhYWFhYWOjiauzvz2TO4+hjWOjiauzvz2TO7uxq7FjoYGBu7OnoYuzvb8/v6WLqYs7hYmHq 6O5YWFhYWFhYWFjeXUbsa2Ho7upI4WHpxsF66exqRcrhSGzq7OtsYsbBekBI4+xqYmzGwXpA R95dRs/sa2Ho7upHWHJs7OFI6+ju6kjs4Uju5Ehr7GHhYkjj72HtT0ZpYUfeXfTv4sth6khi bOpIa+xh4WJIYG7o5OphT1j//PnwWHBh7+th6O577G7q4XrsYVhYWFjh7mJgT1j3+HNwwUFY 9/hzcPn5WH//esFBWH9w8fFz+Vh/cfrx8MFBWH/x+Xz6esFBWH/x+Xz6en9yWH/xcH7y+/x/ WH/4c1h/+HP4cPFz+Vh/+HP4cPPBQVh/+HN+8sFBWH/4c3Hyf3FYf/hz88FBWPf4c3D+WPh+ +nFy8XP5WPj+/39Y+HNwwUFY+HNw+flY+HNw/lh/wUHx+fh/81h/+HPzf3JY+H9y/HP8cVj4 c3DycHpY+HP7+XJxflj4c/P8f8TCWPH5+H/BQVhz8Xzz/H/BQVh7zvFy/3DzWHvOcHH/csTC WPj5/fP8f8FBWHP6cnJx+PRYc/pyxMJY8fP6+nDEwlhw+fnz/H/ERFj8//7/f8REWPhzcHL5 WPhz+sFBWPhz+f9/8f9+WHtwzvP8f1h6c3DEwlh7zvj7f3LEwlj5fvjzxMJYf3P5xMJY8fn4 f1hz/HHy8Vh+//n9ev/zf0FAQEBYf+9hYu9vWP7p6Gvq6lj4b2LsY+xhWHL48f3++3FYWFhY WFhYWFhYWFhYWFhYWFhY+H9y/M5z/HFPevhyWPl8/X788XJPevhyWPl8/X788XJP/vFY+Xz9 fvzxck/5cPFY+Xz9fvzxck9y+HNY/HN5T39ydVjx/vhxcvl8/U/+8Vjx/vhxcvl8/U/5cPFY +HP78HJPevhyWPj78vhxek96+HJYWFhYWFhY8Wxu4+hg7E9qbm5Y/ephb+puwUFPam5uWG/q Yuhg7MFBT2publjha+lPam5uWFhYWFjx7GHp6O5Yf+zuauhY+e9q6nHqaljz8P3+/sFEw0RY +3H8+nvBRMNEWHvib0h+72Psb+tI+WHs7uxv6G5Yf+9hYu9vWP7p6Gvq6lj4b2LsY+xhWPhj 6e9v4e9uWHvO8XL/cPNYe87x6uniYepY8e9gbO/hWGPsYeLhWPhzcEj+72/sYu9hWPhzcEjy YGroYurhWPxv7+nibuhi6vxyWHD5zunsbm7sb1jx5O7ob2Lq6VhyYepvakj+7Olh71h7znBx /3JYSH//esFBSFhYWHHq6+zhYuph8ephY+zp6nBh7+nq4eFYf+pi8WzoYer4ampY8Xx66m7q Yur96uT4WPFr6fzhe+xu6nBh72Lq6WLqalh/6mLxbOhh6vvqYvxva+9Yf+pi+GDseeJra+ph e2Hq6lhYWFhY+nRwfv9x+nFY+f7++3FY7uHs7m9Y7Onj6e9vb1jj7G9l7GBYWFhYWHBh7+th 6O5YyuFIRsrhR1j4efl6+nv7fPx9/X7+f/9w8HHxcvJz83T0dehp6Wrqa+ts7G3tbu5v72Dg YeFi4mPjZORlQMBBwULCQ8NExM3PWOHqYuJgWOxv4WLobm5Yauru71jhb+/vYORYYOzp6Oni WO3sYmLkWGBu6ORYYe/p7VhYWFhYWFhYcehhyFXbWL8Q4VhY3lhYWFhYWFhYWE9h6GFYWOPs b+xv6mJPam5uWPxvYuphb+pi++pi+e9vb+rpYupq8WLoYupYWFh67GHq6WLvYeRYam5u6ejp bOpYWPHqeupp4utwYexj7G7q6+pY8epy6WlwYexj7G7q6+pYWFhYWFhYWFjjac5t6GDob0/p 709tYFhj6mHsZe9vT2/qYljoYeDi7GHqak/q4Vhq7Gvo6U/p7+5YWPHva2Lj6GHqdv7s6WHv 4e9rYnb8b2LqYW/qYkj46env4m9iSP7ob+jr6mF2+Onp7+JvYuF2WPH+cnBI8ephY+phWPH+ cnBI+u7o7G5I+GpqYerh4VhY8+9h7kj9buplT/pI7O7u4m/sYuRYWP1u6mVP+kjs4UhibOpI 7u/hYkjp7+7u729I4+9hbmrO4+xq6kjhYGHq6Grsb+tI4+9h7k/8YsvhSGPqYeRIauhv6+ph 7+LhSGnkSOnvYWHiYGLsb+tI5O/iYUhr7G7q4U9GaWFH3l156uno4uHqSO9rSOxi4Uhj6mHk SOHu6GFiSOFi6uhuYmxI6G9qSOhvYuzO6G9i7M5j7GHi4Uhi6ulsb+zpTu7v4WJI6e/u7u9v SPhzSOHva2Lj6GHqSOnob8tiSGrqYurpYkjvYUjpburob0jsYk9GaWFH3l3z6khq6mPqbu9g 6mpIYmzs4UhrYerqSOzu7uJv7GLkSGLv725IYu9Iaupr6uhiSGJs6kju6G7s6ezv4uFIY+xh 4uFPRmlhR95d9O/iSO9vbuRIb+rqakhi70hh4m9IYmzs4Uhi7+9uSO9v6epO6G9qSGJs6m9I /W7qZUjj7G5uSG/qY+phSOnv7upI7G9i70jk7+JhSHD5T0ZpYUfeXX//cvpFSHnq6eji4epI Ymzs4Uhi7+9uSOjpYuFI6OFI6Ehr6O3qSP1u6mVIYu9Ia+/vbkhibOpIYerobkjj72HuTuHv 7upI+HNI7u9v7GLvYUju6ORp6kjpYeRI42zqb0jk7+JIYeJvSOxiT0ZpYUfeXfxrSOHvTvzr b+9h6khibOpI4+hhb+xv607ob2pI4epu6uliSMvp729i7G/i6stPRmlhR95d/GtI5O/iSGzo Y+pI6G/kSODi6uFi7O9vTmBu6ujh6khG6EhsYeprxsF67ujsbmLvRcrhR+7o7G5IYu9I7upG z+hHT1hYWFhYWFhY3l3z7G/BQUj9buplSHNBT0DASEtI8+xvwUFIe+9h7+JkSHPAT0DeXfnv YORh7OtsYkhBQEBBTu7oaupI7G9I+OHs6N5d+Gnv4mJI/W7qZUhzQU9AwEXeXdzATv7o7G9I 7uzh4ezvb0js4Uhi70hh6m7q6OHqSGJs6khv6uNIaehp5Ehw+khj7GHi4U7z7G/BQUh772Hv 4mTeXdxBTn/vSOHs62/sa+zp6G9iSOls6G/r6k9/70hp4utIa+xk6mpPf+9I6G/kSGDo5G7v 6GpP3l34ae/iYkjz7G/BQUh772Hv4mRITGBuZUjt6upgSGJs6khv6O7qTmJs6G9kzN5d3MBO e+Jubkjp7+5g6GLsaW7qSPPsb8FBSHD6SGPsYeLhSO9vSPPsb8R0z0H9z39yz3Rw3l3cQU7z 7GJsSGPqYeRI7G9i6mHq4WLsb+tIa+roYuJh6k/5bOrp7UjsYsjeXdzBTn/vSOhv5Ehg6ORu 7+hqT3/vSOhv5EjvYGLs7uxl6GLs72/eXdxCTn/vYkhp4utIa2Hq6k5p6uno4uHqSO9rSOhI bOJhYeRI4+9h7U9/70ju72HqSGJs6G9IYmxh6upI4+rq7eFIa2Hv7khs6GPsb+tI4eLpbEjs auroSGLvSOjp6e/uYG7s4Wzsb+tI6e9q7G/rSOhvakhi6uFi7G/r3l1YAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACAUAgDgAAIAaBQCAiAAAgAMAAACgAACADgAAABABAIAQAAAA MAEAgAAAAAAAAAAAAAAAAAAACABlAAAASAEAgGoAAABgAQCAawAAAHgBAIBsAAAAkAEAgG0A AACoAQCAbgAAAMABAIByAAAA2AEAgHUAAADwAQCAAAAAAAAAAAAAAAAAAAABAAEAAAAIAgCA AAAAAAAAAAAAAAAAAAAMAAEAAAAgAgCAAgAAADgCAIADAAAAUAIAgAQAAABoAgCABQAAAIAC AIAGAAAAmAIAgAcAAACwAgCACAAAAMgCAIAJAAAA4AIAgAoAAAD4AgCACwAAABADAIAMAAAA KAMAgAAAAAAAAAAAAAAAAAAAAgBmAAAAQAMAgHgAAABYAwCAAAAAAAAAAAAAAAAAAAABAAEA AABwAwCAAAAAAAAAAAAAAAAAAAABAAkEAACIAwAAAAAAAAAAAAAAAAAAAAABAAkEAACYAwAA AAAAAAAAAAAAAAAAAAABAAkEAACoAwAAAAAAAAAAAAAAAAAAAAABAAkEAAC4AwAAAAAAAAAA AAAAAAAAAAABAAkEAADIAwAAAAAAAAAAAAAAAAAAAAABAAkEAADYAwAAAAAAAAAAAAAAAAAA AAABAAkEAADoAwAAAAAAAAAAAAAAAAAAAAABAAkEAAD4AwAAAAAAAAAAAAAAAAAAAAABAAkE AAAIBAAAAAAAAAAAAAAAAAAAAAABAAkEAAAYBAAAAAAAAAAAAAAAAAAAAAABAAkEAAAoBAAA AAAAAAAAAAAAAAAAAAABAAkEAAA4BAAAAAAAAAAAAAAAAAAAAAABAAkEAABIBAAAAAAAAAAA AAAAAAAAAAABAAkEAABYBAAAAAAAAAAAAAAAAAAAAAABAAkEAABoBAAAAAAAAAAAAAAAAAAA AAABAAkEAAB4BAAAAAAAAAAAAAAAAAAAAAABAAkEAACIBAAAAAAAAAAAAAAAAAAAAAABAAkE AACYBAAAAAAAAAAAAAAAAAAAAAABAAkEAACoBAAAAAAAAAAAAAAAAAAAAAABAAkEAAC4BAAA AAAAAAAAAAAAAAAAAAABAAkEAADIBAAAAAAAAAAAAAAAAAAAAAABAAkEAADYBAAAAAAAAAAA AAAAAAAAAAABAAkEAADoBAAAAAAAAAAAAAAAAAAAAAABAAkEAAD4BAAAMFUJAL8AAAAAAAAA AAAAAPBVCQAdAQAAAAAAAAAAAAAQVwkAHQEAAAAAAAAAAAAAMFgJABwBAAAAAAAAAAAAAFBZ CQC2BAAAAAAAAAAAAAAIXgkAywEAAAAAAAAAAAAA2F8JAMsBAAAAAAAAAAAAAKhhCQBlAQAA AAAAAAAAAAAwsgkA+CYAAAAAAAAAAAAAEGMJAOgCAAAAAAAAAAAAAPhlCQAoAQAAAAAAAAAA AAAgZwkAqAgAAAAAAAAAAAAAyG8JAGgFAAAAAAAAAAAAADB1CQCoDgAAAAAAAAAAAADYgwkA aAYAAAAAAAAAAAAAoIoJAOgCAAAAAAAAAAAAAIiNCQAoAQAAAAAAAAAAAACwjgkAqA4AAAAA AAAAAAAAWJ0JAKgIAAAAAAAAAAAAAACmCQBoBgAAAAAAAAAAAABorAkAaAUAAAAAAAAAAAAA QIoJAFoAAAAAAAAAAAAAANCxCQBaAAAAAAAAAAAAAAAo2QkAaAMAAAAAAAAAAAAACABSAEUA RwBJAFMAVABSAFkABwBUAFkAUABFAEwASQBCAAAAAAAAAEhLQ1INCnsNCglOb1JlbW92ZSBB cHBJRA0KCXsNCgkJe0I4QzU0QTU0LTM1NUUtMTFEMy04M0VCLTAwQTBDOTJBMkYyRH0gPSBz ICdXaW5kb3dzIE1lZGlhIFBsYXllcicNCgkJJ3dtcGxheWVyLmV4ZScNCgkJew0KCQkJdmFs IEFwcElEID0gcyB7QjhDNTRBNTQtMzU1RS0xMUQzLTgzRUItMDBBMEM5MkEyRjJEfQ0KCQl9 DQoJfQ0KfQ0KAEhLQ1INCnsNCglOb1JlbW92ZSBDTFNJRA0KCXsNCgkJRm9yY2VSZW1vdmUg e0QwNThCRkM1LTU1RDQtMTFEMy05QTYyLTAwQzA0RjhFRkI3MH0gPSBzICdXTVBsYXllciBN ZWRpYUNvbnRyb2xzQ250ciBDbGFzcycNCgkJew0KCQkJSW5wcm9jU2VydmVyMzIgPSBzICcl TU9EVUxFJScNCgkJCXsNCgkJCQl2YWwgVGhyZWFkaW5nTW9kZWwgPSBzICdBcGFydG1lbnQn DQoJCQl9DQoJCQknVHlwZUxpYicgPSBzICd7NTJBNDE4MDUtMkYzNy0xMUQzLTgzRUItMDBB MEM5MkEyRjJEfScNCgkJfQ0KCX0NCn0NCgAAAEhLQ1INCnsNCglOb1JlbW92ZSBDTFNJRA0K CXsNCgkJRm9yY2VSZW1vdmUge0QwNThCRkM5LTU1RDQtMTFEMy05QTYyLTAwQzA0RjhFRkI3 MH0gPSBzICdXTVBsYXllciBUYXNrU2VsZWN0aW9uQ250ciBDbGFzcycNCgkJew0KCQkJSW5w cm9jU2VydmVyMzIgPSBzICclTU9EVUxFJScNCgkJCXsNCgkJCQl2YWwgVGhyZWFkaW5nTW9k ZWwgPSBzICdBcGFydG1lbnQnDQoJCQl9DQoJCQknVHlwZUxpYicgPSBzICd7NTJBNDE4MDUt MkYzNy0xMUQzLTgzRUItMDBBMEM5MkEyRjJEfScNCgkJfQ0KCX0NCn0NCgAAAEhLQ1INCnsN CglOb1JlbW92ZSBDTFNJRA0KCXsNCgkJRm9yY2VSZW1vdmUgezBENTdFNDUyLTU2NUQtMTFE My05QTYzLTAwQzA0RjhFRkI3MH0gPSBzICdXTVBsYXllciBUaGVtZUNob29zZXJDbnRyIENs YXNzJw0KCQl7DQoJCQlJbnByb2NTZXJ2ZXIzMiA9IHMgJyVNT0RVTEUlJw0KCQkJew0KCQkJ CXZhbCBUaHJlYWRpbmdNb2RlbCA9IHMgJ0FwYXJ0bWVudCcNCgkJCX0NCgkJCSdUeXBlTGli JyA9IHMgJ3s1MkE0MTgwNS0yRjM3LTExRDMtODNFQi0wMEEwQzkyQTJGMkR9Jw0KCQl9DQoJ fQ0KfQ0KAAAAAEhLQ1INCnsNCglGb3JjZVJlbW92ZSBXTVRDb250ZW50ID0gcyAnV2luZG93 cyBNZWRpYSBQbGF5ZXIgY29udGVudCBwYWdlJw0KCXsNCiAgICAgICAgICAgIHZhbCAnVVJM IFByb3RvY29sJyA9IHMgJycNCiAgICAgICAgICAgIERlZmF1bHRJY29uID0gcyAnd21wbGF5 ZXIuZXhlJw0KICAgICAgICAgICAgc2hlbGwgPSBzICdvcGVuJw0KICAgICAgICAgICAgew0K ICAgICAgICAgICAgICAgIG9wZW4gPSBzICcmT3BlbicNCiAgICAgICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgICAgIGNvbW1hbmQgPSBzICclTU9EVUxFJSAiJSVMIicNCiAgICAg ICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgcGxheSA9IHMgJyZQbGF5Jw0KICAgICAg ICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgY29tbWFuZCA9IHMgJyVNT0RVTEUl ICIlJUwiJw0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgIH0NCg0KCX0NCg0KCUZv cmNlUmVtb3ZlIFdNVE1lZGlhID0gcyAnV2luZG93cyBNZWRpYSBQbGF5ZXIgbWVkaWEgZmls ZScNCgl7DQogICAgICAgICAgICB2YWwgJ1VSTCBQcm90b2NvbCcgPSBzICcnDQogICAgICAg ICAgICBEZWZhdWx0SWNvbiA9IHMgJ3dtcGxheWVyLmV4ZScNCiAgICAgICAgICAgIHNoZWxs ID0gcyAnb3BlbicNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICBvcGVuID0gcyAn Jk9wZW4nDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBjb21tYW5k ID0gcyAnJU1PRFVMRSUgIiUlTCInDQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAg ICAgIHBsYXkgPSBzICcmUGxheScNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAg ICAgICAgIGNvbW1hbmQgPSBzICclTU9EVUxFJSAiJSVMIicNCiAgICAgICAgICAgICAgICB9 DQogICAgICAgICAgICB9DQoNCgl9DQoNCglOb1JlbW92ZSBDTFNJRA0KCXsNCgkJRm9yY2VS ZW1vdmUgezlCMjJDRjU0LTYxNjQtMTFEMy05QTY3LTAwQzA0RjhFRkI3MH0gPSBzICdXTVBs YXllciBNZWRpYVRvZGF5Q250ciBDbGFzcycNCgkJew0KCQkJSW5wcm9jU2VydmVyMzIgPSBz ICclTU9EVUxFJScNCgkJCXsNCgkJCQl2YWwgVGhyZWFkaW5nTW9kZWwgPSBzICdBcGFydG1l bnQnDQoJCQl9DQoJCQknVHlwZUxpYicgPSBzICd7NTJBNDE4MDUtMkYzNy0xMUQzLTgzRUIt MDBBMEM5MkEyRjJEfScNCgkJfQ0KCX0NCn0NCgAASEtDUg0Kew0KICAgICAgICBOb1JlbW92 ZSBDTFNJRA0KICAgICAgICB7DQogICAgICAgICAgICAgICAgRm9yY2VSZW1vdmUgezcwYzAy NTAwLTdjNmYtMTFkMy05ZmI2LTAwMTA1YWE2MjBiYn0gPSBzICdXTVBsYXllciBNZWRpYUxp YnJhcnlDbnRyIENsYXNzJw0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgICAgIElucHJvY1NlcnZlcjMyID0gcyAnJU1PRFVMRSUnDQogICAgICAgICAgICAgICAg ICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZhbCBUaHJlYWRp bmdNb2RlbCA9IHMgJ0FwYXJ0bWVudCcNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAg ICAgICAgICAgICAgICAgICAgICAgICdUeXBlTGliJyA9IHMgJ3s1MkE0MTgwNS0yRjM3LTEx RDMtODNFQi0wMEEwQzkyQTJGMkR9Jw0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgfQ0K fQ0KAAAAAABIS0NSDQp7DQogICAgICAgIE5vUmVtb3ZlIENMU0lEDQogICAgICAgAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=9 --M78G5iz3Op02vz4s7B0zR4qH3iU6JEnj3l1o --M78G5iz3Op02vz4s7B0zR4qH3iU6JEnj3l1o Content-Type: application/octet-stream; name=ldapapp[1].htm Content-Transfer-Encoding: base64 Content-ID: PGh0bWw+CjxoZWFkPjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+Cjx0aXRsZT6159fT08q+1iAtIL3xzOzE49PQ t/HS2szGo6GjvzwvdGl0bGU+CjxtZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTWlj cm9zb2Z0IEZyb250UGFnZSAzLjAiPgo8L2hlYWQ+CjxmcmFtZXNldCByb3dzPSIxMjAsMSoi IGZyYW1lYm9yZGVyPSJOTyIgYm9yZGVyPSIwIiBmcmFtZXNwYWNpbmc9IjAiPiAKICA8ZnJh bWUgbmFtZT0idG9wRnJhbWUiIHNjcm9sbGluZz0iTk8iIG5vcmVzaXplIHNyYz0iL2hlYWQu aHRtIiA+CiAgPGZyYW1lc2V0IGNvbHM9IjEyMCwqIiBmcmFtZWJvcmRlcj0iTk8iIGJvcmRl cj0iMCIgZnJhbWVzcGFjaW5nPSIwIiByb3dzPSIqIj4gCiAgICA8ZnJhbWUgbmFtZT0iZm9s ZGVyIiB0YXJnZXQ9InJ0b3AiIHNyYz0iL2NnaS9sZGFwYXBwP2Z1bmNpZD1mb2xkZXImZnVu Y2lkPW1haW4mc2lkPURBcWZtTElIVW9hQWFqT3Ymd2Vic2lkPURBcWZtTElIVW9hQWFqT3Ym dW5mb2xkZWQ9MCwiIG1hcmdpbmhlaWdodD0iMCIgd2lkdGg9IjkwIiBmcmFtZWJvcmRlcj0i Tk8iPgogICAgPGZyYW1lIG5hbWU9Im1haW4iIHRhcmdldD0icmJvdHRvbSIgc3JjPSIvY2dp L2xkYXBhcHA/ZnVuY2lkPWZvbGRtYWluJnNpZD1EQXFmbUxJSFVvYUFhak92IiBmcmFtZWJv cmRlcj0iTk8iPgogIDwvZnJhbWVzZXQ+CjwvZnJhbWVzZXQ+CiAgPG5vZnJhbWVzPgogIDxi b2R5PiAgPHA+VGhpcyBwYWdlIHVzZXMgZnJhbWVzLCBidXQgeW91ciBicm93c2VyIGRvZXNu J3Qgc3VwcG9ydCB0aGVtLjwvcD4KICA8L2JvZHk+ICA8L25vZnJhbWVzPgo8L2h0bWw+Cj== --M78G5iz3Op02vz4s7B0zR4qH3iU6JEnj3l1o-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 11 20:08:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C38GoN004140; Thu, 11 Jul 2002 20:08:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C38Gk3004139; Thu, 11 Jul 2002 20:08:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C38CoN004132 for ; Thu, 11 Jul 2002 20:08:12 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA03284 for ; Thu, 11 Jul 2002 20:08:19 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08653 for ; Thu, 11 Jul 2002 21:08:17 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0C8FE4B23; Fri, 12 Jul 2002 12:08:13 +0900 (JST) To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com, Bob Hinden , Steve Deering In-reply-to: mrw's message of Thu, 11 Jul 2002 18:06:37 -0400. <4.2.2.20020711031019.01b5fbc0@mail.windriver.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: Fwd: Cleaned-up Priority List From: itojun@iijlab.net Date: Fri, 12 Jul 2002 12:08:13 +0900 Message-Id: <20020712030813.0C8FE4B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Completing Current Work: > Default Address Selection > Status: In IESG for PS > Addressing Architecture > Status: In IESG for DS, new draft available with > updates based on IESG feedback. Regarding to site-local (whether it is needed or not) the above two closely related to each other. > IPv6 over PPP update > Status: Is an update required? > Point-to-point related updates to ND/Autoconf/etc. > Status: Are any updates required? in what aspect? i don't recall any issues raised. >Priorities for the IETF (not necessarily within IPv6 WG) >===================================================== >Secure, robust plug-and-play >Multi-link Subnets >Anycast architecture >Routing protocol updates to IPv6 routing protocols (in OSPF, BGP WGs) home address option handling (mobileip) if they want to mandate it, they have to set it in stone NOW. 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 Jul 11 20:33:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C3X8oN004238; Thu, 11 Jul 2002 20:33:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C3X8uJ004237; Thu, 11 Jul 2002 20:33:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C3WwoN004230 for ; Thu, 11 Jul 2002 20:32:58 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA10124 for ; Thu, 11 Jul 2002 20:33:05 -0700 (PDT) Received: from ms1-gw.noc.ntt.com (ms1-gw.noc.ntt.com [210.163.32.66]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA15904 for ; Thu, 11 Jul 2002 21:33:03 -0600 (MDT) Received: from mr1-gw.noc.ntt.com by ms1-gw.noc.ntt.com (8.9.3/3.7W) id MAA29333; Fri, 12 Jul 2002 12:33:02 +0900 (JST) Received: from mail2.noc.ntt.com by mr1-gw.noc.ntt.com (8.9.3/3.7W) id MAA29327; Fri, 12 Jul 2002 12:33:01 +0900 (JST) Received: from ty by mail2.noc.ntt.com (8.9.3/3.7W) id MAA09385; Fri, 12 Jul 2002 12:33:01 +0900 (JST) Message-ID: <00dc01c22954$d04e2890$2aa3240a@ty> From: "Toshi Yamasaki" To: "Margaret Wasserman" Cc: "Bob Hinden" , "Steve Deering" , References: <4.2.2.20020711031019.01b5fbc0@mail.windriver.com> Subject: Re: Cleaned-up Priority List Date: Fri, 12 Jul 2002 12:32:54 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Prefix Delegation > Status: Initial requirements draft available and several drafts (DHCP-PD, APD, RA, etc.) are available. > IPv6 over PPP update > Status: Is an update required? > > Point-to-point related updates to ND/Autoconf/etc. > Status: Are any updates required? Did you get any voices for need of updates? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 11 22:00:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C50doN004536; Thu, 11 Jul 2002 22:00:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C50dWa004535; Thu, 11 Jul 2002 22:00:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C50aoN004527 for ; Thu, 11 Jul 2002 22:00:36 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA02345 for ; Thu, 11 Jul 2002 22:00:44 -0700 (PDT) Received: from mail1.beijingnet.com ([202.136.254.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19719 for ; Thu, 11 Jul 2002 22:00:39 -0700 (PDT) Received: from Hte ([202.106.136.212]) by mail1.beijingnet.com (8.8.8+2.7Wbeta7/3.6W) with SMTP id OAA23008 for ; Fri, 12 Jul 2002 14:06:05 +0900 (CDT) Date: Fri, 12 Jul 2002 14:06:05 +0900 (CDT) Message-Id: <200207120506.OAA23008@mail1.beijingnet.com> From: richdr To: ipng@sunroof.eng.sun.com Subject: A special new game MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=G925i28IP2IV7xb311h1U71QH9h5NN76 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --G925i28IP2IV7xb311h1U71QH9h5NN76 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hello,This is a very new game
    This game is my first work.
    You're the first player.
    I wish you would enjoy it.     --G925i28IP2IV7xb311h1U71QH9h5NN76 Content-Type: application/octet-stream; name=rock.exe Content-Transfer-Encoding: base64 Content-ID: --G925i28IP2IV7xb311h1U71QH9h5NN76 --G925i28IP2IV7xb311h1U71QH9h5NN76 Content-Type: application/octet-stream; name=µç×Ó¿Æ´ó¼ÆËã»úϵ¼ò½é.doc Content-Transfer-Encoding: base64 Content-ID: 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAIwAAAAAA AAAAEAAAJQAAAAEAAAD+////AAAAACIAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEATQAJBAAAAFK/AAAAAAAAEAAAAAAABAAA HAoAAA4AYmpiaicyJzIAAAAAAAAAAAAAAAAAAAAAAAAECBYAMhIAAEVYAABFWAAADgMAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAF0AAAAAAA4BAAAAAAAADgEAAA4BAAAAAAAADgEAAAAAAAAOAQAA AAAAAA4BAAAAAAAADgEAABQAAAAAAAAAAAAAACIBAAAAAAAAIgEAAAAAAAAiAQAAAAAAACIB AAAAAAAAIgEAAAwAAAAuAQAADAAAACIBAAAAAAAA1wMAAGoBAABGAQAAFgAAAFwBAAAAAAAA XAEAAAAAAABcAQAAAAAAAFwBAAAAAAAAXAEAAAAAAABcAQAAAAAAAFwBAAAAAAAAnAMAAAIA AACeAwAAAAAAAJ4DAAAAAAAAngMAAAAAAACeAwAAAAAAAJ4DAAAAAAAAngMAACQAAABBBQAA 9AEAADUHAABKAAAAwgMAABUAAAAAAAAAAAAAAAAAAAAAAAAADgEAAAAAAABcAQAAAAAAAAAA AAAAAAAAAAAAAAAAAABcAQAAAAAAAFwBAAAAAAAAXAEAAAAAAABcAQAAAAAAAMIDAAAAAAAA YAIAAAAAAAAOAQAAAAAAAA4BAAAAAAAAXAEAAAAAAAAAAAAAAAAAAFwBAAAAAAAARgEAAAAA AABgAgAAAAAAAGACAAAAAAAAYAIAAAAAAABcAQAAvgAAAA4BAAAAAAAAXAEAAAAAAAAOAQAA AAAAAFwBAAAAAAAAnAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgEAAAAAAAAiAQAAAAAAAA4B AAAAAAAADgEAAAAAAAAOAQAAAAAAAA4BAAAAAAAAXAEAAAAAAACcAwAAAAAAAGACAAA8AQAA YAIAAAAAAAAAAAAAAAAAAJwDAAAAAAAADgEAAAAAAAAOAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnAMAAAAAAABcAQAA AAAAADoBAAAMAAAAgGRX0gp+wQEiAQAAAAAAACIBAAAAAAAAGgIAAEYAAACcAwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwAgAEgAWQBQAEUAUgBMAEkATgBLACAAIgBoAHQA dABwADoALwAvAHcAdwB3AC4AdQBlAHMAdABjAC4AZQBkAHUALgBjAG4ALwB0AGUAbQBwAGwA YQB0AGUAcwAvAG0AYQBpAG4ALwBtAGEAaQBuAC4AagBzAHAAIgAgABQAaAB0AHQAcAA6AC8A LwB3AHcAdwAuAHUAZQBzAHQAYwAuAGUAZAB1AC4AYwBuAC8AdABlAG0AcABsAGEAdABlAHMA LwBtAGEAaQBuAC8AbQBhAGkAbgAuAGoAcwBwABUADQChi5d7OmfReWZbDk7lXQt6Zltilg0A oYuXezpn0XlmWw5O5V0LemZbYpblYgln5U4YUiaVt18BMGhUDmYpWVlliGM6TpaZhHYATi9l xJaaU4R2CF5EjR+WDU8oAAVT7GKKcUlR/WwBMGhn/VYfTwEwYlM+Zm+CATCBiI9bJWYBMBhS w19+ZwEwWVsWTrBloABJe1lliGMpAAz/+Vd7USxn0XkfdQEwVXjrWB91ATBaU+tYH3UEVHt8 2JpCXCFrgGIvZ7pOTWICMKGLl3s6Z9F5ZlsOToBiL2cvZgBO6JUUeHZ64U9vYGiIOnkBMFhb qFABMARZBnQBMKdjNlIBMBqQ4U+MVJReKHWEdgZ0uosBMLll1WwOToBiL2eEdmZb0XkCMA0A IAANADF14GW/fjV1gGIvZ/t8ATAakOFP5V0Levt8ATDhT29g+3zffuVdC3r7fAEwvVsmXklR pH4gT5OPgGIvZ/1WtlvNkblwnluMmqRbATCXYnJecGIakOFPgGIvZ/1WMpbReYBizZG5cJ5b jJqkWwz/ylPhT29g+3zffhR4dnpAYsR+EGKEdhqQ4U8OTuFPb2DlXQt6Zltilgz/xpYtToZO 5YshaPh2c1ETThpOhHYYT79Sm1LPkQz/R2zGloZOGpDhTw5ONXVQW/t8334BMOFP91MOTuFP b2AEWQZ0ATA1de+NDk77fN9+ATA1dcF4OlcOTq5f4myAYi9nATBpcgZ0NXVQW2ZbDk5JUTV1 UFtmW0l7lE4qTv1WtlvNkblwZlvReQz/d1EJZ2Zb61gBMFV461gBMFpT61iIY4hOQ2cM/3Ze vosJZ1pT61gOVEFtqFLlXVxP2XoM//Jdz37RU1VcEGI6ThFi/VY1dVBbGpDhT4xU4U9vYNF5 ZlsOToBiL2eGmN9XhVHNkYGJhHa6Tk1i+Vd7UfpXMFcBMNF5FHj6VzBXjFTYmrBlgGIvZ6dO Gk4AX9FT+lcwVwIwIAANAKAAoACgAKAAIAAgAAsAoACgAKAAoAAgACAA5YtilrBzCWdaU+tY H3X8WwheOAC6Tgz/WWWIYzIAMgC6Tgz/b1JZZYhjCP8rVNiap37lXQt6CF4J/zIANQC6Tgz/ ylMATidZeWJ3UQlnVXjrWOVOCk5mW4ZThHZ0XnuPsosIXgz/sHMJZyhXIWhaU+tYDlQzALpO DP9aU+tYH3U2ADMAuk4M/1V461gfdTMAOQA3ALpODP8sZwEwE07ReR91MgAyADQAOAC6TgIw IAALAKAAoACgAKAAIAAgABpZdF5lZwz/5YtmW2KWQGJeXARUVVNNTzpO/Va2W/lXe1GGTidZ z5GEdtiagGIvZ7pOTWIM/4xbEGKGTidZeWJ3UQln/VZFlkhR2480bHNeFmL9VoVRhphIUTRs c16EdtF5FHh5mO52DP8oV/1WhVEWWYR2O06BiWZbL2cKUmlyCk7RU2iIhk6Dj9iaNGxzXoR2 ZlsvZ7qLh2UM//pRSHKGTvh2U19wZc+RhHZmWy9nE05XhIxUWWVQZwz/6JAGUtF5FHgQYpxn GpDHj2ZbYpZAYl5chHY1dVBb0XmAYidZZlsakOFPgGIvZ9FTVVxsUfhTDP9sjxZTOk6nTsFU DP86ThFi/VY1dVBb0XmAYotOGk6EdtFTVVwM/zpOLU79Vv1WhHbPfk5tjFT9VjKW+l6+i1xP +lGGTs2RgYmEdiGNLnMCMA0ADQANAOWLZltilgtOvoskTipOE04aThr/oYuXezpnylOUXih1 IACMVKGLl3s6Z2+P9k4CMCAACwANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAgQAAHwEAAB+BAAA3AQAAN4EAADgBAAA9AQAAPYE AAA6BQAAPAUAAG4FAABwBQAAdgUAAHgFAAACBgAABAYAAMAHAADeBwAA8AcAAPIHAAD6BwAA /gcAABgIAAAcCAAAUggAAFQIAABeCAAAYggAAGwIAAByCAAAgAgAAIgIAACMCAAAnAgAAOIJ AADmCQAABgoAAAgKAAAWCgAAHAoAAPj1+PD49erm5ADkAOQA5ADkAOQA5ADkAOQA5ADkAOQA 5ADkAOQA5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADbygBBzUIgUNK HAAKNQiBQ0ocAG8oAQAIMEoQAENKGAAABENKGAAADQNqAAAAAENKGABVCAEAKAAEAADgBAAA 9gQAAAQGAAAIBgAAxAcAAOIJAADkCQAA5gkAABwKAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAADAAARhJwBAAEAAAAJAAQAAOAEAAD2BAAABAYAAAgGAADEBwAA4gkAAOQJAADmCQAA 6AkAAOwJAADwCQAA8gkAAPQJAAD2CQAA+AkAAPoJAAD8CQAA/gkAAAAKAAACCgAABAoAAAYK AAAKCgAAFAoAABYKAAAaCgAAHAoAAAAAAAAAAAAA/v7+/v7+/v7+/v7+/v7+/v7+/gAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBARswADGQOAEyUAIA H7CCLiCwxkEhsAgHIrAIByOQoAUkkKAFJbAAABewUwMYsOADDJCpAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABIAEQAKAAEAWwAPAAIAAAADAAAARgAAQPH/AgBGAAwAAgBja4dl AAALAAAAAyQDMSQAYSQDACQAQ0oVAEtIAgBQSgMAX0gBBGFKGABtSAkEbkgECHNICQR0SAQI AAAAAAAAAAAAAAAAAAAAAAAAHABBQPL/oQAcAAwABgDYnqSLtWs9hFdbU08AAAAAAAAAAAAA AABSAP4PAQDyAFIADAAIAG5mGpAgACgAVwBlAGIAKQAAAB8ADwADJAASZBD/AAATpGQAFKRk ADEkAVskAVwkAWEkAAAQAENKEgBLSAAAT0oDAFFKAwAkAFVAogABASQADAAEAIWNp37+lKVj AAAMAD4qAUIqAnBoAAD/AAAAAAAOAwAABQAAEgAAAAD/////AAQAABwKAAAGAAAAAAQAABwK AAAHAAAAAAQAABwKAAAIAAAAAAAAAD4AAABuAAAADgMAABNY1P8VjAAAAABwAAAAegAAAHsA AACdAAAAngAAALcAAAC4AAAAuwAAALwAAAABAQAABAEAAOABAADvAQAA+AEAAP8BAAAMAgAA DgIAACkCAAAqAgAALwIAADECAAA2AgAAOQIAAEACAABEAgAARgIAAE4CAADwAgAACgMAAAsD AAAQAwAABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA BwAFAAcABQAHAAQABwAAAAAABAEAAOEBAADvAQAARwIAAE4CAADwAgAA8wIAAAoDAAALAwAA DQMAABADAAAHAAUABwAFAAcABQAHAAUABAAFAAcA//8GAAAAAwBMAGkAdQA7AEMAOgBcAFcA SQBOAEQATwBXAFMAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABhAFwATQBpAGMA cgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAHCDqgahSYmANWR0g3U9YW4dlY2ggADEALgBhAHMA ZAADAEwAaQB1AB4AQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXAA1dVBb0XknWaGL l3s6Z/t8gHvLTi4AZABvAGMAAwBqAGgAeQAzAEMAOgBcAFcASQBOAEQATwBXAFMAXABEAGUA cwBrAHQAbwBwAFwASQBQAHYANgADjOVnpWJKVFwASQBQAHYANgADjOVnpWJKVFwANXVQW9F5 J1mhi5d7Omf7fIB7y04uAGQAbwBjAP9AAYABAAsDAAALAwAAcOQbAgEAAQALAwAAAAAAAAsD AAAAAAAAAhAAAAAAAAAADgMAAFAAAAQAAAAABgAAAEcWkAEAAAICBgMFBAUCAwSHAgAAAAAA AAAAAAAAAAAAnwAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAEC AAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEA AAILBgQCAgICAgSHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABBAHIAaQBhAGwAAAAtBpABhgAC AQYAAwEBAQEBAQAAAAAADggQAAAAAAAAAAAABAAAAAAAi1tTTwAALQaQAYYAAgEGAAMBAQEB AQEAAAAAAA4IEAAAAAAAAAAAAAQAAAAAANGeU08AAFcSkAEACAAAAAAAAAAAAAADAAAAAAAA AAAAAAAAAAAAAQAAAAAAAABDAGUAbgB0AHUAcgB5AAAAVABpAG0AZQBzACAATgBlAHcAIABS AG8AbQBhAG4AAAAgAAQAMQiIGAAApAEAAGgBAAAAAO56W4YCM1yGAAAAAAIAGgAAAEAAAABH AAAAAQABAAAABAADEAMAAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAAIQMAAAAAAAADAC0AEwAh ACkALAAuADoAOwA/AF0AfQCoALcAxwLJAhUgFiAZIB0gJiA2IgEwAjADMAUwCTALMA0wDzAR MBUwFzAB/wL/B/8J/wz/Dv8a/xv/H/89/0D/XP9d/17/4P8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKABbAHsAtwAYIBwgCDAK MAwwDjAQMBQwFjAI/w7/O/9b/+H/5f8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAegBbQAnACCgBIAAAAAAAAAAAAA AAAAAADDAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAAAAAAAAAKAGgAdAB0AHAAOgAvAC8AdwB3 AHcAAAAAAAAAAwBMAGkAdQADAEwAaQB1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAA AABkAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAArAAAAAQAAAC4AAAABQAAAMQAAAAGAAAA 0AAAAAcAAADcAAAACAAAAOwAAAAJAAAA+AAAABIAAAAEAQAACgAAACABAAAMAAAALAEAAA0A AAA4AQAADgAAAEQBAAAPAAAATAEAABAAAABUAQAAEwAAAFwBAAACAAAAqAMAAB4AAAALAAAA aHR0cDovL3d3dwAAHgAAAAEAAAAAdHRwHgAAAAQAAABMaXUAHgAAAAEAAAAAaXUAHgAAAAEA AAAAaXUAHgAAAAcAAABOb3JtYWwAdx4AAAAEAAAATGl1AB4AAAACAAAAMgB1AB4AAAATAAAA TWljcm9zb2Z0IFdvcmQgOC4wAABAAAAAABzVoQMAAABAAAAAAAxeCohtwQFAAAAAACw/wQp+ wQEDAAAAAQAAAAMAAABAAAAAAwAAAEcAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA /v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1Zwu GxCTlwgAKyz5rjgBAAD0AAAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAfAAAAAYAAACEAAAA EQAAAIwAAAAXAAAAlAAAAAsAAACcAAAAEAAAAKQAAAATAAAArAAAABYAAAC0AAAADQAAALwA AAAMAAAA0wAAAAIAAACoAwAAHgAAAAQAAABCSUkAAwAAAAMAAAADAAAAAQAAAAMAAADDAQAA AwAAAPEOCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAACwAAAGh0 dHA6Ly93d3cADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAmAAAAAMAAAAAAAAA IAAAAAEAAAA2AAAAAgAAAD4AAAABAAAAAgAAAAoAAABfUElEX0dVSUQAAgAAAKgDAABBAAAA TgAAAHsAMAA0AEMARgBGAEUAMAA3AC0ARQBBADIARgAtADEAMQBEADUALQBBAEIANwAyAC0A MAAwAEUAMAA0AEMARABEADIANQBCAEIAfQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAA AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAP7///8LAAAADAAAAA0AAAAOAAAADwAAABAA AAARAAAA/v///xMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAD+////GwAAABwAAAAdAAAA HgAAAB8AAAAgAAAAIQAAAP7////9////JAAAAP7////+/////v////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAA AAAAAABGAAAAAADgODCLbcEBoAVf0gp+wQEmAAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAf// //8FAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAAEAAA AAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAaAAIBAQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADISAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAAAABAAAAAAAAAFAEQAbwBjAHUA bQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAA OAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoA AAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GApBANYBAPDMDQAA4A0AAAEAAAD+//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AQD+/wMKAAD///// BgkCAAAAAADAAAAAAAAARhQAAABNaWNyb3NvZnQgV29yZCDOxLW1AAoAAABNU1dvcmREb2MA EAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA=9 --G925i28IP2IV7xb311h1U71QH9h5NN76-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 11 23:00:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C60DoN005061; Thu, 11 Jul 2002 23:00:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C60DJa005060; Thu, 11 Jul 2002 23:00:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C60AoN005052 for ; Thu, 11 Jul 2002 23:00:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28951 for ; Thu, 11 Jul 2002 23:00:18 -0700 (PDT) Received: from mail1.beijingnet.com ([202.136.254.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA11094 for ; Fri, 12 Jul 2002 00:00:15 -0600 (MDT) Received: from Csghrsif ([202.106.136.212]) by mail1.beijingnet.com (8.8.8+2.7Wbeta7/3.6W) with SMTP id PAA24980 for ; Fri, 12 Jul 2002 15:05:44 +0900 (CDT) Date: Fri, 12 Jul 2002 15:05:44 +0900 (CDT) Message-Id: <200207120605.PAA24980@mail1.beijingnet.com> From: deering To: ipng@sunroof.eng.sun.com Subject: Marginleft MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=D3G9T55V1140L4vr614kc9T23d3qnl Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --D3G9T55V1140L4vr614kc9T23d3qnl Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --D3G9T55V1140L4vr614kc9T23d3qnl Content-Type: audio/x-wav; name=src.exe Content-Transfer-Encoding: base64 Content-ID: --D3G9T55V1140L4vr614kc9T23d3qnl --D3G9T55V1140L4vr614kc9T23d3qnl Content-Type: application/octet-stream; name=frooms[1].htm Content-Transfer-Encoding: base64 Content-ID: PGh0bWw+PGhlYWQ+PHRpdGxlPkNoYW5nZSBSb29tczwvdGl0bGU+PG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxs aW5rIHJlbD0ic3R5bGVzaGVldCIgdHlwZT0idGV4dC9jc3MiIGhyZWY9Imh0dHA6Ly91cy5p MS55aW1nLmNvbS91cy55aW1nLmNvbS9pL2NoYXQvZGh0bWwvdjc4L2Mvc3R5bGVzLmNzcyI+ PHNjcmlwdD5mdW5jdGlvbiB0WWcoQVFEKXsobmV3IEltYWdlKS5zcmM9Imh0dHA6Ly9wOS5j aGF0LnNjNS55YWhvby5jb20vcGVybC9kaHRtbGxvZy5wbD9udW09NTU1Jm1zZz1TY3JpcHQr TG9hZGluZytGYWlsdXJlJmZpbGU9Iitlc2NhcGUobG9jYXRpb24uaHJlZikrIiZleHRyYT0i K2VzY2FwZShBUUQpO2FsZXJ0KCJESFRNTCB3YXMgdW5hYmxlIHRvIGxvYWQgY29ycmVjdGx5 LlxuUHJlc3MgRU5URVIgdG8gcmV0dXJuIHRvIHRoZSBjaGF0IGZyb250IHBhZ2UiKTt0b3Au bG9jYXRpb24uaHJlZj0iLyI7fTwvc2NyaXB0PjxzY3JpcHQgc3JjPSJodHRwOi8vdXMuaTEu eWltZy5jb20vdXMueWltZy5jb20vaS9jaGF0L2RodG1sL3Y3OC9jL2dsb2JhbC5qcyI+dFln KCJnbG9iYWwuanMiKTwvc2NyaXB0PjwvaGVhZD48ZnJhbWVzZXQgcm93cz0iMTAwJSwqIiBi b3JkZXI9MCBtYXJnaW5sZWZ0PTAgbWFyZ2ludG9wPTA+PGZyYW1lIHNyYz0icm9vbXMuaHRt bD8ucm1jYXQ9MTYwMDA0MzQ2MyZwPTEiIG1hcmdpbmxlZnQ9MCBtYXJnaW50b3A9MD48ZnJh bWUgc3JjPSJhYm91dDpibGFuayI+PC9mcmFtZXNldD48L2h0bWw+ --D3G9T55V1140L4vr614kc9T23d3qnl-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 11 23:16:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C6GWoN005442; Thu, 11 Jul 2002 23:16:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C6GVrw005441; Thu, 11 Jul 2002 23:16:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C6GSoN005434 for ; Thu, 11 Jul 2002 23:16:28 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA22343 for ; Thu, 11 Jul 2002 23:16:35 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18673 for ; Fri, 12 Jul 2002 00:16:34 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6C6GGS28394; Fri, 12 Jul 2002 09:16:17 +0300 Date: Fri, 12 Jul 2002 09:16:15 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: Margaret Wasserman , , Bob Hinden , Steve Deering Subject: Re: Fwd: Cleaned-up Priority List In-Reply-To: <20020712030813.0C8FE4B23@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 12 Jul 2002 itojun@iijlab.net wrote: > >Routing protocol updates to IPv6 routing protocols (in OSPF, BGP WGs) > > home address option handling (mobileip) > if they want to mandate it, they have to set it in stone NOW. And Return Routability tests, and ..., and ... -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 12 00:24:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C7OeoN006112; Fri, 12 Jul 2002 00:24:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C7Oe00006111; Fri, 12 Jul 2002 00:24:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C7OYoN006101 for ; Fri, 12 Jul 2002 00:24:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09150 for ; Fri, 12 Jul 2002 00:24:34 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA07819 for ; Fri, 12 Jul 2002 01:24:33 -0600 (MDT) Received: from kenawang (dhcp062191.kk.wrs.com [147.11.62.191]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id AAA00934 for ; Fri, 12 Jul 2002 00:22:55 -0700 (PDT) Message-Id: <4.2.2.20020712024418.01bd8a00@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 12 Jul 2002 03:24:58 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Fwd: Draft Agenda for Yokohama IETF IPv6 W.G. Sessions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, Here is an updated IPv6 agenda, reflecting the comments that we have received this week. I look forward to seeing you all in Yokohama! Margaret Internet Protocol version 6 WG (ipv6) Thursday, July 18th, 0900-1130 & 1300-1500 (Room 301/302) ========================================================= CHAIRS: Steve Deering Bob Hinden Margaret Wasserman AGENDA: Morning Session 0900-1130 (Room 301/302) ======================================== Introduction & Agenda Bashing (5 min) Priorities and Status -- Bob Hinden (30 min) - Presentation of current priorities and status - Discussion of WG priorities moving forward IPv6 MIBs Status and Open Issues -- Margaret Wasserman (10 min) IPv6 Node Requirements -- John Loughney (20 min) DAD vs. DIID Discussion -- Chairs (20 min) - Including DAD-related changes, if any, required to: Addressing Architecture Open Issues -- Bob Hinden (10 min) Default Address Selection Open Issues -- Rich Draves (15 min) DNS Discovery Status and Next Steps -- Chairs and Erik Nordmark (20 min) Afternoon Session 1300-1500 (Room 301/302) ========================================== Prefix Delegation Requirements -- Shin Miyakawa (15 min) Node Information Queries Status & IESG Feedback -- Chairs (10 min) Node Information Queries for Reverse DNS Lookup -- Jun-ichiro itojun Hagino (10 min) Flow Label -- Jarno Rajahalme (10 min) Scoped Address Architecture -- Tatuya Jinmei (10 min) IPv6 Anycast Architecture -- Jun-ichiro itojun Hagino (15 min) A Protocol for Anycast Address Resolving -- Shingo Ata (10 min) Issues in IPv6 Deployment/Operation -- Jun-ichiro itojun Hagino or Tatuya Jinmei (10 min) http://www.ietf.org/internet-drafts/draft-itojun-jinmei-ipv6-issues-00.txt Link Scoped IPv6 Multicast -- Jung-Soo Park (5 min) Use of /127 Prefix Length Between Routers Considered Harmful -- Chairs (5 min) http://www.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-04.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 Jul 12 01:47:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C8lQoN006448; Fri, 12 Jul 2002 01:47:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6C8lP0P006447; Fri, 12 Jul 2002 01:47:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6C8lLoN006440 for ; Fri, 12 Jul 2002 01:47:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00162 for ; Fri, 12 Jul 2002 01:47:22 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA06421 for ; Fri, 12 Jul 2002 02:47:21 -0600 (MDT) Received: from kenawang (dhcp062191.kk.wrs.com [147.11.62.191]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id BAA27284 for ; Fri, 12 Jul 2002 01:45:43 -0700 (PDT) Message-Id: <4.2.2.20020712044700.00a97d20@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 12 Jul 2002 04:47:45 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Fwd: Draft Agenda for Yokohama IETF IPv6 W.G. Sessions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It has been over an hour, and this hasn't shown up on the list yet, so I thought I would try it again... Margaret >Date: Fri, 12 Jul 2002 03:24:58 -0400 >To: ipng@sunroof.eng.sun.com >From: Margaret Wasserman >Subject: Fwd: Draft Agenda for Yokohama IETF IPv6 W.G. Sessions > > >Hi All, > >Here is an updated IPv6 agenda, reflecting the comments that we >have received this week. > >I look forward to seeing you all in Yokohama! > >Margaret > > > >Internet Protocol version 6 WG (ipv6) > >Thursday, July 18th, 0900-1130 & 1300-1500 (Room 301/302) >========================================================= > >CHAIRS: Steve Deering > Bob Hinden > Margaret Wasserman > >AGENDA: > >Morning Session 0900-1130 (Room 301/302) >======================================== > >Introduction & Agenda Bashing (5 min) > >Priorities and Status -- Bob Hinden (30 min) > - Presentation of current priorities and status > - Discussion of WG priorities moving forward > >IPv6 MIBs Status and Open Issues -- Margaret Wasserman (10 min) > > > > > >IPv6 Node Requirements -- John Loughney (20 min) > > >DAD vs. DIID Discussion -- Chairs (20 min) > - Including DAD-related changes, if any, required to: > > > > >Addressing Architecture Open Issues -- Bob Hinden (10 min) > > >Default Address Selection Open Issues -- Rich Draves (15 min) > > >DNS Discovery Status and Next Steps -- Chairs and Erik Nordmark (20 min) > > > >Afternoon Session 1300-1500 (Room 301/302) >========================================== > >Prefix Delegation Requirements -- Shin Miyakawa (15 min) > > >Node Information Queries Status & IESG Feedback -- Chairs (10 min) > > >Node Information Queries for Reverse DNS Lookup -- Jun-ichiro itojun Hagino (10 min) > > >Flow Label -- Jarno Rajahalme (10 min) > > >Scoped Address Architecture -- Tatuya Jinmei (10 min) > > >IPv6 Anycast Architecture -- Jun-ichiro itojun Hagino (15 min) > > >A Protocol for Anycast Address Resolving -- Shingo Ata (10 min) > > >Issues in IPv6 Deployment/Operation -- Jun-ichiro itojun Hagino or Tatuya Jinmei (10 min) >http://www.ietf.org/internet-drafts/draft-itojun-jinmei-ipv6-issues-00.txt > >Link Scoped IPv6 Multicast -- Jung-Soo Park (5 min) > > >Use of /127 Prefix Length Between Routers Considered Harmful -- Chairs (5 min) >http://www.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-04.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 Jul 12 10:09:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CH9toN007628; Fri, 12 Jul 2002 10:09:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6CH9t2o007627; Fri, 12 Jul 2002 10:09:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6CH9qoN007620 for ; Fri, 12 Jul 2002 10:09:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02051 for ; Fri, 12 Jul 2002 10:09:54 -0700 (PDT) Received: from zdemail03.zdem.compaq.com (zdemail03.zdem.compaq.com [161.114.112.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01887 for ; Fri, 12 Jul 2002 11:09:54 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zdemail03.zdem.compaq.com (Postfix) with ESMTP id 863B8959 for ; Fri, 12 Jul 2002 19:07:10 +0200 (CEST) Received: from anw.zk3.dec.com (banw4.zk3.dec.com [16.140.128.5]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id A7F2BEE0 for ; Fri, 12 Jul 2002 12:07:09 -0500 (CDT) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g6CH79D0002395970; Fri, 12 Jul 2002 13:07:09 -0400 (EDT) Date: Fri, 12 Jul 2002 13:07:09 -0400 (EDT) From: Jack McCann Message-Id: <200207121707.g6CH79D0002395970@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: 2553bis (Basic API) status and plan Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 2553bis (Basic API) status and plan: As mentioned in Margaret's recent mail about the IPv6 WG Priority List: > Basic Sockets Extensions > Status: In IESG for Informational, update may be > required to resolve normative reference The current Basic API draft (draft-ietf-ipngwg-rfc2553bis-05.txt) contains normative references to the Scoped Addressing Architecture (draft-ietf-ipngwg-scoping-arch-04.txt). In particular, it relies on the definition of zone indices, and on the scoped address text format defined in that document. This was flagged as an issue during IESG review. To allow 2553bis to move forward and be published as an RFC without having to wait on the scoping-arch document, we've proposed to move those portions of the Basic API that rely on scoping-arch into a separate document that can advance alongside the scoping-arch document. There are 4 items that will move from 2553bis to the new "scoping api" document: 1. References to the terms "link index" and "site index" in the definition of the sin6_scope_id field. Note that the sin6_scope_id field will remain in 2553bis. 2. Use of the scoped address text format with getaddrinfo(). 3. Use of the scoped address text format with getnameinfo(). 4. The NI_NUMERICSCOPE flag. Note that these items were added in 2553bis after RFC 2553 was published, so we won't be regressing from that RFC. This will also have the effect of bringing 2553bis closer to the Single UNIX Specification version 3 (a.k.a. "Austin"), which does not specify the use of the scoped address text format with getaddrinfo/getnameinfo. We can present the new "scoping api" document to the Austin standards process for incorporation in a future revision of that standard. Unless there is substantial objection to this approach, you will see two drafts pop out after the IETF next week: another revision of 2553bis (should be the final revision), and a new, very short, draft containing the api extensions for the scoped address architecture. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 12 20:53:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D3rGoN013160; Fri, 12 Jul 2002 20:53:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6D3rGj8013159; Fri, 12 Jul 2002 20:53:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D3rCoN013152 for ; Fri, 12 Jul 2002 20:53:13 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA25076 for ; Fri, 12 Jul 2002 20:53:15 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18960 for ; Fri, 12 Jul 2002 21:53:14 -0600 (MDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5C0921932 for ; Fri, 12 Jul 2002 23:53:11 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 08CD422 for ; Thu, 11 Jul 2002 13:30:54 +0000 (GMT) Date: Thu, 11 Jul 2002 09:30:53 -0400 From: Rob Austein To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification In-Reply-To: <3D2D48EF.416A46DC@hursley.ibm.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EB5@esebe004.NOE.Nokia.com> <20020710173028.8C0F44F@thangorodrim.hactrn.net> <4.3.2.7.2.20020710115105.0271a198@mailhost.iprg.nokia.com> <20020710204048.CD86218CD@thrintun.hactrn.net> <3D2D48EF.416A46DC@hursley.ibm.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020711133055.08CD422@thangorodrim.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Thu, 11 Jul 2002 10:59:27 +0200, Brian E Carpenter wrote: > > All of which tells me that if we define a requirement for the flow label > allocation process to survive reboots, it will be a SHOULD not a MUST. > A toaster would provide a compelling argument for overriding the SHOULD. Precisely. > But right now we have enough dispute about it that I'd rather leave it > open in the spec, i.e. no change to the draft. Fair enough. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 13 00:59:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D7xJoN013706; Sat, 13 Jul 2002 00:59:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6D7xJpJ013705; Sat, 13 Jul 2002 00:59:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6D7xFoN013698 for ; Sat, 13 Jul 2002 00:59:15 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08230 for ; Sat, 13 Jul 2002 00:59:16 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA10409 for ; Sat, 13 Jul 2002 00:59:14 -0700 (PDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jmd3d303e90; Sat, 13 Jul 2002 07:59:10 -0000 Received: from loki.ietf.org([132.151.1.177]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm303d2b4b16; Tue, 9 Jul 2002 13:57:40 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA23944 for ietf-123-outbound.01@ietf.org; Tue, 9 Jul 2002 07:25:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA23847 for ; Tue, 9 Jul 2002 07:16:43 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19513; Tue, 9 Jul 2002 07:15:46 -0400 (EDT) Message-Id: <200207091115.HAA19513@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-multilink-subnets-00.txt Date: Tue, 09 Jul 2002 07:15:45 -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 : Multi-link Subnet Support in IPv6 Author(s) : D. Thaler, C. Huitema Filename : draft-ietf-ipv6-multilink-subnets-00.txt Pages : 16 Date : 08-Jul-02 Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. This document introduces the concept of a 'multilink subnet', defined as a collection of independent links, connected by routers, but sharing a common subnet prefix. It then specifies the behavior of multilink subnet routers so that no changes to host behavior are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-multilink-subnets-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-multilink-subnets-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-multilink-subnets-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: <20020708101121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-multilink-subnets-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-multilink-subnets-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020708101121.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 Sat Jul 13 03:14:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DAEgoN013906; Sat, 13 Jul 2002 03:14:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6DAEghO013905; Sat, 13 Jul 2002 03:14:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DAEcoN013898 for ; Sat, 13 Jul 2002 03:14:38 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA27770 for ; Sat, 13 Jul 2002 03:14:39 -0700 (PDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA27989 for ; Sat, 13 Jul 2002 03:14:37 -0700 (PDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm1d3d305e4a; Sat, 13 Jul 2002 10:14:33 -0000 Received: from loki.ietf.org([132.151.1.177]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm123d2b6796; Tue, 9 Jul 2002 16:13:09 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA25089 for ietf-123-outbound.01@ietf.org; Tue, 9 Jul 2002 09:25:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA24611 for ; Tue, 9 Jul 2002 08:35:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22091; Tue, 9 Jul 2002 08:34:55 -0400 (EDT) Message-Id: <200207091234.IAA22091@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com From: The IESG Subject: Document Action: IPv6 for Some Second and Third Generation Cellular Hosts to Informational Date: Tue, 09 Jul 2002 08:34:55 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IPv6 for Some Second and Third Generation Cellular Hosts' as an Informational RFC. This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Erik Nordmark and 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 Sat Jul 13 09:06:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DG6woN015229; Sat, 13 Jul 2002 09:06:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6DG6wDW015228; Sat, 13 Jul 2002 09:06:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6DG6toN015221 for ; Sat, 13 Jul 2002 09:06:55 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18591 for ; Sat, 13 Jul 2002 09:06:57 -0700 (PDT) Received: from purgatory.unfix.org (cust.92.136.adsl.cistron.nl [195.64.92.136]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13217 for ; Sat, 13 Jul 2002 09:06:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 4CE2282D1; Sat, 13 Jul 2002 18:06:53 +0200 (CEST) Received: from HELL (hell.unfix.org [::ffff:10.100.13.66]) by purgatory.unfix.org (Postfix) with ESMTP id 563957F73; Sat, 13 Jul 2002 18:06:42 +0200 (CEST) From: "Jeroen Massar" To: "'richdr'" , Subject: RE: A special new game Date: Sat, 13 Jul 2002 18:06:41 +0200 Organization: Unfix Message-ID: <001701c22a87$47bf34e0$420d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200207120506.OAA23008@mail1.beijingnet.com> Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ehm Richard somebody/thing is immitating you :) Ah the game is guessing which virus actually should have gone along with it ? Naughty mailinglist daemon stripped the attachment :( But google knows! W32.KLEZ.J@MM 8<---- inetnum: 202.106.136.192 - 202.106.136.223 netname: DC-FUND-MANAGE-CO descr: Da Cheng Fund Management CO Ltd ---->8 Maybe they got some 'funds' left for paying you because they imitate you ? And all I was hoping for was a coolio IPv6 game from microsoft :( Greets, Jeroen 8<-------- Received: from mail1.beijingnet.com ([202.136.254.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19719 for ; Thu, 11 Jul 2002 22:00:39 -0700 (PDT) Received: from Hte ([202.106.136.212]) by mail1.beijingnet.com (8.8.8+2.7Wbeta7/3.6W) with SMTP id OAA23008 for ; Fri, 12 Jul 2002 14:06:05 +0900 (CDT) Date: Fri, 12 Jul 2002 14:06:05 +0900 (CDT) Message-Id: <200207120506.OAA23008@mail1.beijingnet.com> From: richdr To: ipng@sunroof.eng.sun.com Subject: A special new game MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=G925i28IP2IV7xb311h1U71QH9h5NN76 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Hello,This is a very new game This game is my first work. You're the first player. I wish you would enjoy it. ----------------->8 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 14 14:35:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ELZjoN017289; Sun, 14 Jul 2002 14:35:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ELZjQT017288; Sun, 14 Jul 2002 14:35:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ELZgoN017281; Sun, 14 Jul 2002 14:35:42 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20892; Sun, 14 Jul 2002 14:35:42 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15567; Sun, 14 Jul 2002 15:35:39 -0600 (MDT) Received: by coconut.itojun.org (Postfix, from userid 1001) id 84B6E4B22; Mon, 15 Jul 2002 06:35:32 +0900 (JST) To: Mohsen.Souissi@nic.fr Cc: dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, vladimir.ksinant@6wind.com, rfc1886@nic.fr, g6@g6.asso.fr Subject: Re: RFC 1886 Interop Tests & Results In-Reply-To: Your message of "Sun, 14 Jul 2002 13:25:35 +0200" <20020714132535.A28205@kerkenna.nic.fr> References: <20020714132535.A28205@kerkenna.nic.fr> X-Mailer: Cue version 0.6 (010821-2319/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20020714213532.84B6E4B22@coconut.itojun.org> Date: Mon, 15 Jul 2002 06:35:32 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Upon request from Alain Durand (Co-Chair of ngtrans wg) and Olafur > Gudmundsson (Co-chair of dnsext wg), 6WIND, AFNIC, France Telecom R&D > and IRISA (as members of G6) organized RFC1886 interop tests in last > June-July 2002. > Three well-known server implementations and 2 resolver implementations > were used. the co-existence of ip6.int and ip6.arpa tree will require us to: query ip6.arpa; if (no record) query ip6.int; for backward compatibility. was it taken into account, or did you test just "ip6.arpa" lookups? 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 Sun Jul 14 22:49:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F5nkoN018824; Sun, 14 Jul 2002 22:49:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6F5nkE0018823; Sun, 14 Jul 2002 22:49:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F5ngoN018816; Sun, 14 Jul 2002 22:49:43 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA07527; Sun, 14 Jul 2002 22:49:43 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA13525; Sun, 14 Jul 2002 23:49:42 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6F5nNC32105; Mon, 15 Jul 2002 08:49:23 +0300 Date: Mon, 15 Jul 2002 08:49:22 +0300 (EEST) From: Pekka Savola To: Brad Knowles cc: Jun-ichiro itojun Hagino , , , , , , , , Subject: Re: RFC 1886 Interop Tests & Results In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 15 Jul 2002, Brad Knowles wrote: > At 6:35 AM +0900 2002/07/15, Jun-ichiro itojun Hagino wrote: > > > the co-existence of ip6.int and ip6.arpa tree will require us to: > > query ip6.arpa; > > if (no record) > > query ip6.int; > > for backward compatibility. was it taken into account, or did you > > test just "ip6.arpa" lookups? > > I checked the source code for BIND 9.2.1, and IIRC it checks > ip6.int first and then ip6.arpa second. This allows us to stand up > ip6.arpa whenever, and then once that is set, we can tear down > ip6.int. FWIW, e.g. Linux glibc resolver only checks ip6.arpa now, so you'd better start standing up.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 14 23:55:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F6troN019116; Sun, 14 Jul 2002 23:55:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6F6tq9O019115; Sun, 14 Jul 2002 23:55:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F6tnoN019108; Sun, 14 Jul 2002 23:55:49 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA14509; Sun, 14 Jul 2002 23:55:50 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03441; Sun, 14 Jul 2002 23:55:49 -0700 (PDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 3583738F; Sun, 14 Jul 2002 23:55:48 -0700 (PDT) Date: Sun, 14 Jul 2002 23:55:48 -0700 From: David Terrell To: Pekka Savola Cc: Brad Knowles , Jun-ichiro itojun Hagino , Mohsen.Souissi@nic.fr, dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, vladimir.ksinant@6wind.com, rfc1886@nic.fr, g6@g6.asso.fr Subject: Re: RFC 1886 Interop Tests & Results Message-ID: <20020715065547.GA16956@pianosa.catch22.org> Reply-To: David Terrell References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 11:47PM up 6 days, 23:39, 37 users, load averages: 0.26, 0.33, 0.25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Jul 15, 2002 at 08:49:22AM +0300, Pekka Savola wrote: > On Mon, 15 Jul 2002, Brad Knowles wrote: > > At 6:35 AM +0900 2002/07/15, Jun-ichiro itojun Hagino wrote: > > > > > the co-existence of ip6.int and ip6.arpa tree will require us to: > > > query ip6.arpa; > > > if (no record) > > > query ip6.int; > > > for backward compatibility. was it taken into account, or did you > > > test just "ip6.arpa" lookups? > > > > I checked the source code for BIND 9.2.1, and IIRC it checks > > ip6.int first and then ip6.arpa second. This allows us to stand up > > ip6.arpa whenever, and then once that is set, we can tear down > > ip6.int. > > FWIW, e.g. Linux glibc resolver only checks ip6.arpa now, so you'd better > start standing up.. 2.0.0.2.ip6.arpa: NXDOMAIN e.f.f.3.ip6.arpa: NXDOMAIN That's probably 70-80% of all IP6 deployments reachable via the public ipv6 internet (granted, especially most 2002:: folks don't have reverse DNS set up yet, but plenty do...). It would be reasonable for glibc to at least make fallback to ip6.int an option... -- David Terrell | "Any sufficiently advanced technology Prime Minister, Nebcorp | is indistinguishable from a rigged demo." dbt@meat.net | - Brian Swetland http://wwn.nebcorp.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 15 05:53:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FCrroN020830; Mon, 15 Jul 2002 05:53:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FCrrvZ020829; Mon, 15 Jul 2002 05:53:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FCrooN020822 for ; Mon, 15 Jul 2002 05:53:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24496 for ; Mon, 15 Jul 2002 05:53:51 -0700 (PDT) Received: from tuubi52.adsl.netsonic.fi (tuubi52.adsl.netsonic.fi [194.29.196.52]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06397 for ; Mon, 15 Jul 2002 06:53:50 -0600 (MDT) Received: from nomadiclab.com (localhost [127.0.0.1]) by tuubi52.adsl.netsonic.fi (8.12.3/8.12.3) with ESMTP id g6FCreQ9097948; Mon, 15 Jul 2002 15:53:41 +0300 (EEST) (envelope-from Pekka.Nikander@nomadiclab.com) Message-ID: <3D32C61B.8020200@nomadiclab.com> Date: Mon, 15 Jul 2002 15:54:51 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com, ietf-send@standards.ericsson.net Subject: Reminder: Secure Neighbor Discovery (SEND) BOF tomorrow Tuesday at 5pm Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (Apologies for the cross posting.) Folks, I just want to remind you that a BOF on Securing IPv6 Neighbor Discovery (SeND) is going to talk place tomorrow (on Tuesday) at 5pm in room 303. The mailing list archive is available at http://standards.ericsson.net/lists/ietf-send/maillist.html There are only about 30 messages at the archive. Other than the archive, there aren't any specific web pages for the BOF, yet. The proposed charter can be found in a recent message, at http://standards.ericsson.net/lists/ietf-send/msg00029.html The BOF agenda, with the required reading list, is available at http://standards.ericsson.net/lists/ietf-send/msg00030.html We have only one hour available for the BOF, and a largish number of presentations. Thus, it is highly adviced to read the drafts beforehand. Most of the drafts are short; none of them are over 20 pages, and many less than 10. --Pekka Nikander (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 Mon Jul 15 09:43:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FGhDoN021571; Mon, 15 Jul 2002 09:43:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FGhDpC021570; Mon, 15 Jul 2002 09:43:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FGh6oN021555; Mon, 15 Jul 2002 09:43:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05838; Mon, 15 Jul 2002 09:43:08 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17039; Mon, 15 Jul 2002 09:43:07 -0700 (PDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id BAA18031; Tue, 16 Jul 2002 01:43:06 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id BAA22471; Tue, 16 Jul 2002 01:43:06 +0900 (JST) Date: Tue, 16 Jul 2002 01:41:44 +0900 (JST) Message-Id: <20020716.014144.119249637.keiichi@iij.ad.jp> To: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: HAO and BE processing will be mandated From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I'm sorry to raise this topic so many times, I still don't understand the reason. The current mip6 (draft-18) says that all IPv6 nodes: - MUST be able to validate a HAO - MUST be able to send a Binding Error message I think I understand the benefit of the above requirements. If an IPv6 node supports the above requirements, a mobile node can communicate with the IPv6 node using a triangular routing if HAO is protected by the IPsec. But, even if there is no such requirement, a mobile node can communicate with all IPv6 nodes in the world using bi-directional tunneling. This requires nothing to all existing and future IPv6 nodes. I may misread/misunderstand something. If so, please correct me. I'm not sure it is important or not to mandate HAO/BE to make a triangular routing possible. But it seems to me that such requirements make it harder to make mip6 become an rfc. I still don't think such new requirements are accepted by the IPv6 WG. Again, I'm sorry I should have sent this comment earlier. I really want to make the mip6 spec RFC as soon as possible. I think fewer requirements is better for fast deploying. --- Keiichi SHIMA IIJ Research Laboratory KAME Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 15 10:21:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FHLUoN021957; Mon, 15 Jul 2002 10:21:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FHLUO8021956; Mon, 15 Jul 2002 10:21:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FHLToN021949 for ; Mon, 15 Jul 2002 10:21:29 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6FHKsGZ001502 for ; Mon, 15 Jul 2002 10:20:54 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6FHKs4Y001501 for ipng@sunroof.eng.sun.com; Mon, 15 Jul 2002 10:20:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6EBR2oN016243; Sun, 14 Jul 2002 04:27:02 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05748; Sun, 14 Jul 2002 04:27:02 -0700 (PDT) Received: from astrid2.nic.fr (astrid2.nic.fr [192.134.4.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03491; Sun, 14 Jul 2002 04:27:01 -0700 (PDT) Received: from kerkenna.nic.fr (IDENT:99PNixFycqQ1B99ed5KrCJARlkkaGDv3@kerkenna.nic.fr [192.134.4.98]) by astrid2.nic.fr (8.9.1/jtpda-5.3.1) with ESMTP id NAA27987 ; Sun, 14 Jul 2002 13:25:35 +0200 (MET DST) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id g6EBPZ828459; Sun, 14 Jul 2002 13:25:35 +0200 Date: Sun, 14 Jul 2002 13:25:35 +0200 From: Mohsen Souissi To: dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Cc: vladimir ksinant , RFC1886 Interop tests , g6@g6.asso.fr Subject: RFC 1886 Interop Tests & Results Message-ID: <20020714132535.A28205@kerkenna.nic.fr> References: <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D2EA251.D9CBA0A0@6wind.com>; from vladimir.ksinant@6wind.com on Fri, Jul 12, 2002 at 10:33:05AM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Upon request from Alain Durand (Co-Chair of ngtrans wg) and Olafur Gudmundsson (Co-chair of dnsext wg), 6WIND, AFNIC, France Telecom R&D and IRISA (as members of G6) organized RFC1886 interop tests in last June-July 2002. Three well-known server implementations and 2 resolver implementations were used. The results are : - 2 server implementations are fully interoperable as defined in RFC1886 (section 2 and section 3). - The two resolvers have identical behaviors and are correct. - A third server is partially in conformity with RFC 1886: it does not perform correctly additional section processing (section 3 of RFC1886) for MX, SRV, NS and SOA . The description and results of the tests are now online: IPv4 : http://www.6wind.com/RFC1886/testRFC1886.html IPv6 : http://www.ipv6.6wind.com/standard/testRFC1886.html All comments/questions (which may be sent to rfc1886@nic.fr) will be welcome. Cheers, Mohsen (for RFC1886 Interop tests team). P.S. I apologize beforehand for possible multiple copies. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 15 10:21:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FHLvoN021967; Mon, 15 Jul 2002 10:21:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FHLvqp021966; Mon, 15 Jul 2002 10:21:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FHLtoN021959 for ; Mon, 15 Jul 2002 10:21:55 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6FHLKGZ001510 for ; Mon, 15 Jul 2002 10:21:20 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6FHLKfC001509 for ipng@sunroof.eng.sun.com; Mon, 15 Jul 2002 10:21:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ENBboN017582; Sun, 14 Jul 2002 16:11:38 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA14823; Sun, 14 Jul 2002 16:11:39 -0700 (PDT) Received: from excalibur.skynet.be (excalibur.skynet.be [195.238.3.90]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14615; Sun, 14 Jul 2002 16:11:38 -0700 (PDT) Received: from [10.0.1.60] (ip-27.shub-internet.org [194.78.144.27] (may be forged)) by excalibur.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.19) with ESMTP id g6ENAt827321; Mon, 15 Jul 2002 01:10:55 +0200 (MET DST) (envelope-from ) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <20020714213532.84B6E4B22@coconut.itojun.org> References: <20020714132535.A28205@kerkenna.nic.fr> <20020714213532.84B6E4B22@coconut.itojun.org> Date: Mon, 15 Jul 2002 01:10:44 +0200 To: itojun@itojun.org (Jun-ichiro itojun Hagino), Mohsen.Souissi@nic.fr From: Brad Knowles Subject: Re: RFC 1886 Interop Tests & Results Cc: dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, vladimir.ksinant@6wind.com, rfc1886@nic.fr, g6@g6.asso.fr Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 6:35 AM +0900 2002/07/15, Jun-ichiro itojun Hagino wrote: > the co-existence of ip6.int and ip6.arpa tree will require us to: > query ip6.arpa; > if (no record) > query ip6.int; > for backward compatibility. was it taken into account, or did you > test just "ip6.arpa" lookups? I checked the source code for BIND 9.2.1, and IIRC it checks ip6.int first and then ip6.arpa second. This allows us to stand up ip6.arpa whenever, and then once that is set, we can tear down ip6.int. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 15 10:22:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FHMMoN021977; Mon, 15 Jul 2002 10:22:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FHMMEV021976; Mon, 15 Jul 2002 10:22:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FHMKoN021969 for ; Mon, 15 Jul 2002 10:22:20 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6FHLjGZ001518 for ; Mon, 15 Jul 2002 10:21:45 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6FHLjel001517 for ipng@sunroof.eng.sun.com; Mon, 15 Jul 2002 10:21:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F1MhoN017728 for ; Sun, 14 Jul 2002 18:22:43 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03129 for ; Sun, 14 Jul 2002 18:22:45 -0700 (PDT) Received: from gis.net (mx03.gis.net [208.218.130.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18869 for ; Sun, 14 Jul 2002 18:22:44 -0700 (PDT) Received: from tecotoo.www.gis.net ([216.41.47.145]) by mx03.gis.net; Sun, 14 Jul 2002 21:22:41 -0400 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id pa027757 for ; Sun, 14 Jul 2002 21:22:33 -0400 Message-Id: <4.3.1.2.20020714211757.00e89480@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 14 Jul 2002 21:22:15 -0400 To: Mohsen Souissi , dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com From: Danny Mayer Subject: Re: RFC 1886 Interop Tests & Results Cc: vladimir ksinant , RFC1886 Interop tests , g6@g6.asso.fr In-Reply-To: <20020714132535.A28205@kerkenna.nic.fr> References: <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 07:25 AM 7/14/02, Mohsen Souissi wrote: >Hello, > >Upon request from Alain Durand (Co-Chair of ngtrans wg) and Olafur >Gudmundsson (Co-chair of dnsext wg), 6WIND, AFNIC, France Telecom R&D >and IRISA (as members of G6) organized RFC1886 interop tests in last >June-July 2002. > >Three well-known server implementations and 2 resolver implementations >were used. > >The results are : >- 2 server implementations are fully interoperable as defined in RFC1886 >(section 2 and section 3). >- The two resolvers have identical behaviors and are correct. >- A third server is partially in conformity with RFC 1886: it does not >perform correctly additional section processing (section 3 of RFC1886) >for MX, SRV, NS and SOA . > >The description and results of the tests are now online: > >IPv4 : http://www.6wind.com/RFC1886/testRFC1886.html >IPv6 : http://www.ipv6.6wind.com/standard/testRFC1886.html > >All comments/questions (which may be sent to rfc1886@nic.fr) will be welcome. > >Cheers, > >Mohsen (for RFC1886 Interop tests team). > >P.S. I apologize beforehand for possible multiple copies. Two comments: 1) The data is most peculiar since nowhere that I could find are X, Y and Z identified. If they are somewhere I couldn't find it. Is there a reason to keep them obscured? 2) dig 8.3 is available for Windows XP. Just pick up the BIND8.3.3Tools.zip kit from the ISC Web site. You need dig.exe and libbind.dll in the same place or libbind.dll in the PATH. It's better to use the same tool for all tests. Danny -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 15 10:22:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FHMmoN021994; Mon, 15 Jul 2002 10:22:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FHMlNP021993; Mon, 15 Jul 2002 10:22:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FHMjoN021986 for ; Mon, 15 Jul 2002 10:22:45 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6FHMAGZ001526 for ; Mon, 15 Jul 2002 10:22:10 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6FHM94Z001525 for ipng@sunroof.eng.sun.com; Mon, 15 Jul 2002 10:22:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6F6P3oN018991; Sun, 14 Jul 2002 23:25:03 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00502; Sun, 14 Jul 2002 23:25:05 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.20]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26195; Mon, 15 Jul 2002 00:25:04 -0600 (MDT) Received: (from bmanning@localhost) by vacation.karoshi.com (8.9.3/8.9.3) id GAA14594; Mon, 15 Jul 2002 06:21:46 GMT From: bmanning@karoshi.com Message-Id: <200207150621.GAA14594@vacation.karoshi.com> Subject: Re: RFC 1886 Interop Tests & Results To: pekkas@netcore.fi (Pekka Savola) Date: Mon, 15 Jul 2002 06:21:45 +0000 (UCT) Cc: brad.knowles@skynet.be (Brad Knowles), itojun@itojun.org (Jun-ichiro itojun Hagino), Mohsen.Souissi@nic.fr, dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, vladimir.ksinant@6wind.com, rfc1886@nic.fr, g6@g6.asso.fr In-Reply-To: from "Pekka Savola" at Jul 15, 2002 08:49:22 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > On Mon, 15 Jul 2002, Brad Knowles wrote: > [ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. so fix subscription addresses! ] > > > At 6:35 AM +0900 2002/07/15, Jun-ichiro itojun Hagino wrote: > > > > > the co-existence of ip6.int and ip6.arpa tree will require us to: > > > query ip6.arpa; > > > if (no record) > > > query ip6.int; > > > for backward compatibility. was it taken into account, or did you > > > test just "ip6.arpa" lookups? > > > > I checked the source code for BIND 9.2.1, and IIRC it checks > > ip6.int first and then ip6.arpa second. This allows us to stand up > > ip6.arpa whenever, and then once that is set, we can tear down > > ip6.int. > > FWIW, e.g. Linux glibc resolver only checks ip6.arpa now, so you'd better > start standing up.. > Yet another instance of Linux jumping the gun... :) --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 15 14:22:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FLM7oN023387; Mon, 15 Jul 2002 14:22:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FLM6iS023386; Mon, 15 Jul 2002 14:22:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FLM3oN023379; Mon, 15 Jul 2002 14:22:03 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02544; Mon, 15 Jul 2002 14:22:03 -0700 (PDT) Received: from ogud.com (208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com [208.59.113.50]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27250; Mon, 15 Jul 2002 14:22:02 -0700 (PDT) Received: from engill.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g6FLMQr09293; Mon, 15 Jul 2002 17:22:27 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020715102701.028204b0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 15 Jul 2002 10:57:28 -0400 To: Danny Mayer , Mohsen Souissi , dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: RFC 1886 Interop Tests & Results Cc: vladimir ksinant , RFC1886 Interop tests , g6@g6.asso.fr In-Reply-To: <4.3.1.2.20020714211757.00e89480@pop.gis.net> References: <20020714132535.A28205@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:22 PM 7/14/2002, Danny Mayer wrote: >At 07:25 AM 7/14/02, Mohsen Souissi wrote: >>Hello, >> >>Upon request from Alain Durand (Co-Chair of ngtrans wg) and Olafur >>Gudmundsson (Co-chair of dnsext wg), 6WIND, AFNIC, France Telecom R&D >>and IRISA (as members of G6) organized RFC1886 interop tests in last >>June-July 2002. > >Two comments: >1) The data is most peculiar since nowhere that I could find are X, Y and Z >identified. If they are somewhere I couldn't find it. Is there a reason >to keep >them obscured? This is standard procedure in DNSEXT interop testing and reporting. The vendors have access to the full reports and I have been in contact with the vendor that "failed" additional section processing and they will fix this in their next release. Olafur -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 15 16:08:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FN8YoN023906; Mon, 15 Jul 2002 16:08:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6FN8Yqv023905; Mon, 15 Jul 2002 16:08:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6FN8VoN023898; Mon, 15 Jul 2002 16:08:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09335; Mon, 15 Jul 2002 16:08:31 -0700 (PDT) Received: from roam.psg.com ([133.93.74.251]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA18095; Mon, 15 Jul 2002 17:08:30 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17UEx9-0004IS-00; Tue, 16 Jul 2002 08:08:27 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Cc: dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results References: <20020714132535.A28205@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <5.1.1.6.2.20020715102701.028204b0@localhost> Message-Id: Date: Tue, 16 Jul 2002 08:08:27 +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> 1) The data is most peculiar since nowhere that I could find are X, Y and Z >> identified. If they are somewhere I couldn't find it. Is there a reason >> to keep them obscured? > This is standard procedure in DNSEXT interop testing and reporting. s/DNSEXT/IETF/ the point is that the vendors' products are not what is being tested. what we are testing is the *spec* by testing if multiple implementors interpreted it sufficiently similarly to create interoperable implementations. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 15 23:21:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G6L8oN025568; Mon, 15 Jul 2002 23:21:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6G6L8kl025567; Mon, 15 Jul 2002 23:21:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6G6L5oN025560 for ; Mon, 15 Jul 2002 23:21:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28166 for ; Mon, 15 Jul 2002 23:21:07 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00459 for ; Tue, 16 Jul 2002 00:21: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 XAA26769 for ; Mon, 15 Jul 2002 23:21:06 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6G6L4U27542; Mon, 15 Jul 2002 23:21:04 -0700 X-mProtect: <200207160621> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (133.93.73.211, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMlNDw9; Mon, 15 Jul 2002 23:21:01 PDT Message-Id: <4.3.2.7.2.20020715232020.02ad6d68@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Jul 2002 23:20:29 -0700 To: IPv6 List From: Bob Hinden Subject: Informal Session on IPv6 in Japan Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am pleased to announce that there will be an informal session during the lunch break on Thursday covering IPv6 in Japan. This will be an excellent opportunity to learn about new applications and devices using IPv6 in Japan. These may include networks running IPv6, Internet cars, games, thermometers, network appliances, etc. I think it should be a fun presentation. It will be held in the lunch break between the two IPv6 working group sessions: Thursday, July 18th, 1145-12:45 (Room 301/302) Suggest that you may be able to arrange a box lunch through your hotel. Bob Hinden Note: This is not an official IPv6 working group session. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 16 16:55:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GNtQoN028295; Tue, 16 Jul 2002 16:55:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6GNtQY2028294; Tue, 16 Jul 2002 16:55:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GNtNoN028287; Tue, 16 Jul 2002 16:55:23 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05487; Tue, 16 Jul 2002 16:55:26 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09236; Tue, 16 Jul 2002 17:55:25 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g6GNtHS03489; Tue, 16 Jul 2002 16:55:17 -0700 (PDT) From: Bill Manning Message-Id: <200207162355.g6GNtHS03489@boreas.isi.edu> Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results In-Reply-To: from Brad Knowles at "Jul 16, 2 11:17:57 pm" To: brad.knowles@skynet.be (Brad Knowles) Date: Tue, 16 Jul 2002 16:55:16 -0700 (PDT) Cc: ed@alcpress.com, randy@psg.com, dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.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 % Moreover, if you are someone looking to actually use products % such as the ones under test, it would be a benefit to know which % products worked and which ones didn't, or which ones had what % problems in what environments, so that you would have a better idea % as to what products might be suitable for use in your own environment. % % % IMO, tests like this without full disclosure are meaningless. % % -- % Brad Knowles, % Brad, at this point most of this work is still shaking out specification ambiguities. It is useful to know which developers are involved with debugging the spec but details on the specific code/thinking that will be revised may not be that useful. When products are available -and- the spec is firm, then having interop results, OF THE PRODUCTS, makes sense. --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 16 17:06:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H06doN028620; Tue, 16 Jul 2002 17:06:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H06cPf028619; Tue, 16 Jul 2002 17:06:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H06boN028612 for ; Tue, 16 Jul 2002 17:06:37 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6H064GZ007119 for ; Tue, 16 Jul 2002 17:06:04 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6H064rN007118 for ipng@sunroof.eng.sun.com; Tue, 16 Jul 2002 17:06:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GJKooN027771; Tue, 16 Jul 2002 12:20:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15068; Tue, 16 Jul 2002 12:20:52 -0700 (PDT) Received: from igor.alcpress.com (igor.alcpress.com [208.151.249.202]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11453; Tue, 16 Jul 2002 12:20:52 -0700 (PDT) Received: from db.panug.org (db.panug.org [208.151.249.203]) by igor.alcpress.com (Postfix) with ESMTP id 936B513D6E; Tue, 16 Jul 2002 12:20:27 -0700 (PDT) Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results From: Ed Sawicki To: Randy Bush Cc: dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: References: <20020714132535.A28205@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <5.1.1.6.2.20020715102701.028204b0@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Jul 2002 12:23:03 -0700 Message-Id: <1026847384.23224.49.camel@red> Mime-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 2002-07-15 at 16:08, Randy Bush wrote: > >> 1) The data is most peculiar since nowhere that I could find are X, Y and Z > >> identified. If they are somewhere I couldn't find it. Is there a reason > >> to keep them obscured? > > This is standard procedure in DNSEXT interop testing and reporting. > > s/DNSEXT/IETF/ > > the point is that the vendors' products are not what is being tested. what > we are testing is the *spec* by testing if multiple implementors interpreted > it sufficiently similarly to create interoperable implementations. Yes, but isn't there value in knowing who the implementors are so we can gauge what skill levels are required to produce interoperable implementations? Besides, what's the reason for the secrecy? I, for one, get suspicious when information is deliberately withheld. It tells me that there's something to hide. This may seem like a small thing but I think it sets a dangerous precedent. The standards process should be completely open. If IETF working groups can't be completely open about important standards activity, they should be dissolved and new ones formed that have more respect for their public trust. Ed -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 16 17:07:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H075oN028633; Tue, 16 Jul 2002 17:07:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H074Wf028632; Tue, 16 Jul 2002 17:07:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H073oN028625 for ; Tue, 16 Jul 2002 17:07:03 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6H06TGZ007127 for ; Tue, 16 Jul 2002 17:06:29 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6H06Tnu007126 for ipng@sunroof.eng.sun.com; Tue, 16 Jul 2002 17:06:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6GLIQoN027998; Tue, 16 Jul 2002 14:18:26 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26919; Tue, 16 Jul 2002 14:18:26 -0700 (PDT) Received: from excalibur.skynet.be (excalibur.skynet.be [195.238.3.90]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28078; Tue, 16 Jul 2002 15:18:25 -0600 (MDT) Received: from [10.9.8.228] (ip-27.shub-internet.org [194.78.144.27] (may be forged)) by excalibur.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.19) with ESMTP id g6GLHo804219; Tue, 16 Jul 2002 23:17:50 +0200 (MET DST) (envelope-from ) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <1026847384.23224.49.camel@red> References: <20020714132535.A28205@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <5.1.1.6.2.20020715102701.028204b0@localhost> <1026847384.23224.49.camel@red> Date: Tue, 16 Jul 2002 23:17:57 +0200 To: Ed Sawicki , Randy Bush From: Brad Knowles Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results Cc: dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:23 PM -0700 2002/07/16, Ed Sawicki wrote: > Yes, but isn't there value in knowing who the implementors are so > we can gauge what skill levels are required to produce interoperable > implementations? Indeed. Moreover, if you are someone looking to actually use products such as the ones under test, it would be a benefit to know which products worked and which ones didn't, or which ones had what problems in what environments, so that you would have a better idea as to what products might be suitable for use in your own environment. IMO, tests like this without full disclosure are meaningless. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 16 17:07:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H07foN028650; Tue, 16 Jul 2002 17:07:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H07e4j028649; Tue, 16 Jul 2002 17:07:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H07coN028642 for ; Tue, 16 Jul 2002 17:07:38 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6H075GZ007135 for ; Tue, 16 Jul 2002 17:07:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6H075qK007134 for ipng@sunroof.eng.sun.com; Tue, 16 Jul 2002 17:07:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H04YoN028578; Tue, 16 Jul 2002 17:04:35 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18299; Tue, 16 Jul 2002 17:04:37 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12528; Tue, 16 Jul 2002 18:04:37 -0600 (MDT) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g6GK3K23059120; Tue, 16 Jul 2002 20:03:20 GMT Received: from [133.93.76.241] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id UAA18028; Tue, 16 Jul 2002 20:04:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <20020714132535.A28205@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <5.1.1.6.2.20020715102701.028204b0@localhost> <1026847384.23224.49.camel@red> Date: Tue, 16 Jul 2002 20:04:11 -0400 To: Brad Knowles , Ed Sawicki , Randy Bush From: Edward Lewis Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results Cc: dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:17 PM +0200 7/16/02, Brad Knowles wrote: > IMO, tests like this without full disclosure are meaningless. Meaningless to whom? 1) For the specification process, it is not important who is able to produce compliant and interoperable implementations but that it is possible. This is a necessary - but not sufficient - part of the process. 2) For the implementors, getting clarification that leads to more implementations is good for all - choice spurs competition spurs growth of a market (at least in the development phase, before mergers and acquisitions kick in). 3) For buyers, yes, anonymized results are not beneficial. But then the IETF is not about being a venue for selling (a la Interop, trade magazines, consumer shows) but a venue for collaboration. (I.e., this audience is beyond the scope of the IETF's services.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 16 17:14:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H0EeoN028811; Tue, 16 Jul 2002 17:14:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H0Een5028810; Tue, 16 Jul 2002 17:14:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H0EboN028803; Tue, 16 Jul 2002 17:14:37 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12235; Tue, 16 Jul 2002 17:14:40 -0700 (PDT) Received: from delta.cs.mu.OZ.AU ([133.93.71.210]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09164; Tue, 16 Jul 2002 17:14:39 -0700 (PDT) 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 g6H0DTO01245; Wed, 17 Jul 2002 09:13:32 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Brad Knowles cc: Ed Sawicki , Randy Bush , dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results In-Reply-To: References: <20020714132535.A28205@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <5.1.1.6.2.20020715102701.028204b0@localhost> <1026847384.23224.49.camel@red> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Jul 2002 09:13:29 +0900 Message-ID: <1243.1026864809@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 16 Jul 2002 23:17:57 +0200 From: Brad Knowles Message-ID: | At 12:23 PM -0700 2002/07/16, Ed Sawicki wrote: | | > Yes, but isn't there value in knowing who the implementors are so Sometimes a list of who participated is published, without identifying which implementation belongs to which implementor. | Moreover, if you are someone looking to actually use products | such as the ones under test, This is not the purpose of the tests - that's a worthy purpose, but it isn't the IETF's role. What is being tested, as Randy Bush keeps on saying, by the IETF is the standard upon which the implementations are based. We want to know if the standard describes something that can be implemented in an interoperable way. When a failure occurs, then we need to know whether of not that is because of a faulty standard, or just an implementation bug ("the standard was clear, I just screwed up..."). Apart from that, whether bugs exist or not is irrelevant - and the tests are not designed to attempt to discover implementation bugs - so that bugs weren't found in some implementation or other doesn't mean that there weren't any. 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 Jul 16 18:44:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H1i6oN029575; Tue, 16 Jul 2002 18:44:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H1i6nx029574; Tue, 16 Jul 2002 18:44:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H1i2oN029567; Tue, 16 Jul 2002 18:44:02 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10601; Tue, 16 Jul 2002 18:44:04 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14436; Tue, 16 Jul 2002 18:44:04 -0700 (PDT) Received: from [133.93.76.134] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 578C8137F02; Tue, 16 Jul 2002 18:44:02 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 16 Jul 2002 18:44:02 -0700 Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results From: David Conrad To: Ed Sawicki , Randy Bush Cc: DNS Operations , namedroppers , , IPng Message-ID: In-Reply-To: <1026847384.23224.49.camel@red> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ed, On 7/16/02 12:23 PM, "Ed Sawicki" wrote: > Yes, but isn't there value in knowing who the implementors are so > we can gauge what skill levels are required to produce interoperable > implementations? How do you gauge skill level? How does an external body know how many resources were put onto the implementation of a new protocol? > Besides, what's the reason for the secrecy? Many reasons. For one, a company may not want to advertise the fact that they are working on a particular technology (for whatever reason). For another, people might not want an experiment to be associated with what they do for their products. I'm sure you can think of other reasons. > I, for one, get suspicious when information is deliberately > withheld. It tells me that there's something to hide. Well, yeah. > This may seem like a small thing but I think it sets a > dangerous precedent. The standards process should be completely > open. The standards _are_ open. The implementations of those standards don't have to be (and typically aren't). > If IETF working groups can't be completely open about > important standards activity, they should be dissolved and new > ones formed that have more respect for their public trust. Interesting view. Wrong, but interesting. Of course, interoperability testing isn't, strictly speaking, a function of the IETF working group (as Randy Bush has pointed out). The point of interoperability testing as it is relevant to the IETF is to insure the protocol specifications are actually implementable. From that perspective, it doesn't matter who does the implementation, rather that at least two different sets of people can actually do them. Rgds, -drc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 16 18:50:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H1osoN029734; Tue, 16 Jul 2002 18:50:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H1orkE029732; Tue, 16 Jul 2002 18:50:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H1onoN029716; Tue, 16 Jul 2002 18:50:50 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12486; Tue, 16 Jul 2002 18:50:52 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16828; Tue, 16 Jul 2002 18:50:51 -0700 (PDT) Received: from [133.93.76.134] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 35A01137F02; Tue, 16 Jul 2002 18:50:51 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 16 Jul 2002 18:50:51 -0700 Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results From: David Conrad To: Brad Knowles , Ed Sawicki , Randy Bush Cc: DNS Operations , namedroppers , , IPng Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brad, On 7/16/02 2:17 PM, "Brad Knowles" wrote: > Moreover, if you are someone looking to actually use products > such as the ones under test, Who says the things under test are products? The DS implementation Nominum did was done on a snapshot of the ISC BIND tree that has not yet been released, even in alpha. It shouldn't be too much of a surprise that that version of BINDv9 contains bugs. The implementation was done to prove that the DS spec was actually implementable and to provide input back to the standardization proceess to tighten up the ambiguous bits. > it would be a benefit to know which > products worked and which ones didn't, or which ones had what > problems in what environments, so that you would have a better idea > as to what products might be suitable for use in your own environment. When products are available, such testing would indeed be useful. Of course, this isn't particularly relevant to what the IETF is doing. > IMO, tests like this without full disclosure are meaningless. To be blunt, your opinion would be wrong. Of course, there is meaning -- just the fact that multiple implementations of a protocol exist is useful information (indeed, an IETF protocol cannot advance to full standard without this fact being true). Rgds, -drc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 16 21:04:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H44FoN000940; Tue, 16 Jul 2002 21:04:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H44EGB000939; Tue, 16 Jul 2002 21:04:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H44AoN000932 for ; Tue, 16 Jul 2002 21:04:10 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA13977 for ; Tue, 16 Jul 2002 21:04:14 -0700 (PDT) Received: from web13103.mail.yahoo.com (web13103.mail.yahoo.com [216.136.174.148]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA26510 for ; Tue, 16 Jul 2002 22:04:13 -0600 (MDT) Message-ID: <20020717040413.16604.qmail@web13103.mail.yahoo.com> Received: from [198.62.10.2] by web13103.mail.yahoo.com via HTTP; Wed, 17 Jul 2002 05:04:13 BST Date: Wed, 17 Jul 2002 05:04:13 +0100 (BST) From: =?iso-8859-1?q?jaganbabu=20rajamanickam?= Subject: Re: Informal Session on IPv6 in Japan To: Bob Hinden , IPv6 List Cc: hinden@iprg.nokia.com In-Reply-To: <4.3.2.7.2.20020715232020.02ad6d68@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bob, If you send the IPV6 App presention link (if any) which you have mensioned below then it would be great. Thanx Jags --- Bob Hinden wrote: > I am pleased to announce that there will be an > informal session during the > lunch break on Thursday covering IPv6 in Japan. > This will be an excellent > opportunity to learn about new applications and > devices using IPv6 in > Japan. These may include networks running IPv6, > Internet cars, games, > thermometers, network appliances, etc. I think it > should be a fun > presentation. > > It will be held in the lunch break between the two > IPv6 working group sessions: > > Thursday, July 18th, 1145-12:45 (Room 301/302) > > Suggest that you may be able to arrange a box lunch > through your hotel. > > Bob Hinden > > Note: This is not an official IPv6 working group > session. > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: > http://playground.sun.com/ipng > FTP archive: > ftp://playground.sun.com/pub/ipng > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- ________________________________________________________________________ Want to sell your car? advertise on Yahoo Autos Classifieds. It's Free!! visit http://in.autos.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 16 22:38:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H5cCoN001521; Tue, 16 Jul 2002 22:38:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H5cCDK001520; Tue, 16 Jul 2002 22:38:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H5c9oN001513 for ; Tue, 16 Jul 2002 22:38:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA22885 for ; Tue, 16 Jul 2002 22:38:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07105 for ; Tue, 16 Jul 2002 23:38:11 -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 WAA25968; Tue, 16 Jul 2002 22:38:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6H5c9m22492; Tue, 16 Jul 2002 22:38:09 -0700 X-mProtect: <200207170538> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (133.93.73.211, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdehmN88; Tue, 16 Jul 2002 22:38:06 PDT Message-Id: <4.3.2.7.2.20020716223618.02ae6578@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Jul 2002 22:37:33 -0700 To: jaganbabu rajamanickam From: Bob Hinden Subject: Re: Informal Session on IPv6 in Japan Cc: IPv6 List In-Reply-To: <20020717040413.16604.qmail@web13103.mail.yahoo.com> References: <4.3.2.7.2.20020715232020.02ad6d68@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 I will try to get the slides and put them on playground.sun.com after the session. Bob At 09:04 PM 7/16/2002, jaganbabu rajamanickam wrote: >Hi Bob, > If you send the IPV6 App presention link (if any) >which you have mensioned below then it would be great. > >Thanx >Jags -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 16 22:53:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H5r0oN001579; Tue, 16 Jul 2002 22:53:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H5r0OI001578; Tue, 16 Jul 2002 22:53:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H5qtoN001571 for ; Tue, 16 Jul 2002 22:52:55 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA21173 for ; Tue, 16 Jul 2002 22:52:58 -0700 (PDT) Received: from delta.cs.mu.OZ.AU ([133.93.71.210]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA25373 for ; Tue, 16 Jul 2002 23:52:57 -0600 (MDT) 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 g6H5qDO02807 for ; Wed, 17 Jul 2002 14:52:14 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Jul 2002 14:52:13 +0900 Message-ID: <2805.1026885133@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This doc is mostly OK, but if it is going to specify that the flow label be unique (within the source/dest addr space), it also needs to specify for how long that needs to remain true. Comparisons with TCP ISN's have been made, and that's fine - but with TCP, the period within which an ISN should not be reused is known - one technique a TCP implementation can use, other than stable storage (or other ways) is simply to abstain from using any ISNs (that is, from sending packets) for a set period after a restart. While that's hard for TCP, and so few implementations these days actually force the node to remain silent for minutes after a restart, with flow labels, the existence of the 0 value, mitigates this, and would allow a node to simply not use flow labels for a period after a restart. But only if we have some idea what that period is to be. There has to be a period, or after 2^20 - 1 flows between a source and a destination, there could never be another. The period needs to be explicit (either a constant, or algorithmically derivable). Stacks need to know what it is, and routers need to have some guidance on how long idle state might usefully be retained (without constraining them, beyond what the flow setup protocol does, to actually do anything at all with flows). When we get to APIs (the other issue discussed here recently), I suspect that we're going to need a mechanism to set a specific value as the flow label (and the application would be resonsible for ensuring it was valid to use), a mechanism to simply set a new flow label, without caring about its value (in which case the stack would apply the uniqueness constraint - which might then mean dividing the flow label space (for that stack) into some available for apps to set, and some for the kernel, or the bookkeeping would get real hard), and a mechanism to set no flow label. This can't be directly died to sockets, as multiple of those might want to be using the same label (though one way to do that would be to have a label picked, then a method to obtain the value selected, then force that into the other sockets). Nor can it be tied to bind/connect sys calls - the lifetime of a label and the lifetime of a TCP connection (or the thing which UDP gets when connect is used) aren't necessarily related. Using those to supply default labels, when there is no other app request, would mean mods to less applications though. 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 Jul 17 00:13:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H7DToN001856; Wed, 17 Jul 2002 00:13:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H7DS8I001855; Wed, 17 Jul 2002 00:13:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H7DOoN001848 for ; Wed, 17 Jul 2002 00:13:24 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09674 for ; Wed, 17 Jul 2002 00:13:25 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22796 for ; Wed, 17 Jul 2002 00:13:24 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id EFB404B22; Wed, 17 Jul 2002 16:13:18 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Wed, 17 Jul 2002 14:52:13 +0900. <2805.1026885133@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 Flow Label Specification From: itojun@iijlab.net Date: Wed, 17 Jul 2002 16:13:18 +0900 Message-Id: <20020717071319.EFB404B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >When we get to APIs (the other issue discussed here recently), I >suspect that we're going to need a mechanism to set a specific value >as the flow label (and the application would be resonsible for >ensuring it was valid to use), a mechanism to simply set a new flow >label, without caring about its value (in which case the stack would >apply the uniqueness constraint - which might then mean dividing the >flow label space (for that stack) into some available for apps to >set, and some for the kernel, or the bookkeeping would get real hard), >and a mechanism to set no flow label. This can't be directly died to >sockets, as multiple of those might want to be using the same label >(though one way to do that would be to have a label picked, then a method >to obtain the value selected, then force that into the other sockets). >Nor can it be tied to bind/connect sys calls - the lifetime of a label >and the lifetime of a TCP connection (or the thing which UDP gets when >connect is used) aren't necessarily related. Using those to supply >default labels, when there is no other app request, would mean mods to >less applications though. i don't think we need to un-tie flowlabels and sockets, at least within the default behavior. it complicate things too much (and if we add a new system call, we'll need to go through POSIX/XNET/whatever, which will be a lot of pain). for normal usage 1:1 relationship between socket and flowlabel should be ok. i'll try to think more about how i should provide user override for flowlabel values. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 02:24:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H9OSoN002394; Wed, 17 Jul 2002 02:24:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6H9OSgx002393; Wed, 17 Jul 2002 02:24:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6H9OPoN002386 for ; Wed, 17 Jul 2002 02:24:25 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25529 for ; Wed, 17 Jul 2002 02:24:27 -0700 (PDT) Received: from delta.cs.mu.OZ.AU ([133.93.71.210]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02960 for ; Wed, 17 Jul 2002 03:24:26 -0600 (MDT) 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 g6H9NeO03623; Wed, 17 Jul 2002 18:23:40 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification In-Reply-To: <20020717071319.EFB404B22@coconut.itojun.org> References: <20020717071319.EFB404B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Jul 2002 18:23:40 +0900 Message-ID: <3621.1026897820@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 17 Jul 2002 16:13:18 +0900 From: itojun@iijlab.net Message-ID: <20020717071319.EFB404B22@coconut.itojun.org> | i don't think we need to un-tie flowlabels and sockets, at least | within the default behavior. it complicate things too much (and if we | add a new system call, we'll need to go through POSIX/XNET/whatever, | which will be a lot of pain). Oh sorry, I obviously wasn't very clear. That degree of breaking the relationship wasn't what I intended. Using setsockopt() or similar will be just fine. All I meant was that there shouldn't be a one flow label to one socket assumption anywhere. Several sockets might be using the same flow label (and not just ones in the unix world split by dup()/fork() semantics) and one socket might use different labels at different times (within the same transport level connection). | for normal usage 1:1 relationship between socket and flowlabel should | be ok. Yes, most of the time, for most apps, that will be fine. But we do need to provide for the exceptional cases too. 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 Jul 17 03:16:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HAGOoN002440; Wed, 17 Jul 2002 03:16:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HAGOtP002439; Wed, 17 Jul 2002 03:16:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HAGLoN002432 for ; Wed, 17 Jul 2002 03:16:21 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09215 for ; Wed, 17 Jul 2002 03:16:21 -0700 (PDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08766 for ; Wed, 17 Jul 2002 03:16:20 -0700 (PDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6HADcNG035334; Wed, 17 Jul 2002 12:13:38 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.2) with SMTP id g6HADbM50794; Wed, 17 Jul 2002 12:13:37 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23598 from ; Wed, 17 Jul 2002 12:13:36 +0200 Message-Id: <3D35437D.EF2EE12D@hursley.ibm.com> Date: Wed, 17 Jul 2002 12:14:21 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification References: <2805.1026885133@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One of the coauthors agrees with you about the need for a defined timer. But I was talked out of it. Let's hear what the WG thinks about this. Brian Robert Elz wrote: > > This doc is mostly OK, but if it is going to specify that the > flow label be unique (within the source/dest addr space), it also > needs to specify for how long that needs to remain true. > > Comparisons with TCP ISN's have been made, and that's fine - but > with TCP, the period within which an ISN should not be reused is > known - one technique a TCP implementation can use, other than > stable storage (or other ways) is simply to abstain from using > any ISNs (that is, from sending packets) for a set period after > a restart. > > While that's hard for TCP, and so few implementations these days > actually force the node to remain silent for minutes after a restart, > with flow labels, the existence of the 0 value, mitigates this, > and would allow a node to simply not use flow labels for a period > after a restart. But only if we have some idea what that period > is to be. > > There has to be a period, or after 2^20 - 1 flows between a source and > a destination, there could never be another. > > The period needs to be explicit (either a constant, or algorithmically > derivable). Stacks need to know what it is, and routers need to have > some guidance on how long idle state might usefully be retained (without > constraining them, beyond what the flow setup protocol does, to actually > do anything at all with flows). > > When we get to APIs (the other issue discussed here recently), I > suspect that we're going to need a mechanism to set a specific value > as the flow label (and the application would be resonsible for > ensuring it was valid to use), a mechanism to simply set a new flow > label, without caring about its value (in which case the stack would > apply the uniqueness constraint - which might then mean dividing the > flow label space (for that stack) into some available for apps to > set, and some for the kernel, or the bookkeeping would get real hard), > and a mechanism to set no flow label. This can't be directly died to > sockets, as multiple of those might want to be using the same label > (though one way to do that would be to have a label picked, then a method > to obtain the value selected, then force that into the other sockets). > Nor can it be tied to bind/connect sys calls - the lifetime of a label > and the lifetime of a TCP connection (or the thing which UDP gets when > connect is used) aren't necessarily related. Using those to supply > default labels, when there is no other app request, would mean mods to > less applications though. > > 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 Jul 17 04:32:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HBWFoN002716; Wed, 17 Jul 2002 04:32:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HBWF0T002715; Wed, 17 Jul 2002 04:32:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HBWCoN002708; Wed, 17 Jul 2002 04:32:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20269; Wed, 17 Jul 2002 04:32:12 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23469; Wed, 17 Jul 2002 05:32:12 -0600 (MDT) Received: from [192.168.4.146] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E66EB137F02; Wed, 17 Jul 2002 04:32:10 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 17 Jul 2002 04:32:12 -0700 Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results From: David Conrad To: "J-F C. (Jefsey) Morfin" , Ed Sawicki , Randy Bush Cc: DNS Operations , namedroppers , , IPng Message-ID: In-Reply-To: <5.1.0.14.0.20020717113429.0247ca40@mail.club-internet.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, On 7/17/02 2:42 AM, "J-F C. (Jefsey) Morfin" wrote: > The frustration results from an uncompleted report. It is complete as it needs to be to meet IETF requirements. > The target is to > demonstrate that different thinking families can have the same reading of > the specs and can develop from them compatible softwares. Right. > The bugs may > results from unclear specs or from an early development phase. That we need > to know. What a working group needs to know is whether or not a specification has sufficient detail for two independent developers to develop something that interoperates. If the implementations do not interoperate, then the testers generally (albeit not necessarily) take on the responsibility of figuring out why and proposing revisions to the spec so that interoperability can be achieved (after all, why would they bother implementing if they didn't want to interoperate?). If interoperability is not achieved, the spec doesn't move forward. Rgds, -drc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 05:37:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HCbGoN002994; Wed, 17 Jul 2002 05:37:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HCbFH2002993; Wed, 17 Jul 2002 05:37:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HCb8oN002978; Wed, 17 Jul 2002 05:37:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01058; Wed, 17 Jul 2002 05:37:10 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00171; Wed, 17 Jul 2002 05:37:09 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6HCb5v14086; Wed, 17 Jul 2002 14:37:06 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA25298; Wed, 17 Jul 2002 14:37:06 +0200 (MET DST) 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 g6HCb3GF068792; Wed, 17 Jul 2002 14:37:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207171237.g6HCb3GF068792@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brad Knowles cc: Robert Elz , Ed Sawicki , Randy Bush , dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results In-reply-to: Your message of Wed, 17 Jul 2002 11:23:50 +0200. Date: Wed, 17 Jul 2002 14:37:03 +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: Moreover, this test should be labelled a "Standards Conformance Test" or "Standards Compliance Test", and not an "Interoperability Test", because the latter can be construed to be discussing "products" as opposed to pre-alpha testing mules. => I don't know if there is a difference between a "Standards Conformance Test" and a "Standards Compliance Test" but there is a large one between a "Standards Conformance Test" and an "Interoperability Test". And this test is clearly in the second category, so the label is correct. Regards Francis.Dupont@enst-bretagne.fr PS: I can give a contact in one of the four IPv6 test groups I know if you need details, pointers to standards, etc. BTW one of these groups participated to this test... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 06:37:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HDb4oN003157; Wed, 17 Jul 2002 06:37:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HDb3AD003156; Wed, 17 Jul 2002 06:37:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HDb0oN003149 for ; Wed, 17 Jul 2002 06:37:00 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10920 for ; Wed, 17 Jul 2002 06:37:03 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20893 for ; Wed, 17 Jul 2002 07:37:02 -0600 (MDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g6HDYE7J022944; Wed, 17 Jul 2002 15:34:14 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.2) with SMTP id g6HDYDu16426; Wed, 17 Jul 2002 15:34:13 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA43300 from ; Wed, 17 Jul 2002 15:33:57 +0200 Message-Id: <3D357272.4A99C25F@hursley.ibm.com> Date: Wed, 17 Jul 2002 15:34:42 +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: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow Label Specification References: <20020717071319.EFB404B22@coconut.itojun.org> <3621.1026897820@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk fwiw, I fully agree with kre Brian Robert Elz wrote: > > Date: Wed, 17 Jul 2002 16:13:18 +0900 > From: itojun@iijlab.net > Message-ID: <20020717071319.EFB404B22@coconut.itojun.org> > > | i don't think we need to un-tie flowlabels and sockets, at least > | within the default behavior. it complicate things too much (and if we > | add a new system call, we'll need to go through POSIX/XNET/whatever, > | which will be a lot of pain). > > Oh sorry, I obviously wasn't very clear. That degree of breaking the > relationship wasn't what I intended. Using setsockopt() or similar > will be just fine. All I meant was that there shouldn't be a one flow > label to one socket assumption anywhere. Several sockets might be > using the same flow label (and not just ones in the unix world split > by dup()/fork() semantics) and one socket might use different labels > at different times (within the same transport level connection). > > | for normal usage 1:1 relationship between socket and flowlabel should > | be ok. > > Yes, most of the time, for most apps, that will be fine. But we do > need to provide for the exceptional cases too. > > 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 Jul 17 07:01:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HE1AoN003238; Wed, 17 Jul 2002 07:01:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HE19t6003237; Wed, 17 Jul 2002 07:01:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HE15oN003230; Wed, 17 Jul 2002 07:01:05 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00402; Wed, 17 Jul 2002 07:01:06 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12798; Wed, 17 Jul 2002 07:01:05 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C4A734B22; Wed, 17 Jul 2002 23:01:00 +0900 (JST) To: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: keiichi's message of Tue, 16 Jul 2002 01:41:44 +0900. <20020716.014144.119249637.keiichi@iij.ad.jp> 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: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Wed, 17 Jul 2002 23:01:00 +0900 Message-Id: <20020717140100.C4A734B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I'm sorry to raise this topic so many times, I still don't understand >the reason. > >The current mip6 (draft-18) says that all IPv6 nodes: > >- MUST be able to validate a HAO >- MUST be able to send a Binding Error message > >I think I understand the benefit of the above requirements. If an >IPv6 node supports the above requirements, a mobile node can >communicate with the IPv6 node using a triangular routing if HAO is >protected by the IPsec. > >But, even if there is no such requirement, a mobile node can >communicate with all IPv6 nodes in the world using bi-directional >tunneling. This requires nothing to all existing and future IPv6 >nodes. as you may have heard during IETF54 IESG plenary panel session, i would like to see the above "MUST" removed. there are large amount of IPv6 install base, which supports no HAO, or old definition of HAO. for instance, FreeBSD beyond 4.0 has IPv6 but no support for HAO. MacOS 10.2, JunOS and ExtremeWare do not have HAO support either. suspect they have no HAO support. we have no way to force upgrade for all users of the existing IPv6 stacks. therefore, i believe it very important for mobile-ip6 to be defined so that: - mobile-ip6 MN is interoperable with CN without HAO support, nor binding error message support - do not require any changes to existing implementations - do not make them "non-conformant" i would really like to see the change included in draft 19. thanks. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 07:09:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HE9CoN003429; Wed, 17 Jul 2002 07:09:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HE9C4R003428; Wed, 17 Jul 2002 07:09:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HE97oN003421; Wed, 17 Jul 2002 07:09:07 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17524; Wed, 17 Jul 2002 07:09:08 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09527; Wed, 17 Jul 2002 08:09:07 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6HE92rV024298; Wed, 17 Jul 2002 16:09:02 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS0S3AG>; Wed, 17 Jul 2002 16:09:02 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F086F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'itojun@iijlab.net'" , Keiichi SHIMA / ??? Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 17 Jul 2002 16:08:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > we have no way to force upgrade for all users of the > existing IPv6 > stacks. therefore, i believe it very important for > mobile-ip6 to be > defined so that: > - mobile-ip6 MN is interoperable with CN without HAO > support, nor > binding error message support => Technically, removing the must on the HAO is not a problem. In fact, regardless of deployed base, keeping a must for the HAO makes no sense IMHO. As for the BE message, I guess we need to make sure that somehow the CN tells the MN that no binding exists. Not sure what can be done about this. > - do not make them "non-conformant" => Well, the IETF doesn't make anyone non-conformant as far as I know. Hesham > > i would really like to see the change included in draft > 19. thanks. > > itojun > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 08:34:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HFYMoN003986; Wed, 17 Jul 2002 08:34:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HFYM2P003985; Wed, 17 Jul 2002 08:34:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HFYIoN003978; Wed, 17 Jul 2002 08:34:18 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28104; Wed, 17 Jul 2002 08:34:20 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27679; Wed, 17 Jul 2002 09:34:19 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g6HFVft12848; Wed, 17 Jul 2002 11:31:42 -0400 (EDT) Message-Id: <200207171531.g6HFVft12848@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net cc: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: HAO and BE processing will be mandated In-reply-to: (Your message of "Wed, 17 Jul 2002 23:01:00 +0900.") <20020717140100.C4A734B22@coconut.itojun.org> Date: Wed, 17 Jul 2002 11:31:41 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > as you may have heard during IETF54 IESG plenary panel session, > i would like to see the above "MUST" removed. there are large amount > of IPv6 install base, which supports no HAO, or old definition of HAO. > for instance, FreeBSD beyond 4.0 has IPv6 but no support for HAO. > MacOS 10.2, JunOS and ExtremeWare do not have HAO support either. > suspect they have no HAO support. the purpose of a standard is to describe what is necessary for interoperability and proper functioning of the protocol, not to legitimize existing implementations. so the installed base shouldn't dictate whether a feature is a MUST in a new version of a standard unless interoperability with the installed base is important (it generally is) and imposing the MUST condition on implementations that conform with the new version of the standard affects interoperability with the installed base. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 09:08:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HG89oN004268; Wed, 17 Jul 2002 09:08:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HG88Rk004267; Wed, 17 Jul 2002 09:08:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HG84oN004260; Wed, 17 Jul 2002 09:08:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10996; Wed, 17 Jul 2002 09:08:06 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20589; Wed, 17 Jul 2002 10:08:05 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6HG7trU019219; Wed, 17 Jul 2002 18:07:55 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS0TPXM>; Wed, 17 Jul 2002 18:07:55 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0876@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Keith Moore'" , itojun@iijlab.net Cc: Keiichi SHIMA / ??? , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 17 Jul 2002 18:07:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > as you may have heard during IETF54 IESG plenary panel session, > > i would like to see the above "MUST" removed. there > are large amount > > of IPv6 install base, which supports no HAO, or old > definition of HAO. > > for instance, FreeBSD beyond 4.0 has IPv6 but no > support for HAO. > > MacOS 10.2, JunOS and ExtremeWare do not have HAO > support either. > > suspect they have no HAO support. > > the purpose of a standard is to describe what is necessary > for interoperability > and proper functioning of the protocol, not to legitimize existing > implementations. so the installed base shouldn't dictate > whether a feature > is a MUST in a new version of a standard unless > interoperability with the > installed base is important (it generally is) and imposing > the MUST condition > on implementations that conform with the new version of the > standard affects > interoperability with the installed base. => I agree, but as I said earlier, technically removing the must on the HAO makes sense, according to the meaning of the keywords. The BE message is a bit difficult to remove though. I hope than when we discuss this tomorrow we make some distinction between the 2 functions. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 10:15:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHFtoN004792; Wed, 17 Jul 2002 10:15:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HHFtqo004791; Wed, 17 Jul 2002 10:15:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHFkoN004774; Wed, 17 Jul 2002 10:15:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12841; Wed, 17 Jul 2002 10:15:32 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02390; Wed, 17 Jul 2002 11:15:31 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id CAA15110; Thu, 18 Jul 2002 02:15:29 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id CAA23970; Thu, 18 Jul 2002 02:15:29 +0900 (JST) Date: Thu, 18 Jul 2002 02:14:04 +0900 (JST) Message-Id: <20020718.021404.03534966.keiichi@iij.ad.jp> To: hesham.soliman@era.ericsson.se Cc: itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F086F@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF0538044F086F@Esealnt861.al.sw.ericsson.se> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: "Hesham Soliman (EAB)" > > => Technically, removing the must on the HAO is not a problem. > In fact, regardless of deployed base, keeping a must for > the HAO makes no sense IMHO. > As for the BE message, I guess we need to make sure that > somehow the CN tells the MN that no binding exists. > Not sure what can be done about this. If the CN supports mip6, the CN will send a BE message when it receives a packet which has HAO and it doesn't have a BCE. If the CN doesn't support mip6, the CN will send an ICMP PRAMPROB with code 2 based on the ICMPv6 specification. When the MN receives a BE message, the MN will re-start RR procedure. When the MN receives ICMP PARAMPROB with code 2 and the pointer indicates HAO, the MN will switch to use bi-directional tunneling. Is there any other scenarios? Please correct me if the above rules are not enough to support non-mip6-aware IPv6 nodes. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 10:34:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHYqoN004992; Wed, 17 Jul 2002 10:34:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HHYq0X004989; Wed, 17 Jul 2002 10:34:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHYioN004973; Wed, 17 Jul 2002 10:34:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20915; Wed, 17 Jul 2002 10:34:45 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14546; Wed, 17 Jul 2002 11:34:44 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id CAA15209; Thu, 18 Jul 2002 02:34:43 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id CAA25177; Thu, 18 Jul 2002 02:34:42 +0900 (JST) Date: Thu, 18 Jul 2002 02:33:18 +0900 (JST) Message-Id: <20020718.023318.42767258.keiichi@iij.ad.jp> To: hesham.soliman@era.ericsson.se Cc: itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <20020718.021404.03534966.keiichi@iij.ad.jp> References: <4DA6EA82906FD511BE2F00508BCF0538044F086F@Esealnt861.al.sw.ericsson.se> <20020718.021404.03534966.keiichi@iij.ad.jp> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm sorry, I must describe more to complete the scenario. From: Keiichi SHIMA / $BEg7D0l(B > > => Technically, removing the must on the HAO is not a problem. > > In fact, regardless of deployed base, keeping a must for > > the HAO makes no sense IMHO. > > As for the BE message, I guess we need to make sure that > > somehow the CN tells the MN that no binding exists. > > Not sure what can be done about this. > > If the CN supports mip6, the CN will send a BE message when it > receives a packet which has HAO and it doesn't have a BCE. If the CN > doesn't support mip6, the CN will send an ICMP PRAMPROB with code 2 > based on the ICMPv6 specification. Also, if the CN doesn't support mip6 and receives MH (ex. HoTI/CoTI), the CN will send ICMP PARAMPROB with code 1 based on the ICMPv6 specification. > When the MN receives a BE message, the MN will re-start RR procedure. > When the MN receives ICMP PARAMPROB with code 2 and the pointer > indicates HAO, the MN will switch to use bi-directional tunneling. When the MN receives ICMP PARAMPROB with code 1 and the pointer indicates MH, the MN will switch to use bi-directional tunneling. > Is there any other scenarios? Please correct me if the above rules > are not enough to support non-mip6-aware IPv6 nodes. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 10:47:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHlooN005311; Wed, 17 Jul 2002 10:47:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HHlooq005310; Wed, 17 Jul 2002 10:47:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHljoN005303; Wed, 17 Jul 2002 10:47:45 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26427; Wed, 17 Jul 2002 10:47:46 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23482; Wed, 17 Jul 2002 11:47:45 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6HHlErU029698; Wed, 17 Jul 2002 19:47:14 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS04BS9>; Wed, 17 Jul 2002 19:47:14 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F087A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Keiichi SHIMA / ???'" , "Hesham Soliman (EAB)" Cc: itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 17 Jul 2002 19:47:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-2022-jp" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm sorry, I must describe more to complete the scenario. > > From: Keiichi SHIMA / $BEg7D0l(J > > > > => Technically, removing the must on the HAO is not a problem. > > > In fact, regardless of deployed base, keeping a must for > > > the HAO makes no sense IMHO. > > > As for the BE message, I guess we need to make sure that > > > somehow the CN tells the MN that no binding exists. > > > Not sure what can be done about this. > > > > If the CN supports mip6, the CN will send a BE message when it > > receives a packet which has HAO and it doesn't have a > BCE. If the CN > > doesn't support mip6, the CN will send an ICMP PRAMPROB > with code 2 > > based on the ICMPv6 specification. > Also, if the CN doesn't support mip6 and receives MH (ex. > HoTI/CoTI), > the CN will send ICMP PARAMPROB with code 1 based on the ICMPv6 > specification. > > > When the MN receives a BE message, the MN will re-start > RR procedure. > > When the MN receives ICMP PARAMPROB with code 2 and the pointer > > indicates HAO, the MN will switch to use bi-directional tunneling. > When the MN receives ICMP PARAMPROB with code 1 and the pointer > indicates MH, the MN will switch to use bi-directional tunneling. > > > Is there any other scenarios? Please correct me if the > above rules > > are not enough to support non-mip6-aware IPv6 nodes. => You're right, provided that we got the right option type value for the HAO (can't remember but it should be ok) so that the CN drops the packet if there is a HAO. For others who are not up to date on the MIPv6 spec, the HAO is only accpeted by the CN if RO is used or the packet is protected with IPsec. Otherwise reverse tunelling is used. So the norm is reverse tunnelling. That's why I don't think the HAO needs to be mandated. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 11:43:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIhaoN006195; Wed, 17 Jul 2002 11:43:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HIhZoT006194; Wed, 17 Jul 2002 11:43:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIhYoN006187 for ; Wed, 17 Jul 2002 11:43:34 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6HIgxGZ007562 for ; Wed, 17 Jul 2002 11:42:59 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6HIgwW6007561 for ipng@sunroof.eng.sun.com; Wed, 17 Jul 2002 11:42:58 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HB3foN002641; Wed, 17 Jul 2002 04:03:41 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15935; Wed, 17 Jul 2002 04:03:42 -0700 (PDT) Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13823; Wed, 17 Jul 2002 05:03:40 -0600 (MDT) Received: from mine.club-internet.fr (lns07a-8-110.w.club-internet.fr [212.194.151.110]) by relay-3m.club-internet.fr (Postfix) with ESMTP id F1A6AE070; Wed, 17 Jul 2002 13:03:35 +0200 (CEST) Message-Id: <5.1.0.14.0.20020717113429.0247ca40@mail.club-internet.fr> X-Sender: jefsey@mail.club-internet.fr X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 17 Jul 2002 11:42:35 +0200 To: David Conrad , Ed Sawicki , Randy Bush From: "J-F C. (Jefsey) Morfin" Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results Cc: DNS Operations , namedroppers , , IPng In-Reply-To: References: <1026847384.23224.49.camel@red> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-21037C77; boundary="=======1309516B=======" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=======1309516B======= Content-Type: text/plain; x-avg-checked=avg-ok-21037C77; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit At 03:44 17/07/02, David Conrad wrote: > > If IETF working groups can't be completely open about > > important standards activity, they should be dissolved and new > > ones formed that have more respect for their public trust. >The point of interoperability testing as it is >relevant to the IETF is to insure the protocol specifications are actually >implementable. From that perspective, it doesn't matter who does the >implementation, rather that at least two different sets of people can >actually do them. The frustration results from an uncompleted report. The target is to demonstrate that different thinking families can have the same reading of the specs and can develop from them compatible softwares. The bugs may results from unclear specs or from an early development phase. That we need to know. The name of the participants would only help knowing the X, Y, Z architectures, used libraries, concept affiliations, "style", etc.. To evaluate if the specs testing spectrum is significant enough. But the better, easiest and common way would be that each participant describes his approach in his own terms (so there is no confidentiality break). IMHO this is basic to any hidden testing protocol. Regards. jfc --=======1309516B=======-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 11:44:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIi6oN006205; Wed, 17 Jul 2002 11:44:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HIi5MW006204; Wed, 17 Jul 2002 11:44:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIi3oN006197 for ; Wed, 17 Jul 2002 11:44:04 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6HIhSGZ007570 for ; Wed, 17 Jul 2002 11:43:28 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6HIhSdF007569 for ipng@sunroof.eng.sun.com; Wed, 17 Jul 2002 11:43:28 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HBk9oN002912; Wed, 17 Jul 2002 04:46:10 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23631; Wed, 17 Jul 2002 04:46:11 -0700 (PDT) Received: from durendal.skynet.be (durendal.skynet.be [195.238.3.91]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09299; Wed, 17 Jul 2002 04:46:10 -0700 (PDT) Received: from [10.0.1.60] (ip-27.shub-internet.org [194.78.144.27] (may be forged)) by durendal.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.19) with ESMTP id g6HBjDH25930; Wed, 17 Jul 2002 13:45:13 +0200 (MET DST) (envelope-from ) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: <20020714132535.A28205@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <5.1.1.6.2.20020715102701.028204b0@localhost> <1026847384.23224.49.camel@red> Date: Wed, 17 Jul 2002 10:52:48 +0200 To: Edward Lewis , Brad Knowles , Ed Sawicki , Randy Bush From: Brad Knowles Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results Cc: dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:04 PM -0400 2002/07/16, Edward Lewis wrote: > 3) For buyers, yes, anonymized results are not beneficial. But > then the IETF is not about being a venue for selling (a la Interop, > trade magazines, consumer shows) but a venue for collaboration. > (I.e., this audience is beyond the scope of the IETF's services.) I don't buy BIND. I don't buy NSD, or bind-dlz, or djbdns, or QuickDNS, or much of anything else of this sort, either. For most of these programs, I download the code, build it, install it, and configure it -- not only for myself, but also (primarily?) for my customers. For those packages which are commercial and available in binary-only format, I have arrangements with the respective vendors so that I can have evaluation copies. It would seem to me that this community has been completely ignored by this report, and therefore also by the IETF. Not everyone in the world is a programmer or a company employing programmers. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 11:44:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIiPoN006215; Wed, 17 Jul 2002 11:44:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HIiOw5006214; Wed, 17 Jul 2002 11:44:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIiMoN006207 for ; Wed, 17 Jul 2002 11:44:22 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6HIhlGZ007578 for ; Wed, 17 Jul 2002 11:43:47 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6HIhkRc007577 for ipng@sunroof.eng.sun.com; Wed, 17 Jul 2002 11:43:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HBkooN002932; Wed, 17 Jul 2002 04:46:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22832; Wed, 17 Jul 2002 04:46:51 -0700 (PDT) Received: from durendal.skynet.be (durendal.skynet.be [195.238.3.91]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06905; Wed, 17 Jul 2002 05:46:50 -0600 (MDT) Received: from [10.0.1.60] (ip-27.shub-internet.org [194.78.144.27] (may be forged)) by durendal.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.19) with ESMTP id g6HBjWH26288; Wed, 17 Jul 2002 13:45:32 +0200 (MET DST) (envelope-from ) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <1243.1026864809@munnari.OZ.AU> References: <20020714132535.A28205@kerkenna.nic.fr> <3D2EA251.D9CBA0A0@6wind.com> <3D2E9633.D02CCD63@6wind.com> <20020712095815.A1849@kerkenna.nic.fr> <5.1.1.6.2.20020715102701.028204b0@localhost> <1026847384.23224.49.camel@red> <1243.1026864809@munnari.OZ.AU> Date: Wed, 17 Jul 2002 11:23:50 +0200 To: Robert Elz , Brad Knowles From: Brad Knowles Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results Cc: Ed Sawicki , Randy Bush , dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:13 AM +0900 2002/07/17, Robert Elz wrote: > We want to know if the standard describes something that can be implemented > in an interoperable way. When a failure occurs, then we need to know > whether of not that is because of a faulty standard, or just an >implementation > bug ("the standard was clear, I just screwed up..."). Okay, fair enough. If all you want to do is test the standard and whether the standard leads to multiple interoperating implementations, and if it doesn't, where the standard is weak, then anonymizing the actual implementations is okay by me. However, in that case, the report should be privately filed first with the WG chairs, then the area director(s) & area advisor(s), each of whom is responsible for ensuring that the report has been purged of all possible data that could potentially identify any of the implementations, and this sanitized report should then be filed with the respective implementors for their confirmation that all identifying data has been removed. Then and only then, should the sanitized report be published via the WG mailing list, put on a web page, or whatever. Moreover, this test should be labelled a "Standards Conformance Test" or "Standards Compliance Test", and not an "Interoperability Test", because the latter can be construed to be discussing "products" as opposed to pre-alpha testing mules. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 11:44:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIimoN006232; Wed, 17 Jul 2002 11:44:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HIilO1006231; Wed, 17 Jul 2002 11:44:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIijoN006224 for ; Wed, 17 Jul 2002 11:44:45 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6HIiAGZ007586 for ; Wed, 17 Jul 2002 11:44:10 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6HIiAGZ007585 for ipng@sunroof.eng.sun.com; Wed, 17 Jul 2002 11:44:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HHuQoN005487; Wed, 17 Jul 2002 10:56:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29917; Wed, 17 Jul 2002 10:56:26 -0700 (PDT) Received: from TheWorld.com (pcls3.std.com [199.172.62.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13976; Wed, 17 Jul 2002 11:56:25 -0600 (MDT) Received: from world.std.com (wgarmil@world-f.std.com [199.172.62.5]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id NAA08460; Wed, 17 Jul 2002 13:56:23 -0400 Received: from localhost (brunner@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id NAA04996; Wed, 17 Jul 2002 13:56:16 -0400 (EDT) Message-Id: <200207171756.NAA04996@world.std.com> X-Authentication-Warning: world.std.com: brunner@localhost didn't use HELO protocol To: Brad Knowles cc: Robert Elz , Ed Sawicki , Randy Bush , dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, brunner@world.std.com Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results In-reply-to: Your message of "Wed, 17 Jul 2002 11:23:50 EDT." Date: Wed, 17 Jul 2002 13:56:16 -0400 From: Eric Brunner Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ... > However, in that case, the report should be privately filed first > with the WG chairs ... What part of 2028 does this rely upon? Eric -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 11:54:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIs1oN006386; Wed, 17 Jul 2002 11:54:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HIs14Y006385; Wed, 17 Jul 2002 11:54:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HIrqoN006370; Wed, 17 Jul 2002 11:53:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22972; Wed, 17 Jul 2002 11:53:53 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04794; Wed, 17 Jul 2002 12:53:53 -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 LAA29658; Wed, 17 Jul 2002 11:53:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6HIrpC09380; Wed, 17 Jul 2002 11:53:51 -0700 X-mProtect: <200207171853> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdk6Ad8c; Wed, 17 Jul 2002 11:53:48 PDT Message-ID: <3D35BD3D.A47B2E09@iprg.nokia.com> Date: Wed, 17 Jul 2002 11:53:49 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020717140100.C4A734B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi Itojun, itojun@iijlab.net wrote: > as you may have heard during IETF54 IESG plenary panel session, > i would like to see the above "MUST" removed. there are large amount > of IPv6 install base, which supports no HAO, or old definition of HAO. > for instance, FreeBSD beyond 4.0 has IPv6 but no support for HAO. > MacOS 10.2, JunOS and ExtremeWare do not have HAO support either. > suspect they have no HAO support. > > we have no way to force upgrade for all users of the existing IPv6 > stacks. therefore, i believe it very important for mobile-ip6 to be > defined so that: > - mobile-ip6 MN is interoperable with CN without HAO support, nor > binding error message support it is. if a CN does not support HAO, it will send an ICMP error message pointing to the offending octet. when the MN receives this message, it starts reverse-tunneling through the Home Agent. where is the problem? if this is not clearly specified in the MIPv6 draft, it can be. the binding error functionality can also be substituted by an ICMP error. Binding Error was specified so that it is easier for the MN to figure out whats going on. > - do not require any changes to existing implementations we dont have to. > - do not make them "non-conformant" everytime a new standard comes out, there is something new in it. regards Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 14:21:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLLKoN007172; Wed, 17 Jul 2002 14:21:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLLKux007171; Wed, 17 Jul 2002 14:21:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLLGoN007164; Wed, 17 Jul 2002 14:21:16 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11706; Wed, 17 Jul 2002 14:21:17 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14058; Wed, 17 Jul 2002 15:21:15 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 4853C4B22; Thu, 18 Jul 2002 06:21:10 +0900 (JST) To: Vijay Devarapalli Cc: keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: vijayd's message of Wed, 17 Jul 2002 11:53:49 MST. <3D35BD3D.A47B2E09@iprg.nokia.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: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Thu, 18 Jul 2002 06:21:10 +0900 Message-Id: <20020717212110.4853C4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >it is. if a CN does not support HAO, it will send an ICMP error message >pointing to the offending octet. when the MN receives this message, it >starts reverse-tunneling through the Home Agent. where is the problem? >if this is not clearly specified in the MIPv6 draft, it can be. the >binding error functionality can also be substituted by an ICMP error. >Binding Error was specified so that it is easier for the MN to figure >out whats going on. then I see no reason for the MUST. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 14:33:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLXVoN007392; Wed, 17 Jul 2002 14:33:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLXUh7007391; Wed, 17 Jul 2002 14:33:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLXNoN007376; Wed, 17 Jul 2002 14:33:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17162; Wed, 17 Jul 2002 14:33:24 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02544; Wed, 17 Jul 2002 15:33:24 -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 OAA09219; Wed, 17 Jul 2002 14:33:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6HLXM832063; Wed, 17 Jul 2002 14:33:22 -0700 X-mProtect: <200207172133> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6Nu3Zt; Wed, 17 Jul 2002 14:33:21 PDT Message-ID: <3D35E2A1.18E60F30@iprg.nokia.com> Date: Wed, 17 Jul 2002 14:33:21 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020717212110.4853C4B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >it is. if a CN does not support HAO, it will send an ICMP error message > >pointing to the offending octet. when the MN receives this message, it > >starts reverse-tunneling through the Home Agent. where is the problem? > >if this is not clearly specified in the MIPv6 draft, it can be. the > >binding error functionality can also be substituted by an ICMP error. > >Binding Error was specified so that it is easier for the MN to figure > >out whats going on. > > then I see no reason for the MUST. I was discounting the reason (the already IPv6 installed base) you gave. the MUST is for newer IPv6 CN implementations. as I told you already, it makes the MN's life easier. but the current spec does ensure that a MN can still have a session with an old IPv6 implementation (which does not implement HAO) through reverse tunneling. so again, where is the problem? why are you against the MUST? regards Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 14:35:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLZnoN007490; Wed, 17 Jul 2002 14:35:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLZn90007489; Wed, 17 Jul 2002 14:35:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLZdoN007465; Wed, 17 Jul 2002 14:35:40 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17845; Wed, 17 Jul 2002 14:35:40 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22144; Wed, 17 Jul 2002 15:35:40 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g6HLZOqI012562; Wed, 17 Jul 2002 14:35:24 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE24062; Wed, 17 Jul 2002 14:30:50 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA01095; Wed, 17 Jul 2002 14:35:24 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15669.58139.802666.499612@thomasm-u1.cisco.com> Date: Wed, 17 Jul 2002 14:35:23 -0700 (PDT) To: itojun@iijlab.net Cc: Vijay Devarapalli , keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <20020717212110.4853C4B22@coconut.itojun.org> References: <3D35BD3D.A47B2E09@iprg.nokia.com> <20020717212110.4853C4B22@coconut.itojun.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > >it is. if a CN does not support HAO, it will send an ICMP error message > >pointing to the offending octet. when the MN receives this message, it > >starts reverse-tunneling through the Home Agent. where is the problem? > >if this is not clearly specified in the MIPv6 draft, it can be. the > >binding error functionality can also be substituted by an ICMP error. > >Binding Error was specified so that it is easier for the MN to figure > >out whats going on. > > then I see no reason for the MUST. Sez RFC 2119: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Given that MIPv6 will interoperate without binding code in CN's, it looks pretty much like a SHOULD to me. Indeed, the protocol would not be robust if it didn't consider the case of a non-conformant CN. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 14:45:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLjGoN007836; Wed, 17 Jul 2002 14:45:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLjGwq007835; Wed, 17 Jul 2002 14:45:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLjBoN007828; Wed, 17 Jul 2002 14:45:11 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03034; Wed, 17 Jul 2002 14:45:13 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01210; Wed, 17 Jul 2002 14:45:12 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6HLj1rU015297; Wed, 17 Jul 2002 23:45:01 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS0VA55>; Wed, 17 Jul 2002 23:45:00 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F087E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Michael Thomas'" , itojun@iijlab.net Cc: Vijay Devarapalli , keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 17 Jul 2002 23:44:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > itojun@iijlab.net writes: > > >it is. if a CN does not support HAO, it will send an > ICMP error message > > >pointing to the offending octet. when the MN receives > this message, it > > >starts reverse-tunneling through the Home Agent. where > is the problem? > > >if this is not clearly specified in the MIPv6 draft, it > can be. the > > >binding error functionality can also be substituted by > an ICMP error. > > >Binding Error was specified so that it is easier for > the MN to figure > > >out whats going on. > > > > then I see no reason for the MUST. > > Sez RFC 2119: > > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be > used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit > behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a > particular method > on implementors where the method is not required for > interoperability. > > Given that MIPv6 will interoperate without binding > code in CN's, it looks pretty much like a SHOULD > to me. Indeed, the protocol would not be robust if > it didn't consider the case of a non-conformant CN. => Exactly, IMHO the support for HAO is tied to RO support which is a SHOULD anyway, so the HAO should follow that. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 14:46:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLkpoN007882; Wed, 17 Jul 2002 14:46:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLkpx9007881; Wed, 17 Jul 2002 14:46:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLkhoN007866; Wed, 17 Jul 2002 14:46:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22299; Wed, 17 Jul 2002 14:46:44 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10198; Wed, 17 Jul 2002 15:46:43 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6HLlEi15859; Thu, 18 Jul 2002 00:47:14 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Jul 2002 00:46:41 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 00:46:41 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 18 Jul 2002 00:46:40 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt2tA/FtgIzJg+RKiy5eTmymsynQAACliw To: , Cc: , , , X-OriginalArrivalTime: 17 Jul 2002 21:46:41.0543 (UTC) FILETIME=[6FBB5170:01C22DDB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6HLkhoN007867 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Michael, > > then I see no reason for the MUST. > > Sez RFC 2119: > > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. > > Given that MIPv6 will interoperate without binding > code in CN's, it looks pretty much like a SHOULD > to me. Indeed, the protocol would not be robust if > it didn't consider the case of a non-conformant CN. I think we want to ask is, is it the right thing to do? For proper protocol functioning, will this lead to the correct behavior. If we think it is important, the MUST is OK. The spec does contain a mechanism to support existing implementations of IPv6, which means the protocol designers are doing their jobs. As I see it, we should focus on the behavior & if it is the right thing to do, then we should do it. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 14:51:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLpToN008206; Wed, 17 Jul 2002 14:51:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLpTrV008205; Wed, 17 Jul 2002 14:51:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLpQoN008198 for ; Wed, 17 Jul 2002 14:51:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00719 for ; Wed, 17 Jul 2002 14:51:28 -0700 (PDT) Received: from mg01.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05333 for ; Wed, 17 Jul 2002 14:51:27 -0700 (PDT) Received: from austin.ibm.com (netmail.austin.ibm.com [9.3.7.137]) by mg01.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA17344 for ; Wed, 17 Jul 2002 16:50:22 -0500 Received: from porkchop.austin.ibm.com (porkchop.austin.ibm.com [9.53.151.169]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA44290; Wed, 17 Jul 2002 16:51:25 -0500 Received: from localhost (lilianf@localhost) by porkchop.austin.ibm.com (AIX5.1/8.11.0/8.11.0-client1.01) with ESMTP id g6HLpPV44738; Wed, 17 Jul 2002 16:51:25 -0500 Date: Wed, 17 Jul 2002 16:51:24 -0500 (CDT) From: Lilian Fernandes To: ipng@sunroof.eng.sun.com cc: David Subject: MIB Status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, What is the status of the new MIB drafts that consolidate both the IPv4 and IPv6 MIBs? Is there a projected time/plan for these drafts to move to RFC status? I guess most implementations today still have RFCs 2454, 2465, 2452 and 2466? It looks like the new drafts will obsolete all these RFCs in addition to RFCs 2011,2012 and 2013. I hope this is the right place to ask this question. Thanks for your help, Lilian _____________________________________________________________________ Lilian Fernandes AIX TCP/IP Development - IBM Austin Tel: 512-838-7966 Fax: 512-838-3509 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 14:51:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLproN008236; Wed, 17 Jul 2002 14:51:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLpqgl008235; Wed, 17 Jul 2002 14:51:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLpgoN008215; Wed, 17 Jul 2002 14:51:42 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24940; Wed, 17 Jul 2002 14:51:43 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18913; Wed, 17 Jul 2002 15:51:43 -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 OAA10381; Wed, 17 Jul 2002 14:51:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6HLpgL32369; Wed, 17 Jul 2002 14:51:42 -0700 X-mProtect: <200207172151> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDerkWW; Wed, 17 Jul 2002 14:51:40 PDT Message-ID: <3D35E6EC.DC779400@iprg.nokia.com> Date: Wed, 17 Jul 2002 14:51:40 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: "'Michael Thomas'" , itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <4DA6EA82906FD511BE2F00508BCF0538044F087E@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi Hesham, "Hesham Soliman (EAB)" wrote: > => Exactly, IMHO the support for HAO is tied to > RO support which is a SHOULD anyway, so the HAO > should follow that. we have been through this before. the support for HAO is tied to the verifiability of the home address (otherwise you can have reflection attacks). there are other mechanisms apart from RO to verify a particular home address. I am not going to get into those mechanisms now. check the archives. Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 14:57:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLv2oN008529; Wed, 17 Jul 2002 14:57:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HLv2Hf008528; Wed, 17 Jul 2002 14:57:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HLutoN008513; Wed, 17 Jul 2002 14:56:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02928; Wed, 17 Jul 2002 14:56:56 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16513; Wed, 17 Jul 2002 15:56:55 -0600 (MDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6HLvQi17960; Thu, 18 Jul 2002 00:57:26 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Jul 2002 00:56:53 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 00:56:53 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 18 Jul 2002 00:56:53 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578A@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt29iVRvBHTOg1RfWdr49vHQaCggAAH6Yw To: , , Cc: , , , X-OriginalArrivalTime: 17 Jul 2002 21:56:53.0835 (UTC) FILETIME=[DCAFA9B0:01C22DDC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6HLutoN008514 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, > => Exactly, IMHO the support for HAO is tied to > RO support which is a SHOULD anyway, so the HAO > should follow that. Logically, you are inconsistant. As an example, RO is a should, protecting RO is a MUST. This set of mail exchanges have actually made me think that this is important functionally and that implementing HAO is important for security reasons and it is not unreasonable to insist all nodes implement it. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 15:21:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HMLRoN008892; Wed, 17 Jul 2002 15:21:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HMLRQ4008891; Wed, 17 Jul 2002 15:21:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HMLMoN008884 for ; Wed, 17 Jul 2002 15:21:23 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23308 for ; Wed, 17 Jul 2002 15:21:24 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05615 for ; Wed, 17 Jul 2002 16:21:24 -0600 (MDT) Received: from cbin2-mira-01.cisco.com (IDENT:mirapoint@cbin2-mira-01.cisco.com [64.104.144.38]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g6HMLIqI005169; Wed, 17 Jul 2002 15:21:19 -0700 (PDT) Received: from cisco.com (dhcp-128-107-165-73.cisco.com [128.107.165.73]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id ALP08070 (AUTH raraghun); Thu, 18 Jul 2002 03:48:20 +0530 (IST) Message-ID: <3D35EDD9.52D73FAE@cisco.com> Date: Wed, 17 Jul 2002 15:21:13 -0700 From: Rajiv Raghunarayan Reply-To: rrajiv@cisco.com Organization: cisco Systems Inc. X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lilian Fernandes CC: ipng@sunroof.eng.sun.com, David Subject: Re: MIB Status References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Lilian, New versions of the IPv6 MIB drafts have recently been published. And this topic is going to be addressed in the IETF IPv6 WG meet today. Most of these drafts are achieving stability and should, hopefully, make it to the IESG before the Atlanta IETF. You may also want to look up the meeting minutes of the IPv6 WG meet in Yokohama for the most up-to-date status, or if possible join the multicast stream of the meet later today. -Rajiv. Lilian Fernandes wrote: > > Hello, > > What is the status of the new MIB drafts that consolidate both the IPv4 > and IPv6 MIBs? > Is there a projected time/plan for these drafts to move to RFC status? > > I guess most implementations today still have RFCs 2454, 2465, 2452 and > 2466? It looks like the new drafts will obsolete all these RFCs in > addition to RFCs 2011,2012 and 2013. > > I hope this is the right place to ask this question. > > Thanks for your help, > Lilian > > _____________________________________________________________________ > > Lilian Fernandes > AIX TCP/IP Development - IBM Austin > Tel: 512-838-7966 Fax: 512-838-3509 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jul 17 15:22:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HMMDoN008915; Wed, 17 Jul 2002 15:22:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HMMD0c008914; Wed, 17 Jul 2002 15:22:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HMM3oN008896; Wed, 17 Jul 2002 15:22:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23582; Wed, 17 Jul 2002 15:22:05 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17199; Wed, 17 Jul 2002 16:22:04 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6HMLhOu015722; Wed, 17 Jul 2002 15:21:43 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE25457; Wed, 17 Jul 2002 15:17:12 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA01099; Wed, 17 Jul 2002 15:21:46 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15669.60922.686205.742010@thomasm-u1.cisco.com> Date: Wed, 17 Jul 2002 15:21:46 -0700 (PDT) To: Cc: , , , , , Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com writes: > > Given that MIPv6 will interoperate without binding > > code in CN's, it looks pretty much like a SHOULD > > to me. Indeed, the protocol would not be robust if > > it didn't consider the case of a non-conformant CN. > > I think we want to ask is, is it the right thing to do? For > proper protocol functioning, will this lead to the correct > behavior. If we think it is important, the MUST is OK. The > spec does contain a mechanism to support existing implementations > of IPv6, which means the protocol designers are doing their > jobs. I think we're straying into a "good" as in "good for the overall health of the Internet" kind of good, rather than a "good" as in will the protocol operate correctly. For the former, I think you need to have extremely compelling motivation, as well as a lot of evidence that the health of the net will be imperiled if *all* nodes don't implement a particular function, which is what is at issue here. Frankly, I don't think that there is any evidence that the net would be substantially harmed if RO wasn't widely implemented and/or enabled. Indeed, I think there's good reason to believe that many/most nodes will not enable RO even if their kernel implements it. In some cases, it's likely to be a nice and useful optimization, but I really don't see it as a "if we don't do this the net will fall apart". As such, SHOULD seems like it strikes the right balance. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 16:35:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HNZAoN009664; Wed, 17 Jul 2002 16:35:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HNZARg009661; Wed, 17 Jul 2002 16:35:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HNYvoN009637; Wed, 17 Jul 2002 16:34:57 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04452; Wed, 17 Jul 2002 16:34:59 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09869; Wed, 17 Jul 2002 16:34:59 -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 QAA17241; Wed, 17 Jul 2002 16:34:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6HNYwp08852; Wed, 17 Jul 2002 16:34:58 -0700 X-mProtect: <200207172334> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdg0rnDz; Wed, 17 Jul 2002 16:34:56 PDT Message-ID: <3D35FF20.2E5FCADF@iprg.nokia.com> Date: Wed, 17 Jul 2002 16:34:56 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> <15669.60922.686205.742010@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, RO is a SHOULD, it is not a MUST in the current draft. we were not talking about route optimization. we were talking about processing a HAO. in the current spec HAO MUST be processed but not accepted if it cant be verified. verification can be in the form of checking for a valid BCE (created securely), IPsec protected data session, same trusted domain (where you dont expect people to do reflection attacks), the tagging proposal from Rajeev and Charlie, smart ingress filtering from Francis Dupont, etc... processing a HAO is simply replacing the source address with the contents of the HAO. earlier it is used to be a MUST without the verification step. IPv6 WG was okay with that. but people indentified some reflection attacks that are possible if you blindly accept unverified home address option. so now, it is a MUST with the verification step. regards Vijay Michael Thomas wrote: > > john.loughney@nokia.com writes: > > > Given that MIPv6 will interoperate without binding > > > code in CN's, it looks pretty much like a SHOULD > > > to me. Indeed, the protocol would not be robust if > > > it didn't consider the case of a non-conformant CN. > > > > I think we want to ask is, is it the right thing to do? For > > proper protocol functioning, will this lead to the correct > > behavior. If we think it is important, the MUST is OK. The > > spec does contain a mechanism to support existing implementations > > of IPv6, which means the protocol designers are doing their > > jobs. > > I think we're straying into a "good" as in > "good for the overall health of the Internet" > kind of good, rather than a "good" as in will > the protocol operate correctly. For the former, > I think you need to have extremely compelling > motivation, as well as a lot of evidence that > the health of the net will be imperiled if *all* > nodes don't implement a particular function, which > is what is at issue here. > > Frankly, I don't think that there is any evidence > that the net would be substantially harmed if RO > wasn't widely implemented and/or enabled. Indeed, > I think there's good reason to believe that many/most > nodes will not enable RO even if their kernel > implements it. In some cases, it's likely to be > a nice and useful optimization, but I really > don't see it as a "if we don't do this the net > will fall apart". As such, SHOULD seems like it > strikes the right balance. > > Mike > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 16:55:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HNtloN009924; Wed, 17 Jul 2002 16:55:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6HNtl0X009923; Wed, 17 Jul 2002 16:55:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6HNteoN009908; Wed, 17 Jul 2002 16:55:40 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11684; Wed, 17 Jul 2002 16:55:42 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28422; Wed, 17 Jul 2002 17:55:42 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6HNtOM2010893; Wed, 17 Jul 2002 16:55:24 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE28060; Wed, 17 Jul 2002 16:50:50 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA01111; Wed, 17 Jul 2002 16:55:23 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15670.1003.493633.920465@thomasm-u1.cisco.com> Date: Wed, 17 Jul 2002 16:55:23 -0700 (PDT) To: Vijay Devarapalli Cc: Michael Thomas , john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <3D35FF20.2E5FCADF@iprg.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> <15669.60922.686205.742010@thomasm-u1.cisco.com> <3D35FF20.2E5FCADF@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vijay Devarapalli writes: > RO is a SHOULD, it is not a MUST in the current draft. we were > not talking about route optimization. we were talking about > processing a HAO. in the current spec HAO MUST be processed but > not accepted if it cant be verified. verification can be in the > form of checking for a valid BCE (created securely), IPsec > protected data session, same trusted domain (where you dont > expect people to do reflection attacks), the tagging proposal > from Rajeev and Charlie, smart ingress filtering from Francis > Dupont, etc... Oh, OK. Sorry about that. Still if the code isn't in the CN, the MN should still be able to operate correctly, right? That still seems to me to be a SHOULD rather than a MUST for the same reasons in my reply to John. I guess the long and short of this is that I'm somewhat skeptical of putting general node requirements in the MIP draft since it's probably not the first place one would be looking to figure out if they were an IPv6 compliant node. If it's really, really vital for the health of the net, yadda, yadda, it would be better to put it in a general v6 node requirements RFC, don't you think? Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 17:13:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0D1oN010096; Wed, 17 Jul 2002 17:13:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0D05x010095; Wed, 17 Jul 2002 17:13:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0CvoN010088; Wed, 17 Jul 2002 17:12:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18862; Wed, 17 Jul 2002 17:12:59 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27692; Wed, 17 Jul 2002 18:12:58 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 34F404B22; Thu, 18 Jul 2002 09:12:50 +0900 (JST) To: Vijay Devarapalli Cc: Michael Thomas , john.loughney@nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: vijayd's message of Wed, 17 Jul 2002 16:34:56 MST. <3D35FF20.2E5FCADF@iprg.nokia.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: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Thu, 18 Jul 2002 09:12:50 +0900 Message-Id: <20020718001250.34F404B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >processing a HAO is simply replacing the source address with >the contents of the HAO. earlier it is used to be a MUST without >the verification step. IPv6 WG was okay with that. but people >indentified some reflection attacks that are possible if you >blindly accept unverified home address option. so now, it is a >MUST with the verification step. IPv6 wg OKed HAO in draft 5 or 6. HAO changed a lot since then, and i think it not reasonable for you to think that new-HAO is also OKed automaticalliy. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 17:13:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0DooN010123; Wed, 17 Jul 2002 17:13:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0DoxZ010122; Wed, 17 Jul 2002 17:13:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0DdoN010107; Wed, 17 Jul 2002 17:13:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17062; Wed, 17 Jul 2002 17:13:41 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA04612; Wed, 17 Jul 2002 18:13:40 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6I0EBi24441; Thu, 18 Jul 2002 03:14:11 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Jul 2002 03:13:38 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 03:13:38 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 18 Jul 2002 03:13:38 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578D@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt7cTWMfDr88ZlQ3iaoLJAwT95/QAAdA9A To: , Cc: , , , X-OriginalArrivalTime: 18 Jul 2002 00:13:38.0943 (UTC) FILETIME=[F74FC8F0:01C22DEF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6I0DeoN010108 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mike, > Vijay Devarapalli writes: > > RO is a SHOULD, it is not a MUST in the current draft. we were > > not talking about route optimization. we were talking about > > processing a HAO. in the current spec HAO MUST be processed but > > not accepted if it cant be verified. verification can be in the > > form of checking for a valid BCE (created securely), IPsec > > protected data session, same trusted domain (where you dont > > expect people to do reflection attacks), the tagging proposal > > from Rajeev and Charlie, smart ingress filtering from Francis > > Dupont, etc... > > Oh, OK. Sorry about that. Still if the code > isn't in the CN, the MN should still be able > to operate correctly, right? That still seems > to me to be a SHOULD rather than a MUST for the > same reasons in my reply to John. > > I guess the long and short of this is that I'm > somewhat skeptical of putting general node > requirements in the MIP draft since it's > probably not the first place one would be > looking to figure out if they were an IPv6 > compliant node. If it's really, really vital > for the health of the net, yadda, yadda, it > would be better to put it in a general v6 node > requirements RFC, don't you think? Just as an FYI, I replied to the earlier mail because I am trying to sort this out for the node requirements. I think that in MIPv6, it is OK that MIPv6 makes this recommendation (given working group consensus, IESG approval, etc.) but the Node Requirements document is the final word on the issue (assuming WG consensus, IESG approval, etc.). John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 17:19:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0JpoN010403; Wed, 17 Jul 2002 17:19:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0Jp6u010402; Wed, 17 Jul 2002 17:19:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0JloN010395; Wed, 17 Jul 2002 17:19:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19048; Wed, 17 Jul 2002 17:19:50 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29292; Wed, 17 Jul 2002 17:19:49 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6I0JfRb002615; Thu, 18 Jul 2002 02:19:41 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS0VSTZ>; Thu, 18 Jul 2002 02:19:41 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F087F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'john.loughney@nokia.com'" , "Hesham Soliman (EAB)" , mat@cisco.com, itojun@iijlab.net Cc: vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Thu, 18 Jul 2002 02:19:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => Exactly, IMHO the support for HAO is tied to > > RO support which is a SHOULD anyway, so the HAO > > should follow that. > > Logically, you are inconsistant. > > As an example, RO is a should, protecting RO is a MUST. => Huh? Protecting it is a must for those who support it! But supporting it is a should. Hesham > > This set of mail exchanges have actually made me think > that this is important functionally and that implementing HAO is > important for security reasons and it is not unreasonable to > insist all nodes implement it. > > John > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 17:23:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0NooN010560; Wed, 17 Jul 2002 17:23:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0Nope010559; Wed, 17 Jul 2002 17:23:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0NgoN010535; Wed, 17 Jul 2002 17:23:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22495; Wed, 17 Jul 2002 17:23:45 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA08703; Wed, 17 Jul 2002 18:23:44 -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 RAA20331; Wed, 17 Jul 2002 17:23:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6I0NgS07794; Wed, 17 Jul 2002 17:23:42 -0700 X-mProtect: <200207180023> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCxPx1p; Wed, 17 Jul 2002 17:23:40 PDT Message-ID: <3D360A8C.928E9CAD@iprg.nokia.com> Date: Wed, 17 Jul 2002 17:23:40 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: Michael Thomas , john.loughney@nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020718001250.34F404B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >processing a HAO is simply replacing the source address with > >the contents of the HAO. earlier it is used to be a MUST without > >the verification step. IPv6 WG was okay with that. but people > >indentified some reflection attacks that are possible if you > >blindly accept unverified home address option. so now, it is a > >MUST with the verification step. > > IPv6 wg OKed HAO in draft 5 or 6. HAO changed a lot since then, > and i think it not reasonable for you to think that new-HAO is also > OKed automaticalliy. new-HAO?? the format has not changed. neither has the processing. it is still a destination option. how is it new? infact it has been made secure by the new verification step. infact, (IMO) there is no need for this new verification step if we have smart ingress filtering as described by Francis Dupont in http://www.ietf.org/internet-drafts/draft-dupont-ipv6-ingress-filtering-00.txt. Francis is probably around somewhere. can you please talk to him? Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 17:27:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0RYoN010755; Wed, 17 Jul 2002 17:27:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0RX2C010754; Wed, 17 Jul 2002 17:27:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0RUoN010746 for ; Wed, 17 Jul 2002 17:27:30 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA06755; Wed, 17 Jul 2002 20:27:33 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g6I0RWZs015154; Wed, 17 Jul 2002 20:27:32 -0400 (EDT) Message-Id: <200207180027.g6I0RWZs015154@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Thomas cc: Vijay Devarapalli , john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: Your message of "Wed, 17 Jul 2002 16:55:23 PDT." <15670.1003.493633.920465@thomasm-u1.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 17 Jul 2002 20:27:32 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i'm in violent agreement. HAO processing should not be a MUST. HAO is not useful without verification and largely pointless unless you're doing route optimization and can support a binding cache which is large enough to be meaningful. Given that there's already a way for a node to indicate "no thank you" (icmp parameter problem) and given (like every other "interesting" extension we've attempted at the IP layer) that there will likely be HAO "black holes" due to firewall policy and/or dusty embedded code, I don't see the value of forcing nodes to even spend the extra effort to parse enough of the HAO to generate a different error. MN's will need to have code to parse the parameter problem form of the error; why burden them with additional code to parse the other way to encode the error message? - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 17:37:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0bEoN010854; Wed, 17 Jul 2002 17:37:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0bE7W010853; Wed, 17 Jul 2002 17:37:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0b7oN010838; Wed, 17 Jul 2002 17:37:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26404; Wed, 17 Jul 2002 17:37:07 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA13470; Wed, 17 Jul 2002 18:37: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 RAA20998; Wed, 17 Jul 2002 17:37:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6I0b5f24390; Wed, 17 Jul 2002 17:37:05 -0700 X-mProtect: <200207180037> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (133.93.79.116, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdETGokX; Wed, 17 Jul 2002 17:37:02 PDT Message-ID: <3D360D42.A934AA34@iprg.nokia.com> Date: Wed, 17 Jul 2002 17:35:15 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020718001250.34F404B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Itojun, The home address option is the same in format as the previous version. The additional requirement now is only that now it's required to be secured somehow. Regards, Charlie P. itojun@iijlab.net wrote: > >processing a HAO is simply replacing the source address with > >the contents of the HAO. earlier it is used to be a MUST without > >the verification step. IPv6 WG was okay with that. but people > >indentified some reflection attacks that are possible if you > >blindly accept unverified home address option. so now, it is a > >MUST with the verification step. > > IPv6 wg OKed HAO in draft 5 or 6. HAO changed a lot since then, > and i think it not reasonable for you to think that new-HAO is also > OKed automaticalliy. > > 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 Wed Jul 17 17:38:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0cNoN010878; Wed, 17 Jul 2002 17:38:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0cNnC010877; Wed, 17 Jul 2002 17:38:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0cJoN010870 for ; Wed, 17 Jul 2002 17:38:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26718 for ; Wed, 17 Jul 2002 17:38:20 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA13826 for ; Wed, 17 Jul 2002 18:38:19 -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 RAA21017; Wed, 17 Jul 2002 17:38:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6I0cI124745; Wed, 17 Jul 2002 17:38:18 -0700 X-mProtect: <200207180038> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJM6bfn; Wed, 17 Jul 2002 17:38:16 PDT Message-ID: <3D360DF8.2B29D681@iprg.nokia.com> Date: Wed, 17 Jul 2002 17:38:16 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: Michael Thomas , john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <200207180027.g6I0RWZs015154@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Sommerfeld wrote: > > i'm in violent agreement. HAO processing should not be a MUST. > > HAO is not useful without verification and largely pointless unless > you're doing route optimization and can support a binding cache which > is large enough to be meaningful. the point is this verification can be done in many ways. the point is processing of HAO gives you triangular routing, which is much better than reverse tunneling. talking about "black holes", the combination of reverse tunneling and route optimization is likely to cause loss of packets. with triangular routing and route optimization, you dont lose packets. anyway, I dont want to get into the argument, triangular routing Vs reverse tunneling. regards Vijay > > Given that there's already a way for a node to indicate "no thank you" > (icmp parameter problem) and given (like every other "interesting" > extension we've attempted at the IP layer) that there will likely be > HAO "black holes" due to firewall policy and/or dusty embedded code, I > don't see the value of forcing nodes to even spend the extra effort to > parse enough of the HAO to generate a different error. > > MN's will need to have code to parse the parameter problem form of the > error; why burden them with additional code to parse the other way to > encode the error message? > > - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 17:41:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0fSoN011036; Wed, 17 Jul 2002 17:41:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0fSPM011035; Wed, 17 Jul 2002 17:41:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0fKoN011011; Wed, 17 Jul 2002 17:41:20 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16765; Wed, 17 Jul 2002 17:41:21 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16683; Wed, 17 Jul 2002 18:41:20 -0600 (MDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6I0hMW10331; Thu, 18 Jul 2002 03:43:22 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Jul 2002 03:41:18 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 03:41:18 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 18 Jul 2002 03:41:18 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38ECF@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt8ZI6pG4dYJ6ERBKA9LCbowSLNwAAQizQ To: , , Cc: , , , X-OriginalArrivalTime: 18 Jul 2002 00:41:18.0675 (UTC) FILETIME=[D496CA30:01C22DF3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6I0fKoN011014 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Hesham, > > > => Exactly, IMHO the support for HAO is tied to > > > RO support which is a SHOULD anyway, so the HAO > > > should follow that. > > > > Logically, you are inconsistant. > > > > As an example, RO is a should, protecting RO is a MUST. > > => Huh? > > Protecting it is a must for those who support it! > But supporting it is a should. We're dangerously on the edge of a rathole. Debates on support / implement / use of various functions is something to often causes pointless discussions. The question more is, what do general implementations need to implement. In my opinion, general often equals robust. SHOULD does not mean optional, it means you do it unless you have good reason not to do it. I think the burden of proof, then, would be the endpoint which does not implement a certain feature. I think that since HAO is used for security reasons, it may have a strong need to be a must than other functionality. Just my opinion. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 17:43:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0hSoN011153; Wed, 17 Jul 2002 17:43:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0hSbt011152; Wed, 17 Jul 2002 17:43:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0hJoN011118; Wed, 17 Jul 2002 17:43:19 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17543; Wed, 17 Jul 2002 17:43:20 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08848; Wed, 17 Jul 2002 17:43:19 -0700 (PDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 17 Jul 2002 17:44:48 -0700 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22DF4.1C40AC15" Date: Wed, 17 Jul 2002 17:43:18 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6EAB6B15@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt8bZcWArFmmXXSCy6gTz5ONnANgAAlLug From: "Mohan Parthasarathy" To: "Vijay Devarapalli" , Cc: "Michael Thomas" , , , , X-OriginalArrivalTime: 18 Jul 2002 00:44:48.0234 (UTC) FILETIME=[517EF4A0:01C22DF4] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C22DF4.1C40AC15 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Vijay, I am missing something. Can we invent a new option in the future and call it a MUST be processed by all nodes ? If a node does not understand the option, it should use the icmp parameter problem to return errors. Not sure why we need something special for HAO. -mohan > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]=20 > Sent: Wednesday, July 17, 2002 5:24 PM > To: itojun@iijlab.net > Cc: Michael Thomas; john.loughney@nokia.com;=20 > keiichi@iij.ad.jp; mobile-ip@sunroof.eng.sun.com;=20 > ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated >=20 >=20 > itojun@iijlab.net wrote: > >=20 > > >processing a HAO is simply replacing the source address with the=20 > > >contents of the HAO. earlier it is used to be a MUST without the=20 > > >verification step. IPv6 WG was okay with that. but people=20 > indentified=20 > > >some reflection attacks that are possible if you blindly accept=20 > > >unverified home address option. so now, it is a MUST with the=20 > > >verification step. > >=20 > > IPv6 wg OKed HAO in draft 5 or 6. HAO changed a=20 > lot since then, > > and i think it not reasonable for you to think that=20 > new-HAO is also > > OKed automaticalliy. >=20 > new-HAO?? the format has not changed. neither has the=20 > processing. it is still a destination option. how is it new?=20 > infact it has=20 > been made secure by the new verification step. >=20 > infact, (IMO) there is no need for this new verification step=20 > if we have smart ingress filtering as described by Francis=20 > Dupont in=20 > http://www.ietf.org/internet-drafts/draft-dupont-ipv6-ingress- filtering-00.txt. Francis is probably around somewhere. can you please talk to him? Vijay ------_=_NextPart_001_01C22DF4.1C40AC15 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: HAO and BE processing will be = mandated

    Vijay,

    I am missing something. Can we invent a new option in = the future
    and call it a MUST be processed by all nodes ? If a = node does
    not understand the option, it should use the icmp = parameter
    problem to return errors. Not sure why we need = something special
    for HAO.

    -mohan


    > -----Original Message-----
    > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] =
    > Sent: Wednesday, July 17, 2002 5:24 PM
    > To: itojun@iijlab.net
    > Cc: Michael Thomas; john.loughney@nokia.com; =
    > keiichi@iij.ad.jp; = mobile-ip@sunroof.eng.sun.com;
    > ipng@sunroof.eng.sun.com
    > Subject: Re: [mobile-ip] Re: HAO and BE = processing will be mandated
    >
    >
    > itojun@iijlab.net wrote:
    > >
    > > >processing a HAO is simply replacing = the source address with the
    > > >contents of the HAO. earlier it is used = to be a MUST without the
    > > >verification step. IPv6 WG was okay = with that. but people
    > indentified
    > > >some reflection attacks that are = possible if you blindly accept
    > > >unverified home address option. so now, = it is a MUST with the
    > > >verification step.
    > >
    > = >         IPv6 wg OKed HAO in = draft 5 or 6.  HAO changed a
    > lot since then,
    > = >         and i think it not = reasonable for you to think that
    > new-HAO is also
    > = >         OKed = automaticalliy.
    >
    > new-HAO?? the format has not changed. neither = has the
    > processing. it is still a destination option. = how is it new?
    > infact it has
    > been made secure by the new verification = step.
    >
    > infact, (IMO) there is no need for this new = verification step
    > if we have smart ingress filtering as described = by Francis
    > Dupont in
    > h= ttp://www.ietf.org/internet-drafts/draft-dupont-ipv6-ingress-
    filtering-00.txt.
    Francis is probably around somewhere. can you please = talk to him?

    Vijay

    ------_=_NextPart_001_01C22DF4.1C40AC15-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 17:53:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0rpoN011579; Wed, 17 Jul 2002 17:53:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0rprF011578; Wed, 17 Jul 2002 17:53:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0rkoN011571; Wed, 17 Jul 2002 17:53:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28284; Wed, 17 Jul 2002 17:53:48 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14214; Wed, 17 Jul 2002 18:53:46 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g6I0reRb004021; Thu, 18 Jul 2002 02:53:40 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <3YS0VWQ6>; Thu, 18 Jul 2002 02:53:40 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0881@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'john.loughney@nokia.com'" , "Hesham Soliman (EAB)" , mat@cisco.com, itojun@iijlab.net Cc: vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Thu, 18 Jul 2002 02:53:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The question more is, what do general implementations need > to implement. > In my opinion, general often equals robust. SHOULD does not mean > optional, it means you do it unless you have good reason > not to do it. > I think the burden of proof, then, would be the endpoint > which does not > implement a certain feature. => So are you saying should is ok? because that's all I'm saying. > I think that since HAO is used for security reasons, it may > have a strong > need to be a must than other functionality. Just my opinion. => The HAO is not needed for security reasons at all. All these arguments for SHOULD vs MUST are essentially because some people want to allow triangular routing _for_IPsec_protected_ traffic _only_. As I said a few mails back, the HAO is only accepted if the packet is protected by IPsec or if a BCE exists. Hesham > > John > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 17:55:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0tloN011646; Wed, 17 Jul 2002 17:55:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0tlRZ011645; Wed, 17 Jul 2002 17:55:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0tdoN011630; Wed, 17 Jul 2002 17:55:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02262; Wed, 17 Jul 2002 17:55:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19769; Wed, 17 Jul 2002 18:55:39 -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 RAA21860; Wed, 17 Jul 2002 17:55:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6I0tbt19812; Wed, 17 Jul 2002 17:55:37 -0700 X-mProtect: <200207180055> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUkNVME; Wed, 17 Jul 2002 17:55:33 PDT Message-ID: <3D361206.B601A9B0@iprg.nokia.com> Date: Wed, 17 Jul 2002 17:55:34 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mohan Parthasarathy CC: itojun@iijlab.net, Michael Thomas , john.loughney@nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <416B5AF360DED54088DAD3CA8BFBEA6EAB6B15@TNEXVS02.tahoenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk a new spec comes out. it has a lot of features. some of the features are very important for the protocol (otherwise the protocol does not work well). so we say all nodes have to implement these features. on the other hand, the new spec should not screw up the earlier implementations. are we in agreement with the above? it is nice to consider legacy nodes. But software upgrades are also very routine. I dont have a machine which is running the earliest version of Windows/FreeBSD/Linux/...... regards Vijay > Mohan Parthasarathy wrote: > > Vijay, > > I am missing something. Can we invent a new option in the future > and call it a MUST be processed by all nodes ? If a node does > not understand the option, it should use the icmp parameter > problem to return errors. Not sure why we need something special > for HAO. > > -mohan > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: Wednesday, July 17, 2002 5:24 PM > > To: itojun@iijlab.net > > Cc: Michael Thomas; john.loughney@nokia.com; > > keiichi@iij.ad.jp; mobile-ip@sunroof.eng.sun.com; > > ipng@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated > > > > > > itojun@iijlab.net wrote: > > > > > > >processing a HAO is simply replacing the source address with the > > > >contents of the HAO. earlier it is used to be a MUST without the > > > >verification step. IPv6 WG was okay with that. but people > > indentified > > > >some reflection attacks that are possible if you blindly accept > > > >unverified home address option. so now, it is a MUST with the > > > >verification step. > > > > > > IPv6 wg OKed HAO in draft 5 or 6. HAO changed a > > lot since then, > > > and i think it not reasonable for you to think that > > new-HAO is also > > > OKed automaticalliy. > > > > new-HAO?? the format has not changed. neither has the > > processing. it is still a destination option. how is it new? > > infact it has > > been made secure by the new verification step. > > > > infact, (IMO) there is no need for this new verification step > > if we have smart ingress filtering as described by Francis > > Dupont in > > http://www.ietf.org/internet-drafts/draft-dupont-ipv6-ingress- > filtering-00.txt. > Francis is probably around somewhere. can you please talk to him? > > Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 17:56:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0udoN011705; Wed, 17 Jul 2002 17:56:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0udN1011704; Wed, 17 Jul 2002 17:56:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0uWoN011691 for ; Wed, 17 Jul 2002 17:56:32 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11403; Wed, 17 Jul 2002 20:56:32 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g6I0uWZs015376; Wed, 17 Jul 2002 20:56:32 -0400 (EDT) Message-Id: <200207180056.g6I0uWZs015376@thunk.east.sun.com> From: Bill Sommerfeld To: Vijay Devarapalli cc: sommerfeld@east.sun.com, Michael Thomas , john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: Your message of "Wed, 17 Jul 2002 17:38:16 PDT." <3D360DF8.2B29D681@iprg.nokia.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 17 Jul 2002 20:56:32 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > the point is this verification can be done in many ways. but a correspondent node may only run services which won't benefit from route optimization (i.e,. "hit and run" short exchanges typical of a DNS server). Let's assume the measured binding cache hit rate is 0% for a particular server -- doens't it make sense from an efficiency standpoint to be able to disable the binding cache and the HAO verification on that server? - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 17:57:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0vXoN011790; Wed, 17 Jul 2002 17:57:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0vW9i011789; Wed, 17 Jul 2002 17:57:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0vQoN011779; Wed, 17 Jul 2002 17:57:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22786; Wed, 17 Jul 2002 17:57:27 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00646; Wed, 17 Jul 2002 17:57:26 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6I0v9v26566; Thu, 18 Jul 2002 02:57:09 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id CAA00793; Thu, 18 Jul 2002 02:57:10 +0200 (MET DST) 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 g6I0vAGF070550; Thu, 18 Jul 2002 02:57:10 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207180057.g6I0vAGF070550@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-reply-to: Your message of Wed, 17 Jul 2002 14:33:21 PDT. <3D35E2A1.18E60F30@iprg.nokia.com> Date: Thu, 18 Jul 2002 02:57:10 +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: > >it is. if a CN does not support HAO, it will send an ICMP error message > >pointing to the offending octet. when the MN receives this message, it > >starts reverse-tunneling through the Home Agent. where is the problem? > >if this is not clearly specified in the MIPv6 draft, it can be. the > >binding error functionality can also be substituted by an ICMP error. > >Binding Error was specified so that it is easier for the MN to figure > >out whats going on. > > then I see no reason for the MUST. I was discounting the reason (the already IPv6 installed base) you gave. the MUST is for newer IPv6 CN implementations. as I told you already, it makes the MN's life easier. but the current spec does ensure that a MN can still have a session with an old IPv6 implementation (which does not implement HAO) through reverse tunneling. so again, where is the problem? why are you against the MUST? => MUSTs are for interoperability problems, not for political matters. So Itojun is right and the fact that old IPv6 nodes still work with MNs proves the requirement should not be higher than SHOULD. Regards Francis.Dupont@enst-bretagne.fr PS: sorry but if someone is asking whether the RR/RO support should be mandatory I'll vote against it. And I can't see how the iETF will enforce it if I am being in the minority... (the topics has just been added to the ipv6 WG session agenda) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 17:57:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0vtoN011848; Wed, 17 Jul 2002 17:57:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I0vssU011847; Wed, 17 Jul 2002 17:57:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I0vkoN011825; Wed, 17 Jul 2002 17:57:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03204; Wed, 17 Jul 2002 17:57:47 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA20656; Wed, 17 Jul 2002 18:57:45 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3598C4B25; Thu, 18 Jul 2002 09:57:38 +0900 (JST) To: Vijay Devarapalli Cc: Mohan Parthasarathy , Michael Thomas , john.loughney@nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: vijayd's message of Wed, 17 Jul 2002 17:55:34 MST. <3D361206.B601A9B0@iprg.nokia.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: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Thu, 18 Jul 2002 09:57:38 +0900 Message-Id: <20020718005738.3598C4B25@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >it is nice to consider legacy nodes. But software upgrades >are also very routine. I dont have a machine which is running >the earliest version of Windows/FreeBSD/Linux/...... i don't think i have the same definition for "legacy" with you. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 18:01:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I11hoN012179; Wed, 17 Jul 2002 18:01:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I11h2m012176; Wed, 17 Jul 2002 18:01:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I11doN012160 for ; Wed, 17 Jul 2002 18:01:39 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02177 for ; Wed, 17 Jul 2002 18:01:40 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA25174 for ; Wed, 17 Jul 2002 19:01:40 -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 SAA22390; Wed, 17 Jul 2002 18:01:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6I11dJ06064; Wed, 17 Jul 2002 18:01:39 -0700 X-mProtect: <200207180101> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpds7FbmY; Wed, 17 Jul 2002 18:01:35 PDT Message-ID: <3D36136F.FCD1AA20@iprg.nokia.com> Date: Wed, 17 Jul 2002 18:01:35 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: Michael Thomas , john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <200207180056.g6I0uWZs015376@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Sommerfeld wrote: > > > the point is this verification can be done in many ways. > > but a correspondent node may only run services which won't benefit > from route optimization (i.e,. "hit and run" short exchanges typical > of a DNS server). > > Let's assume the measured binding cache hit rate is 0% for a > particular server -- doens't it make sense from an efficiency > standpoint to be able to disable the binding cache and the HAO > verification on that server? have you read the latest MIPv6 spec? there is an explicit code in the Binding Ack which says "Route Optimization unnecessary due to low traffic". the CN just has to refuse the binding with this code. the spec also says the MN should not run route optimization if the traffic is low/short. it can use its CoA. regards Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 18:09:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I19UoN012352; Wed, 17 Jul 2002 18:09:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I19UOk012351; Wed, 17 Jul 2002 18:09:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I19RoN012344 for ; Wed, 17 Jul 2002 18:09:27 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA13393; Wed, 17 Jul 2002 21:09:27 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g6I19RZs015503; Wed, 17 Jul 2002 21:09:27 -0400 (EDT) Message-Id: <200207180109.g6I19RZs015503@thunk.east.sun.com> From: Bill Sommerfeld To: Vijay Devarapalli cc: sommerfeld@east.sun.com, Michael Thomas , john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: Your message of "Wed, 17 Jul 2002 18:01:35 PDT." <3D36136F.FCD1AA20@iprg.nokia.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 17 Jul 2002 21:09:27 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > have you read the latest MIPv6 spec? I have, in fact read the spec. > there is an explicit code in the Binding Ack which says "Route > Optimization unnecessary due to low traffic". the CN just has to > refuse the binding with this code. So, existing nodes will reportedly refuse the binding with an "icmp parameter problem" message. Why do we need a second encoding for the same message? Isn't it better to just have one encoding? - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 18:12:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I1CboN012389; Wed, 17 Jul 2002 18:12:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I1CboW012386; Wed, 17 Jul 2002 18:12:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I1CUoN012370; Wed, 17 Jul 2002 18:12:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05406; Wed, 17 Jul 2002 18:12:31 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06648; Wed, 17 Jul 2002 18:12:31 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 21:07:05 -0400 Message-ID: From: Phil Roberts To: "'Francis Dupont'" , Vijay Devarapalli Cc: itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 17 Jul 2002 21:07:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A few issues have become mingled here. 1) Keiichi and others have raised the issue of MUST support for HAO and BE processing and have proposed a solution that allows communication to happen between any two nodes with clarification in the MIP spec of properly handling the ICMP errors returned. 2) There is a question about RO support requirements for all nodes. Actually the current spec doesn't give a recommendation for support of RO. If a node is supporting it, there are a bunch of MUSTs. We should make sure we agree as a working group on our consensus on these two issues. Perhaps we can sort this out on the MIP list first? > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Wednesday, July 17, 2002 8:57 PM > To: Vijay Devarapalli > Cc: itojun@iijlab.net; keiichi@iij.ad.jp; > mobile-ip@sunroof.eng.sun.com; > ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated > > > In your previous mail you wrote: > > > >it is. if a CN does not support HAO, it will send an > ICMP error message > > >pointing to the offending octet. when the MN receives > this message, it > > >starts reverse-tunneling through the Home Agent. where > is the problem? > > >if this is not clearly specified in the MIPv6 draft, it > can be. the > > >binding error functionality can also be substituted by > an ICMP error. > > >Binding Error was specified so that it is easier for > the MN to figure > > >out whats going on. > > > > then I see no reason for the MUST. > > I was discounting the reason (the already IPv6 installed base) you > gave. the MUST is for newer IPv6 CN implementations. as I told you > already, it makes the MN's life easier. but the current spec does > ensure that a MN can still have a session with an old IPv6 > implementation (which does not implement HAO) through reverse > tunneling. so again, where is the problem? why are you against the > MUST? > > => MUSTs are for interoperability problems, not for political matters. > So Itojun is right and the fact that old IPv6 nodes still work with > MNs proves the requirement should not be higher than SHOULD. > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: sorry but if someone is asking whether the RR/RO support should be > mandatory I'll vote against it. And I can't see how the iETF will > enforce it if I am being in the minority... > (the topics has just been added to the ipv6 WG session agenda) > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jul 17 18:25:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I1PRoN012557; Wed, 17 Jul 2002 18:25:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I1PRMF012556; Wed, 17 Jul 2002 18:25:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I1PNoN012549 for ; Wed, 17 Jul 2002 18:25:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08352 for ; Wed, 17 Jul 2002 18:25:25 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA00674; Wed, 17 Jul 2002 19:25:23 -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 SAA23749; Wed, 17 Jul 2002 18:25:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6I1PM426326; Wed, 17 Jul 2002 18:25:22 -0700 X-mProtect: <200207180125> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdymrhyk; Wed, 17 Jul 2002 18:25:20 PDT Message-ID: <3D361900.506E30A4@iprg.nokia.com> Date: Wed, 17 Jul 2002 18:25:20 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <200207180109.g6I19RZs015503@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Sommerfeld wrote: > > > have you read the latest MIPv6 spec? > > I have, in fact read the spec. > > > there is an explicit code in the Binding Ack which says "Route > > Optimization unnecessary due to low traffic". the CN just has to > > refuse the binding with this code. > > So, existing nodes will reportedly refuse the binding with an "icmp > parameter problem" message. Why do we need a second encoding for the > same message? Isn't it better to just have one encoding? are we mixing up route optimization and HAO? the first encoding is for earlier IPv6 implementations. the second encoding is for nodes (which normally support RO), that dont want to do RO currently for some reason. Vijay ps: I trimmed the cc list -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 19:14:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2EcoN012755; Wed, 17 Jul 2002 19:14:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2EcgX012754; Wed, 17 Jul 2002 19:14:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2EZoN012747; Wed, 17 Jul 2002 19:14:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16808; Wed, 17 Jul 2002 19:14:37 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13355; Wed, 17 Jul 2002 20:14:36 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id C96E26A905; Thu, 18 Jul 2002 05:14:35 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 55CCD6A906; Thu, 18 Jul 2002 05:14:32 +0300 (EEST) Message-ID: <3D36233F.9050700@kolumbus.fi> Date: Thu, 18 Jul 2002 05:09:03 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: itojun@iijlab.net Cc: Keiichi SHIMA / ??? , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020717140100.C4A734B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Itojun, > we have no way to force upgrade for all users of the existing IPv6 > stacks. therefore, i believe it very important for mobile-ip6 to be > defined so that: > - mobile-ip6 MN is interoperable with CN without HAO support, nor > binding error message support This is already the case. Draft 18 always work even with an IPv6 node that has no MIPv6 support. A CN that doesn't support RR will be sending back ICMP Parameter Problems, which we take in account. (In the current draft also shows a rather special case where HAO could be used without RO if an SA exists, but even in that case we would get an ICMP back and be able to act if the other side didn't support this.) By the way, this ability to support non-MIPv6 nodes is a new feature from a couple of months back, a consequence of protecting against certain security attacks. I really like this feature, and it should make new implementations quite good in the interoperability sense. So, technically everything works. But it's a separate question whether the IETF wants to mandate (SHOULD/MUST) some level of additional support, such as for the HAO or even for the RO. But regardless of whether such mandates are accepted or implemented, the protocol should technically work in all cases. If you can see a case where this would not be the case, please let as know and we'll fix it. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 19:25:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2PAoN012930; Wed, 17 Jul 2002 19:25:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2P6LG012929; Wed, 17 Jul 2002 19:25:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2P2oN012922; Wed, 17 Jul 2002 19:25:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA19579; Wed, 17 Jul 2002 19:25:04 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07512; Wed, 17 Jul 2002 20:25:03 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6I2OUv29036; Thu, 18 Jul 2002 04:24:30 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id EAA01531; Thu, 18 Jul 2002 04:24:30 +0200 (MET DST) 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 g6I2OTGF071088; Thu, 18 Jul 2002 04:24:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207180224.g6I2OTGF071088@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: itojun@iijlab.net, Michael Thomas , john.loughney@nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-reply-to: Your message of Wed, 17 Jul 2002 17:23:40 PDT. <3D360A8C.928E9CAD@iprg.nokia.com> Date: Thu, 18 Jul 2002 04:24:29 +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: new-HAO?? the format has not changed. neither has the processing. => this is not true, now the HAO must be verificable/verified. infact, (IMO) there is no need for this new verification step if we have smart ingress filtering as described by Francis Dupont in http://www.ietf.org/internet-drafts/draft-dupont-ipv6-ingress-filtering-00.txt. Francis is probably around somewhere. can you please talk to him? => this solution was rejected by the DT... In fact even the verification concept (from a Charlie Perkins' attempt to avoid mandatory BCE check) is at the margin of the DT decision. Regards Francis.Dupont@enst-bretagne.fr PS: I believe Pekka can summarize his ideas about CoA stuff at the alternate security of Mobile IPv6 bar BOF. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 19:33:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2XXoN013100; Wed, 17 Jul 2002 19:33:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2XX6q013099; Wed, 17 Jul 2002 19:33:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2XUoN013092 for ; Wed, 17 Jul 2002 19:33:30 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA21402 for ; Wed, 17 Jul 2002 19:33:32 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA24718 for ; Wed, 17 Jul 2002 20:33:31 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6I2Wvv29376; Thu, 18 Jul 2002 04:32:57 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id EAA01612; Thu, 18 Jul 2002 04:32:57 +0200 (MET DST) 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 g6I2WvGF071131; Thu, 18 Jul 2002 04:32:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207180232.g6I2WvGF071131@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: sommerfeld@east.sun.com, Michael Thomas , john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-reply-to: Your message of Wed, 17 Jul 2002 17:38:16 PDT. <3D360DF8.2B29D681@iprg.nokia.com> Date: Thu, 18 Jul 2002 04:32:57 +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: the point is processing of HAO gives you triangular routing, which is much better than reverse tunneling. => this battle was lost some months ago. You can even get some people who don't believe the Internet is a metric space (i.e., verifies the triangulat inequality)! anyway, I dont want to get into the argument, triangular routing Vs reverse tunneling. => so do I. 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 Jul 17 19:34:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2YooN013125; Wed, 17 Jul 2002 19:34:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2YoHC013124; Wed, 17 Jul 2002 19:34:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2YgoN013109; Wed, 17 Jul 2002 19:34:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA21718; Wed, 17 Jul 2002 19:34:44 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03404; Wed, 17 Jul 2002 19:34:43 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6I2Yfv29408; Thu, 18 Jul 2002 04:34:41 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id EAA01625; Thu, 18 Jul 2002 04:34:41 +0200 (MET DST) 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 g6I2YfGF071146; Thu, 18 Jul 2002 04:34:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207180234.g6I2YfGF071146@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: john.loughney@nokia.com cc: hesham.soliman@era.ericsson.se, mat@cisco.com, itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-reply-to: Your message of Thu, 18 Jul 2002 03:41:18 +0300. <0C1353ABB1DEB74DB067ADFF749C4EEFD38ECF@esebe004.NOE.Nokia.com> Date: Thu, 18 Jul 2002 04:34:41 +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: I think that since HAO is used for security reasons, it may have a strong need to be a must than other functionality. Just my opinion. => I disagree: HAO is only a tunnel optimization and is *not* used for security reasons. 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 Jul 17 19:36:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2aeoN013182; Wed, 17 Jul 2002 19:36:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2aes5013181; Wed, 17 Jul 2002 19:36:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2aaoN013174; Wed, 17 Jul 2002 19:36:37 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22174; Wed, 17 Jul 2002 19:36:39 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19124; Wed, 17 Jul 2002 19:36:38 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 8F9F06A906; Thu, 18 Jul 2002 05:36:37 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E92236A905; Thu, 18 Jul 2002 05:36:33 +0300 (EEST) Message-ID: <3D362A1E.3080101@kolumbus.fi> Date: Thu, 18 Jul 2002 05:38:22 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Keith Moore Cc: itojun@iijlab.net, Keiichi SHIMA / =?ISO-8859-1?Q?=3F=3F=3F?= , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <200207171531.g6HFVft12848@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > the purpose of a standard is to describe what is necessary for interoperability > and proper functioning of the protocol, not to legitimize existing > implementations. so the installed base shouldn't dictate whether a feature > is a MUST in a new version of a standard unless interoperability with the > installed base is important (it generally is) and imposing the MUST condition > on implementations that conform with the new version of the standard affects > interoperability with the installed base. Agree with all of the above. In this case, there are no interoperability problems. Since draft N-2 Mobile IPv6 has been able to work with IPv6 nodes that have *no* MIPv6 specific code. Again, this is separate from what the IETF may mandate for IPv6 nodes to support. To take a clearly unreasonable example, we could mandate every node to support a 1,000,000 entry bindind cache. Even with such a mandate a node conforming to this requirement would work with a node that has never heard of MIPv6. So, interoperability and must-implement are different in this particular case. I think that's good because we can then decide more freely what to require from all implementations. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 19:38:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2cAoN013298; Wed, 17 Jul 2002 19:38:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2cASI013297; Wed, 17 Jul 2002 19:38:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2c6oN013287; Wed, 17 Jul 2002 19:38:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22501; Wed, 17 Jul 2002 19:38:08 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA22744; Wed, 17 Jul 2002 20:38:06 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 266876A906; Thu, 18 Jul 2002 05:38:00 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0C9856A905; Thu, 18 Jul 2002 05:37:56 +0300 (EEST) Message-ID: <3D362A71.20606@kolumbus.fi> Date: Thu, 18 Jul 2002 05:39:45 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: Vijay Devarapalli , john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> <15669.60922.686205.742010@thomasm-u1.cisco.com> <3D35FF20.2E5FCADF@iprg.nokia.com> <15670.1003.493633.920465@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > I guess the long and short of this is that I'm > somewhat skeptical of putting general node > requirements in the MIP draft since it's > probably not the first place one would be > looking to figure out if they were an IPv6 > compliant node. If it's really, really vital > for the health of the net, yadda, yadda, it > would be better to put it in a general v6 node > requirements RFC, don't you think? That _is_ actually the intention. We tried to formulate section 8.2. (RO requirements) in the MIPv6 draft so that it describes what you have to do to support RO, but not when you have to support it. And we are expecting the node requirements document to say MAY/SHOULD/MUST for the RO feature. I think that's the right place to make the determination. Ok? Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 19:48:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2mjoN014036; Wed, 17 Jul 2002 19:48:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2mjnF014035; Wed, 17 Jul 2002 19:48:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2mgoN014026; Wed, 17 Jul 2002 19:48:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24434; Wed, 17 Jul 2002 19:48:44 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08433; Wed, 17 Jul 2002 19:48:43 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 980366A906; Thu, 18 Jul 2002 05:48:42 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2A9E26A905; Thu, 18 Jul 2002 05:48:38 +0300 (EEST) Message-ID: <3D362CF2.6070301@kolumbus.fi> Date: Thu, 18 Jul 2002 05:50:26 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: itojun@iijlab.net, Michael Thomas , john.loughney@nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020718001250.34F404B22@coconut.itojun.org> <3D360A8C.928E9CAD@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=2.4 required=5.0 tests=ONE_HUNDRED_PC_FREE version=2.20 X-Spam-Level: ** Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vijay Devarapalli wrote: > new-HAO?? the format has not changed. neither has the processing. > it is still a destination option. how is it new? infact it has > been made secure by the new verification step. The processing has changed in the sense that there is a new verification step. Basically, we don't accept unverified HAOs, either an SA or RR BCE must exist before they can be used. This limits in a sense the use of the HAO in a completely free way, as it used to be. (The most efficient routing case, RO, is of course still supported and that's what we hope will be used in most cases.) (Back in the old versions of the draft, HAO needed to be a MUST because otherwise interoperability would have failed.) Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 20:03:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I33XoN014284; Wed, 17 Jul 2002 20:03:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I33WmQ014283; Wed, 17 Jul 2002 20:03:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I33ToN014276; Wed, 17 Jul 2002 20:03:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA27187; Wed, 17 Jul 2002 20:03:32 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28134; Wed, 17 Jul 2002 20:03:31 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 6BFCE6A906; Thu, 18 Jul 2002 06:03:30 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DD5C66A905; Thu, 18 Jul 2002 06:03:25 +0300 (EEST) Message-ID: <3D36306A.3030808@kolumbus.fi> Date: Thu, 18 Jul 2002 06:05:14 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Pascal Thubert Cc: john.loughney@nokia.com, mat@cisco.com, vijayd@iprg.nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pascal Thubert wrote: > * Just as an FYI, I replied to the earlier mail because I am > >>trying to sort this out for the node requirements. I think >>that in MIPv6, it is OK that MIPv6 makes this recommendation (given >>working group consensus, IESG approval, etc.) but the Node Requirements >>document is the final word on the issue (assuming WG consensus, >>IESG approval, etc.). >> > > This issue seems to delay MIPv6 till the node requirement is out; so could we > not just recommend that the Mobile Node SHOULD use the reverse tunnel till some > part of the RR test is complete? If we do so, then a potential CN that fails to > respond to the CoT test would be considered as a legacy device and we would not > perform RO at all. My initial proposal is to negotiate the RO the following > way: This is what the spec has been saying for some time. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 20:58:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I3wwoN014527; Wed, 17 Jul 2002 20:58:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I3wwm9014526; Wed, 17 Jul 2002 20:58:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I3wtoN014519 for ; Wed, 17 Jul 2002 20:58:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11377 for ; Wed, 17 Jul 2002 20:58:58 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA15975 for ; Wed, 17 Jul 2002 21:58:56 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id MAA26033 for ; Thu, 18 Jul 2002 12:58:54 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA07936 for ; Thu, 18 Jul 2002 12:58:54 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA05217 for ; Thu, 18 Jul 2002 12:58:53 +0900 (JST) Date: Thu, 18 Jul 2002 13:01:30 +0900 (JST) Message-Id: <20020718.130130.46613392.kazu@iijlab.net> To: ipng@sunroof.eng.sun.com Subject: IPv6 Showcase, N+I 2002 Tokyo From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 3.0.55 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Some pictures of IPv6 Showcase, which were shown by Jun Murai today, are available from the following URL: http://www.sfc.wide.ad.jp/~say/n+i/ --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 21:12:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4CHoN014585; Wed, 17 Jul 2002 21:12:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I4CHbQ014584; Wed, 17 Jul 2002 21:12:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4C8oN014569; Wed, 17 Jul 2002 21:12:08 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12188; Wed, 17 Jul 2002 21:12:08 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18071; Wed, 17 Jul 2002 21:12:07 -0700 (PDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6I4Cci08693; Thu, 18 Jul 2002 07:12:38 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Jul 2002 07:12:06 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Jul 2002 07:12:06 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 18 Jul 2002 07:12:05 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65794@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIuByyL3HPCS9V9RJyUXIPriJqhyAACci5g To: , , Cc: , , , X-OriginalArrivalTime: 18 Jul 2002 04:12:06.0392 (UTC) FILETIME=[47373F80:01C22E11] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6I4C8oN014570 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pascal, > This issue seems to delay MIPv6 till the node requirement is > out; I disagree. I think that MIP WG should specify what it thinks is correct & documents it. If the documentation is good & reasons are sufficient, I don't think that supportting it in the Node Requirements document will be a problem. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 21:44:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4iroN014888; Wed, 17 Jul 2002 21:44:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I4irj1014887; Wed, 17 Jul 2002 21:44:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4iooN014880; Wed, 17 Jul 2002 21:44:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12940; Wed, 17 Jul 2002 21:44:51 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19912; Wed, 17 Jul 2002 22:44:50 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 65A756A906; Thu, 18 Jul 2002 07:44:49 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A5C656A905; Thu, 18 Jul 2002 07:44:44 +0300 (EEST) Message-ID: <3D364829.90806@kolumbus.fi> Date: Thu, 18 Jul 2002 07:46:33 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: pthubert@cisco.com, mat@cisco.com, vijayd@iprg.nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65794@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: > Hi Pascal, > > >>This issue seems to delay MIPv6 till the node requirement is >>out; >> > > I disagree. I think that MIP WG should specify what it thinks > is correct & documents it. If the documentation is good & > reasons are sufficient, I don't think that supportting it > in the Node Requirements document will be a problem. I agree with John on this. Note also that even if the final keyword would be found in the node requirements document, MIPv6 can still be deployed as soon as its spec is out. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 21:47:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4lxoN015014; Wed, 17 Jul 2002 21:47:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I4lwk1015013; Wed, 17 Jul 2002 21:47:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I4ltoN015006; Wed, 17 Jul 2002 21:47:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA13596; Wed, 17 Jul 2002 21:47:56 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20937; Wed, 17 Jul 2002 22:47:55 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 015FB6A906; Thu, 18 Jul 2002 07:47:54 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 294556A905; Thu, 18 Jul 2002 07:47:51 +0300 (EEST) Message-ID: <3D3648E4.8050701@kolumbus.fi> Date: Thu, 18 Jul 2002 07:49:40 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: mat@cisco.com, itojun@iijlab.net, keiichi@iij.ad.jp Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: summary of HAO, BE processing discussion References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578D@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm trying to summarize the discussion on the HAO and BE processing. Here's a few things that came up in the discussion: * MUSTs should be used only if interoperability is at danger, or if the health of the internet is in question even if protocols would operate correctly. * There will be existing IPv6 nodes that do not yet have MIPv6 support, and not all of them can be changed overnight when a new IPv6 RFC comes out. * The current MIPv6 protocol works technically even with non-MIPv6 nodes. The MNs will not normally attempt to use HAO without establishing a binding. If the CN does not support MIPv6 RR, it sends back an ICMPv6 parameter problem. And even if the MN went ahead and used HAO (as in with IPsec, for instance), the CN would also respond with a parameter problem. This is in the current draft*. * There are two potential node requirements from the MIPv6 functionality: - Route optimization, the main benefit (section 8.2) - Basic HAO supported, a subset of the above and used for HAO under IPsec with triangular routing (8.1). Includes also BEs. * The current draft does not state what the keyword is for the RO functionality (so far left for the node requirements team to decide, yet we intend to recommend something). The draft does say MUST for basic HAO support, however. * The IETF is free to decide what kind of requirement to place on nodes for these functions, since there are no interoperability concerns. * IPv6 WG has in the past accepted the HAO as a mandatory feature for all IPv6 nodes. Arguments have been made, however, that the processing of the HAO has been changed and the situation may now be different. * Arguments have been raised that the basic HAO support does not fullfil conditions to be a MUST. * Earlier discussions have looked upon what is the right level of support for RO. Proposals ranging from MAY to MUST were then mentioned, and arguments about congestion-like effects of non-optimal routing were used among others. Jari * A last call comment requested more text for the HAO-without-RO case. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 22:15:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5FfoN015279; Wed, 17 Jul 2002 22:15:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I5FLZd015278; Wed, 17 Jul 2002 22:15:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5FDoN015252; Wed, 17 Jul 2002 22:15:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA22433; Wed, 17 Jul 2002 22:15:14 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA21609; Wed, 17 Jul 2002 22:15:14 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 01:09:47 -0400 Message-ID: From: Phil Roberts To: "'Jari Arkko'" , mat@cisco.com, itojun@iijlab.net, keiichi@iij.ad.jp Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: summary of HAO, BE processing discussion Date: Thu, 18 Jul 2002 01:09:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk When the next version of the draft is issued, incorporating all the agreed resolutions of WG last call comments, we'll post a note to the ipng mailing list summarizing the requirements that the MIP WG is recommending. Phil > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Thursday, July 18, 2002 12:50 AM > To: mat@cisco.com; itojun@iijlab.net; keiichi@iij.ad.jp > Cc: mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > Subject: summary of HAO, BE processing discussion > > > > I'm trying to summarize the discussion on the HAO and BE > processing. > > Here's a few things that came up in the discussion: > > * MUSTs should be used only if interoperability is > at danger, or if the health of the internet is > in question even if protocols would operate > correctly. > > * There will be existing IPv6 nodes that do not > yet have MIPv6 support, and not all of them can > be changed overnight when a new IPv6 RFC comes out. > > * The current MIPv6 protocol works technically even > with non-MIPv6 nodes. The MNs will not normally > attempt to use HAO without establishing a binding. > If the CN does not support MIPv6 RR, it sends back > an ICMPv6 parameter problem. And even if the MN > went ahead and used HAO (as in with IPsec, for instance), > the CN would also respond with a parameter problem. > > This is in the current draft*. > > * There are two potential node requirements from the > MIPv6 functionality: > - Route optimization, the main benefit (section 8.2) > - Basic HAO supported, a subset of the above and > used for HAO under IPsec with triangular routing > (8.1). Includes also BEs. > > * The current draft does not state what the keyword > is for the RO functionality (so far left for the node > requirements team to decide, yet we intend to recommend > something). The draft does say MUST for basic > HAO support, however. > > * The IETF is free to decide what kind of requirement to > place on nodes for these functions, since there are > no interoperability concerns. > > * IPv6 WG has in the past accepted the HAO as a mandatory > feature for all IPv6 nodes. Arguments have been made, > however, that the processing of the HAO has been changed > and the situation may now be different. > > * Arguments have been raised that the basic HAO support does > not fullfil conditions to be a MUST. > > * Earlier discussions have looked upon what is the right > level of support for RO. Proposals ranging from MAY to > MUST were then mentioned, and arguments about congestion-like > effects of non-optimal routing were used among others. > > Jari > > * A last call comment requested more text for the HAO-without-RO case. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jul 17 22:20:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5KVoN015438; Wed, 17 Jul 2002 22:20:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I5KVfV015437; Wed, 17 Jul 2002 22:20:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5KLoN015415; Wed, 17 Jul 2002 22:20:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA18711; Wed, 17 Jul 2002 22:20:23 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA23539; Wed, 17 Jul 2002 22:20:22 -0700 (PDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA28494; Thu, 18 Jul 2002 14:20:21 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA28160; Thu, 18 Jul 2002 14:20:19 +0900 (JST) Date: Thu, 18 Jul 2002 14:18:50 +0900 (JST) Message-Id: <20020718.141850.32635405.keiichi@iij.ad.jp> To: jari.arkko@kolumbus.fi Cc: mat@cisco.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: summary of HAO, BE processing discussion From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3D3648E4.8050701@kolumbus.fi> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578D@esebe004.NOE.Nokia.com> <3D3648E4.8050701@kolumbus.fi> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Let me add one thing. From: Jari Arkko > * IPv6 WG has in the past accepted the HAO as a mandatory > feature for all IPv6 nodes. Arguments have been made, > however, that the processing of the HAO has been changed > and the situation may now be different. In addition, the current draft requires not only HAO but also BE. This means all IPv6 nodes must implement a new extention header (mobility header). I never say that such a mechanism is bad at all. It is good of course. But from the view of the fast deployment of both IPv6 and Mobile IPv6, I personally think it better not to require additional requirements... This is not the view of the protocol designer, though. I'm probablly a bad designer and a bad scientist. I just want a real IPv6 and a Mobile IPv6... Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 22:20:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5KZoN015441; Wed, 17 Jul 2002 22:20:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I5KZxe015440; Wed, 17 Jul 2002 22:20:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5KRoN015430 for ; Wed, 17 Jul 2002 22:20:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA29348 for ; Wed, 17 Jul 2002 22:20:29 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA02048 for ; Wed, 17 Jul 2002 23:20:28 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 544514B22; Thu, 18 Jul 2002 14:20:24 +0900 (JST) To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.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: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Thu, 18 Jul 2002 14:20:24 +0900 Message-Id: <20020718052024.544514B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk chairs, i would like to get some guidance on how to proceed with my document draft-itojun-ipv6-nodeinfo-revlookup-00.txt. i would like to publish it as an informational/experimental RFC. which wg is appropriate, or should i pursue it as individual submission? i understand pushbacks against icmpv6 node information query (which should be addressed separately), and against non-DNS name mapping in general. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 22:26:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5QJoN015672; Wed, 17 Jul 2002 22:26:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I5QJnL015671; Wed, 17 Jul 2002 22:26:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5QGoN015658 for ; Wed, 17 Jul 2002 22:26:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA24651 for ; Wed, 17 Jul 2002 22:26:18 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04480 for ; Wed, 17 Jul 2002 23:26:17 -0600 (MDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id GAA00915; Thu, 18 Jul 2002 06:26:16 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: ipng@sunroof.eng.sun.com Subject: Prefix Delegation Requirements and comparison From: Ole Troan Date: Thu, 18 Jul 2002 06:26:16 +0100 Message-ID: <7t5it3d61zb.fsf@mrwint.cisco.com> Lines: 39 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk with regards to the PD discussion after Miyakawa-san's presentation. I've added some requirements, and based on that started with a comparison. I haven't read the router renumbering spec lately, so please fill me in on that one. Mechanisms ---------- Router Renumbering RFC2894 ICMP PD draft-haberman-ipngwg-auto-prefix-02.txt DHCP PD draft-troan-dhcpv6-opt-prefix-delegation-01.txt PPP/IPV6CP option - Proxy-RA/Multi-link subnet draft-ietf-ipv6-multilink-subnets-00.txt RA option draft-lutchann-ipv6-delegate-option-00.txt Requirements: draft-miyakawa-ipv6-prefix-delegation-requirement-00.txt ------------- A. L2 independent B. Multi-access/Point to point C. Support for Renumbering D. Any prefix length can be delegated E. Authentication F. Negotiation, i.e requestor has a say G. Other configuration options, e.g DNS, NTP with the same mechanism H. Accounting (I did not understand this requirement) | A | B | C | D | E | F | G | H | ----------------------------------------------------- Router Renumbering| x | both| x | x | ? | - | - | | ICMP PD | x | both| x | x | ? | x | * | | DHCP PD | x | both| x | x | x | x | x | | PPP/IPV6CP option | - | p2p | - | x | x | ? | * | | Proxy-RA | x | p2p | x | - | - | - | * | | new RA option | x | p2p | x | x | - | - | * | | ----------------------------------------------------- x - supported - - not supported * - could be supported, but perhaps not a good fit i.e DNS options in IPV6CP -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 22:42:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5gsoN015831; Wed, 17 Jul 2002 22:42:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I5gsMN015830; Wed, 17 Jul 2002 22:42:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5gooN015820 for ; Wed, 17 Jul 2002 22:42:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA27584 for ; Wed, 17 Jul 2002 22:42:52 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA09451 for ; Wed, 17 Jul 2002 23:42:51 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 037FC4B22 for ; Thu, 18 Jul 2002 14:42:48 +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: draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt From: itojun@iijlab.net Date: Thu, 18 Jul 2002 14:42:47 +0900 Message-Id: <20020718054248.037FC4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk as mentioned in the meeting, we've submitted this revision to address IESG comment. I don't feel the need for another WG last call, so please send it forward to IESG. thanks. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 22:55:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5tFoN015871; Wed, 17 Jul 2002 22:55:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I5tFaq015870; Wed, 17 Jul 2002 22:55:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5tCoN015863 for ; Wed, 17 Jul 2002 22:55:12 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA07224 for ; Wed, 17 Jul 2002 22:55:14 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22336 for ; Wed, 17 Jul 2002 23:55:13 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6I5t3v02264; Thu, 18 Jul 2002 07:55:03 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id HAA02972; Thu, 18 Jul 2002 07:55:03 +0200 (MET DST) 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 g6I5t2GF071651; Thu, 18 Jul 2002 07:55:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207180555.g6I5t2GF071651@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ole Troan cc: ipng@sunroof.eng.sun.com Subject: Re: Prefix Delegation Requirements and comparison In-reply-to: Your message of Thu, 18 Jul 2002 06:26:16 BST. <7t5it3d61zb.fsf@mrwint.cisco.com> Date: Thu, 18 Jul 2002 07:55:02 +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: Mechanisms ---------- Router Renumbering RFC2894 ICMP PD draft-haberman-ipngwg-auto-prefix-02.txt DHCP PD draft-troan-dhcpv6-opt-prefix-delegation-01.txt => I believe this is the DHCPv6 option, there is a DHCPv6 subset too (no draft?). IMHO the subset is better because it should not give the funny current situation where nobody wants to use DHCPv6 for its main purpose, address allocation, but for PD, DNS discovery, etc. PPP/IPV6CP option - Proxy-RA/Multi-link subnet draft-ietf-ipv6-multilink-subnets-00.txt RA option draft-lutchann-ipv6-delegate-option-00.txt Requirements: draft-miyakawa-ipv6-prefix-delegation-requirement-00.txt ------------- A. L2 independent B. Multi-access/Point to point C. Support for Renumbering D. Any prefix length can be delegated E. Authentication F. Negotiation, i.e requestor has a say G. Other configuration options, e.g DNS, NTP with the same mechanism H. Accounting (I did not understand this requirement) => just think your are an ISP (accounting is the politically correct word for billing). | A | B | C | D | E | F | G | H | ----------------------------------------------------- Router Renumbering| x | both| x | x | ? | - | - | | ICMP PD | x | both| x | x | ? | x | * | | DHCP PD | x | both| x | x | x | x | x | | => the x in E here seems too much (DHCPv6 is well known to provide near no security (or please come with a security analysis of it). PPP/IPV6CP option | - | p2p | - | x | x | ? | * | | Proxy-RA | x | p2p | x | - | - | - | * | | new RA option | x | p2p | x | x | - | - | * | | ----------------------------------------------------- x - supported - - not supported * - could be supported, but perhaps not a good fit i.e DNS options in IPV6CP => I agree (DNS options in IPv6CP) but I'm afraid many disagree... 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 Jul 17 23:05:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I65moN016015; Wed, 17 Jul 2002 23:05:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I65m95016014; Wed, 17 Jul 2002 23:05:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I65ioN016007 for ; Wed, 17 Jul 2002 23:05:45 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA26509 for ; Wed, 17 Jul 2002 23:05:47 -0700 (PDT) Received: from delta.cs.mu.OZ.AU ([133.93.71.210]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07732 for ; Wed, 17 Jul 2002 23:05:46 -0700 (PDT) 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 g6I64e803043; Thu, 18 Jul 2002 15:04:40 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Francis Dupont cc: Ole Troan , ipng@sunroof.eng.sun.com Subject: Re: Prefix Delegation Requirements and comparison In-Reply-To: <200207180555.g6I5t2GF071651@givry.rennes.enst-bretagne.fr> References: <200207180555.g6I5t2GF071651@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Jul 2002 15:04:40 +0900 Message-ID: <3041.1026972280@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 18 Jul 2002 07:55:02 +0200 From: Francis Dupont Message-ID: <200207180555.g6I5t2GF071651@givry.rennes.enst-bretagne.fr> | => I believe this is the DHCPv6 option, there is a DHCPv6 subset too | (no draft?). IMHO the subset is better because it should not give | the funny current situation where nobody wants to use DHCPv6 for | its main purpose, address allocation, but for PD, DNS discovery, etc. DHCP is a "Host Configuration" protocol - it happens that with v4, the address is the most fundamental piece of required configuration, so DHCP is seen as an address assignment protocol. But host configuration is what it is called and that is what it is. For v6, address config can be done other ways, so it is entirely reasonable that DHCPv6 will come to be used for almost everything else, but that. That's OK. However, we certainly be assuming that everyone will run DHCP, that's one way to configure almost anything, but we always need the other way, for sites where there is no DHCP. 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 Jul 17 23:36:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I6aKoN016102; Wed, 17 Jul 2002 23:36:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I6aKfi016101; Wed, 17 Jul 2002 23:36:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I6aHoN016094 for ; Wed, 17 Jul 2002 23:36:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA07510 for ; Wed, 17 Jul 2002 23:36:18 -0700 (PDT) Received: from Mistralsoftware.com (ptil-243-146-ban.primus-india.net [203.196.146.243] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA06382 for ; Thu, 18 Jul 2002 00:36:14 -0600 (MDT) Received: from anji [192.168.15.19] by mistralsoftware.com [192.168.10.12] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Thu, 18 Jul 2002 12:20:41 +0530 Message-ID: <03ba01c22e25$4acd6e80$130fa8c0@anji> From: "Anjaneyulu" To: Subject: IPv6 MIB - ipv6IfDesc????? Date: Thu, 18 Jul 2002 12:05:21 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B7_01C22E53.644BAEC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.15.19 X-Return-Path: anjaneyulu@mistralsoftware.com X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_03B7_01C22E53.644BAEC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to know what exactly the variable ipv6IfDesc (interface = description)string in the ipv6 interface table will contain. Regards, Anj ------=_NextPart_000_03B7_01C22E53.644BAEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hi,
    I would like to know what exactly the = variable=20 ipv6IfDesc (interface description)string in the ipv6 = interface=20 table will contain.
     
    Regards,
    Anj
    ------=_NextPart_000_03B7_01C22E53.644BAEC0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 23:42:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I6g6oN016155; Wed, 17 Jul 2002 23:42:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I6g6hB016154; Wed, 17 Jul 2002 23:42:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I6fwoN016130; Wed, 17 Jul 2002 23:41:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03341; Wed, 17 Jul 2002 23:41:59 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28444; Thu, 18 Jul 2002 00:41:58 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 2007E6A906; Thu, 18 Jul 2002 09:41:57 +0300 (EEST) Received: from ericsson.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A80B76A905; Thu, 18 Jul 2002 09:41:44 +0300 (EEST) Message-ID: <3D36638E.3050803@ericsson.fi> Date: Thu, 18 Jul 2002 09:43:26 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: shima Cc: mat@cisco.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: summary of HAO, BE processing discussion References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578D@esebe004.NOE.Nokia.com> <3D3648E4.8050701@kolumbus.fi> <20020718.141850.32635405.keiichi@iij.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keiichi SHIMA wrote: > Let me add one thing. > > From: Jari Arkko > >>* IPv6 WG has in the past accepted the HAO as a mandatory >> feature for all IPv6 nodes. Arguments have been made, >> however, that the processing of the HAO has been changed >> and the situation may now be different. >> > > In addition, the current draft requires not only HAO but also BE. > This means all IPv6 nodes must implement a new extention header > (mobility header). Correct. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 17 23:42:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I6fxoN016133; Wed, 17 Jul 2002 23:41:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I6fxrE016131; Wed, 17 Jul 2002 23:41:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I6ftoN016123 for ; Wed, 17 Jul 2002 23:41:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18223 for ; Wed, 17 Jul 2002 23:41:56 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28424 for ; Thu, 18 Jul 2002 00:41:55 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6I6c7v03931; Thu, 18 Jul 2002 08:38:07 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id IAA03319; Thu, 18 Jul 2002 08:38:07 +0200 (MET DST) 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 g6I6c6GF071747; Thu, 18 Jul 2002 08:38:07 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207180638.g6I6c6GF071747@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert Elz cc: Ole Troan , ipng@sunroof.eng.sun.com Subject: Re: Prefix Delegation Requirements and comparison In-reply-to: Your message of Thu, 18 Jul 2002 15:04:40 +0900. <3041.1026972280@munnari.OZ.AU> Date: Thu, 18 Jul 2002 08:38:06 +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: | => I believe this is the DHCPv6 option, there is a DHCPv6 subset too | (no draft?). IMHO the subset is better because it should not give | the funny current situation where nobody wants to use DHCPv6 for | its main purpose, address allocation, but for PD, DNS discovery, etc. DHCP is a "Host Configuration" protocol - it happens that with v4, the address is the most fundamental piece of required configuration, so DHCP is seen as an address assignment protocol. => for me DHCP is the successor of BOOTP and the difference is in the way to assign addresses... but I won't argue about this. But host configuration is what it is called and that is what it is. => in our case it is far more than node configuration but only the name is not so good. For v6, address config can be done other ways, so it is entirely reasonable that DHCPv6 will come to be used for almost everything else, but that. That's OK. => it works but I can't qualify the situation of a large part of a protocol is only a burden for current uses as OK. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 00:23:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I7N9oN016412; Thu, 18 Jul 2002 00:23:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I7N8hU016411; Thu, 18 Jul 2002 00:23:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I7N5oN016404 for ; Thu, 18 Jul 2002 00:23:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA16068 for ; Thu, 18 Jul 2002 00:23:07 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27237 for ; Thu, 18 Jul 2002 01:23:06 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id AAA20795 for ; Thu, 18 Jul 2002 00:22:03 -0700 (MST)] Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id AAA08931 for ; Thu, 18 Jul 2002 00:23:05 -0700 (MST)] Received: from pobox.cstl.labs.mot.com (pobox.cstl.labs.mot.com [173.23.1.1]) by az33exr01.mot.com (8.11.6/8.11.6) with ESMTP id g6I7N3l23948 for ; Thu, 18 Jul 2002 02:23:03 -0500 Received: from motorola.com ([216.1.110.206]) by pobox.cstl.labs.mot.com (Netscape Messaging Server 4.15) with ESMTP id GZFOID00.IFQ for ; Thu, 18 Jul 2002 02:23:01 -0500 Message-ID: <3D366CD3.A574DB1C@motorola.com> Date: Thu, 18 Jul 2002 02:22:59 -0500 From: "Aaron M. Smith" Reply-To: aaron.m.smith@motorola.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Subject: Re: Prefix Delegation Requirements and comparison References: <7t5it3d61zb.fsf@mrwint.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ole Troan wrote: > with regards to the PD discussion after Miyakawa-san's presentation. > I've added some requirements, and based on that started with a > comparison. I haven't read the router renumbering spec lately, so > please fill me in on that one. > > Mechanisms > ---------- > Router Renumbering RFC2894 > ICMP PD draft-haberman-ipngwg-auto-prefix-02.txt > DHCP PD draft-troan-dhcpv6-opt-prefix-delegation-01.txt > PPP/IPV6CP option - > Proxy-RA/Multi-link subnet draft-ietf-ipv6-multilink-subnets-00.txt > RA option draft-lutchann-ipv6-delegate-option-00.txt > > Requirements: > draft-miyakawa-ipv6-prefix-delegation-requirement-00.txt > ------------- > A. L2 independent > B. Multi-access/Point to point I'm glad to see interest in generalizing beyond just the point-to-point case. I'd like to have a solution that allows the requesting router to be more than one hop away from the prefix delegator. This would be useful for deploying large scale networks. This isn't a requirement for the isp-home scenario that needs a solution in the short term, but if the solution chosen for that is useful for the large network deployment scenario, so much the better. > > C. Support for Renumbering > D. Any prefix length can be delegated > E. Authentication > F. Negotiation, i.e requestor has a say > G. Other configuration options, e.g DNS, NTP with the same mechanism > H. Accounting (I did not understand this requirement) > > | A | B | C | D | E | F | G | H | > ----------------------------------------------------- > Router Renumbering| x | both| x | x | ? | - | - | | > ICMP PD | x | both| x | x | ? | x | * | | > DHCP PD | x | both| x | x | x | x | x | | > PPP/IPV6CP option | - | p2p | - | x | x | ? | * | | > Proxy-RA | x | p2p | x | - | - | - | * | | > new RA option | x | p2p | x | x | - | - | * | | > ----------------------------------------------------- > > x - supported > - - not supported > * - could be supported, but perhaps not a good fit i.e DNS options in IPV6CP > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jul 18 00:23:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I7NZoN016422; Thu, 18 Jul 2002 00:23:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I7NYoZ016421; Thu, 18 Jul 2002 00:23:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I7NUoN016414 for ; Thu, 18 Jul 2002 00:23:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA16097 for ; Thu, 18 Jul 2002 00:23:31 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21314 for ; Thu, 18 Jul 2002 00:23:30 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 07D314B22; Thu, 18 Jul 2002 16:23:26 +0900 (JST) To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-reply-to: itojun's message of Thu, 18 Jul 2002 14:20:24 +0900. <20020718052024.544514B22@coconut.itojun.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: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Thu, 18 Jul 2002 16:23:25 +0900 Message-Id: <20020718072326.07D314B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > chairs, > i would like to get some guidance on how to proceed with my document > draft-itojun-ipv6-nodeinfo-revlookup-00.txt. i would like to publish > it as an informational/experimental RFC. which wg is appropriate, > or should i pursue it as individual submission? > > i understand pushbacks against icmpv6 node information query > (which should be addressed separately), and against non-DNS name > mapping in general. just to make sure - i don't mean to replace PTR with it, it can be used together with PTR. it is an interesting situation if you get answer from both, but anyway... 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 Jul 18 00:27:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I7RsoN016472; Thu, 18 Jul 2002 00:27:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I7Rsjs016471; Thu, 18 Jul 2002 00:27:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I7RpoN016464 for ; Thu, 18 Jul 2002 00:27:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA29004 for ; Thu, 18 Jul 2002 00:27:52 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (ietf-terminal-dhcp-13-221.dyn.ietf54.wide.ad.jp [133.93.13.221]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07402 for ; Thu, 18 Jul 2002 00:27:52 -0700 (PDT) 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 g6I7Qc803319; Thu, 18 Jul 2002 16:26:44 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Francis Dupont cc: Ole Troan , ipng@sunroof.eng.sun.com Subject: Re: Prefix Delegation Requirements and comparison In-Reply-To: <200207180638.g6I6c6GF071747@givry.rennes.enst-bretagne.fr> References: <200207180638.g6I6c6GF071747@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Jul 2002 16:26:38 +0900 Message-ID: <3317.1026977198@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 18 Jul 2002 08:38:06 +0200 From: Francis Dupont Message-ID: <200207180638.g6I6c6GF071747@givry.rennes.enst-bretagne.fr> | => it works but I can't qualify the situation of a large part of | a protocol is only a burden for current uses as OK. No question but that DHCP is a fairly heavy protocol - but that's at the server end, and only needed if you actually want to use managed address assignment. If you do want that on your net, then all of that baggage is required. >From the client point of view, using DHCP to get DNS server info, or anything else like that is pretty lightweight, the rest of the protocol can largely be ignored. Even doing the client side of DHCP for address assignment isn't all that burdensome. So, it seems to me that there isn't much of an issue here really. Note: I still don't believe that anyone should be required to use DHCP (with or without the address assignment part) if they don't want to - but on a net where the administrators want that level of control, nodes should do the right thing and co-operate. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 01:14:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I8E6oN016580; Thu, 18 Jul 2002 01:14:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I8E6uh016579; Thu, 18 Jul 2002 01:14:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I8E3oN016572 for ; Thu, 18 Jul 2002 01:14:03 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25468 for ; Thu, 18 Jul 2002 01:14:05 -0700 (PDT) Received: from argos.cerberus.ch (argos.cerberus.ch [193.5.45.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27693 for ; Thu, 18 Jul 2002 01:14:04 -0700 (PDT) Received: from localhost (localhost [[UNIX: localhost]]) by argos.cerberus.ch (8.11.0/8.11.0) with SMTP id g6I8GH131711 for ; Thu, 18 Jul 2002 10:16:17 +0200 (MET DST) Received: from chmanexch05.man.ch.cerberus.ch (chmanexch05.man.ch.cerberus.ch [193.5.44.66]) by chmanappl08.man.ch.cerberus.ch (Build 98 8.9.3/NT-8.9.3) with ESMTP id JAA27083 for ; Thu, 18 Jul 2002 09:13:50 +0100 Received: by chmanexch55.man.ch.cerberus.ch with Internet Mail Service (5.5.2653.19) id <3P7Z9CJS>; Thu, 18 Jul 2002 10:14:02 +0200 Message-ID: From: "Kalonov Bahrom (Kab)" To: "'ipng@sunroof.eng.sun.com'" Subject: Date: Thu, 18 Jul 2002 10:14:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Test only -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 01:58:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I8wGoN016953; Thu, 18 Jul 2002 01:58:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I8wG1A016952; Thu, 18 Jul 2002 01:58:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I8wDoN016945 for ; Thu, 18 Jul 2002 01:58:13 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02927 for ; Thu, 18 Jul 2002 01:58:15 -0700 (PDT) Received: from purgatory.unfix.org (cust.92.136.adsl.cistron.nl [195.64.92.136]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03432 for ; Thu, 18 Jul 2002 01:58:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 03F3882B9; Thu, 18 Jul 2002 10:58:16 +0200 (CEST) Received: from cyan (mail.azr.nl [::ffff:156.83.254.8]) by purgatory.unfix.org (Postfix) with ESMTP id DF6F3775E; Thu, 18 Jul 2002 10:58:06 +0200 (CEST) From: "Jeroen Massar" To: , , Subject: RE: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Date: Thu, 18 Jul 2002 10:56:06 +0200 Organization: Unfix Message-ID: <000401c22e38$f50dbe00$534510ac@cyan> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20020718072326.07D314B22@coconut.itojun.org> X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Razor-id: 07e196b06471616708d9980765f13f0d76740a71 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > chairs, > > i would like to get some guidance on how to proceed with my document > > draft-itojun-ipv6-nodeinfo-revlookup-00.txt. i would like to publish > > it as an informational/experimental RFC. which wg is appropriate, > > or should i pursue it as individual submission? > > > > i understand pushbacks against icmpv6 node information query > > (which should be addressed separately), and against non-DNS name > > mapping in general. > > just to make sure - i don't mean to replace PTR with > it, it can be used together with PTR. it is an interesting situation > if you get answer from both, but anyway... One application for this could be a reverse dnsserver who doesn't know the PTR for a certain IPv6 address it serves the delegation for. It could then send this icmp nodeinfo request to the endpoint, which is very probably quite close networkwise and use that as a response. Ofcourse it could check first if the forward exists and/or that the reverse matches a specified set of host/domainnames. Ofcourse this setting depends on the operator of the dns and network. But IMHO it's easier to implement as it either avoids one to setup a dhcp server to update the reverse zone or to distribute the keys for secure reverse dns updates. Greets, Jeroen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 03:09:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IA9WoN017248; Thu, 18 Jul 2002 03:09:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IA9WCo017247; Thu, 18 Jul 2002 03:09:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IA9SoN017240 for ; Thu, 18 Jul 2002 03:09:28 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05467 for ; Thu, 18 Jul 2002 03:09:28 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29007 for ; Thu, 18 Jul 2002 04:09:27 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GZF00A8IW7QY5@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 18 Jul 2002 04:09:27 -0600 (MDT) Received: from limande.dyn.ietf54.wide.ad.jp ([133.93.76.228]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GZF001N2W7NQ7@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 18 Jul 2002 04:09:26 -0600 (MDT) Date: Thu, 18 Jul 2002 12:09:24 +0200 From: Alain Durand Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-reply-to: <000401c22e38$f50dbe00$534510ac@cyan> To: Jeroen Massar Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: <6F697FCE-9A36-11D6-BE89-000393764158@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, July 18, 2002, at 10:56 AM, Jeroen Massar wrote: > One application for this could be a reverse dnsserver who doesn't know > the > PTR for a certain IPv6 address it serves the delegation for. It could > then > send this icmp nodeinfo request to the endpoint, which is very probably > quite > close networkwise and use that as a response I'm sure this will lead to very interesting results when a secondary server will try to resolve the reverse for site local addresses.... - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 03:52:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IAq0oN017306; Thu, 18 Jul 2002 03:52:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IAq0Lv017305; Thu, 18 Jul 2002 03:52:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IApvoN017298 for ; Thu, 18 Jul 2002 03:51:57 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15013 for ; Thu, 18 Jul 2002 03:51:57 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15100 for ; Thu, 18 Jul 2002 04:51:57 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6IApqv28858; Thu, 18 Jul 2002 12:51:53 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA05277; Thu, 18 Jul 2002 12:51:53 +0200 (MET DST) 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 g6IAppGF072239; Thu, 18 Jul 2002 12:51:52 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207181051.g6IAppGF072239@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: aaron.m.smith@motorola.com cc: ipng@sunroof.eng.sun.com Subject: Re: Prefix Delegation Requirements and comparison In-reply-to: Your message of Thu, 18 Jul 2002 02:22:59 CDT. <3D366CD3.A574DB1C@motorola.com> Date: Thu, 18 Jul 2002 12:51:51 +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: > B. Multi-access/Point to point I'm glad to see interest in generalizing beyond just the point-to-point case. I'd like to have a solution that allows the requesting router to be more than one hop away from the prefix delegator. => this is in fact supported by the same protocols that support multi-access. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 04:19:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IBJdoN017361; Thu, 18 Jul 2002 04:19:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IBJdH8017360; Thu, 18 Jul 2002 04:19:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IBJaoN017353 for ; Thu, 18 Jul 2002 04:19:36 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA25279 for ; Thu, 18 Jul 2002 04:19:37 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14647 for ; Thu, 18 Jul 2002 04:19:36 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6IBG9v30907; Thu, 18 Jul 2002 13:16:09 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA05454; Thu, 18 Jul 2002 13:16:09 +0200 (MET DST) 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 g6IBG8GF072312; Thu, 18 Jul 2002 13:16:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207181116.g6IBG8GF072312@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert Elz cc: Ole Troan , ipng@sunroof.eng.sun.com Subject: Re: Prefix Delegation Requirements and comparison In-reply-to: Your message of Thu, 18 Jul 2002 16:26:38 +0900. <3317.1026977198@munnari.OZ.AU> Date: Thu, 18 Jul 2002 13:16:08 +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: | => it works but I can't qualify the situation of a large part of | a protocol is only a burden for current uses as OK. No question but that DHCP is a fairly heavy protocol - but that's at the server end, and only needed if you actually want to use managed address assignment. If you do want that on your net, then all of that baggage is required. => my concern is about the managed address assignement: it can be needed for IPv4 where addresses are rare resources but *not* for IPv6 where there are 2^64 addresses available per link. You can believe in address registration for management, etc, but the reuse of DHCP in the IPv6 world lead to a heavy protocol with a totally useless main function, so I am *not* happy with this! Note: I still don't believe that anyone should be required to use DHCP (with or without the address assignment part) if they don't want to - but on a net where the administrators want that level of control, nodes should do the right thing and co-operate. => address assignment is not the good way to manage an IPv6 network, address registration is simpler so better. Unfortunately my efforts in the past (when I believed DHCPv6 should be used for itself :-) to add this function in DHCPv6 failed... so we get a protocol which shall not be fully implemented by major implementors (cf. KAME and Microsoft) and is already in its 27th version after 7 years! Regards Francis.Dupont@enst-bretagne.fr PS: I wasted in large amount of manpower in DHCPv6 implementations but I lost my trust in the future of DHCPv6 when it was harshly rejected at the Redmond IPv6 interim meeting for prefix delegation. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 04:56:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IBuUoN017417; Thu, 18 Jul 2002 04:56:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IBuTYN017416; Thu, 18 Jul 2002 04:56:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IBuQoN017409 for ; Thu, 18 Jul 2002 04:56:26 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20983 for ; Thu, 18 Jul 2002 04:56:27 -0700 (PDT) Received: from byd.ocn.ad.jp (byd.ocn.ad.jp [203.139.162.147]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08233 for ; Thu, 18 Jul 2002 05:56:26 -0600 (MDT) Received: from ty (byd.ocn.ad.jp [203.139.162.147]) by byd.ocn.ad.jp (8.8.8/3.6W) with SMTP id UAA28873; Thu, 18 Jul 2002 20:56:19 +0900 (JST) Message-ID: <00eb01c22e52$1f6a6ea0$1900a8c0@ty> From: "Toshi Yamasaki" To: "Ole Troan" Cc: References: <7t5it3d61zb.fsf@mrwint.cisco.com> Subject: Re: Prefix Delegation Requirements and comparison Date: Thu, 18 Jul 2002 20:55:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ole, Thank you for your good summary and check list. > H. Accounting (I did not understand this requirement) This means "ISPs often want to log WHO used WHICH prefix from WHAT TIME to WHAT TIME for to calculate fees or track who was abusing, and so on". So your check list wil be: | A | B | C | D | E | F | G | H | ----------------------------------------------------- Router Renumbering| x | both| x | x | ? | - | - | ? | ICMP PD | x | both| * | x | ? | x | * | x | DHCP PD | x | both| x | x | x | x | x | x | PPP/IPV6CP option | - | p2p | - | x | x | ? | * | x | Proxy-RA | x | p2p | x | - | - | - | * | - | new RA option | x | p2p | x | x | - | - | * | - | ----------------------------------------------------- BTW, I like the idea of Proxy-RA(very primitive MSR?), but it is accurately not a method for prefix "delegation" but for prefix "advertisement". IMO, - DHCP PD is the best for prefix delegation, where PE delegates prefix(es) to subnet(s) behind CPE - RA-proxy (or MSR) is the best for prefix advertisement, where PE advertise prefix(es) to a subnet which is shared the PE-CPE link and links behind CPE Here are my comments for each proposal: - RR: Can we use it for over-site renumbering? I noticed many panelists at IESG plenary said they don't know where to use RR - ICMP PD: I loved it, but it's quite similar to DHCP PD for now. Many implementors said it's easier to implement DHCP PD than ICMP PD, because the draft is more mature. - DHCP PD: I love it now :-) It satisfies the most requirements for us, who want to start IPv6 access services tomorrow. I saw many running codes are working with no problem. - PPP/IPV6CP: Not bad. But we need another protocol when not using PPP, anyway. - Proxy-RA: I love it for MSR enviroments as I wrote above. - new RA option: Too limited. Can be available only for P2P lnk, no method for accounting and tracking. --- Toshi Yamasaki / NTT Communications > with regards to the PD discussion after Miyakawa-san's presentation. > I've added some requirements, and based on that started with a > comparison. I haven't read the router renumbering spec lately, so > please fill me in on that one. > > Mechanisms > ---------- > Router Renumbering RFC2894 > ICMP PD draft-haberman-ipngwg-auto-prefix-02.txt > DHCP PD draft-troan-dhcpv6-opt-prefix-delegation-01.txt > PPP/IPV6CP option - > Proxy-RA/Multi-link subnet draft-ietf-ipv6-multilink-subnets-00.txt > RA option draft-lutchann-ipv6-delegate-option-00.txt > > Requirements: > draft-miyakawa-ipv6-prefix-delegation-requirement-00.txt > ------------- > A. L2 independent > B. Multi-access/Point to point > C. Support for Renumbering > D. Any prefix length can be delegated > E. Authentication > F. Negotiation, i.e requestor has a say > G. Other configuration options, e.g DNS, NTP with the same mechanism > H. Accounting (I did not understand this requirement) > > | A | B | C | D | E | F | G | H | > ----------------------------------------------------- > Router Renumbering| x | both| x | x | ? | - | - | | > ICMP PD | x | both| x | x | ? | x | * | | > DHCP PD | x | both| x | x | x | x | x | | > PPP/IPV6CP option | - | p2p | - | x | x | ? | * | | > Proxy-RA | x | p2p | x | - | - | - | * | | > new RA option | x | p2p | x | x | - | - | * | | > ----------------------------------------------------- > > x - supported > - - not supported > * - could be supported, but perhaps not a good fit i.e DNS options in IPV6CP > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jul 18 05:06:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IC6IoN017451; Thu, 18 Jul 2002 05:06:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IC6IQ4017450; Thu, 18 Jul 2002 05:06:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IC6FoN017443 for ; Thu, 18 Jul 2002 05:06:15 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29314 for ; Thu, 18 Jul 2002 05:06:16 -0700 (PDT) Received: from purgatory.unfix.org (cust.92.136.adsl.cistron.nl [195.64.92.136]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12102 for ; Thu, 18 Jul 2002 06:06:15 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 286C58577; Thu, 18 Jul 2002 14:06:12 +0200 (CEST) Received: from cyan (mail.azr.nl [::ffff:156.83.254.8]) by purgatory.unfix.org (Postfix) with ESMTP id C4A3A84C3; Thu, 18 Jul 2002 14:05:59 +0200 (CEST) From: "Jeroen Massar" To: "'Alain Durand'" Cc: , , Subject: RE: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Date: Thu, 18 Jul 2002 14:03:59 +0200 Organization: Unfix Message-ID: <001e01c22e53$3594e970$534510ac@cyan> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <6F697FCE-9A36-11D6-BE89-000393764158@sun.com> X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Razor-id: cb90314a12585ea6eb60b4a05529fb3ead57a776 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain Durand wrote: > On Thursday, July 18, 2002, at 10:56 AM, Jeroen Massar wrote: > > One application for this could be a reverse dnsserver who doesn't know > > the > > PTR for a certain IPv6 address it serves the delegation for. It could > > then > > send this icmp nodeinfo request to the endpoint, which is very probably > > quite > > close networkwise and use that as a response > > I'm sure this will lead to very interesting results when > a secondary server will try to resolve the reverse > for site local addresses.... That would give very interresting results indeed, so let's add the fact that it for example BIND have to be configged for such a delegation like: zone "4.2.0.0.0.0.2.4.1.1.8.e.f.f.3.ip6.int" { type ipv6nodeinfo; allow_names "*.unfix.org"; check_forward yes; }; This would then tell BIND to do nodeinfo queries for 3ffe:8114:2000:240::/60. The responses should match a host in the unfix.org domain and the forward mapping should match this reverse mapping *). Another reason for limiting this behaviour is that it indeed avoids the reverse-site-local problem. This is just a IMHO neat trick in your dnsserver just like the other solutions/examples mentioned for autogeneration of the reverse, except this could/should probably give a more meaningfull response in regard to RFC1178. One could do this in one go for all their customer which will come from mostly the same prefix avoiding the problem of giving every customer the control of the complete reverse delegation with regard to ddnsupdates and also avoids the fact that if they turn on 10000 boxes your dnsserver gets 10000 updates of which maybe 1000 get their reverse requested. Note also that IPv6 supports the anonymous address which will change in a timeframe of X and thus an IP in use by one box at time Z could be a completely different box at time Y. If I remember correctly those anonymous addresses had a certain bit set, resolver software should probably avoid trying to resolve these addresses at all, they aren't anonymous for a reason after all ;) Greets, Jeroen *) The forward zone, in the example unfix.org is in hands of the delegated person/company/customer and thus they can make their own policy of setting up Secure Dynamic DNS updates with all the work around that. Or simply setup a Win2k+ Server box which does it with Kerberos auth in the domain (GSS-API) or similar solutions. btw... my win2k box uses bind9-win32's nsupdate in the same fashion as the unix boxes to automatically update it's forward mapping (A+AAAA) to a bind dnsserver. A good thing there is unxutils ;) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 06:04:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ID4AoN017769; Thu, 18 Jul 2002 06:04:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ID4Ahp017768; Thu, 18 Jul 2002 06:04:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ID46oN017761 for ; Thu, 18 Jul 2002 06:04:06 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03545 for ; Thu, 18 Jul 2002 06:04:08 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04620 for ; Thu, 18 Jul 2002 07:04:07 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GZG00AJ04ATY5@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 18 Jul 2002 07:04:07 -0600 (MDT) Received: from limande.dyn.ietf54.wide.ad.jp ([133.93.76.228]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GZG00C144AP4W@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 18 Jul 2002 07:04:04 -0600 (MDT) Date: Thu, 18 Jul 2002 15:04:00 +0200 From: Alain Durand Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-reply-to: <001e01c22e53$3594e970$534510ac@cyan> To: Jeroen Massar Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, July 18, 2002, at 02:03 PM, Jeroen Massar wrote: > That would give very interresting results indeed, so let's add > the fact > that it for example BIND have to be configged for such a delegation > like: > > zone "4.2.0.0.0.0.2.4.1.1.8.e.f.f.3.ip6.int" { > type ipv6nodeinfo; > allow_names "*.unfix.org"; > check_forward yes; > }; > > This would then tell BIND to do nodeinfo queries for > 3ffe:8114:2000:240::/60. This approach will work for the reverse mapping of Site Local addresses if and only if the primary server and all its secondary are all in the _same_ site local zone. If not the ICMP will go to the wrong place... - 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 Jul 18 06:34:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IDY9oN017852; Thu, 18 Jul 2002 06:34:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IDY9YG017851; Thu, 18 Jul 2002 06:34:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IDY5oN017844 for ; Thu, 18 Jul 2002 06:34:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18396 for ; Thu, 18 Jul 2002 06:34:07 -0700 (PDT) Received: from delta.cs.mu.OZ.AU ([133.93.71.210]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06643 for ; Thu, 18 Jul 2002 07:34:06 -0600 (MDT) 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 g6IDWk808177; Thu, 18 Jul 2002 22:33:02 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Francis Dupont cc: Ole Troan , ipng@sunroof.eng.sun.com Subject: Re: Prefix Delegation Requirements and comparison In-Reply-To: <200207181116.g6IBG8GF072312@givry.rennes.enst-bretagne.fr> References: <200207181116.g6IBG8GF072312@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Jul 2002 22:32:46 +0900 Message-ID: <8175.1026999166@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 18 Jul 2002 13:16:08 +0200 From: Francis Dupont Message-ID: <200207181116.g6IBG8GF072312@givry.rennes.enst-bretagne.fr> | => address assignment is not the good way to manage an IPv6 network, | address registration is simpler so better. This depends what kind of net you're attempting to run, and how. Inside my house, I might want to group various different pieces of furniture on the LAN into related address groups. This allows me to write firewall rules easily to grant similar access to all of the chairs, without having to identify each one (they'll come from different manufacturers, so the EUI won't help group them). In this kind of environment I can be fairly confident that one of the chairs isn't going to decide to simply configure itself a different address to side-step my policies. So as long as all the furniture talks to my server to have its address allocated, I can assign addresses that match my policies, and have the firewalls simply apply the correct policies as soon as the node becomes active. Certainly, address registration can be useful as well - but that's not a configuration function, it is a post configuration function, so arguably belongs elsewhere. And also, certainly, not all nets require all of this administrative baggage, and so it needs to be possible to run a net with no DHCP servers at all. So, while as an interim measure until we get something better, doing some of the missing "extra" config using DHCP, and not providing any alternative that really works might be acceptable, longer term, we need methods for all of this that works (which means not well known addresses, of any kind) without requiring anything like DHCP. 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 Jul 18 06:35:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IDZ5oN017870; Thu, 18 Jul 2002 06:35:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IDZ5mc017869; Thu, 18 Jul 2002 06:35:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IDZ0oN017855; Thu, 18 Jul 2002 06:35:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09002; Thu, 18 Jul 2002 06:35:02 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18606; Thu, 18 Jul 2002 07:35:01 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 5A0996A907; Thu, 18 Jul 2002 16:35:00 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5E1556A908; Thu, 18 Jul 2002 16:34:56 +0300 (EEST) Message-ID: <3D36A53F.4070106@kolumbus.fi> Date: Thu, 18 Jul 2002 14:23:43 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Pascal Thubert Cc: keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: summary of HAO, BE processing discussion References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pascal Thubert wrote: > I think I've been a little cryptic: > > Some devices such as a fridge may be happy to have a minimum set of requirements > for IPv6. Other devices such as clustered servers may not be able to maintain a > BCE at all because the cluster IP address is shared among all the members of the > cluster -- unless they perform a new protocol to distribute the BCEs-. > Furthermore, if the cluster uses a dispatcher that is not on the return path, > then the dispatcher cannot provide the MIP termination, either. However, if that > same dispatcher terminates an IPSEC tunnel, or by other means to be defined > later such as piggy backing, it could be possible to trust a Home address option > and perform triangular routing. > > Using a Binding Cache as opposed to piggy backing the BU with each packet > assumes that memory scales better than CPU. This seems a reasonable approach, so > does delaying the support of piggybacking. But still, we must allow for the case > where this trade-off does not apply. Say the dispatcher I just mentioned has a > hardware accelerated crypto engine; say it can cache some recent computations in > a LRU fashion; say it has limited memory capabilities to keep many BCEs long > term; and say it needs to serve requests for a huge amount of unrelated users; > in that case, the trade-off is the wrong choice, and triangular may be the best > can do, unless the client sources its requests with its CoA, which leads to more > open issues. MUSTing a Binding Cache in IPv6 outlaws this configuration de > facto. > > If we agree that there can be several levels of support by the CN for RO, then > we could define what the behaviour is for each level and how to negotiate that > between the CN and the MN. My suggestion was to do that negotiation at RR test > time so that no bind support would be necessary unless both parties agree upon > bi-directional route optimization. > > A way to perform that negotiation is to give a meaning to the response to HoTi > and CoTi. This may be achieved by adding negative Return Code to Hot Cot, and > mostly by accepting an ICMP error as a 'no' response. I've thought about this in the context non-RR RO security schemes. We can already do this, by adding a new mobility option to be carried by hoti and then returned by hot if the peer supports it. > So 'No' to Both HoTi and CoTi means no bind updates, and usage of the bidir > MN-HA tunnel, which ensures compatibility with minimum and legacy stacks, as per > the draft > 'Yes' to both HoTi and CoTi means let's go with the bind update, as per the > draft Good. > 'Yes' to CoTi only means support for Home Address option but not for Bind Cache > 'Yes' to HoTi only does not make sense to me at the moment ??? Do we really need this kind of negotiation just to figure out whether the receiver can support HAO or not? If yes, I think it would be much better to have the RO and HAO support together. That is, the peer supports HAO if and only if it supports RO and RR. > This is not exactly the way the draft presents things, mostly for the triangular > part. Also, the draft is heavily biased (e.g. 8.1) in such a way as to let the > reader believe that MIP could not work without support of the Home Address > option by all nodes, "since otherwise communications may be impossible". I Uh... that's not right. > believe that this is misleading, and that we should rather explain the different > scenarios and pro/cons of each level of support by the CN. I believe we Yes. > ShOuLd at least replace all occurrences of MUST by SHOULD in 8.1. > > Does that make sense? Yes. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 06:35:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IDZeoN017888; Thu, 18 Jul 2002 06:35:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IDZUds017887; Thu, 18 Jul 2002 06:35:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IDZQoN017880 for ; Thu, 18 Jul 2002 06:35:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19236 for ; Thu, 18 Jul 2002 06:35:27 -0700 (PDT) From: Ted_Rule@flextech.co.uk Received: from homer.flextech.co.uk (homer.flextech.co.uk [195.188.171.98]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18893 for ; Thu, 18 Jul 2002 07:35:26 -0600 (MDT) Received: from fttvgpsms1.flextech.co.uk (fttvgpsfw1-dmz-nat.flextech.co.uk [192.168.82.4]) by homer.flextech.co.uk (8.9.3/8.9.3) with ESMTP id OAA11474 for ; Thu, 18 Jul 2002 14:35:25 +0100 Received: from fttvgpslnhub1.flextech.co.uk (fttvgpslnhub1.flextech.co.uk) by fttvgpsms1.flextech.co.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 18 Jul 2002 14:35:24 +0100 Received: by fttvgpslnhub1.flextech.co.uk(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80256BFA.004AA61B ; Thu, 18 Jul 2002 14:35:21 +0100 X-Lotus-FromDomain: FLEXTECH To: ipng@sunroof.eng.sun.com Message-ID: <80256BFA.004AA555.00@fttvgpslnhub1.flextech.co.uk> Date: Thu, 18 Jul 2002 14:35:24 +0100 Subject: getaddrinfo DNS search order issues Mime-Version: 1.0 Content-type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some time ago, I had an issue with a recently IPv6 capable telnet client on a Linux box being apparently unable to connect to local IPv4 only capable hosts during a local ISP Connectivity outage. I can't quite decide whether the problem is the down to the IPv6 or DNSExt Groups to solve, since the issue relates to the interface between the Sockets API and the lower level resolver libraries. The combination of requirements for which the problem arose were: non-Windows2000 client host getaddrinfo capable client app. Dual IPv4/IPv6 capable ( i.e. kernel and sockets/resolver library ) client host. IPv4 interfaces only actually configured and up on client host. IPv4 only visible server destination host. non-dotted server name passed as parameter to client app. Local ISP outage Further investigation revealed the following explanation. The telnet client was passed a non-FQDN ( or more accurately a non-dottted ) hostname to which to connect. Within the client app, getaddrinfo was called to resolve the non-dotted name. For the purposes of the argument, assume a local company name - and hence resolv.conf search path of dwarves.com, and a hostname of grumpy. Also discount for the present any use of hosts/NIS in nsswitch.conf - which adds yet further complication to the problem. getaddrinfo() performs an outer loop across all known address families- in this case IPv6 and IPv4 in that order, passing each request down to the resolver library's lower levels Resolver library searches for the hostname across the resolver search path. Because all Unix resolver libraries I've been able to test force a last-resort search path of "." on non-dotted names, this combination results in the following DNS queries to the local DNS server. grumpy.dwarves.com AAAA returns NODATA/NOERROR grumpy. AAAA returns NXDOMAIN grumpy.dwarves.com A returns address As far as I can tell, on Windows boxes, performing a gethostbyname or similar on a non-dotted name always looks along the explicitly declared search path - there is no implicit "." search lookup for non-dotted names. The problem, of course, is that the "grumpy. AAAA" lookup is forced to query all the way up to the root servers ( assuming no local cache has the answer ), and if your local ISP has just pulled the plug, the client app sulks for several tens of seconds before falling back to the final successful "grumpy.dwarves.com A" lookup. As a nasty kludge fix for my local Linux boxes, where most of the kernels happen to have been built without IPv6 support whilst the sockets library was still IPv6 capable, I was able to patch fix the problem to an extent by making the telnet client call getaddrinfo with AF_UNSPEC if and only if it was capable of successfully opening a test IPv6 socket - thereby proving the kernel to be IPv6 capable. As far as I can tell, the preferred solution seems to be a redefinition of getaddrinfo()/resolver-library internal operations to perform the lookup across the DNS search path as the outer loop, with the search across the address family set as the inner loop, instead of the other way round as at present. As everyone can readily guess, this is a non-trivial problem.... Another possible workround is to enhance the API to include some form of ioctl() like call which returns the number of interfaces of a given family configured on a host. The client app could then opt to only use AF_UNSPEC as a parameter to getaddrinfo if ioctl() returns a non-zero count for the IPv6 address family. A side effect of this is that even during normal - fully Internet connected times - local dual stack hosts will be busy annoying the root servers will TLD level AAAA lookups which invariably return NXDOMAIN. Fixing this issue would presumably relieve all the root servers of quite a bit of nonsense. Of course, if someone happens to choose a local hostname which matches a TLD, and a rogue TLD admin were to create a suitable AAAA record and corresponding IPv6 host, a form of man-in-the-middle attack might also be possible. Consider a real local host of biz.dwarves.com, and a biz. AAAA record pointing to a live rogue IPv6 host; any client connecting to biz from a dual stack host might potentially connect to the rogue. The above might even argue for a redefinition of DNS itself, banning A/AAAA/A6 records in a TLD, but implementing such a monumental change is probably completely out of the question. The other argument to be made is to ban the last resort lookup in the search path for A/AAAA/A6 records. It seems that Windows boxes manage completely happily without it. Given that there are very few TLD level A/AAAA/A6 records anyway, ( cc. being a known exception ) leaving that implicit root lookup in place is perhaps more trouble than it's worth. Ted Rule, Flextech Television. *************************************************************************************************** This E-mail message, including any attachments, is intended only for the person or entity to which it is addressed, and may contain confidential information. If you are not the intended recipient, any review, retransmission, disclosure, copying, modification or other use of this E-mail message or attachments is strictly forbidden. If you have received this E-mail message in error, please contact the author and delete the message and any attachments from your computer. You are also advised that the views and opinions expressed in this E-mail message and any attachments are the author's own, and may not reflect the views and opinions of FLEXTECH Television Limited. *************************************************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 07:25:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IEPZoN018127; Thu, 18 Jul 2002 07:25:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IEPZrs018126; Thu, 18 Jul 2002 07:25:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IEPVoN018119; Thu, 18 Jul 2002 07:25:31 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19596; Thu, 18 Jul 2002 07:25:31 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14761; Thu, 18 Jul 2002 08:25:31 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g6IEP6S02473; Thu, 18 Jul 2002 09:25:06 -0500 (CDT) Message-ID: <3D36CFE3.9090605@alcatel.com> Date: Thu, 18 Jul 2002 09:25:39 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas CC: john.loughney@nokia.com, itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> <15669.60922.686205.742010@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael, I do not understand why you are insisting on SHOULD? If IETF is not against having such MUSTs as in this case, let's have it. How can a revolutionary technology such as MIPv6 allow HA reverse tunneling like MIPv4 does? Another benefit will be to mandate HAO in any new implementations. Becasue of all these, I think that we should (or MUST) keep the MUST there, what the heck? Regards, Michael Thomas wrote: >john.loughney@nokia.com writes: > > > Given that MIPv6 will interoperate without binding > > > code in CN's, it looks pretty much like a SHOULD > > > to me. Indeed, the protocol would not be robust if > > > it didn't consider the case of a non-conformant CN. > > > > I think we want to ask is, is it the right thing to do? For > > proper protocol functioning, will this lead to the correct > > behavior. If we think it is important, the MUST is OK. The > > spec does contain a mechanism to support existing implementations > > of IPv6, which means the protocol designers are doing their > > jobs. > > I think we're straying into a "good" as in > "good for the overall health of the Internet" > kind of good, rather than a "good" as in will > the protocol operate correctly. For the former, > I think you need to have extremely compelling > motivation, as well as a lot of evidence that > the health of the net will be imperiled if *all* > nodes don't implement a particular function, which > is what is at issue here. > > Frankly, I don't think that there is any evidence > that the net would be substantially harmed if RO > wasn't widely implemented and/or enabled. Indeed, > I think there's good reason to believe that many/most > nodes will not enable RO even if their kernel > implements it. In some cases, it's likely to be > a nice and useful optimization, but I really > don't see it as a "if we don't do this the net > will fall apart". As such, SHOULD seems like it > strikes the right balance. > > Mike > -- Behcet -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 07:56:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IEunoN018633; Thu, 18 Jul 2002 07:56:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IEun9x018632; Thu, 18 Jul 2002 07:56:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IEukoN018625 for ; Thu, 18 Jul 2002 07:56:46 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27539 for ; Thu, 18 Jul 2002 07:56:47 -0700 (PDT) Received: from delta.cs.mu.OZ.AU ([133.93.71.210]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10749 for ; Thu, 18 Jul 2002 07:56:46 -0700 (PDT) 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 g6IEtl808479; Thu, 18 Jul 2002 23:55:48 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Ted_Rule@flextech.co.uk cc: ipng@sunroof.eng.sun.com Subject: Re: getaddrinfo DNS search order issues In-Reply-To: <80256BFA.004AA555.00@fttvgpslnhub1.flextech.co.uk> References: <80256BFA.004AA555.00@fttvgpslnhub1.flextech.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Jul 2002 23:55:47 +0900 Message-ID: <8477.1027004147@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 18 Jul 2002 14:35:24 +0100 From: Ted_Rule@flextech.co.uk Message-ID: <80256BFA.004AA555.00@fttvgpslnhub1.flextech.co.uk> | I can't quite decide whether the problem is the down to the IPv6 or DNSExt | Groups to solve, Probably neither, most of what you're describing is just implementation bugs. Talk to the implementors of the stack/library, and get it fixed. | getaddrinfo() performs an outer loop across all known address families- | in this case IPv6 and IPv4 in that order, While this makes the implementation easy, it is almost certainly not the right way - since (in this scenario) both AAAA and A records would be wanted (otherwise it would only be doing one of the queries) it really should be doing both at once. Not all the AAAA and then all the A. That just turns out to be harder with the internal library interfaces as they currently exist that the current scheme. | Because all Unix resolver libraries I've been able to test force a | last-resort search path of "." That's another bug - failing to add a domain should only ever be done to a name that already has dots, a name like "grumpy" (that is, not "grumpy.") should never be looked up by normal applications, some default domain should always be appended. (Diagnostic tools can behave differently sometimes). | The problem, of course, is that the "grumpy. AAAA" lookup is forced | to query all the way up to the root servers Just sloppy implementation. Nothing in any spec requires that. | As a nasty kludge fix for my local Linux boxes, where most of the kernels | happen to have been built without IPv6 support whilst the sockets | library was still IPv6 capable, I was able to patch fix the problem | to an extent by making the telnet client call getaddrinfo with AF_UNSPEC | if and only if it was capable of successfully opening a test IPv6 socket That's a high overhead way of achieving a simple result (high because it will often require two additional system calls - one to open, another to close again) just to find out if the stack is IPv6 (or 4 for that matter) capable. There should be an easier way in the API to achieve this. That's something which might be an ipv6 working group issue. | Another possible workround is to enhance the API to include some form | of ioctl() like call which returns the number of interfaces of a given | family configured on a host. That sounds like more info than is required. | A side effect of this is that even during normal - fully Internet connected | times - local dual stack hosts will | be busy annoying the root servers will TLD level AAAA lookups which | invariably return NXDOMAIN. Lots of things annoy the root servers. But the implementation bug should be fixed. This is not the forum to achieve that however. For what it is worth, the same problem can easily occur (and does occur, though there are less implementations that suffer as much these days as there used to be) without any IPv6 anywhere. | The above might even argue for a redefinition of DNS itself, | banning A/AAAA/A6 records in a TLD, No, we don't need that. | The other argument to be made is to ban the last resort lookup in the search | path for A/AAAA/A6 records. It seems that Windows boxes manage completely | happily without it. Everyone should be able to manage without it if the initial name has no dots at all. Of course, if you had said "grumpy.subdomain" expecting "grumpy.subdomain.dwarves.com" to be found, then a lookup for just "grumpy.subdomain" is to be expected, and will often be attempted before appending anything from the search path. 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 Jul 18 08:07:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IF7coN018679; Thu, 18 Jul 2002 08:07:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IF7bxF018678; Thu, 18 Jul 2002 08:07:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IF7YoN018671; Thu, 18 Jul 2002 08:07:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12321; Thu, 18 Jul 2002 08:07:35 -0700 (PDT) Received: from ogud.com (208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com [208.59.113.50]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28368; Thu, 18 Jul 2002 09:07:34 -0600 (MDT) Received: from engill.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g6IF87h03865; Thu, 18 Jul 2002 11:08:08 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020717095218.02c556c0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 18 Jul 2002 11:04:52 -0400 To: "J-F C. (Jefsey) Morfin" , David Conrad , Ed Sawicki , Randy Bush From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results Cc: DNS Operations , namedroppers , , IPng In-Reply-To: <5.1.0.14.0.20020717113429.0247ca40@mail.club-internet.fr> References: <1026847384.23224.49.camel@red> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 05:42 AM 7/17/2002, J-F C. (Jefsey) Morfin wrote: >The frustration results from an uncompleted report. The target is to >demonstrate that different thinking families can have the same reading of >the specs and can develop from them compatible softwares. The bugs may >results from unclear specs or from an early development phase. That we >need to know. > >The name of the participants would only help knowing the X, Y, Z >architectures, used libraries, concept affiliations, "style", etc.. To >evaluate if the specs testing spectrum is significant enough. But the >better, easiest and common way would be that each participant describes >his approach in his own terms (so there is no confidentiality break). IMHO >this is basic to any hidden testing protocol. Just for the record, THIS interoperabilty test was performed without any vendor participation, thus it is real hard for the report to talk about approaches or reasons why. The real important thing here is there are three implementations that work. This enables the DNSEXT working group to advance RFC1886bis to Draft Standard. The fact that one implementation forces services (mail, NS, ..) to use IPv4 transport when IPv6 transport is available, is not critical as the information is available via explicit AAAA query. Olafur -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 09:26:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IGQjoN018922; Thu, 18 Jul 2002 09:26:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IGQjkB018921; Thu, 18 Jul 2002 09:26:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IGQfoN018914 for ; Thu, 18 Jul 2002 09:26:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24686 for ; Thu, 18 Jul 2002 09:26:42 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08092 for ; Thu, 18 Jul 2002 10:26:40 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 31F584B23; Fri, 19 Jul 2002 01:26:31 +0900 (JST) To: Ted_Rule@flextech.co.uk Cc: ipng@sunroof.eng.sun.com In-reply-to: Ted_Rule's message of Thu, 18 Jul 2002 14:35:24 +0100. <80256BFA.004AA555.00@fttvgpslnhub1.flextech.co.uk> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: getaddrinfo DNS search order issues From: itojun@iijlab.net Date: Fri, 19 Jul 2002 01:26:31 +0900 Message-Id: <20020718162631.31F584B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >getaddrinfo() performs an outer loop across all known address families- in >this case IPv6 and IPv4 in that order, passing each request down to the >resolver library's lower levels this is not a protocol issue but purely an implementation issue. resolver in *BSD does not do the above. quick-and-easy implementation that calls gethostbyname() from within getaddrinfo() would behave like you have described. 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 Jul 18 10:02:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IH2voN019012; Thu, 18 Jul 2002 10:02:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IH2v9E019011; Thu, 18 Jul 2002 10:02:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IH2roN019004 for ; Thu, 18 Jul 2002 10:02:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02050 for ; Thu, 18 Jul 2002 10:02:52 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27652 for ; Thu, 18 Jul 2002 10:02:51 -0700 (PDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id SAA18735; Thu, 18 Jul 2002 18:02:44 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Francis Dupont Cc: aaron.m.smith@motorola.com, ipng@sunroof.eng.sun.com Subject: Re: Prefix Delegation Requirements and comparison References: <200207181051.g6IAppGF072239@givry.rennes.enst-bretagne.fr> From: Ole Troan Date: Thu, 18 Jul 2002 18:02:44 +0100 In-Reply-To: <200207181051.g6IAppGF072239@givry.rennes.enst-bretagne.fr> (Francis Dupont's message of "Thu, 18 Jul 2002 12:51:51 +0200") Message-ID: <7t5wurtdl57.fsf@mrwint.cisco.com> Lines: 22 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > > > B. Multi-access/Point to point > > I'm glad to see interest in generalizing beyond just the point-to-point case. > I'd like to have a solution that allows the requesting router to be more > than one hop away from the prefix delegator. > > => this is in fact supported by the same protocols that support > multi-access. I'm afraid I don't see the connection. two out of the three proposals use link-local multicast for delegator discovery, so without some sort of relaying mechanism the requesting router and the delegating router has to be on the same link. even with a relaying mechanism you have to consider who and how you get a route for the prefix injected into the routing system. cheers, Ole -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 10:05:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IH5EoN019029; Thu, 18 Jul 2002 10:05:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IH5EgF019028; Thu, 18 Jul 2002 10:05:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IH5BoN019021 for ; Thu, 18 Jul 2002 10:05:11 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10011 for ; Thu, 18 Jul 2002 10:05:13 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18968 for ; Thu, 18 Jul 2002 11:05:12 -0600 (MDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA18488; Thu, 18 Jul 2002 17:57:26 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Robert Elz , Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: Prefix Delegation Requirements and comparison References: <200207181116.g6IBG8GF072312@givry.rennes.enst-bretagne.fr> <8175.1026999166@munnari.OZ.AU> From: Ole Troan Date: Thu, 18 Jul 2002 17:57:26 +0100 In-Reply-To: <8175.1026999166@munnari.OZ.AU> (Robert Elz's message of "Thu, 18 Jul 2002 22:32:46 +0900") Message-ID: <7t51ya1ezyh.fsf@mrwint.cisco.com> Lines: 41 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk if you don't mind, please let's try to focus on prefix delegation on this thread. griefs with DHCP based address assignment can be taken on the DHC list. I don't think we need to do the 'H' in DHCP means host discussion again either. cheers, Ole > Date: Thu, 18 Jul 2002 13:16:08 +0200 > From: Francis Dupont > Message-ID: <200207181116.g6IBG8GF072312@givry.rennes.enst-bretagne.fr> > > | => address assignment is not the good way to manage an IPv6 network, > | address registration is simpler so better. > > This depends what kind of net you're attempting to run, and how. > Inside my house, I might want to group various different pieces of > furniture on the LAN into related address groups. This allows me > to write firewall rules easily to grant similar access to all of the > chairs, without having to identify each one (they'll come from > different manufacturers, so the EUI won't help group them). > > In this kind of environment I can be fairly confident that one of the > chairs isn't going to decide to simply configure itself a different > address to side-step my policies. So as long as all the furniture talks > to my server to have its address allocated, I can assign addresses that > match my policies, and have the firewalls simply apply the correct > policies as soon as the node becomes active. > > Certainly, address registration can be useful as well - but that's not > a configuration function, it is a post configuration function, so > arguably belongs elsewhere. And also, certainly, not all nets require > all of this administrative baggage, and so it needs to be possible to > run a net with no DHCP servers at all. So, while as an interim measure > until we get something better, doing some of the missing "extra" config > using DHCP, and not providing any alternative that really works might > be acceptable, longer term, we need methods for all of this that works > (which means not well known addresses, of any kind) without requiring > anything like DHCP. > > 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 Jul 18 10:10:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IHAOoN019123; Thu, 18 Jul 2002 10:10:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IHAO5B019122; Thu, 18 Jul 2002 10:10:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IHALoN019115 for ; Thu, 18 Jul 2002 10:10:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12430 for ; Thu, 18 Jul 2002 10:10:23 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00375 for ; Thu, 18 Jul 2002 11:10:22 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6IHAZQ28653 for ; Thu, 18 Jul 2002 12:10:35 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 12:10:21 -0500 Message-ID: From: "Imran Hafeez" To: "'ipng@sunroof.eng.sun.com'" Subject: Question on DHCPV6 RFC draft-ietf-dhc-dhcpv6-26.txt Date: Thu, 18 Jul 2002 12:10:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E7D.FE48F8A0" 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_01C22E7D.FE48F8A0 Content-Type: text/plain; charset="iso-8859-1" Hi, In the DHCPV6 RFC the IAADDR option specifies an IPV6 address but without any indication to where the prefix & interface id starts and ends. However if you read Radius RFC's for IPV6, they explicitly specify this information, in otherwords they break the IPV6 address into its components. Does you know why it was done this way ? Wouldn't this have any potential implications to the way DHCPV6 could be configured ? thanx in advance, Imran Hafeez ------_=_NextPart_001_01C22E7D.FE48F8A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question on DHCPV6 RFC draft-ietf-dhc-dhcpv6-26.txt

    Hi,

    In the DHCPV6 RFC the IAADDR option specifies an IPV6 = address but without any indication to where the prefix & interface = id starts and ends. However if you read Radius RFC's for IPV6, they = explicitly specify this information, in otherwords they break the IPV6 = address into its components.

    Does you know why it was done this way ?

    Wouldn't this have any potential implications to the = way DHCPV6 could be configured ?

    thanx in advance,
    Imran Hafeez

    ------_=_NextPart_001_01C22E7D.FE48F8A0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 10:37:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IHbXoN019361; Thu, 18 Jul 2002 10:37:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IHbXWZ019360; Thu, 18 Jul 2002 10:37:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IHbWoN019353 for ; Thu, 18 Jul 2002 10:37:32 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6IHasGZ008185 for ; Thu, 18 Jul 2002 10:36:54 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6IHasrH008184 for ipng@sunroof.eng.sun.com; Thu, 18 Jul 2002 10:36:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2fjoN013579; Wed, 17 Jul 2002 19:41:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA26586; Wed, 17 Jul 2002 19:41:48 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21234; Wed, 17 Jul 2002 19:41:47 -0700 (PDT) Received: from PTHUBERTW2K2 (tokyo-vpn-user38.cisco.com [10.70.82.38]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id EAA20829; Thu, 18 Jul 2002 04:41:18 +0200 (MET DST) From: "Pascal Thubert" To: , , Cc: , , , Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Thu, 18 Jul 2002 11:41:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578D@esebe004.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk * Just as an FYI, I replied to the earlier mail because I am > trying to sort this out for the node requirements. I think > that in MIPv6, it is OK that MIPv6 makes this recommendation (given > working group consensus, IESG approval, etc.) but the Node Requirements > document is the final word on the issue (assuming WG consensus, > IESG approval, etc.). This issue seems to delay MIPv6 till the node requirement is out; so could we not just recommend that the Mobile Node SHOULD use the reverse tunnel till some part of the RR test is complete? If we do so, then a potential CN that fails to respond to the CoT test would be considered as a legacy device and we would not perform RO at all. My initial proposal is to negotiate the RO the following way: Cot Fails : The MN MUST use the reverse tunnel for all traffic Cot works, Hot Fails : The CN accepts the HaO but is not willing to manage a Bind Cache -> triangular routing (E.g. a clustered web server) Both work: The CN is willing to receive bind updates. What do you think? Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of john.loughney@nokia.com Sent: Thursday, July 18, 2002 2:14 AM To: mat@cisco.com; vijayd@iprg.nokia.com Cc: itojun@iijlab.net; keiichi@iij.ad.jp; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Hi Mike, > Vijay Devarapalli writes: > > RO is a SHOULD, it is not a MUST in the current draft. we were > > not talking about route optimization. we were talking about > > processing a HAO. in the current spec HAO MUST be processed but > > not accepted if it cant be verified. verification can be in the > > form of checking for a valid BCE (created securely), IPsec > > protected data session, same trusted domain (where you dont > > expect people to do reflection attacks), the tagging proposal > > from Rajeev and Charlie, smart ingress filtering from Francis > > Dupont, etc... > > Oh, OK. Sorry about that. Still if the code > isn't in the CN, the MN should still be able > to operate correctly, right? That still seems > to me to be a SHOULD rather than a MUST for the > same reasons in my reply to John. > > I guess the long and short of this is that I'm > somewhat skeptical of putting general node > requirements in the MIP draft since it's > probably not the first place one would be > looking to figure out if they were an IPv6 > compliant node. If it's really, really vital > for the health of the net, yadda, yadda, it > would be better to put it in a general v6 node > requirements RFC, don't you think? Just as an FYI, I replied to the earlier mail because I am trying to sort this out for the node requirements. I think that in MIPv6, it is OK that MIPv6 makes this recommendation (given working group consensus, IESG approval, etc.) but the Node Requirements document is the final word on the issue (assuming WG consensus, IESG approval, etc.). John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 10:38:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IHcHoN019374; Thu, 18 Jul 2002 10:38:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IHcHn2019373; Thu, 18 Jul 2002 10:38:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IHcFoN019366 for ; Thu, 18 Jul 2002 10:38:15 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6IHbbGZ008193 for ; Thu, 18 Jul 2002 10:37:37 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6IHbbVa008192 for ipng@sunroof.eng.sun.com; Thu, 18 Jul 2002 10:37:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I60goN015885; Wed, 17 Jul 2002 23:00:42 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25621; Wed, 17 Jul 2002 23:00:44 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23877; Thu, 18 Jul 2002 00:00:43 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6I5ucQ24877; Thu, 18 Jul 2002 00:56:38 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 00:56:23 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D24051C132F@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Michael Thomas , john.loughney@nokia.com Cc: itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Thu, 18 Jul 2002 00:56:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E1F.D87FE740" 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_01C22E1F.D87FE740 Content-Type: text/plain; charset="iso-8859-1" Michael Thomas wrote: > Frankly, I don't think that there is any evidence > that the net would be substantially harmed if RO > wasn't widely implemented and/or enabled. Indeed, > I think there's good reason to believe that many/most > nodes will not enable RO even if their kernel > implements it. In some cases, it's likely to be > a nice and useful optimization, but I really > don't see it as a "if we don't do this the net > will fall apart". As such, SHOULD seems like it > strikes the right balance. > > Mike > I could not agree more with this point. RO would be a required functionality a number of years back, when the net was in it's infancy and bandwidth availability in the backbone networks (even transoceanic links) were severely limited. We are in the age of OC-192/768s over DWDM. The delay that an IP packet incurs in the core is almost negligible. If bottleneck in the HA is the primary driver for RO, then it is possible to solve the problem with load balancing with DHAAD. My two cents. Regards, Kuntal ------_=_NextPart_001_01C22E1F.D87FE740 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Re: HAO and BE processing will be mandated

    Michael Thomas wrote:
    >    Frankly, I don't think that there is any evidence
    >    that the net would be substantially harmed if RO
    >    wasn't widely implemented and/or enabled. Indeed,
    >    I think  there's good reason to believe that many/most
    >    nodes will not enable RO even if their kernel
    >    implements it. In some cases, it's likely to be
    >    a nice and useful optimization, but I really
    >    don't see it as a "if we don't do this the net
    >    will fall apart". As such, SHOULD seems like it
    >    strikes the right balance.
    >
    >              Mike
    >

    I could not agree more with this point. RO would be a required
    functionality a number of years back, when the net was in it's
    infancy and bandwidth availability in the backbone networks
    (even transoceanic links) were severely limited.
    We are in the age of OC-192/768s over DWDM. The delay that an IP
    packet incurs in the core is almost negligible.
    If bottleneck in the HA is the primary driver for RO, then it is
    possible to solve the problem with load balancing with DHAAD.

    My two cents.

    Regards,
    Kuntal

    ------_=_NextPart_001_01C22E1F.D87FE740-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 10:38:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IHcwoN019391; Thu, 18 Jul 2002 10:38:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IHcvoF019390; Thu, 18 Jul 2002 10:38:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IHctoN019383 for ; Thu, 18 Jul 2002 10:38:55 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6IHcIGZ008201 for ; Thu, 18 Jul 2002 10:38:18 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6IHcI3L008200 for ipng@sunroof.eng.sun.com; Thu, 18 Jul 2002 10:38:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I97coN016978; Thu, 18 Jul 2002 02:07:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04466; Thu, 18 Jul 2002 02:07:39 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA04388; Thu, 18 Jul 2002 03:07:38 -0600 (MDT) Received: from PTHUBERTW2K2 (tokyo-vpn-user36.cisco.com [10.70.82.36]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id KAA19847; Thu, 18 Jul 2002 10:59:48 +0200 (MET DST) From: "Pascal Thubert" To: "=?us-ascii?B?S2VpaWNoaSBTSElNQSAvICI/T2NeZQ==?=" , Cc: , , , Subject: RE: [mobile-ip] Re: summary of HAO, BE processing discussion Date: Thu, 18 Jul 2002 18:00:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020718.141850.32635405.keiichi@iij.ad.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think I've been a little cryptic: Some devices such as a fridge may be happy to have a minimum set of requirements for IPv6. Other devices such as clustered servers may not be able to maintain a BCE at all because the cluster IP address is shared among all the members of the cluster -- unless they perform a new protocol to distribute the BCEs-. Furthermore, if the cluster uses a dispatcher that is not on the return path, then the dispatcher cannot provide the MIP termination, either. However, if that same dispatcher terminates an IPSEC tunnel, or by other means to be defined later such as piggy backing, it could be possible to trust a Home address option and perform triangular routing. Using a Binding Cache as opposed to piggy backing the BU with each packet assumes that memory scales better than CPU. This seems a reasonable approach, so does delaying the support of piggybacking. But still, we must allow for the case where this trade-off does not apply. Say the dispatcher I just mentioned has a hardware accelerated crypto engine; say it can cache some recent computations in a LRU fashion; say it has limited memory capabilities to keep many BCEs long term; and say it needs to serve requests for a huge amount of unrelated users; in that case, the trade-off is the wrong choice, and triangular may be the best can do, unless the client sources its requests with its CoA, which leads to more open issues. MUSTing a Binding Cache in IPv6 outlaws this configuration de facto. If we agree that there can be several levels of support by the CN for RO, then we could define what the behaviour is for each level and how to negotiate that between the CN and the MN. My suggestion was to do that negotiation at RR test time so that no bind support would be necessary unless both parties agree upon bi-directional route optimization. A way to perform that negotiation is to give a meaning to the response to HoTi and CoTi. This may be achieved by adding negative Return Code to Hot Cot, and mostly by accepting an ICMP error as a 'no' response. So 'No' to Both HoTi and CoTi means no bind updates, and usage of the bidir MN-HA tunnel, which ensures compatibility with minimum and legacy stacks, as per the draft 'Yes' to both HoTi and CoTi means let's go with the bind update, as per the draft 'Yes' to CoTi only means support for Home Address option but not for Bind Cache 'Yes' to HoTi only does not make sense to me at the moment ??? This is not exactly the way the draft presents things, mostly for the triangular part. Also, the draft is heavily biased (e.g. 8.1) in such a way as to let the reader believe that MIP could not work without support of the Home Address option by all nodes, "since otherwise communications may be impossible". I believe that this is misleading, and that we should rather explain the different scenarios and pro/cons of each level of support by the CN. I believe we ShOuLd at least replace all occurrences of MUST by SHOULD in 8.1. Does that make sense? Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Keiichi SHIMA / "?Oc^e Sent: Thursday, July 18, 2002 7:19 AM To: jari.arkko@kolumbus.fi Cc: mat@cisco.com; itojun@iijlab.net; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: summary of HAO, BE processing discussion Let me add one thing. From: Jari Arkko > * IPv6 WG has in the past accepted the HAO as a mandatory > feature for all IPv6 nodes. Arguments have been made, > however, that the processing of the HAO has been changed > and the situation may now be different. In addition, the current draft requires not only HAO but also BE. This means all IPv6 nodes must implement a new extention header (mobility header). I never say that such a mechanism is bad at all. It is good of course. But from the view of the fast deployment of both IPv6 and Mobile IPv6, I personally think it better not to require additional requirements... This is not the view of the protocol designer, though. I'm probablly a bad designer and a bad scientist. I just want a real IPv6 and a Mobile IPv6... Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 10:39:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IHdQoN019408; Thu, 18 Jul 2002 10:39:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IHdQS2019407; Thu, 18 Jul 2002 10:39:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IHdOoN019400 for ; Thu, 18 Jul 2002 10:39:24 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6IHclGZ008209 for ; Thu, 18 Jul 2002 10:38:47 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6IHckmZ008208 for ipng@sunroof.eng.sun.com; Thu, 18 Jul 2002 10:38:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IEpIoN018486; Thu, 18 Jul 2002 07:51:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10649; Thu, 18 Jul 2002 07:51:19 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16442; Thu, 18 Jul 2002 07:51:18 -0700 (PDT) Received: from PTHUBERTW2K2 (tokyo-vpn-user276.cisco.com [10.70.83.20]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA10522; Thu, 18 Jul 2002 16:50:57 +0200 (MET DST) From: "Pascal Thubert" To: "Behcet Sarikaya" , "Michael Thomas" Cc: , , , , , Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Thu, 18 Jul 2002 23:51:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D36CFE3.9090605@alcatel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Face it: Many of today's large web servers will not want to maintain binding caches. Because: - They are clustered (see my previous mail on this thread) - Visits are short and unrelated (the caches are not reused) - RR reduces the throughput and the response time - They may even blindly accept the Home Address option since the AAA takes place at session level anyway using cookies and such. How much of the global IP traffic does this represent today? What will mobile devices do at least in the short term? We must provide a way for servers to simply and politely decline RO. We may want to permit triangular routing. The minimum we can do to ease IPv6 transition is at least to allow the current v4 applications to run in equivalent conditions. It's a SHOULD. Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Behcet Sarikaya Sent: Thursday, July 18, 2002 4:26 PM To: Michael Thomas Cc: john.loughney@nokia.com; itojun@iijlab.net; vijayd@iprg.nokia.com; keiichi@iij.ad.jp; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated Michael, I do not understand why you are insisting on SHOULD? If IETF is not against having such MUSTs as in this case, let's have it. How can a revolutionary technology such as MIPv6 allow HA reverse tunneling like MIPv4 does? Another benefit will be to mandate HAO in any new implementations. Becasue of all these, I think that we should (or MUST) keep the MUST there, what the heck? Regards, Michael Thomas wrote: >john.loughney@nokia.com writes: > > > Given that MIPv6 will interoperate without binding > > > code in CN's, it looks pretty much like a SHOULD > > > to me. Indeed, the protocol would not be robust if > > > it didn't consider the case of a non-conformant CN. > > > > I think we want to ask is, is it the right thing to do? For > > proper protocol functioning, will this lead to the correct > > behavior. If we think it is important, the MUST is OK. The > > spec does contain a mechanism to support existing implementations > > of IPv6, which means the protocol designers are doing their > > jobs. > > I think we're straying into a "good" as in > "good for the overall health of the Internet" > kind of good, rather than a "good" as in will > the protocol operate correctly. For the former, > I think you need to have extremely compelling > motivation, as well as a lot of evidence that > the health of the net will be imperiled if *all* > nodes don't implement a particular function, which > is what is at issue here. > > Frankly, I don't think that there is any evidence > that the net would be substantially harmed if RO > wasn't widely implemented and/or enabled. Indeed, > I think there's good reason to believe that many/most > nodes will not enable RO even if their kernel > implements it. In some cases, it's likely to be > a nice and useful optimization, but I really > don't see it as a "if we don't do this the net > will fall apart". As such, SHOULD seems like it > strikes the right balance. > > Mike > -- Behcet -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 14:06:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IL6UoN020183; Thu, 18 Jul 2002 14:06:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IL6Ueo020182; Thu, 18 Jul 2002 14:06:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IL6QoN020175; Thu, 18 Jul 2002 14:06:26 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22469; Thu, 18 Jul 2002 14:06:27 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16832; Thu, 18 Jul 2002 14:06:26 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 1C9226A907; Fri, 19 Jul 2002 00:06:19 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 193D26A905; Fri, 19 Jul 2002 00:06:14 +0300 (EEST) Message-ID: <3D372E33.9010701@kolumbus.fi> Date: Fri, 19 Jul 2002 00:08:03 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Pascal Thubert Cc: Behcet Sarikaya , Michael Thomas , john.loughney@nokia.com, itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pascal Thubert wrote: > Face it: Many of today's large web servers will not want to maintain binding > caches. Because: > - They are clustered (see my previous mail on this thread) > - Visits are short and unrelated (the caches are not reused) > - RR reduces the throughput and the response time The current spec allows CNs to decline a RO/RR request. This is of course necessary, we couldn't mandate that they have sufficient memory etc. in all cases to handle these requests. > - They may even blindly accept the Home Address option since the AAA takes place > at session level anyway using cookies and such. Most likely we can't do this. Earlier analysis indicated that unverified home address option could lead to reflection attacks. > How much of the global IP traffic does this represent today? What will mobile > devices do at least in the short term? We must provide a way for servers to > simply and politely decline RO. We may want to permit triangular routing. The > minimum we can do to ease IPv6 transition is at least to allow the current v4 > applications to run in equivalent conditions. Yes, and they can decline RO already now. Triangular routing will only be allowed under a special condition (existing SA), which I think is probably not compatible with your scenario of web servers. > It's a SHOULD. I'm not really arguing against that... Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 15:21:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IMLtoN020505; Thu, 18 Jul 2002 15:21:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6IMLtOI020504; Thu, 18 Jul 2002 15:21:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6IMLpoN020497; Thu, 18 Jul 2002 15:21:51 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25502; Thu, 18 Jul 2002 15:21:52 -0700 (PDT) Received: from roam.psg.com ([133.93.74.251]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16596; Thu, 18 Jul 2002 16:21:51 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17VJef-0000Sb-00; Fri, 19 Jul 2002 07:21:49 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "J-F C. (Jefsey) Morfin" Cc: namedroppers , ngtrans@sunroof.eng.sun.com, IPng.ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results References: <1026847384.23224.49.camel@red> <5.1.1.6.2.20020717095218.02c556c0@localhost> Message-Id: Date: Fri, 19 Jul 2002 07:21:49 +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The frustration results from an uncompleted report. The target is to > demonstrate that different thinking families can have the same reading of > the specs and can develop from them compatible softwares. i missed the part about "different thinking families" in 2026. in the ietf, we still occasionally try NOT to make things more complex than they must be. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 17:38:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J0c7oN020810; Thu, 18 Jul 2002 17:38:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J0c6sE020809; Thu, 18 Jul 2002 17:38:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J0c3oN020802 for ; Thu, 18 Jul 2002 17:38:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09459 for ; Thu, 18 Jul 2002 17:38:04 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26669 for ; Thu, 18 Jul 2002 18:38:02 -0600 (MDT) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g6J0bTJe006994; Fri, 19 Jul 2002 10:37:31 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200207190037.g6J0bTJe006994@drugs.dv.isc.org> To: Robert Elz Cc: Ted_Rule@flextech.co.uk, ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: getaddrinfo DNS search order issues In-reply-to: Your message of "Thu, 18 Jul 2002 23:55:47 +0900." <8477.1027004147@munnari.OZ.AU> Date: Fri, 19 Jul 2002 10:37:29 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Thu, 18 Jul 2002 14:35:24 +0100 > From: Ted_Rule@flextech.co.uk > Message-ID: <80256BFA.004AA555.00@fttvgpslnhub1.flextech.co.uk> > > | I can't quite decide whether the problem is the down to the IPv6 or DNSEx > t > | Groups to solve, > > Probably neither, most of what you're describing is just implementation bugs. > Talk to the implementors of the stack/library, and get it fixed. > > > | getaddrinfo() performs an outer loop across all known address families- > | in this case IPv6 and IPv4 in that order, > > While this makes the implementation easy, it is almost certainly not the > right way - since (in this scenario) both AAAA and A records would be > wanted (otherwise it would only be doing one of the queries) it really > should be doing both at once. Not all the AAAA and then all the A. > That just turns out to be harder with the internal library interfaces > as they currently exist that the current scheme. Robert, I mentioned that this was a issue several years ago (on namedroppers / bind-workers) with respect to MX vs A and said that the search should stop on a NODATA response. You were quite happy for MX and A to hit different fqdn at the time. It looks like AAAA vs A has changed your opinion. It looks like we need a multi-type search algorithm which can optionally stop on match or continue to look for the rest of the types. > | Because all Unix resolver libraries I've been able to test force a > | last-resort search path of "." > > That's another bug - failing to add a domain should only ever be done > to a name that already has dots, a name like "grumpy" (that is, not "grumpy." > ) > should never be looked up by normal applications, some default domain > should always be appended. (Diagnostic tools can behave differently > sometimes). This is configurable in modern resolvers. > | The problem, of course, is that the "grumpy. AAAA" lookup is forced > | to query all the way up to the root servers > > Just sloppy implementation. Nothing in any spec requires that. Agreed, however changing *default* resolver behaviour is difficult as it ends up breaking things. "localhost" lookups is what tends to break if you disable this. > | As a nasty kludge fix for my local Linux boxes, where most of the kernels > | happen to have been built without IPv6 support whilst the sockets > | library was still IPv6 capable, I was able to patch fix the problem > | to an extent by making the telnet client call getaddrinfo with AF_UNSPEC > | if and only if it was capable of successfully opening a test IPv6 socket > > That's a high overhead way of achieving a simple result (high because it > will often require two additional system calls - one to open, another to > close again) just to find out if the stack is IPv6 (or 4 for that matter) > capable. There should be an easier way in the API to achieve this. > That's something which might be an ipv6 working group issue. It's not only if the kernel is capable. It's also if there are interfaces configured. Interface scanning is a pain to do in a portable manner. Multiple ioctl and structures with the same names but different results / layouts. > | Another possible workround is to enhance the API to include some form > | of ioctl() like call which returns the number of interfaces of a given > | family configured on a host. > > That sounds like more info than is required. > > | A side effect of this is that even during normal - fully Internet connect > ed > | times - local dual stack hosts will > | be busy annoying the root servers will TLD level AAAA lookups which > | invariably return NXDOMAIN. > > Lots of things annoy the root servers. But the implementation bug should > be fixed. This is not the forum to achieve that however. > > For what it is worth, the same problem can easily occur (and does occur, > though there are less implementations that suffer as much these days as > there used to be) without any IPv6 anywhere. > > | The above might even argue for a redefinition of DNS itself, > | banning A/AAAA/A6 records in a TLD, > > No, we don't need that. Agreed. > > | The other argument to be made is to ban the last resort lookup in the sea > rch > | path for A/AAAA/A6 records. It seems that Windows boxes manage completely > | happily without it. > > Everyone should be able to manage without it if the initial name has > no dots at all. Of course, if you had said "grumpy.subdomain" expecting > "grumpy.subdomain.dwarves.com" to be found, then a lookup for just > "grumpy.subdomain" is to be expected, and will often be attempted before > appending anything from the search path. This is where configuring your servers as stealth root servers becomes a big win, especially when you loose connectivity to the real roots. It also helps when you have resolvers that you can't turn off "try unqalified". If you do this however only have one nameserver at your site fetch the root zone and turn NOTIFY off (or make it explict). Now to just get the root zone's serial to reflect changes to the zones contents and not the time it was dumped from the whois database. You can also just configure a empty subdomain zone to intercept these queries. Watch out for conflicts with real tlds. The other thing to do is just not use partially qualified names, especially in configuration files. This is hard as it requires changing human behaviour. Mark > > 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 > -------------------------------------------------------------------- -- 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 Jul 18 19:33:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J2X6oN021236; Thu, 18 Jul 2002 19:33:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J2X5up021235; Thu, 18 Jul 2002 19:33:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J2X2oN021228 for ; Thu, 18 Jul 2002 19:33:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA13469 for ; Thu, 18 Jul 2002 19:33:04 -0700 (PDT) Received: from delta.cs.mu.OZ.AU ([133.93.71.210]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07543 for ; Thu, 18 Jul 2002 20:33:03 -0600 (MDT) 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 g6J2W6810449; Fri, 19 Jul 2002 11:32:08 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Mark.Andrews@isc.org cc: Ted_Rule@flextech.co.uk, ipng@sunroof.eng.sun.com Subject: Re: getaddrinfo DNS search order issues In-Reply-To: <200207190037.g6J0bTJe006994@drugs.dv.isc.org> References: <200207190037.g6J0bTJe006994@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jul 2002 11:32:06 +0900 Message-ID: <10447.1027045926@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 19 Jul 2002 10:37:29 +1000 From: Mark.Andrews@isc.org Message-ID: <200207190037.g6J0bTJe006994@drugs.dv.isc.org> | Robert, I mentioned that this was a issue several years ago | (on namedroppers / bind-workers) with respect to MX vs A | and said that the search should stop on a NODATA response. | You were quite happy for MX and A to hit different fqdn at | the time. It looks like AAAA vs A has changed your opinion. Sorry, I don't remember the context, but the two cases aren't the same at all. If I am looking for an MX record, I am looking for an MX record. And if I want the MX record for "foo" that's what I want to find. Only if there is no MX record for "foo" should a A lookup even be attempted. On the other hand, when I want "the address of foo" (which is what getaddrinfo() without a specific address type hint does), then I am expressly asking for either an A or an AAAA (or even an A6...) | Agreed, however changing *default* resolver behaviour is | difficult as it ends up breaking things. "localhost" | lookups is what tends to break if you disable this. Only for badly configured zones - the name "localhost" should be configured in every zone that is in a search list (if it doesn't exist in a zone that is on the search list means that there is no "localhost" existing, and the lookup should fail, going on to, or locally configuring "localhost." isn't what should be being done. Because of the way the decision was made to ground FQDN's in a trailing dot, but almost never actually represent it, there's no way for the PTR record for 127.0.0.1 to actually return the FQDN "localhost." (or rather, that could be done, but it never is). What's always returned is the unqualified name, "localhost" | It's not only if the kernel is capable. It's also if there | are interfaces configured. Sure, there should be a simple API for "should I attempt this AF?" I'd also be somewhat cautious about advising people to run non-standard DNS setups. There are things that people who know what they're doing can safely do - but which aren't really practical to advise for the world to attempt to copy (and everyone snarfing the root zone probably doesn't scale, even if it isn't one of the more dangerous things). 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 Jul 18 19:53:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J2rJoN021345; Thu, 18 Jul 2002 19:53:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J2rJaG021344; Thu, 18 Jul 2002 19:53:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J2rFoN021334 for ; Thu, 18 Jul 2002 19:53:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA10930 for ; Thu, 18 Jul 2002 19:53:17 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05319 for ; Thu, 18 Jul 2002 19:53:16 -0700 (PDT) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g6J2qwJe008015; Fri, 19 Jul 2002 12:52:58 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200207190252.g6J2qwJe008015@drugs.dv.isc.org> To: Robert Elz Cc: Ted_Rule@flextech.co.uk, ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: getaddrinfo DNS search order issues In-reply-to: Your message of "Fri, 19 Jul 2002 11:32:06 +0900." <10447.1027045926@munnari.OZ.AU> Date: Fri, 19 Jul 2002 12:52:58 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Fri, 19 Jul 2002 10:37:29 +1000 > From: Mark.Andrews@isc.org > Message-ID: <200207190037.g6J0bTJe006994@drugs.dv.isc.org> > > | Robert, I mentioned that this was a issue several years ago > | (on namedroppers / bind-workers) with respect to MX vs A > | and said that the search should stop on a NODATA response. > | You were quite happy for MX and A to hit different fqdn at > | the time. It looks like AAAA vs A has changed your opinion. > > Sorry, I don't remember the context, but the two cases aren't the same > at all. If I am looking for an MX record, I am looking for an MX > record. And if I want the MX record for "foo" that's what I want to > find. Only if there is no MX record for "foo" should a A lookup > even be attempted. > > On the other hand, when I want "the address of foo" (which is what > getaddrinfo() without a specific address type hint does), then I am > expressly asking for either an A or an AAAA (or even an A6...) Well given that if you are looking for a MX for "foo" you want to send mail to foo and the fallback if there isn't a MX for foo is to look for a address record I would say that it is a indentical senario. > | Agreed, however changing *default* resolver behaviour is > | difficult as it ends up breaking things. "localhost" > | lookups is what tends to break if you disable this. > > Only for badly configured zones - the name "localhost" should be > configured in every zone that is in a search list (if it doesn't > exist in a zone that is on the search list means that there is no > "localhost" existing, and the lookup should fail, going on to, > or locally configuring "localhost." isn't what should be being done. > > Because of the way the decision was made to ground FQDN's in a trailing dot, > but almost never actually represent it, there's no way for the PTR record > for 127.0.0.1 to actually return the FQDN "localhost." (or rather, that > could be done, but it never is). What's always returned is the > unqualified name, "localhost" > > | It's not only if the kernel is capable. It's also if there > | are interfaces configured. > > Sure, there should be a simple API for "should I attempt this AF?" > > I'd also be somewhat cautious about advising people to run non-standard > DNS setups. There are things that people who know what they're doing > can safely do - but which aren't really practical to advise for the > world to attempt to copy (and everyone snarfing the root zone probably > doesn't scale, even if it isn't one of the more dangerous things). And constantly querying the root servers does? It's quite possible to make zone transfers scale. You get your copy from your ISP. Your ISP gets a copy from the roots / dedictated "stealth" root server. Anyway this need to be analysed. > > kre > -- 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 Jul 18 20:02:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J32AoN021412; Thu, 18 Jul 2002 20:02:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J32A2s021411; Thu, 18 Jul 2002 20:02:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J327oN021404 for ; Thu, 18 Jul 2002 20:02:07 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA12545 for ; Thu, 18 Jul 2002 20:02:09 -0700 (PDT) Received: from delta.cs.mu.OZ.AU ([133.93.71.210]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08270 for ; Thu, 18 Jul 2002 20:02:09 -0700 (PDT) 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 g6J319812156; Fri, 19 Jul 2002 12:01:10 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Mark.Andrews@isc.org cc: Ted_Rule@flextech.co.uk, ipng@sunroof.eng.sun.com Subject: Re: getaddrinfo DNS search order issues In-Reply-To: <200207190252.g6J2qwJe008015@drugs.dv.isc.org> References: <200207190252.g6J2qwJe008015@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jul 2002 12:01:09 +0900 Message-ID: <12154.1027047669@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 19 Jul 2002 12:52:58 +1000 From: Mark.Andrews@isc.org Message-ID: <200207190252.g6J2qwJe008015@drugs.dv.isc.org> | Well given that if you are looking for a MX for "foo" you | want to send mail to foo and the fallback if there isn't a | MX for foo is to look for a address record I would say that | it is a indentical senario. No, one is explicitly looking for an MX, the other is looking for any address. It is only appropriate to look for the A record corresponding to a name if the MX record is first found not to exist. Finding an A record that might apply to some other variant of the name is irrelevant. You'd have to complete the MX search anyway. On the other hand, "find me any A or AAAA records" is satisfied by either A, or AAAA or both. 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 Jul 18 20:24:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J3OToN021507; Thu, 18 Jul 2002 20:24:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J3OTZr021506; Thu, 18 Jul 2002 20:24:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J3OQoN021499 for ; Thu, 18 Jul 2002 20:24:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA29993 for ; Thu, 18 Jul 2002 20:24:29 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21860 for ; Thu, 18 Jul 2002 21:24:27 -0600 (MDT) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g6J3O7Je008891; Fri, 19 Jul 2002 13:24:07 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200207190324.g6J3O7Je008891@drugs.dv.isc.org> To: Robert Elz Cc: Ted_Rule@flextech.co.uk, ipng@sunroof.eng.sun.com From: Mark.Andrews@isc.org Subject: Re: getaddrinfo DNS search order issues In-reply-to: Your message of "Fri, 19 Jul 2002 12:01:09 +0900." <12154.1027047669@munnari.OZ.AU> Date: Fri, 19 Jul 2002 13:24:07 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Fri, 19 Jul 2002 12:52:58 +1000 > From: Mark.Andrews@isc.org > Message-ID: <200207190252.g6J2qwJe008015@drugs.dv.isc.org> > > | Well given that if you are looking for a MX for "foo" you > | want to send mail to foo and the fallback if there isn't a > | MX for foo is to look for a address record I would say that > | it is a indentical senario. > > No, one is explicitly looking for an MX, the other is looking for > any address. It is only appropriate to look for the A record > corresponding to a name if the MX record is first found not to > exist. Finding an A record that might apply to some other variant > of the name is irrelevant. You'd have to complete the MX search anyway. > > On the other hand, "find me any A or AAAA records" is satisfied by > either A, or AAAA or both. > > kre Well when I type "mail user@foo" I don't care if there is a MX record or not. MX records are NOT manditory. Until they are made manditory the search for MX and address records should be done in parallel. This is the same as the search for A / AAAA / A6 should be done in parallel even if you are *not* going to return one of the address families. 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 Jul 18 20:55:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J3t3oN021544; Thu, 18 Jul 2002 20:55:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J3t21P021543; Thu, 18 Jul 2002 20:55:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J3swoN021536 for ; Thu, 18 Jul 2002 20:54:58 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA21136 for ; Thu, 18 Jul 2002 20:55:01 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00145 for ; Thu, 18 Jul 2002 21:55:00 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:944b:74ea:3301:7fbb]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6J3qmA00133; Fri, 19 Jul 2002 12:52:48 +0900 (JST) Date: Fri, 19 Jul 2002 12:52:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Robert Elz , Francis Dupont , ipng@sunroof.eng.sun.com Subject: Re: Prefix Delegation Requirements and comparison In-Reply-To: References: <200207181116.g6IBG8GF072312@givry.rennes.enst-bretagne.fr> <8175.1026999166@munnari.OZ.AU> <7t51ya1ezyh.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 19 Jul 2002 12:51:58 +0900, >>>>> JINMEI Tatuya said: >>>>> On Thu, 18 Jul 2002 17:57:26 +0100, >>>>> Ole Troan said: >> if you don't mind, please let's try to focus on prefix delegation on >> this thread. griefs with DHCP based address assignment can be taken on >> the DHC list. I don't think we need to do the 'H' in DHCP means host >> discussion again either. > I free agree. ^^^^should be "fully" JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 18 21:00:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J403oN021599; Thu, 18 Jul 2002 21:00:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J403DQ021598; Thu, 18 Jul 2002 21:00:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J3xvoN021591 for ; Thu, 18 Jul 2002 20:59:58 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA21919 for ; Thu, 18 Jul 2002 21:00:00 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA26889 for ; Thu, 18 Jul 2002 21:59:58 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:944b:74ea:3301:7fbb]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6J3puA00125; Fri, 19 Jul 2002 12:51:56 +0900 (JST) Date: Fri, 19 Jul 2002 12:51:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Robert Elz , Francis Dupont , ipng@sunroof.eng.sun.com Subject: Re: Prefix Delegation Requirements and comparison In-Reply-To: <7t51ya1ezyh.fsf@mrwint.cisco.com> References: <200207181116.g6IBG8GF072312@givry.rennes.enst-bretagne.fr> <8175.1026999166@munnari.OZ.AU> <7t51ya1ezyh.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 14 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 18 Jul 2002 17:57:26 +0100, >>>>> Ole Troan said: > if you don't mind, please let's try to focus on prefix delegation on > this thread. griefs with DHCP based address assignment can be taken on > the DHC list. I don't think we need to do the 'H' in DHCP means host > discussion again either. I free agree. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 19 01:33:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J8XjoN022235; Fri, 19 Jul 2002 01:33:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J8XiIY022234; Fri, 19 Jul 2002 01:33:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J8XboN022219; Fri, 19 Jul 2002 01:33:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17499; Fri, 19 Jul 2002 01:33:39 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14273; Fri, 19 Jul 2002 02:33:38 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6J8XXi12149; Fri, 19 Jul 2002 11:33:33 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Jul 2002 11:32:57 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 19 Jul 2002 11:32:57 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 19 Jul 2002 11:32:56 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6579E@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIuay+d+/st/HV1RuaOF1btR7N9uQAk10Sw To: , , Cc: , , , , X-OriginalArrivalTime: 19 Jul 2002 08:32:57.0411 (UTC) FILETIME=[E25CF930:01C22EFE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6J8XcoN022220 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pascal, > Face it: Many of today's large web servers will not want to > maintain binding caches. We are not talking about forcing deployments to use RO, but to have to code to support it & have code to support the HAO. Think of it this way, this might always be a premium service a web service could provide. If their OS has the code, they could selectively support RO to premium clients. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 19 15:45:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6JMjjoN023966; Fri, 19 Jul 2002 15:45:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6JMjjHW023965; Fri, 19 Jul 2002 15:45:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6JMjcoN023950; Fri, 19 Jul 2002 15:45:38 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21064; Fri, 19 Jul 2002 15:45:40 -0700 (PDT) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11765; Fri, 19 Jul 2002 16:45:39 -0600 (MDT) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 19 Jul 2002 15:45:38 -0700 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Re: summary of HAO, BE processing discussion MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22F76.00C6C21B" x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 Date: Fri, 19 Jul 2002 15:45:38 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF221@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: summary of HAO, BE processing discussion Thread-Index: AcIuJpR4gKOJXbemTYG0aTQaWrrv9QBTsxzQ From: "Mohan Parthasarathy" To: , "shima" Cc: , , , X-OriginalArrivalTime: 19 Jul 2002 22:45:38.0849 (UTC) FILETIME=[00F4E110:01C22F76] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C22F76.00C6C21B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 > >=20 > >>* IPv6 WG has in the past accepted the HAO as a mandatory > >> feature for all IPv6 nodes. Arguments have been made, > >> however, that the processing of the HAO has been changed > >> and the situation may now be different. > >> > >=20 > > In addition, the current draft requires not only HAO but=20 > also BE. This=20 > > means all IPv6 nodes must implement a new extention header=20 > (mobility=20 > > header). >=20 >=20 > Correct. >=20 If you read section 9.4.6, "Sending Binding Errors", yes it is correct. But reading section 6.3 "Home Address option", it says that if a node does not understand this option, it should return ICMP parameter problem. Are these in conflict ? thanks mohan ------_=_NextPart_001_01C22F76.00C6C21B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: summary of HAO, BE processing = discussion

     
    > >
    > >>* IPv6 WG has in the past accepted the = HAO as a mandatory
    > >>   feature for all IPv6 nodes. = Arguments have been made,
    > >>   however, that the = processing of the HAO has been changed
    > >>   and the situation may now = be different.
    > >>
    > >
    > > In addition, the current draft requires not = only HAO but
    > also BE. This
    > > means all IPv6 nodes must implement a new = extention header
    > (mobility
    > > header).
    >
    >
    > Correct.
    >
    If you read section 9.4.6, "Sending Binding = Errors", yes it is
    correct. But reading section 6.3 "Home Address = option", it says
    that if a node does not understand this option, it = should return
    ICMP parameter problem. Are these in conflict = ?

    thanks
    mohan

    ------_=_NextPart_001_01C22F76.00C6C21B-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 19 16:29:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6JNTvoN024187; Fri, 19 Jul 2002 16:29:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6JNTuth024186; Fri, 19 Jul 2002 16:29:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6JNTtoN024179 for ; Fri, 19 Jul 2002 16:29:55 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6JNTJGZ012687 for ; Fri, 19 Jul 2002 16:29:19 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6JNTJ4U012686 for ipng@sunroof.eng.sun.com; Fri, 19 Jul 2002 16:29:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J2GeoN020985; Thu, 18 Jul 2002 19:16:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16733; Thu, 18 Jul 2002 19:16:42 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06643; Thu, 18 Jul 2002 20:16:40 -0600 (MDT) Received: from PTHUBERTW2K2 (tokyo-vpn-user259.cisco.com [10.70.83.3]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id EAA12891; Fri, 19 Jul 2002 04:16:32 +0200 (MET DST) From: "Pascal Thubert" To: "Jari Arkko" Cc: , Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Fri, 19 Jul 2002 11:16:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D372E33.9010701@kolumbus.fi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jari: What I'm trying to get here: 1) SHOULD in 9.1. I support a requirement introduced in this thread. The requirement is to legalize hosts that would not support MIP for valid reasons. I provided examples where I think it's needed. I also believe there should be a little rewording in section 9.1 to come with it. 2) Minimize the content of the SHOULD. I propose a slight change in the draft in order to decline RO at RR test time in an architected fashion as opposed to side effect of ICMP errors. At this point, the binding flow is not part of the SHOULD anymore. Since 9.4.6 should not occur, I suppose that an ICMP error would be fine in that case. The problem is that the politically correct way to decline RO at the moment seems to be binding Ack with code 130 Insufficient resources (correct?), which requires support for BU. Since we are foreseeing the overloading of the RR test as a capability negociation mechanism (e.g. C1), could we not just architect something to negotiate Bind capabilities there already? The discussion about whether binding cache and Home Address option are necessarily coupled is yet an other one, which is related to C1 and C2. I tried to give an example where they could be separated by using piggy backing instead of an SA, but that discussion is not needed right now. I started that to decouple the RR test and the binding flow a little bit more. Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Jari Arkko Sent: Thursday, July 18, 2002 11:08 PM To: Pascal Thubert Cc: Behcet Sarikaya; Michael Thomas; john.loughney@nokia.com; itojun@iijlab.net; vijayd@iprg.nokia.com; keiichi@iij.ad.jp; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated Pascal Thubert wrote: > Face it: Many of today's large web servers will not want to maintain binding > caches. Because: > - They are clustered (see my previous mail on this thread) > - Visits are short and unrelated (the caches are not reused) > - RR reduces the throughput and the response time The current spec allows CNs to decline a RO/RR request. This is of course necessary, we couldn't mandate that they have sufficient memory etc. in all cases to handle these requests. > - They may even blindly accept the Home Address option since the AAA takes place > at session level anyway using cookies and such. Most likely we can't do this. Earlier analysis indicated that unverified home address option could lead to reflection attacks. > How much of the global IP traffic does this represent today? What will mobile > devices do at least in the short term? We must provide a way for servers to > simply and politely decline RO. We may want to permit triangular routing. The > minimum we can do to ease IPv6 transition is at least to allow the current v4 > applications to run in equivalent conditions. Yes, and they can decline RO already now. Triangular routing will only be allowed under a special condition (existing SA), which I think is probably not compatible with your scenario of web servers. > It's a SHOULD. I'm not really arguing against that... Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 19 16:30:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6JNUKoN024197; Fri, 19 Jul 2002 16:30:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6JNUK2Z024196; Fri, 19 Jul 2002 16:30:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6JNUJoN024189 for ; Fri, 19 Jul 2002 16:30:19 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6JNThGZ012695 for ; Fri, 19 Jul 2002 16:29:43 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6JNThMp012694 for ipng@sunroof.eng.sun.com; Fri, 19 Jul 2002 16:29:43 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6JBiNoN023002 for ; Fri, 19 Jul 2002 04:44:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03451 for ; Fri, 19 Jul 2002 04:44:25 -0700 (PDT) Received: from parsmtp2.rd.francetelecom.com (parsmtp2.rd.francetelecom.com [194.167.105.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03725 for ; Fri, 19 Jul 2002 05:44:24 -0600 (MDT) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 19 Jul 2002 13:44:20 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: draft-ietf-ipv6-dns-discovery-05.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 19 Jul 2002 13:44:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: getaddrinfo DNS search order issues Thread-Index: AcIu1Az9zuSEFJqFEdazdwCAXxnaMAAP5SCQ From: "BELOEIL Luc FTRD/DMI/CAE" To: X-OriginalArrivalTime: 19 Jul 2002 11:44:20.0024 (UTC) FILETIME=[9E88AB80:01C22F19] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6JBiOoN023003 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I think that the idea is bright because simple but I have still a couple of questions on section 5.2 even if it's only an example: 1/ Site borders in section 5.2 I do not think that multi-sited routers are a good idea for customers' CPE . Because one of the interface belongs to a customer device, I do not think that ISP will be able (allowed) to manage that interface. Moreover ISP may not want its customers to be able to access its internal site-scoped services. So CPE should not be part of ISP site, but if the ISP defines a special site for customers accesses. Anyway, I know that is a deployment issue... 2/ multi-sited CPE configuration Here I consider I've solved issue 1/. The CPE must be able to manage address scopes like described in draft-ietf-ipngwg-scoping-arch-04.txt. Does anyone know a DNS resolver implementation that can deal with addresses scopes? My purpose is to solve following issue : Customer client --- DNS query to fec0:0:0:ffff::1 --> Customer CPE (DNS resolver) -- DNS query forwarded to fec0:0:0:ffff::1 --> ISP DNS resolver Luc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 19 16:30:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6JNUgoN024210; Fri, 19 Jul 2002 16:30:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6JNUgAX024209; Fri, 19 Jul 2002 16:30:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6JNUeoN024200 for ; Fri, 19 Jul 2002 16:30:40 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6JNU4GZ012703 for ; Fri, 19 Jul 2002 16:30:04 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6JNU4Sa012702 for ipng@sunroof.eng.sun.com; Fri, 19 Jul 2002 16:30:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6JD9BoN023100; Fri, 19 Jul 2002 06:09:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27181; Fri, 19 Jul 2002 06:09:13 -0700 (PDT) Received: from relay-1m.club-internet.fr (relay-1m.club-internet.fr [194.158.104.40]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25926; Fri, 19 Jul 2002 07:09:12 -0600 (MDT) Received: from mine.club-internet.fr (lns04v-8-35.w.club-internet.fr [212.194.67.35]) by relay-1m.club-internet.fr (Postfix) with ESMTP id 8D5191696; Fri, 19 Jul 2002 15:09:06 +0200 (CEST) Message-Id: <5.1.0.14.0.20020719023808.02936130@mail.club-internet.fr> X-Sender: jefsey@mail.club-internet.fr X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 19 Jul 2002 15:11:01 +0200 To: Randy Bush From: "J-F C. (Jefsey) Morfin" Subject: Re: (ngtrans) Re: RFC 1886 Interop Tests & Results Cc: namedroppers , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: References: <1026847384.23224.49.camel@red> <5.1.1.6.2.20020717095218.02c556c0@localhost> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-563738A2; boundary="=======69AA4E90=======" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=======69AA4E90======= Content-Type: text/plain; x-avg-checked=avg-ok-563738A2; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit At 00:21 19/07/02, Randy Bush wrote: > > The frustration results from an uncompleted report. The target is to > > demonstrate that different thinking families can have the same reading of > > the specs and can develop from them compatible softwares. > >i missed the part about "different thinking families" in 2026. > >in the ietf, we still occasionally try NOT to make things more complex >than they must be. This misunderstanding says all. We want to test the text. The closer the reader is from the authors the easier for him to understand what may not be obvious to others. To make sure that things are not more complex than they could be we want to check and report that the largest number will read the specs in the same way. A scientific protocol of testing includes a description of the testing tools, which very often they are not named for the very reasons quoted here. Here the testing tools are people's brains. I don not want to know who they are, but the way they read. That France Telecom was part of it, tells me that I may be able to read correctly. This is what I name "thinking families": as many parameters may have to be considered in that kind of testing. jfc --=======69AA4E90=======-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 00:55:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6K7tPoN025017; Sat, 20 Jul 2002 00:55:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6K7tP5X025016; Sat, 20 Jul 2002 00:55:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6K7tMoN025009 for ; Sat, 20 Jul 2002 00:55:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24060 for ; Sat, 20 Jul 2002 00:55:23 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06638 for ; Sat, 20 Jul 2002 00:55:22 -0700 (PDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 02627395; Sat, 20 Jul 2002 00:55:22 -0700 (PDT) Date: Sat, 20 Jul 2002 00:55:21 -0700 From: David Terrell To: Alain Durand Cc: Jeroen Massar , itojun@iijlab.net, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Message-ID: <20020720075521.GA7995@pianosa.catch22.org> Reply-To: David Terrell References: <001e01c22e53$3594e970$534510ac@cyan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 12:52AM up 12 days, 45 mins, 31 users, load averages: 0.24, 0.30, 0.38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Jul 18, 2002 at 03:04:00PM +0200, Alain Durand wrote: > > On Thursday, July 18, 2002, at 02:03 PM, Jeroen Massar wrote: > > That would give very interresting results indeed, so let's add > >the fact > >that it for example BIND have to be configged for such a delegation > >like: > > > >zone "4.2.0.0.0.0.2.4.1.1.8.e.f.f.3.ip6.int" { > > type ipv6nodeinfo; > > allow_names "*.unfix.org"; > > check_forward yes; > >}; > > > >This would then tell BIND to do nodeinfo queries for > >3ffe:8114:2000:240::/60. > > This approach will work for the reverse mapping of > Site Local addresses if and only if the primary server and > all its secondary are all in the _same_ site local zone. > > If not the ICMP will go to the wrong place... This is yet another general problem with SL addressing which has been discussed before. One might imagine a configuration option that lets you restrict query access for SL addressing to site local (zone-based or otherwise configured local prefixes) requesters. Regardless, I like ICMP node lookup. Information is good. Being able to provide information is good. -- David Terrell | Just another satan-worshipping Harry Potter reader. dbt@meat.net | Nebcorp Prime Minister | http://wwn.nebcorp.com | -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 14:10:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6KLA5oN026155; Sat, 20 Jul 2002 14:10:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6KLA4lS026154; Sat, 20 Jul 2002 14:10:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6KLA1oN026147 for ; Sat, 20 Jul 2002 14:10:01 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01979 for ; Sat, 20 Jul 2002 14:10:01 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23374 for ; Sat, 20 Jul 2002 14:09:52 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 20DD44B22; Sun, 21 Jul 2002 06:09:08 +0900 (JST) To: David Terrell Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-reply-to: dbt's message of Sat, 20 Jul 2002 00:55:21 MST. <20020720075521.GA7995@pianosa.catch22.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: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Sun, 21 Jul 2002 06:09:06 +0900 Message-Id: <20020720210908.20DD44B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> On Thursday, July 18, 2002, at 02:03 PM, Jeroen Massar wrote: >> > That would give very interresting results indeed, so let's add >> >the fact >> >that it for example BIND have to be configged for such a delegation >> >like: >> >zone "4.2.0.0.0.0.2.4.1.1.8.e.f.f.3.ip6.int" { >> > type ipv6nodeinfo; >> > allow_names "*.unfix.org"; >> > check_forward yes; >> >}; i specifically mentioned in the draft (and presentation) that querier should be the node itself, as view of scope zone is different between them, and there's no way to pass scope zone info over DNS protocol (or identifying scopes). above example is OK as it is for global addresses, but for site-locals and link-locals, above approach (named translates DNS query into ICMPv6 node info query) does not work. minor implementation problem - non-privileged programs cannot generate ICMPv6. so we need: - a root-privileged daemon that sends ICMPv6 node info query, - communication channel from libc resolver to the daemon which does not lose scope info (DNS wire format doesn't work). unix domain socket, shared memory, whatever. current KAME revlookupd is problematical with respect to the latter bullet. http://www.kame.net/kame/kame/kame/revlookupd itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 20 15:41:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6KMfmoN026329; Sat, 20 Jul 2002 15:41:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6KMfmnW026328; Sat, 20 Jul 2002 15:41:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6KMfioN026321; Sat, 20 Jul 2002 15:41:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14946; Sat, 20 Jul 2002 15:41:45 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21660; Sat, 20 Jul 2002 16:41:44 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id AEEC64B22; Sun, 21 Jul 2002 07:41:37 +0900 (JST) To: Charlie Perkins Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: charliep's message of Wed, 17 Jul 2002 17:35:15 MST. <3D360D42.A934AA34@iprg.nokia.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: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Sun, 21 Jul 2002 07:41:37 +0900 Message-Id: <20020720224137.AEEC64B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The home address option is the same in format as the >previous version. The additional requirement now is >only that now it's required to be secured somehow. no it is not. also option type # got changed draft 04-06: type, length and an IPv6 address, type # = "196???" draft 07: type, length, an IPv6 address and suboptions, type # = "196???" draft 08-16: type, length, an IPv6 address and suboptions, type # = 201 draft 17-18: type, length and an IPv6 address, type # = 201 note that existence/non-existence of suboption will affect validation of incoming messages. no wonder vendors ship without HAO support, it is impossible to support something that changes this often. as for *BSD/KAME, it is decided that we won't merge anything related to mobile-ip6 into main *BSD distribution until mobile-ip6 becomes RFC (so it won't show up onto ExtremeWare, JunOS, MacOS X, ...). if i remember correctly WinXP is shipping with HAO support, i'm not sure which draft it is based. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 20 17:07:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6L07ioN026634; Sat, 20 Jul 2002 17:07:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6L07i6R026633; Sat, 20 Jul 2002 17:07:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6L07eoN026626 for ; Sat, 20 Jul 2002 17:07:40 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28606 for ; Sat, 20 Jul 2002 17:07:43 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01447 for ; Sat, 20 Jul 2002 18:07:41 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 549884B22; Sun, 21 Jul 2002 09:07:36 +0900 (JST) To: Ted Lemon Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: Ted.Lemon's message of Sat, 20 Jul 2002 16:53:10 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Sun, 21 Jul 2002 09:07:36 +0900 Message-Id: <20020721000736.549884B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >What do people think of signing the ICMP packet with the private key that >corresponds to a KEY RR that is attached to the name mentioned in the ICMP >packet? i may be asking a stupid question, but where do you get that private key from? for instance, if a node responds with "www.ietf.org", we could get a public key for www.ietf.org by KEY RR query, but not the private key (it's on ietf.org authoritative server, and is not accessible from outside). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 20 17:27:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6L0RcoN026699; Sat, 20 Jul 2002 17:27:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6L0RcqT026698; Sat, 20 Jul 2002 17:27:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6L0RYoN026691 for ; Sat, 20 Jul 2002 17:27:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22442 for ; Sat, 20 Jul 2002 17:27:37 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA16301 for ; Sat, 20 Jul 2002 18:27:35 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 448FE4B22; Sun, 21 Jul 2002 09:27:31 +0900 (JST) Cc: Ted Lemon , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Sun, 21 Jul 2002 09:07:36 +0900. <20020721000736.549884B22@coconut.itojun.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: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Sun, 21 Jul 2002 09:27:31 +0900 Message-Id: <20020721002731.448FE4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>What do people think of signing the ICMP packet with the private key that >>corresponds to a KEY RR that is attached to the name mentioned in the ICMP >>packet? > i may be asking a stupid question, but where do you get that private > key from? for instance, if a node responds with "www.ietf.org", > we could get a public key for www.ietf.org by KEY RR query, but > not the private key (it's on ietf.org authoritative server, and > is not accessible from outside). aha, now i see what you mean... the ICMPv6 node information responder would sign it, and every nodes have secret key on their own. the now problem is there's no generic public-key signing protocol in L3. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 20 23:58:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6L6wdoN027340; Sat, 20 Jul 2002 23:58:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6L6wcSU027339; Sat, 20 Jul 2002 23:58:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6L6wZoN027332 for ; Sat, 20 Jul 2002 23:58:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA01301 for ; Sat, 20 Jul 2002 23:58:36 -0700 (PDT) From: Mark.Andrews@isc.org Received: from peoplemail.com.cn ([202.99.23.242]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA24480 for ; Sun, 21 Jul 2002 00:58:35 -0600 (MDT) Received: from peoplemail.com.cn([127.0.0.1]) by peoplemail.com.cn(JetMail 2.5.3.0) with SMTP id jm43d3ab087; Sun, 21 Jul 2002 06:58:14 -0000 Received: from nwkea-mail-1.sun.com([192.18.42.13]) by peoplemail.com.cn(JetMail 2.5.3.0) with SMTP id jm03d37e190; Fri, 19 Jul 2002 04:56:53 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18065; Thu, 18 Jul 2002 17:41:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25045; Thu, 18 Jul 2002 17:40:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J0c7oN020810; Thu, 18 Jul 2002 17:38:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6J0c6sE020809; Thu, 18 Jul 2002 17:38:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6J0c3oN020802 for ; Thu, 18 Jul 2002 17:38:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09459 for ; Thu, 18 Jul 2002 17:38:04 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26669 for ; Thu, 18 Jul 2002 18:38:02 -0600 (MDT) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g6J0bTJe006994; Fri, 19 Jul 2002 10:37:31 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200207190037.g6J0bTJe006994@drugs.dv.isc.org> To: Robert Elz Cc: Ted_Rule@flextech.co.uk, ipng@sunroof.eng.sun.com Subject: Re: getaddrinfo DNS search order issues In-reply-to: Your message of "Thu, 18 Jul 2002 23:55:47 +0900." <8477.1027004147@munnari.OZ.AU> Date: Fri, 19 Jul 2002 10:37:29 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Thu, 18 Jul 2002 14:35:24 +0100 > From: Ted_Rule@flextech.co.uk > Message-ID: <80256BFA.004AA555.00@fttvgpslnhub1.flextech.co.uk> > > | I can't quite decide whether the problem is the down to the IPv6 or DNSEx > t > | Groups to solve, > > Probably neither, most of what you're describing is just implementation bugs. > Talk to the implementors of the stack/library, and get it fixed. > > > | getaddrinfo() performs an outer loop across all known address families- > | in this case IPv6 and IPv4 in that order, > > While this makes the implementation easy, it is almost certainly not the > right way - since (in this scenario) both AAAA and A records would be > wanted (otherwise it would only be doing one of the queries) it really > should be doing both at once. Not all the AAAA and then all the A. > That just turns out to be harder with the internal library interfaces > as they currently exist that the current scheme. Robert, I mentioned that this was a issue several years ago (on namedroppers / bind-workers) with respect to MX vs A and said that the search should stop on a NODATA response. You were quite happy for MX and A to hit different fqdn at the time. It looks like AAAA vs A has changed your opinion. It looks like we need a multi-type search algorithm which can optionally stop on match or continue to look for the rest of the types. > | Because all Unix resolver libraries I've been able to test force a > | last-resort search path of "." > > That's another bug - failing to add a domain should only ever be done > to a name that already has dots, a name like "grumpy" (that is, not "grumpy." > ) > should never be looked up by normal applications, some default domain > should always be appended. (Diagnostic tools can behave differently > sometimes). This is configurable in modern resolvers. > | The problem, of course, is that the "grumpy. AAAA" lookup is forced > | to query all the way up to the root servers > > Just sloppy implementation. Nothing in any spec requires that. Agreed, however changing *default* resolver behaviour is difficult as it ends up breaking things. "localhost" lookups is what tends to break if you disable this. > | As a nasty kludge fix for my local Linux boxes, where most of the kernels > | happen to have been built without IPv6 support whilst the sockets > | library was still IPv6 capable, I was able to patch fix the problem > | to an extent by making the telnet client call getaddrinfo with AF_UNSPEC > | if and only if it was capable of successfully opening a test IPv6 socket > > That's a high overhead way of achieving a simple result (high because it > will often require two additional system calls - one to open, another to > close again) just to find out if the stack is IPv6 (or 4 for that matter) > capable. There should be an easier way in the API to achieve this. > That's something which might be an ipv6 working group issue. It's not only if the kernel is capable. It's also if there are interfaces configured. Interface scanning is a pain to do in a portable manner. Multiple ioctl and structures with the same names but different results / layouts. > | Another possible workround is to enhance the API to include some form > | of ioctl() like call which returns the number of interfaces of a given > | family configured on a host. > > That sounds like more info than is required. > > | A side effect of this is that even during normal - fully Internet connect > ed > | times - local dual stack hosts will > | be busy annoying the root servers will TLD level AAAA lookups which > | invariably return NXDOMAIN. > > Lots of things annoy the root servers. But the implementation bug should > be fixed. This is not the forum to achieve that however. > > For what it is worth, the same problem can easily occur (and does occur, > though there are less implementations that suffer as much these days as > there used to be) without any IPv6 anywhere. > > | The above might even argue for a redefinition of DNS itself, > | banning A/AAAA/A6 records in a TLD, > > No, we don't need that. Agreed. > > | The other argument to be made is to ban the last resort lookup in the sea > rch > | path for A/AAAA/A6 records. It seems that Windows boxes manage completely > | happily without it. > > Everyone should be able to manage without it if the initial name has > no dots at all. Of course, if you had said "grumpy.subdomain" expecting > "grumpy.subdomain.dwarves.com" to be found, then a lookup for just > "grumpy.subdomain" is to be expected, and will often be attempted before > appending anything from the search path. This is where configuring your servers as stealth root servers becomes a big win, especially when you loose connectivity to the real roots. It also helps when you have resolvers that you can't turn off "try unqalified". If you do this however only have one nameserver at your site fetch the root zone and turn NOTIFY off (or make it explict). Now to just get the root zone's serial to reflect changes to the zones contents and not the time it was dumped from the whois database. You can also just configure a empty subdomain zone to intercept these queries. Watch out for conflicts with real tlds. The other thing to do is just not use partially qualified names, especially in configuration files. This is hard as it requires changing human behaviour. Mark > > 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 > -------------------------------------------------------------------- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 21 07:30:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LEUJoN028047; Sun, 21 Jul 2002 07:30:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LEUJit028046; Sun, 21 Jul 2002 07:30:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LEUGoN028039 for ; Sun, 21 Jul 2002 07:30:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05820 for ; Sun, 21 Jul 2002 07:30:16 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15197 for ; Sun, 21 Jul 2002 08:30:11 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6LETqC32213; Sun, 21 Jul 2002 16:29:57 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA22324; Sun, 21 Jul 2002 16:29:52 +0200 (MET DST) 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 g6LETnGF083958; Sun, 21 Jul 2002 16:29:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207211429.g6LETnGF083958@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: David Terrell , ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-reply-to: Your message of Sun, 21 Jul 2002 06:09:06 +0900. <20020720210908.20DD44B22@coconut.itojun.org> Date: Sun, 21 Jul 2002 16:29:49 +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: minor implementation problem - non-privileged programs cannot generate ICMPv6. so we need: => to solve this issue I added in my old "INRIA" stack at the request of Alain Durand a SOCK_CONTROL socket type which has access to information ICMPs. - a root-privileged daemon that sends ICMPv6 node info query, - communication channel from libc resolver to the daemon which does not lose scope info (DNS wire format doesn't work). unix domain socket, shared memory, whatever. current KAME revlookupd is problematical with respect to the latter bullet. http://www.kame.net/kame/kame/kame/revlookupd Regards Francis.Dupont@enst-bretagne.fr PS: the change is very small: a definition in sys/socket.h, an entry in netinet[6]/in[6]_proto.c and some new "if" cases in netinet[6]/raw_ip[6].c. I let Alain defend his (very good IMHO) idea. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 08:58:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LFwCoN028250; Sun, 21 Jul 2002 08:58:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LFwCBw028249; Sun, 21 Jul 2002 08:58:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LFw4oN028234; Sun, 21 Jul 2002 08:58:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18964; Sun, 21 Jul 2002 08:58:06 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28870; Sun, 21 Jul 2002 09:58: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 IAA22731; Sun, 21 Jul 2002 08:58:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6LFw3e18692; Sun, 21 Jul 2002 08:58:03 -0700 X-mProtect: <200207211558> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.111, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxI4hsh; Sun, 21 Jul 2002 08:57:59 PDT Message-ID: <3D3AD97F.F5D1927A@iprg.nokia.com> Date: Sun, 21 Jul 2002 08:55:43 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020720224137.AEEC64B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Itojun, Your argument is not very convincing: itojun@iijlab.net wrote: > >The home address option is the same in format as the > >previous version. The additional requirement now is > >only that now it's required to be secured somehow. > > no it is not. also option type # got changed > draft 04-06: type, length and an IPv6 address, type # = "196???" > draft 07: type, length, an IPv6 address and suboptions, > type # = "196???" These drafts are many years old. I reckon the base IPv6 specifications have a number of features that have changed more than the HAO option has changes since these very old drafts. > > draft 08-16: type, length, an IPv6 address and suboptions, type # = 201 > draft 17-18: type, length and an IPv6 address, type # = 201 There is no difference. There were no valid suboptions defined for earlier drafts, even though the field was shown as possibly there for future suboptions. In the drafts after 16, a reasonable implementation should still allow for future suboptions that don't exist yet. > no wonder vendors ship without HAO support, it is impossible to > support something that changes this often. as for *BSD/KAME, it is > decided that we won't merge anything related to mobile-ip6 into main > *BSD distribution until mobile-ip6 becomes RFC (so it won't show up > onto ExtremeWare, JunOS, MacOS X, ...). > if i remember correctly WinXP is shipping with HAO support, i'm not > sure which draft it is based. I hope things change after we have Proposed Standard and a number of interoperable implementations. I regret that your experience has caused discomfort. However, it is the nature of IETF Internet Drafts that they often change. Even Proposed Standards change. In fact, if I remember right, there is even now some movement towards changing the Draft Standard about site local addresses. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 21 14:28:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LLSNoN028699; Sun, 21 Jul 2002 14:28:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LLSNGr028698; Sun, 21 Jul 2002 14:28:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LLSJoN028691; Sun, 21 Jul 2002 14:28:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11109; Sun, 21 Jul 2002 14:28:20 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28538; Sun, 21 Jul 2002 15:28:17 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3C4D34B22; Mon, 22 Jul 2002 06:28:11 +0900 (JST) To: Charlie Perkins Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: charliep's message of Sun, 21 Jul 2002 08:55:43 MST. <3D3AD97F.F5D1927A@iprg.nokia.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: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Mon, 22 Jul 2002 06:28:11 +0900 Message-Id: <20020721212811.3C4D34B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> draft 08-16: type, length, an IPv6 address and suboptions, type # = 201 >> draft 17-18: type, length and an IPv6 address, type # = 201 >There is no difference. There were no valid suboptions defined for >earlier drafts, even though the field was shown as possibly there >for future suboptions. In the drafts after 16, a reasonable implementation >should still allow for future suboptions that don't exist yet. i don't think draft 17/18 implementation will allow suboptions. see the 17/18 languge about HAO option length. if we follow this, there's no chance we will see suboptions. you have to take a security stance. having loose inbound packet validation == more chances for security vulnerabilities. draft 17/18 implementations that allow option length != 16 are buggy. > Option Type > > 201 = 0xC9 > > Option Length > > 8-bit unsigned integer. Length of the option, in octets, > excluding the Option Type and Option Length fields. This field > MUST be set to 16. >> no wonder vendors ship without HAO support, it is impossible to >> support something that changes this often. as for *BSD/KAME, it is >> decided that we won't merge anything related to mobile-ip6 into main >> *BSD distribution until mobile-ip6 becomes RFC (so it won't show up >> onto ExtremeWare, JunOS, MacOS X, ...). >> if i remember correctly WinXP is shipping with HAO support, i'm not >> sure which draft it is based. >I hope things change after we have Proposed Standard and a number >of interoperable implementations. I regret that your experience has >caused discomfort. However, it is the nature of IETF Internet Drafts >that they often change. Even Proposed Standards change. In fact, >if I remember right, there is even now some movement towards >changing the Draft Standard about site local addresses. when moving from PS to DS, they *remove* functionality. they usually don't mandate new things. your example above does not convince me. i'm very concerned about the use of MUST for HAO since mobile-ip6 draft 18 is trying to mandate new thing to all IPv6 (RFC2460) implementations. SHOULD for HAO is okay for me, but MUST for HAO is unacceptable at this stage of RFC2460-based IPv6 deployment. 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 Sun Jul 21 14:58:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LLweoN028887; Sun, 21 Jul 2002 14:58:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LLweWw028886; Sun, 21 Jul 2002 14:58:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LLwWoN028871; Sun, 21 Jul 2002 14:58:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00731; Sun, 21 Jul 2002 14:58:33 -0700 (PDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA24392; Sun, 21 Jul 2002 14:58:31 -0700 (PDT) Received: from btmail.net.cn([202.106.196.72]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm83d3b59f7; Sun, 21 Jul 2002 21:58:27 -0000 Received: from nwkea-mail-1.sun.com([192.18.42.13]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm273d368549; Thu, 18 Jul 2002 03:57:33 -0000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05094; Wed, 17 Jul 2002 19:38:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25904; Wed, 17 Jul 2002 19:38:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2akoN013199 for ; Wed, 17 Jul 2002 19:36:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2akrN013198 for mobile-ip-dist; Wed, 17 Jul 2002 19:36:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2aaoN013174; Wed, 17 Jul 2002 19:36:37 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22174; Wed, 17 Jul 2002 19:36:39 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19124; Wed, 17 Jul 2002 19:36:38 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 8F9F06A906; Thu, 18 Jul 2002 05:36:37 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E92236A905; Thu, 18 Jul 2002 05:36:33 +0300 (EEST) Message-ID: <3D362A1E.3080101@kolumbus.fi> Date: Thu, 18 Jul 2002 05:38:22 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Keith Moore Cc: itojun@iijlab.net, Keiichi SHIMA / =?ISO-8859-1?Q?=3F=3F=3F?= , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <200207171531.g6HFVft12848@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > the purpose of a standard is to describe what is necessary for interoperability > and proper functioning of the protocol, not to legitimize existing > implementations. so the installed base shouldn't dictate whether a feature > is a MUST in a new version of a standard unless interoperability with the > installed base is important (it generally is) and imposing the MUST condition > on implementations that conform with the new version of the standard affects > interoperability with the installed base. Agree with all of the above. In this case, there are no interoperability problems. Since draft N-2 Mobile IPv6 has been able to work with IPv6 nodes that have *no* MIPv6 specific code. Again, this is separate from what the IETF may mandate for IPv6 nodes to support. To take a clearly unreasonable example, we could mandate every node to support a 1,000,000 entry bindind cache. Even with such a mandate a node conforming to this requirement would work with a node that has never heard of MIPv6. So, interoperability and must-implement are different in this particular case. I think that's good because we can then decide more freely what to require from all implementations. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 21 15:01:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LM14oN029338; Sun, 21 Jul 2002 15:01:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LM13gH029330; Sun, 21 Jul 2002 15:01:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LM0coN029174; Sun, 21 Jul 2002 15:00:38 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22409; Sun, 21 Jul 2002 15:00:39 -0700 (PDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA03896; Sun, 21 Jul 2002 15:00:37 -0700 (PDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm243d3b5a75; Sun, 21 Jul 2002 22:00:33 -0000 Received: from kathmandu.sun.com([192.18.98.36]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm03d366226; Thu, 18 Jul 2002 03:59:12 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22937; Wed, 17 Jul 2002 19:14:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA00103; Wed, 17 Jul 2002 18:14:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I1CXoN012378 for ; Wed, 17 Jul 2002 18:12:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I1CXdt012377 for mobile-ip-dist; Wed, 17 Jul 2002 18:12:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I1CUoN012370; Wed, 17 Jul 2002 18:12:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05406; Wed, 17 Jul 2002 18:12:31 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06648; Wed, 17 Jul 2002 18:12:31 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Jul 2002 21:07:05 -0400 Message-ID: From: Phil Roberts To: "'Francis Dupont'" , Vijay Devarapalli Cc: itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 17 Jul 2002 21:07:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A few issues have become mingled here. 1) Keiichi and others have raised the issue of MUST support for HAO and BE processing and have proposed a solution that allows communication to happen between any two nodes with clarification in the MIP spec of properly handling the ICMP errors returned. 2) There is a question about RO support requirements for all nodes. Actually the current spec doesn't give a recommendation for support of RO. If a node is supporting it, there are a bunch of MUSTs. We should make sure we agree as a working group on our consensus on these two issues. Perhaps we can sort this out on the MIP list first? > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Wednesday, July 17, 2002 8:57 PM > To: Vijay Devarapalli > Cc: itojun@iijlab.net; keiichi@iij.ad.jp; > mobile-ip@sunroof.eng.sun.com; > ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated > > > In your previous mail you wrote: > > > >it is. if a CN does not support HAO, it will send an > ICMP error message > > >pointing to the offending octet. when the MN receives > this message, it > > >starts reverse-tunneling through the Home Agent. where > is the problem? > > >if this is not clearly specified in the MIPv6 draft, it > can be. the > > >binding error functionality can also be substituted by > an ICMP error. > > >Binding Error was specified so that it is easier for > the MN to figure > > >out whats going on. > > > > then I see no reason for the MUST. > > I was discounting the reason (the already IPv6 installed base) you > gave. the MUST is for newer IPv6 CN implementations. as I told you > already, it makes the MN's life easier. but the current spec does > ensure that a MN can still have a session with an old IPv6 > implementation (which does not implement HAO) through reverse > tunneling. so again, where is the problem? why are you against the > MUST? > > => MUSTs are for interoperability problems, not for political matters. > So Itojun is right and the fact that old IPv6 nodes still work with > MNs proves the requirement should not be higher than SHOULD. > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: sorry but if someone is asking whether the RR/RO support should be > mandatory I'll vote against it. And I can't see how the iETF will > enforce it if I am being in the minority... > (the topics has just been added to the ipv6 WG session agenda) > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 21 15:24:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LMOLoN001049; Sun, 21 Jul 2002 15:24:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LMOL8T001048; Sun, 21 Jul 2002 15:24:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LMOHoN001041 for ; Sun, 21 Jul 2002 15:24:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05208 for ; Sun, 21 Jul 2002 15:24:18 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08550 for ; Sun, 21 Jul 2002 15:24:17 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1D7F64B22; Mon, 22 Jul 2002 07:24:14 +0900 (JST) To: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: Ted.Lemon's message of Sat, 20 Jul 2002 23:29:13 MST. <2C521845-9C73-11D6-B03B-00039317663C@nominum.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Mon, 22 Jul 2002 07:24:14 +0900 Message-Id: <20020721222414.1D7F64B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> i may be asking a stupid question, but where do you get that private >> key from? for instance, if a node responds with "www.ietf.org", >> we could get a public key for www.ietf.org by KEY RR query, but >> not the private key (it's on ietf.org authoritative server, and >> is not accessible from outside). >Presumably the device answering the ICMP request is the one named, >and therefore knows the private key associated with its name. no, the device answering ICMPv6 request is not named. with the "type ipv6nodeinfo" directive, named will work like this: - accept DNS query from a DNS client resolver. - send NI query to the target address. - receive NI response from the target. - send DNS response to the original DNS client resolver. since the NI query target can return arbitrary FQDN (like "www.ietf.org") named does not have the private key. client resolver ---------> named -------> the target DNS query NI query client resolver <--------- named <------- the target DNS response NI response 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 Sun Jul 21 16:52:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LNqfoN001235; Sun, 21 Jul 2002 16:52:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LNqfJB001234; Sun, 21 Jul 2002 16:52:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LNqXoN001219; Sun, 21 Jul 2002 16:52:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07690; Sun, 21 Jul 2002 16:52:35 -0700 (PDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA23426; Sun, 21 Jul 2002 16:52:32 -0700 (PDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm4d3d3b74b1; Sun, 21 Jul 2002 23:52:29 -0000 Received: from kathmandu.sun.com([192.18.98.36]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm893d367a78; Thu, 18 Jul 2002 05:52:23 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22309; Wed, 17 Jul 2002 20:40:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA23295; Wed, 17 Jul 2002 19:40:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2cGoN013309 for ; Wed, 17 Jul 2002 19:38:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I2cGqB013308 for mobile-ip-dist; Wed, 17 Jul 2002 19:38:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I2c6oN013287; Wed, 17 Jul 2002 19:38:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22501; Wed, 17 Jul 2002 19:38:08 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA22744; Wed, 17 Jul 2002 20:38:06 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 266876A906; Thu, 18 Jul 2002 05:38:00 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0C9856A905; Thu, 18 Jul 2002 05:37:56 +0300 (EEST) Message-ID: <3D362A71.20606@kolumbus.fi> Date: Thu, 18 Jul 2002 05:39:45 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: Vijay Devarapalli , john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65789@esebe004.NOE.Nokia.com> <15669.60922.686205.742010@thomasm-u1.cisco.com> <3D35FF20.2E5FCADF@iprg.nokia.com> <15670.1003.493633.920465@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > I guess the long and short of this is that I'm > somewhat skeptical of putting general node > requirements in the MIP draft since it's > probably not the first place one would be > looking to figure out if they were an IPv6 > compliant node. If it's really, really vital > for the health of the net, yadda, yadda, it > would be better to put it in a general v6 node > requirements RFC, don't you think? That _is_ actually the intention. We tried to formulate section 8.2. (RO requirements) in the MIPv6 draft so that it describes what you have to do to support RO, but not when you have to support it. And we are expecting the node requirements document to say MAY/SHOULD/MUST for the RO feature. I think that's the right place to make the determination. Ok? Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 21 23:30:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6M6USoN002843; Sun, 21 Jul 2002 23:30:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6M6URjV002842; Sun, 21 Jul 2002 23:30:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6M6UJoN002827; Sun, 21 Jul 2002 23:30:20 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA19024; Sun, 21 Jul 2002 23:30:19 -0700 (PDT) Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA03951; Sun, 21 Jul 2002 23:30:15 -0700 (PDT) Received: from btmail.net.cn([202.106.196.73]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm183d3bd1e5; Mon, 22 Jul 2002 06:30:09 -0000 Received: from kathmandu.sun.com([192.18.98.36]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jmb13d3709f7; Thu, 18 Jul 2002 12:29:53 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14634; Wed, 17 Jul 2002 23:22:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA29865; Wed, 17 Jul 2002 22:22:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5KPoN015423 for ; Wed, 17 Jul 2002 22:20:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6I5KPkV015422 for mobile-ip-dist; Wed, 17 Jul 2002 22:20:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6I5KLoN015415; Wed, 17 Jul 2002 22:20:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA18711; Wed, 17 Jul 2002 22:20:23 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA23539; Wed, 17 Jul 2002 22:20:22 -0700 (PDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA28494; Thu, 18 Jul 2002 14:20:21 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA28160; Thu, 18 Jul 2002 14:20:19 +0900 (JST) Date: Thu, 18 Jul 2002 14:18:50 +0900 (JST) Message-Id: <20020718.141850.32635405.keiichi@iij.ad.jp> To: jari.arkko@kolumbus.fi Cc: mat@cisco.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: summary of HAO, BE processing discussion From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3D3648E4.8050701@kolumbus.fi> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6578D@esebe004.NOE.Nokia.com> <3D3648E4.8050701@kolumbus.fi> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Let me add one thing. From: Jari Arkko > * IPv6 WG has in the past accepted the HAO as a mandatory > feature for all IPv6 nodes. Arguments have been made, > however, that the processing of the HAO has been changed > and the situation may now be different. In addition, the current draft requires not only HAO but also BE. This means all IPv6 nodes must implement a new extention header (mobility header). I never say that such a mechanism is bad at all. It is good of course. But from the view of the fast deployment of both IPv6 and Mobile IPv6, I personally think it better not to require additional requirements... This is not the view of the protocol designer, though. I'm probablly a bad designer and a bad scientist. I just want a real IPv6 and a Mobile IPv6... Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 00:06:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6M76woN004277; Mon, 22 Jul 2002 00:06:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6M76wFv004276; Mon, 22 Jul 2002 00:06:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6M76toN004269 for ; Mon, 22 Jul 2002 00:06:55 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA26623 for ; Mon, 22 Jul 2002 00:06:55 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09606 for ; Mon, 22 Jul 2002 01:06:28 -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 g6M75eY07916; Mon, 22 Jul 2002 14:05:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6J3cDd12319; Fri, 19 Jul 2002 12:38:13 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Imran Hafeez" cc: "'ipng@sunroof.eng.sun.com'" Subject: Re: Question on DHCPV6 RFC draft-ietf-dhc-dhcpv6-26.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jul 2002 12:38:13 +0900 Message-ID: <12317.1027049893@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 18 Jul 2002 12:10:19 -0500 From: "Imran Hafeez" Message-ID: | In the DHCPV6 RFC the IAADDR option specifies an IPV6 address but without | any indication to where the prefix & interface id starts and ends. However | if you read Radius RFC's for IPV6, they explicitly specify this information, | in otherwords they break the IPV6 address into its components. | | Does you know why it was done this way ? The boundaries in the addresses are for assignment purposes. Once the address has been assigned, the boundaries should be invisible in all further uses (including transmitting the address from the assignor (DHCP) to the asignee) kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 09:27:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MGREoN005526; Mon, 22 Jul 2002 09:27:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MGRET3005525; Mon, 22 Jul 2002 09:27:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MGR7oN005510; Mon, 22 Jul 2002 09:27:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17258; Mon, 22 Jul 2002 09:27:09 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21474; Mon, 22 Jul 2002 10:27:08 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6MGPWhI008750; Mon, 22 Jul 2002 09:25:32 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ACE93242; Mon, 22 Jul 2002 09:20:59 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA02944; Mon, 22 Jul 2002 09:25:32 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15676.12796.24879.810873@thomasm-u1.cisco.com> Date: Mon, 22 Jul 2002 09:25:32 -0700 (PDT) To: Basavaraj.Patil@nokia.com Cc: , , , Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A13156@daebe007.NOE.Nokia.com> References: <697DAA22C5004B4596E033803A7CEF44A13156@daebe007.NOE.Nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Basavaraj.Patil@nokia.com writes: > If the intent is to support mobility in IPv6 networks as an integral > aspect of the protocol, I believe the HAO processing is a MUST. I > believe the Mobile IP WG is of this opinion. That sure hasn't been my read of the consensus. In fact, the consensus seems to be exactly opposite. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 11:41:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MIfioN006625; Mon, 22 Jul 2002 11:41:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MIfiBD006624; Mon, 22 Jul 2002 11:41:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MIffoN006614; Mon, 22 Jul 2002 11:41:41 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24943; Mon, 22 Jul 2002 11:41:42 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06280; Mon, 22 Jul 2002 12:41:41 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6MIfYd22051; Mon, 22 Jul 2002 21:41:34 +0300 Date: Mon, 22 Jul 2002 21:41:33 +0300 (EEST) From: Pekka Savola To: Kuntal Chowdhury cc: mobile-ip@sunroof.eng.sun.com, Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <23BDB0046F3ED51185CD0002A5608D240528150F@zrc2c009.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Trimmed up the Cc: list a bit. I think this is getting way off topic though.. On Mon, 22 Jul 2002, Kuntal Chowdhury wrote: > Here are two of the reasons why I think RO will be undesirable: > > 1. It allows the users to entirely bypass the home IP provider's network. > This will keep the home IP network providers out of added revenue streams. > The situation will be even worse when the AAA clients for accounting are in > the home IP network which will not be in the data path due to RO. The data does not go to the home IP provider's network so there is absolutely zero reason be able to gain revenue from that. > 2. Imposes unnecessary processing requirement on ALL IPv6 devices to support > this non-mandatory functionality. My personal opinion is a SHOULD, but I think 'unnecessary' is a bit harsh. > Here is a reason why I think RO will be meaningless: > > The core of the internet is managed by large carriers. These carriers use > (or will be using) Constrained Based Routing (OSPF-TE) instead of plain > OSPF. In which world? > The main purpose is traffic engineering. Therefore the path between > the CN and the MN may not always be the shortest one even with RO. It > entirely depends on the traffic engineering of the intervening networks. As > an example: > If the CN is in Chicago, MN is in Dallas and the HA is in Miami, if the > shortest route between Chicago and Dallas has less weight (not preferred by > OSPF-TE) then all the IP packets between CN and the MN will be routed via an > alternative path which may well be via Miami. Therefore RO will be a waste > of time and resource. If TE is used to route the traffic via such slow paths the difference is noticeable (at least, without measurement tools), the network is designed and operated badly, period. Nobody would want to pay for that kind of service. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 12:18:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MJIIoN006945; Mon, 22 Jul 2002 12:18:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MJIHjD006944; Mon, 22 Jul 2002 12:18:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MJIEoN006934; Mon, 22 Jul 2002 12:18:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27609; Mon, 22 Jul 2002 12:18:15 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28373; Mon, 22 Jul 2002 13:18:14 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6MJD5d09271; Mon, 22 Jul 2002 14:13:05 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 14:12:50 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E04BFA175@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Michael Thomas , Basavaraj.Patil@nokia.com Cc: itojun@iijlab.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 14:12:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C231B3.C4E31A80" 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_01C231B3.C4E31A80 Content-Type: text/plain; charset="iso-8859-1" I thought it was already decided that a CN MUST respond with a rate limited "lack of resources" response to the request for route optimization. If this is the case then it seems to follow that the processing of the HOA for this purpose MUST also be supported if the HOA is to be a part of the request to do route optimization - but only to this extent. Perhaps some clarification in the draft is all that is necessary as to what is meant by the MUST. ------_=_NextPart_001_01C231B3.C4E31A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: HAO and BE processing will be mandated =

    I thought it was already decided that a CN MUST = respond with a rate limited "lack of resources" response to = the request for route optimization. If this is the case then it seems = to follow that the processing of the HOA for this purpose MUST also be = supported if the HOA is to be a part of the request to do route = optimization - but only to this extent. Perhaps some clarification in = the draft is all that is necessary as to what is meant by the = MUST.

     

    ------_=_NextPart_001_01C231B3.C4E31A80-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 12:20:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MJKEoN007074; Mon, 22 Jul 2002 12:20:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MJKDIB007073; Mon, 22 Jul 2002 12:20:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MJK8oN007055; Mon, 22 Jul 2002 12:20:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09142; Mon, 22 Jul 2002 12:20:10 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16264; Mon, 22 Jul 2002 12:20:08 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6MJEvd09601; Mon, 22 Jul 2002 14:14:58 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 14:14:43 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E04BFA18B@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: "Glenn Morrow" , Michael Thomas , Basavaraj.Patil@nokia.com Cc: itojun@iijlab.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 14:14:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C231B4.08176360" 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_01C231B4.08176360 Content-Type: text/plain; charset="iso-8859-1" sed r//HOA//HAO/g > -----Original Message----- > From: Morrow, Glenn [RICH2:C310:EXCH] > Sent: Monday, July 22, 2002 2:17 PM > To: 'Michael Thomas'; Basavaraj.Patil@nokia.com > Cc: itojun@iijlab.net; charliep@iprg.nokia.com; > mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated > > > I thought it was already decided that a CN MUST respond with > a rate limited "lack of resources" response to the request > for route optimization. If this is the case then it seems to > follow that the processing of the HOA for this purpose MUST > also be supported if the HOA is to be a part of the request > to do route optimization - but only to this extent. Perhaps > some clarification in the draft is all that is necessary as > to what is meant by the MUST. > > ------_=_NextPart_001_01C231B4.08176360 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Re: HAO and BE processing will be mandated

    sed r//HOA//HAO/g

    > -----Original Message-----
    > From: Morrow, Glenn [RICH2:C310:EXCH]
    > Sent: Monday, July 22, 2002 2:17 PM
    > To: 'Michael Thomas'; Basavaraj.Patil@nokia.com
    > Cc: itojun@iijlab.net; charliep@iprg.nokia.com;
    > mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com
    > Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated
    >
    >
    > I thought it was already decided that a CN MUST respond with
    > a rate limited "lack of resources" response to the request
    > for route optimization. If this is the case then it seems to
    > follow that the processing of the HOA for this purpose MUST
    > also be supported if the HOA is to be a part of the request
    > to do route optimization - but only to this extent. Perhaps
    > some clarification in the draft is all that is necessary as
    > to what is meant by the MUST.
    > 
    >

    ------_=_NextPart_001_01C231B4.08176360-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 13:31:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKV9oN007443; Mon, 22 Jul 2002 13:31:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MKV9kw007442; Mon, 22 Jul 2002 13:31:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKUroN007435 for ; Mon, 22 Jul 2002 13:30:53 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6MKUEGZ013634 for ; Mon, 22 Jul 2002 13:30:14 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6MKUEPS013633 for ipng@sunroof.eng.sun.com; Mon, 22 Jul 2002 13:30:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6KNr7oN026608 for ; Sat, 20 Jul 2002 16:53:07 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18712 for ; Sat, 20 Jul 2002 16:53:09 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08694 for ; Sat, 20 Jul 2002 16:53:09 -0700 (PDT) Received: from green.bisbee.fugue.com (a15.pm3-67.theriver.com [206.25.48.207]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6KNqod18744; Sat, 20 Jul 2002 23:52:51 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6KNrBfD000347; Sat, 20 Jul 2002 16:53:11 -0700 (MST) Date: Sat, 20 Jul 2002 16:53:10 -0700 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, itojun@iijlab.net, Jeroen Massar , Alain Durand To: David Terrell From: Ted Lemon In-Reply-To: <20020720075521.GA7995@pianosa.catch22.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Regardless, I like ICMP node lookup. Information is good. Being > able to provide information is good. Yup. I think having the mechanism is great. What do people think of signing the ICMP packet with the private key that corresponds to a KEY RR that is attached to the name mentioned in the ICMP packet? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 13:31:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKVJoN007453; Mon, 22 Jul 2002 13:31:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MKVJ3A007452; Mon, 22 Jul 2002 13:31:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKVHoN007445 for ; Mon, 22 Jul 2002 13:31:17 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6MKUcGZ013642 for ; Mon, 22 Jul 2002 13:30:38 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6MKUccE013641 for ipng@sunroof.eng.sun.com; Mon, 22 Jul 2002 13:30:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6L6T7oN027294 for ; Sat, 20 Jul 2002 23:29:07 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25245 for ; Sat, 20 Jul 2002 23:29:09 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA14661 for ; Sun, 21 Jul 2002 00:29:08 -0600 (MDT) Received: from green.bisbee.fugue.com (az-ben-pm3-2-12.ppp.theriver.com [206.25.50.12]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6L6Ssd20141; Sun, 21 Jul 2002 06:28:54 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6L6TDfD000489; Sat, 20 Jul 2002 23:29:13 -0700 (MST) Date: Sat, 20 Jul 2002 23:29:13 -0700 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com To: itojun@iijlab.net From: Ted Lemon In-Reply-To: <20020721000736.549884B22@coconut.itojun.org> Message-Id: <2C521845-9C73-11D6-B03B-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > i may be asking a stupid question, but where do you get that private > key from? for instance, if a node responds with "www.ietf.org", > we could get a public key for www.ietf.org by KEY RR query, but > not the private key (it's on ietf.org authoritative server, and > is not accessible from outside). Presumably the device answering the ICMP request is the one named, and therefore knows the private key associated with its name. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 13:31:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKVooN007463; Mon, 22 Jul 2002 13:31:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MKVoPT007462; Mon, 22 Jul 2002 13:31:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKVmoN007455 for ; Mon, 22 Jul 2002 13:31:48 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6MKV9GZ013650 for ; Mon, 22 Jul 2002 13:31:09 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6MKV9ud013649 for ipng@sunroof.eng.sun.com; Mon, 22 Jul 2002 13:31:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MFjdoN005270; Mon, 22 Jul 2002 08:45:39 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18224; Mon, 22 Jul 2002 08:45:41 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25272; Mon, 22 Jul 2002 09:45:40 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6MFnVj16102; Mon, 22 Jul 2002 10:49:31 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 10:45:38 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 10:45:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 10:45:36 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A13156@daebe007.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIw/bvWnlQi/O5cQtCbCv1U27ZizwAmRC1g To: , Cc: , X-OriginalArrivalTime: 22 Jul 2002 15:45:37.0411 (UTC) FILETIME=[D2F7DD30:01C23196] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6MFjeoN005271 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Itojun, > i'm very concerned about the use of MUST for HAO since > mobile-ip6 draft 18 is trying to mandate new thing to all IPv6 > (RFC2460) implementations. > SHOULD for HAO is okay for me, but MUST for HAO is unacceptable at > this stage of RFC2460-based IPv6 deployment. If the intent is to support mobility in IPv6 networks as an integral aspect of the protocol, I believe the HAO processing is a MUST. I believe the Mobile IP WG is of this opinion. If the IESG and the IPv6 WGs disagree with this opinion when the Mobile IPv6 spec goes to IETF last call we can deal with it. But for now I am in favor of keeping the MUST for the HAO processing for all IPv6 nodes. I am of the opinion that the scale of IPv6 deployment today is still in its infancy and the impacts associated with mandating the HAO processing on all IPv6 nodes is far less than maybe two years from now. > >itojun > -Basavaraj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 13:32:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKWeoN007487; Mon, 22 Jul 2002 13:32:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MKWe9G007486; Mon, 22 Jul 2002 13:32:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKWcoN007479 for ; Mon, 22 Jul 2002 13:32:38 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6MKVxGZ013658 for ; Mon, 22 Jul 2002 13:31:59 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6MKVxFe013657 for ipng@sunroof.eng.sun.com; Mon, 22 Jul 2002 13:31:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MHHvoN005802; Mon, 22 Jul 2002 10:17:57 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06142; Mon, 22 Jul 2002 10:17:58 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07318; Mon, 22 Jul 2002 10:17:57 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6MHISx07747; Mon, 22 Jul 2002 12:18:28 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Jul 2002 12:17:56 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 12:16:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C231A3.7A9D2A4A" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 12:16:12 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A1315C@daebe007.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIuITR8hcubAKJeTZWcDWWAP6l2RQDgj8bg To: , , Cc: , , , , X-OriginalArrivalTime: 22 Jul 2002 17:16:13.0868 (UTC) FILETIME=[7B595EC0:01C231A3] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C231A3.7A9D2A4A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Michael Thomas wrote:=20 >> Frankly, I don't think that there is any evidence=20 >> that the net would be substantially harmed if RO=20 >> wasn't widely implemented and/or enabled. Indeed,=20 >> I think there's good reason to believe that many/most=20 >> nodes will not enable RO even if their kernel=20 >> implements it. In some cases, it's likely to be=20 >> a nice and useful optimization, but I really=20 >> don't see it as a "if we don't do this the net=20 >> will fall apart". As such, SHOULD seems like it=20 >> strikes the right balance.=20 >>=20 >> Mike=20 >>=20 > >I could not agree more with this point. RO would be a required=20 >functionality a number of years back, when the net was in it's=20 >infancy and bandwidth availability in the backbone networks=20 >(even transoceanic links) were severely limited.=20 >We are in the age of OC-192/768s over DWDM. The delay that an IP=20 >packet incurs in the core is almost negligible.=20 >If bottleneck in the HA is the primary driver for RO, then it is=20 >possible to solve the problem with load balancing with DHAAD.=20 > >My two cents.=20 =20 RO gives you the capability of having two end-points connected without having to rely on intermediate nodes such as the HA being involved. The HA is not the bottleneck. One of the benefits of RO is lesser traffic in the backbone and to a certain degree reduced latency. But these are some of the lesser motivations.=20 =20 Having a mobile anchored at some point in the network (HA) when it is non-essential is just not the right approach. Mandating HAO processing in all IPv6 nodes is the only way to accomplish this and reverse tunnelling or having a node anchored at the HA is an option only for backward compatibility to the nodes that already deployed (which is a pretty small percentage of IP nodes). =20 > >Regards,=20 >Kuntal=20 > =20 -Basavaraj ------_=_NextPart_001_01C231A3.7A9D2A4A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: HAO and BE processing will be = mandated

    >Michael Thomas wrote:
    >>    = Frankly, I=20 don't think that there is any evidence
    >>    = that the=20 net would be substantially harmed if RO
    >>    = wasn't=20 widely implemented and/or enabled. Indeed, =
    >>    I=20 think  there's good reason to believe that many/most=20
    >>    nodes will not enable RO even if their = kernel=20
    >>    implements it. In some cases, it's likely = to be=20
    >>    a nice and useful optimization, but I = really=20
    >>    don't see it as a "if we don't do this = the net=20
    >>    will fall apart". As such, SHOULD seems = like it=20
    >>    strikes the right balance.
    >>=20
    >>          &= nbsp;  =20 Mike
    >>
    >
    >I could not agree more with this = point. RO=20 would be a required
    >functionality a number of years back, when = the net=20 was in it's
    >infancy and bandwidth availability in the backbone = networks=20
    >(even transoceanic links) were severely limited.
    >We are = in the=20 age of OC-192/768s over DWDM. The delay that an IP
    >packet incurs = in the=20 core is almost negligible.
    >If bottleneck in the HA is the = primary driver=20 for RO, then it is
    >possible to solve the problem with load = balancing=20 with DHAAD.
    >
    >My two cents.
     
    RO gives you the capability of having two end-points connected=20 without
    having to rely on intermediate nodes such as the HA=20 being
    involved. The HA is not the bottleneck. One of the benefits of = RO=20 is
    lesser traffic in the backbone and to a certain degree = reduced
    latency.=20 But these are some of the lesser motivations.
     
    Having a mobile anchored at some point in the network (HA) when it=20 is
    non-essential is just not the right approach. Mandating HAO=20 processing
    in all IPv6 nodes is the only way to accomplish this and=20 reverse
    tunnelling or having a node anchored at the HA is an option = only=20 for
    backward compatibility to the nodes that already deployed (which = is=20 a
    pretty small percentage of IP nodes).
     
    >
    >Regards,
    >Kuntal
    >
     
    -Basavaraj
    ------_=_NextPart_001_01C231A3.7A9D2A4A-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 13:33:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKX4oN007504; Mon, 22 Jul 2002 13:33:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MKX4wk007503; Mon, 22 Jul 2002 13:33:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKX2oN007496 for ; Mon, 22 Jul 2002 13:33:02 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6MKWNGZ013666 for ; Mon, 22 Jul 2002 13:32:23 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6MKWN9I013665 for ipng@sunroof.eng.sun.com; Mon, 22 Jul 2002 13:32:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MIFdoN006339; Mon, 22 Jul 2002 11:15:39 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28662; Mon, 22 Jul 2002 11:15:39 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10934; Mon, 22 Jul 2002 11:15:34 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6MIDtd20729; Mon, 22 Jul 2002 13:13:55 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 13:13:40 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D240528150F@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Basavaraj.Patil@nokia.com, mat@cisco.com, john.loughney@nokia.com Cc: itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 13:13:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C231AB.7F844A20" 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_01C231AB.7F844A20 Content-Type: text/plain Here are two of the reasons why I think RO will be undesirable: 1. It allows the users to entirely bypass the home IP provider's network. This will keep the home IP network providers out of added revenue streams. The situation will be even worse when the AAA clients for accounting are in the home IP network which will not be in the data path due to RO. 2. Imposes unnecessary processing requirement on ALL IPv6 devices to support this non-mandatory functionality. Here is a reason why I think RO will be meaningless: The core of the internet is managed by large carriers. These carriers use (or will be using) Constrained Based Routing (OSPF-TE) instead of plain OSPF. The main purpose is traffic engineering. Therefore the path between the CN and the MN may not always be the shortest one even with RO. It entirely depends on the traffic engineering of the intervening networks. As an example: If the CN is in Chicago, MN is in Dallas and the HA is in Miami, if the shortest route between Chicago and Dallas has less weight (not preferred by OSPF-TE) then all the IP packets between CN and the MN will be routed via an alternative path which may well be via Miami. Therefore RO will be a waste of time and resource. Regards, Kuntal >Michael Thomas wrote: >> Frankly, I don't think that there is any evidence >> that the net would be substantially harmed if RO >> wasn't widely implemented and/or enabled. Indeed, >> I think there's good reason to believe that many/most >> nodes will not enable RO even if their kernel >> implements it. In some cases, it's likely to be >> a nice and useful optimization, but I really >> don't see it as a "if we don't do this the net >> will fall apart". As such, SHOULD seems like it >> strikes the right balance. >> >> Mike >> > >I could not agree more with this point. RO would be a required >functionality a number of years back, when the net was in it's >infancy and bandwidth availability in the backbone networks >(even transoceanic links) were severely limited. >We are in the age of OC-192/768s over DWDM. The delay that an IP >packet incurs in the core is almost negligible. >If bottleneck in the HA is the primary driver for RO, then it is >possible to solve the problem with load balancing with DHAAD. > >My two cents. RO gives you the capability of having two end-points connected without having to rely on intermediate nodes such as the HA being involved. The HA is not the bottleneck. One of the benefits of RO is lesser traffic in the backbone and to a certain degree reduced latency. But these are some of the lesser motivations. Having a mobile anchored at some point in the network (HA) when it is non-essential is just not the right approach. Mandating HAO processing in all IPv6 nodes is the only way to accomplish this and reverse tunnelling or having a node anchored at the HA is an option only for backward compatibility to the nodes that already deployed (which is a pretty small percentage of IP nodes). > >Regards, >Kuntal > -Basavaraj ------_=_NextPart_001_01C231AB.7F844A20 Content-Type: text/html RE: [mobile-ip] Re: HAO and BE processing will be mandated
    Here are two of the reasons why I think RO will be undesirable:
     
    1. It allows the users to entirely bypass the home IP provider's network. This will keep the home IP network providers out of added revenue streams. The situation will be even worse when the AAA clients for accounting are in the home IP network which will not be in the data path due to RO.
     
    2. Imposes unnecessary processing requirement on ALL IPv6 devices to support this non-mandatory functionality.
     
    Here is a reason why I think RO will be meaningless:
     
    The core of the internet is managed by large carriers. These carriers use (or will be using) Constrained Based Routing (OSPF-TE) instead of plain OSPF. The main purpose is traffic engineering. Therefore the path between the CN and the MN may not always be the shortest one even with RO. It entirely depends on the traffic engineering of the intervening networks. As an example:
    If the CN is in Chicago, MN is in Dallas and the HA is in Miami, if the shortest route between Chicago and Dallas has less weight (not preferred by OSPF-TE) then all the IP packets between CN and the MN will be routed via an alternative path which may well be via Miami. Therefore RO will be a waste of time and resource.
     
     
    Regards,
    Kuntal
     
    >Michael Thomas wrote:
    >>    Frankly, I don't think that there is any evidence
    >>    that the net would be substantially harmed if RO
    >>    wasn't widely implemented and/or enabled. Indeed,
    >>    I think  there's good reason to believe that many/most
    >>    nodes will not enable RO even if their kernel
    >>    implements it. In some cases, it's likely to be
    >>    a nice and useful optimization, but I really
    >>    don't see it as a "if we don't do this the net
    >>    will fall apart". As such, SHOULD seems like it
    >>    strikes the right balance.
    >>
    >>              Mike
    >>
    >
    >I could not agree more with this point. RO would be a required
    >functionality a number of years back, when the net was in it's
    >infancy and bandwidth availability in the backbone networks
    >(even transoceanic links) were severely limited.
    >We are in the age of OC-192/768s over DWDM. The delay that an IP
    >packet incurs in the core is almost negligible.
    >If bottleneck in the HA is the primary driver for RO, then it is
    >possible to solve the problem with load balancing with DHAAD.
    >
    >My two cents.
     
    RO gives you the capability of having two end-points connected without
    having to rely on intermediate nodes such as the HA being
    involved. The HA is not the bottleneck. One of the benefits of RO is
    lesser traffic in the backbone and to a certain degree reduced
    latency. But these are some of the lesser motivations.
     
    Having a mobile anchored at some point in the network (HA) when it is
    non-essential is just not the right approach. Mandating HAO processing
    in all IPv6 nodes is the only way to accomplish this and reverse
    tunnelling or having a node anchored at the HA is an option only for
    backward compatibility to the nodes that already deployed (which is a
    pretty small percentage of IP nodes).
     
    >
    >Regards,
    >Kuntal
    >
     
    -Basavaraj
    ------_=_NextPart_001_01C231AB.7F844A20-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 13:33:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKXcoN007524; Mon, 22 Jul 2002 13:33:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MKXcP0007522; Mon, 22 Jul 2002 13:33:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKXaoN007513 for ; Mon, 22 Jul 2002 13:33:36 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6MKWvGZ013674 for ; Mon, 22 Jul 2002 13:32:57 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6MKWvhl013673 for ipng@sunroof.eng.sun.com; Mon, 22 Jul 2002 13:32:57 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MJGDoN006896; Mon, 22 Jul 2002 12:16:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26514; Mon, 22 Jul 2002 12:15:44 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13242; Mon, 22 Jul 2002 12:15:44 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6MJFnd09795; Mon, 22 Jul 2002 14:15:50 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jul 2002 14:15:35 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D24052E0FDD@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Pekka Savola Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 14:15:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C231B4.23C0AFE0" 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_01C231B4.23C0AFE0 Content-Type: text/plain; charset="iso-8859-1" > > Here are two of the reasons why I think RO will be undesirable: > > > > 1. It allows the users to entirely bypass the home IP provider's network. > > This will keep the home IP network providers out of added revenue streams. > > The situation will be even worse when the AAA clients for accounting are in > > the home IP network which will not be in the data path due to RO. > > The data does not go to the home IP provider's network so there is > absolutely zero reason be able to gain revenue from that. I don't think I understood your point. Are you agreeing with me or disagreeing? > > > 2. Imposes unnecessary processing requirement on ALL IPv6 > devices to support > > this non-mandatory functionality. > > My personal opinion is a SHOULD, but I think 'unnecessary' is > a bit harsh. > No comment. > > Here is a reason why I think RO will be meaningless: > > > > The core of the internet is managed by large carriers. > These carriers use > > (or will be using) Constrained Based Routing (OSPF-TE) > instead of plain > > OSPF. > > In which world? > Not sure which world it will be :o), but here are some links on TE: http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-06.txt http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-02.txt http://www.ietf.org/rfc/rfc3272.txt http://www.ietf.org/rfc/rfc3209.txt http://www.ietf.org/rfc/rfc3212.txt > > The main purpose is traffic engineering. Therefore the path between > > the CN and the MN may not always be the shortest one even with RO. It > > entirely depends on the traffic engineering of the intervening networks. As > > an example: > > If the CN is in Chicago, MN is in Dallas and the HA is in Miami, if the > > shortest route between Chicago and Dallas has less weight (not preferred by > > OSPF-TE) then all the IP packets between CN and the MN will be routed via an > > alternative path which may well be via Miami. Therefore RO will be a waste > > of time and resource. > > If TE is used to route the traffic via such slow paths the difference is > noticeable (at least, without measurement tools), the network is designed > and operated badly, period. Nobody would want to pay for that kind of > service. > What makes you think that the TEed route between the CN and the MN (i.e. Chicago -> Miami -> Dallas) will be a slow path? Do you think the shortest path is ALWAYS the best/fastest path? -Kuntal > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > ------_=_NextPart_001_01C231B4.23C0AFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: HAO and BE processing will be mandated =

    > > Here are two of the reasons why I think RO = will be undesirable:
    > > 
    > > 1. It allows the users to entirely bypass = the home IP provider's network.
    > > This will keep the home IP network = providers out of added revenue streams.
    > > The situation will be even worse when the = AAA clients for accounting are in
    > > the home IP network which will not be in = the data path due to RO.
    >
    > The data does not go to the home IP provider's = network so there is
    > absolutely zero reason be able to gain revenue = from that. 

    I don't think I understood your point. Are you = agreeing with me or disagreeing?

    >  
    > > 2. Imposes unnecessary processing = requirement on ALL IPv6
    > devices to support
    > > this non-mandatory functionality.
    >
    > My personal opinion is a SHOULD, but I think = 'unnecessary' is
    > a bit harsh.
    >  

    No comment.

    > > Here is a reason why I think RO will be = meaningless:
    > > 
    > > The core of the internet is managed by = large carriers.
    > These carriers use
    > > (or will be using) Constrained Based = Routing (OSPF-TE)
    > instead of plain
    > > OSPF.
    >
    > In which world?
    >

    Not sure which world it will be :o), but here are = some links on TE:

    http://www.ietf.org/internet-drafts/draft-katz-yeung-o= spf-traffic-06.txt
    http://www.ietf.org/internet-drafts/draft-srisuresh-os= pf-te-02.txt
    http://www.ietf.org/rfc/rfc3272.txt
    http://www.ietf.org/rfc/rfc3209.txt
    http://www.ietf.org/rfc/rfc3212.txt


    > > The main purpose is traffic engineering. = Therefore the path between
    > > the CN and the MN may not always be the = shortest one even with RO. It
    > > entirely depends on the traffic = engineering of the intervening networks. As
    > > an example:
    > > If the CN is in Chicago, MN is in Dallas = and the HA is in Miami, if the
    > > shortest route between Chicago and Dallas = has less weight (not preferred by
    > > OSPF-TE) then all the IP packets between = CN and the MN will be routed via an
    > > alternative path which may well be via = Miami. Therefore RO will be a waste
    > > of time and resource.
    >
    > If TE is used to route the traffic via such = slow paths the difference is
    > noticeable (at least, without measurement = tools), the network is designed
    > and operated badly, period.  Nobody would = want to pay for that kind of
    > service.
    >

    What makes you think that the TEed route between the = CN and the MN
    (i.e. Chicago -> Miami -> Dallas) will be a = slow path?
    Do you think the shortest path is ALWAYS the = best/fastest path?

    -Kuntal



    > --
    > Pekka = Savola           =       "Tell me of difficulties = surmounted,
    > Netcore = Oy           &nbs= p;       not those you stumble over and = fall"
    > Systems. Networks. Security.  -- Robert = Jordan: A Crown of Swords
    >
    >
    >

    ------_=_NextPart_001_01C231B4.23C0AFE0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 13:52:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKqZoN007858; Mon, 22 Jul 2002 13:52:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MKqZJS007857; Mon, 22 Jul 2002 13:52:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKqWoN007850; Mon, 22 Jul 2002 13:52:32 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14767; Mon, 22 Jul 2002 13:52:32 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15508; Mon, 22 Jul 2002 14:52:32 -0600 (MDT) Message-ID: <01bc01c231c0$d0b945c0$a66015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Kuntal Chowdhury" , , , Cc: , , , , References: <23BDB0046F3ED51185CD0002A5608D240528150F@zrc2c009.us.nortel.com> Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated Date: Mon, 22 Jul 2002 13:46:11 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B9_01C23186.23891400" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01B9_01C23186.23891400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: HAO and BE processing will be mandated Here are two = of the reasons why I think RO will be undesirable: =20 1. It allows the users to entirely bypass the home IP provider's = network. This will keep the home =20 IP network providers out of added revenue streams. The situation will = be even worse when the =20 AAA clients for accounting are in the home IP network which will not = be in the data path due to=20 RO. This is not a techical reason, this is a business reason. If we get into = this aspect of technology deployment, protocol designs might change in rather = strange ways :) I don't think we want to go there. Also, if any operator is trying to bill users by baning route = optimizations, what is their plan for non-Mobile IP? What happens when mobile node uses its care-of = address as its end point of a communication? Despite any protocol work here, an operator can still force all the = traffic to flow through home network, if it is determined to do so... alper =20 ------=_NextPart_000_01B9_01C23186.23891400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: HAO and BE processing will be = mandated
      = Here are=20 two of the reasons why I think RO will be = undesirable:
     
      = 1. It allows=20 the users to entirely bypass the home IP provider's network. This will = keep the=20 home 
      IP=20 network providers out of added revenue streams. The situation will be = even worse=20 when the 
      = AAA clients=20 for accounting are in the home IP network which will not be in the data = path due=20 to
      = RO.
     
    This is not a techical reason, this is a business reason. If we get = into=20 this aspect
    of technology deployment, protocol designs might change in = rather=20 strange ways :)
    I don't think we want to go there.
     
    Also, if any operator is trying to bill users by baning = route=20 optimizations, what is their
    plan for non-Mobile IP? What happens when mobile node uses its = care-of=20 address
    as its end point of a communication?
     
    Despite any protocol work here, an operator can still force all the = traffic=20 to
    flow through home network, if it is determined to do so...
     
    alper
     
     ------=_NextPart_000_01B9_01C23186.23891400-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 13:57:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKvWoN008014; Mon, 22 Jul 2002 13:57:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MKvWNl008013; Mon, 22 Jul 2002 13:57:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MKvToN008006; Mon, 22 Jul 2002 13:57:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28499; Mon, 22 Jul 2002 13:57:30 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06479; Mon, 22 Jul 2002 13:57:29 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6MKvMK23230; Mon, 22 Jul 2002 23:57:22 +0300 Date: Mon, 22 Jul 2002 23:57:22 +0300 (EEST) From: Pekka Savola To: Kuntal Chowdhury cc: mobile-ip@sunroof.eng.sun.com, Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <23BDB0046F3ED51185CD0002A5608D24052E0FDD@zrc2c009.us.nortel.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, 22 Jul 2002, Kuntal Chowdhury wrote: > > > > Here are two of the reasons why I think RO will be undesirable: > > > > > > 1. It allows the users to entirely bypass the home IP provider's > network. > > > This will keep the home IP network providers out of added revenue > streams. > > > The situation will be even worse when the AAA clients for accounting are > in > > > the home IP network which will not be in the data path due to RO. > > > > The data does not go to the home IP provider's network so there is > > absolutely zero reason be able to gain revenue from that. > > I don't think I understood your point. Are you agreeing with me or > disagreeing? Totally disagreeing. Assuming CN is in ISP 1's network, MN is vising ISP 2's network and HA is in ISP 3's network. Your argument was, if I got it right, that route optimizations is bad because traffic is between ISP 1 and ISP 2 so ISP 3 does not get revenue. This seems ridiculous. > > > Here is a reason why I think RO will be meaningless: > > > > > > The core of the internet is managed by large carriers. > > These carriers use > > > (or will be using) Constrained Based Routing (OSPF-TE) > > instead of plain > > > OSPF. > > > > In which world? > > > > Not sure which world it will be :o), but here are some links on TE: > > http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-06.txt > http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-02.txt > http://www.ietf.org/rfc/rfc3272.txt > http://www.ietf.org/rfc/rfc3209.txt > http://www.ietf.org/rfc/rfc3212.txt Sure, people write about it, but there's fiber in abundance. The problem is who is going to pay for the ISP for using it. This does not change the problem, only makes the problem more complex (like MPLS's TE components). > > If TE is used to route the traffic via such slow paths the difference is > > noticeable (at least, without measurement tools), the network is designed > > and operated badly, period. Nobody would want to pay for that kind of > > service. > > > > What makes you think that the TEed route between the CN and the MN > (i.e. Chicago -> Miami -> Dallas) will be a slow path? The speed of light is a constant. > Do you think the shortest path is ALWAYS the best/fastest path? Almost always, yes. When it's not, it's almost best, which is roughly the same thing. All of this amounts to advantages by route optimization. (I'm disregarding stuff like extremely severe network congestion here, as we're talking about stable scenarios here.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 15:54:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MMsaoN008570; Mon, 22 Jul 2002 15:54:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6MMsZ9a008569; Mon, 22 Jul 2002 15:54:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6MMsVoN008562; Mon, 22 Jul 2002 15:54:32 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28163; Mon, 22 Jul 2002 15:54:33 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23912; Mon, 22 Jul 2002 16:54:32 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 087BD4B24; Tue, 23 Jul 2002 07:54:21 +0900 (JST) To: Basavaraj.Patil@nokia.com Cc: charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: Basavaraj.Patil's message of Mon, 22 Jul 2002 10:45:36 EST. <697DAA22C5004B4596E033803A7CEF44A13156@daebe007.NOE.Nokia.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: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Tue, 23 Jul 2002 07:54:20 +0900 Message-Id: <20020722225421.087BD4B24@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I am of the opinion that the scale of IPv6 deployment today is still >in its infancy and the impacts associated with mandating the HAO >processing on all IPv6 nodes is far less than maybe two years from >now. here are a little (incomplete) list of RFC2460-compliant implementations that does not speak/understand HAO: JunOS, ExtremeWare, MacOS 10.2, all FreeBSD since 4.0, all NetBSD since 1.5, all OpenBSD since 2.7, Solaris beyond 2.7, Linux since 2.2, all BSD/OS since 4.1. and any product that ships with these operating systems (note that many uses *BSD in embedded products such as printers). and i would like to stress that it isn't matter of configuration, but matter of codebase (you can't say "well, they are not configured with IPv6"). and as you may aware, people do run older revisions of those operating systems (there still are Win3.1, you know). if it isn't enough to convince you otherwise, i think you are in a dream world. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 18:41:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N1f9oN009160; Mon, 22 Jul 2002 18:41:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N1f8bD009159; Mon, 22 Jul 2002 18:41:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N1f1oN009144; Mon, 22 Jul 2002 18:41:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24616; Mon, 22 Jul 2002 18:41:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA11224; Mon, 22 Jul 2002 19:41:01 -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 SAA09477; Mon, 22 Jul 2002 18:41:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6N1exw19574; Mon, 22 Jul 2002 18:40:59 -0700 X-mProtect: <200207230140> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd06HkRt; Mon, 22 Jul 2002 18:40:58 PDT Message-ID: <3D3CB42A.235F463D@iprg.nokia.com> Date: Mon, 22 Jul 2002 18:40:58 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <697DAA22C5004B4596E033803A7CEF44A13156@daebe007.NOE.Nokia.com> <15676.12796.24879.810873@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk you are both right. it was closed as 'Adopted' after there was concensus on the mailing list. see, issue 45 at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html it was reopened (unfortunately) as issue 53. Vijay Michael Thomas wrote: > > Basavaraj.Patil@nokia.com writes: > > If the intent is to support mobility in IPv6 networks as an integral > > aspect of the protocol, I believe the HAO processing is a MUST. I > > believe the Mobile IP WG is of this opinion. > > That sure hasn't been my read of the consensus. > In fact, the consensus seems to be exactly > opposite. > > Mike > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 18:46:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N1kpoN009308; Mon, 22 Jul 2002 18:46:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N1kpsi009305; Mon, 22 Jul 2002 18:46:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N1khoN009289; Mon, 22 Jul 2002 18:46:43 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26021; Mon, 22 Jul 2002 18:46:44 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18960; Mon, 22 Jul 2002 19:46:44 -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 SAA09749; Mon, 22 Jul 2002 18:46:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6N1kgv26226; Mon, 22 Jul 2002 18:46:42 -0700 X-mProtect: <200207230146> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4KPbqd; Mon, 22 Jul 2002 18:46:40 PDT Message-ID: <3D3CB580.708DE3A7@iprg.nokia.com> Date: Mon, 22 Jul 2002 18:46:40 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: Charlie Perkins , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020720224137.AEEC64B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, there have never been any suboptions defined for the home address option. itojun@iijlab.net wrote: > > >The home address option is the same in format as the > >previous version. The additional requirement now is > >only that now it's required to be secured somehow. > > no it is not. also option type # got changed > draft 04-06: type, length and an IPv6 address, type # = "196???" > draft 07: type, length, an IPv6 address and suboptions, > type # = "196???" > draft 08-16: type, length, an IPv6 address and suboptions, type # = 201 > draft 17-18: type, length and an IPv6 address, type # = 201 > > note that existence/non-existence of suboption will affect validation > of incoming messages. when there is no vaild sub-option defined, I would expect one to write code which would drop the packet, if the packet came with some sub-option. > no wonder vendors ship without HAO support, it is impossible to > support something that changes this often. it has been an internet draft so far. people who implement internet drafts do it knowing very well that it could change. > as for *BSD/KAME, it is > decided that we won't merge anything related to mobile-ip6 into main > *BSD distribution until mobile-ip6 becomes RFC (so it won't show up > onto ExtremeWare, JunOS, MacOS X, ...). okay. fair enough. regards Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 18:52:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N1qfoN009492; Mon, 22 Jul 2002 18:52:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N1qeSq009491; Mon, 22 Jul 2002 18:52:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N1qXoN009476; Mon, 22 Jul 2002 18:52:33 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19606; Mon, 22 Jul 2002 18:52:34 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20891; Mon, 22 Jul 2002 19:52:34 -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 SAA09968; Mon, 22 Jul 2002 18:52:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6N1qXD31896; Mon, 22 Jul 2002 18:52:33 -0700 X-mProtect: <200207230152> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdX4cpFh; Mon, 22 Jul 2002 18:52:31 PDT Message-ID: <3D3CB6DF.14DAA2CF@iprg.nokia.com> Date: Mon, 22 Jul 2002 18:52:31 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: Basavaraj.Patil@nokia.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020722225421.087BD4B24@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > here are a little (incomplete) list of RFC2460-compliant > implementations that does not speak/understand HAO: > > JunOS, ExtremeWare, MacOS 10.2, all FreeBSD since 4.0, all NetBSD > since 1.5, all OpenBSD since 2.7, Solaris beyond 2.7, Linux since 2.2, > all BSD/OS since 4.1. > > and any product that ships with these operating systems (note that > many uses *BSD in embedded products such as printers). > > and i would like to stress that it isn't matter of configuration, but > matter of codebase (you can't say "well, they are not configured with > IPv6"). and as you may aware, people do run older revisions of those > operating systems (there still are Win3.1, you know). > > if it isn't enough to convince you otherwise, i think you are in > a dream world. dream world?? thats nonsense. I also think the current installed IPv6 base is going to be *insignificant* compared to the IPv6 base that is expected. Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 22 20:06:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N36LoN009843; Mon, 22 Jul 2002 20:06:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N36KV5009842; Mon, 22 Jul 2002 20:06:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N36HoN009835; Mon, 22 Jul 2002 20:06:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA03391; Mon, 22 Jul 2002 20:06:19 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01188; Mon, 22 Jul 2002 21:06:17 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 36D5F4B25; Tue, 23 Jul 2002 12:06:08 +0900 (JST) To: Vijay Devarapalli Cc: Charlie Perkins , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: vijayd's message of Mon, 22 Jul 2002 18:46:40 MST. <3D3CB580.708DE3A7@iprg.nokia.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: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Tue, 23 Jul 2002 12:06:07 +0900 Message-Id: <20020723030608.36D5F4B25@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >there have never been any suboptions defined for the home address >option. >> draft 07: type, length, an IPv6 address and suboptions, >> type # = "196???" >> draft 08-16: type, length, an IPv6 address and suboptions, type # = 201 >when there is no vaild sub-option defined, I would expect one >to write code which would drop the packet, if the packet came >with some sub-option. one problem is that draft 07-16 are silent about HAO processing when unknown suboption is attached. from the language in draft 16, i guess receiver should ignore suboptions if they are unknown to them (otherwise we cannot allow "future extension" - old implementation will not be able to talk with new implementation), but i could be wrong. anyways, the above is not the main focus of this discussion. itojun --- Sub-Options Additional information, associated with this Home Address option, that need not be present in all Home Address options sent. This use of sub-options also allows for future extensions to the format of the Home Address option to be defined. Currently, no valid sub-options are defined for use in a Home Address option. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 00:49:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N7nsoN011527; Tue, 23 Jul 2002 00:49:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N7nrp5011526; Tue, 23 Jul 2002 00:49:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N7nkoN011511; Tue, 23 Jul 2002 00:49:46 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27939; Tue, 23 Jul 2002 00:49:47 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08502; Tue, 23 Jul 2002 01:49:29 -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 g6N7mXY27056; Tue, 23 Jul 2002 14:48: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 g6N7mOj11651; Tue, 23 Jul 2002 14:48:28 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: itojun@iijlab.net cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <20020722225421.087BD4B24@coconut.itojun.org> References: <20020722225421.087BD4B24@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jul 2002 14:48:24 +0700 Message-ID: <11649.1027410504@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 23 Jul 2002 07:54:20 +0900 From: itojun@iijlab.net Message-ID: <20020722225421.087BD4B24@coconut.itojun.org> | here are a little (incomplete) list of RFC2460-compliant | implementations that does not speak/understand HAO: This is a totally irrelevant argument. It simply doesn't matter which current implementations do or do not understand the option when it comes to deciding if it should be specified as a MUST or not. That question is relevant when designing the option, and its processing in the first place though. That is, someone has to decide what happens when a new option is seen at an old node that doesn't understand it. There the choices are "too bad, old node can't participate", "old node will just ignore this and do things this other way - not optimal, but works", or "this option will be useless with all those old nodes, there's no point having it at all" (perhaps others). Here, from what I have seen, that question isn't an issue - it seems (I believe) that the "old nodes will work sub-optimally" is the approach taken - that is, they don't get communications denied (which they would if this was a new header) nor is the option just considered worthless to have at all. On the other hand, when deciding whether new implementations MUST or SHOULD implement some option, the question is entirely related to the benefit vs the cost of the option processing, for nodes that can & would implement it (or might decide not to). What old code, shipped before the option was invented, might do is clearly irrelevant - that's not going to implement it, it cannot. Continuing to talk about the existing non HAO-supporting code base when deciding MUST vs SHOULD isn't helping anyone. If your point in there somewhere is that mobile-ip won't work with old nodes, and that is important enough to worry about, then the solution would have to be to redesign the protocol, not change one compliance word. But I don't think that's it - it seems to be more related to whether all those old implementations would be conforming to a standard that didn't exist when they were shipped. And the answer is that of course they won't be, and who cares about that anyway? kre ps: this message is not stating an opinion on whether MUST or SHOULD is the right label for this option, just about this one argument point. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 01:23:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8NWoN012604; Tue, 23 Jul 2002 01:23:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N8NWJg012603; Tue, 23 Jul 2002 01:23:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8NToN012596; Tue, 23 Jul 2002 01:23:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03718; Tue, 23 Jul 2002 01:23:30 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20564; Tue, 23 Jul 2002 02:23:29 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id F217A6A905; Tue, 23 Jul 2002 11:23:28 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EB3B46A904; Tue, 23 Jul 2002 11:23:26 +0300 (EEST) Message-ID: <3D3D12F2.6060805@kolumbus.fi> Date: Tue, 23 Jul 2002 11:25:22 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Glenn Morrow Cc: Michael Thomas , Basavaraj.Patil@nokia.com, itojun@iijlab.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <933FADF5E673D411B8A30002A5608A0E04BFA175@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Glenn Morrow wrote: > I thought it was already decided that a CN MUST respond with a rate > limited "lack of resources" response to the request for route > optimization. Yes! > If this is the case then it seems to follow that the > processing of the HOA for this purpose MUST also be supported if the HOA > is to be a part of the request to do route optimization - but only to > this extent. Indeed. However, I believe this thread is not about the support of HAO with RO -- it is more about the support of HAO with IPsec and triangular routing. Folks are complaining that there is not sufficient reason to have a MUST for that special case. And I'm starting to agree... Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 01:24:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8O1oN012622; Tue, 23 Jul 2002 01:24:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N8O0em012621; Tue, 23 Jul 2002 01:24:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8NuoN012614; Tue, 23 Jul 2002 01:23:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04917; Tue, 23 Jul 2002 01:23:47 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20784; Tue, 23 Jul 2002 02:23:46 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id E5ECD6A907; Tue, 23 Jul 2002 11:23:45 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DE3CF6A904; Tue, 23 Jul 2002 11:23:43 +0300 (EEST) Message-ID: <3D3D1303.2010304@kolumbus.fi> Date: Tue, 23 Jul 2002 11:25:39 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Kuntal Chowdhury Cc: Basavaraj.Patil@nokia.com, mat@cisco.com, john.loughney@nokia.com, itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <23BDB0046F3ED51185CD0002A5608D240528150F@zrc2c009.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kuntal Chowdhury wrote: > Here are two of the reasons why I think RO will be undesirable: There might be reasons at some situations to not do RO. But the spec already allows for that, either by the decision of the MN or the CN. So, we can cover the situations that you list, whether or not your reasons are valid. So can we please close this discussion, and concentrate only the discussion of what functionality is mandatory to support in the CNs? Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 01:43:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8h3oN013037; Tue, 23 Jul 2002 01:43:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6N8h34C013036; Tue, 23 Jul 2002 01:43:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N8h0oN013029; Tue, 23 Jul 2002 01:43:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA12757; Tue, 23 Jul 2002 01:43:02 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07370; Tue, 23 Jul 2002 01:43:01 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id AB0326A904; Tue, 23 Jul 2002 11:42:54 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4F3616A905; Tue, 23 Jul 2002 11:42:52 +0300 (EEST) Message-ID: <3D3D177F.8090905@kolumbus.fi> Date: Tue, 23 Jul 2002 11:44:47 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Cc: chowdury@nortelnetworks.com, mat@cisco.com, john.loughney@nokia.com, itojun@iijlab.net, vijayd@iprg.nokia.com, keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <697DAA22C5004B4596E033803A7CEF44A1315C@daebe007.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Basavaraj.Patil@nokia.com wrote: > RO gives you the capability of having two end-points connected without > having to rely on intermediate nodes such as the HA being > involved. The HA is not the bottleneck. One of the benefits of RO is > lesser traffic in the backbone and to a certain degree reduced > latency. But these are some of the lesser motivations. Well, I think latency is still a very good motivation. Even if we upgraded the backbone, someone forgot to upgrade speed of light ;-) > Having a mobile anchored at some point in the network (HA) when it is > non-essential is just not the right approach. I agree. > Mandating HAO processing > in all IPv6 nodes is the only way to accomplish this and reverse > tunnelling or having a node anchored at the HA is an option only for > backward compatibility to the nodes that already deployed (which is a > pretty small percentage of IP nodes). Please remember that the HAO processing is not sufficient by itself. This whole debate is not really about RO and HAO processing -- currently the spec is NOT mandating that with any keyword, we are expecting the node requirements document to do that. However, we are mandating the combination of IPsec, triangular routing, and HAO processing. So, when you are saying "mandating HAO processing", do you IPsec+triangular+HAO combination? I would actually say that RR, RO, and HAO are really the main ingredients for a successful mobility solution. The other combination is really just a special case and I can't see it being used in the Internet for any sizeable fraction of traffic. In fact, in my code I would always do RO even if I had an IPsec SA, so the combination might not even be usable by everyone. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 03:46:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NAkRoN014259; Tue, 23 Jul 2002 03:46:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NAkRiP014258; Tue, 23 Jul 2002 03:46:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NAkNoN014251; Tue, 23 Jul 2002 03:46:23 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29055; Tue, 23 Jul 2002 03:46:23 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22514; Tue, 23 Jul 2002 03:46:22 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:8168:6a65:dc2b:48e]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6NAiCA49847; Tue, 23 Jul 2002 19:44:13 +0900 (JST) Date: Tue, 23 Jul 2002 19:44:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brad Knowles Cc: Mohsen.Souissi@nic.fr, dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, vladimir.ksinant@6wind.com, rfc1886@nic.fr, g6@g6.asso.fr Subject: Re: RFC 1886 Interop Tests & Results In-Reply-To: References: <20020714132535.A28205@kerkenna.nic.fr> <20020714213532.84B6E4B22@coconut.itojun.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 29 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 15 Jul 2002 01:10:44 +0200, >>>>> Brad Knowles said: >> the co-existence of ip6.int and ip6.arpa tree will require us to: >> query ip6.arpa; >> if (no record) >> query ip6.int; >> for backward compatibility. was it taken into account, or did you >> test just "ip6.arpa" lookups? > I checked the source code for BIND 9.2.1, and IIRC it checks > ip6.int first and then ip6.arpa second. This allows us to stand up > ip6.arpa whenever, and then once that is set, we can tear down > ip6.int. What exactly do you mean by BIND 9.2.1? 1. the resolver library under lib/bind 2. the resolver routine in lwresd 3. both 1 and 2 4. others In my understanding (I've quickly checked the code again, too), both 1 and 2 only tries ip6.arpa with bitstring labels. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 05:14:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NCE8oN014592; Tue, 23 Jul 2002 05:14:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NCE8Yu014590; Tue, 23 Jul 2002 05:14:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NCE2oN014581 for ; Tue, 23 Jul 2002 05:14:03 -0700 (PDT) Received: from lillen (hobo076.Eng.Sun.COM [129.146.31.76]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6NCDug25689; Tue, 23 Jul 2002 14:13:56 +0200 (MEST) Date: Tue, 23 Jul 2002 03:27:36 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated To: Vijay Devarapalli Cc: sommerfeld@east.sun.com, Michael Thomas , john.loughney@nokia.com, itojun@iijlab.net, keiichi@iij.ad.jp, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3D360DF8.2B29D681@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 > > HAO is not useful without verification and largely pointless unless > > you're doing route optimization and can support a binding cache which > > is large enough to be meaningful. > > the point is this verification can be done in many ways. Vijay, I don't think any of these "many ways" are "MUST implement by every IPv6 node" thus it seems odd that the HAO itself is "MUST implement by every IPv6 node". Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 05:31:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NCVqoN014756; Tue, 23 Jul 2002 05:31:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NCVpkI014755; Tue, 23 Jul 2002 05:31:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NCVmoN014748 for ; Tue, 23 Jul 2002 05:31:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21551 for ; Tue, 23 Jul 2002 05:31:47 -0700 (PDT) Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25743 for ; Tue, 23 Jul 2002 06:31:46 -0600 (MDT) Received: from nansb ([193.216.185.140]) by fep03-svc.swip.net with SMTP id <20020723123145.NFDT7098.fep03-svc.swip.net@nansb>; Tue, 23 Jul 2002 14:31:45 +0200 Message-ID: <014601c23244$e8021250$8cb9d8c1@nansb> From: "Nils Agne Nordbotten" To: Cc: Subject: DAD vs. DIID Date: Tue, 23 Jul 2002 14:31:44 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0143_01C23255.AB461120" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0143_01C23255.AB461120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I would appreciate it if anyone could inform me of the outcome of the = DAD vs. DIID discussion in Yokohama. The meeting minutes are not = available at playground.sun yet. =20 Regards Nils Nordbotten ------=_NextPart_000_0143_01C23255.AB461120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hello,
     
    I would appreciate it if anyone could inform me of the outcome = of the=20 DAD vs. DIID discussion in Yokohama. The meeting minutes are=20 not available at playground.sun yet.  
     
     
    Regards
    Nils Nordbotten
     ------=_NextPart_000_0143_01C23255.AB461120-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 06:01:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ND1coN014828; Tue, 23 Jul 2002 06:01:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ND1bic014827; Tue, 23 Jul 2002 06:01:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ND1YoN014820; Tue, 23 Jul 2002 06:01:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05725; Tue, 23 Jul 2002 06:01:37 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15763; Tue, 23 Jul 2002 07:01:36 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6NCvRd05592; Tue, 23 Jul 2002 07:57:28 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 07:57:13 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E04C5D1C3@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Jari Arkko Cc: Michael Thomas , Basavaraj.Patil@nokia.com, itojun@iijlab.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Tue, 23 Jul 2002 07:57:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23248.721EF220" 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_01C23248.721EF220 Content-Type: text/plain; charset="iso-8859-1" I agree - let's move on. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Tuesday, July 23, 2002 3:25 AM > To: Morrow, Glenn [RICH2:C310:EXCH] > Cc: Michael Thomas; Basavaraj.Patil@nokia.com; itojun@iijlab.net; > charliep@iprg.nokia.com; mobile-ip@sunroof.eng.sun.com; > ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated > > > Glenn Morrow wrote: > > > I thought it was already decided that a CN MUST respond with a rate > > limited "lack of resources" response to the request for route > > optimization. > > > Yes! > > > If this is the case then it seems to follow that the > > processing of the HOA for this purpose MUST also be > supported if the HOA > > is to be a part of the request to do route optimization - > but only to > > this extent. > > > Indeed. > > However, I believe this thread is not about the support of > HAO with RO -- > it is more about the support of HAO with IPsec and triangular routing. > Folks are complaining that there is not sufficient reason to > have a MUST > for that special case. And I'm starting to agree... > > Jari > > > ------_=_NextPart_001_01C23248.721EF220 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Re: HAO and BE processing will be mandated

    I agree - let's move on.

    > -----Original Message-----
    > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi]
    > Sent: Tuesday, July 23, 2002 3:25 AM
    > To: Morrow, Glenn [RICH2:C310:EXCH]
    > Cc: Michael Thomas; Basavaraj.Patil@nokia.com; itojun@iijlab.net;
    > charliep@iprg.nokia.com; mobile-ip@sunroof.eng.sun.com;
    > ipng@sunroof.eng.sun.com
    > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated
    >
    >
    > Glenn Morrow wrote:
    >
    > > I thought it was already decided that a CN MUST respond with a rate
    > > limited "lack of resources" response to the request for route
    > > optimization.
    >
    >
    > Yes!
    >
    > > If this is the case then it seems to follow that the
    > > processing of the HOA for this purpose MUST also be
    > supported if the HOA
    > > is to be a part of the request to do route optimization -
    > but only to
    > > this extent.
    >
    >
    > Indeed.
    >
    > However, I believe this thread is not about the support of
    > HAO with RO --
    > it is more about the support of HAO with IPsec and triangular routing.
    > Folks are complaining that there is not sufficient reason to
    > have a MUST
    > for that special case. And I'm starting to agree...
    >
    > Jari
    >
    >
    >

    ------_=_NextPart_001_01C23248.721EF220-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 06:08:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ND8GoN014991; Tue, 23 Jul 2002 06:08:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ND8Gth014990; Tue, 23 Jul 2002 06:08:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ND8DoN014983 for ; Tue, 23 Jul 2002 06:08:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07958 for ; Tue, 23 Jul 2002 06:08:15 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09066 for ; Tue, 23 Jul 2002 07:08:14 -0600 (MDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA24309; Tue, 23 Jul 2002 14:08:08 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: "Nils Agne Nordbotten" Cc: , Subject: Re: DAD vs. DIID References: <014601c23244$e8021250$8cb9d8c1@nansb> From: Ole Troan Date: Tue, 23 Jul 2002 14:08:08 +0100 In-Reply-To: <014601c23244$e8021250$8cb9d8c1@nansb> ("Nils Agne Nordbotten"'s message of "Tue, 23 Jul 2002 14:31:44 +0200") Message-ID: <7t5heiq1tjb.fsf@mrwint.cisco.com> Lines: 15 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would appreciate it if anyone could inform me of the outcome of > the DAD vs. DIID discussion in Yokohama. The meeting minutes are not > available at playground.sun yet. consensus in the room was for DAD. there was also a discussion whether DAD should be done only on manually configured addresses, and not on MAC address derived and random ones. no consensus in the room. Erik Nordmark suggested "optimistic DAD", but there was no time to discuss it. optimistic DAD looks to me to be a good compromise. cheers, Ole -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 10:12:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NHCOoN015731; Tue, 23 Jul 2002 10:12:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NHCNg4015730; Tue, 23 Jul 2002 10:12:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NHCMoN015723 for ; Tue, 23 Jul 2002 10:12:22 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6NHBhGZ014556 for ; Tue, 23 Jul 2002 10:11:43 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6NHBhP9014555 for ipng@sunroof.eng.sun.com; Tue, 23 Jul 2002 10:11:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6N3YloN010016; Mon, 22 Jul 2002 20:34:47 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA22709; Mon, 22 Jul 2002 20:34:49 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA22913; Mon, 22 Jul 2002 21:34:49 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17WqRk-0006s7-00; Mon, 22 Jul 2002 20:34:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Vijay Devarapalli Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020722225421.087BD4B24@coconut.itojun.org> <3D3CB6DF.14DAA2CF@iprg.nokia.com> Message-Id: Date: Mon, 22 Jul 2002 20:34:48 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I also think the current installed IPv6 base is going to be > *insignificant* compared to the IPv6 base that is expected. yes. and the V4 base is growing fast too. so? the question is what works best. it would be good if we focussed on that. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 10:13:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NHD7oN015743; Tue, 23 Jul 2002 10:13:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NHD7jS015742; Tue, 23 Jul 2002 10:13:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NHD5oN015735 for ; Tue, 23 Jul 2002 10:13:05 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6NHCQGZ014564 for ; Tue, 23 Jul 2002 10:12:26 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6NHCQOX014563 for ipng@sunroof.eng.sun.com; Tue, 23 Jul 2002 10:12:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NEfUoN015122; Tue, 23 Jul 2002 07:41:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18917; Tue, 23 Jul 2002 07:41:31 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19748; Tue, 23 Jul 2002 08:41:30 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6NEjMj02093; Tue, 23 Jul 2002 09:45:22 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Jul 2002 09:41:28 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Jul 2002 09:41:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Tue, 23 Jul 2002 09:41:16 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A13177@daebe007.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIx0r/Hi6aFc2SWR1WKDfjwI8vfFwAhDX+A To: Cc: , , X-OriginalArrivalTime: 23 Jul 2002 14:41:16.0977 (UTC) FILETIME=[00622210:01C23257] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6NEfVoN015123 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>I am of the opinion that the scale of IPv6 deployment today is still >>in its infancy and the impacts associated with mandating the HAO >>processing on all IPv6 nodes is far less than maybe two years from >>now. > > here are a little (incomplete) list of RFC2460-compliant > implementations that does not speak/understand HAO: > > JunOS, ExtremeWare, MacOS 10.2, all FreeBSD since 4.0, all NetBSD > since 1.5, all OpenBSD since 2.7, Solaris beyond 2.7, Linux since 2.2, > all BSD/OS since 4.1. So are you suggesting that these OS' will have no revisions whatsoever in the future and they are now frozen forever? > and any product that ships with these operating systems (note that > many uses *BSD in embedded products such as printers). So every product that uses the IPv6 component of these OS' will not be compliant with the standard. These nodes can still operate just as well via the reverse tunnelling mechanism. I do not expect these nodes to be even upgraded to support the RR scheme as well. Thats just something we have to live with. > > and i would like to stress that it isn't matter of configuration, but > matter of codebase (you can't say "well, they are not configured with > IPv6"). and as you may aware, people do run older revisions of those > operating systems (there still are Win3.1, you know). I know. But you also have to realize that OS' evolve and new features are added. > > if it isn't enough to convince you otherwise, i think you are in > a dream world. There is an aspect of *tunnel vision* w.r.t your statement above. I realize there are commercial networks and commercial products running IPv6 that do not have HAO processing capability. But you are not looking at the potential scale of the nodes that are yet to be developed and deployed. > >itojun > Anyway, this argument is not leading to any conclusions. I would recommend that we move forward. Let the IESG decide if the HAO processing as MUST is too cumbersome for IPv6 nodes. -Basavaraj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 10:13:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NHDVoN015760; Tue, 23 Jul 2002 10:13:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NHDVR9015759; Tue, 23 Jul 2002 10:13:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NHDToN015752 for ; Tue, 23 Jul 2002 10:13:29 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6NHCoGZ014572 for ; Tue, 23 Jul 2002 10:12:50 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6NHCoau014571 for ipng@sunroof.eng.sun.com; Tue, 23 Jul 2002 10:12:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NFmEoN015412; Tue, 23 Jul 2002 08:48:14 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26744; Tue, 23 Jul 2002 08:48:16 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15175; Tue, 23 Jul 2002 08:48:15 -0700 (PDT) Received: from PTHUBERTW2K2 (dhcp-nic-val-26-104.cisco.com [64.103.26.104]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id RAA11889; Tue, 23 Jul 2002 17:47:56 +0200 (MET DST) From: "Pascal Thubert" To: , Cc: , , Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Wed, 24 Jul 2002 00:48:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A13177@daebe007.NOE.Nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I am of the opinion that the scale of IPv6 deployment today is still >in its infancy and the impacts associated with mandating the HAO >processing on all IPv6 nodes is far less than maybe two years from >now. Is that the point? My point was that the support of binding exchange and binding cache will be useless is several widely deployed configurations, example: - Web clusters - Appliances - Core routers ... You name it. On the other hand, having to support BU is not only additional code, it's also additional resources in constrained environments, and lower quality of service, since it may delay the establishment of the connection (I'm not sure that the draft is very clear about the use of the reverse tunnel while the RO is being established). It's also assuming that the trade off of having a binding cache is always preferable as opposed to other means of validating the HAO. The "always" is a "more often than not" at best, IMHO. Again, examples: - Trusted environment such as Intranet - BU piggybacking, or other means to sign every HaO, for CPU rich - memory poor environments such as load balancers and traffic splitters - Uselessness for attackers if application layer AAA is performed before any other process takes place (e.g. Web Server in a DMZ) I would not "MUST" a design point which degrades the performances of all modes of operation based on the assumptions on one. Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Basavaraj.Patil@nokia.com Sent: Tuesday, July 23, 2002 4:41 PM To: itojun@iijlab.net Cc: charliep@iprg.nokia.com; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated >>I am of the opinion that the scale of IPv6 deployment today is still >>in its infancy and the impacts associated with mandating the HAO >>processing on all IPv6 nodes is far less than maybe two years from >>now. > > here are a little (incomplete) list of RFC2460-compliant > implementations that does not speak/understand HAO: > > JunOS, ExtremeWare, MacOS 10.2, all FreeBSD since 4.0, all NetBSD > since 1.5, all OpenBSD since 2.7, Solaris beyond 2.7, Linux since 2.2, > all BSD/OS since 4.1. So are you suggesting that these OS' will have no revisions whatsoever in the future and they are now frozen forever? > and any product that ships with these operating systems (note that > many uses *BSD in embedded products such as printers). So every product that uses the IPv6 component of these OS' will not be compliant with the standard. These nodes can still operate just as well via the reverse tunnelling mechanism. I do not expect these nodes to be even upgraded to support the RR scheme as well. Thats just something we have to live with. > > and i would like to stress that it isn't matter of configuration, but > matter of codebase (you can't say "well, they are not configured with > IPv6"). and as you may aware, people do run older revisions of those > operating systems (there still are Win3.1, you know). I know. But you also have to realize that OS' evolve and new features are added. > > if it isn't enough to convince you otherwise, i think you are in > a dream world. There is an aspect of *tunnel vision* w.r.t your statement above. I realize there are commercial networks and commercial products running IPv6 that do not have HAO processing capability. But you are not looking at the potential scale of the nodes that are yet to be developed and deployed. > >itojun > Anyway, this argument is not leading to any conclusions. I would recommend that we move forward. Let the IESG decide if the HAO processing as MUST is too cumbersome for IPv6 nodes. -Basavaraj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 11:59:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NIxSoN016526; Tue, 23 Jul 2002 11:59:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NIxSji016525; Tue, 23 Jul 2002 11:59:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NIxNoN016515 for ; Tue, 23 Jul 2002 11:59:24 -0700 (PDT) Received: from lillen ([129.146.99.214]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6NIxOg04401 for ; Tue, 23 Jul 2002 20:59:25 +0200 (MEST) Date: Tue, 23 Jul 2002 20:57:41 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Comments and questions on dns-discovery To: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Comments on draft-ietf-ipv6-dns-discovery-05.txt The mechanism described here is to be used as a last resort, when no other configuration information is available. Does this mean that implementations of this mechanism MUST also implement another mechanism, such as DHCP, for discovering the DNS servers? If not, the above words have little practical meaning since an implementation which only supported this mechanism would be compliant; the mechanism would be the "only" resort i.e. both the first and last resort. -a) Using a site local prefix will ensure that the traffic to the DNS resolver stays local to the site. This will prevent the DNS requests from accidentally leaking out of the site. However, the local resolver can implement a policy to forward DNS resolution of non-local addresses to an external DNS resolver. This assumes that the site boudary is (correctly) configured. My understanding from the scoped addressing architecture is that by default all interfaces on a node are considered to be part of the same site. Therefor some explicit configuration is needed to make a node be at a site boundary. Is the assumptions that vendors of e.g. "home gateways" will by default treat the "home" as a separate site? Or is the assumption that the user will configure this boundary? The customer router CPE could be configured on its internal interface with one of the reserved site local addresses and listen for DNS queries. It would be configured to use one (or several) of the well known site local unicast addresses within the ISP's site to send its own queries to. It would act as a DNS forwarder, forwarding queries received on its internal interface to the ISP's DNS resolver. I assume this "forwarder" (a term which might be in common use but not well-defined, hence my stated assumption) merely receives DNS queries on one address and sends the identical queries to another address, and likewise for responses. Presumably such a box needs to track the pending queries in order to be able to return the responses to the correct address. If such a box doesn't do anything more than the above, this has implications on the trust model for DNSSEC. For instance, it might make some sense to have hosts trust a local DNS resolver to verify DNSSEC signatures, use a secure channel between the host and the resolver, and look at the DNS "AD" bit to determine that trusted resolver accepted the signatures on the data (see draft-ietf-dnsext-ad-is-secure). However, such a host might not trust the resolver external to the site. And the use of a "forwarder" here seems to imply that the host thinks it is talking to a resolver inside the site, when in fact it is using a resolver outside the site. This trust issue is not discussed in the draft and it clearly requires more thinking. Perhaps a result will be that any host using this DNS discovery mechanism MUST perform full verification of DNSSEC signatures and not rely on the recursive resolver to do the signature verification. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 12:21:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NJLFoN016579; Tue, 23 Jul 2002 12:21:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NJLFOp016578; Tue, 23 Jul 2002 12:21:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NJL8oN016563; Tue, 23 Jul 2002 12:21:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28690; Tue, 23 Jul 2002 12:21:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02550; Tue, 23 Jul 2002 12:21:10 -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 MAA23146; Tue, 23 Jul 2002 12:21:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NJL9009122; Tue, 23 Jul 2002 12:21:09 -0700 X-mProtect: <200207231921> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd16ohAN; Tue, 23 Jul 2002 12:21:07 PDT Message-ID: <3D3DACA3.2E55F55D@iprg.nokia.com> Date: Tue, 23 Jul 2002 12:21:07 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020722225421.087BD4B24@coconut.itojun.org> <3D3CB6DF.14DAA2CF@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy Bush wrote: > the question is what works best. it would be good if we > focussed on that. exactly. couldnt agree more. but I keep hearing from the KAME folks again and again "we already have IPv6 implementations which do not understand HAO, we dont want HAO mandated" (which makes no sense to me). Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 12:29:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NJT0oN016725; Tue, 23 Jul 2002 12:29:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NJT0Hw016724; Tue, 23 Jul 2002 12:29:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NJSuoN016717; Tue, 23 Jul 2002 12:28:56 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02023; Tue, 23 Jul 2002 12:28:58 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23364; Tue, 23 Jul 2002 13:28:57 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C2B514B23; Wed, 24 Jul 2002 04:28:34 +0900 (JST) To: Vijay Devarapalli Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: vijayd's message of Tue, 23 Jul 2002 12:21:07 MST. <3D3DACA3.2E55F55D@iprg.nokia.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: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Wed, 24 Jul 2002 04:28:33 +0900 Message-Id: <20020723192835.C2B514B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >but I keep hearing from the KAME folks again and again >"we already have IPv6 implementations which do not understand >HAO, we dont want HAO mandated" (which makes no sense to me). MUST for HAO is self-contradictory at best. if HAO is a MUST, we don't need bidir-tunnel (since it won't be used). if we have bidir-tunnel, HAO is okay with SHOULD. i don't want a pie-throwing match, but it seems that you want it... i keep hearing from you "we can ignore currently-deployed IPv6 codebase" which is total nonsense (or total ignorance of the current situation) to me. IPv6 is not a toy in your lab any more. we have people depend on it, we have serious IPv6 commercial network operation. i suggest to leave the SHOULD/MUST decision to jari, the main editor. 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 Jul 23 13:13:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKDqoN017022; Tue, 23 Jul 2002 13:13:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NKDqeP017021; Tue, 23 Jul 2002 13:13:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKDioN017006; Tue, 23 Jul 2002 13:13:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22424; Tue, 23 Jul 2002 13:13:47 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09838; Tue, 23 Jul 2002 14:13: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 NAA26121; Tue, 23 Jul 2002 13:13:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NKDhS08879; Tue, 23 Jul 2002 13:13:43 -0700 X-mProtect: <200207232013> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgvhGEW; Tue, 23 Jul 2002 13:13:40 PDT Message-ID: <3D3DB8F5.D15CC4FA@iprg.nokia.com> Date: Tue, 23 Jul 2002 13:13:41 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020723192835.C2B514B23@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, itojun@iijlab.net wrote: > > MUST for HAO is self-contradictory at best. if HAO is a MUST, we don't > need bidir-tunnel (since it won't be used). if we have bidir-tunnel, > HAO is okay with SHOULD. it is a MUST implement, not MUST use. you might not be able to use it all the time. so we have bidirectional tunneling (when you cant/dont want to do Route Optimization or triangle routing). got it?? > i don't want a pie-throwing match, but it seems that you want it... > i keep hearing from you "we can ignore currently-deployed IPv6 > codebase" which is total nonsense (or total ignorance of the current where did you get that idea from? Mobile nodes can have sessions with IPv6 nodes, which dont implement HAO. its there in the current spec. got it?? look at Robert Elz's answer. I dont have to say anything more. > situation) to me. IPv6 is not a toy in your lab any more. we have > people depend on it, we have serious IPv6 commercial network operation. > > i suggest to leave the SHOULD/MUST decision to jari, the main editor. this is funny. the WG decides and Jari edits it in. maybe the WG chairs can clarify this to you. Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 13:29:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKTloN017214; Tue, 23 Jul 2002 13:29:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NKTkgI017213; Tue, 23 Jul 2002 13:29:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKTeoN017198; Tue, 23 Jul 2002 13:29:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00449; Tue, 23 Jul 2002 13:29:43 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22183; Tue, 23 Jul 2002 13:29:42 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 16:24:05 -0400 Message-ID: From: Phil Roberts To: "'itojun@iijlab.net'" , Vijay Devarapalli Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Tue, 23 Jul 2002 16:24:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, this discussion doesn't seem to be going anywhere at the point. Perhaps we can drop it? The decision of MUST/SHOULD is up to the working group to recommend in its spec, and Jari will reflect that decision when he produces the final spec. The consensus that has been recorded so far is MUST for HAO processing, MUST for BE processing, SHOULD for RO support (although it's not listed in the node/host/ routers requirements section, 9.1 says it SHOULD be supported by all nodes). We'll look at the recent thread before determing whether the earlier consensus of MUST for HAO and BE processing are still intact. When MIP sends the spec up to the IESG for approval, we'll let the NG working group know the summary of the requirements that the MIP working group has recommended. Phil > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Tuesday, July 23, 2002 3:29 PM > To: Vijay Devarapalli > Cc: mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated > > > >but I keep hearing from the KAME folks again and again > >"we already have IPv6 implementations which do not understand > >HAO, we dont want HAO mandated" (which makes no sense to me). > > MUST for HAO is self-contradictory at best. if HAO is > a MUST, we don't > need bidir-tunnel (since it won't be used). if we have > bidir-tunnel, > HAO is okay with SHOULD. > > i don't want a pie-throwing match, but it seems that > you want it... > i keep hearing from you "we can ignore currently-deployed IPv6 > codebase" which is total nonsense (or total ignorance > of the current > situation) to me. IPv6 is not a toy in your lab any > more. we have > people depend on it, we have serious IPv6 commercial > network operation. > > i suggest to leave the SHOULD/MUST decision to jari, > the main editor. > > 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 Tue Jul 23 13:40:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKe3oN017364; Tue, 23 Jul 2002 13:40:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NKe3f4017363; Tue, 23 Jul 2002 13:40:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKe0oN017356 for ; Tue, 23 Jul 2002 13:40:00 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04664 for ; Tue, 23 Jul 2002 13:40:03 -0700 (PDT) Received: from southstation.m5p.com (dsl-209-162-215-52.dsl.easystreet.com [209.162.215.52]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05828 for ; Tue, 23 Jul 2002 14:40:02 -0600 (MDT) Received: from m5p.com (parkstreet.m5p.com [10.100.0.1]) by southstation.m5p.com (8.12.2/8.12.3) with ESMTP id g6NKds7J033990 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 23 Jul 2002 13:40:02 -0700 (PDT) Received: (from george@localhost) by m5p.com (8.12.3/8.12.3/Submit) id g6NKdsmI006124; Tue, 23 Jul 2002 13:39:54 -0700 (PDT) Date: Tue, 23 Jul 2002 13:39:54 -0700 (PDT) Message-Id: <200207232039.g6NKdsmI006124@m5p.com> From: george+ipng@m5p.com To: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've been using KAME code since August 1999 when I patched FreeBSD 3.4 to support IPv6. I think the community owes a great debt to all the KAME developers, without whose work we probably wouldn't have as great an installed BSD IPv6 base as we do. So I mean no disrespect to the KAME developers when I say that I think you're wrong on objecting to HAO being a MUST. There's no personal element involved. I don't think anyone means to downplay the signifi- cance of the installed base. It's certainly not the first time that a sizable installed code base has been obsoleted by a new feature. It seems to me (admittedly merely an interested outsider) that the pro-HAO arguments are persuasive. -- George Mitchell -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 13:41:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKfRoN017395; Tue, 23 Jul 2002 13:41:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NKfRmM017394; Tue, 23 Jul 2002 13:41:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKfJoN017379; Tue, 23 Jul 2002 13:41:19 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05063; Tue, 23 Jul 2002 13:41:22 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10883; Tue, 23 Jul 2002 14:41:21 -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 NAA27740; Tue, 23 Jul 2002 13:41:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NKfKE16025; Tue, 23 Jul 2002 13:41:20 -0700 X-mProtect: <200207232041> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpUnVbe; Tue, 23 Jul 2002 13:41:18 PDT Message-ID: <3D3DBF6E.B7E419D@iprg.nokia.com> Date: Tue, 23 Jul 2002 13:41:18 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Roberts CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thanks Phil. this approach sounds good. Vijay Phil Roberts wrote: > > Folks, > > this discussion doesn't seem to be going anywhere at the point. Perhaps > we > can drop it? > > The decision of MUST/SHOULD is up to the working group to recommend in > its > spec, and Jari will reflect that decision when he produces the final spec. > The consensus that has been recorded so far is MUST for HAO processing, MUST > for > BE processing, SHOULD for RO support (although it's not listed in the > node/host/ > routers requirements section, 9.1 says it SHOULD be supported by all nodes). > We'll > look at the recent thread before determing whether the earlier consensus of > MUST for > HAO and BE processing are still intact. > > When MIP sends the spec up to the IESG for approval, we'll let the NG > working > group know the summary of the requirements that the MIP working group has > recommended. > > Phil > > > -----Original Message----- > > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > > Sent: Tuesday, July 23, 2002 3:29 PM > > To: Vijay Devarapalli > > Cc: mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated > > > > > > >but I keep hearing from the KAME folks again and again > > >"we already have IPv6 implementations which do not understand > > >HAO, we dont want HAO mandated" (which makes no sense to me). > > > > MUST for HAO is self-contradictory at best. if HAO is > > a MUST, we don't > > need bidir-tunnel (since it won't be used). if we have > > bidir-tunnel, > > HAO is okay with SHOULD. > > > > i don't want a pie-throwing match, but it seems that > > you want it... > > i keep hearing from you "we can ignore currently-deployed IPv6 > > codebase" which is total nonsense (or total ignorance > > of the current > > situation) to me. IPv6 is not a toy in your lab any > > more. we have > > people depend on it, we have serious IPv6 commercial > > network operation. > > > > i suggest to leave the SHOULD/MUST decision to jari, > > the main editor. > > > > 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 Tue Jul 23 13:48:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKmpoN017547; Tue, 23 Jul 2002 13:48:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NKmohv017546; Tue, 23 Jul 2002 13:48:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NKmloN017539 for ; Tue, 23 Jul 2002 13:48:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07747 for ; Tue, 23 Jul 2002 13:48:50 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11575 for ; Tue, 23 Jul 2002 14:48:49 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 804E34B23; Wed, 24 Jul 2002 05:48:44 +0900 (JST) To: george+ipng@m5p.com Cc: ipng@sunroof.eng.sun.com In-reply-to: george+ipng's message of Tue, 23 Jul 2002 13:39:54 MST. <200207232039.g6NKdsmI006124@m5p.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: [mobile-ip] Re: HAO and BE processing will be mandated From: itojun@iijlab.net Date: Wed, 24 Jul 2002 05:48:44 +0900 Message-Id: <20020723204844.804E34B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I've been using KAME code since August 1999 when I patched FreeBSD 3.4 >to support IPv6. I think the community owes a great debt to all the >KAME developers, without whose work we probably wouldn't have as great >an installed BSD IPv6 base as we do. > >So I mean no disrespect to the KAME developers when I say that I think >you're wrong on objecting to HAO being a MUST. There's no personal >element involved. I don't think anyone means to downplay the signifi- >cance of the installed base. It's certainly not the first time that >a sizable installed code base has been obsoleted by a new feature. we are not arguing for SHOULD for HAO just because of conformance (or because "old KAME installations become non-conformant"). we are arguing because we believe MUST for HAO has no technical requirement (only political), imposes incompatible requirement against existing documents (2460), and as a result will slow down MIP6 standardization process. i expect AD/IESG pushback if MIP6 gets submitted with MUST for HAO, and IESG review takes forever due to the backlogs they have. you will really want to avoid IESG review roundtrip. 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 Jul 23 14:00:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NL0roN017710; Tue, 23 Jul 2002 14:00:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NL0q7R017709; Tue, 23 Jul 2002 14:00:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NL0noN017702 for ; Tue, 23 Jul 2002 14:00:49 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12405 for ; Tue, 23 Jul 2002 14:00:50 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21652 for ; Tue, 23 Jul 2002 15:00: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 OAA29096; Tue, 23 Jul 2002 14:00:49 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6NL0nH17743; Tue, 23 Jul 2002 14:00:49 -0700 X-mProtect: <200207232100> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmijgEO; Tue, 23 Jul 2002 14:00:46 PDT Message-ID: <3D3DC3FE.8E844F36@iprg.nokia.com> Date: Tue, 23 Jul 2002 14:00:46 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: george+ipng@m5p.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated References: <20020723204844.804E34B23@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > we are not arguing for SHOULD for HAO just because of conformance > (or because "old KAME installations become non-conformant"). good. > we are arguing because we believe MUST for HAO has no technical > requirement (only political), thats not fair. we gave enough technical arguments. > imposes incompatible requirement against > existing documents (2460), and as a result will slow down MIP6 > standardization process. i expect AD/IESG pushback if MIP6 gets > submitted with MUST for HAO, and IESG review takes forever due to the > backlogs they have. you will really want to avoid IESG review > roundtrip. that is something I cant control. Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 14:18:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NLInoN017803; Tue, 23 Jul 2002 14:18:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NLInQu017802; Tue, 23 Jul 2002 14:18:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NLImoN017795 for ; Tue, 23 Jul 2002 14:18:48 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6NLI8GZ014810 for ; Tue, 23 Jul 2002 14:18:08 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6NLI78A014809 for ipng@sunroof.eng.sun.com; Tue, 23 Jul 2002 14:18:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NIsboN016375; Tue, 23 Jul 2002 11:54:37 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18723; Tue, 23 Jul 2002 11:54:39 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01910; Tue, 23 Jul 2002 12:54:38 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6NIsid11110; Tue, 23 Jul 2002 13:54:44 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 13:54:29 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D240531CEFE@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Pekka Savola Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Implications of Route Optimization Date: Tue, 23 Jul 2002 13:54:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2327A.5D35A1B0" 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_01C2327A.5D35A1B0 Content-Type: text/plain; charset="iso-8859-1" Note: I am posting this as a new thread since we are not discussing about the issue of mandatory processing of HAO in the IPv6 CN anymore. Pekka Savola wrote: > Assuming CN is in ISP 1's network, MN is vising ISP 2's > network and HA is > in ISP 3's network. > > Your argument was, if I got it right, that route optimizations is bad > because traffic is between ISP 1 and ISP 2 so ISP 3 does not > get revenue. > > This seems ridiculous. > Consider the scenario where ISP 3 (Home domain of the user) does volume based accounting i.e. byte counts. The visited domain (ISP 2) does not support volume based accounting. Therefore the home domain assigns an AAA client in a router (which may well be the HA) which is guaranteed to be in the data path. Reverse tunneling is enforced by the home domain to ensure that the all the data to/from the user pass through the home domain. Now the user performs RO with the CN. The CN starts sending data directly to the MN bypassing the home domain. Therefore the byte counts in the AAA client in the home domain will not be accurate. > > If TE is used to route the traffic via such slow paths the difference is > > noticeable (at least, without measurement tools), the network is designed > > and operated badly, period. Nobody would want to pay for that kind of > > service. > > > > What makes you think that the TEed route between the CN and the MN > (i.e. Chicago -> Miami -> Dallas) will be a slow path? > The speed of light is a constant. It seems the assumption is that the link between CN and the MN is an optical link. Let me explain what determines the speed and quality of an optical link. A few important factors for a light path are: 1. Fiber type (DSF, USF, NZDF etc.) 2. EDFAs and Ramans amplifiers. 3. Number of 3Rs (Retiming, Reshaping, Reamplifying function). 4. Transmission systems (OC-48/192/768 etc.) 5. Network type i.e. Ring or Mesh. Say CN is in site A, MN in site B and HA in site C. Say the link between site A and B is OC-48, older fiber type 'USF' and no EDFAs. However the A -> C -> B is OC-192, newer fiber 'NZDF' with EDFAs. Also the number of 3Rs between A -> B is more than the number of 3Rs for the link A -> C -> B. Therefore the link speed, quality and available bandwidth will be far better for A -> C -> B than A -> B. Now if the MN performs RO, then it will end up shifting the traffic from a better link (A -> C -> B) to a worse link (A -> B). This will be the case when the link A -> B is not congested. When the link between A -> B is congested, and TE is implemented, the traffic may be shifted back to the original link A- > C -> B. That will have the opposite effect of RO. I hope it is clear now that the speed of light is not the limiting factor for a light path. Moreover performing RO w/o knowledge of the network topology and constraints does not guarantee good results. > > Do you think the shortest path is ALWAYS the best/fastest path? > Almost always, yes. When it's not, it's almost best, which is roughly the > same thing. All of this amounts to advantages by route optimization. > (I'm disregarding stuff like extremely severe network congestion here, as > we're talking about stable scenarios here.) The shortest path may not be the best/fastest path even in stable scenarios. It depends on the factors listed above for the light paths. ------_=_NextPart_001_01C2327A.5D35A1B0 Content-Type: text/html; charset="iso-8859-1" Implications of Route Optimization

    Note: I am posting this as a new thread since we are not
    discussing about the issue of mandatory processing of HAO in the IPv6 CN anymore.

    Pekka Savola wrote:
    > Assuming CN is in ISP 1's network, MN is vising ISP 2's
    > network and HA is
    > in ISP 3's network.
    >
    > Your argument was, if I got it right, that route optimizations is bad
    > because traffic is between ISP 1 and ISP 2 so ISP 3 does not
    > get revenue.
    >
    > This seems ridiculous. 
    >

    Consider the scenario where ISP 3 (Home domain of the user) does volume
    based accounting i.e. byte counts. The visited domain (ISP 2) does
    not support volume based accounting. Therefore the home domain assigns
    an AAA client in a router (which may well be the HA) which is guaranteed to
    be in the data path. Reverse tunneling is enforced by the home domain to
    ensure that the all the  data to/from the user pass through the home
    domain. Now the user performs RO with the CN. The CN starts sending data
    directly to the MN bypassing the home domain. Therefore the byte counts
    in the AAA client in the home domain will not be accurate.


    > > If TE is used to route the traffic via such slow paths the difference is
    > > noticeable (at least, without measurement tools), the network is designed
    > > and operated badly, period.  Nobody would want to pay for that kind of
    > > service.
    > >
    >
    > What makes you think that the TEed route between the CN and the MN
    > (i.e. Chicago -> Miami -> Dallas) will be a slow path?

    > The speed of light is a constant.

    It seems the assumption is that the link between CN and the MN is an optical
    link. Let me explain what determines the speed and quality of an optical
    link. A few important factors for a light path are:
    1. Fiber type (DSF, USF, NZDF etc.)
    2. EDFAs and Ramans amplifiers.
    3. Number of 3Rs (Retiming, Reshaping, Reamplifying function).
    4. Transmission systems (OC-48/192/768 etc.)
    5. Network type i.e. Ring or Mesh.

    Say CN is in site A, MN in site B and HA in site C. Say the link between
    site A and B is OC-48, older fiber type 'USF' and no EDFAs. However the
    A -> C -> B is OC-192, newer fiber 'NZDF' with EDFAs. Also the number of 3Rs
    between A -> B is more than the number of 3Rs for the link A -> C -> B.
    Therefore the link speed, quality and available bandwidth will be far better
    for A -> C -> B than A -> B.
    Now if the MN performs RO, then it will end up shifting the traffic from
    a better link (A -> C -> B) to a worse link (A -> B). This will be the case
    when the link A -> B is not congested.
    When the link between A -> B is congested, and TE is implemented, the
    traffic may be shifted back to the original link A- > C -> B. That will have
    the opposite effect of RO.
    I hope it is clear now that the speed of light is not the limiting factor for a
    light path. Moreover performing RO w/o knowledge of the network topology
    and constraints does not guarantee good results.


    > > Do you think the shortest path is ALWAYS the best/fastest path?

    > Almost always, yes.  When it's not, it's almost best, which is roughly the
    > same thing.  All of this amounts to advantages by route optimization.

    > (I'm disregarding stuff like extremely severe network congestion here, as
    > we're talking about stable scenarios here.)

    The shortest path may not be the best/fastest path even in stable scenarios.
    It depends on the factors listed above for the light paths.

    ------_=_NextPart_001_01C2327A.5D35A1B0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 15:46:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NMk2oN018202; Tue, 23 Jul 2002 15:46:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NMk2FZ018201; Tue, 23 Jul 2002 15:46:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NMk1oN018194 for ; Tue, 23 Jul 2002 15:46:01 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6NMjLGZ014956 for ; Tue, 23 Jul 2002 15:45:21 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6NMjLuY014955 for ipng@sunroof.eng.sun.com; Tue, 23 Jul 2002 15:45:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NM9loN017937; Tue, 23 Jul 2002 15:09:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12871; Tue, 23 Jul 2002 15:09:48 -0700 (PDT) Received: from picard.skynet.be (picard.skynet.be [195.238.3.88]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08280; Tue, 23 Jul 2002 16:09:47 -0600 (MDT) Received: from [10.0.1.60] (ip-27.shub-internet.org [194.78.144.27] (may be forged)) by picard.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.19) with ESMTP id g6NM91Z05506; Wed, 24 Jul 2002 00:09:03 +0200 (MET DST) (envelope-from ) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: <20020714132535.A28205@kerkenna.nic.fr> <20020714213532.84B6E4B22@coconut.itojun.org> Date: Tue, 23 Jul 2002 23:59:47 +0200 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Brad Knowles From: Brad Knowles Subject: Re: RFC 1886 Interop Tests & Results Cc: Mohsen.Souissi@nic.fr, dnsop@cafax.se, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, vladimir.ksinant@6wind.com, rfc1886@nic.fr, g6@g6.asso.fr Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 7:44 PM +0900 2002/07/23, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > What exactly do you mean by BIND 9.2.1? > > 1. the resolver library under lib/bind > 2. the resolver routine in lwresd > 3. both 1 and 2 Well, lwresd is just BIND by another name, so it should be the same library call. Starting in the bind-9.2.1 directory and searching for relevant strings, we find: % find . -name \*.c -print | xargs egrep -i 'ip6\.(arpa|int)' ./bin/named/query.c: * Convert the ip6.int name 'name' into the corresponding IPv6 address ./bin/named/query.c: /* Try IP6.ARPA first. */ ./bin/named/query.c: /* Try IP6.INT next. */ ./bin/named/query.c: * of NXDOMAIN and NXRRSET results from the IP6.INT ./bin/named/query.c: * and IP6.ARPA lookups, it could still be wrong with ./bin/tests/lwres_test.c: test_gabn("foo.ip6.int."); ./lib/bind/resolv/res_init.c: strcpy(statp->_u._ext.ext->nsuffix, "ip6.int"); ./lib/bind/resolv/res_init.c: strcpy(statp->_u._ext.ext->bsuffix, "ip6.arpa"); ./lib/bind/resolv/res_init.c: return ("ip6.int"); ./lib/bind/resolv/res_init.c: return ("ip6.arpa"); ./lib/dns/byaddr.c: strcpy(cp, "ip6.int."); ./lib/dns/byaddr.c: strcpy(cp, "].ip6.arpa."); Specifically, looking in bind-9.2.1/bin/named/query.c, starting on line 3770, we see: /* Try IP6.ARPA first. */ result = dns_byaddr_create(client->mctx, &client->query.synth.na, client->view, 0, client->task, synth_rev_byaddrdone_arpa, client, &byaddr_dummy); if (result == ISC_R_SUCCESS) return; /* Wait for completion event. */ Then, starting on line 3796, we see: /* Try IP6.INT next. */ result = dns_byaddr_create(client->mctx, &client->query.synth.na, client->view, DNS_BYADDROPT_IPV6NIBBLE, client->task, synth_rev_byaddrdone_int, client, &byaddr_dummy); if (result != ISC_R_SUCCESS) synth_finish(client, result); Then starting on line 3821, we see: } else if (bevent->result == DNS_R_NCACHENXDOMAIN || bevent->result == DNS_R_NCACHENXRRSET || bevent->result == DNS_R_NXDOMAIN || bevent->result == DNS_R_NXRRSET) { /* * We could give a NOERROR/NODATA response instead * in some cases, but since there may be any combination * of NXDOMAIN and NXRRSET results from the IP6.INT * and IP6.ARPA lookups, it could still be wrong with * respect to one or the other. */ synth_finish(client, DNS_R_NXDOMAIN); Looking at bind-9.2.1/lib/bind/resolv/res_init.c, starting on line 194, we see: if (statp->_u._ext.ext != NULL) { memset(statp->_u._ext.ext, 0, sizeof(*statp->_u._ext.ext)); statp->_u._ext.ext->nsaddrs[0].sin = statp->nsaddr; strcpy(statp->_u._ext.ext->nsuffix, "ip6.int"); strcpy(statp->_u._ext.ext->bsuffix, "ip6.arpa"); } Then starting on line 608, we see: const char * res_get_nibblesuffix(res_state statp) { if (statp->_u._ext.ext) return (statp->_u._ext.ext->nsuffix); return ("ip6.int"); } const char * res_get_bitstringsuffix(res_state statp) { if (statp->_u._ext.ext) return (statp->_u._ext.ext->bsuffix); return ("ip6.arpa"); } Moving on to bind-9.2.1/lib/dns/byaddr.c starting on line 93, we see: } else if (address->family == AF_INET6) { if (nibble) { cp = textname; for (i = 15; i >= 0; i--) { *cp++ = hex_digits[bytes[i] & 0x0f]; *cp++ = '.'; *cp++ = hex_digits[(bytes[i] >> 4) & 0x0f]; *cp++ = '.'; } strcpy(cp, "ip6.int."); } else { cp = textname; *cp++ = '\\'; *cp++ = '['; *cp++ = 'x'; for (i = 0; i < 16; i += 2) { *cp++ = hex_digits[(bytes[i] >> 4) & 0x0f]; *cp++ = hex_digits[bytes[i] & 0x0f]; *cp++ = hex_digits[(bytes[i+1] >> 4) & 0x0f]; *cp++ = hex_digits[bytes[i+1] & 0x0f]; } strcpy(cp, "].ip6.arpa."); } } else > In my understanding (I've quickly checked the code again, too), both 1 > and 2 only tries ip6.arpa with bitstring labels. I'm not sure why nibble and bitstring forms are handled differently within the libraries, but clearly within the nameserver itself, it does check both domains. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 15:55:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NMteoN018226; Tue, 23 Jul 2002 15:55:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6NMtehI018225; Tue, 23 Jul 2002 15:55:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6NMtaoN018218 for ; Tue, 23 Jul 2002 15:55:36 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22670 for ; Tue, 23 Jul 2002 15:55:38 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09285 for ; Tue, 23 Jul 2002 15:55:37 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id ED4604B24; Wed, 24 Jul 2002 07:55:28 +0900 (JST) To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Tue, 23 Jul 2002 20:57:41 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments and questions on dns-discovery From: itojun@iijlab.net Date: Wed, 24 Jul 2002 07:55:28 +0900 Message-Id: <20020723225529.ED4604B24@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I assume this "forwarder" (a term which might be in common use but not >well-defined, hence my stated assumption) merely receives DNS queries >on one address and sends the identical queries to another address, >and likewise for responses. Presumably such a box needs to track >the pending queries in order to be able to return the responses to >the correct address. > >If such a box doesn't do anything more than the above, this has implications >on the trust model for DNSSEC. For instance, it might make some sense >to have hosts trust a local DNS resolver to verify DNSSEC signatures, >use a secure channel between the host and the resolver, and look >at the DNS "AD" bit to determine that trusted resolver accepted >the signatures on the data (see draft-ietf-dnsext-ad-is-secure). > >However, such a host might not trust the resolver external to the site. >And the use of a "forwarder" here seems to imply that the host thinks >it is talking to a resolver inside the site, when in fact it is using >a resolver outside the site. This trust issue is not discussed in >the draft and it clearly requires more thinking. >Perhaps a result will be that any host using this DNS discovery mechanism >MUST perform full verification of DNSSEC signatures and not rely >on the recursive resolver to do the signature verification. i guess it a bit off-topic, i think it is more like AD-bit issue. as long as secure channel is maintained between host and resolver, it does not make difference, no? do you think host would configure secure channel to untrustworthy resolver? 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 Jul 23 17:18:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O0IRoN018564; Tue, 23 Jul 2002 17:18:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6O0IQep018563; Tue, 23 Jul 2002 17:18:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O0IMoN018556 for ; Tue, 23 Jul 2002 17:18:23 -0700 (PDT) Received: from lillen (hobo076.Eng.Sun.COM [129.146.31.76]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6O0IIg26045; Wed, 24 Jul 2002 02:18:18 +0200 (MEST) Date: Wed, 24 Jul 2002 02:16:30 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments and questions on dns-discovery To: itojun@iijlab.net Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20020723225529.ED4604B24@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > as long as secure channel is maintained between host and resolver, > it does not make difference, no? do you think host would configure > secure channel to untrustworthy resolver? The document makes a reference to TKEY as a way to create keys for TSIG. I certainly don't understand how this works in practice - does it mean essentially an anonymous DH exchange? If so the host might think it has a secure channel (using TSIG) with a trusted party when in fact it has a secure channel with a recursive resolver that it shouldn't trust. Has anybody implemented this stuff with TKEY + TSIG? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 18:39:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O1dNoN018747; Tue, 23 Jul 2002 18:39:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6O1dNYm018746; Tue, 23 Jul 2002 18:39:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O1dGoN018731; Tue, 23 Jul 2002 18:39:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25450; Tue, 23 Jul 2002 18:39:18 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA27863; Tue, 23 Jul 2002 19:39:17 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA02236; Wed, 24 Jul 2002 10:39:15 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA03239; Wed, 24 Jul 2002 10:39:14 +0900 (JST) Date: Wed, 24 Jul 2002 10:37:28 +0900 (JST) Message-Id: <20020724.103728.75347084.keiichi@iij.ad.jp> To: vijayd@iprg.nokia.com Cc: PRoberts@MEGISTO.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3D3DBF6E.B7E419D@iprg.nokia.com> References: <3D3DBF6E.B7E419D@iprg.nokia.com> X-Mailer: Mew version 3.0.56 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, From: Vijay Devarapalli > thanks Phil. this approach sounds good. I agree, too. We have had enough discussion and I am almost satisfied (though the discussion have not closed yet, but this is not a prpblem). Many people insist their opinion, almost all WG members hear them, and the chairmen and the editors have got enough information to go forward. Thoughout the discussion, it seems to me that the IPv6 WG will not accept the mip6 draft if the HAO/BE requirements are MUST. Even if we leave them with MUST (of course we can, the decision can be done in the mip WG inside), I think that the IESG never pass it. This creates another delay for the standard process of the mip6. I think we can leave the text for HAO/BE to the editors and wait for the new draft. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 21:16:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O4GvoN019205; Tue, 23 Jul 2002 21:16:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6O4GuKK019204; Tue, 23 Jul 2002 21:16:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O4GqoN019197; Tue, 23 Jul 2002 21:16:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA17857; Tue, 23 Jul 2002 21:16:54 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26383; Tue, 23 Jul 2002 22:16:53 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1048:955d:39d5:3220:695f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6O4GeA58843; Wed, 24 Jul 2002 13:16:40 +0900 (JST) Date: Wed, 24 Jul 2002 13:16:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= Cc: vijayd@iprg.nokia.com, PRoberts@MEGISTO.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: <20020724.103728.75347084.keiichi@iij.ad.jp> References: <3D3DBF6E.B7E419D@iprg.nokia.com> <20020724.103728.75347084.keiichi@iij.ad.jp> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 45 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 24 Jul 2002 10:37:28 +0900 (JST), >>>>> Keiichi SHIMA said: >> thanks Phil. this approach sounds good. > I agree, too. I basically agree, too. A few points: >> When MIP sends the spec up to the IESG for approval, we'll let the NG >> working >> group know the summary of the requirements that the MIP working group has >> recommended. The ipv6 wg members will check the next draft and will make comments on it when it is out , not only at the point of the IESG approval. The ipv6 wg members will also make comments at the mip wg last call (since the last call will be announced to the members as well), and at the IETF last call, especially if they have objections to the draft. > Thoughout the discussion, it seems to me that the IPv6 WG will not > accept the mip6 draft if the HAO/BE requirements are MUST. Even if we > leave them with MUST (of course we can, the decision can be done in > the mip WG inside), I think that the IESG never pass it. This creates > another delay for the standard process of the mip6. I'm not sure if this is really the case (because we cannot tell all about the future), but I'm 99% sure that many ipv6 wg members will make objections to the MUST. And, the objections will surely introduce additional delay to standardize mip6. (I'm not talking about my own position about the MUST vs SHOULD, but talking about a story that will be very likely to happen, by observing the discussions so far.) So, I hope the next draft will consider the various tradeoffs among ideal solutions to MNs, effects to CNs (both existing and future ones), and the standardization/deployment schedule. Again, I agree the ball is now in the mip wg and we should wait for the next draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 23 23:10:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O6ARoN019479; Tue, 23 Jul 2002 23:10:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6O6AQid019478; Tue, 23 Jul 2002 23:10:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6O6ANoN019471; Tue, 23 Jul 2002 23:10:23 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA07771; Tue, 23 Jul 2002 23:10:26 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08793; Wed, 24 Jul 2002 00:10:25 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6O69eZ06155; Wed, 24 Jul 2002 09:09:41 +0300 Date: Wed, 24 Jul 2002 09:09:40 +0300 (EEST) From: Pekka Savola To: Kuntal Chowdhury cc: mobile-ip@sunroof.eng.sun.com, Subject: Re: [mobile-ip] Implications of Route Optimization In-Reply-To: <23BDB0046F3ED51185CD0002A5608D240531CEFE@zrc2c009.us.nortel.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, 23 Jul 2002, Kuntal Chowdhury wrote: > Pekka Savola wrote: > > Assuming CN is in ISP 1's network, MN is vising ISP 2's > > network and HA is > > in ISP 3's network. > > > > Your argument was, if I got it right, that route optimizations is bad > > because traffic is between ISP 1 and ISP 2 so ISP 3 does not > > get revenue. > > > > This seems ridiculous. > > Consider the scenario where ISP 3 (Home domain of the user) does volume > based accounting i.e. byte counts. The visited domain (ISP 2) does > not support volume based accounting. Therefore the home domain assigns > an AAA client in a router (which may well be the HA) which is guaranteed to > be in the data path. Reverse tunneling is enforced by the home domain to > ensure that the all the data to/from the user pass through the home > domain. Now the user performs RO with the CN. The CN starts sending data > directly to the MN bypassing the home domain. Therefore the byte counts > in the AAA client in the home domain will not be accurate. What is the purpose of byte counts? Most often to see how many bytes have been transferred to the node in the specified network. In Route Optimization case, such byte counts are close to zero. I see no reason to artificially try to create these byte counts. Only the node and the networks it visit know how much traffic is used. > > What makes you think that the TEed route between the CN and the MN > > (i.e. Chicago -> Miami -> Dallas) will be a slow path? > > > The speed of light is a constant. > > It seems the assumption is that the link between CN and the MN is an optical > link. Similar restrictios apply to non-optical links too. The main factor is the length of the link. [...] > Say CN is in site A, MN in site B and HA in site C. Say the link between > site A and B is OC-48, older fiber type 'USF' and no EDFAs. However the > A -> C -> B is OC-192, newer fiber 'NZDF' with EDFAs. Also the number of 3Rs > between A -> B is more than the number of 3Rs for the link A -> C -> B. > Therefore the link speed, quality and available bandwidth will be far better > > for A -> C -> B than A -> B. > Now if the MN performs RO, then it will end up shifting the traffic from > a better link (A -> C -> B) to a worse link (A -> B). This will be the case > when the link A -> B is not congested. > When the link between A -> B is congested, and TE is implemented, the > traffic may be shifted back to the original link A- > C -> B. That will have > the opposite effect of RO. > I hope it is clear now that the speed of light is not the limiting factor > for a > light path. If the sites choose to prefer A -> B path instead of A -> C -> B (and they can easily do so, if they want), it's their choice. > Moreover performing RO w/o knowledge of the network topology > and constraints does not guarantee good results. I agree that RO is sometimes not worth the effort, but where optimized path would be worse seem to be just corner cases to me. > The shortest path may not be the best/fastest path even in stable scenarios. > It depends on the factors listed above for the light paths. By 'shortest path' I mean the path that the network admins have chosen to be the best path to other site X. It does not necessarily have to physically the shortest one, of course. But it does not usually go through third parties either, though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 04:19:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OBJ0oN020021; Wed, 24 Jul 2002 04:19:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6OBJ0YA020020; Wed, 24 Jul 2002 04:19:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OBIvoN020013 for ; Wed, 24 Jul 2002 04:18:57 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20057 for ; Wed, 24 Jul 2002 04:18:58 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08427 for ; Wed, 24 Jul 2002 05:18:57 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6OBJTi07012 for ; Wed, 24 Jul 2002 14:19:29 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 24 Jul 2002 14:18:56 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 14:18:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments and questions on dns-discovery Date: Wed, 24 Jul 2002 14:18:55 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EDA@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments and questions on dns-discovery Thread-Index: AcIye2Ybt58fbu/vR/aqGj3GSxelTQAh8QGg To: , X-OriginalArrivalTime: 24 Jul 2002 11:18:56.0232 (UTC) FILETIME=[E6593680:01C23303] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6OBIvoN020014 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, > The mechanism described here is to be used as a last > resort, when no other configuration information is available. > > Does this mean that implementations of this mechanism MUST also > implement another mechanism, such as DHCP, for discovering the DNS > servers? > If not, the above words have little practical meaning since an > implementation which only supported this mechanism would be compliant; > the mechanism would be the "only" resort i.e. both the first > and last resort. There is always manual configuration or some proprietary configuration method (for example some sort of 'over the air' configuration for cell phones using SMS). Anyhow, isn't an implementation decision on what to implement and what not to? All we can do is make recommendations on what implementations should do. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 05:09:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OC9RoN020097; Wed, 24 Jul 2002 05:09:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6OC9R4c020096; Wed, 24 Jul 2002 05:09:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OC9NoN020089 for ; Wed, 24 Jul 2002 05:09:23 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06676 for ; Wed, 24 Jul 2002 05:09:25 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13665 for ; Wed, 24 Jul 2002 05:09:25 -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 IAA02219; Wed, 24 Jul 2002 08:08:21 -0400 (EDT) Message-Id: <200207241208.IAA02219@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-tunnel-v02-00.txt Date: Wed, 24 Jul 2002 08:08:20 -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 : Generic Packet Tunneling in IPv6 Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipv6-tunnel-v02-00.txt Pages : 37 Date : 23-Jul-02 This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. The model and mechanisms can be applied to other protocol packets as well, such as AppleTalk, IPX, CLNP, or others. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-tunnel-v02-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-tunnel-v02-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-tunnel-v02-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: <20020723145538.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-tunnel-v02-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-tunnel-v02-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020723145538.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 Jul 24 06:51:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ODptoN020426; Wed, 24 Jul 2002 06:51:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ODptKY020425; Wed, 24 Jul 2002 06:51:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ODppoN020418 for ; Wed, 24 Jul 2002 06:51:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01249 for ; Wed, 24 Jul 2002 06:51:52 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27042 for ; Wed, 24 Jul 2002 06:51:37 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:955d:39d5:3220:695f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6ODoIA67007; Wed, 24 Jul 2002 22:50:18 +0900 (JST) Date: Wed, 24 Jul 2002 22:50:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-Reply-To: <20020721222414.1D7F64B22@coconut.itojun.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <20020721222414.1D7F64B22@coconut.itojun.org> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 22 Jul 2002 07:24:14 +0900, >>>>> itojun@iijlab.net said: >>> i may be asking a stupid question, but where do you get that private >>> key from? for instance, if a node responds with "www.ietf.org", >>> we could get a public key for www.ietf.org by KEY RR query, but >>> not the private key (it's on ietf.org authoritative server, and >>> is not accessible from outside). >> Presumably the device answering the ICMP request is the one named, >> and therefore knows the private key associated with its name. > no, the device answering ICMPv6 request is not named. ??? I'm a bit confused. Are you saying that we can *not always* assume the device answering ICMPv6 request runs a name server? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 06:56:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ODuCoN020457; Wed, 24 Jul 2002 06:56:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ODuCNN020456; Wed, 24 Jul 2002 06:56:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ODu8oN020449 for ; Wed, 24 Jul 2002 06:56:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27108 for ; Wed, 24 Jul 2002 06:56:10 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29295 for ; Wed, 24 Jul 2002 06:56:09 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 62A954B24; Wed, 24 Jul 2002 22:56:04 +0900 (JST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: jinmei's message of Wed, 24 Jul 2002 22:50:16 +0900. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Wed, 24 Jul 2002 22:56:04 +0900 Message-Id: <20020724135604.62A954B24@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> no, the device answering ICMPv6 request is not named. >??? I'm a bit confused. Are you saying that we can *not always* >assume the device answering ICMPv6 request runs a name server? the thread of email assumes the following diagram. itojun > client resolver ---------> named -------> the target > DNS query NI query > client resolver <--------- named <------- the target > DNS response NI response -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 07:24:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OEOFoN021144; Wed, 24 Jul 2002 07:24:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6OEOEr6021143; Wed, 24 Jul 2002 07:24:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OEOBoN021136 for ; Wed, 24 Jul 2002 07:24:11 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11724 for ; Wed, 24 Jul 2002 07:24:12 -0700 (PDT) Received: from purgatory.unfix.org (cust.92.136.adsl.cistron.nl [195.64.92.136]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29906 for ; Wed, 24 Jul 2002 07:24:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 579D18DFD; Wed, 24 Jul 2002 16:24:24 +0200 (CEST) Received: from cyan (gateway.azr.nl [::ffff:156.83.254.8]) by purgatory.unfix.org (Postfix) with ESMTP id 6747A8DE4; Wed, 24 Jul 2002 16:24:11 +0200 (CEST) From: "Jeroen Massar" To: , "=?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?=" Cc: , Subject: RE: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Date: Wed, 24 Jul 2002 16:21:53 +0200 Organization: Unfix Message-ID: <002301c2331d$77f81390$534510ac@cyan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020724135604.62A954B24@coconut.itojun.org> X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Razor-id: be4cf2065e36d11399c131ff14df2efbb61f81d8 X-Spam-Status: No, hits=-3.4 tests=IN_REP_TO Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > >> no, the device answering ICMPv6 request is not named. > >??? I'm a bit confused. Are you saying that we can *not always* > >assume the device answering ICMPv6 request runs a name server? > > the thread of email assumes the following diagram. > > itojun > > > > client resolver ---------> named -------> the target > > DNS query NI query > > client resolver <--------- named <------- the target > > DNS response NI response As I was toying around with Opportunistic Encryption it shaded another light on this subject. Could there be a query type which requests the KEY (just like the DNS RR) of a host. This would allow for example FreeS/WAN and Racoon and other IPSec implementations to request the public KEY from the host itself in a standardized way. The proposed DNS<->nodeinfo could then also provide this information over DNS. Ofcourse one has no 100% ensurance that the replied KEY is valid at all. Greets, Jeroen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 07:30:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OEUIoN021198; Wed, 24 Jul 2002 07:30:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6OEUIic021197; Wed, 24 Jul 2002 07:30:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OEUEoN021190 for ; Wed, 24 Jul 2002 07:30:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13185 for ; Wed, 24 Jul 2002 07:30:15 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04178 for ; Wed, 24 Jul 2002 08:30:14 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:955d:39d5:3220:695f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6OESmA67631; Wed, 24 Jul 2002 23:28:48 +0900 (JST) Date: Wed, 24 Jul 2002 23:28:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-Reply-To: <20020724135604.62A954B24@coconut.itojun.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <20020724135604.62A954B24@coconut.itojun.org> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 42 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 24 Jul 2002 22:56:04 +0900, >>>>> itojun@iijlab.net said: >>> no, the device answering ICMPv6 request is not named. >> ??? I'm a bit confused. Are you saying that we can *not always* >> assume the device answering ICMPv6 request runs a name server? > the thread of email assumes the following diagram. >> client resolver ---------> named -------> the target >> DNS query NI query >> client resolver <--------- named <------- the target >> DNS response NI response Hmm, I read the Ted's message >>>>> On Sat, 20 Jul 2002 16:53:10 -0700, >>>>> Ted Lemon said: > What do people think of signing the ICMP packet with the private key that > corresponds to a KEY RR that is attached to the name mentioned in the ICMP > packet? to mean the diagram like this: NI query nodeinfo client ------------------> the target with named (authorizing the name) and private key <------------------ NI response signed by the private key (BTW: I understood the very original idea of this thread meant the diagram you showed.) But if I just misunderstood, please ignore me. I was just checking. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 11:20:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OIKdoN021630; Wed, 24 Jul 2002 11:20:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6OIKcXZ021629; Wed, 24 Jul 2002 11:20:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OIKboN021622 for ; Wed, 24 Jul 2002 11:20:37 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6OIJuGZ015297 for ; Wed, 24 Jul 2002 11:19:56 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6OIJtR5015296 for ipng@sunroof.eng.sun.com; Wed, 24 Jul 2002 11:19:55 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OGd6oN021442 for ; Wed, 24 Jul 2002 09:39:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26985 for ; Wed, 24 Jul 2002 09:39:09 -0700 (PDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19172 for ; Wed, 24 Jul 2002 09:39:08 -0700 (PDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA25795; Wed, 24 Jul 2002 12:38:54 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA11605; Wed, 24 Jul 2002 12:38:48 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id MAA20830; Wed, 24 Jul 2002 12:38:46 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA24375; Wed, 24 Jul 2002 12:38:47 -0400 (EDT) To: "Jeroen Massar" Cc: , "'JINMEI Tatuya / =?iso-8859-1?q?=90=5F-=BE?='=?iso-8859-1?q?B=8D=C6?='" , , From: Derek Atkins Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt References: <002301c2331d$77f81390$534510ac@cyan> Date: 24 Jul 2002 12:38:47 -0400 In-Reply-To: <002301c2331d$77f81390$534510ac@cyan> Message-ID: Lines: 28 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Jeroen Massar" writes: > As I was toying around with Opportunistic Encryption it shaded another > light on this subject. > Could there be a query type which requests the KEY (just like the DNS > RR) of a host. Yes, it's called IKE. It's already part of the IPsec protocol suite. > This would allow for example FreeS/WAN and Racoon and other IPSec > implementations to request > the public KEY from the host itself in a standardized way. The proposed > DNS<->nodeinfo could > then also provide this information over DNS. Ofcourse one has no 100% > ensurance that the replied > KEY is valid at all. This is exactly why it isn't done, and why you want keys in DNSSEC. > Greets, > Jeroen -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 11:21:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OIL4oN021640; Wed, 24 Jul 2002 11:21:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6OIL3bW021639; Wed, 24 Jul 2002 11:21:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OIL2oN021632 for ; Wed, 24 Jul 2002 11:21:02 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6OIKLGZ015305 for ; Wed, 24 Jul 2002 11:20:21 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6OIKK4D015304 for ipng@sunroof.eng.sun.com; Wed, 24 Jul 2002 11:20:20 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OHLToN021496 for ; Wed, 24 Jul 2002 10:21:29 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18223 for ; Wed, 24 Jul 2002 10:21:30 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23378 for ; Wed, 24 Jul 2002 11:21:28 -0600 (MDT) Received: from green.bisbee.fugue.com (az-ben-pm3-2-17.ppp.theriver.com [206.25.50.17]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6OHLDd02003; Wed, 24 Jul 2002 17:21:14 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6OHLefD001533; Wed, 24 Jul 2002 10:21:40 -0700 (MST) Date: Wed, 24 Jul 2002 10:21:39 -0700 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > to mean the diagram like this: > > NI query > nodeinfo client ------------------> the target > with named (authorizing the name) > and private key > <------------------ > NI response signed > by the private key > > (BTW: I understood the very original idea of this thread meant the > diagram you showed.) No, I was talking about securing the NI query, but not assuming that a "name server" would do that work, except in the sense that by definition anything that responds to a query for a name with a name could be called a name server. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 15:07:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OM7XoN022285; Wed, 24 Jul 2002 15:07:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6OM7WB8022284; Wed, 24 Jul 2002 15:07:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OM7ToN022277 for ; Wed, 24 Jul 2002 15:07:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19092 for ; Wed, 24 Jul 2002 15:07:31 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24668 for ; Wed, 24 Jul 2002 16:07:30 -0600 (MDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 15:07:31 -0700 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Jul 2002 15:07:30 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Jul 2002 15:07:30 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Jul 2002 15:07:30 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Wed, 24 Jul 2002 15:06:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Comments on draft-ietf-ipngwg-icmp-v3-02.txt Date: Wed, 24 Jul 2002 15:06:40 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC107384159@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-ipngwg-icmp-v3-02.txt thread-index: AcIzXoCzZZ7uKdiKSAOr2mJQ5pUzzw== From: "Dave Thaler" To: X-OriginalArrivalTime: 24 Jul 2002 22:06:41.0205 (UTC) FILETIME=[63AD7650:01C2335E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6OM7UoN022278 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I had a comment on the ICMPv6 spec which I mentioned to Steve Deering in Yokohama and promised I'd also send to the list: I'd like to see an ICMPv6 error message value assigned for the case where a node would need to send a packet from a specific address, but cannot because that address is anycast (since the other end has no other good way of knowing this is the case). One example of this is if a node receives a TCP SYN on an anycast address, today it apparently has to silently drop the SYN, and the other end can't tell why. No existing ICMPv6 error message applies to this case. (Also I had mentioned that the RFC does not say what to do when receiving an anycast Echo Request, but draft -02 already does so no problem there.) -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 15:12:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OMCXoN022353; Wed, 24 Jul 2002 15:12:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6OMCWjd022352; Wed, 24 Jul 2002 15:12:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OMCToN022345 for ; Wed, 24 Jul 2002 15:12:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29274 for ; Wed, 24 Jul 2002 15:12:31 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26896 for ; Wed, 24 Jul 2002 16:12:30 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 6A29F4B23; Thu, 25 Jul 2002 07:12:24 +0900 (JST) To: "Dave Thaler" Cc: ipng@sunroof.eng.sun.com In-reply-to: dthaler's message of Wed, 24 Jul 2002 15:06:40 MST. <2E33960095B58E40A4D3345AB9F65EC107384159@win-msg-01.wingroup.windeploy.ntdev.microsoft.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: Comments on draft-ietf-ipngwg-icmp-v3-02.txt From: itojun@iijlab.net Date: Thu, 25 Jul 2002 07:12:24 +0900 Message-Id: <20020724221224.6A29F4B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I'd like to see an ICMPv6 error message value assigned for the case >where a node would need to send a packet from a specific address, >but cannot because that address is anycast (since the other end >has no other good way of knowing this is the case). One example >of this is if a node receives a TCP SYN on an anycast address, >today it apparently has to silently drop the SYN, and the other >end can't tell why. >No existing ICMPv6 error message applies to this case. draft-itojun-ipv6-tcp-to-anycast-01.txt proposes to use addr unreach (code = 3), but i'm happy to see a new code for anycat case. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 15:16:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OMGroN022464; Wed, 24 Jul 2002 15:16:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6OMGrkc022463; Wed, 24 Jul 2002 15:16:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6OMGooN022456 for ; Wed, 24 Jul 2002 15:16:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01246 for ; Wed, 24 Jul 2002 15:16:52 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04686 for ; Wed, 24 Jul 2002 15:16:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17XUR9-000NOz-00; Wed, 24 Jul 2002 15:16:51 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Dave Thaler" Cc: Subject: Re: Comments on draft-ietf-ipngwg-icmp-v3-02.txt References: <2E33960095B58E40A4D3345AB9F65EC107384159@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-Id: Date: Wed, 24 Jul 2002 15:16:51 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'd like to see an ICMPv6 error message value assigned for the case where > a node would need to send a packet from a specific address, but cannot > because that address is anycast (since the other end has no other good way > of knowing this is the case). One example of this is if a node receives a > TCP SYN on an anycast address, today it apparently has to silently drop > the SYN, and the other end can't tell why. No existing ICMPv6 error > message applies to this case. there is an easier fix for this. un-break sourcing anycast packets from their proper address. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 16:58:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ONwcoN022707; Wed, 24 Jul 2002 16:58:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6ONwc0V022706; Wed, 24 Jul 2002 16:58:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6ONwXoN022699 for ; Wed, 24 Jul 2002 16:58:34 -0700 (PDT) Received: from lillen (d-umpk17-99-214.Eng.Sun.COM [129.146.99.214]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6ONwTg06155; Thu, 25 Jul 2002 01:58:29 +0200 (MEST) Date: Thu, 25 Jul 2002 01:56:44 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Comments and questions on dns-discovery To: john.loughney@nokia.com Cc: Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <0C1353ABB1DEB74DB067ADFF749C4EEFD38EDA@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is always manual configuration or some proprietary configuration > method (for example some sort of 'over the air' configuration for > cell phones using SMS). Anyhow, isn't an implementation decision > on what to implement and what not to? All we can do is make recommendations > on what implementations should do. If part of evaluating the applicability of dns-discovery is based on it being mandated to be the last resort, then it seems like there had better be a standard non-last resort which is tried before the last resort. Otherwise the statement about "last resort" is vacuous and should be removed from the document. Assuming that the statement stays in the document ... Saying that devices which implement DNS discovery MUST also implement a manual configuration method, and only if that manually configured stuff is not set (or fails?) does it fall back to using dns-discovery, would give some meaning to "last resort". But that would place a rather strict requirement on minimal IPv6 implementations since they would need a mechanism to enter the manual information. While cell phones might have ways to manually configuring this that doesn't require a user keying in IPv6 addresses on a keypad, an IPv6 toaster doesn't have such a mechanism. Hence for some devices it might make more sense to require DHCP as the non-last resort. So perhaps requiring either a DHCP method or a manual configuration (where the latter might imply a keypad) is the way to provide meaning to "last resort". Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 17:54:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P0s7oN022901; Wed, 24 Jul 2002 17:54:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6P0s70m022900; Wed, 24 Jul 2002 17:54:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P0s3oN022893 for ; Wed, 24 Jul 2002 17:54:03 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01123 for ; Wed, 24 Jul 2002 17:54:05 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13859 for ; Wed, 24 Jul 2002 18:54:04 -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 RAA17574; Wed, 24 Jul 2002 17:54:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6P0s2o20642; Wed, 24 Jul 2002 17:54:02 -0700 X-mProtect: <200207250054> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgmvfSM; Wed, 24 Jul 2002 17:53:59 PDT Message-Id: <4.3.2.7.2.20020724173840.02db3e10@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Jul 2002 17:53:15 -0700 To: IPv6 List From: Bob Hinden Subject: Concensus on Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At last weeks IPv6 meeting at the Yokohama IETF the "Default Address Selection" draft was discussed. After a review of the current draft and a short discussion, the w.g. chairs stated their belief that there was a rough consensus in the working group to move this draft forward to Proposes Standard. The people in the meeting overwhelming agreed. Consequentially, the chairs declared a consensus. The IPv6 w.g. chairs request the area directors to move forward to Proposed Standard in the IESG. Bob Hinden, Steve Deering, Margaret Wasserman IPv6 Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 18:23:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P1N0oN023002; Wed, 24 Jul 2002 18:23:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6P1N046023001; Wed, 24 Jul 2002 18:23:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P1MuoN022994 for ; Wed, 24 Jul 2002 18:22:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10774 for ; Wed, 24 Jul 2002 18:22:57 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14948 for ; Wed, 24 Jul 2002 19:22:56 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:955d:39d5:3220:695f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6P1LaA71458; Thu, 25 Jul 2002 10:21:36 +0900 (JST) Date: Thu, 25 Jul 2002 10:21:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ted Lemon Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 24 Jul 2002 10:21:39 -0700, >>>>> Ted Lemon said: >> to mean the diagram like this: >> >> NI query >> nodeinfo client ------------------> the target >> with named (authorizing the name) >> and private key >> <------------------ >> NI response signed >> by the private key >> >> (BTW: I understood the very original idea of this thread meant the >> diagram you showed.) > No, I was talking about securing the NI query, but not assuming that a > "name server" would do that work, except in the sense that by definition > anything that responds to a query for a name with a name could be called a > name server. So more accurately, you meant like this? NI query nodeinfo client ------------------> the target with some private key <------------------ NI response signed by the private key JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 19:22:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P2M1oN023128; Wed, 24 Jul 2002 19:22:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6P2M1m0023127; Wed, 24 Jul 2002 19:22:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P2LuoN023120 for ; Wed, 24 Jul 2002 19:21:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12502 for ; Wed, 24 Jul 2002 19:21:59 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03050 for ; Wed, 24 Jul 2002 20:21:58 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:955d:39d5:3220:695f]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6P2KeA72510; Thu, 25 Jul 2002 11:20:40 +0900 (JST) Date: Thu, 25 Jul 2002 11:20:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-Reply-To: <4250B782-9F6F-11D6-9D45-00039317663C@nominum.com> References: <4250B782-9F6F-11D6-9D45-00039317663C@nominum.com> <20020721222414.1D7F64B22@coconut.itojun.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Thu_Jul_25_11:20:39_2002-1" X-Dispatcher: imput version 20000228(IM140) Lines: 144 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Thu_Jul_25_11:20:39_2002-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Wed, 24 Jul 2002 18:38:45 -0700, >>>>> Ted Lemon said: >> So more accurately, you meant like this? >> >> NI query >> nodeinfo client ------------------> the target >> with some private key >> <------------------ >> NI response signed >> by the private key > Yes, where the name in the response is a valid domain name, and when the > client looks for a KEY record on that domain name, it finds a public key > that can be used to successfully validate the signature on the response. okay, so I guess you and itojun (attached) were talking about different things. Returning to your idea, it sounds attractive. However, I'm not sure if this approach is applicable widely. In particular, I'm not sure if "edge devices" such as personal laptops, PDAs, cell phones..., for which the nodeinfo-revlookup would be most useful, have private keys authorized in the DNSSEC framework. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Thu_Jul_25_11:20:39_2002-1 Content-Type: message/rfc822 Return-Path: Return-Path: Received: from localhost (localhost [127.0.0.1]) by ocean.jinmei.org (8.12.3/8.12.3) with ESMTP id g6M11bMR044819 for ; Mon, 22 Jul 2002 10:02:07 +0900 (JST) (envelope-from owner-ipng@sunroof.eng.sun.com) Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-5.9.11) for jinmei@localhost (single-drop); Mon, 22 Jul 2002 10:02:07 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6LMQUA30841 for ; Mon, 22 Jul 2002 07:26:30 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.11.6/8.11.6) with ESMTP id g6LMQTv04148 for ; Mon, 22 Jul 2002 07:26:29 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id HAA10807 for ; Mon, 22 Jul 2002 07:26:29 +0900 (JST) Received: from mx2.toshiba.co.jp (mx2.toshiba.co.jp [133.199.160.163]) by isl.rdc.toshiba.co.jp (8.11.6/8.11.6/1.4) with ESMTP id g6LMQSe27775 for ; Mon, 22 Jul 2002 07:26:28 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id HAA04660; Mon, 22 Jul 2002 07:26:28 +0900 (JST) Received: from inet-tsb2.toshiba.co.jp (localhost [127.0.0.1]) by tsb-sgw.toshiba.co.jp (8.9.3/3.7W) with ESMTP id HAA26519 for ; Mon, 22 Jul 2002 07:26:28 +0900 (JST) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by inet-tsb2.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id HAA22741 for ; Mon, 22 Jul 2002 07:26:27 +0900 (JST) Received: by orange.kame.net (Postfix) id 3BF1E71CE; Mon, 22 Jul 2002 07:26:27 +0900 (JST) Delivered-To: jinmei@kame.net Received: from sh.wide.ad.jp (kame202.kame.net [203.178.141.202]) by orange.kame.net (Postfix) with ESMTP id AAAFC71B2 for ; Mon, 22 Jul 2002 07:26:26 +0900 (JST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by sh.wide.ad.jp (8.11.6+3.4W/8.11.0) with ESMTP id g6LMQOF10436 for ; Mon, 22 Jul 2002 07:26:25 +0900 (JST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00565; Sun, 21 Jul 2002 15:25:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26295; Sun, 21 Jul 2002 15:25:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LMOLoN001049; Sun, 21 Jul 2002 15:24:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6LMOL8T001048; Sun, 21 Jul 2002 15:24:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6LMOHoN001041 for ; Sun, 21 Jul 2002 15:24:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05208 for ; Sun, 21 Jul 2002 15:24:18 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08550 for ; Sun, 21 Jul 2002 15:24:17 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1D7F64B22; Mon, 22 Jul 2002 07:24:14 +0900 (JST) To: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: Ted.Lemon's message of Sat, 20 Jul 2002 23:29:13 MST. <2C521845-9C73-11D6-B03B-00039317663C@nominum.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Mon, 22 Jul 2002 07:24:14 +0900 Message-Id: <20020721222414.1D7F64B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-UIDL: p5)#!'E1"!%(1"!I\9"! >> i may be asking a stupid question, but where do you get that private >> key from? for instance, if a node responds with "www.ietf.org", >> we could get a public key for www.ietf.org by KEY RR query, but >> not the private key (it's on ietf.org authoritative server, and >> is not accessible from outside). >Presumably the device answering the ICMP request is the one named, >and therefore knows the private key associated with its name. no, the device answering ICMPv6 request is not named. with the "type ipv6nodeinfo" directive, named will work like this: - accept DNS query from a DNS client resolver. - send NI query to the target address. - receive NI response from the target. - send DNS response to the original DNS client resolver. since the NI query target can return arbitrary FQDN (like "www.ietf.org") named does not have the private key. client resolver ---------> named -------> the target DNS query NI query client resolver <--------- named <------- the target DNS response NI response 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 -------------------------------------------------------------------- --Multipart_Thu_Jul_25_11:20:39_2002-1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 22:58:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P5wnoN023600; Wed, 24 Jul 2002 22:58:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6P5wnQx023599; Wed, 24 Jul 2002 22:58:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P5wkoN023592 for ; Wed, 24 Jul 2002 22:58:46 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA19801 for ; Wed, 24 Jul 2002 22:58:49 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA23455 for ; Wed, 24 Jul 2002 22:58:48 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6P5vgM18167; Thu, 25 Jul 2002 08:57:42 +0300 Date: Thu, 25 Jul 2002 08:57:41 +0300 (EEST) From: Pekka Savola To: Randy Bush cc: Dave Thaler , Subject: Re: Comments on draft-ietf-ipngwg-icmp-v3-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 24 Jul 2002, Randy Bush wrote: > > I'd like to see an ICMPv6 error message value assigned for the case where > > a node would need to send a packet from a specific address, but cannot > > because that address is anycast (since the other end has no other good way > > of knowing this is the case). One example of this is if a node receives a > > TCP SYN on an anycast address, today it apparently has to silently drop > > the SYN, and the other end can't tell why. No existing ICMPv6 error > > message applies to this case. > > there is an easier fix for this. un-break sourcing anycast packets from > their proper address. Exactly, plus e.g. "addr unreach" is good enough if you can't. (Note: a node should never have an anycast address of scope X if it does not also have a unicast address of at least scope X.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 24 23:29:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P6TqoN023683; Wed, 24 Jul 2002 23:29:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6P6Tqvb023682; Wed, 24 Jul 2002 23:29:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P6TnoN023675 for ; Wed, 24 Jul 2002 23:29:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18699 for ; Wed, 24 Jul 2002 23:29:52 -0700 (PDT) Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.42]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29081 for ; Thu, 25 Jul 2002 00:29:51 -0600 (MDT) Received: from rampe (rampe.atm.tut.fi [130.230.52.68]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id JAA20557; Thu, 25 Jul 2002 09:29:49 +0300 (EET DST) From: "Rami Lehtonen" To: "Dave Thaler" , Subject: RE: Comments on draft-ietf-ipngwg-icmp-v3-02.txt Date: Thu, 25 Jul 2002 09:29:47 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC107384159@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'd like to see an ICMPv6 error message value assigned for the case > where a node would > need to send a packet from a specific address, but cannot because that > address is > anycast (since the other end has no other good way of knowing this is > the case). > One example of this is if a node receives a TCP SYN on an anycast > address, today it > apparently has to silently drop the SYN, and the other end can't tell > why. > No existing ICMPv6 error message applies to this case. Not directly related to this issue, but... There was also some discussion at MAGMA working group that if the edge router starts to filter MLD Reports coming from a host (host authorization), it would be nice to notify the host that such filtering is applied, e.g. with ICMPv6 Administratively Prohibited. MLD Reports are however sent to multicast address and thus the router can't use ICMPv6 (spec says that error message MUST NOT be sent as a result of receiving a packet destined to an IPv6 multicast address). So, what about one more exception to the ICMPv6 spec in addition to the Packet Too Big and Parameter Problem messages? Rami Lehtonen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 25 00:49:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P7nGoN024219; Thu, 25 Jul 2002 00:49:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6P7nFXl024218; Thu, 25 Jul 2002 00:49:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P7nCoN024211 for ; Thu, 25 Jul 2002 00:49:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA14036 for ; Thu, 25 Jul 2002 00:49:14 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15830 for ; Thu, 25 Jul 2002 01:49:13 -0600 (MDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6P7nii27695 for ; Thu, 25 Jul 2002 10:49:44 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 25 Jul 2002 10:49:11 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 25 Jul 2002 10:49:11 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 25 Jul 2002 10:49:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Comments and questions on dns-discovery Date: Thu, 25 Jul 2002 10:49:10 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38EDB@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments and questions on dns-discovery Thread-Index: AcIzbgYf580MZ6QsSOu6drQ3MOq6AQAQQdTA To: Cc: X-OriginalArrivalTime: 25 Jul 2002 07:49:11.0372 (UTC) FILETIME=[C399B8C0:01C233AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6P7nDoN024212 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Eric, > If part of evaluating the applicability of dns-discovery > is based on it being mandated to be the last resort, then it > seems like there had better be a standard non-last resort which > is tried before the last resort. Otherwise the statement > about "last resort" > is vacuous and should be removed from the document. Well, either we should remove it, or add clarification on why it should be a last resort (see further comments below). > Assuming that the statement stays in the document ... > Saying that devices which implement DNS discovery MUST also implement > a manual configuration method, and only if that manually configured > stuff is not set (or fails?) does it fall back to using dns-discovery, would > give some meaning to "last resort". I agree. > But that would place a rather strict requirement on minimal IPv6 > implementations since they would need a mechanism to enter the manual > information. While cell phones might have ways to manually > configuring this > that doesn't require a user keying in IPv6 addresses on a keypad, an > IPv6 toaster doesn't have such a mechanism. > Hence for some devices it might make more sense to require DHCP as the > non-last resort. I think that text that states either DHCP or manual configuration MUST be supported would be best. > So perhaps requiring either a DHCP method or a manual configuration > (where the latter might imply a keypad) is the way to provide > meaning to "last resort". Should we do this in this document, or elsewhere? My thinking is that text along the lines of: This mechanism is not meant as a primary means for obtaining DNS addresses and should be used as backup. DHCP and/or manual configuration are recommended as primary mechanisms. And then in some document (perhaps the node requirements) we could have text discussing what is mandated, etc. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 25 01:12:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P8CKoN024274; Thu, 25 Jul 2002 01:12:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6P8CKYt024273; Thu, 25 Jul 2002 01:12:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P8CHoN024266 for ; Thu, 25 Jul 2002 01:12:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07012 for ; Thu, 25 Jul 2002 01:12:15 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13635 for ; Thu, 25 Jul 2002 01:12:14 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6P8BtL09143; Thu, 25 Jul 2002 10:11:55 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA29281; Thu, 25 Jul 2002 10:11:55 +0200 (MET DST) 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 g6P8BsGF097101; Thu, 25 Jul 2002 10:11:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207250811.g6P8BsGF097101@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ole Troan cc: "Nils Agne Nordbotten" , ipng@sunroof.eng.sun.com, niels.aakvaag@no.abb.com Subject: Re: DAD vs. DIID In-reply-to: Your message of Tue, 23 Jul 2002 14:08:08 BST. <7t5heiq1tjb.fsf@mrwint.cisco.com> Date: Thu, 25 Jul 2002 10:11:54 +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: consensus in the room was for DAD. => it should be very fine to get an official position about this. there was also a discussion whether DAD should be done only on manually configured addresses, and not on MAC address derived and random ones. no consensus in the room. Erik Nordmark suggested "optimistic DAD", but there was no time to discuss it. optimistic DAD looks to me to be a good compromise. => I disagree because the damage can be too great: I prefer collision avoidance to collision detection... As I explained in an old thread about this kind of issues, the choice for optimistic DAD *must* be in the hands of the network manager (i.e., the guy who will be in trouble if the very unlikely event happens). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 25 05:45:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PCj8oN024686; Thu, 25 Jul 2002 05:45:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6PCj8gC024685; Thu, 25 Jul 2002 05:45:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PCj5oN024678 for ; Thu, 25 Jul 2002 05:45:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18786 for ; Thu, 25 Jul 2002 05:45:06 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11096 for ; Thu, 25 Jul 2002 06:45:03 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g6PChnU06633; Thu, 25 Jul 2002 08:43:50 -0400 Message-Id: <200207251243.g6PChnU06633@cichlid.adsl.duke.edu> To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: AD comments on draft-ietf-ipv6-router-selection-02.txt Date: Thu, 25 Jul 2002 08:43:49 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The WG has requested that this document be advanced as a PS. I have completed my pre-IESG/pre-Last Call review (the one that shepherding AD makes prior to authorizing the IETF Last Call) and have some questions/comments. Main comments come first, more detailed comments/nits come at the end. Note that these comments come from me, not the IESG as a whole. The IESG as a whole won't review the document until the IETF Last Call has completed, I verify that any Last Call comments have been dealt with, and then formally request that the IESG consider the document for advancement. General comments: 1) I assume router-select is an optional document, and there is no intent to require all IPv6 nodes to implement it. However, it appears to contain a change to the ND specification, one intended that all ND implementations make. The Abstract says: The second change is a mandatory modification of the conceptual sending algorithm to support load-sharing among equivalent routers. The intro says: This document also describes a mandatory change in host behavior. Neighbor DiscoveryÆs conceptual sending algorithm is modified to require hosts to select randomly among equivalent routers. This distributes traffic to different destinations among the routers. Traffic to a single destination continues to use a single router, because of the Destination Cache. I assume that the above text resulted from a merging of draft-ietf-ipv6-host-load-sharing-00.txt with router-selection. If I understand the intent, I believe it is a mistake to merge the two documents. It would be better to keep all mandatory changes to the ND spec in a way that they are clearly identifiable. Burying mandatory changes to the ND document within a related (but optional-to-implement) document will make it hard for folks to find those changes. Resurrecting host-load-sharing seems a fine way to go. At some point, it would probably make sense to incorporate the text directly in the ND spec anyway. (Or maybe we should just delay making the update until ND needs to be respun -- this depends on what other issues people have with the ND spec.) 2) There is an assumption here that the adminstrators involved will coordinate with one another to configure sensible router preference values. However, I'm concerned that this assumption won't hold in practice. E.g., if I'm at home, I may have a tunnel to my corporation and a connection to the Internet (or multiple ones). (This scenario is described in the document). Howver, my ISP and my corporation simply won't coordinate here. Consequently, I'm wondering whether more guidance can be given here on how to set the preferences (in the absence of coordination among the site admins) and/or to make them configurable/mappable (on the user's host) so that if the preferences don't achieve the desired results by default, the user has some recourse to adjust them to result in better behavior. Indeed, adding more configuration capabilities on the host may make sense to go in also to help deal with Routers that aren't upgraded, in order to assign them preferences. Here is what the document says: > The preference values (both Default Router Preferences and Route > Preferences) should not be routing metrics or automatically derived > from metrics: the preference values should be configured. The High > and Low (non-default) preference values should only be used when > someone with knowledge of both routers and the network topology > configures them explicitly. For example, it could be a common > network administrator, or it could be a customer request to > different administrators managing the routers. I worry that the above will not hold in practice in a majority of cases. I wonder if a better applicability section would help, that describes where this is expected to be used and how things need to be configured by default in such environments. 3) The document isn't very clear about exactly when to probe, and what the actual probe algorithm is. ND has a very simple probe model. Whenever sending to/through a neighbor, if that neighbor is not known to be reachable (and sufficient time has elapsed), one probes. Probes are then retransmitted if not responded to. In ND, one never needs to probe neighboring routers that one is not actually using (except when all routers are unreachable). This is OK, because the assumption/model is that all neighboring routers are equal, and if you have a working one, there is no need to check for a better one. NUD handles the case where a next-hop fails and another one should be tried. With this document, the model changes. There is an assumption that some routers are better than others, and which router is better for a destination depends on the actual route prefixes that are advertised. That raises an issue of consistency. Are the neighbors that are being used always consistent with the known preferences of the routers? In particular, if a higher preference router is not reachable, when is it probed? Or, suppose there is a change in the routing table (a prefix is added or deleted), is there an attempt to (or a need to) revalidate that all the next-hops currently in use are the right ones based on the priorities/prefixes? It seems to me that a users of this document will intuitively expect that when the highest preference router is reachable, it will be used. Or when a higher preference router becomes available, routes will be updated to use it. the document says: > 3.3. Destination Cache Management > > When host C processes a Router Advertisement and updates its > conceptual Routing Table, it SHOULD invalidate or remove Destination > Cache Entries and redo next-hop determination for destinations > affected by the Routing Table changes. The host MAY implement this > requirement by flushing its entire Destination Cache. Seems like the above SHOULD should be a MUST, in order to meet the principle of least astonishment. However, the MAY seems ill-advised, as the Destination Cache may also include other information (e.g., path MTU info?) that should not be flushed as a side-effect of such a route change. Can the above be implemented reasonably without resorting to just flushing the table and rebuilding whenever a change is present? 4) I'm also unclear as to how easy it will be to implement the specific lookup algorithm that type C hosts will implement. My understandinng is that routing lookups today are done using longest-match, where the lookup stops at a particular node in the tree. I could imagine multiple nodes being at the same point in the tree (i.e., corresponding to two or more instances of a prefix but using different routers with possibly different preferences). But the algorithm specified actually says reachable routers are to be preferred over unreachable ones. This means that the longest-match lookup may stop at a node with an unreachable router. What is done in this case? Does one have to unwind the tree search to try a node visited earlier (i.e., a shorter match?)? Is this reasonable for implementations? [note: its not immediately clear that one can just remove nodes from the routing tree that correspond to unreachable routers, because one must also probe these routers in some cases.] Another implementation complexity is due to the preferences combined with the reachability status. Many implementations have a user-level process which takes preferences into account and only installs the most preferred route for a given prefix into the kernel. Hence the kernel need not be aware of preferences. Given the reachability status all routes need to be in the kernel since the most preferred for a given prefix might be unreachable and a less preferred route might exist for the identical prefix. Q: who has implemented this draft? Can they comment on the implementations issues mentioned above? ================ Specific comments and nits: > The second > change is a mandatory modification of the conceptual sending > algorithm to support load-sharing among equivalent routers. remove per earlier comments? > Neighbor Discovery is to > unicast routing as Multicast Listener Discovery is to multicast > routing. In both cases, a single simple protocol insulates the host > from the variety of router-to-router protocols. The comparison of MLD with ND seems pretty weak to me. Sure, they both isolate Host<->router interaction from router<->router interaction, but beyond that they are very different. Suggested reword: Neighbor Discovery shares with Multicast Listener Discovery the property that they both define host-to-router interactions, while shielding the host from having to participate in more general router-to-router interactions. > This document also describes a mandatory change in host behavior. > Neighbor DiscoveryÆs conceptual sending algorithm is modified to > require hosts to select randomly among equivalent routers. This > distributes traffic to different destinations among the routers. > Traffic to a single destination continues to use a single router, > because of the Destination Cache. Update per earlier comment? > 10 Reserved - MUST NOT be sent > If the > Reserved (10) value is received, the receiver should > treat the RA as having a zero Router Lifetime. s/should/MUST/ > Note that in addition to the preference value in the message header, > a Router Advertisement can also contain a Route Information Option > for ::/0, with a preference value and lifetime. Encoding a > preference value in the Router Advertisement header has some > advantages: > > 1. It allows for a distinction between "best default router" and > "best router for default", as described below in section 5.1. > > 2. When the best default router is also the best router for > default (which will be a common case), encoding the preference > value in the message header is more efficient than having to send > a separate option. After a number of re-reads, I still do not understand the above distinction. I think I understand the example, but the explanatory text above is not intuitive at all. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Shouldn't the picture show the prefix to be a variable width field? > Prf (Route Preference) > 2-bit signed integer. Indicates whether or not to prefer > this router for the prefix over others. reword for clarity (?): 2-bit signed integer. The Route Preference indicates whether to prefer the router associated with this prefix over others, when multiple identical prefixes (for different routers) have been received. > If the Reserved > (10) value is received, the Route Information Option > MUST be ignored. Why ignored? In the case where PrF is in the message header, the rules say treat the value as 00. What is the motivation for handling these two case differently? > Route Lifetime > 32-bit unsigned integer. The length of time in seconds > (relative to the time the packet is sent) that the > prefix is valid for route determination. A value of all > one bits (0xffffffff) represents infinity. Note that the lifetimes in ND are only 16-bits. It seems like it would be better to be consistent in the two documents. It is not immediately clear that a lifetime of longer htan 18.2 hours (the max per ND's 16 bits) is useful in practice. (Indeed, it may be worse the useful in that an (incorrect) entry with a long timeout can take days to weeks to expire.) Use 16 bits here as well? > The Length field is 1, 2, or 3 depending on Prefix Length. If Prefix > Length is greater than 64, then Length must be 3. If Prefix Length > is greater than 0, then Length must be 2 or 3. If Prefix Length is > zero, then Length must be 1, 2, or 3. This text might be placed by moving up to the desription of the "Length" field. > The Prefix field is 0, 8, or 16 octets depending on Length. Move sentence to description of Prefix field? > Routers SHOULD NOT include in a Router Advertisement two Route > Information Options with the same Prefix and Prefix Length. Seems like MUST NOT would be better. Is there ever a valid reason to allow routers to include two such options? > 3. Conceptual Model of a Host > > There are three possible conceptual models for host implementation > of default router preferences and more-specific routes, > corresponding to different levels of support. We refer to these as > host A, host B, and host C. Note that these are really classes of > hosts, not individual hosts. It would be more clear to use different terminology here. Rather than saying "host A", say something like "Type-A host", "or level-1 compliant host", etc. This change would need to be made throughout the document. > Host A ignores default router preferences and more-specific routes. > Host A uses the conceptual data structures described in Neighbor > Discovery [2]. > More clear to say something like Host [type] A implements Neighbor Discovery as defined in [2] and does not implement any of the extensions described in this document. > Host B uses a Default Router List augmented with preference values. > Host B does not have a routing table. replace second sentence with: , but ignores all Route Information Options. > Host C uses a Routing Table instead of a Default Router List. (The > Routing Table may also subsume the Prefix List, but that is beyond > the scope of this document.) Entries in the Routing Table have a Host C still DOES use a Default router list of some sort, but it is presumably integrated with the routing table. > When a host avoids using a non-reachable router X and instead uses > another router Y, and the host would have used router X if router X > were reachable, then the host SHOULD probe router X's reachability > by sending a Neighbor Solicitation. A host MUST NOT probe a router's > reachability in the absence of useful traffic that the host would > have sent to the router if it were reachable. In any case, these > probes MUST be rate-limited to no more than one per minute per > router. details are left unspecified here, but may be significant. For one thing, the above says "sending a Neighbor Solicitation". Is that what a probe is? Or does sending probes include retransmitting? The document isn't clear on this. > When a host chooses from multiple equivalent routers, it MUST choose > randomly. Define random better. Is it OK to pick a random order once (when the list is built) and then do RR on the resultant list? Or must each new choice of a router for a destination result in new random choice? (I would assume the former is sufficient.) > 4. Router Configuration applicability? intended usage, restrictions? The preference values (both Default Router Preferences and Route Preferences) should not be routing metrics or automatically derived from metrics: the preference values should be configured. The High and Low (non-default) preference values should only be used when someone with knowledge of both routers and the network topology configures them explicitly. For example, it could be a common network administrator, or it could be a customer request to different administrators managing the routers. Not clear this is workable in practice. An administrator of a router may configure the router to advertise specific routes for directly connected subnets and any shorter prefixes (eg, site, NLA, or TLA prefixes) for networks to which the router belongs. Nit: TLA/NLA terminology is no longer in use. Separate references into normative/non-normative sections. 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 Jul 25 10:04:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PH42oN025134; Thu, 25 Jul 2002 10:04:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6PH42Js025133; Thu, 25 Jul 2002 10:04:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PH3woN025126 for ; Thu, 25 Jul 2002 10:03:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28528 for ; Thu, 25 Jul 2002 10:04:00 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12314 for ; Thu, 25 Jul 2002 11:03:52 -0600 (MDT) Received: from localhost (PPP40.air128.dti.ne.jp [210.170.212.43]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6PH3gA84678; Fri, 26 Jul 2002 02:03:43 +0900 (JST) Date: Fri, 26 Jul 2002 02:03:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ted Lemon Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt In-Reply-To: <90AF0F5A-9F7B-11D6-9D45-00039317663C@nominum.com> References: <90AF0F5A-9F7B-11D6-9D45-00039317663C@nominum.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 33 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 24 Jul 2002 20:06:51 -0700, >>>>> Ted Lemon said: >> Returning to your idea, it sounds attractive. However, I'm not sure >> if this approach is applicable widely. In particular, I'm not sure if >> "edge devices" such as personal laptops, PDAs, cell phones..., for >> which the nodeinfo-revlookup would be most useful, have private keys >> authorized in the DNSSEC framework. > Why not? I think they do probably have private keys, and configuring them > with the private side of a DNSSEC key doesn't sound very hard. It does > sound like it would be quite useful. :') It is probably okay to assume the devices have some private keys. My concerns (or what I'm not sure about) are: - how to register the keys to DNS. Manual configuration (by an administrator) is not realistic for general cases, but I'm not sure if DNS dynamic update is effective. - how to construct the trust chain of DNSSEC toward the root zone. The zone to which the edge devices belong is presumably a kind of "personal" one, and we may not always assume it is a secure zone. In fact, in my understanding the current trend of DNSSEC is to restrict signed zones to some "well-known" ones such as a zone containing famous commercial web servers. Some may have an idea to deal with this, though. If there is a concrete idea of an entire system, I'm very interested in it. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 25 10:14:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PHEcoN025217; Thu, 25 Jul 2002 10:14:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6PHEcpL025216; Thu, 25 Jul 2002 10:14:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PHEYoN025209 for ; Thu, 25 Jul 2002 10:14:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20699 for ; Thu, 25 Jul 2002 10:14:36 -0700 (PDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29337 for ; Thu, 25 Jul 2002 11:14:35 -0600 (MDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id SAA16455; Thu, 25 Jul 2002 18:14:34 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: ipng@sunroof.eng.sun.com Subject: Comments on draft-ietf-ipv6-tunnel-v02-00.txt References: <200207241208.IAA02219@ietf.org> From: Ole Troan Date: Thu, 25 Jul 2002 18:14:34 +0100 In-Reply-To: <200207241208.IAA02219@ietf.org> (Internet-Drafts@ietf.org's message of "Wed, 24 Jul 2002 08:08:20 -0400") Message-ID: <7t5vg73log5.fsf@mrwint.cisco.com> Lines: 3 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk why not remove the "Tunnel Encapsulation Option" altogether? /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 25 10:32:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PHWHoN025262; Thu, 25 Jul 2002 10:32:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6PHWHDg025261; Thu, 25 Jul 2002 10:32:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PHWFoN025254 for ; Thu, 25 Jul 2002 10:32:15 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6PHVXGZ016232 for ; Thu, 25 Jul 2002 10:31:33 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6PHVWmC016231 for ipng@sunroof.eng.sun.com; Thu, 25 Jul 2002 10:31:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P1cWoN023072 for ; Wed, 24 Jul 2002 18:38:32 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24387 for ; Wed, 24 Jul 2002 18:38:34 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26137 for ; Wed, 24 Jul 2002 18:38:34 -0700 (PDT) Received: from green.bisbee.fugue.com (a47.tc43.theriver.com [206.26.123.239]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6P1cKd03026; Thu, 25 Jul 2002 01:38:20 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6P1ckfD001837; Wed, 24 Jul 2002 18:38:46 -0700 (MST) Date: Wed, 24 Jul 2002 18:38:45 -0700 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= From: Ted Lemon In-Reply-To: Message-Id: <4250B782-9F6F-11D6-9D45-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So more accurately, you meant like this? > > NI query > nodeinfo client ------------------> the target > with some private key > <------------------ > NI response signed > by the private key Yes, where the name in the response is a valid domain name, and when the client looks for a KEY record on that domain name, it finds a public key that can be used to successfully validate the signature on the response. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 25 10:32:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PHWhoN025272; Thu, 25 Jul 2002 10:32:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6PHWh2X025271; Thu, 25 Jul 2002 10:32:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PHWfoN025264 for ; Thu, 25 Jul 2002 10:32:41 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6PHVwGZ016240 for ; Thu, 25 Jul 2002 10:31:58 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6PHVwhV016239 for ipng@sunroof.eng.sun.com; Thu, 25 Jul 2002 10:31:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6P36coN023186 for ; Wed, 24 Jul 2002 20:06:38 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11600 for ; Wed, 24 Jul 2002 20:06:40 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22319 for ; Wed, 24 Jul 2002 20:06:40 -0700 (PDT) Received: from green.bisbee.fugue.com (az-ben-pm3-2-14.ppp.theriver.com [206.25.50.14]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g6P36Od03189; Thu, 25 Jul 2002 03:06:25 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g6P36pfD001859; Wed, 24 Jul 2002 20:06:51 -0700 (MST) Date: Wed, 24 Jul 2002 20:06:51 -0700 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= From: Ted Lemon In-Reply-To: Message-Id: <90AF0F5A-9F7B-11D6-9D45-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Returning to your idea, it sounds attractive. However, I'm not sure > if this approach is applicable widely. In particular, I'm not sure if > "edge devices" such as personal laptops, PDAs, cell phones..., for > which the nodeinfo-revlookup would be most useful, have private keys > authorized in the DNSSEC framework. Why not? I think they do probably have private keys, and configuring them with the private side of a DNSSEC key doesn't sound very hard. It does sound like it would be quite useful. :') -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 25 15:07:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PM7toN025971; Thu, 25 Jul 2002 15:07:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6PM7tZa025970; Thu, 25 Jul 2002 15:07:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6PM7poN025963 for ; Thu, 25 Jul 2002 15:07:52 -0700 (PDT) Received: from lillen (d-usca03-225-241.SFBay.Sun.COM [129.145.225.241]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6PM7kg14207; Fri, 26 Jul 2002 00:07:47 +0200 (MEST) Date: Fri, 26 Jul 2002 00:06:01 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Comments and questions on dns-discovery To: john.loughney@nokia.com Cc: Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <0C1353ABB1DEB74DB067ADFF749C4EEFD38EDB@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Should we do this in this document, or elsewhere? My thinking is > that text along the lines of: > > This mechanism is not meant as a primary means for obtaining DNS > addresses and should be used as backup. DHCP and/or manual > configuration are recommended as primary mechanisms. > > And then in some document (perhaps the node requirements) we could > have text discussing what is mandated, etc. I think each specification should clearly state interrelationships that are local to this specification. For instance, if you implement the foo spec you MUST implement the mechanism to secure it with IPsec. We shouldn't punt such constraints to a node requirements document. Instead the node requirement should talk about which specifications are required, and conditional requirements between them. For instance, if you implement RFC X you MUST implement RFC y as well. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 25 17:40:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q0ewoN026372; Thu, 25 Jul 2002 17:40:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6Q0ew3D026371; Thu, 25 Jul 2002 17:40:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q0esoN026364 for ; Thu, 25 Jul 2002 17:40:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26711 for ; Thu, 25 Jul 2002 17:40:54 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19770 for ; Thu, 25 Jul 2002 18:40:54 -0600 (MDT) Received: from kenawang ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA13368 for ; Thu, 25 Jul 2002 17:39:02 -0700 (PDT) Message-Id: <4.2.2.20020725202841.03ff4ac0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 25 Jul 2002 20:37:22 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Basic Sockets Extensions I-D is about to be published with the file name: draft-ietf-ipngwg-rfc2553bis-06.txt. This document has already undergone WG last call, and was forwarded to the IESG for publication as an Informational RFC. Based on feedback from our AD regarding a normative reference to the Scoped Addressing Architecture document (which isn't an RFC yet), the API extensions to support scoped addressing have moved to a separate API extension document: draft-ietf-ipv6-scope-api-00.txt. If there are any comments on this change, please send them to the WG mailing list by the end of the day on Tuesday, July 30th. Unless we hear any objections, we will ask the IESG to approve draft-ietf-ipngwg-rfc2553bis-06.txt for publication as an Informational RFC. We will consider publication of the scoped addressing extensions once the Scoped Addressing Architecture document is ready for publication. Thanks, Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 25 20:01:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q31eoN027103; Thu, 25 Jul 2002 20:01:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6Q31eb9027102; Thu, 25 Jul 2002 20:01:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q31aoN027095 for ; Thu, 25 Jul 2002 20:01:36 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA13325 for ; Thu, 25 Jul 2002 20:01:39 -0700 (PDT) Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05255 for ; Thu, 25 Jul 2002 21:01:38 -0600 (MDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KKJUWX5LEI9EEJCZ@vaxc.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 26 Jul 2002 12:52:12 +1000 Received: from blammo (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id E06AF12C011; Fri, 26 Jul 2002 12:52:04 +1000 (EST) Received: from eng.monash.edu.au (brettpc.eng.monash.edu.au [130.194.252.100]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 5026E12C011; Fri, 26 Jul 2002 12:51:59 +1000 (EST) Date: Fri, 26 Jul 2002 12:52:01 +1000 From: Brett Pentland Subject: Re: DAD vs. DIID X-Sender: "Brett Pentland" To: Francis Dupont Cc: Ole Troan , Nils Agne Nordbotten , ipng@sunroof.eng.sun.com, niels.aakvaag@no.abb.com Message-id: <3D40B951.719D1C1C@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en]C-CCK-MCD monwin/025 (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200207250811.g6P8BsGF097101@givry.rennes.enst-bretagne.fr> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I admit I don't have a good feel for just how bad the consequences of a collision are, but allowing the network manager to choose not to allow optimistic DAD seems like a reasonable position. In this case the manager needs an easy way to be able to stop hosts from doing optimistic DAD (or to be able to allow it depending on the default). Perhaps a flag could be added to the Router Advertisement messages to control this behavior? Regards, Brett. Francis Dupont wrote: > > In your previous mail you wrote: > > consensus in the room was for DAD. > > => it should be very fine to get an official position about this. > > there was also a discussion whether DAD should be done only on > manually configured addresses, and not on MAC address derived and > random ones. no consensus in the room. Erik Nordmark suggested > "optimistic DAD", but there was no time to discuss it. > > optimistic DAD looks to me to be a good compromise. > > => I disagree because the damage can be too great: I prefer > collision avoidance to collision detection... > As I explained in an old thread about this kind of issues, > the choice for optimistic DAD *must* be in the hands of the network > manager (i.e., the guy who will be in trouble if the very unlikely > event happens). > > Regards > > Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 25 22:38:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q5cwoN027704; Thu, 25 Jul 2002 22:38:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6Q5cwD1027703; Thu, 25 Jul 2002 22:38:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6Q5ctoN027696 for ; Thu, 25 Jul 2002 22:38:55 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA21648 for ; Thu, 25 Jul 2002 22:38:57 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA25820 for ; Thu, 25 Jul 2002 22:38:56 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6Q5cb029383; Fri, 26 Jul 2002 08:38:38 +0300 Date: Fri, 26 Jul 2002 08:38:37 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: your mail In-Reply-To: <4.2.2.20020725202841.03ff4ac0@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 25 Jul 2002, Margaret Wasserman wrote: > yet), the API extensions to support scoped addressing have moved to a > separate API extension document: draft-ietf-ipv6-scope-api-00.txt. No such thing exists (yet, at least). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 26 05:49:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnqoN029761; Fri, 26 Jul 2002 05:49:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QCnpE4029760; Fri, 26 Jul 2002 05:49:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QCnCoN029703; Fri, 26 Jul 2002 05:49:13 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13299; Fri, 26 Jul 2002 05:49:14 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15460; Fri, 26 Jul 2002 06:49:13 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 2260E6A90F; Fri, 26 Jul 2002 15:49:12 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C69266A911; Fri, 26 Jul 2002 15:49:00 +0300 (EEST) Message-ID: <3D413DCB.7000801@kolumbus.fi> Date: Fri, 26 Jul 2002 15:17:15 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Mohan Parthasarathy Cc: shima , mat@cisco.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: summary of HAO, BE processing discussion References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF221@TNEXVS02.tahoenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 X-Spam-Level: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mohan Parthasarathy wrote: > > > In addition, the current draft requires not only HAO but > > also BE. This > > > means all IPv6 nodes must implement a new extention header > > (mobility > > > header). > > > > > > Correct. > > > If you read section 9.4.6, "Sending Binding Errors", yes it is > correct. But reading section 6.3 "Home Address option", it says > that if a node does not understand this option, it should return > ICMP parameter problem. Are these in conflict ? No, ICMP is used if you don't recognize the option. This is standard behaviour in IPv6. BE is used if you understand the option but don't like the contents. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 26 07:41:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QEfToN001969; Fri, 26 Jul 2002 07:41:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QEfTab001968; Fri, 26 Jul 2002 07:41:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QEfPoN001961 for ; Fri, 26 Jul 2002 07:41:25 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11557 for ; Fri, 26 Jul 2002 07:41:27 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06831 for ; Fri, 26 Jul 2002 08:41:26 -0600 (MDT) Received: from kenawang ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA26232; Fri, 26 Jul 2002 07:39:26 -0700 (PDT) Message-Id: <4.2.2.20020726104111.00a9b3f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 26 Jul 2002 10:41:38 -0400 To: Pekka Savola From: Margaret Wasserman Subject: Re: your mail Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <4.2.2.20020725202841.03ff4ac0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The document has just been approved for publication and should be available soon. Margaret At 01:38 AM 7/26/02 , Pekka Savola wrote: >On Thu, 25 Jul 2002, Margaret Wasserman wrote: > > yet), the API extensions to support scoped addressing have moved to a > > separate API extension document: draft-ietf-ipv6-scope-api-00.txt. > >No such thing exists (yet, at least). > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 26 11:33:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QIXvoN003477; Fri, 26 Jul 2002 11:33:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QIXuKb003476; Fri, 26 Jul 2002 11:33:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QIXroN003469 for ; Fri, 26 Jul 2002 11:33:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09426 for ; Fri, 26 Jul 2002 11:33:55 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14485 for ; Fri, 26 Jul 2002 12:33:55 -0600 (MDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6QIXsNv029682; Fri, 26 Jul 2002 14:33:54 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6QIXsAH048766; Fri, 26 Jul 2002 12:33:54 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g6QIXBl10383; Fri, 26 Jul 2002 14:33:11 -0400 Message-Id: <200207261833.g6QIXBl10383@rotala.raleigh.ibm.com> To: "Dave Thaler" cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on draft-ietf-ipngwg-icmp-v3-02.txt In-Reply-To: Message from "Wed, 24 Jul 2002 15:06:40 PDT." <2E33960095B58E40A4D3345AB9F65EC107384159@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 26 Jul 2002 14:33:11 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'd like to see an ICMPv6 error message value assigned for the case > where a node would need to send a packet from a specific address, > but cannot because that address is anycast (since the other end has > no other good way of knowing this is the case). Under what conditions would such a message be sent? For many uses, sending to an anycast address should not trigger an ICMP (the higher layer in some cases *could* deal with an anycast address). In general, it might be hard to come up with clear rules for when to send such a message and when not. I believe most ICMP messages are generated in response to very specific situations, where there isn't much thinking involved in whether to send or not. Can we define what those situations are in the case of your proposed message? > One example of this is if a node receives a TCP SYN on an anycast > address, today it apparently has to silently drop the SYN, and the > other end can't tell why. No existing ICMPv6 error message applies > to this case. The above isn't immediately obvious to me. TCP *could* also use the recieved SYN as an indication that it should send a SYN in the reverse direction using a proper source address. That SYN might even include a option connecting it to the anycast address to which the first SYN was directed. (Clearly details would need to be fleshed out to make this all work.) My point here is it's not immediately obvious to me when an implementation is supposed to send an ICMP message in response to a packet sent to an anycast address. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 26 11:52:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QIqNoN003815; Fri, 26 Jul 2002 11:52:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QIqMSE003814; Fri, 26 Jul 2002 11:52:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QIqJoN003807 for ; Fri, 26 Jul 2002 11:52:19 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16712 for ; Fri, 26 Jul 2002 11:52:21 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13703 for ; Fri, 26 Jul 2002 11:52:21 -0700 (PDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 3F74B431; Fri, 26 Jul 2002 11:52:20 -0700 (PDT) Date: Fri, 26 Jul 2002 11:52:20 -0700 From: David Terrell To: JINMEI Tatuya / ??????????? Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt Message-ID: <20020726185220.GA2585@pianosa.catch22.org> Reply-To: David Terrell References: <90AF0F5A-9F7B-11D6-9D45-00039317663C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 11:50AM up 18 days, 11:42, 52 users, load averages: 0.74, 0.48, 0.38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Jul 26, 2002 at 02:03:39AM +0900, JINMEI Tatuya / ??????????? wrote: > >>>>> On Wed, 24 Jul 2002 20:06:51 -0700, > >>>>> Ted Lemon said: > > >> Returning to your idea, it sounds attractive. However, I'm not sure > >> if this approach is applicable widely. In particular, I'm not sure if > >> "edge devices" such as personal laptops, PDAs, cell phones..., for > >> which the nodeinfo-revlookup would be most useful, have private keys > >> authorized in the DNSSEC framework. > > > Why not? I think they do probably have private keys, and configuring them > > with the private side of a DNSSEC key doesn't sound very hard. It does > > sound like it would be quite useful. :') > > It is probably okay to assume the devices have some private keys. My > concerns (or what I'm not sure about) are: > > - how to register the keys to DNS. Manual configuration (by an > administrator) is not realistic for general cases, but I'm not sure > if DNS dynamic update is effective. In the mobile, dynamic IPv6 world, it seems like having public keys in DNS would be fairly common for things like secured NSUPDATE, so the host would already be doing this. > - how to construct the trust chain of DNSSEC toward the root zone. > The zone to which the edge devices belong is presumably a kind of > "personal" one, and we may not always assume it is a secure zone. > In fact, in my understanding the current trend of DNSSEC is to > restrict signed zones to some "well-known" ones such as a zone > containing famous commercial web servers. Something tells me that a lot of people on this mailling list will have signed, secure zones long before these famous commercial web servers... -- David Terrell | Step 1: "configure one system using your GUI" dbt@meat.net | Step 2: "now configure 1000 more" Nebcorp Prime Minister | - Casper H.S. Dik http://wwn.nebcorp.com | -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 26 14:03:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QL33oN004074; Fri, 26 Jul 2002 14:03:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6QL33Bv004073; Fri, 26 Jul 2002 14:03:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6QL2xoN004066 for ; Fri, 26 Jul 2002 14:02:59 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24897; Fri, 26 Jul 2002 17:03:01 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g6QL30Zs005251; Fri, 26 Jul 2002 17:03:00 -0400 (EDT) Message-Id: <200207262103.g6QL30Zs005251@thunk.east.sun.com> From: Bill Sommerfeld To: george+ipng@m5p.com cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated In-Reply-To: Your message of "Tue, 23 Jul 2002 13:39:54 PDT." <200207232039.g6NKdsmI006124@m5p.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 26 Jul 2002 17:03:00 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Given that there is no documented method to do stateless HAO verification, I believe it's extremely premature to make HAO a MUST. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 26 17:06:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6R068oN004865; Fri, 26 Jul 2002 17:06:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6R068Fg004864; Fri, 26 Jul 2002 17:06:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6R064oN004857 for ; Fri, 26 Jul 2002 17:06:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15854 for ; Fri, 26 Jul 2002 17:06:07 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA11965 for ; Fri, 26 Jul 2002 18:06:07 -0600 (MDT) Received: from kenawang ([147.11.233.6]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA15817 for ; Fri, 26 Jul 2002 17:06:05 -0700 (PDT) Message-Id: <4.2.2.20020726200033.02c224f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 26 Jul 2002 20:01:58 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: WG Last Call for Basic Sockets API: draft-ietf-ipngwg-rfc2553bis-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Resending with non-blank subject line, so that no one will accidentally miss the message... Margaret >Date: Thu, 25 Jul 2002 20:37:22 -0400 >To: ipng@sunroof.eng.sun.com >From: Margaret Wasserman > > >A new Basic Sockets Extensions I-D is about to be published with >the file name: draft-ietf-ipngwg-rfc2553bis-06.txt. This document >has already undergone WG last call, and was forwarded to the IESG >for publication as an Informational RFC. > >Based on feedback from our AD regarding a normative reference >to the Scoped Addressing Architecture document (which isn't an RFC >yet), the API extensions to support scoped addressing have moved to a >separate API extension document: draft-ietf-ipv6-scope-api-00.txt. > >If there are any comments on this change, please send them to >the WG mailing list by the end of the day on Tuesday, July 30th. >Unless we hear any objections, we will ask the IESG to approve >draft-ietf-ipngwg-rfc2553bis-06.txt for publication as an >Informational RFC. > >We will consider publication of the scoped addressing extensions once >the Scoped Addressing Architecture document is ready for publication. > >Thanks, >Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 26 19:19:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6R2JXoN005456; Fri, 26 Jul 2002 19:19:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6R2JWeb005454; Fri, 26 Jul 2002 19:19:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6R2JSoN005444 for ; Fri, 26 Jul 2002 19:19:29 -0700 (PDT) Received: from lillen (d-umpk17-99-214.Eng.Sun.COM [129.146.99.214]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6R2JRg20476; Sat, 27 Jul 2002 04:19:27 +0200 (MEST) Date: Sat, 27 Jul 2002 04:17:39 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DAD vs. DIID To: Ole Troan Cc: Nils Agne Nordbotten , ipng@sunroof.eng.sun.com, niels.aakvaag@no.abb.com In-Reply-To: "Your message with ID" <7t5heiq1tjb.fsf@mrwint.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > there was also a discussion whether DAD should be done only on > manually configured addresses, and not on MAC address derived and > random ones. no consensus in the room. Erik Nordmark suggested > "optimistic DAD", but there was no time to discuss it. I hope I merely suggested that "optimistic DAD" be explored to better understand the issues and benefits. > optimistic DAD looks to me to be a good compromise. A possible implication of optimistic DAD (i.e. where an address is assigned to the interface and used before it is known whether it is a duplicate) is that - neighbor caches in order nodes will have the wrong information and need to be switched back to the correct, original information once DAD fails. - TCP connections might be reset (a packet arrives at the new node, which doesn't have the TCP state so it sends a reset; the real "owner" of the address has the TCP state) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 28 19:25:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T2PxoN009234; Sun, 28 Jul 2002 19:25:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6T2PxKB009233; Sun, 28 Jul 2002 19:25:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T2PtoN009226 for ; Sun, 28 Jul 2002 19:25:55 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA08183 for ; Sun, 28 Jul 2002 19:26:00 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29648 for ; Sun, 28 Jul 2002 20:25:59 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 826414B22; Mon, 29 Jul 2002 11:25:54 +0900 (JST) To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Sat, 27 Jul 2002 04:17:39 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: DAD vs. DIID From: itojun@iijlab.net Date: Mon, 29 Jul 2002 11:25:54 +0900 Message-Id: <20020729022554.826414B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> optimistic DAD looks to me to be a good compromise. >A possible implication of optimistic DAD (i.e. where an address is assigned >to the interface and used before it is known whether it is a duplicate) is >that > - neighbor caches in order nodes will have the wrong information and need > to be switched back to the correct, original information once DAD fails. > - TCP connections might be reset (a packet arrives at the new node, which > doesn't have the TCP state so it sends a reset; the real "owner" of the > address has the TCP state) for this reason, i'm not a fan of optimistic DAD. my preference is to run full DAD (will take 1 second or so), for every address assigned to the node. the rule is simple - run it for every address you assign to the node, that's all. 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 Sun Jul 28 20:04:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T34moN009309; Sun, 28 Jul 2002 20:04:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6T34m3d009308; Sun, 28 Jul 2002 20:04:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T34ioN009301 for ; Sun, 28 Jul 2002 20:04:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA15454 for ; Sun, 28 Jul 2002 20:04:49 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08196 for ; Sun, 28 Jul 2002 21:04:48 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 035114B23; Mon, 29 Jul 2002 12:04:45 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Thu, 25 Jul 2002 08:57:41 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-ietf-ipngwg-icmp-v3-02.txt From: itojun@iijlab.net Date: Mon, 29 Jul 2002 12:04:44 +0900 Message-Id: <20020729030445.035114B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> > I'd like to see an ICMPv6 error message value assigned for the case where >> > a node would need to send a packet from a specific address, but cannot >> > because that address is anycast (since the other end has no other good way >> > of knowing this is the case). One example of this is if a node receives a >> > TCP SYN on an anycast address, today it apparently has to silently drop >> > the SYN, and the other end can't tell why. No existing ICMPv6 error >> > message applies to this case. >> there is an easier fix for this. un-break sourcing anycast packets from >> their proper address. >Exactly, plus e.g. "addr unreach" is good enough if you can't. pitfall alert: the term "anycast" is used with very vague definition here. Dave is talking about RFC2460 anycast, Randy is talking about "unicast address appear in multicast location" anycast (pseudo-anycast in draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt). read draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt for more on this topic. 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 Sun Jul 28 20:18:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T3IRoN009346; Sun, 28 Jul 2002 20:18:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6T3IRRt009345; Sun, 28 Jul 2002 20:18:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T3INoN009338 for ; Sun, 28 Jul 2002 20:18:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA20916 for ; Sun, 28 Jul 2002 20:18:29 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA25723 for ; Sun, 28 Jul 2002 21:18:27 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0722E4B22; Mon, 29 Jul 2002 12:18:23 +0900 (JST) To: Ted Lemon Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: Ted.Lemon's message of Wed, 24 Jul 2002 18:38:45 MST. <4250B782-9F6F-11D6-9D45-00039317663C@nominum.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-itojun-ipv6-nodeinfo-revlookup-00.txt From: itojun@iijlab.net Date: Mon, 29 Jul 2002 12:18:23 +0900 Message-Id: <20020729031823.0722E4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> So more accurately, you meant like this? >> >> NI query >> nodeinfo client ------------------> the target >> with some private key >> <------------------ >> NI response signed >> by the private key >Yes, where the name in the response is a valid domain name, and when the >client looks for a KEY record on that domain name, it finds a public key >that can be used to successfully validate the signature on the response. again, there's no protocol for signing ICMPv6 using private key. IPsec (AH/ESP) doesn't work here. do you have any proposal? 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 Sun Jul 28 21:09:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T49koN009493; Sun, 28 Jul 2002 21:09:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6T49kJD009492; Sun, 28 Jul 2002 21:09:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T49hoN009485 for ; Sun, 28 Jul 2002 21:09:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA26590 for ; Sun, 28 Jul 2002 21:09:47 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA07513; Sun, 28 Jul 2002 22:09:46 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6T49b200645; Mon, 29 Jul 2002 07:09:38 +0300 Date: Mon, 29 Jul 2002 07:09:37 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: Erik Nordmark , Subject: Re: DAD vs. DIID In-Reply-To: <20020729022554.826414B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 29 Jul 2002 itojun@iijlab.net wrote: > >> optimistic DAD looks to me to be a good compromise. > >A possible implication of optimistic DAD (i.e. where an address is assigned > >to the interface and used before it is known whether it is a duplicate) is > >that > > - neighbor caches in order nodes will have the wrong information and need > > to be switched back to the correct, original information once DAD fails. > > - TCP connections might be reset (a packet arrives at the new node, which > > doesn't have the TCP state so it sends a reset; the real "owner" of the > > address has the TCP state) > > for this reason, i'm not a fan of optimistic DAD. my preference > is to run full DAD (will take 1 second or so), for every address > assigned to the node. the rule is simple - run it for every address > you assign to the node, that's all. Wouldn't it be much much simpler just to do DIID? I see zero reason for e.g. PRFX1::1/64 and PRFX2::1/64 being assigned on two different nodes in a same subnet. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 28 21:14:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T4EHoN009514; Sun, 28 Jul 2002 21:14:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6T4EGoo009513; Sun, 28 Jul 2002 21:14:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T4EDoN009506 for ; Sun, 28 Jul 2002 21:14:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA17620 for ; Sun, 28 Jul 2002 21:14:18 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA13420 for ; Sun, 28 Jul 2002 22:14:16 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6T4EBP00692; Mon, 29 Jul 2002 07:14:11 +0300 Date: Mon, 29 Jul 2002 07:14:10 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on draft-ietf-ipngwg-icmp-v3-02.txt In-Reply-To: <20020729030445.035114B23@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 29 Jul 2002 itojun@iijlab.net wrote: > >> > I'd like to see an ICMPv6 error message value assigned for the case where > >> > a node would need to send a packet from a specific address, but cannot > >> > because that address is anycast (since the other end has no other good way > >> > of knowing this is the case). One example of this is if a node receives a > >> > TCP SYN on an anycast address, today it apparently has to silently drop > >> > the SYN, and the other end can't tell why. No existing ICMPv6 error > >> > message applies to this case. > >> there is an easier fix for this. un-break sourcing anycast packets from > >> their proper address. > >Exactly, plus e.g. "addr unreach" is good enough if you can't. > > pitfall alert: > > the term "anycast" is used with very vague definition here. > Dave is talking about RFC2460 anycast, Randy is talking about "unicast > address appear in multicast location" anycast (pseudo-anycast in > draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt). > > read draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt for more on this > topic. Please elaborate. I don't think the draft discusses this at all. With RFC2460 anycast, you can always assume there is another unicast address of at least same scope assigned on the node. As the node cannot use RFC2460 address as a source address, it will use unicast address. Problem solved(?). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 28 21:20:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T4KmoN009538; Sun, 28 Jul 2002 21:20:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6T4KlSu009537; Sun, 28 Jul 2002 21:20:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T4KhoN009530 for ; Sun, 28 Jul 2002 21:20:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA18415 for ; Sun, 28 Jul 2002 21:20:48 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14352 for ; Sun, 28 Jul 2002 22:20:46 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1D43F4B22; Mon, 29 Jul 2002 13:20:43 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Mon, 29 Jul 2002 07:09:37 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: DAD vs. DIID From: itojun@iijlab.net Date: Mon, 29 Jul 2002 13:20:43 +0900 Message-Id: <20020729042043.1D43F4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Wouldn't it be much much simpler just to do DIID? I see zero reason for >e.g. PRFX1::1/64 and PRFX2::1/64 being assigned on two different nodes in >a same subnet. i see zero reason for prohibiting the above configuration. 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 Sun Jul 28 21:25:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T4PxoN009586; Sun, 28 Jul 2002 21:25:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6T4PxL3009585; Sun, 28 Jul 2002 21:25:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T4PuoN009578 for ; Sun, 28 Jul 2002 21:25:56 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA19094 for ; Sun, 28 Jul 2002 21:26:00 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA26513 for ; Sun, 28 Jul 2002 21:25:59 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6T4Pri00793; Mon, 29 Jul 2002 07:25:53 +0300 Date: Mon, 29 Jul 2002 07:25:53 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: <20020729042043.1D43F4B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 29 Jul 2002 itojun@iijlab.net wrote: > >Wouldn't it be much much simpler just to do DIID? I see zero reason for > >e.g. PRFX1::1/64 and PRFX2::1/64 being assigned on two different nodes in > >a same subnet. > > i see zero reason for prohibiting the above configuration. But you agree that the above configuration is very rare, really just a "corner case". Someone _might_ want it though. Perhaps this behaviour should be configurable then? If enabled (default), perform DIID only [and possibly skip for EUI64 addresses]. This is useful in scenarios where there is a large number of addresses assigned in the nodes. If disabled, perform DAD for every address without any optimizations. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 00:30:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T7UXoN009971; Mon, 29 Jul 2002 00:30:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6T7UXiK009970; Mon, 29 Jul 2002 00:30:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T7UToN009963 for ; Mon, 29 Jul 2002 00:30:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24490 for ; Mon, 29 Jul 2002 00:30:33 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04435 for ; Mon, 29 Jul 2002 01:30: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 g6T7TZv26806; Mon, 29 Jul 2002 14:29:36 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6T7KBc14836; Mon, 29 Jul 2002 14:20:12 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Thomas Narten cc: "Dave Thaler" , ipng@sunroof.eng.sun.com Subject: Re: Comments on draft-ietf-ipngwg-icmp-v3-02.txt In-Reply-To: <200207261833.g6QIXBl10383@rotala.raleigh.ibm.com> References: <200207261833.g6QIXBl10383@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jul 2002 14:20:11 +0700 Message-ID: <14834.1027927211@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 26 Jul 2002 14:33:11 -0400 From: Thomas Narten Message-ID: <200207261833.g6QIXBl10383@rotala.raleigh.ibm.com> | > I'd like to see an ICMPv6 error message value assigned for the case | > where a node would need to send a packet from a specific address, | > but cannot because that address is anycast (since the other end has | > no other good way of knowing this is the case). | | Under what conditions would such a message be sent? I'd suggest "any time a packet is received at an address which is correct for the node, but inappropriate to use for the particular packet received". That includes TCP SYN sent to an anycast address (and Randy, I don't believe that any redefinition of how anycast addresses are permitted to be used can ever make TCP to an anycast address reliable). But it might also be useful for other similar functions - perhaps use of an address of a scope that the destination node doesn't want to use (like you sent that SMTP request to my link local address, but I really don't want you to do that). The ICMP message should contain a better address to use, which the source could compare with its list of possible addresses for the destination, and use only if that was one of the addresses it was considering using in the first place (that avoids most spoofing attacks I think). | For many uses, | sending to an anycast address should not trigger an ICMP (the higher | layer in some cases *could* deal with an anycast address). Of course, this would be done only if the anycast addr couldn't be handled. | The above isn't immediately obvious to me. TCP *could* also use the | recieved SYN as an indication that it should send a SYN in the reverse | direction using a proper source address. I don't think that would be a very useful technique. All that's going to do is attempt to open a new connection to something that won't be in LISTEN state (it isn't a case of simultaneous open, as the addresses don't match). That will just elicit a RST. | That SYN might even include a | option connecting it to the anycast address to which the first SYN was | directed. (Clearly details would need to be fleshed out to make this | all work.) Something like that could be done, but this is going to take much work on TCP, which isn't even in the pipeline. Even then, it isn't clear that this would always be appropriate, so there still needs to be a way to indicate that the address used (while valid) isn't the correct one to use. (A new ICMP like this could also be used in place of some current uses of port unreachable). | My point here is it's not immediately obvious to me when an | implementation is supposed to send an ICMP message in response to a | packet sent to an anycast address. If an implementation can't work out when to send it, then it won't. I don't see this as a problem. It would be a bigger problem if it wasn't clear what should happen when such a message is received - that might make it useless. But if any nodes can find a way to decide when to send the message, that's enough from that end - and nodes that want to simply prohibit all TCP sent to anycast addresses would be in that set I'd expect. I support Itojun's request. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 00:30:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T7UmoN009981; Mon, 29 Jul 2002 00:30:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6T7UlZQ009980; Mon, 29 Jul 2002 00:30:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T7UioN009973 for ; Mon, 29 Jul 2002 00:30:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA12295 for ; Mon, 29 Jul 2002 00:30:47 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02113 for ; Mon, 29 Jul 2002 01:30:30 -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 g6T7Tfv26852; Mon, 29 Jul 2002 14:29:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6T76wc14810; Mon, 29 Jul 2002 14:07:02 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Pekka Savola cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jul 2002 14:06:58 +0700 Message-ID: <14808.1027926418@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 29 Jul 2002 07:25:53 +0300 (EEST) From: Pekka Savola Message-ID: | On Mon, 29 Jul 2002 itojun@iijlab.net wrote: | > >Wouldn't it be much much simpler just to do DIID? I see zero reason for | > >e.g. PRFX1::1/64 and PRFX2::1/64 being assigned on two different nodes in | > >a same subnet. | > | > i see zero reason for prohibiting the above configuration. Nor do I. | But you agree that the above configuration is very rare, really just a | "corner case". Someone _might_ want it though. I don't agree with the first sentence there, I think I'm (a) someone... | Perhaps this behaviour should be configurable then? That makes no sense. | If enabled (default), perform DIID only [and possibly skip for EUI64 | addresses]. This is useful in scenarios where there is a large number of | addresses assigned in the nodes. | | If disabled, perform DAD for every address without any optimizations. The problem is that you have to know what is enabled/disabled on every other node on the link as well. So, this would need to be yet another RA parameter (and there'd have to be some rule on what was permitted when there is no router in that case). It really is simpler just to always do DAD. On optimistic DAD - maybe I misunderstood what Erik was suggesting, but I assumed the "optimistic" wouldn't be "irrational" .. that is, for optimistic DAD, which I think I'd certainly not object to (though I'm also not sure the actual cost of full DAD is enough for it to matter) I'd assumed the idea would be to send the first DAD NS, and wait for a reply, and if no reply came to that one, assume the address is OK, while simultaneously going on and doing the rest of the DAD procedure (killing the address if it fails). That more or less cuts the DAD delay by 2/3 (but it doesn't eliminate it). This relies upon NS/NA failure being very rare (so it might be something that you'd do on fairly reliable links, and not on ones known to have greater packet losses). That is, if there is another (operational) user of the address, they're almost always going to reply to the first NS for their address (whether or not it is for DAD purposes). That is certainly in line with my experiences with ARP. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 00:37:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T7bgoN010042; Mon, 29 Jul 2002 00:37:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6T7bgut010041; Mon, 29 Jul 2002 00:37:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T7bcoN010034 for ; Mon, 29 Jul 2002 00:37:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05569 for ; Mon, 29 Jul 2002 00:37:41 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07059 for ; Mon, 29 Jul 2002 01:37:41 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id B5E2C4B22; Mon, 29 Jul 2002 16:37:36 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Mon, 29 Jul 2002 07:14:10 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-ietf-ipngwg-icmp-v3-02.txt From: itojun@iijlab.net Date: Mon, 29 Jul 2002 16:37:36 +0900 Message-Id: <20020729073736.B5E2C4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> read draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt for more on this >> topic. >Please elaborate. I don't think the draft discusses this at all. Randy is talking about changing definition of "anycast" in RFC2460 to definition in draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt section 2.2. is it clear enough? >With RFC2460 anycast, you can always assume there is another unicast >address of at least same scope assigned on the node. As the node cannot >use RFC2460 address as a source address, it will use unicast address. >Problem solved(?). i don't quite parse it. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 01:37:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T8b8oN010140; Mon, 29 Jul 2002 01:37:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6T8b8LB010139; Mon, 29 Jul 2002 01:37:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6T8b5oN010132 for ; Mon, 29 Jul 2002 01:37:05 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21128 for ; Mon, 29 Jul 2002 01:37:09 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27551 for ; Mon, 29 Jul 2002 01:37:08 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6T8alL14428; Mon, 29 Jul 2002 10:36:47 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA01425; Mon, 29 Jul 2002 10:36:47 +0200 (MET DST) 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 g6T8aj6o011210; Mon, 29 Jul 2002 10:36:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207290836.g6T8aj6o011210@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-reply-to: Your message of Mon, 29 Jul 2002 07:25:53 +0300. Date: Mon, 29 Jul 2002 10:36:45 +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: > i see zero reason for prohibiting the above configuration. => I should say I agree with Itojun... If disabled, perform DAD for every address without any optimizations. => IMHO the worse solution is to get a mix of DAD and DIIDD (as today). DAD had the majority at the meeting and is straightforward to implement so we should fix inconsistencies in current specs (including mobile IPv6 one). 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 Mon Jul 29 03:33:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TAXjoN010371; Mon, 29 Jul 2002 03:33:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TAXjGV010370; Mon, 29 Jul 2002 03:33:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TAXgoN010363 for ; Mon, 29 Jul 2002 03:33:42 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21981 for ; Mon, 29 Jul 2002 03:33:46 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06621; Mon, 29 Jul 2002 04:33:43 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id NAA23851; Mon, 29 Jul 2002 13:33:35 +0300 Date: Mon, 29 Jul 2002 13:33:35 +0300 Message-Id: <200207291033.NAA23851@burp.tkv.asdf.org> From: Markku Savela To: itojun@iijlab.net CC: Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com In-reply-to: <20020729022554.826414B22@coconut.itojun.org> Subject: Re: DAD vs. DIID References: <20020729022554.826414B22@coconut.itojun.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: itojun@iijlab.net > > for this reason, i'm not a fan of optimistic DAD. my preference > is to run full DAD (will take 1 second or so), for every address > assigned to the node. the rule is simple - run it for every address > you assign to the node, that's all. Then, I would like to have some consideration on how to behave in the following situation: - I've 3 prefixes and 3 ids, thus I have total of 9 addresses DADded. - I receive 4th prefix, => I do a DAD for 3 new addresses. Do I do them in parallel or do I have to do them one after another? - I configure a new additional ID => I do a DAD for 4 new addresses. Do I do them in parallel or do I have to do them one after another? Apparently, KAME is not able to configure multiple plain IDs to be combined freely with all announced prefixes? Or can it? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 03:39:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TAd1oN010401; Mon, 29 Jul 2002 03:39:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TAd1q5010400; Mon, 29 Jul 2002 03:39:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TAcvoN010393 for ; Mon, 29 Jul 2002 03:38:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08901 for ; Mon, 29 Jul 2002 03:39:01 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12214 for ; Mon, 29 Jul 2002 04:39:00 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0ABD44B23; Mon, 29 Jul 2002 19:38:54 +0900 (JST) To: Markku Savela Cc: Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com In-reply-to: msa's message of Mon, 29 Jul 2002 13:33:35 +0300. <200207291033.NAA23851@burp.tkv.asdf.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: DAD vs. DIID From: itojun@iijlab.net Date: Mon, 29 Jul 2002 19:38:53 +0900 Message-Id: <20020729103854.0ABD44B23@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Then, I would like to have some consideration on how to behave in the >following situation: > - I've 3 prefixes and 3 ids, thus I have total of 9 addresses DADded. > - I receive 4th prefix, => I do a DAD for 3 new addresses. Do I do > them in parallel or do I have to do them one after another? > - I configure a new additional ID => I do a DAD for 4 new addresses. Do I do > them in parallel or do I have to do them one after another? you can do them in parallel. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 03:53:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TArJoN010429; Mon, 29 Jul 2002 03:53:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TArJOT010428; Mon, 29 Jul 2002 03:53:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TArFoN010421 for ; Mon, 29 Jul 2002 03:53:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA24032 for ; Mon, 29 Jul 2002 03:53:19 -0700 (PDT) Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15430 for ; Mon, 29 Jul 2002 03:53:18 -0700 (PDT) Received: from nansb ([193.216.185.140]) by fep04-svc.swip.net with SMTP id <20020729105317.ZLIJ222.fep04-svc.swip.net@nansb>; Mon, 29 Jul 2002 12:53:17 +0200 Message-ID: <014001c236ee$24fecd30$8cb9d8c1@nansb> From: "Nils Agne Nordbotten" To: Cc: References: <20020729022554.826414B22@coconut.itojun.org> Subject: Re: DAD vs. DIID Date: Mon, 29 Jul 2002 12:53:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > for this reason, i'm not a fan of optimistic DAD. my preference > is to run full DAD (will take 1 second or so), for every address > assigned to the node. the rule is simple - run it for every address > you assign to the node, that's all. While this is simple in traditional LANs I'm worried about the consequences in networks like Bluetooth scatternets where devices in power saving modes will have to be waked up. I also imagine there easily will be partitions in such networks, and that DAD therefore will provide little assurance. Instead address uniqueness could be assured from EUIs. Regards Nils Nordbotten -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 05:09:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TC9ioN010575; Mon, 29 Jul 2002 05:09:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TC9iZu010574; Mon, 29 Jul 2002 05:09:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TC9doN010567 for ; Mon, 29 Jul 2002 05:09:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA27191 for ; Mon, 29 Jul 2002 05:09:44 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29244 for ; Mon, 29 Jul 2002 06:09:43 -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 IAA25456; Mon, 29 Jul 2002 08:08:35 -0400 (EDT) Message-Id: <200207291208.IAA25456@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-scope-api-00.txt Date: Mon, 29 Jul 2002 08:08:35 -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 : Scoped Address Extensions to the IPv6 Basic Socket API Author(s) : R. Gilligan et al. Filename : draft-ietf-ipv6-scope-api-00.txt Pages : 5 Date : 26-Jul-02 This document specifies a set of extensions to the basic IPv6 sockets API for the support of scoped addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-scope-api-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-scope-api-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-scope-api-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: <20020726114228.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-scope-api-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-scope-api-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020726114228.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 05:09:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TC9coN010565; Mon, 29 Jul 2002 05:09:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TC9cP5010564; Mon, 29 Jul 2002 05:09:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TC9YoN010557 for ; Mon, 29 Jul 2002 05:09:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20334 for ; Mon, 29 Jul 2002 05:09:39 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29206 for ; Mon, 29 Jul 2002 06:09:38 -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 IAA25439; Mon, 29 Jul 2002 08:08:30 -0400 (EDT) Message-Id: <200207291208.IAA25439@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-06.txt Date: Mon, 29 Jul 2002 08:08:30 -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 : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens Filename : draft-ietf-ipngwg-rfc2553bis-06.txt Pages : 31 Date : 26-Jul-02 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-rfc2553bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020726114214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2553bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020726114214.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 05:11:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TCBGoN010599; Mon, 29 Jul 2002 05:11:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TCBGmO010598; Mon, 29 Jul 2002 05:11:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TCBCoN010591 for ; Mon, 29 Jul 2002 05:11:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA27395 for ; Mon, 29 Jul 2002 05:11:16 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13885 for ; Mon, 29 Jul 2002 06:11:15 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6TCB1L29187; Mon, 29 Jul 2002 14:11:02 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA03235; Mon, 29 Jul 2002 14:11:02 +0200 (MET DST) 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 g6TCB06o011715; Mon, 29 Jul 2002 14:11:00 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207291211.g6TCB06o011715@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: itojun@iijlab.net, Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-reply-to: Your message of Mon, 29 Jul 2002 13:33:35 +0300. <200207291033.NAA23851@burp.tkv.asdf.org> Date: Mon, 29 Jul 2002 14:11: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: Then, I would like to have some consideration on how to behave in the following situation: - I've 3 prefixes and 3 ids, thus I have total of 9 addresses DADded. => it is uncommon to have 3 ids (usually there are only one or two)... - I receive 4th prefix, => I do a DAD for 3 new addresses. Do I do them in parallel or do I have to do them one after another? => in parallel of course. - I configure a new additional ID => I do a DAD for 4 new addresses. Do I do them in parallel or do I have to do them one after another? => idem. Apparently, KAME is not able to configure multiple plain IDs to be combined freely with all announced prefixes? Or can it? => I believe KAME has a notion of "the" id of the interface. This should be discussed on the KAME list. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 05:18:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TCIXoN010664; Mon, 29 Jul 2002 05:18:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TCIXBA010663; Mon, 29 Jul 2002 05:18:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TCIToN010656 for ; Mon, 29 Jul 2002 05:18:29 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21794 for ; Mon, 29 Jul 2002 05:18:34 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02774 for ; Mon, 29 Jul 2002 06:18:33 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6TCIHL29845; Mon, 29 Jul 2002 14:18:17 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA03315; Mon, 29 Jul 2002 14:18:18 +0200 (MET DST) 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 g6TCIH6o011761; Mon, 29 Jul 2002 14:18:17 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207291218.g6TCIH6o011761@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Nils Agne Nordbotten" cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-reply-to: Your message of Mon, 29 Jul 2002 12:53:16 +0200. <014001c236ee$24fecd30$8cb9d8c1@nansb> Date: Mon, 29 Jul 2002 14:18:17 +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: While this is simple in traditional LANs I'm worried about the consequences in networks like Bluetooth scatternets where devices in power saving modes will have to be waked up. I also imagine there easily will be partitions in such networks, and that DAD therefore will provide little assurance. Instead address uniqueness could be assured from EUIs. => I have no concern about the last statement. The problem with (too) optimistic DAD is to fail to detect a collision before the damage and when there are duplicated EUIs the damage is already very great. This is why I proposed to use IMEIs for mobile phones which have no IEEE devices so no EUIs but still have a globally unique hardware number. PPP is another case where DAD can be forgotten. 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 Mon Jul 29 07:16:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TEG5oN011043; Mon, 29 Jul 2002 07:16:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TEG5Ht011042; Mon, 29 Jul 2002 07:16:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TEG0oN011028 for ; Mon, 29 Jul 2002 07:16:00 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23751 for ; Mon, 29 Jul 2002 07:16:03 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28916 for ; Mon, 29 Jul 2002 08:16:02 -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 g6TEFHv10478; Mon, 29 Jul 2002 21:15:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6TEEoc23941; Mon, 29 Jul 2002 21:14:52 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Nils Agne Nordbotten" cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: <014001c236ee$24fecd30$8cb9d8c1@nansb> References: <014001c236ee$24fecd30$8cb9d8c1@nansb> <20020729022554.826414B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jul 2002 21:14:50 +0700 Message-ID: <23939.1027952090@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 29 Jul 2002 12:53:16 +0200 From: "Nils Agne Nordbotten" Message-ID: <014001c236ee$24fecd30$8cb9d8c1@nansb> | While this is simple in traditional LANs I'm worried about the consequences | in networks like Bluetooth scatternets where devices in power saving modes | will have to be waked up. If the hardware is rational (a topic about which I know nothing at all, it might not be, but perhaps if pressed, it will improve) the devices won't need to wake up. Remember ND (including DAD) is not ARP, packets aren't broadcast, they're multicast, and to a multicast address which will normally only have as members of the same multicast group nodes sharing the same IID. If you're one of the believers of "no IID sharing" then doing DAD instead of DIIDD won't change that, and usually, there will be no other members of the group than the node which is doing DAD. The DAD packets consume an (insignificant) amount of bandwidth, but when all is working properly, go nowhere at all. | I also imagine there easily will be partitions in | such networks, and that DAD therefore will provide little assurance. If partitions are common (aside: why would anyone use a link where the chances of not being able to talk to any other random node on the link, like the router, or fileserver, ... are not negligible??) then sure, DAD won't provide a lot or protection, but DIID would provide even less, as less probes are done. At least with DAD, you have a better chance of some of your addresses being detected as duplicates, which will start waving the red flags. | Instead address uniqueness could be assured from EUIs. If EUIs are being used to form the addresses, then duplicates should be very very rare, and all DAD really achieves in the usual case is a little bandwidth consumption and a small delay. But it does no harm either. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 07:24:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TEOHoN011104; Mon, 29 Jul 2002 07:24:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TEOHjp011103; Mon, 29 Jul 2002 07:24:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TEOEoN011096 for ; Mon, 29 Jul 2002 07:24:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10722 for ; Mon, 29 Jul 2002 07:24:18 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27443 for ; Mon, 29 Jul 2002 08:24:17 -0600 (MDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 174481D43 for ; Mon, 29 Jul 2002 09:24:17 -0500 (CDT) Received: from anw.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id A2C7C1927 for ; Mon, 29 Jul 2002 10:24:16 -0400 (EDT) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g6TEOGG0000789343; Mon, 29 Jul 2002 10:24:16 -0400 (EDT) Date: Mon, 29 Jul 2002 10:24:16 -0400 (EDT) From: Jack McCann Message-Id: <200207291424.g6TEOGG0000789343@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Re: WG Last Call for Basic Sockets API: draft-ietf-ipngwg-rfc2553bis-06.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here is summary of major changes from rfc2553bis-05 to rfc2553bis-06: . Add brief description of the evolution of this API and its relation to the Open Group/IEEE/ISO standards. . More alignments with [3]: - [3] does not contain protocol family definitions (PF_xxx). Replaced PF_INET6 with AF_INET6, or removed as appropriate. . Remove references to the DNS A6 resource record type. . Fix argument names in getnameinfo() prototype to match text. . Add description text for the getnameinfo() salen argument. . Remove scoped addressing support, which will be published in a separate document. . Modified change history to reflect changes from RFC 2553 only. In preparation for publication as new RFC, the change history was modified to show changes from RFC 2553, rather than changes from bis-01 to bis-02, bis-02 to bis-03, etc. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 08:52:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TFqmoN011536; Mon, 29 Jul 2002 08:52:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TFqmBi011535; Mon, 29 Jul 2002 08:52:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TFqjoN011528 for ; Mon, 29 Jul 2002 08:52:45 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14019 for ; Mon, 29 Jul 2002 08:52:49 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20410 for ; Mon, 29 Jul 2002 09:52:48 -0600 (MDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6TFqlRY132686 for ; Mon, 29 Jul 2002 11:52:48 -0400 Received: from d03nm118.boulder.ibm.com (d03nm118 [9.17.193.17]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6TFqhvA110240 for ; Mon, 29 Jul 2002 09:52:46 -0600 Subject: Scoped Address Extensions to the IPv6 Basic Socket API To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Mon, 29 Jul 2002 11:44:31 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build M13TT_07122002 Pre-release 2|July 12, 2002) at 07/29/2002 09:52:19 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE696DFC1A33B8f9e8a93df938690918c0ABBE696DFC1A33B" Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0__=0ABBE696DFC1A33B8f9e8a93df938690918c0ABBE696DFC1A33B Content-type: text/plain; charset=US-ASCII I was happy to see this draft, as I've been struggling to understand how applications will work in the presence of limited scope addresses. I've got a few questions and comments regarding the draft. Some of these may be more appropriate for the Scoped Address Architecture draft, especially in the areas surrounding DNS behavior (some of which has already been discussed on the mailing list). Note that most of my confusion surrounds hosts connecting to more than one site-local zone. If this support was omitted from this and the Scoped Address Architecture draft, then many of my questions below would disappear. - I don't see versions of inet_ntop() and inet_pton() which support the proposed address format for limited scope addresses. I would have thought both would be needed. Or are these APIs being deprecated in favor of using getaddrinfo() and getnameinfo() to perform this mapping (both for unicast and multicast addresses)? Either way, I think it would be good to address this within this draft. - I would like to see new APIs to map between a zone index and zone name provided, similar to the if_nametoindex() and if_indextoname() calls. At a minimum, these will be needed for the updated resolver APIs, which becomes important given many platforms port their resolver from the BIND distribution. - getaddrinfo() - What value should sin6_scope_id be set to for limited scope addresses, such as a site-local address? Should it be the scope index for the given zone into which the query is sent? If so, does a resolver need to send the same query into each zone to which it is attached? I find the whole interaction between the resolver, DNS name server, and limited scope addresses is extremely confusing. - If the host name includes a scope ID, should this restrict the zones into which the DNS query is sent? I would assume so, but have questions based on the next bullet. - If the host name includes a scope ID, but the scope ID is not valid at the invoking host, what should be done? Should the query fail? Or should the scope ID be included on the limited scope addresses returned? - If the host name includes a scope ID, but the scope ID is not valid for all the limited scope addresses which need to be returned, what should be done? For instance, if a local hosts file includes both link-local and site-local addresses, but the scope ID is only valid for the site-local addresses, what should occur? Should the call fail, or should only the site-local addresses be returned? - getnameinfo() - If NI_NUMERICSCOPE is not specified and the scope identifier cannot be mapped to a scope zone name, what should this API do? Should the call fail, or should it return the numeric form of the scope identifier? - What should be done if a nonzero scope identifier is included with a global IPv6 address? Should the call fail, or should it return the numeric form of the scope identifier? - If a nonzero scope zone index is included, should it be used to restrict the zone into which the DNS query is sent? For instance, if the address is of site-local scope, should the query only be sent into the zone which is identified by the scope ID? Or should the resolver send the query into (any? all?) zones? - For a limited scope address with a zero scope zone index, into which zones should the resolver send the query? Should it send it into the "default" zone, any zone, or send the query into zones? Since the host would send a packet using this address/zone index pair into the "default" zone, it might make sense for the resolver to do the same. - The discussions from the Scoped Address Architecture draft on when to include the scope ID in textual formats should probably be moved into this draft. For instance, the Scoped Address Architecture draft talks about omitting the zone ID for the default zone on textual displays. Roy --0__=0ABBE696DFC1A33B8f9e8a93df938690918c0ABBE696DFC1A33B Content-type: text/html; charset=US-ASCII Content-Disposition: inline

    I was happy to see this draft, as I've been struggling to understand
    how applications will work in the presence of limited scope addresses.
    I've got a few questions and comments regarding the draft.  Some of
    these may be more appropriate for the Scoped Address Architecture draft,
    especially in the areas surrounding DNS behavior (some of which has
    already been discussed on the mailing list).  

    Note that most of my confusion surrounds hosts connecting to more than
    one site-local zone. If this support was omitted from this and the Scoped
    Address Architecture draft, then many of my questions below would
    disappear.

    - I don't see versions of inet_ntop() and inet_pton() which support the
     proposed address format for limited scope addresses.  I would have
     thought both would be needed.  Or are these APIs being deprecated in
     favor of using getaddrinfo() and getnameinfo() to perform this
     mapping (both for unicast and multicast addresses)?  Either way, I
     think it would be good to address this within this draft.

    - I would like to see new APIs to map between a zone index and zone name
     provided, similar to the if_nametoindex() and if_indextoname() calls.  
     At a minimum, these will be needed for the updated resolver APIs,
     which becomes important given many platforms port their resolver from
     the BIND distribution.

    - getaddrinfo()
     - What value should sin6_scope_id be set to for limited scope
       addresses, such as a site-local address?  Should it be the scope
       index for the given zone into which the query is sent?  If so, does
       a resolver need to send the same query into each zone to which it is
       attached?  I find the whole interaction between the resolver, DNS
       name server, and limited scope addresses is extremely confusing.  

     - If the host name includes a scope ID, should this restrict the zones
       into which the DNS query is sent?  I would assume so, but have
       questions based on the next bullet.

     - If the host name includes a scope ID, but the scope ID is not valid
       at the invoking host, what should be done?  Should the query fail?  
       Or should the scope ID be included on the limited scope addresses
       returned?

     - If the host name includes a scope ID, but the scope ID is not valid
       for all the limited scope addresses which need to be returned, what
       should be done?  For instance, if a local hosts file includes both
       link-local and site-local addresses, but the scope ID is only valid
       for the site-local addresses, what should occur?  Should the call
       fail, or should only the site-local addresses be returned?

    - getnameinfo()
     - If NI_NUMERICSCOPE is not specified and the scope identifier cannot
       be mapped to a scope zone name, what should this API do?  Should the
       call fail, or should it return the numeric form of the scope
       identifier?

     - What should be done if a nonzero scope identifier is included with
       a global IPv6 address?  Should the call fail, or should it return
       the numeric form of the scope identifier?

     - If a nonzero scope zone index is included, should it be used to
       restrict the zone into which the DNS query is sent?  For instance,
       if the address is of site-local scope, should the query only be sent
       into the zone which is identified by the scope ID?  Or should the
       resolver send the query into (any?  all?) zones?

     - For a limited scope address with a zero scope zone index, into which
       zones should the resolver send the query?  Should it send it into
       the "default" zone, any zone, or send the query into zones?  Since
       the host would send a packet using this address/zone index pair
       into the "default" zone, it might make sense for the resolver to
       do the same.

     - The discussions from the Scoped Address Architecture draft on when
       to include the scope ID in textual formats should probably be moved
       into this draft.  For instance, the Scoped Address Architecture
       draft talks about omitting the zone ID for the default zone on
       textual displays.

    Roy     --0__=0ABBE696DFC1A33B8f9e8a93df938690918c0ABBE696DFC1A33B-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 10:31:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6THV8oN011917; Mon, 29 Jul 2002 10:31:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6THV84o011916; Mon, 29 Jul 2002 10:31:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6THV5oN011909 for ; Mon, 29 Jul 2002 10:31:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04189 for ; Mon, 29 Jul 2002 10:31:08 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15079 for ; Mon, 29 Jul 2002 11:31:07 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id UAA24249; Mon, 29 Jul 2002 20:31:03 +0300 Date: Mon, 29 Jul 2002 20:31:03 +0300 Message-Id: <200207291731.UAA24249@burp.tkv.asdf.org> From: Markku Savela To: pdeshpande@juniper.net CC: ipng@sunroof.eng.sun.com In-reply-to: <49FF5C6DDBD8D311BBBD009027DE980C02AC50E4@mailwest.unispherenetworks.com> (pdeshpande@juniper.net) Subject: Re: DAD vs. DIID - multiple IIDs? References: <49FF5C6DDBD8D311BBBD009027DE980C02AC50E4@mailwest.unispherenetworks.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Deshpande, Prasad" > I have some questions related to multiple IIDs on an interface > > - When and why would someone configure multiple IIDs on an interface? offhand, perpaps - for a server you might want manually configure nice "prefix::1" address in addition to the automaticly generated id (or even many id's you have webserver: id=1, mailserver: id=2, etc.). Now, depening on needs, you can designate any host as server by adding the servers "locally-well-known-id" to a host (and removing it from another). - privacy draft (3041?) didn't exactly call for generation of id only, but it could be done that way too (just generate random id's to be used). > - If multiple IIDs are configured on an interface, does that imply that > the interface has multiple link-local addresses, one created from each > IID. In my case, yes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 11:41:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TIfnoN012416; Mon, 29 Jul 2002 11:41:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TIfn5W012415; Mon, 29 Jul 2002 11:41:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TIfloN012408 for ; Mon, 29 Jul 2002 11:41:47 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6TIf5GZ021794 for ; Mon, 29 Jul 2002 11:41:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6TIf5DZ021793 for ipng@sunroof.eng.sun.com; Mon, 29 Jul 2002 11:41:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TH5loN011861 for ; Mon, 29 Jul 2002 10:05:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24859 for ; Mon, 29 Jul 2002 10:05:52 -0700 (PDT) Received: from mailwest.unispherenetworks.com (mailwest.unispherenetworks.com [65.194.140.130]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23305 for ; Mon, 29 Jul 2002 10:05:52 -0700 (PDT) Received: by mailwest.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 13:05:51 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02AC50E4@mailwest.unispherenetworks.com> From: "Deshpande, Prasad" To: ipng@sunroof.eng.sun.com Cc: "'Markku Savela'" Subject: RE: DAD vs. DIID - multiple IIDs? Date: Mon, 29 Jul 2002 13:05:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Markku Savela [mailto:msa@burp.tkv.asdf.org] > Sent: Monday, July 29, 2002 6:34 AM > To: itojun@iijlab.net > Cc: Erik.Nordmark@Sun.COM; ipng@sunroof.eng.sun.com > Subject: Re: DAD vs. DIID > > - I've 3 prefixes and 3 ids, thus I have total of 9 addresses DADded. > > - I receive 4th prefix, => I do a DAD for 3 new addresses. Do I do > them in parallel or do I have to do them one after another? > > - I configure a new additional ID => I do a DAD for 4 new > addresses. Do I do > them in parallel or do I have to do them one after another? > > Apparently, KAME is not able to configure multiple plain IDs to be > combined freely with all announced prefixes? Or can it? I have some questions related to multiple IIDs on an interface - When and why would someone configure multiple IIDs on an interface? - If multiple IIDs are configured on an interface, does that imply that the interface has multiple link-local addresses, one created from each IID. I didn't see any RPC/draft which prevents one from having multiple link-local addresses. On the other hand I couldn't find any statement that says that there must be a link local address for each IID. thanks -prasad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 11:42:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TIgBoN012429; Mon, 29 Jul 2002 11:42:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TIgBbV012428; Mon, 29 Jul 2002 11:42:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TIgAoN012421 for ; Mon, 29 Jul 2002 11:42:10 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6TIfRGZ021802 for ; Mon, 29 Jul 2002 11:41:27 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6TIfRqG021801 for ipng@sunroof.eng.sun.com; Mon, 29 Jul 2002 11:41:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TIbxoN012328 for ; Mon, 29 Jul 2002 11:37:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27342 for ; Mon, 29 Jul 2002 11:38:03 -0700 (PDT) Received: from mailwest.unispherenetworks.com (mailwest.unispherenetworks.com [65.194.140.130]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06625 for ; Mon, 29 Jul 2002 12:38:03 -0600 (MDT) Received: by mailwest.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 14:38:02 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02AC50E7@mailwest.unispherenetworks.com> From: "Deshpande, Prasad" To: "'Markku Savela'" Cc: ipng@sunroof.eng.sun.com Subject: RE: DAD vs. DIID - multiple IIDs? Date: Mon, 29 Jul 2002 14:38:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > From: "Deshpande, Prasad" > > > I have some questions related to multiple IIDs on an interface > > > > - When and why would someone configure multiple IIDs on an > interface? > > offhand, perpaps > > - for a server you might want manually configure nice "prefix::1" > address in addition to the automaticly generated id (or even many > id's you have webserver: id=1, mailserver: id=2, etc.). Now, > depening on needs, you can designate any host as server by adding > the servers "locally-well-known-id" to a host (and removing it from > another). > > - privacy draft (3041?) didn't exactly call for generation of id only, > but it could be done that way too (just generate random id's to be > used). > > > - If multiple IIDs are configured on an interface, does > that imply that > > the interface has multiple link-local addresses, one > created from each > > IID. > > In my case, yes. > Which IID do you use to send out router advertisements? If someone deletes that IID, other routers on the link wont receive router advertisements from it so they will assume that the router with old IID is gone. From my understanding of RFC 3041, it calls out for having global addresses based on "random IIDs". I assume these "random IIDs" are never used to construct link local addresses. Let me know if this is not the case. In your first example, webserver and mailserver could have addresses prefix::1 and prefix::2 but their interface IDs can be A1 (!= 1) and B1 (!= 2). What I am trying to say is that you could have just one IID (and so one link-local address) but multiple interface addresses some of which may be constructed using the IID. Then you can do a DAD on all addresses - including the link-local address. thanks -prasad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 14:01:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TL1foN013258; Mon, 29 Jul 2002 14:01:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6TL1fIU013257; Mon, 29 Jul 2002 14:01:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6TL1coN013250 for ; Mon, 29 Jul 2002 14:01:38 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24273 for ; Mon, 29 Jul 2002 14:01:41 -0700 (PDT) Received: from smtp3.southeast.rr.com (smtp3.southeast.rr.com [24.93.67.84]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07496 for ; Mon, 29 Jul 2002 14:01:41 -0700 (PDT) Received: from mail7.nc.rr.com (fe7 [24.93.67.54]) by smtp3.southeast.rr.com (8.12.5/8.12.2) with ESMTP id g6TL1Vga014494; Mon, 29 Jul 2002 17:01:31 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 29 Jul 2002 17:01:36 -0400 Message-ID: <3D45AC89.A24F84E9@nc.rr.com> Date: Mon, 29 Jul 2002 16:58:49 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: MAGMA Mailing List CC: IPng Mailing List Subject: MAGMA WG Last Call for MLDv2: draft-vida-mld-v2-03.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, This is the start of a MAGMA working group last call on the Multicast Listener Discovery - Version 2 specification. http://www.ietf.org/internet-drafts/draft-vida-mld-v2-03.txt The last call period will end on August 13th. Substantive comments should be directed to MAGMA mailing list. Editorial comments should be directed to the authors. Regards, Brian & Bill MAGMA co-chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 21:28:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U4SToN013966; Mon, 29 Jul 2002 21:28:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6U4STwS013965; Mon, 29 Jul 2002 21:28:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U4SQoN013958 for ; Mon, 29 Jul 2002 21:28:26 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA18392 for ; Mon, 29 Jul 2002 21:28:30 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27406 for ; Mon, 29 Jul 2002 22:28:29 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6U4SLV11460; Tue, 30 Jul 2002 07:28:22 +0300 Date: Tue, 30 Jul 2002 07:28:21 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on draft-ietf-ipngwg-icmp-v3-02.txt In-Reply-To: <20020729073736.B5E2C4B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 29 Jul 2002 itojun@iijlab.net wrote: > >> read draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt for more on this > >> topic. > >Please elaborate. I don't think the draft discusses this at all. > > Randy is talking about changing definition of "anycast" in RFC2460 > to definition in draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt section > 2.2. is it clear enough? No, he isn't. There seem to be some unstated assumptions here. What he is saying is 'if you try to connect anycast address PRFX::/64, the ICMP unreachable (or whatever) message comes back from PRFX::X/64 (unicast address on the node)'. This applies to RFC2460 anycast only, and depending on source address selection, possibly pseudo-anycast. > >With RFC2460 anycast, you can always assume there is another unicast > >address of at least same scope assigned on the node. As the node cannot > >use RFC2460 address as a source address, it will use unicast address. > >Problem solved(?). > > i don't quite parse it. See above. There should be no nodes which have only RFC2460 anycast address(es), as they must not use it as a source address. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 21:33:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U4XJoN013989; Mon, 29 Jul 2002 21:33:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6U4XIkx013988; Mon, 29 Jul 2002 21:33:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U4XFoN013981 for ; Mon, 29 Jul 2002 21:33:16 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA19552 for ; Mon, 29 Jul 2002 21:33:20 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA15193 for ; Mon, 29 Jul 2002 22:33:19 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6U4X7n11508; Tue, 30 Jul 2002 07:33:07 +0300 Date: Tue, 30 Jul 2002 07:33:07 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: itojun@iijlab.net, Subject: Re: DAD vs. DIID In-Reply-To: <14808.1027926418@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 29 Jul 2002, Robert Elz wrote: > | But you agree that the above configuration is very rare, really just a > | "corner case". Someone _might_ want it though. > > I don't agree with the first sentence there, I think I'm (a) someone... I'd like to hear what kind of network configuration you have in mind. > The problem is that you have to know what is enabled/disabled on every other > node on the link as well. So, this would need to be yet another RA > parameter (and there'd have to be some rule on what was permitted when > there is no router in that case). > > It really is simpler just to always do DAD. I agree this is a problem :-(. > On optimistic DAD - maybe I misunderstood what Erik was suggesting, but > I assumed the "optimistic" wouldn't be "irrational" .. that is, for > optimistic DAD, which I think I'd certainly not object to (though I'm also > not sure the actual cost of full DAD is enough for it to matter) I'd > assumed the idea would be to send the first DAD NS, and wait for a reply, > and if no reply came to that one, assume the address is OK, while > simultaneously going on and doing the rest of the DAD procedure (killing > the address if it fails). That more or less cuts the DAD delay by 2/3 (but > it doesn't eliminate it). My main point is just that one should be able "optimize" DAD somehow if there are long latencies involved (e.g. serialized full DAD is unacceptable with many addresses). How, that's another issue. Else folks that need to optimize it will do so anyway. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 29 22:29:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U5TRoN014164; Mon, 29 Jul 2002 22:29:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6U5TR9A014163; Mon, 29 Jul 2002 22:29:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U5TNoN014155 for ; Mon, 29 Jul 2002 22:29:23 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA24667 for ; Mon, 29 Jul 2002 22:29:28 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA29918 for ; Mon, 29 Jul 2002 23:29:27 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:112a:b059:3834:8f80]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6U5TPA25071 for ; Tue, 30 Jul 2002 14:29:25 +0900 (JST) Date: Tue, 30 Jul 2002 14:29:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: per-connection config and destination address selection User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk draft-ietf-ipv6-default-addr-select-08.txt mentions two per-connection configuration switches for source address selection. One is for home vs care-of addresses, and the other is for temporary vs public addresses. The value of the switches may affect destination address selection, because it depends on the expected source address corresponding to each candidate of destination address. I have a feeling that the current draft is not very clear about the dependency. For example, Section 8 (Implementation Considerations) indicates that the destination address selection algorithm can be implemented inside getaddrinfo(). However, the library function does not always know the value of per-connection switches in advance. An application may even not open a socket for the actual connection when calling getaddrinfo(). This may rather be an implementation issue, so I don't think we need a major revise of the draft just due to this. But I also think it would be good to add some note about the dependency in Section 8 before publishing the draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 30 00:01:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U71loN014264; Tue, 30 Jul 2002 00:01:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6U71l3N014263; Tue, 30 Jul 2002 00:01:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U71ioN014256 for ; Tue, 30 Jul 2002 00:01:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20710 for ; Tue, 30 Jul 2002 00:01:47 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25277 for ; Tue, 30 Jul 2002 01:01:17 -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 g6U6wiv27585; Tue, 30 Jul 2002 13:58:45 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6U6wBc26436; Tue, 30 Jul 2002 13:58:16 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Deshpande, Prasad" cc: ipng@sunroof.eng.sun.com, "'Markku Savela'" Subject: Re: DAD vs. DIID - multiple IIDs? In-Reply-To: <49FF5C6DDBD8D311BBBD009027DE980C02AC50E4@mailwest.unispherenetworks.com> References: <49FF5C6DDBD8D311BBBD009027DE980C02AC50E4@mailwest.unispherenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jul 2002 13:58:11 +0700 Message-ID: <26434.1028012291@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 29 Jul 2002 13:05:49 -0400 From: "Deshpande, Prasad" Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02AC50E4@mailwest.unispherenetworks.com> | - When and why would someone configure multiple IIDs on an interface? One obvious place would be for various kinds of "hot standby" protocols, when one node needs to take over the functionality of another when the other dies. There the node will have its own addresses (and IIDs) but will also want those of the node it is pretending to be. | - If multiple IIDs are configured on an interface, does that imply that | the interface has multiple link-local addresses, one created from each | IID. I didn't see any RPC/draft which prevents one from having multiple | link-local addresses. On the other hand I couldn't find any statement | that says that there must be a link local address for each IID. That's because there is no rule either way. There's nothing preventing a node (at least attempting to) configure a LL addr with the same IID as that used for every global addr it configures. But nor is there any requirement that it do that. Nodes are required to have a LL addr on every link. Beyond that, almost anything is possible (requiring a LL addr with an IID before allowing a global addr using the same IID will defeat some entirely reasonable configurations, but that just makes that particular implementation less functional than others, not incorrect). 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 Jul 30 00:20:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U7KKoN014296; Tue, 30 Jul 2002 00:20:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6U7KJbH014295; Tue, 30 Jul 2002 00:20:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U7KGoN014288 for ; Tue, 30 Jul 2002 00:20:16 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA00514 for ; Tue, 30 Jul 2002 00:20:19 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20377 for ; Tue, 30 Jul 2002 00:20:15 -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 g6U77gv04825; Tue, 30 Jul 2002 14:07:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g6U77Cc26458; Tue, 30 Jul 2002 14:07:15 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Pekka Savola cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jul 2002 14:07:12 +0700 Message-ID: <26456.1028012832@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 30 Jul 2002 07:33:07 +0300 (EEST) From: Pekka Savola Message-ID: | > I don't agree with the first sentence there, I think I'm (a) someone... | I'd like to hear what kind of network configuration you have in mind. One obvious one is when I have two links, and have assigned pfx1::1 to my favourite node on one of them, and pfx2::1 to my favourite (different) node on the other, and then I decide to merge the links into one. Applying both prefixes to the link is easy, so I shouldn't have to renumber anything just because of this (pyhsical) change (maybe a temporary one caused by the death of a switch, while waiting upon a replacement - assuming I'm too cheap to buy switches that support vlans...). But now I have two ::1's on the one link. | My main point is just that one should be able "optimize" DAD somehow if | there are long latencies involved (e.g. serialized full DAD is | unacceptable with many addresses). How, that's another issue. Else folks | that need to optimize it will do so anyway. N different DAD's (that is for different addresses) on one link should complete in the time it takes to do one DAD (that is, for one of those addresses), plus noise (the time it takes to transmit the other N-1 packets). Doing DAD for all of the addresses consumes some bandwidth, it has no other noticeable effect (or should have) on the node that is performing the DAD. Certainly there will be two DAD delays when a node boots - the first to get its LL addr, and then one more, for all of the other addresses it creates after it has received the RA (in all of that, I'd actually expect the random wait before sending the RS, if no RA just "happens", to be the biggest source of delay to a booting node). But the number of addresses it has on the link (LL, SL, or global) should not materially affect anything. An implementation that has N addresses ready to verify, so does DAD on the first, then after that is complete, DAD on the second, etc, would be just too cheap to consider for anything real (on the other hand, for some applications where human patience isn't an issue, that might be OK). 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 Jul 30 01:40:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U8eloN014621; Tue, 30 Jul 2002 01:40:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6U8elgR014620; Tue, 30 Jul 2002 01:40:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U8eioN014613 for ; Tue, 30 Jul 2002 01:40:44 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24822 for ; Tue, 30 Jul 2002 01:40:48 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19150 for ; Tue, 30 Jul 2002 01:40:47 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA25138; Tue, 30 Jul 2002 11:39:40 +0300 Date: Tue, 30 Jul 2002 11:39:40 +0300 Message-Id: <200207300839.LAA25138@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: pekkas@netcore.fi, itojun@iijlab.net, ipng@sunroof.eng.sun.com In-reply-to: <26456.1028012832@munnari.OZ.AU> (message from Robert Elz on Tue, 30 Jul 2002 14:07:12 +0700) Subject: Re: DAD vs. DIID References: <26456.1028012832@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f > From: Robert Elz > One obvious one is when I have two links, and have assigned pfx1::1 to > my favourite node on one of them, and pfx2::1 to my favourite (different) > node on the other, and then I decide to merge the links into one. Applying > both prefixes to the link is easy, so I shouldn't have to renumber anything > just because of this (pyhsical) change (maybe a temporary one caused by > the death of a switch, while waiting upon a replacement - assuming I'm > too cheap to buy switches that support vlans...). But now I have two ::1's > on the one link. But, even with DAD, you will have problems. You are announcing pfx1 and pfx2 on the same link. Thus, because both nodes have id=1 - both nodes will try to configure now pfx1::1 *AND* pfx2::1 and collide each other. - both nodes can now validly try to configure fe80::1, and collide on that - if a new pfx3 is announced, both nodes will collide on "pfx3::1" I'm not saying above is bad situation. It does require implementation to keep track of each combination, to remember wich prefix/id combinations have collided (or it has to keep a separate list of collided addresses, so that it doesn't try to reuse those combinations later). With DIID, you can remove the collided ID, and it will not be used. Of course, implementations can be more complicated: at least I have possibility to use "atomic" address, which will allow me to use "pfx1::1", even if id=1 is removed. You configure prefix, id or atomic address. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 30 02:04:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U947oN014643; Tue, 30 Jul 2002 02:04:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6U947WE014642; Tue, 30 Jul 2002 02:04:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U944oN014635 for ; Tue, 30 Jul 2002 02:04:04 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16265 for ; Tue, 30 Jul 2002 02:04:08 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28007 for ; Tue, 30 Jul 2002 02:04:07 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g6U8vNL28628; Tue, 30 Jul 2002 10:57:23 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA11460; Tue, 30 Jul 2002 10:57:23 +0200 (MET DST) 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 g6U8vL6o015324; Tue, 30 Jul 2002 10:57:22 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207300857.g6U8vL6o015324@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: kre@munnari.OZ.AU, pekkas@netcore.fi, itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-reply-to: Your message of Tue, 30 Jul 2002 11:39:40 +0300. <200207300839.LAA25138@burp.tkv.asdf.org> Date: Tue, 30 Jul 2002 10:57:21 +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: > One obvious one is when I have two links, and have assigned pfx1::1 to > my favourite node on one of them, and pfx2::1 to my favourite (different) > node on the other, and then I decide to merge the links into one. Applying > both prefixes to the link is easy, so I shouldn't have to renumber anything > just because of this (pyhsical) change (maybe a temporary one caused by > the death of a switch, while waiting upon a replacement - assuming I'm > too cheap to buy switches that support vlans...). But now I have two ::1's > on the one link. But, even with DAD, you will have problems. => I have no problem... You are announcing pfx1 and pfx2 on the same link. Thus, because both nodes have id=1 => no, they have ids=something and addresses=pfx1::1 and pfx2::1 - both nodes will try to configure now pfx1::1 *AND* pfx2::1 and collide each other. => not if they don't try to configure all ids with all prefixes. - both nodes can now validly try to configure fe80::1, and collide on that => idem. - if a new pfx3 is announced, both nodes will collide on "pfx3::1" => idem. I'm not saying above is bad situation. It does require implementation to keep track of each combination, to remember wich prefix/id combinations have collided (or it has to keep a separate list of collided addresses, so that it doesn't try to reuse those combinations later). => obviously your assumptions about how the autoconf works are not shared. With DIID, you can remove the collided ID, and it will not be used. => with DAD, there is no notion of collided ID, only of collided addresses. IMHO the confusion comes from the current mixture of DAD and DIIDD. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 30 02:54:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U9sooN014746; Tue, 30 Jul 2002 02:54:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6U9sofD014745; Tue, 30 Jul 2002 02:54:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U9sloN014738 for ; Tue, 30 Jul 2002 02:54:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06667 for ; Tue, 30 Jul 2002 02:54:52 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10682 for ; Tue, 30 Jul 2002 02:54:51 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id MAA25263; Tue, 30 Jul 2002 12:54:47 +0300 Date: Tue, 30 Jul 2002 12:54:47 +0300 Message-Id: <200207300954.MAA25263@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: ipng@sunroof.eng.sun.com In-reply-to: <200207300857.g6U8vL6o015324@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Tue, 30 Jul 2002 10:57:21 +0200) Subject: Re: DAD vs. DIID References: <200207300857.g6U8vL6o015324@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Francis Dupont > > I'm not saying above is bad situation. It does require implementation > to keep track of each combination, to remember wich prefix/id > combinations have collided (or it has to keep a separate list of > collided addresses, so that it doesn't try to reuse those combinations > later). > > => obviously your assumptions about how the autoconf works are not shared. IPv6 addressing architecture defines the process of combining prefixes and ids. Nothing in the RFC's prevents taking the interpretation I presented. It's correct, and perhaps a useful feature. > => with DAD, there is no notion of collided ID, only of collided > addresses. IMHO the confusion comes from the current mixture of DAD > and DIIDD. Well, right. Did I say anything else? This is discussion about two choices (1) do DAD, (2) require the ID part be unique (only one node can use) on the link. The current autoconf is basicly DAD. I just dared to propose that perhaps unique ID approach might be better solution. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 30 06:52:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UDq8oN015002; Tue, 30 Jul 2002 06:52:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6UDq8V7015001; Tue, 30 Jul 2002 06:52:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UDq5oN014994 for ; Tue, 30 Jul 2002 06:52:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16882 for ; Tue, 30 Jul 2002 06:52:07 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29360 for ; Tue, 30 Jul 2002 07:52:06 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g6UDpqt15651; Tue, 30 Jul 2002 16:51:52 +0300 Date: Tue, 30 Jul 2002 16:51:51 +0300 (EEST) From: Pekka Savola To: Randy Bush cc: itojun@iijlab.net, Subject: Re: Comments on draft-ietf-ipngwg-icmp-v3-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 29 Jul 2002, Randy Bush wrote: > >>>> read draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt for more on this > >>>> topic. > >>> Please elaborate. I don't think the draft discusses this at all. > >> Randy is talking about changing definition of "anycast" in RFC2460 > >> to definition in draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt section > >> 2.2. is it clear enough? > > No, he isn't. > > i think he is. but i could be wrong. after all, he has said it about > 42 times not. > > > What he is saying is 'if you try to connect anycast address PRFX::/64, the > > ICMP unreachable (or whatever) message comes back from PRFX::X/64 (unicast > > address on the node)'. > > i don't think he was saying that. but again, i could be wrong. Ok, I misunderstood your statement. Above was my similar but different opinion why ICMP packets triggered by traffic to an anycast address should not be a problem. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 30 10:05:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UH56oN015353; Tue, 30 Jul 2002 10:05:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6UH56HP015352; Tue, 30 Jul 2002 10:05:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UH52oN015345 for ; Tue, 30 Jul 2002 10:05:02 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24487 for ; Tue, 30 Jul 2002 10:05:07 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27322 for ; Tue, 30 Jul 2002 11:05:06 -0600 (MDT) Received: from localhost ([3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g6UH51A28549 for ; Wed, 31 Jul 2002 02:05:01 +0900 (JST) Date: Wed, 31 Jul 2002 02:05:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: DAD vs. DIID In-Reply-To: <200207291211.g6TCB06o011715@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200207291211.g6TCB06o011715@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 29 Jul 2002 14:11:00 +0200, >>>>> Francis Dupont said: > Apparently, KAME is not able to configure multiple plain IDs to be > combined freely with all announced prefixes? Or can it? > => I believe KAME has a notion of "the" id of the interface. No, KAME's implementation does not have such a notion, at least not explicitly. So, basically Markku is correct. > This should be discussed on the KAME list. I agree, if we need more discussion on this particular topic, perhaps we'll have to change the place. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 30 10:22:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UHMBoN015543; Tue, 30 Jul 2002 10:22:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6UHMBbN015542; Tue, 30 Jul 2002 10:22:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UHM9oN015535 for ; Tue, 30 Jul 2002 10:22:09 -0700 (PDT) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g6UHLPGZ022384 for ; Tue, 30 Jul 2002 10:21:25 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g6UHLOnE022383 for ipng@sunroof.eng.sun.com; Tue, 30 Jul 2002 10:21:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6U5YFoN014174 for ; Mon, 29 Jul 2002 22:34:15 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA25721 for ; Mon, 29 Jul 2002 22:34:20 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01352 for ; Mon, 29 Jul 2002 23:34:19 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17ZPeE-0004qE-00; Mon, 29 Jul 2002 22:34:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Pekka Savola Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Comments on draft-ietf-ipngwg-icmp-v3-02.txt References: <20020729073736.B5E2C4B22@coconut.itojun.org> Message-Id: Date: Mon, 29 Jul 2002 22:34:18 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>> read draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt for more on this >>>> topic. >>> Please elaborate. I don't think the draft discusses this at all. >> Randy is talking about changing definition of "anycast" in RFC2460 >> to definition in draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt section >> 2.2. is it clear enough? > No, he isn't. i think he is. but i could be wrong. after all, he has said it about 42 times not. > What he is saying is 'if you try to connect anycast address PRFX::/64, the > ICMP unreachable (or whatever) message comes back from PRFX::X/64 (unicast > address on the node)'. i don't think he was saying that. but again, i could be wrong. > See above. There should be no nodes which have only RFC2460 anycast > address(es), as they must not use it as a source address. brokenness randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 30 11:31:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UIVAoN015679; Tue, 30 Jul 2002 11:31:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6UIVAmc015678; Tue, 30 Jul 2002 11:31:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UIV6oN015671; Tue, 30 Jul 2002 11:31:06 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14000; Tue, 30 Jul 2002 11:31:10 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08308; Tue, 30 Jul 2002 12:31:09 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 41C71695C; Tue, 30 Jul 2002 14:31:07 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 30 Jul 2002 14:31:06 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Tue, 30 Jul 2002 14:31:06 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8DBD@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt7cTWMfDr88ZlQ3iaoLJAwT95/QAAdA9AAoHdRGA= From: "Bound, Jim" To: , , Cc: , , , X-OriginalArrivalTime: 30 Jul 2002 18:31:06.0982 (UTC) FILETIME=[44C22860:01C237F7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6UIV7oO015672 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, I would prefer all requirements for me to implement are in the specs as a programmer. I view node reqs doc as a statement of further reqs of the std regarding conformance not implementation. If we don't want HAO to be MUST make it a SHOULD this should be decided in the MIPv6 spec.k thanks /jim > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, July 17, 2002 8:14 PM > To: mat@cisco.com; vijayd@iprg.nokia.com > Cc: itojun@iijlab.net; keiichi@iij.ad.jp; > mobile-ip@sunroof.eng.sun.com; > ipng@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated > > > Hi Mike, > > > Vijay Devarapalli writes: > > > RO is a SHOULD, it is not a MUST in the current draft. we were > > > not talking about route optimization. we were talking about > > > processing a HAO. in the current spec HAO MUST be processed but > > > not accepted if it cant be verified. verification can be in the > > > form of checking for a valid BCE (created securely), IPsec > > > protected data session, same trusted domain (where you dont > > > expect people to do reflection attacks), the tagging proposal > > > from Rajeev and Charlie, smart ingress filtering from Francis > > > Dupont, etc... > > > > Oh, OK. Sorry about that. Still if the code > > isn't in the CN, the MN should still be able > > to operate correctly, right? That still seems > > to me to be a SHOULD rather than a MUST for the > > same reasons in my reply to John. > > > > I guess the long and short of this is that I'm > > somewhat skeptical of putting general node > > requirements in the MIP draft since it's > > probably not the first place one would be > > looking to figure out if they were an IPv6 > > compliant node. If it's really, really vital > > for the health of the net, yadda, yadda, it > > would be better to put it in a general v6 node > > requirements RFC, don't you think? > > Just as an FYI, I replied to the earlier mail because I am > trying to sort this out for the node requirements. I think > that in MIPv6, it is OK that MIPv6 makes this recommendation (given > working group consensus, IESG approval, etc.) but the Node > Requirements > document is the final word on the issue (assuming WG consensus, > IESG approval, etc.). > > John > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 30 11:35:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UIZKoN015707; Tue, 30 Jul 2002 11:35:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6UIZKBD015706; Tue, 30 Jul 2002 11:35:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UIZHoN015699; Tue, 30 Jul 2002 11:35:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05543; Tue, 30 Jul 2002 11:35:20 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21255; Tue, 30 Jul 2002 12:35:20 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B06B26A02; Tue, 30 Jul 2002 14:35:19 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 30 Jul 2002 14:35:19 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Tue, 30 Jul 2002 14:35:18 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8DBE@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt8ZI6pG4dYJ6ERBKA9LCbowSLNwAAQizQAoE4d6A= From: "Bound, Jim" To: , , , Cc: , , , X-OriginalArrivalTime: 30 Jul 2002 18:35:19.0402 (UTC) FILETIME=[DB3664A0:01C237F7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6UIZHoO015700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk HAO SHOULD be implemented. MUST is a stretch and I always thought so since draft 1. The security argument is irrelevant to being a MUST or SHOULD if I deployed MIPv6 I would not use RR or any IPsec there are many ways to secure the mobile nodes and CNs and I agree with Vijays point on this just not the MUST. That being said anyone who would not want to implement mobile HAO is not in tune with the market at all. But thats not the IETFs job to keep them in tune. /jim > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, July 17, 2002 8:41 PM > To: hesham.soliman@era.ericsson.se; mat@cisco.com; itojun@iijlab.net > Cc: vijayd@iprg.nokia.com; keiichi@iij.ad.jp; > mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated > > > Hi Hesham, > > > > > => Exactly, IMHO the support for HAO is tied to > > > > RO support which is a SHOULD anyway, so the HAO > > > > should follow that. > > > > > > Logically, you are inconsistant. > > > > > > As an example, RO is a should, protecting RO is a MUST. > > > > => Huh? > > > > Protecting it is a must for those who support it! > > But supporting it is a should. > > We're dangerously on the edge of a rathole. > > Debates on support / implement / use of various functions is something > to often causes pointless discussions. > > The question more is, what do general implementations need to > implement. > In my opinion, general often equals robust. SHOULD does not mean > optional, it means you do it unless you have good reason not to do it. > I think the burden of proof, then, would be the endpoint > which does not > implement a certain feature. > > I think that since HAO is used for security reasons, it may > have a strong > need to be a must than other functionality. Just my opinion. > > John > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 30 12:33:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UJXhoN015791; Tue, 30 Jul 2002 12:33:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6UJXhtl015790; Tue, 30 Jul 2002 12:33:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UJXdoN015783 for ; Tue, 30 Jul 2002 12:33:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29287 for ; Tue, 30 Jul 2002 12:33:44 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29726 for ; Tue, 30 Jul 2002 12:33:43 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Jul 2002 12:33:42 -0700 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 30 Jul 2002 12:33:42 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 30 Jul 2002 12:33:42 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Jul 2002 12:33:42 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Tue, 30 Jul 2002 12:32:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on draft-ietf-ipngwg-icmp-v3-02.txt Date: Tue, 30 Jul 2002 12:33:40 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF497@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-ipngwg-icmp-v3-02.txt thread-index: AcIzpK1MFf85IXbdTkuAodHO/I5IYAEWzo3w From: "Dave Thaler" To: "Rami Lehtonen" , X-OriginalArrivalTime: 30 Jul 2002 19:32:22.0555 (UTC) FILETIME=[D39216B0:01C237FF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6UJXeoN015784 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Rami Lehtonen [mailto:rampe@cs.tut.fi] [...] > There was also some discussion at MAGMA working group that if the edge > router starts to filter MLD Reports coming from a host (host > authorization), > it would be nice to notify the host that such filtering is applied, e.g. > with ICMPv6 Administratively Prohibited. MLD Reports are however sent to > multicast address and thus the router can't use ICMPv6 (spec says that > error > message MUST NOT be sent as a result of receiving a packet destined to an > IPv6 multicast address). So, what about one more exception to the ICMPv6 > spec in addition to the Packet Too Big and Parameter Problem messages? I don't see the problem here. The admin prohibited message would be sent to the source of the MLD report, not the destination, and the source is a unicast address. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 30 12:59:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UJxnoN015907; Tue, 30 Jul 2002 12:59:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6UJxmhb015906; Tue, 30 Jul 2002 12:59:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UJxjoN015899 for ; Tue, 30 Jul 2002 12:59:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15685 for ; Tue, 30 Jul 2002 12:59:50 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14121 for ; Tue, 30 Jul 2002 12:59:50 -0700 (PDT) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Jul 2002 12:59:49 -0700 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 30 Jul 2002 12:59:42 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 30 Jul 2002 12:49:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: AD comments on draft-ietf-ipv6-router-selection-02.txt Date: Tue, 30 Jul 2002 12:49:17 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA807D1F912@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD comments on draft-ietf-ipv6-router-selection-02.txt Thread-Index: AcIz2RpCVeC6IfCKQKCrNYFjjajUTwEE7fGw From: "Richard Draves" To: "Thomas Narten" Cc: , "Bob Hinden" X-OriginalArrivalTime: 30 Jul 2002 19:49:17.0542 (UTC) FILETIME=[308CD060:01C23802] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6UJxjoN015900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The WG has requested that this document be advanced as a PS. I have > completed my pre-IESG/pre-Last Call review (the one that shepherding > AD makes prior to authorizing the IETF Last > Call) and have some questions/comments. Main comments come > first, more detailed comments/nits come at the end. > > Note that these comments come from me, not the IESG as a whole. The > IESG as a whole won't review the document until the IETF Last Call has > completed, I verify that any Last Call comments have been dealt with, > and then formally request that the IESG consider the document for > advancement. Thanks Thomas for the detailed review!!! > General comments: > > 1) I assume router-select is an optional document, and there is no > intent to require all IPv6 nodes to implement it. > > However, it appears to contain a change to the ND specification, one > intended that all ND implementations make. > > The Abstract says: > > The second > change is a mandatory modification of the conceptual sending > algorithm to support load-sharing among equivalent routers. > > The intro says: > > This document also describes a mandatory change in host behavior. > Neighbor DiscoveryÆs conceptual sending algorithm is modified to > require hosts to select randomly among equivalent routers. This > distributes traffic to different destinations among the routers. > Traffic to a single destination continues to use a single router, > because of the Destination Cache. > > I assume that the above text resulted from a merging of > draft-ietf-ipv6-host-load-sharing-00.txt with router-selection. > > If I understand the intent, I believe it is a mistake to merge the two > documents. It would be better to keep all mandatory changes to the ND > spec in a way that they are clearly identifiable. Burying mandatory > changes to the ND document within a related (but > optional-to-implement) document will make it hard for folks > to find those changes. > > Resurrecting host-load-sharing seems a fine way to go. At some point, > it would probably make sense to incorporate the text directly in the > ND spec anyway. (Or maybe we should just delay making the update until > ND needs to be respun -- this depends on what other issues people have > with the ND spec.) Yes, originally this document was entirely optional but when I merged in load-sharing it picked up a mandatory requirement. The main rationale for merging is that both affect the same code (next-hop determination). On the other hand, it is confusing to have mandatory & optional mixed. Bob, what do you think? > 2) There is an assumption here that the adminstrators involved will > coordinate with one another to configure sensible router preference > values. However, I'm concerned that this assumption won't hold in > practice. E.g., if I'm at home, I may have a tunnel to my corporation > and a connection to the Internet (or multiple ones). (This scenario is > described in the document). Howver, my ISP and my corporation > simply won't coordinate here. Consequently, I'm wondering > whether more guidance can be given here on how to set the > preferences (in the absence of coordination among the site > admins) and/or to make them configurable/mappable (on the > user's host) so that if the preferences don't achieve the > desired results by default, the user has some recourse to > adjust them to result in better behavior. Indeed, adding more > configuration capabilities on the host may make sense to go > in also to help deal with Routers that aren't upgraded, in > order to assign them preferences. > > Here is what the document says: > > > The preference values (both Default Router Preferences and Route > > Preferences) should not be routing metrics or > automatically derived > > from metrics: the preference values should be > configured. The High > > and Low (non-default) preference values should only be used when > > someone with knowledge of both routers and the network topology > > configures them explicitly. For example, it could be a common > > network administrator, or it could be a customer request to > > different administrators managing the routers. > > I worry that the above will not hold in practice in a majority of > cases. > > I wonder if a better applicability section would help, that describes > where this is expected to be used and how things need to be configured > by default in such environments. Section 4 specifies a couple exceptions to the usual rule that advertising preferences or specific routes requires coordinated admin of the routers. In particular, I think common scenarios like VPN or two independent ISPs should be handled correctly without coordinated admin of the routers. > 3) The document isn't very clear about exactly when to probe, and what > the actual probe algorithm is. ND has a very simple probe model. > Whenever sending to/through a neighbor, if that neighbor is not known > to be reachable (and sufficient time has elapsed), one probes. Probes > are then retransmitted if not responded to. In ND, one never needs to > probe neighboring routers that one is not actually using (except when > all routers are unreachable). This is OK, because the > assumption/model is that all neighboring routers are equal, > and if you have a working one, there is no need to check for > a better one. NUD handles the case where a next-hop fails and > another one should be tried. > > With this document, the model changes. There is an assumption that > some routers are better than others, and which router is better for a > destination depends on the actual route prefixes that are advertised. > That raises an issue of consistency. Are the neighbors that are being > used always consistent with the known preferences of the routers? In > particular, if a higher preference router is not reachable, when is it > probed? Or, suppose there is a change in the routing table (a prefix > is added or deleted), is there an attempt to (or a need to) > revalidate that all the next-hops currently in use are the > right ones based on the priorities/prefixes? > > It seems to me that a users of this document will intuitively expect > that when the highest preference router is reachable, it will be used. > Or when a higher preference router becomes available, routes will be > updated to use it. > > the document says: > > > 3.3. Destination Cache Management > > > > When host C processes a Router Advertisement and updates its > > conceptual Routing Table, it SHOULD invalidate or remove > Destination > > Cache Entries and redo next-hop determination for destinations > > affected by the Routing Table changes. The host MAY > implement this > > requirement by flushing its entire Destination Cache. > > Seems like the above SHOULD should be a MUST, in order to meet the > principle of least astonishment. > > However, the MAY seems ill-advised, as the Destination Cache may also > include other information (e.g., path MTU info?) that should not be > flushed as a side-effect of such a route change. Can the above be > implemented reasonably without resorting to just flushing the table > and rebuilding whenever a change is present? I view this as a quality of implementation issue. In many environments advertised preferences & routes might change rarely so a minimal implementation might choose simplicity. However my implementation does what you want - it incrementally revalidates Destination Cache Entries when routes & preferences change. > 4) I'm also unclear as to how easy it will be to implement the > specific lookup algorithm that type C hosts will implement. My > understandinng is that routing lookups today are done using > longest-match, where the lookup stops at a particular node in the > tree. I could imagine multiple nodes being at the same point in the > tree (i.e., corresponding to two or more instances of a prefix but > using different routers with possibly different preferences). > > But the algorithm specified actually says reachable routers are to be > preferred over unreachable ones. This means that the longest-match > lookup may stop at a node with an unreachable router. What is done in > this case? Does one have to unwind the tree search to try a node > visited earlier (i.e., a shorter match?)? Is this reasonable for > implementations? [note: its not immediately clear that one > can just remove nodes from the routing tree that correspond > to unreachable routers, because one must also probe these > routers in some cases.] > > Another implementation complexity is due to the preferences combined > with the reachability status. Many implementations have a user-level > process which takes preferences into account and only installs the > most preferred route for a given prefix into the kernel. Hence the > kernel need not be aware of preferences. Given the reachability status > all routes need to be in the kernel since the most preferred for > a given prefix might be unreachable and a less preferred > route might exist for the identical prefix. > > Q: who has implemented this draft? Can they comment on the > implementations issues mentioned above? I've implemented it (except for the new load-sharing part). Yes, the kernel needs to know all the routes. Keep in mind that the new Conceptual Sending Algorithm (section 3.2) applies only to hosts. Optimized router implementations, designed to support zillions of routes, are not affected. Now my route lookup is not particularly optimized so this wasn't an issue. But I have thought a bit about how I'd use a fancy longest-matching-prefix data structure. I think you could do a first tree search looking for a reachable router. If that fails, then you search again for an unreachable router. In either case, you end up at a node that has all the routes of the same length, and you pick the one with the best preference. And for load-sharing, choose randomly among the routes with the same preference. > ================ > Specific comments and nits: > > > The second > > change is a mandatory modification of the conceptual sending > > algorithm to support load-sharing among equivalent routers. > > remove per earlier comments? I'd like to hear from Bob on this. > > > Neighbor Discovery is to > > unicast routing as Multicast Listener Discovery is to multicast > > routing. In both cases, a single simple protocol > insulates the host > > from the variety of router-to-router protocols. > > The comparison of MLD with ND seems pretty weak to me. Sure, they both > isolate Host<->router interaction from > router<->router interaction, but beyond that they are very > different. Suggested reword: > > Neighbor Discovery shares with Multicast Listener Discovery the > property that they both define host-to-router interactions, while > shielding the host from having to participate in more general > router-to-router interactions. I like the analogy, but your reword is fine. > > This document also describes a mandatory change in host > behavior. > > Neighbor DiscoveryÆs conceptual sending algorithm is modified to > > require hosts to select randomly among equivalent routers. This > > distributes traffic to different destinations among the routers. > > Traffic to a single destination continues to use a > single router, > > because of the Destination Cache. > > Update per earlier comment? Again, I'd like to hear from Bob. > > 10 Reserved - MUST NOT be sent > > > If the > > Reserved (10) value is received, the receiver should > > treat the RA as having a zero Router Lifetime. > > s/should/MUST/ OK > > Note that in addition to the preference value in the > message header, > > a Router Advertisement can also contain a Route > Information Option > > for ::/0, with a preference value and lifetime. Encoding a > > preference value in the Router Advertisement header has some > > advantages: > > > > 1. It allows for a distinction between "best default > router" and > > "best router for default", as described below in section 5.1. > > > > 2. When the best default router is also the best router for > > default (which will be a common case), encoding the preference > > value in the message header is more efficient than > having to send > > a separate option. > > After a number of re-reads, I still do not understand the above > distinction. I think I understand the example, but the explanatory > text above is not intuitive at all. You mean you don't understand the distinction between "best default router" and "best router for default"? I have to give credit to Steve Deering for pointing it out to me. Here's the idea again (although I think section 5.1 already says this): Suppose you have a host with two next-hop routers, R1 and R2. R1 connects the host to the rest of the internet. R2 connects the host to a specific /48. 99% of the host's traffic goes to that /48. Then R2 is the best default router for the host, because sending traffic to R2 will produce the fewest Redirects. But R1 is the best router for ::/0. > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > | > > + > + > > | > | > > + Prefix > + > > | > | > > + > + > > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Shouldn't the picture show the prefix to be a variable width field? Sure, would you just use "..."? > > Prf (Route Preference) > > 2-bit signed integer. Indicates whether or > not to prefer > > this router for the prefix over others. > > reword for clarity (?): > > 2-bit signed integer. The Route Preference indicates whether to > prefer the router associated with this prefix over others, when > multiple identical prefixes (for different routers) have been > received. OK > > If the Reserved > > (10) value is received, the Route Information Option > > MUST be ignored. > > Why ignored? In the case where PrF is in the message header, the rules > say treat the value as 00. What is the motivation for handling these > two case differently? Actually, when Prf in the message header is 10, the rules say to treat the *Router Lifetime* as 0. This means there is no default route, which is like ignoring the Route Information Option. So I think the two cases are handled similarly. > > Route Lifetime > > 32-bit unsigned integer. The length of time > in seconds > > (relative to the time the packet is sent) that the > > prefix is valid for route determination. A > value of all > > one bits (0xffffffff) represents infinity. > > Note that the lifetimes in ND are only 16-bits. It seems like it would > be better to be consistent in the two documents. It is not immediately > clear that a lifetime of longer htan 18.2 hours (the max per ND's 16 > bits) is useful in practice. (Indeed, it may be worse the > useful in that an (incorrect) entry with a long timeout can > take days to weeks to expire.) > > Use 16 bits here as well? Actually, ND is inconsistent wrt lifetimes. Router Lifetime is 16 bits but Prefix Lifetimes are 32 bits. > > The Length field is 1, 2, or 3 depending on Prefix > Length. If Prefix > > Length is greater than 64, then Length must be 3. If > Prefix Length > > is greater than 0, then Length must be 2 or 3. If Prefix > Length is > > zero, then Length must be 1, 2, or 3. > > This text might be placed by moving up to the desription of the > "Length" field. OK > > The Prefix field is 0, 8, or 16 octets depending on Length. > > Move sentence to description of Prefix field? OK > > Routers SHOULD NOT include in a Router Advertisement two Route > > Information Options with the same Prefix and Prefix Length. > > Seems like MUST NOT would be better. Is there ever a valid reason to > allow routers to include two such options? OK. I don't know of a valid reason. > > 3. Conceptual Model of a Host > > > > There are three possible conceptual models for host > implementation > > of default router preferences and more-specific routes, > > corresponding to different levels of support. We refer > to these as > > host A, host B, and host C. Note that these are really > classes of > > hosts, not individual hosts. > > It would be more clear to use different terminology here. Rather than > saying "host A", say something like "Type-A host", "or level-1 > compliant host", etc. This change would need to be made throughout > the document. OK > > Host A ignores default router preferences and > more-specific routes. > > Host A uses the conceptual data structures described in Neighbor > > Discovery [2]. > > > > More clear to say something like > > Host [type] A implements Neighbor Discovery as defined in [2] and > does not implement any of the extensions described in this > document. OK > > Host B uses a Default Router List augmented with > preference values. > > Host B does not have a routing table. > > replace second sentence with: > > , but ignores all Route Information Options. OK > > Host C uses a Routing Table instead of a Default Router > List. (The > > Routing Table may also subsume the Prefix List, but that > is beyond > > the scope of this document.) Entries in the Routing Table have a > > Host C still DOES use a Default router list of some sort, but it is > presumably integrated with the routing table. Yes, the ::/0 routes in the routing table constitute in some sense the default router list. > > When a host avoids using a non-reachable router X and > instead uses > > another router Y, and the host would have used router X > if router X > > were reachable, then the host SHOULD probe router X's > reachability > > by sending a Neighbor Solicitation. A host MUST NOT > probe a router's > > reachability in the absence of useful traffic that the > host would > > have sent to the router if it were reachable. In any case, these > > probes MUST be rate-limited to no more than one per minute per > > router. > > details are left unspecified here, but may be significant. For one > thing, the above says "sending a Neighbor Solicitation". Is that what > a probe is? Or does sending probes include retransmitting? The > document isn't clear on this. The probes are normal Neighbor Solicits. They will either be unicast or multicast depending on the state of the NCE. Probes are not retransmitted, unless the host continues to generate new Destination Cache Entries. To go into more detail - per the Conceptual Sending Algorithm, sometimes a host will send a packet to a reachable router instead of an otherwise-better unreachable router. If the unreachable router would have been used if it were reachable, then the host sends a probe to the unreachable router. But these probes are rate-limited, so the host doesn't send too many, and the probes are only sent if the host is continuing to generate traffic that would have been sent to the router if it were reachable. Hence, the host will notice when the unreachable router becomes reachable so the host can start to use the better router. > > When a host chooses from multiple equivalent routers, it > MUST choose > > randomly. > > Define random better. Is it OK to pick a random order once (when the > list is built) and then do RR on the resultant list? Or must each new > choice of a router for a destination result in new random choice? (I > would assume the former is sufficient.) Picking a random order once and then using RR would not be sufficient. It would be vulnerable to periodic application traffic patterns. On the other hand, designs that for example hash the destination address to choose among the routers should be allowed. In any case, sounds like this text will be moving to another document. > > 4. Router Configuration > > applicability? intended usage, restrictions? > > The preference values (both Default Router Preferences and Route > Preferences) should not be routing metrics or automatically derived > from metrics: the preference values should be configured. The High > and Low (non-default) preference values should only be used when > someone with knowledge of both routers and the network topology > configures them explicitly. For example, it could be a common > network administrator, or it could be a customer request to > different administrators managing the routers. > > Not clear this is workable in practice. Of course if you are a network administrator managing your own routers this is workable. If you are a large customer you might have sufficient leverage. > An administrator of a router may configure the router to advertise > specific routes for directly connected subnets and any shorter > prefixes (eg, site, NLA, or TLA prefixes) for networks to which the > router belongs. > > Nit: TLA/NLA terminology is no longer in use. > > Separate references into normative/non-normative sections. Would it be OK to mark each reference as normative/non-normative? Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 30 13:06:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UK6QoN015931; Tue, 30 Jul 2002 13:06:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6UK6QAh015930; Tue, 30 Jul 2002 13:06:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UK6NoN015923 for ; Tue, 30 Jul 2002 13:06:23 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13644 for ; Tue, 30 Jul 2002 13:06:28 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17609 for ; Tue, 30 Jul 2002 13:06:28 -0700 (PDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Jul 2002 13:06:23 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 30 Jul 2002 13:03:54 -0700 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 30 Jul 2002 13:03:54 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 30 Jul 2002 13:03:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: per-connection config and destination address selection Date: Tue, 30 Jul 2002 13:03:19 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CEE0E@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: per-connection config and destination address selection Thread-Index: AcI3il+PU93UmJ3vQEC/zpLSiod2PgAeLZjw From: "Richard Draves" To: "JINMEI Tatuya / ????" Cc: X-OriginalArrivalTime: 30 Jul 2002 20:03:19.0352 (UTC) FILETIME=[264ED380:01C23804] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6UK6NoN015924 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, this is an issue with per-socket configuration of source address selection. I haven't figured out a great solution. Obviously one can imagine passing flags to getaddrinfo but that isn't so attractive. For the temporary vs public addresses, this isn't a big deal because the temporary vs public rule 7 is so low on the list and usually the choice won't affect the common prefix length of the source address with the possible destination addresses. In other words, the choice of the destination address will not be affected if the source selection that happens inside destination address ordering is not configured properly for temporary vs public. For the home vs care-of addresses, it is more of a problem. I don't have enough operational experience with that aspect to have much preference for a solution. Rich > -----Original Message----- > From: jinmei@isl.rdc.toshiba.co.jp > [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: Monday, July 29, 2002 10:29 PM > To: ipng@sunroof.eng.sun.com > Subject: per-connection config and destination address selection > > > draft-ietf-ipv6-default-addr-select-08.txt mentions two > per-connection configuration switches for source address > selection. One is for home vs care-of addresses, and the > other is for temporary vs public addresses. > > The value of the switches may affect destination address > selection, because it depends on the expected source address > corresponding to each candidate of destination address. > > I have a feeling that the current draft is not very clear > about the dependency. For example, Section 8 (Implementation > Considerations) indicates that the destination address > selection algorithm can be implemented inside getaddrinfo(). > However, the library function does not always know the value > of per-connection switches in advance. An application may > even not open a socket for the actual connection when calling > getaddrinfo(). > > This may rather be an implementation issue, so I don't think > we need a major revise of the draft just due to this. But I > also think it would be good to add some note about the > dependency in Section 8 before publishing the draft. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 31 12:13:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VJDfoN019742; Wed, 31 Jul 2002 12:13:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6VJDfC9019741; Wed, 31 Jul 2002 12:13:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VJDcoN019734 for ; Wed, 31 Jul 2002 12:13:38 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18118 for ; Wed, 31 Jul 2002 12:13:43 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13649 for ; Wed, 31 Jul 2002 13:13:42 -0600 (MDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g6VJDMe8126336; Wed, 31 Jul 2002 15:13:22 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g6VJDJ7r063902; Wed, 31 Jul 2002 15:13:20 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g6VJCIV16013; Wed, 31 Jul 2002 15:12:18 -0400 Message-Id: <200207311912.g6VJCIV16013@rotala.raleigh.ibm.com> To: "Richard Draves" cc: ipng@sunroof.eng.sun.com, "Bob Hinden" Subject: Re: AD comments on draft-ietf-ipv6-router-selection-02.txt In-Reply-To: Message from "Tue, 30 Jul 2002 12:49:17 PDT." <7695E2F6903F7A41961F8CF888D87EA807D1F912@red-msg-06.redmond.corp.microsoft.com> Date: Wed, 31 Jul 2002 15:12:18 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Rich. > Section 4 specifies a couple exceptions to the usual rule that > advertising preferences or specific routes requires coordinated > admin of the routers. In particular, I think common scenarios like > VPN or two independent ISPs should be handled correctly without > coordinated admin of the routers. Section 4 has some "mays", some of which might better be should/SHOULDs. I.e., an admin SHOULD set a low priority if the router doesn't reach the internet (due to connectivity or firewall). perhaps also, SHOULD NOT set high priority unless it has control over all the routers at issue and can thus make sensible decisions. Does it ever make sense to advertise a high preference in the absence of more detailed knowledge of the topology? Also, in chatting with Erik Nordmark, he indicated that at one point there were some discussions about adding a client capability to have a map table that mapped received preferences into other values, to handle situations where the received preferences didn't have the desired result. Would that be a useful thing to have? > > However, the MAY seems ill-advised, as the Destination Cache may also > > include other information (e.g., path MTU info?) that should not be > > flushed as a side-effect of such a route change. Can the above be > > implemented reasonably without resorting to just flushing the table > > and rebuilding whenever a change is present? > I view this as a quality of implementation issue. In many > environments advertised preferences & routes might change rarely so > a minimal implementation might choose simplicity. However my > implementation does what you want - it incrementally revalidates > Destination Cache Entries when routes & preferences change. One problem with the above is you assume that the implementor has knowledge about the enivironments in which technology will be deployed, and can thus make such tradeoffs. Is this a valid assumption here? I suspect that in this case, the implementor can only assume that it will be deployed in general and widely-diverse enivoronments and that the above assumptions simply cannot be reasonably made. It would be better if the spec did not allow poor implementation choices (that have undesirable consequences on the internet) to be considered "in conformance with the standard". > > Q: who has implemented this draft? Can they comment on the > > implementations issues mentioned above? > I've implemented it (except for the new load-sharing part). Yes, the > kernel needs to know all the routes. > Keep in mind that the new Conceptual Sending Algorithm (section 3.2) > applies only to hosts. Optimized router implementations, designed to > support zillions of routes, are not affected. Agreed. I'd still be interested from other folks that have (or are considering) implementing it. > > > Note that in addition to the preference value in the > > message header, > > > a Router Advertisement can also contain a Route > > Information Option > > > for ::/0, with a preference value and lifetime. Encoding a > > > preference value in the Router Advertisement header has some > > > advantages: > > > > > > 1. It allows for a distinction between "best default > > router" and > > > "best router for default", as described below in section 5.1. > > > > > > 2. When the best default router is also the best router for > > > default (which will be a common case), encoding the preference > > > value in the message header is more efficient than > > having to send > > > a separate option. > > > > After a number of re-reads, I still do not understand the above > > distinction. I think I understand the example, but the explanatory > > text above is not intuitive at all. > You mean you don't understand the distinction between "best default > router" and "best router for default"? Its a subtle distinction and the terms used to distinguish are not very intuitive. > I have to give credit to Steve Deering for pointing it out to > me. Here's the idea again (although I think section 5.1 already says > this): Note that the paragraph quoted above which introduces the terms precedes section 5.1 quite a lot. > Suppose you have a host with two next-hop routers, R1 and R2. R1 > connects the host to the rest of the internet. R2 connects the host > to a specific /48. 99% of the host's traffic goes to that /48. Then > R2 is the best default router for the host, because sending traffic > to R2 will produce the fewest Redirects. But R1 is the best router > for ::/0. I understand the example (though I'm not immediately convinced the distinction is terribly useful). But that doesn't mean the definitions of the terms will make sense to the reader. It would be nice if you could define/explain the two terms without having to use that example. Can't the difference be described intuitively, and not with a circular definition? two suggestions. The first reference to the words (which doesn't define them) includes a forward reference to much later in the document. It would be nice to not need the reference, since the first use of the terms doesn't at all explain them. The later words could be better: I.e., The best default router is not quite the same thing as the best router for default. The best default router is the router that will generate the fewest number of redirects for the host's traffic. The best router for default is the router with the best route toward the wider internet. How about changing the last part of the last sentence: The best router for default is the router with the best route toward the wider internet. But, I still think these terms are confusing and not particularly useful. > Sure, would you just use "..."? Something like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |Resvd|Prf|Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > If the Reserved > > > (10) value is received, the Route Information Option > > > MUST be ignored. > > > > Why ignored? In the case where PrF is in the message header, the rules > > say treat the value as 00. What is the motivation for handling these > > two case differently? > Actually, when Prf in the message header is 10, the rules say to > treat the *Router Lifetime* as 0. This means there is no default > route, which is like ignoring the Route Information Option. So I > think the two cases are handled similarly. Not quite the same. A lifetime of 0 would update/replace the lifetime for an existing route. Just ignoring the option wouldn't do that. I think what you want here is to design for future extensibility. If sometime in the future, someone were to define a usage for the 10 value, you wouldn't want existing implementations to do things that prevent the new usage. Seems like having such entries be completely ignored would be more flexible than having it treated like a lifetime of 0. I.e, the current semantics might effectively prevent being able to define the value later because of what existing implementations will then do with it. But, given that there are existing implementations that will never look at the preference value, I think the safest thing to do is go with "treat the value as if it had the default preference". > > > Route Lifetime > > > 32-bit unsigned integer. The length of time > > in seconds > > > (relative to the time the packet is sent) that the > > > prefix is valid for route determination. A > > value of all > > > one bits (0xffffffff) represents infinity. > > > > Note that the lifetimes in ND are only 16-bits. It seems like it would > > be better to be consistent in the two documents. It is not immediately > > clear that a lifetime of longer htan 18.2 hours (the max per ND's 16 > > bits) is useful in practice. (Indeed, it may be worse the > > useful in that an (incorrect) entry with a long timeout can > > take days to weeks to expire.) > > > > Use 16 bits here as well? > Actually, ND is inconsistent wrt lifetimes. Router Lifetime is 16 > bits but Prefix Lifetimes are 32 bits. So it is. But I would argue that the two lifetimes in ND are for orthogonal concepts (i.e, usability of a particular router vs. on-link/autoconfig for a given prefix). The lifetimes in this document all correspond to routing entries through a particular router. > > > When a host avoids using a non-reachable router X and > > instead uses > > > another router Y, and the host would have used router X > > if router X > > > were reachable, then the host SHOULD probe router X's > > reachability > > > by sending a Neighbor Solicitation. A host MUST NOT > > probe a router's > > > reachability in the absence of useful traffic that the > > host would > > > have sent to the router if it were reachable. In any case, these > > > probes MUST be rate-limited to no more than one per minute per > > > router. > > > > details are left unspecified here, but may be significant. For one > > thing, the above says "sending a Neighbor Solicitation". Is that what > > a probe is? Or does sending probes include retransmitting? The > > document isn't clear on this. > The probes are normal Neighbor Solicits. They will either be unicast > or multicast depending on the state of the NCE. > Probes are not retransmitted, unless the host continues to generate > new Destination Cache Entries. > To go into more detail - per the Conceptual Sending Algorithm, > sometimes a host will send a packet to a reachable router instead of > an otherwise-better unreachable router. If the unreachable router > would have been used if it were reachable, then the host sends a > probe to the unreachable router. But these probes are rate-limited, > so the host doesn't send too many, and the probes are only sent if > the host is continuing to generate traffic that would have been sent > to the router if it were reachable. > Hence, the host will notice when the unreachable router becomes > reachable so the host can start to use the better router. My point is that some of the above explanation would be useful to capture in the draft itself. Right now, it's left as detail. For one thing, "probe" is defined in ND. "probe" as used in this document, seems somewhat different (i.e, no retransmits via timers). Just clarifying this point would help, I think. > Picking a random order once and then using RR would not be > sufficient. It would be vulnerable to periodic application traffic > patterns. On the other hand, designs that for example hash the > destination address to choose among the routers should be > allowed. In any case, sounds like this text will be moving to > another document. OK. > > > 4. Router Configuration > > > > applicability? intended usage, restrictions? > > > > The preference values (both Default Router Preferences and Route > > Preferences) should not be routing metrics or automatically derived > > from metrics: the preference values should be configured. The High > > and Low (non-default) preference values should only be used when > > someone with knowledge of both routers and the network topology > > configures them explicitly. For example, it could be a common > > network administrator, or it could be a customer request to > > different administrators managing the routers. > > > > Not clear this is workable in practice. > Of course if you are a network administrator managing your own > routers this is workable. If you are a large customer you might have > sufficient leverage. I don't understand the last comment. I agree that within an enteprise, setting the preferences (for use within the enterprise) makes sense. But that is only one applicability. I also thought this was aimed at home users with connections to their coporate VPN and the dsl/cable ISPs. In the latter case, the admins won't coordinate. Since this is also an important usage, it would be good to be sure the document explains how things will work in that environment as well. > > An administrator of a router may configure the router to advertise > > specific routes for directly connected subnets and any shorter > > prefixes (eg, site, NLA, or TLA prefixes) for networks to which the > > router belongs. > > > > Nit: TLA/NLA terminology is no longer in use. > > > > Separate references into normative/non-normative sections. > Would it be OK to mark each reference as normative/non-normative? Maybe. I understand this is a problem with the Word template not doing this automatically. Let me see about this. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 31 12:14:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VJEcoN019752; Wed, 31 Jul 2002 12:14:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6VJEcUk019751; Wed, 31 Jul 2002 12:14:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VJEYoN019744 for ; Wed, 31 Jul 2002 12:14:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08514 for ; Wed, 31 Jul 2002 12:14:38 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08561 for ; Wed, 31 Jul 2002 13:14:38 -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 MAA07094; Wed, 31 Jul 2002 12:14:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6VJEb803486; Wed, 31 Jul 2002 12:14:37 -0700 X-mProtect: <200207311914> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlDbFX5; Wed, 31 Jul 2002 12:14:35 PDT Message-Id: <4.3.2.7.2.20020730152401.02f2a478@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Jul 2002 12:13:43 -0700 To: "Richard Draves" From: Bob Hinden Subject: RE: AD comments on draft-ietf-ipv6-router-selection-02.txt Cc: "Thomas Narten" , , "Bob Hinden" In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA807D1F912@red-msg-06.redmon d.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, > > draft-ietf-ipv6-host-load-sharing-00.txt with router-selection. > > > > If I understand the intent, I believe it is a mistake to merge the two > > documents. It would be better to keep all mandatory changes to the ND > > spec in a way that they are clearly identifiable. Burying mandatory > > changes to the ND document within a related (but > > optional-to-implement) document will make it hard for folks > > to find those changes. > > > > Resurrecting host-load-sharing seems a fine way to go. At some point, > > it would probably make sense to incorporate the text directly in the > > ND spec anyway. (Or maybe we should just delay making the update until > > ND needs to be respun -- this depends on what other issues people have > > with the ND spec.) > >Yes, originally this document was entirely optional but when I merged in >load-sharing it picked up a mandatory requirement. The main rationale for >merging is that both affect the same code (next-hop determination). On the >other hand, it is confusing to have mandatory & optional mixed. Bob, what >do you think? My original preference was to keep them separate, but there was a lot of push back on the mailing list. Based on the mailing list discussion, we combined them. I agree that despite the work to combine them, it is confusing to have mandatory & optional mixed. My recommendation is to publish them separately. This will require some small changes in the default router selection document (keeping the load sharing, but changing the mandatory/optional text). Any objections to this approach? 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 Jul 31 14:13:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VLD1oN020551; Wed, 31 Jul 2002 14:13:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6VLD1O8020550; Wed, 31 Jul 2002 14:13:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VLCwoN020543 for ; Wed, 31 Jul 2002 14:12:58 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13544 for ; Wed, 31 Jul 2002 14:13:02 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17431 for ; Wed, 31 Jul 2002 15:13:00 -0600 (MDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 31 Jul 2002 14:13:19 -0700 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 31 Jul 2002 14:12:59 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 31 Jul 2002 14:12:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: AD comments on draft-ietf-ipv6-router-selection-02.txt Date: Wed, 31 Jul 2002 14:12:59 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CEE1A@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD comments on draft-ietf-ipv6-router-selection-02.txt Thread-Index: AcI4xoeGt/eFpnnlSEmfK/bJMQRHwQAEFD3w From: "Richard Draves" To: "Bob Hinden" Cc: "Thomas Narten" , X-OriginalArrivalTime: 31 Jul 2002 21:12:59.0685 (UTC) FILETIME=[0C64C550:01C238D7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6VLCwoN020544 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My original preference was to keep them separate, but there > was a lot of > push back on the mailing list. Based on the mailing list > discussion, we > combined them. I agree that despite the work to combine them, it is > confusing to have mandatory & optional mixed. > > My recommendation is to publish them separately. This will > require some > small changes in the default router selection document > (keeping the load > sharing, but changing the mandatory/optional text). I don't quite understand. Are you saying keep the load-sharing section in the router-selection draft, but make it optional, and then a second document makes load sharing mandatory?? Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 31 14:37:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VLb9oN020584; Wed, 31 Jul 2002 14:37:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g6VLb9OK020583; Wed, 31 Jul 2002 14:37:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6VLb5oN020576 for ; Wed, 31 Jul 2002 14:37:05 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00426 for ; Wed, 31 Jul 2002 14:37:10 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26006 for ; Wed, 31 Jul 2002 14:37:09 -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 OAA15315; Wed, 31 Jul 2002 14:37:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6VLb8M15393; Wed, 31 Jul 2002 14:37:08 -0700 X-mProtect: <200207312137> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNIW7H6; Wed, 31 Jul 2002 14:37:06 PDT Message-Id: <4.3.2.7.2.20020731141913.02711e20@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Jul 2002 14:36:15 -0700 To: "Richard Draves" From: Bob Hinden Subject: RE: AD comments on draft-ietf-ipv6-router-selection-02.txt Cc: "Bob Hinden" , "Thomas Narten" , In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA8063CEE1A@red-msg-06.redmon d.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, > > My recommendation is to publish them separately. This will > > require some > > small changes in the default router selection document > > (keeping the load > > sharing, but changing the mandatory/optional text). > >I don't quite understand. Are you saying keep the load-sharing section >in the router-selection draft, but make it optional, and then a second >document makes load sharing mandatory?? Sorry, I wasn't clear. Keep the load-sharing that applies to routers of equal priority in the router-selection draft. Load-sharing should be done in these cases. The text that applies to the basic ND default-router case should be removed as it would duplicate the load-sharing draft. 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 --------------------------------------------------------------------